--- /dev/null
+2025-02-02 Nick Clifton <nickc@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-02-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-31 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Do not relax against __[start|stop]_SECNAME symbol
+
+2025-01-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-30 Nick Clifton <nickc@redhat.com>
+
+ Remove a couple of entries in the binutils MAINTAINERS file
+
+2025-01-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-28 Nick Clifton <nickc@redhat.com>
+
+ Updated translations for various sub-directories
+
+2025-01-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-27 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-24 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-23 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+ Guillaume VACHERIAS <guillaume.vacherias@st.com>
+
+ 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 <sam@gentoo.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-22 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <nickc@redhat.com>
+
+2025-01-22 Jan Beulich <jbeulich@suse.com>
+
+ x86/Solaris: correct support for Sun form of CMOV<size>.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 <hudi2011@163.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-21 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ More updated translations
+
+2025-01-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-20 Maciej W. Rozycki <macro@redhat.com>
+
+ 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 <nickc@redhat.com>
+
+ Update translations for various sub-directories
+
+2025-01-20 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <cailulu@loongson.cn>
+
+ gas/NEWS,ld/NEWS: Announce LoongArch changes in 2.44
+
+2025-01-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-19 Nick Clifton <nickc@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-18 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <guinevere@redhat.com>
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <guinevere@redhat.com>
+
+2025-01-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <keiths@redhat.com>
+
+2025-01-17 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <guinevere@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2025-01-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: update binutils/NEWS for 2.44
+ ChangeLog
+ 2025-01-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * binutils/NEWS: Updated.
+
+2025-01-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * src/Hist_data.cc (DbeInstr::mapPCtoLine): Check for null pointer.
+
+2025-01-17 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <jan@jankratochvil.net>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <aburgess@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+ temp adding completion
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2025-01-17 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2025-01-17 MayShao-oc <MayShao-oc@zhaoxin.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <nickc@redhat.com>
+
+ Sync config.guess and config.sub with latest versions from the config project.
+
+2025-01-17 Jan Beulich <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <nelson@rivosinc.com>
+
+ RISC-V: Added lost zcmt in gas imply testcase.
+
+ gas/NEWS: Updated risc-v assembler support in 2.44.
+
+2025-01-17 Kito Cheng <kito.cheng@sifive.com>
+
+ 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 <monk.chiang@sifive.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * src/parse.cc: Don't check Elf when file is in archive.
+
+2025-01-17 Alan Modra <amodra@gmail.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-16 Alan Modra <amodra@gmail.com>
+
+ plugin_get_ir_dummy_bfd leak
+ * plugin.c (plugin_get_ir_dummy_bfd): Free bfd filename.
+
+ ld parser buffer leak
+ * ldlex.l (<<EOF>>): yy_delete_buffer current.
+ (yy_create_string_buffer): Use yyalloc.
+
+2025-01-16 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ NEWS: Mention mixed LTO and non-LTO output support for ld -r
+
+2025-01-16 Nick Clifton <nickc@redhat.com>
+
+ Copy gcc commit e76df3586417d645dd84e8a1ab165605a8924796 to sourceware
+
+ Have readelf sanitize the program interpreter string before displaying it.
+
+2025-01-16 Tom de Vries <tdevries@suse.de>
+
+ [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 <MayShao-oc@zhaoxin.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <slow core id>.
+
+ 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 <tdevries@suse.de>
+
+ [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 <sergiodj@sergiodj.net>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-15 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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ö <martin@martin.st>
+
+ 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 <matthieu.longo@arm.com>
+
+ aarch64: GCS tests for linking issues with dynamic objects
+
+2025-01-15 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [1] https://github.com/IBM/s390x-abi
+ [2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces
+
+2025-01-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2025-01-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2025-01-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <kevinb@redhat.com>
+
+2025-01-15 Hui Li <lihui@loongson.cn>
+
+ 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 <stdio.h>
+ 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 <lihui@loongson.cn>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <jan.vrany@labware.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ Fix known minor objdump leak
+ * objdump.c (main): Free disassembler_options.
+
+2025-01-15 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <guinevere@redhat.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-15 Alan Modra <amodra@gmail.com>
+
+ 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 <OPTION_INSN_WIDTH>): Restrict size of insn_width.
+
+2025-01-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/32490
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490
+
+2025-01-15 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-14 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-14 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <liuyang22@iscas.ac.cn>
+
+ 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 <tom@tromey.com>
+
+2025-01-14 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <guinevere@redhat.com>
+
+2025-01-14 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <guinevere@redhat.com>
+
+2025-01-14 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <guinevere@redhat.com>
+
+2025-01-14 Sam James <sam@gentoo.org>
+
+ ld: regenerate
+ 80dc29527ff9b5179741c360418e77e5064f2b69 contained some changes from
+ non-vanilla autoconf. Regenerate.
+
+ ChangeLog:
+
+ * config.in: Regenerate.
+ * configure: Regenerate.
+
+2025-01-14 Adhemerval Zanella <adhemerval.zanella@linaro.org>
+
+ 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 <adhemerval.zanella@linaro.org>
+
+ 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 <xutong.ma@inria.fr>
+
+ Fix a syntax error in sim/common/cgen-mem.h
+
+2025-01-14 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+2025-01-14 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <indu.bhagat@oracle.com>
+ Approved-by: Jan Beulich <jbeulich@suse.com>
+
+2025-01-14 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+2025-01-14 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <indu.bhagat@oracle.com>
+ Approved-by: Richard Earnshaw <richard.earnshaw@arm.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+
+2025-01-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+
+2025-01-14 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <lin1.hu@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <lin1.hu@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-13 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <aditya.kamath1@ibm.com>
+
+ 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 <Python.h>
+
+ 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 <tom@tromey.com>
+
+2025-01-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ gdb, doc: do a minor fix in the description of qTSTMat
+ Fix a typo and do a format change.
+
+2025-01-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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:
+ <https://debuginfod.archlinux.org>
+ 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 <jit_frame_unwind>, 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 <jit_frame_unwind>) 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 <thiago.bauermann@linaro.org>
+
+2025-01-13 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Cleanup the imply code and test cases for vendor xsf extensions.
+
+2025-01-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-12 Andrei Pikas <gdb@mail.api.win>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <sergiodj@sergiodj.net>
+
+ Fix typo in gdb/csky-linux-tdep.c
+ This was flagged by Debian's lintian.
+
+2025-01-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ Use bool in linespec
+ This changes various spots in linespec to use a bool rather than an
+ int.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ Minor cleanup in linespec.c:add_minsym
+ This cleans up a 'return' in linespec.c:add_minsym.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-11 Tom Tromey <tom@tromey.com>
+
+ Add constructor and destructor to linespec_state
+ This changes linespec_state to have real constructors and a
+ destructor.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-10 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
+
+2025-01-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2025-01-10 MayShao-oc <MayShao-oc@zhaoxin.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tdevries@suse.de>
+
+ [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<typename T, typename A = std::allocator<T>>
+ +template<typename T,
+ + typename A
+ +#if __cplusplus >= 202002L
+ + = std::pmr::polymorphic_allocator<T>
+ +#else
+ + = std::allocator<T>
+ +#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 <tom@tromey.com>
+
+ [1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator
+
+2025-01-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <tankut.baris.aktemur@intel.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <fun_three>:
+ 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 <fun_two>:
+ 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 <arnez@linux.ibm.com>
+
+ [1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf
+
+2025-01-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <arnez@linux.ibm.com>
+
+2025-01-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <tankut.baris.aktemur@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-09 Alan Modra <amodra@gmail.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2025-01-09 Alan Modra <amodra@gmail.com>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ ld: Utilize specific digit ranges for different numeral systems
+ * ldlex.l: Utilize specific digit ranges for different
+ numeral systems.
+
+2025-01-09 Charlie Jenkins <charlie@rivosinc.com>
+
+ 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 <charlie@rivosinc.com>
+
+ 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 <aburgess@redhat.com>
+
+2025-01-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-08 Tom Tromey <tromey@adacore.com>
+
+ 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 <thiago.bauermann@linaro.org>
+
+ 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 <simon.marchi@efficios.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+ Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3
+
+2025-01-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <liwei.xu@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2025-01-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-07 Nick Clifton <nickc@redhat.com>
+
+ Updated Malay translation for the bfd sub-directory
+
+2025-01-07 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2025-01-07 Christina Schimpe <christina.schimpe@intel.com>
+
+ 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 <tom@tromey.com>
+
+2025-01-07 Tom Tromey <tromey@adacore.com>
+
+ 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 <chigot@adacore.com>
+
+ 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 <chigot@adacore.com>
+
+ 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 <amodra@gmail.com>
+
+ Remove dead code in bfd_check_format_matches
+ Commit cb001c0d283d made code added in 64bfc2584c01 dead. Remove it.
+
+2025-01-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-06 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2025-01-06 Jan Beulich <jbeulich@suse.com>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <command-line>:
+ /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 <tdevries@suse.de>
+ 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 <jbeulich@suse.com>
+
+ x86/Intel: don't accept memory operands with J*CXZ and LOOP*
+ PR gas/31887
+
+ Like for, in particular, J<cc> 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 <jbeulich@suse.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2025-01-06 Tom de Vries <tdevries@suse.de>
+
+ [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 <amodra@gmail.com>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Eliminate redundant instruction macro
+ include/ChangeLog:
+
+ * opcode/riscv.h: Eliminate redundant instruction macro M_j.
+
+2025-01-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-05 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2025-01-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <eliz@gnu.org>
+
+ [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 <eliz@gnu.org>
+
+ [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 <eliz@gnu.org>
+
+ [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 <tdevries@suse.de>
+
+ [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 <thiago.bauermann@linaro.org>
+
+ [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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ _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 <tdevries@suse.de>
+
+ [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 <maskray@sourceware.org>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-03 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-02 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+ Hu, Lin1 <lin1.hu@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2025-01-01 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ gnu_debuglink related memory leak
+ * opncls.c (bfd_fill_in_gnu_debuglink_section): Free section
+ contents on success too.
+
+2025-01-01 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ Regen gprofng after copyright update
+
+ Update year range in copyright notice of binutils files
+
+2025-01-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-31 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-29 Joel Brobecker <brobecker@adacore.com>
+
+ 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 <brobecker@adacore.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-27 Jan Beulich <jbeulich@suse.com>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-25 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <guinevere@redhat.com>
+
+2024-12-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ Fix error: macro may be used uninitialized
+ PR 32391 commit 9f2e3c21f6 fallout
+
+2024-12-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-23 Haochen Jiang <haochen.jiang@intel.com>
+ Jun Zhang <jun.zhang@intel.com>
+ Zewei Mo <zewei.mo@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-22 Carlos Galvez <carlosgalvezp@gmail.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-22 Flavio Cruz <flaviocruz@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-20 Keith Seitz <keiths@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-20 Tom Tromey <tromey@adacore.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [gdb/cli] Don't prefill for operate-and-get-next of last command
+ Consider operate-and-get-next [1] in bash:
+ ...
+ $ <echo 1>echo 1<enter>
+ 1
+ $ <echo 2>echo 2<enter>
+ 2
+ $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
+ 1
+ $ echo 2<Ctrl-o>
+ 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>echo 1<enter>
+ 1
+ $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
+ 1
+ $
+ ...
+ but with gdb do we have a prefill:
+ ...
+ (gdb) echo 1\n
+ 1
+ (gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o>
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-20 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-20 Nick Clifton <nickc@redhat.com>
+
+ Fix examples of the use of the linker script TYPE keyword
+
+2024-12-20 Tom de Vries <tdevries@suse.de>
+
+ [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<tab>" 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 <keiths@redhat.com>
+
+ PR testsuite/31229
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229
+
+2024-12-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-19 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-19 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-12-19 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+
+2024-12-19 Nick Clifton <nickc@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-18 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <keiths@redhat.com>
+
+ [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 <eliz@gnu.org>
+
+2024-12-18 Tom Tromey <tromey@adacore.com>
+
+ Add check-include-guards.py to pre-commit
+ This changes pre-commit to run check-include-guards.py.
+
+ Reviewed-By: Tom de Vries <tdevries@suse.de>
+
+2024-12-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-12-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <flaviocruz@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-12-17 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <tdevries@suse.de>
+
+2024-12-17 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <tdevries@suse.de>
+
+2024-12-17 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <tdevries@suse.de>
+
+2024-12-17 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <tdevries@suse.de>
+
+2024-12-17 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ nm: Avoid potential segmentation fault when displaying symbols without version info.
+ PR 32467
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbsupport: fix a typo in a comment in common-regcache.h
+ Fix a typo.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-17 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-16 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-16 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <sam@gentoo.org>
+
+2024-12-16 Tom Tromey <tromey@adacore.com>
+
+ 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 <pedro@palves.net>
+
+2024-12-16 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-16 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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><d5d27>: Abbrev Number: 12 (DW_TAG_compile_unit)
+ <d5d28> DW_AT_producer : (alt indirect string, offset: 0x16433) t
+ <d5d2c> DW_AT_language : 29 (C11)
+ <d5d2d> DW_AT_name : (indirect line string, offset: 0x5c8f): dlmopen.c
+ <d5d31> DW_AT_comp_dir : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn
+ <d5d35> DW_AT_low_pc : 0x8a4c0
+ <d5d3d> DW_AT_high_pc : 408
+ <d5d3f> 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-16 Nick Clifton <nickc@redhat.com>
+
+ Update translations for the opcodes directory for the French and Serbian languages.
+
+2024-12-16 Jan Beulich <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-15 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-14 oltolm <oleg.tolmatcev@gmail.com>
+
+ fix Windows build
+ Fix the Windows build that was broken in "Introduce \"command\" styling".
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-14 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'TypeError'>: '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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-13 Alan Modra <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html
+
+2024-12-13 oltolm <oleg.tolmatcev@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-12-13 Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-12-13 Marek Pikuła <m.pikula@partner.samsung.com>
+
+ 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 <nickc@redhat.com>
+
+ Give unique names to s390 assembler opcode tests.
+
+2024-12-13 Jan Beulich <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <eliz@gnu.org>
+ Reviewed-By: Keith Seitz <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-13 Tom Tromey <tom@tromey.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-13 Tom Tromey <tom@tromey.com>
+
+ 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 <eliz@gnu.org>
+ Reviewed-By: Keith Seitz <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-12 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-12 Tom Tromey <tom@tromey.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-12 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-12 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-12 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-12 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <aburgess@redhat.com>
+ Approved-By: Jan Beulich <jbeulich@suse.com>
+
+2024-12-12 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-11 Tom Tromey <tromey@adacore.com>
+
+ 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á <ahajkova@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-11 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-11 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix sorting in Hist_data::sort
+ If the '-name soname' option is used, the fake '<Total>' function is expanded
+ with the name loadobject.
+
+ gprofng/ChangeLog
+ 2024-12-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Hist_data.cc (Hist_data::sort): Fix sorting.
+
+2024-12-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html
+
+2024-12-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-12-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <git@xen0n.name>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-09 Alan Modra <amodra@gmail.com>
+
+ Re: gprofng: use gprofng- prefix for gprofng binaries
+ Commit d25ba4596e85 mangled ZLIBINC to ZLIgp-C. Fix that.
+
+2024-12-09 Peter Bergner <bergner@linux.ibm.com>
+
+ 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) <hashst, hashstp, hashchk, hashchkp>: Use RAS.
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-12-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+2024-12-09 Tom de Vries <tdevries@suse.de>
+
+ [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:
+ ...
+ + <syscall name="setxattrat" number="463"/>
+ + <syscall name="getxattrat" number="464"/>
+ + <syscall name="listxattrat" number="465"/>
+ + <syscall name="removexattrat" number="466"/>
+ ...
+ 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 <mark@klomp.org>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-09 Nick Clifton <nickc@redhat.com>
+
+ Add linker diagnostic message about missing static libraries
+
+2024-12-09 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-06 Alan Modra <amodra@gmail.com>
+
+ fix dependencies for ld/emultemp/nto.em
+ Don't use "." to source .em files, use "source_em".
+
+2024-12-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <guinevere@redhat.com>
+
+ gdb: Fix use-after-free when an objfile has no symbols to load
+ The recent commit <HASH> 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 <simark@simark.ca>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-12-06 Hannes Domani <ssbssa@yahoo.de>
+
+ 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<decltype(context)>::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<typename Function>
+ 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 <tom@tromey.com>
+
+2024-12-06 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <jbeulich@suse.com>
+ 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 <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <ssbssa@yahoo.de>
+
+2024-12-05 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <nickc@redhat.com>
+
+ Fix clang compile time warning about optarg parameter shadowing optarg global variable.
+
+2024-12-05 Hu, Lin1 <lin1.hu@intel.com>
+ Zewei Mo <zewei.mo@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+ Levy Hsu <admin@levyhsu.com>
+
+ 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 <sign> 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 <hjl.tools@gmail.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-12-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <simon.marchi@efficios.com>
+
+2024-12-04 Simon Marchi <simark@simark.ca>
+
+ [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 <simark@simark.ca>
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2024-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: make get_thread_lwp a function
+ Replace the macro with a static inline function.
+
+ Change-Id: I1cccf5b38d6a412d251763f0316902b07cc28d16
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-12-04 Stephan Rohr <stephan.rohr@intel.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-12-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <christina.schimpe@intel.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-04 Tom Tromey <tom@tromey.com>
+
+ 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 <christina.schimpe@intel.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-04 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <class 'ModuleNotFoundError'>: 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 <tom@tromey.com>
+
+ PR python/32379
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR python/32389
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32389
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR python/32388
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32388
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-12-03 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2024-12-03 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-03 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-12-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <class 'AttributeError'>: \
+ 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 <guinevere@redhat.com>
+
+ 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 *<instruction>" 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 <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-12-03 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jskumari@linux.ibm.com>
+
+ 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 <nickc@redhat.com>
+
+ Updated Russian translation and new Malay translation for the BFD sub-directory
+
+2024-12-03 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <lingling.kong@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+ Matthieu Longo <matthieu.longo@arm.com>
+ Yury Khrustalev <yury.khrustalev@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 && !<something about aprop>) || !aprop
+
+ It seems easier to understand if it is changed as follows:
+
+ (!aprop || !<something about aprop>)
+
+2024-12-02 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <End of list>
+ ...
+
+ 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 <End of list>
+ ...
+
+ 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 <kevinb@redhat.com>
+
+2024-12-02 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <stephan.rohr@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-12-02 Dongyan Chen <chendongyan@isrc.iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-12-01 Alan Modra <amodra@gmail.com>
+
+ Correct hpux-core.c thread_section_p signature
+ Fix fallout from commit 0a1b45a20eaa.
+
+2024-12-01 Alan Modra <amodra@gmail.com>
+
+ 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 <oleg.tolmatcev@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-29 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <flo2030@eich-krohm.de>
+
+2024-11-29 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ x86: SETcc doesn't permit W suffix
+ Accidentally I had removed No_wSuf when cloning the extra template.
+
+2024-11-29 Surya Kumari Jangala <jskumari@linux.ibm.com>
+
+ MAINTAINERS: Update Peter Bergner's e-mail address
+
+2024-11-29 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-28 Alexandra Hájková <ahajkova@redhat.com>
+
+ Sync include/dwarf.h with gcc up to commit c4073a3d154
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2024-11-28 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Fix 32392 [2.44 Regression] gprofng fails to build on i686-linux-gnu
+ gprofng/ChangeLog
+ 2024-11-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/32392
+ * libcollector/libcol_util.c (__collector_util_init): Fix warning.
+
+2024-11-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * 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 <guinevere@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-11-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [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 <arnez@linux.ibm.com>
+
+ [gdb/tdep] s390: Add arch15 record/replay support
+ Enable recording of the new "arch15" instructions on z/Architecture
+ targets.
+
+2024-11-27 Liu Hao <lh_mouse@126.com>
+
+ PE LD: Merge .CRT .ctors and .dtors into .rdata
+ PR 32264
+
+2024-11-27 Nick Clifton <nickc@redhat.com>
+
+ Tidy up the default ELF linker script
+
+2024-11-27 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-26 Sandra Loosemore <sloosemore@baylibre.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2024-11-26 Alan Modra <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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:
+ ...
+ + <syscall name="mseal" groups="memory"/>
+ ...
+
+ Rerun make to propagate this change to the xml files.
+
+2024-11-26 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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<unrelocated_addr, call_site *>`.
+
+ Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <klaus.gerlicher@intel.com>
+
+2024-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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á <ahajkova@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-25 Nick Clifton <nickc@redhat.com>
+
+ Updated Bulgarian, Romanian and French translations for various sub-directories. New Georgian translation for the gold sub-directory.
+
+2024-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-11-25 Hui Li <lihui@loongson.cn>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-25 Hui Li <lihui@loongson.cn>
+
+ 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 <guinevere@redhat.com> (record-full)
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-25 Hui Li <lihui@loongson.cn>
+
+ 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 <guinevere@redhat.com> (record-full)
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-25 Hui Li <lihui@loongson.cn>
+
+ 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 <guinevere@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-24 Tom de Vries <tdevries@suse.de>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-22 Sam James <sam@gentoo.org>
+
+ 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 <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with -std=gnu23
+ Fix function pointer types accordingly.
+ Remove unused function pointers.
+
+ gprofng/ChangeLog
+ 2024-11-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Sam James <sam@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'ModuleNotFoundError'>: 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 <class 'ModuleNotFoundError'>: 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 <tom@tromey.com>
+
+ [1] https://docs.python.org/3/c-api/init.html#before-python-initialization
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-22 Sam James <sam@gentoo.org>
+
+ 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 <sam@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Tested by rebuilding on x86_64-linux.
+
+2024-11-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+2024-11-22 Martin Storsjö <martin@martin.st>
+
+ 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 <nelson.chu@sifive.com>
+ Kito Cheng <kito.cheng@sifive.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-21 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-11-21 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-11-21 Rohr, Stephan <stephan.rohr@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-20 Peter Bergner <bergner@linux.ibm.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <andre.simoesdiasvieira@arm.com>
+
+ 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 <mohamed.bouhaouel@intel.com>
+
+ gdb: add Mohamed Bouhaouel to gdb/MAINTAINERS
+
+2024-11-20 Nick Clifton <nickc@redhat.com>
+
+ Remove Debian from SECURITY.txt
+
+2024-11-20 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-20 Jiawei <jiawei@iscas.ac.cn>
+
+ 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 <charlie.keaney@embecosm.com>
+ Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
+ Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
+ Co-Authored by: Simon Cook <simon.cook@embecosm.com>
+ Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
+ Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-19 Charles Baylis <cbaylis@undo.io> (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 <tom@tromey.com>
+
+2024-11-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <nelson@rivosinc.com>
+
+ 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 <lin1.hu@intel.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-18 Matthieu Longo <matthieu.longo@arm.com>
+
+ aarch64: renaming of arm to AArch64
+
+ aarch64: remove annoying white spaces in bfd/elfnn-aarch64.c
+
+2024-11-18 Christina Schimpe <christina.schimpe@intel.com>
+
+ 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/<pid>/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 <felix.willgerodt@intel.com>
+
+2024-11-18 Christina Schimpe <christina.schimpe@intel.com>
+
+ 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/<pid>/status file to get the
+ untag mask.
+
+ Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
+ (AArch64) Tested-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2024-11-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: rename SPACE_{,E}VEX_MAP<N>
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <benjamin.drung@canonical.com>
+
+ ld: Support percent-encoded JSON in --package-metadata
+ Specifying the compiler flag `-Wl,--package-metadata=<JSON>` 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ s390: Add arch15 instruction names
+ opcodes/
+ * s390-opc.txt: Add arch15 instruction names.
+
+2024-11-18 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <sam@gentoo.org>
+
+ 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 <sam@gentoo.org>
+
+ 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 <sam@gentoo.org>
+
+ 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 <sam@gentoo.org>
+
+ 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 <sam@gentoo.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <abdul.b.ijaz@intel.com>
+
+ 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 = {<general_symbol_info> =
+ {m_name = 0x7fffcc77dc95 "__jit_debug_descriptor",
+ m_value = {ivalue = 84325936, block = 0x506b630,
+ bytes = 0x506b630 <error: Cannot access memory at address 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 <tom@tromey.com>
+
+2024-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-16 Tom Tromey <tom@tromey.com>
+
+ Use bool for solib::symbols_loaded
+ This changes solib::symbols_loaded to be of type 'bool'.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-11-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-15 Barnabás Pőcze <pobrn@protonmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497
+
+2024-11-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-15 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <main+24> (4)
+ 0x401030 <+16>: sub $0x1,%eax (5)
+ 0x401033 <+19>: jne 0x40103d <main+29> (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 <tdevries@suse.de>
+
+2024-11-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <guinevere@redhat.com> (record-full)
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <foo>:
+ 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 <guinevere@redhat.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ [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 <tdevries@suse.de>
+
+ [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 <guinevere@redhat.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2024-11-13 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <aburgess@redhat.com>
+
+2024-11-13 Andrew Burgess <aburgess@redhat.com>
+
+ 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<CORE_ADDR> 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 <bernd.edlinger@hotmail.de>
+
+2024-11-13 Mark Harmstone <mark@harmstone.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-12 Mark Wielaard <mark@klomp.org>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+ Acked-By: Tom de Vries <tdevries@suse.de>
+
+2024-11-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-11-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <keiths@redhat.com>
+
+2024-11-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-11-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <osabi>GNU/Linux</osabi> 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 <kevinb@redhat.com>
+
+2024-11-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/features: set osabi in all Linux related features/*.xml files
+ Some of the top level (i.e. those that contain the <target> 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 <osabi> element
+ included with the value "GNU/Linux".
+
+ This commits adds the <osabi> 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 <kevinb@redhat.com>
+
+2024-11-12 Shahab Vahedi <shahab.vahedi@amd.com>
+
+ gdb/MAINTAINERS: Update my email address
+
+2024-11-12 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <guinevere@redhat.com>
+ 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 <tom@tromey.com>
+
+2024-11-12 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+2024-11-12 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-11 Shahab Vahedi <shahab.vahedi@amd.com>
+
+ 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 <lancelot.six@amd.com>
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+ Approved-by: Tom Tromey <tom@tromey.com>
+ Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e
+
+2024-11-11 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-11-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-11 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-11-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <pedromsilva.git@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+2024-11-11 Lancelot SIX <lancelot.six@amd.com>
+
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ 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 <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-11 Xin Wang <wangxin03@loongson.cn>
+
+ ld, LoongArch: print error about linking without -fPIC or -fPIE flag in more detail
+
+2024-11-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-11-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-08 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <jan.kratochvil@redhat.com>
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+2024-11-08 Schimpe, Christina <christina.schimpe@intel.com>
+
+ 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 <luis.machado@arm.com>
+
+2024-11-08 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-08 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <viric@viric.name>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-11-08 Mark Wielaard <mark@klomp.org>
+
+ 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 <andre.simoesdiasvieira@arm.com>
+
+ 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 <andre.simoesdiasvieira@arm.com>
+
+ 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<c> instructions.
+
+ unpredictable.d:
+ Was missing an -march, added armv6 as that reproduced the behaviour being
+ tested.
+
+2024-11-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-07 Andre Simoes Dias Vieira <andre.simoesdiasvieira@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <stephan.rohr@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-11-07 Stephan Rohr <stephan.rohr@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-11-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-06 Peter Bergner <bergner@linux.ibm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-11-06 Klaus Gerlicher <klaus.gerlicher@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-04 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-11-04 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ gdb: cleanup includes in gdbtypes.h
+ Remove some includes reported as unused by clangd.
+
+ Change-Id: Ifc74f782d5aaafd1d719816821860352090c6667
+
+2024-11-04 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-11-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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<TAB>
+
+ 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<TAB>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <keiths@redhat.com>
+
+2024-11-04 Aditya Vidyadhar Kamath <aditya.kamath1@ibm.com>
+
+ 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 <ulrich.weigand@de.ibm.com>.
+
+2024-11-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-11-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * 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 <vladimir.mezentsev@oracle.com>
+
+ Fix 32303 ./configure --help: replace --enable-gprofng with --disable-gprofng
+ ChangeLog
+ 2024-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR 32303
+ * configure.ac: Replace --enable-gprofng with --disable-gprofng
+ * configure: Rebuild.
+
+2024-11-01 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <jpoimboe@kernel.org>
+
+ 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 <jpoimboe@kernel.org>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <func>:
+ 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 <func+0x6> 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 <andrew@andrewoates.com>
+
+ 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 <tom@tromey.com>
+
+2024-11-01 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-11-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-31 Domani Johannes <johannes.domani@lisec.com>
+
+ 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<bfd, gdb_bfd_ref_policy>::~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<bfd, gdb_bfd_ref_policy>::~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 <aburgess@redhat.com>
+
+2024-10-31 Nelson Chu <nelson@rivosinc.com>
+
+ gas/doc/riscv: Fixed misaligned instruction table
+ gas/
+ * doc/c-riscv.texi: Fixed misaligned instruction table.
+
+2024-10-31 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-30 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-10-30 Tom de Vries <tdevries@suse.de>
+
+ [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<const gdb_byte> 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 <ssbssa@yahoo.de>
+
+2024-10-30 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-29 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <aburgess@redhat.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
+
+2024-10-29 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-10-29 Nick Clifton <nickc@redhat.com>
+
+ Add a target to src-release.sh to crate a binutils release without Gold
+
+2024-10-29 Hakan Candar <hakancandar@protonmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <abdul.b.ijaz@intel.com>
+
+ 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 = <incomplete type>
+ (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><fd>: Abbrev Number: 12 (DW_TAG_string_type)
+ <fe> 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 <incomplete type> 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 <tom@tromey.com>
+
+2024-10-29 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Corrected to GNU style code
+
+2024-10-29 Jan Beulich <jbeulich@suse.com>
+
+ x86: use <xyz> 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 <jbeulich@suse.com>
+
+ 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 <kito.cheng@sifive.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-28 Hannes Domani <ssbssa@yahoo.de>
+
+ 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<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874
+ #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) 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 <tom@tromey.com>
+
+2024-10-28 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ gdbserver: fix formatting in gdbthread.h
+ Remove newlines after return type in declarations.
+
+ Change-Id: I00c6f35e063024cf6674d532454b67e6d0d98a19
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-28 Jim Lin <jim@andestech.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-27 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-26 Tom de Vries <tdevries@suse.de>
+
+ [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 = <unknown return 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 = {<text variable, no debug info>} 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [gdb] Don't create registry keys in destructor
+ Creating a registry key using emplace calls new:
+ ...
+ DATA *result = new DATA (std::forward<Args> (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 <tom@tromey.com>
+
+2024-10-26 Alan Modra <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-24 Tom Tromey <tom@tromey.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-10-24 Tom Tromey <tom@tromey.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-10-24 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-23 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-10-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-22 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-10-22 Michael Matz <matz@suse.de>
+
+ 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 <stephan.rohr@intel.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-10-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <pid-of-gdb>") 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 <pid-of-gdb>") != 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 <tom@tromey.com>
+
+ PR gdb/30695
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
+
+2024-10-22 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-21 Tom de Vries <tdevries@suse.de>
+
+ [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: <alt 0x93>
+ <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 <dwz>
+ 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 <tom@tromey.com>
+
+ 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á <ahajkova@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-10-21 Alexandra Hájková <ahajkova@redhat.com>
+
+ gdbreplay: Use getopt_long to parse command line arguments
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-10-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ 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 "#<gdb:type int>", 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 <kevinb@redhat.com>
+
+2024-10-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+ 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<klaus.gerlicher@intel.com>
+
+2024-10-20 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-19 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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<T>
+ + using A = gdb::array_view<T>
+ ....
+ 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 <tom@tromey.com>
+
+2024-10-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-10-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <guinevere@redhat.com>
+
+2024-10-18 MayShao-oc <MayShao-oc@zhaoxin.com>
+
+ 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 <MayShao-oc@zhaoxin.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-10-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <bernd.edlinger@hotmail.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
+
+2024-10-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-10-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix regression in man page installation
+ gprofng/ChangeLog
+ 2024-10-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * doc/Makefile.am: Use install-data-local to install gprofng examples.
+ * doc/Makefile.in: Rebuild.
+
+2024-10-17 Michael Matz <matz@suse.de>
+
+ 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 <matz@suse.de>
+
+ 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 <tdevries@suse.de>
+
+ [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 <cailulu@loongson.cn>
+
+ 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 <aditya.kamath1@ibm.com>
+
+ Add myself to gdb/MAINTAINERS
+
+2024-10-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-16 Andreas Schwab <schwab@suse.de>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <liwei.xu@intel.com>
+ Kong Lingling <lingling.kong@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <cvt8> 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-10-15 mengqinggang <mengqinggang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ LoongArch: Optimize the relaxation process
+ The symbol value is only calculated when the relocation can be relaxed.
+
+2024-10-15 Cui, Lili <lili.cui@intel.com>
+
+ 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 <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-14 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-10-14 Jan Beulich <jbeulich@suse.com>
+
+ 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 <fop> 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 <guinevere@redhat.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ PR 32110
+ * src/DwarfLib.cc: Handle DW_FORM_strx* forms.
+
+2024-10-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-12 Robert Guthrie <forkbombidable@gmail.com> (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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <haochen.jiang@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ 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 <vnni>, which prefers EVEX due to earlier introduction
+ for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-10 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: install examples to $(docdir)/gprofng
+ gprofng/ChangeLog
+ 2024-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * doc/Makefile.am: Install gprofng examples.
+ * doc/Makefile.in: Rebuild.
+
+2024-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr<char>
+ Convert target_desc::arch and target_desc::osabi from 'const char*' to
+ gdb::unique_xmalloc_ptr<char>. 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 <tom@tromey.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-10-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <krebbel@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+2024-10-10 Tom de Vries <tdevries@suse.de>
+
+ [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><fb>: Abbrev Number: 2 (DW_TAG_variable)
+ <fc> DW_AT_name : u1
+ <fd> 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 <guinevere@redhat.com>
+ Reviewed-By: Keith Seitz <keiths@redhat.com>
+ Tested-By: Guinevere Larsen <guinevere@redhat.com>
+
+2024-10-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-09 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-10-09 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-10-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <PENDING> 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 <tom@tromey.com>
+
+2024-10-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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><cb>: Abbrev Number: 2 (DW_TAG_namespace)
+ <cc> DW_AT_name : ns
+ <cf> DW_AT_declaration : 1
+ <2><d3>: Abbrev Number: 12 (DW_TAG_class_type)
+ <d4> DW_AT_name : A
+ <d6> DW_AT_declaration : 1
+ <3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type)
+ <db> DW_AT_declaration : 1
+ <1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type)
+ <e7> DW_AT_specification: <0xd6>
+ <2><ef>: Abbrev Number: 5 (DW_TAG_enumerator)
+ <f0> DW_AT_name : val1
+ <f4> 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 <tom@tromey.com>
+
+2024-10-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-10-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+2024-10-08 Alan Modra <amodra@gmail.com>
+
+ 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 "<corrupt>", 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 <amodra@gmail.com>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Fix implicit dependency of Zabha and Zacas
+ 1 Zabha depends on Zaamo:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/zabha.adoc>
+
+ 2 Zacas depends on Zaamo:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/zacas.adoc>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: add hardware counters for Neoverse-N1 and Ampere-1 processors
+ gprofng/ChangeLog
+ 2024-10-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ * 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-07 Andreas Schwab <schwab@linux-m68k.org>
+
+ 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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-06 Gaius Mulley <gaiusmod2@gmail.com>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-10-06 Gaius Mulley <gaiusmod2@gmail.com>
+
+ gdb/MAINTAINERS: update my email address
+ Sync the maintainers file with my new email address.
+
+2024-10-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Rerun spellcheck.sh
+ Fix the following common misspellings:
+ ...
+ completetion -> completion
+ inital -> initial
+ ...
+
+2024-10-06 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
+
+2024-10-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-05 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-04 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 "<null>" 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-03 oltolm <oleg.tolmatcev@gmail.com>
+
+ 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 <izbyshev@ispras.ru>
+
+ 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 <amodra@gmail.com>
+
+ peicode.h formatting
+ Fix some overlong line, comment block style, whitespace issues.
+
+2024-10-03 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 "<null>" 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 "<null>" 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 "<null>" 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-02 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ PR 32193
+ PR 32199
+ PR 32201
+ * gp-display-html/gp-display-html.in: Implement all
+ the above changes.
+
+2024-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-10-02 Martin Storsjö <martin@martin.st>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-01 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-10-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-10-01 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <eliz@gnu.org>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-09-30 Nick Clifton <nickc@redhat.com>
+
+ Improve the placement of orphan note sections.
+ PR 32219
+
+2024-09-30 Andrew Burgess <aburgess@redhat.com>
+
+ 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<TAB>
+
+ 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 <TAB>, 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 <tom@tromey.com>
+
+2024-09-30 Andrew Burgess <aburgess@redhat.com>
+
+ 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<TAB>
+
+ 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<TAB>
+
+ 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<TAB>
+
+ 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 <tom@tromey.com>
+
+2024-09-30 Gerlicher, Klaus <klaus.gerlicher@intel.com>
+
+ gdb/MAINTAINERS: add myself to maintainers
+
+2024-09-30 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb: Remove myself as x86 maintainer and update my email
+
+2024-09-30 Gerlicher, Klaus <klaus.gerlicher@intel.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-09-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-28 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+
+2024-09-27 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ Enable -z separate-code, -z common and -z text for more targets
+ Fix a mis-placed "fi".
+
+2024-09-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-27 Tom Tromey <tom@tromey.com>
+
+ Add 'const' to symmisc.c
+ I noticed a few spots in symmisc.c that could use a 'const'.
+
+2024-09-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Fix 32207 [gprofng collect app] Error in parsing the -O option
+ gprofng/ChangeLog
+ 2024-09-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR 32207
+ * src/collctrl.cc (preprocess_names): Fix the size in strndup.
+
+2024-09-26 Nick Clifton <nickc@redhat.com>
+
+ Updated Brazilian Portuguese translation for the gprof directory.
+
+2024-09-26 Andreas Schwab <schwab@suse.de>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-26 Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-25 Alan Modra <amodra@gmail.com>
+
+ 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 <sam@gentoo.org>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'SystemExit'>: 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 <blarsen@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR python/31946
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
+
+2024-09-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: format some Python files
+ Format with black.
+
+ Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2
+
+2024-09-25 Schimpe, Christina <christina.schimpe@intel.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-09-25 Schimpe, Christina <christina.schimpe@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-09-25 Frank Ch. Eigler <fche@redhat.com>
+
+ 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 <jiawei@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-24 Tom Tromey <tromey@adacore.com>
+
+ 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 <thiago.bauermann@linaro.org>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-09-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ gdb/elfread.c: remove unused includes
+ Remove some includes reported as unused by clangd.
+
+ Change-Id: If7c4729975bd90b9cc2c22bcf84d333bd0002a52
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Frank Ch. Eigler <fche@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ btrace: Add support for IRET events.
+ This is similar to the previous events that we added.
+
+ Approved-By: Markus Metzger <markus.t.metzger@intel.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Markus Metzger <markus.t.metzger@intel.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ btrace: Add printing support for cfe and evd packets.
+ Approved-By: Markus Metzger <markus.t.metzger@intel.com>
+
+2024-09-24 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Eliminate catch(...) in pipe_command
+ Remove duplicate code in pipe_command using SCOPE_EXIT.
+
+ Tested on aarch64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Eliminate catch(...) in target_wait
+ Remove duplicate code in target_wait using SCOPE_EXIT.
+
+ Tested on aarch64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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<EFP>::value
+ && std::is_nothrow_constructible<EF, EFP>::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 <tom@tromey.com>
+
+ [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <bernd.edlinger@hotmail.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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<typename T>
+ [[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<auto val>
+ [[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<nullptr> (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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
+ <be> DW_AT_language : 2 (non-ANSI C)
+ <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <c0> DW_AT_low_pc : 0x4004a7
+ <c8> DW_AT_high_pc : 0x4004b2
+ <d0> DW_AT_specification: <0xd5>
+ <1><d4>: 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 <tom@tromey.com>
+
+2024-09-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 "<artificial>"
+ (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 <same-as-above>
+ 20
+ ...
+ so ~1% of the CUs is expanded.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/32182
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182
+
+2024-09-24 Rohr, Stephan <stephan.rohr@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-24 Mark Harmstone <mark@harmstone.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-23 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-23 Tom Tromey <tromey@adacore.com>
+
+ 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 <ahajkova@redhat.com>
+
+2024-09-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-23 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ ld/PE: enable secrel testcases also for 64-bit Cygwin
+ Plus the others that are grouped there.
+
+2024-09-23 Jan Beulich <jbeulich@suse.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+ PR testsuite/32129
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129
+
+2024-09-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <foo>^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 <tdevries@suse.de>
+
+ [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
+ <LOTS-OF-SPACES>-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 <cpu> (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 <LOTS-OF-SPACES> 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-22 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Turn PLT32 to PC32 only for PC-relative relocations
+ commit 292676c15a615b5a95bede9ee91004d3f7ee7dfd
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ 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 <hjl.tools@gmail.com>
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR testsuite/32177
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177
+
+2024-09-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-09-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-20 Cui, Lili <lili.cui@intel.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-20 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-20 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-20 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-20 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-20 Guinevere Larsen <guinevere@redhat.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-09-20 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-20 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <guinevere@redhat.com>
+
+ gdb/MAINTAINERS: update my email address
+ Sync the maintainers file with my new email address
+
+2024-09-19 Nick Clifton <nickc@redhat.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>.
+
+ 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<Histable*>*.
+ * src/Experiment.cc (update_ts_in_maps): Change variable type.
+ * src/Experiment.h: Change field type to Vector<Histable*>*.
+
+2024-09-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-18 Xin Wang <yw987194828@gmail.com>
+
+ LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata
+ LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata.
+
+2024-09-18 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-17 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-17 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-17 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-16 Tom Tromey <tromey@adacore.com>
+
+ Fix typo in py-arch.exp
+ I found a typo in a test name in py-arch.exp.
+
+2024-09-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-15 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ 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 <macro@orcam.me.uk>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-14 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
+
+2024-09-14 Tom de Vries <tdevries@suse.de>
+
+ [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><dd>: Abbrev Number: 3 (DW_TAG_class_type)
+ <de> DW_AT_name : A
+ <e0> DW_AT_byte_size : 1
+ <2><e3>: 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 <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
+
+2024-09-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-13 oltolm <oleg.tolmatcev@gmail.com>
+
+ gdb dap: introduce stopOnEntry option
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-09-13 Tom Tromey <tom@tromey.com>
+
+ 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 <kevinb@redhat.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-09-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-09-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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<solib>`, 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 <keiths@redhat.com>
+
+2024-09-13 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport/intrusive-list: add owning_intrusive_list
+ It occured to me that `intrusive_list<solib>`, 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<solib>` type
+ does not convey it. If a function is building an
+ `intrusive_list<solib>` 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<T>`
+ (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<Foo> ("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 <pedro@palves.net>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-09-13 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+
+2024-09-13 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+
+2024-09-13 Stephan Rohr <stephan.rohr@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-12 Sam James <sam@gentoo.org>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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<long unsigned int>; 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<unsigned long, std::allocator<unsigned long> >;
+ }
+
+ The crash occurs here:
+
+ #3 0x00007ffff5e334c3 in __GI_abort () at abort.c:79
+ #4 0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320
+ #5 0x0000555561119a16 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::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 <tdevries@suse.de>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-09-12 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <dost@de.ibm.com>
+ Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
+
+2024-09-12 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>.
+
+ 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 <tdevries@suse.de>
+
+ [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 <christophe.lyon@linaro.org>
+
+ 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 <me@kylehuey.com>
+
+ gdb: Support DW_OP_constx (the standardized version of DW_OP_GNU_const_index).
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-09-11 Tom Tromey <tromey@adacore.com>
+
+ Fix typo in Python TUI window text
+ I noticed a typo in the Python TUI window documentation.
+
+2024-09-11 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <mark@harmstone.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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<mem_range>&&, 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<lancelot.six@amd.com>
+
+2024-09-10 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ Boolify ada_identical_enum_types_p
+ This changes ada_identical_enum_types_p to return bool rather than
+ int.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-09 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-09 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Align opcodes to lower-case
+ opcodes/
+ * s390-opc.txt (rdp): Change opcode to lower-case.
+
+2024-09-09 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, 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<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
+ #4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
+ #5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
+ #6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
+ #7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, 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 <tdevries@suse.de>
+
+ [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 <class 'ImportError'>: 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 <kevinb@redhat.com>
+
+ PR testsuite/31576
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31576
+
+2024-09-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <PENDING> 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 <PENDING> 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 <eliz@gnu.org>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <ahajkova@redhat.com>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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/<TAB><TAB>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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<TAB>
+ (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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-09-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <yw987194828@gmail.com>
+
+ 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 <yw987194828@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Rename gp-* man pages to gprofng-* man pages
+ gprofng/ChangeLog
+ 2024-09-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ * 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 <tromey@adacore.com>
+
+ 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 <ahajkova@redhat.com>
+
+2024-09-06 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-09-06 Tom Tromey <tromey@adacore.com>
+
+ 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 <bernd.edlinger@hotmail.de>
+
+ 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 <tdevries@suse.de>
+
+2024-09-06 Shahab Vahedi <shahab.vahedi@amd.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-05 Mark Harmstone <mark@harmstone.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <thiago.bauermann@linaro.org>
+
+ 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 <aburgess@redhat.com>
+
+2024-09-05 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-04 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Fix 32097 Warnings when building gprofng with Clang
+ gprofng/ChangeLog
+ 2024-09-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-09-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 = <unknown return 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 <tdevries@suse.de>
+
+2024-09-04 Christophe Lyon <christophe.lyon@linaro.org>
+
+ Revert "contrib: Add autoregen.py"
+ This reverts commit e1ad04ad6cd43fb5a876d787da5ac29f72a9c7e5.
+
+2024-09-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-09-04 Christophe Lyon <christophe.lyon@linaro.org>
+
+ 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 <christophe.lyon@linaro.org>
+
+ 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 <christophe.lyon@linaro.org>
+
+ contrib/
+ * autoregen.py: New script.
+
+2024-09-04 Shahab Vahedi <list@vahedi.org>
+
+ MAINTAINERS: Update my email address
+
+2024-09-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <bar>:
+ 4ec: b580 push {r7, lr}
+ 4ee: af00 add r7, sp, #0
+
+ 000004f0 <bar_label>:
+ 4f0: 2001 movs r0, #1
+ 4f2: f7ff fff1 bl 4d8 <foo>
+
+ 000004f6 <bar_label_2>:
+ 4f6: 2002 movs r0, #2
+ 4f8: f7ff ffee bl 4d8 <foo>
+ ...
+
+ 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 <mark@harmstone.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <simon.marchi@efficios.com>
+
+2024-09-03 Mary Bennett <mary.bennett682@gmail.com>
+
+ 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 <mary.bennett682@gmail.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-02 Haochen Jiang <haochen.jiang@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-09-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-31 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-08-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-30 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-08-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-08-30 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-30 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nicolas@ortegas.org>
+
+ gdb/doc: fix typo in 'watch' command
+ * gdb/breakpoint.c (watch_option_defs): Fix typo.
+
+2024-08-30 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+ Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6
+
+2024-08-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ gdb: remove unused includes in linespec.c
+ Remove some includes reported as unused by clangd.
+
+ Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df
+
+2024-08-29 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-28 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-28 Jiaying Song <jiaying.song.cn@windriver.com>
+
+ 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 <amodra@gmail.com>
+
+2024-08-28 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-08-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-08-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-08-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-08-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-08-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-27 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
+
+2024-08-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-27 Jiawei <jiawei@iscas.ac.cn>
+
+ 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 <charlie.keaney@embecosm.com>
+ Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
+ Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
+ Co-Authored by: Simon Cook <simon.cook@embecosm.com>
+ Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
+ Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Disable gprofng build for *musl*
+ I disable gprofng until gprofng is ported to musl.
+
+ gprofng/ChangeLog
+ 2024-08-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ PR gprofng/30779
+ PR gprofng/29593
+ PR gprofng/29477
+ * configure.ac: Disable gprofng build for *musl*.
+ * configure: Rebuild.
+
+2024-08-26 Tom Tromey <tromey@adacore.com>
+
+ 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 <mark@harmstone.com>
+
+ 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 <wqferr@gmail.com>
+
+ 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 <blarsen@redhat.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-26 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <markus.t.metzger@intel.com> (btrace)
+ Approved-By: Guinevere Larsen <blarsen@redhat.com>
+
+2024-08-26 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <felix.willgerodt@intel.com>
+
+ 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 <felix.willgerodt@intel.com>
+ 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 <simon.marchi@efficios.com>
+
+2024-08-26 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-25 Dmitry Neverov <dmitry.neverov@jetbrains.com>
+
+ 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 <tom@tromey.com>
+
+2024-08-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-23 Aaron Merey <amerey@redhat.com>
+ Tom de Vries <tdevries@suse.de>
+
+ 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 <tom@tromey.com>
+
+2024-08-23 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-22 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+ 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 <tdevries@suse.de>
+
+ [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><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
+ <be> DW_AT_language : 2 (non-ANSI C)
+ <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <c0> DW_AT_low_pc : 0x4004a7
+ <c8> DW_AT_high_pc : 0x4004b2
+ <d0> DW_AT_specification: <0xe8>
+ <1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
+ <d5> DW_AT_name : main
+ <1><da>: Abbrev Number: 0
+ Compilation Unit @ offset 0xdb:
+ Length: 0xf (32-bit)
+ Version: 4
+ Abbrev Offset: 0x86
+ Pointer Size: 8
+ <0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
+ <e7> DW_AT_language : 2 (non-ANSI C)
+ <1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <e9> DW_AT_specification: <0xd4>
+ <1><ed>: 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 <tom@tromey.com>
+ Reported-By: Andreas Schwab <schwab@linux-m68k.org>
+
+2024-08-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-08-22 Sam James <sam@gentoo.org>
+
+ gprofng: testsuite: fix 'wrapper' typo
+ gprofng/ChangeLog
+ * testsuite/config/default.exp: Fix 'wrapper' typo.
+
+2024-08-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-21 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-08-21 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-08-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-20 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-08-20 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-08-20 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-20 Tom de Vries <tdevries@suse.de>
+
+ [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 "<string>", line 1, in <module>
+ 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 <thiago.bauermann@linaro.org>
+
+ PR testsuite/31913
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913
+
+2024-08-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: add hardware counters for Appliedmicro processor
+ gprofng/ChangeLog
+ 2024-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ * 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <schwab@linux-m68k.org>
+
+ 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 <tromey@adacore.com>
+
+ 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 <nickc@redhat.com>
+
+ Remove Walter Lee as maintainer for Tile Gx and Tile Pro
+
+2024-08-19 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-19 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-08-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-18 Tom de Vries <tdevries@suse.de>
+
+ [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: <gdb.Progspace object at 0xabf4f850>^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: <gdb.Progspace object at 0xabaf03a0>^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: <gdb.Progspace object at 0xabaf03a0>^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 <kevinb@redhat.com>
+
+ PR gdb/31440
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
+
+2024-08-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-17 Nick Clifton <nickc@redhat.com>
+
+ Update release readme after making 2.43.1 release
+
+2024-08-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-16 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-08-16 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+ Tested on arm-linux.
+
+2024-08-16 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+ gdb: Fix gdb.python/py-record-btrace.exp test
+ My previous patch
+
+ commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
+ Author: Felix Willgerodt <felix.willgerodt@intel.com>
+ 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 <main+12>: movl $0x0,-0x4(%rbp)
+ 2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
+ 3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
+ 4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
+ 5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
+ 6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
+ 7 0x0000555555555176 <main+31>: mov %eax,%edi
+ ...
+
+ After clear:
+
+ (gdb) record instruction-history 1,100
+ 1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
+ 2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
+ 3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
+ 4 0x0000555555555176 <main+31>: 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 <tdevries@suse.de>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
+
+2024-08-16 Jan Beulich <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-15 H.J. Lu <hjl.tools@gmail.com>
+
+ Revert "Arm: correct macro use in gas testsuite"
+ This reverts commit cfa18744d435b55bbbbc5ef1ae1df67e84aa1777.
+
+ commit 6ae8a30d44f016cafb46a75843b5109316eb1996
+ Author: Jan Beulich <jbeulich@suse.com>
+ 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 <hjl.tools@gmail.com>
+
+ Revert "bfin: correct macro use in gas testsuite"
+ This reverts commit a1b7023447d19d70bc36d71b7627f457dbfae5ce.
+
+ commit 6ae8a30d44f016cafb46a75843b5109316eb1996
+ Author: Jan Beulich <jbeulich@suse.com>
+ 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 <hjl.tools@gmail.com>
+
+ Revert "ia64: correct macro use in gas testsuite"
+ This reverts commit 2231ac9b9e88191178001d0ae5845e292acb2a56.
+
+ commit 6ae8a30d44f016cafb46a75843b5109316eb1996
+ Author: Jan Beulich <jbeulich@suse.com>
+ 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 <hjl.tools@gmail.com>
+
+ Revert "MIPS: correct macro use in gas and ld testsuites"
+ This reverts commit c0e9aca554e33e900efbd6425c1830f0a20012f5.
+
+ commit 6ae8a30d44f016cafb46a75843b5109316eb1996
+ Author: Jan Beulich <jbeulich@suse.com>
+ 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 <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-08-15 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix typo in src/collctrl.cc
+ gprofng/ChangeLog
+ 2024-08-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/collctrl.cc (read_cpuinfo): Fix typo.
+
+2024-08-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-14 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ btrace, linux: Enable ptwrite packets.
+ Enable ptwrite in the PT config, if it is supported by the kernel.
+
+ Approved-By: Markus Metzger <markus.t.metzger@intel.com>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Markus Metzger <markus.t.metzger@intel.com>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <markus.t.metzger@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-08-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-13 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <klaus.gerlicher@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-13 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ * 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 <dimitar@dinux.eu>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-08-12 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ Revert "gas: have scrubber retain more whitespace"
+ This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996.
+
+ This fixes PR gas/32073.
+
+2024-08-12 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ pre-commit: autoupdate
+ Run `pre-commit autoupdate`.
+
+ Change-Id: I6623a61b7d1e827360854e825d84c5608a68e07b
+
+2024-08-12 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ [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 <tdevries@suse.de>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <lancelot.six@amd.com>
+ Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ gdb: pass inferior to target_current_description
+ Make the current inferior reference bubble up one level.
+
+ Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <eliz@gnu.org>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <kevinb@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <kevinb@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <kevinb@redhat.com>
+
+2024-08-12 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-10 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-09 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tdevries@suse.de>
+
+2024-08-09 Stephan Rohr <stephan.rohr@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-09 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-08 Richard Henderson <richard.henderson@linaro.org>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'KeyboardInterrupt'>: ^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 <aburgess@redhat.com>
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html
+
+2024-08-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025
+
+2024-08-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-07 Jan Beulich <jbeulich@suse.com>
+
+ score: drop TC_ALPHA code
+ I can't see how that could ever have come into play.
+
+2024-08-07 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ gas/NEWS: Moved RISC-V Zimop/Zcmop changes into 2.43 section due to backport.
+
+2024-08-07 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-06 Hannes Domani <ssbssa@yahoo.de>
+
+ 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' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
+ (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 <ahajkova@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <hau.hsu@sifive.com>
+
+ 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 <mary.bennett682@gmail.com>
+
+ 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 <mary.bennett682@gmail.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Add support for Zcmop extension
+ This implements the Zcmop (Compressed Zimop) extension, as of version 1.0.
+
+ View detailed information in:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Add support for Zimop extension
+ This implements the Zimop (May-Be-Operations) extension, as of version 1.0.
+
+ View detailed information in:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-05 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-08-05 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-04 Nick Clifton <nickc@redhat.com>
+
+ Update release-README after completing the 2.43 release.
+
+2024-08-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-03 H.J. Lu <hjl.tools@gmail.com>
+
+ 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':
+ <artificial>:(.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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-02 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-02 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <keiths@redhat.com>
+
+2024-08-02 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tdevries@suse.de>
+ Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-08-02 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-02 Nick Clifton <nickc@redhat.com>
+
+ Updated Bulgarian translation for the binutils/ directory
+
+2024-08-02 Aapo Rantalainen <aapo.rantalainen@gmail.com>
+
+ Fix typo in --help output of the strings program.
+ PR 31940
+
+2024-08-02 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-02 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-02 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-08-02 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-08-01 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <lihui@loongson.cn>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gustavo.romero@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-08-01 Tom de Vries <tdevries@suse.de>
+
+ [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 <class 'TypeError'>: \
+ 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 <class 'TypeError'>: \
+ '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 <cailulu@loongson.cn>
+
+ 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 <mark@harmstone.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-31 Nick Alcock <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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<print (1)>" and
+ "gdb-command<print (2)>.
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-30 Tom de Vries <tdevries@suse.de>
+
+ [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 <simon.marchi@efficios.com>
+
+ 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=<optimized out>) 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<char const*, void> (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158
+ #4 0x0000555564b481fa in macro_bcache<char const*> (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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ PR 32018
+ * libcollector/hwprofile.c (open_experiment): Use __collector_strchr.
+
+2024-07-30 Tom de Vries <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+2024-07-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove use of alloca in new_macro_definition
+ Replace alloca with std::vector.
+
+ Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2024-07-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use std::string vector for macro definition
+ Use std::vector<std::string> 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 <tdevries@suse.de>
+
+2024-07-30 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-07-30 Lulu Cai <cailulu@loongson.cn>
+
+ gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.43
+
+2024-07-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-29 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <class 'AttributeError'>: module 'gdb' has no attribute
+ '_handle_missing_debuginfo'
+
+ Tested by using make check-all-boards.
+
+ Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-07-29 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <nickc@redhat.com>
+
+ Updated translations for the bfd, binutils, gas, ld and opcodes directories
+
+2024-07-29 Alan Modra <amodra@gmail.com>
+
+ 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 <pali@kernel.org>
+
+ PR 31728 testcases
+
+2024-07-29 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-28 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-07-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-26 YunQiang Su <yunqiang.su@cipunited.com>
+
+ 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 <macro@redhat.com>
+
+2024-07-26 Nick Clifton <nickc@redhat.com>
+
+ Fix "Untranslated plural in readelf.c"
+ PR 32002
+
+2024-07-26 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-07-26 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/amdgpu: remove unused includes
+ Remove two includes reported as unused by clangd.
+
+ Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e
+
+2024-07-25 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ Add /usr/lib32 to the native search paths for FreeBSD systems.
+ PR 31395
+
+2024-07-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-24 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-07-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <keiths@redhat.com>
+
+ PR exp/31816
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816
+
+2024-07-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <keiths@redhat.com>
+
+2024-07-24 Nick Clifton <nickc@redhat.com>
+
+ BFD: Add .relro_padding to list of special sections
+
+2024-07-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-07-24 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-23 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-07-23 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-07-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-07-23 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+2024-07-23 Tom de Vries <tdevries@suse.de>
+
+ [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]+|<optimized out>)"})?\]},.*[^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 <luis.machado@arm.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-07-23 Pali Roh?r <pali@kernel.org>
+
+ Improve objdump's display of PE header information.
+ PR 31953
+
+2024-07-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/unittests/intrusive-list: remove unnecessary local objects
+ These objects are not used.
+
+ Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f
+
+2024-07-22 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ gdb/testsuite: fix minor typo in a comment
+ Fix 'text' to 'test' in a test comment.
+
+2024-07-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-21 Alan Modra <amodra@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+ PR testsuite/31983
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983
+
+2024-07-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-20 Mark Harmstone <mark@harmstone.com>
+
+ 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 <mark@harmstone.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <PENDING> 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 <PENDING> 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 <nickc@redhat.com>
+
+ Update after creating 2.43 branch
+
+ Change version to 2.43.50
+
+ Add markers for 2.43 branch/release
+
+2024-07-20 Alan Modra <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ PR31999 strip [.gnu.build.attributes]: failed
+ PR 31999
+ * objcopy.c (merge_gnu_build_notes): Always set *new_size.
+
+2024-07-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <aburgess@redhat.com>
+
+2024-07-19 Maciej W. Rozycki <macro@redhat.com>
+
+ 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 <yunqiang.su@cipunited.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros
+ As from commit ab90248154ba ("Add structures to describe MIPS
+ operands"), <https://sourceware.org/ml/binutils/2013-07/msg00135.html>,
+ 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"), <https://sourceware.org/ml/binutils/2013-07/msg00136.html>,
+ 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"),
+ <https://sourceware.org/ml/binutils/2013-07/msg00139.html>, 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <zhangxianting@uniontech.com>
+
+ bfin: free the allocated memory
+
+2024-07-19 Maciej W. Rozycki <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
+ 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
+ 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-18 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-07-18 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <lili.cui@intel.com>
+
+ X86: Update gas/NEWS for Intel APX.
+ gas/ChangeLog:
+
+ * NEWS: Added "APX_F is fully supportted" to gas/NEWS.
+
+2024-07-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+2024-07-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <lancelot.six@amd.com>
+
+2024-07-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix indentation in remote.c
+ Change-Id: If344acdf703fdd3892f73f75fc891d5473808b79
+
+2024-07-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-15 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ gdb: pass program space to objfile::make
+ Make the current program space reference bubble up one level.
+
+ Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: pass program space to objfile::objfile
+ Make the current program space reference bubble up one level.
+
+ Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: pass program space to objfiles_changed
+ Make the current program space reference bubble up one level.
+
+ Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2024-07-15 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <ssbssa@yahoo.de>
+
+ 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 <blarsen@redhat.com>
+
+2024-07-15 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <szabolcs.nagy@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ Synchronize config.[sub|guess] with the latest versions from the config project.
+
+2024-07-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-14 John David Anglin <danglin@gcc.gnu.org>
+
+ 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 <danglin@gcc.gnu.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-13 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-12 Sam James <sam@gentoo.org>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <agordeev@linux.ibm.com>
+ Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>
+ Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2024-07-12 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <syq@gcc.gnu.org>
+
+ 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 <syq@gcc.gnu.org>
+
+ 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 <Matthieu.Longo@arm.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: add release notes for 2.43
+ ChangeLog
+ 2024-07-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ * binutils/NEWS (gprofng): Add release notes for 2.43
+
+2024-07-12 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-11 Nick Clifton <nickc@redhat.com>
+
+ base64: Add support for targets with byte size > octet size.
+ PR 31964
+
+2024-07-11 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <legouguec@adacore.com>
+
+ 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 <tom@tromey.com>
+
+2024-07-11 Cui, Lili <lili.cui@intel.com>
+
+ X86: Update gas/NEWS for Intel APX.
+ gas/ChangeLog:
+
+ * NEWS: Update gas/NEWS for Intel APX.
+
+2024-07-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ 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:
+ <https://github.com/riscv/riscv-profiles/releases/tag/v1.0>
+
+ [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 <amodra@gmail.com>
+
+ 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 <hejinyang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-11 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <chenyixuan@iscas.ac.cn>
+
+ RISC-V:[gprofng] Minimal support gprofng for riscv.
+ ChangeLog: Add target riscv to --enable-gprofng.
+
+ 2024-07-04 Yixuan Chen <chenyixuan@iscas.ac.cn>
+
+ * configure: Add riscv.
+ * configure.ac: Add riscv.
+
+ gprofng/ChangeLog: Minimal support gprofng for riscv.
+
+ 2024-07-04 Yixuan Chen <chenyixuan@iscas.ac.cn>
+
+ * 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 <nickc@redhat.com>
+
+ Add support for a .base64 pseudo-op to gas
+ PR 31964
+
+2024-07-10 Clément Chigot <chigot@adacore.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-09 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: add hardware counters for Intel Ice Lake processor
+ gprofng/ChangeLog
+ 2024-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
+
+ * 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-08 srinath <srinath.parvathaneni@arm.com>
+
+ 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 <Zd> operand is optional, the index part is
+ dropped in disassembly in both the cases of "no index" or "zero index".
+
+ As per spec: PMOV <Zd>{[<imm>]}, <Pn>.D
+ PMOV <Pn>.D, <Zd>{[<imm>]}
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-06 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-05 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <lingling.kong@intel.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <xry111@xry111.site>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-04 Sun Sunny <sunny.sun@corelabtech.com>
+
+ 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 <lifang_xia@linux.alibaba.com>
+
+ 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) <case BFD_RELOC_RISCV_PCREL_HI20>: Likewise.
+ (md_apply_fix) <case BFD_RELOC_RISCV_PCREL_LO12_I>: Likewise.
+
+2024-07-04 Andre Vieira <andre.simoesdiasvieira@arm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ gas: Don't skip SFrame FDE if .cfi_register specifies SP register
+ Neither ".cfi_offset SP, <offset>", ".cfi_register SP, <regno>", nor
+ ".cfi_val_offset SP, <offset>" 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 = <current_base_reg> + <current_cfa_offset>
+
+ 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 - <initial_cfa_offset>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <name> (0x<hexval>)
+
+ Whenever possible print meaningful warning messages, when the assembler
+ skips generation of SFrame FDE:
+
+ - skipping SFrame FDE; non-SP/FP register <regno> in .cfi_def_cfa
+ - skipping SFrame FDE; non-SP/FP register <regno> in
+ .cfi_def_cfa_register
+ - skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register
+ in effect
+ - skipping SFrame FDE; {FP|RA} register <regno> in .cfi_val_offset
+ - skipping SFrame FDE; {SP|FP|RA} register <regno> in in .cfi_register
+ - skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE
+ state
+ - skipping SFrame FDE; non-default RA register <regno>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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<hexval>
+
+ New:
+ Warning: skipping SFrame FDE; CFI insn <name> (0x<hexval>)
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ x86: Remove unused SFrame CFI RA register variable
+ gas/
+ * config/tc-i386.c (x86_sframe_cfa_ra_reg): Remove.
+
+2024-07-04 Cui, Lili <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-03 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <lingling.kong@intel.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <Aditya.Kamath1@ibm.com>
+
+ 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 <lingling.kong@intel.com>
+
+ 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 <hjl.tools@gmail.com>
+
+2024-07-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-07-01 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Move foo before delete in dl5.cc
+ * testsuite/ld-elf/dl5.cc (main): Move foo before delete.
+
+2024-07-01 Claudiu Zissulescu <claziss@gmail.com>
+
+ MAINTAINERS: Update my e-mail address
+
+2024-07-01 Xi Ruoyao <xry111@xry111.site>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-30 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <brainbomb@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-29 Sam James <sam@gentoo.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-28 Claudio Bantaloukas <claudio.bantaloukas@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <jiawei@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-27 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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<char>. Make
+ use of these overloads throughout GDB and gdbserver.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-06-27 Andrew Burgess <aburgess@redhat.com>
+
+ 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<char>, then make use of these
+ overloads throughout GDB and gdbserver.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-06-27 Pali Roh?r <pali@kernel.org>
+
+ Improve comments describing the Import Directory Table
+ PR 31728
+
+2024-06-27 Nick Clifton <nickc@redhat.com>
+
+ Fix new libdep test so that if the plugin cannot be located the test fails gracefully.
+
+2024-06-27 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-27 Alan Modra <amodra@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ Revert: 35fd2ddeb1d90f1750401cfb6d01fe055656b88d
+ PR 20814
+
+2024-06-26 Tom de Vries <tdevries@suse.de>
+
+ [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 <blarsen@redhat.com>
+
+ Tested on x86_64-linux.
+
+2024-06-26 Tom de Vries <tdevries@suse.de>
+
+ [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<char *>(_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 <blarsen@redhat.com>
+
+2024-06-26 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-26 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ 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 <flaviocruz@gmail.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-06-25 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <nickc@redhat.com>
+
+ Updated Russian translation for the bfd/ sub-directory
+
+2024-06-25 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <Zt1>
+ ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of <Pg>
+ ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of <Xm>
+ ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of <imm> (low value)
+ ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of <imm> (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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 [<imm>] 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 <srinath.parvathaneni@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <christina.schimpe@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-25 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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')
+ <BODY1>
+ else if (*p == '(')
+ <BODY2>
+ else
+ <BODY3>
+ ...
+ BODY3 is dead code.
+
+ Remove it, and get rid of unnecessary indentation by using an early-exit:
+ ....
+ if (*p == ' ' || *p == '\0')
+ {
+ <BODY1>
+ return;
+ }
+
+ gdb_assert (*p == '(');
+ <BODY2>
+ ...
+
+ Tested on aarch64-linux.
+
+ Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-06-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-24 Hui Li <lihui@loongson.cn>
+
+ 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 <stdio.h>
+ 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 <lihui@loongson.cn>
+
+ 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 <stdio.h>
+ 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 <ssbssa@yahoo.de>
+
+ 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 <class 'gdb.error'>: 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 <tom@tromey.com>
+
+2024-06-24 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ aarch64: Move struct definition towards its usage
+
+2024-06-24 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <me@harmenstoppels.nl>
+
+ 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 <nickc@redhat.com>
+
+ 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 <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 <martin@lispworks.com>
+
+ 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<std::string, std::vector<ada_index_var_operation *>>
+ ~~~~~^
+ 1 error generated.
+
+ This change fixes it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <pedro@palves.net>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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, <GEN0> 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 <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+ 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 <felix.willgerodt@intel.com>
+
+2024-06-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-23 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ aarch64: Enable +cssc for armv8.9-a
+ FEAT_CSSC is mandatory in the architecture from Armv8.9.
+
+2024-06-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-22 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <blarsen@redhat.com>
+
+2024-06-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <blarsen@redhat.com>
+
+2024-06-21 Pedro Alves <pedro@palves.net>
+
+ [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 <tdevries@suse.de>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <wangfeng@eswincomputing.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-20 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-06-20 Tom de Vries <tdevries@suse.de>
+
+ [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 <main at py-format-address.c:30>^M
+ (gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \
+ result should have an offset
+ ...
+
+ What is expected here is:
+ ...
+ Got: 0x103dd <main+1 at py-format-address.c:30>^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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <xry111@xry111.site>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-20 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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<typename... Args>
+ 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<unsigned int, long long>(_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<int>(_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<int, int, int>(_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 <tdevries@suse.de>
+
+ [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><a4>: Abbrev Number: 2 (DW_TAG_base_type)
+ <a5> DW_AT_byte_size : 16
+ <a6> DW_AT_encoding : 3 (complex float)
+ <a7> 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 <nick.alcock@oracle.com>
+
+ 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 <lancelot.six@amd.com>
+
+ 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 <tdevries@suse.de>
+ Change-Id: I5bec241144f13500ef78daea30f00d01e373692d
+
+2024-06-19 Cui, Lili <lili.cui@intel.com>
+
+ 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 <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x
+ On s390x-linux, I run into:
+ ...
+ (gdb) p (short []) s1^M
+ $3 = {0, 1, 0, <optimized out>}^M
+ (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1
+ ...
+ while this is expected:
+ ...
+ (gdb) p (short []) s1^M
+ $3 = {1, 0, 0, <optimized out>}^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 <tom@tromey.com>
+
+2024-06-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-06-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-18 Tom de Vries <tdevries@suse.de>
+
+ [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 <nick.alcock@oracle.com>
+
+ 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) <ctn_next_inner>: 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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_) <cu.ctn_fp>: Make non-const.
+
+2024-06-18 Nick Alcock <nick.alcock@oracle.com>
+
+ 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) <ctf_names>: Augment comment.
+ <ctf_conflicting_enums>: 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 <nick.alcock@oracle.com>
+
+ 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 <valgrind/valgrind.h>.
+ * 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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) <cd_name_counts>: 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 <nick.alcock@oracle.com>
+
+ libctf: doc: fix ctf_stype_t typedef string in spec
+
+2024-06-18 Nick Alcock <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <nickc@redhat.com>
+
+ Ensure that the text segment is aligned on disk when using --rosegment.
+
+2024-06-18 Felix Willgerodt <felix.willgerodt@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-06-18 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <hau.hsu@sifive.com>
+
+ 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 <gianluca@rivosinc.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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<cc> { 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-17 Maciej W. Rozycki <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+2024-06-17 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-16 Tom Tromey <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-15 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-06-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-06-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-06-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-06-15 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-06-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-14 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ ld: Align --no-error-execstack help output
+ * lexsup.c (elf_static_list_options): Align --no-error-execstack
+ help output.
+
+2024-06-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ aarch64: add SPMU system registers missed in f01ae0392ed
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <nickc@redhat.com>
+
+ Regenerate configure files in ld sub-directory
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+ Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+ Acked-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+ Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+ Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
+
+2024-06-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-06-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-06-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-06-13 Nick Clifton <nickc@redhat.com>
+
+ Adjust linker tests that are sensitive to --rosegment
+
+2024-06-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <nickc@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <macro@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove LS_TOKEN_STOKEN macro
+ This removes the LS_TOKEN_STOKEN macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove LS_TOKEN_KEYWORD macro
+ This removes the LS_TOKEN_KEYWORD macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove PARSER_STREAM macro
+ This removes the PARSER_STREAM macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove PARSER_EXPLICIT macro
+ This removes the PARSER_EXPLICIT macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove PARSER_RESULT macro
+ This removes the PARSER_RESULT macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove PARSER_STATE macro
+ This removes the PARSER_STATE macro from linespec.c.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2024-06-12 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [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 <tdevries@suse.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-06-12 Claudio Bantaloukas <claudio.bantaloukas@arm.com>
+
+ 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 <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-12 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <tom@tromey.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-06-12 A. Wilcox <awilfox@adelielinux.org>
+
+ PR 31882 libctf: test suite incorrect format specifiers
+
+2024-06-12 Jiawei <jiawei@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-06-11 Kilian Kilger <kkilger@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-06-11 Tom Tromey <tom@tromey.com>
+
+ Remove extract_long_unsigned_integer
+ The function extract_long_unsigned_integer is unused, so remove it.
+ Tested by rebuilding.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-06-11 Alan Modra <amodra@gmail.com>
+
+ support_dt_relr aarch64
+ Tweak commit db335d7e0a so that support_dt_relr returns false for
+ aarch64*-*-*ilp32.
+
+2024-06-11 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ 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 <david@davidgf.net>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-10 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'ValueError'>: \
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <class 'ValueError'>: 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 <ahajkova@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <macro@orcam.me.uk>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [1] https://github.com/python/cpython/issues/72148
+
+2024-06-10 Alan Modra <amodra@gmail.com>
+
+ 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 <rostiprodev@gmail.com>
+
+ src-release.sh: don't take untracked files into account in the uncommitted changes check
+
+2024-06-10 David Guillen Fandos <david@davidgf.net>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <Aditya.Kamath1@ibm.com>
+ Reported-By: Tom de Vries <tdevries@suse.de>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865
+
+2024-06-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+ Tested on arm-linux.
+
+2024-06-10 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ x86/APX: add missing CPU requirement to imm+rm forms of <alu2> insns
+ This was overlooked when the form was added by dd74a603376e ("Support
+ APX NF").
+
+2024-06-10 Clément Chigot <chigot@adacore.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-09 Alan Modra <amodra@gmail.com>
+
+ regen sim/frv files for copyright update
+
+2024-06-09 Matthieu Longo <matthieu.longo@arm.com>
+
+ autoupdate: regen after replacing obsolete macros
+
+2024-06-09 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-08 Tom Tromey <tom@tromey.com>
+
+ 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 <eliz@gnu.org>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-07 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-06-07 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-06-07 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-06-07 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+ PR arm/tdep
+ Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089
+
+2024-06-07 Alan Modra <amodra@gmail.com>
+
+ 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 <szabolcs.nagy@arm.com>
+
+ aarch64: Test DT_RELR with discarded sections
+
+2024-06-07 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-06 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <johan.sternerup@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-06 Johan Sternerup <johan.sternerup@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-06 Johan Sternerup <johan.sternerup@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-06 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ Updated Spanish translation for the bfd/ directory
+
+2024-06-06 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Add support for Zvfbfwma extension
+ This implements the Zvfbfwma extension, as of version 1.0.
+ View detailed information in:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zvfbfwma---vector-bf16-widening-mul-add>
+
+ 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:
+ <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=38dd4e26e07c6be7cf4d169141ee4f3a03f3a09d>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Add support for Zvfbfmin extension
+ This implements the Zvfbfmin extension, as of version 1.0.
+ View detailed information in:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zvfbfmin---vector-bf16-converts>
+
+ 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:
+ <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ddf65c5fc6ba7cf5826e1c02c569c923a541c09>
+
+ 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 <zengxiao@eswincomputing.com>
+
+ RISC-V: Add support for Zfbfmin extension
+ This implements the Zfbfmin extension, as of version 1.0.
+
+ View detailed information in:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/bfloat16.adoc#zfbfmin---scalar-bf16-converts>
+
+ 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:
+ <https://github.com/riscv/riscv-isa-manual/blob/main/src/zfh.adoc>
+
+ 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:
+ <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=35224ead63732a3550ba4b1332c06e9dc7999c31>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-05 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ Fix illegal memory access when bfd_get_section_contents is called with a NULL section pointer.
+ PR 31843
+
+2024-06-05 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <mary.bennett682@gmail.com>
+
+ 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 <mary.bennett682@gmail.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ 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 <mary.bennett682@gmail.com>
+
+ 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 <mary.bennett682@gmail.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+ Nazareno Bruschi <nazareno.bruschi@embecosm.com>
+ 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 <mary.bennett682@gmail.com>
+
+ 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 <mary.bennett682@gmail.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-05 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-04 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-06-04 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <ahajkova@redhat.com>
+
+2024-06-04 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <dmitry.neverov@jetbrains.com>
+
+ Add myself to gdb/MAINTAINERS
+
+2024-06-04 Rostislav Krasny <rostiprodev@gmail.com>
+
+ src-release.sh: fix adjusting files permissions and cleaning
+ PR 31800
+
+2024-06-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-06-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-06-04 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-06-04 mengqinggang <mengqinggang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+ Jinyang He <hejinyang@loongson.cn>
+
+ 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 <git@xen0n.name>
+ Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t
+
+2024-06-04 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: add hardware counters for AMD Zen4
+ ChangeLog
+ 2024-06-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * 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 <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-06-03 Tom Tromey <tromey@adacore.com>
+
+ 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 <ssbssa@yahoo.de>
+
+ 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 "<string>", line 1, in <module>
+ 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 <tom@tromey.com>
+
+2024-06-03 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 "<string>", line 1, in <module>
+ 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 <tom@tromey.com>
+
+2024-06-03 Mark Wielaard <mark@klomp.org>
+
+ 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 <tdevries@suse.de>
+
+ [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 <ahajkova@redhat.com>
+
+ PR testsuite/31822
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822
+
+2024-06-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-02 Tom Tromey <tom@tromey.com>
+
+ Fix typo in tui-data.h
+ I noticed a typo in a comment in tui-data.h.
+
+2024-06-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-06-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-31 Kevin Buettner <kevinb@redhat.com>
+
+ [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 <tdevries@suse.de>
+
+2024-05-31 Claudio Bantaloukas <claudio.bantaloukas@arm.com>
+
+ 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 <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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-05-31 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ aarch64: Add some DT_RELR ld tests
+
+2024-05-31 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <felix.willgerodt@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-31 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <eliz@gnu.org>
+
+2024-05-31 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused includes in symfile.c
+ Remove some includes reported as unused by clangd.
+
+ Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6
+
+2024-05-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused includes in breakpoint.{c,h}
+ Remove some includes reported as unused by clangd.
+
+ Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d
+
+2024-05-30 Nick Clifton <nickc@redhat.com>
+
+ Update binutils release documentation to include using the -z option when invoking src-release.sh
+
+2024-05-30 Mark Wielaard <mark@klomp.org>
+
+ src-release.sh: Support zstd compression
+
+2024-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ .gitignore: ignore .vscode
+
+2024-05-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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, <GEN0> 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 <tom@tromey.com>
+
+2024-05-29 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ 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
+ <no sym>.
+
+2024-05-29 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-28 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ 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 <tom@tromey.com>
+
+ 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 <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 <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 <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-05-28 Nick Clifton <nickc@redhat.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ Add new ELF section and segment types to readelf.
+
+2024-05-28 Javier Mora <cousteaulecommandant@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-27 Tom Tromey <tom@tromey.com>
+
+ 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 <nelson@rivosinc.com>
+
+ RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc.
+ This was originally reported by Hau Hsu <hau.hsu@sifive.com>.
+
+ 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 <nelson@rivosinc.com>
+
+ RISC-V: Segment fault for kernel purgatory when linking.
+ This was originally reported by Ard Biesheuvel <ardb@kernel.org>.
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-26 Joel Brobecker <brobecker@adacore.com>
+
+ 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 <brobecker@adacore.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-25 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-24 Alan Modra <amodra@gmail.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <thiago.bauermann@linaro.org>
+
+ Tested on x86_64-linux.
+
+2024-05-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-23 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-23 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <tom@tromey.com>
+
+2024-05-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-22 Alan Modra <amodra@gmail.com>
+
+ libctf testsuite compilation failure
+ * testsuite/libctf-regression/open-error-free.c (main): Correct
+ format length modifier.
+
+2024-05-22 Tom Tromey <tromey@adacore.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ restore build with --enable-maintainer-mode
+ A build with --enable-maintainer-mode is currently failing with:
+
+ make[4]: *** No rule to make target '<SRC>/gas/config/te-ia64aix.h',
+ needed by '<SRC>/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 <matthieu.longo@arm.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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
+ set<cc>reg32/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 <lili.cui@intel.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: use StringBuilder to create long messages
+ ChangeLog
+ 2024-05-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/collctrl.cc: Use StringBuilder to create messages.
+ Remove unused variables and arrays.
+ * src/collctrl.h: Remove unused variables.
+
+2024-05-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Remove hardware counter tables for unsupported hardware (Sparc)
+ ChangeLog
+ 2024-05-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/31123
+ * common/hwctable.c: Remove hardware counter tables for Sparc machines.
+
+2024-05-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: remove memset() in libcollector
+ ChangeLog
+ 2024-05-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * 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 <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-21 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-05-21 Jan Beulich <jbeulich@suse.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-20 Kévin Le Gouguec <legouguec@adacore.com>
+
+ 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<bool>'
+ 384 | std::atomic<bool> 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 <command-line>:
+ […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>'
+ 174 | struct atomic;
+ | ^~~~~~
+ make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1
+
+ Presumably windows-nat.c relied on objfiles.h including <atomic>,
+ which was undone in 2024-05-16 "gdb: remove unused includes in
+ objfiles.{c,h}" (f617661c110).
+
+2024-05-20 Luca Boccassi <luca.boccassi@gmail.com>
+
+ readelf: add pretty printing for FDO Dlopen Metadata note
+
+2024-05-20 Nick Clifton <nickc@redhat.com>
+
+ Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh
+ PR 31726
+
+2024-05-20 Tom de Vries <tdevries@suse.de>
+
+ [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 <simark@simark.ca>
+ Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2024-05-20 Claudio Bantaloukas <claudio.bantaloukas@arm.com>
+
+ aarch64: Add support for the fpmr system register
+
+2024-05-20 Georg-Johann Lay <avr@gjlay.de>
+
+ 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 <sfoon.kim@samsung.com>
+
+ 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 <aburgess@redhat.com>
+ Approved-By: Nelson Chu <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-18 Tom Tromey <tom@tromey.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-05-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-05-17 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-05-17 Dmitry Neverov <dmitry.neverov@jetbrains.com>
+
+ gdb/symtab: use symbol name matcher for all segments in a qualified name
+
+2024-05-17 Dmitry Neverov <dmitry.neverov@jetbrains.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-17 Dmitry Neverov <dmitry.neverov@jetbrains.com>
+
+ gdb/symtab: reuse last segment lookup name info by creating it outside the loop
+
+2024-05-17 Dmitry.Neverov <dmitry.neverov@jetbrains.com>
+
+ 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<wxBitmapBundleImpl>. 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-16 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <main>
+ ...
+ 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 <tom@tromey.com>
+
+2024-05-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <abdul.b.ijaz@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-05-16 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused include in infcmd.c
+ clangd reports this header as unused.
+
+ Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b
+
+2024-05-16 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-16 Victor Do Nascimento <vicdon01@e133397.arm.com>
+
+ 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 { <Zd1>.H-<Zd2>.H }, <Zn>.B
+ - bf2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
+
+ Multi-vector floating-point convert from FP8 to
+ deinterleaved BFloat16:
+ -----------------------------------------------
+
+ - bf1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
+ - bf2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
+
+ Multi-vector floating-point convert from BFloat16
+ to packed FP8 format:
+ -------------------------------------------------
+
+ - bfcvt <Zd>.B, { <Zn1>.H-<Zn2>.H }
+
+ Multi-vector floating-point convert from FP8 to
+ half-precision (in-order):
+ -----------------------------------------------
+
+ - f1cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
+ - f2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
+
+ Multi-vector floating-point convert from FP8 to
+ deinterleaved half-precision:
+ -----------------------------------------------
+
+ - f1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
+ - f2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.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 <Zd>.B, { <Zn1>.S-<Zn4>.S }
+
+ Multi-vector floating-point adjust exponent by vector:
+ ------------------------------------------------------
+
+ - fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
+ <Zm>.H
+ - fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
+ <Zm>.S
+ - fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
+ <Zm>.D
+
+ Multi-vector floating-point adjust exponent:
+ --------------------------------------------
+
+ - fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
+ { <Zm1>.H - <Zm2>.H }
+ - fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
+ { <Zm1>.S - <Zm2>.S }
+ - fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
+ { <Zm1>.D - <Zm2>.D }
+
+2024-05-16 Victor Do Nascimento <vicdon01@e133397.arm.com>
+
+ 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<d>.H, Z<n>.B
+ - bf2cvt Z<d>.H, Z<n>.B
+ - bf1cvtlt Z<d>.H, Z<n>.B
+ - bf2cvtlt Z<d>.H, Z<n>.B
+
+ FP8 convert to half-precision (bottom/top):
+ -------------------------------------------
+
+ - f1cvt Z<d>.H, Z<n>.B
+ - f2cvt Z<d>.H, Z<n>.B
+ - f1cvtlt Z<d>.H, Z<n>.B
+ - f2cvtlt Z<d>.H, Z<n>.B
+
+ BFloat16/half-precision convert, narrow and
+ interleave to FP8:
+ -------------------------------------------
+
+ - bfcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }
+ - fcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }
+
+ Single-precision convert, narrow and interleave
+ to FP8 (bottom/top):
+ -----------------------------------------------
+
+ - fcvtnb Z<d>.B, { Z<n>1.S - Z<n>2.S }
+ - fcvtnt Z<d>.B, { Z<n>1.S - Z<n>2.S }
+
+2024-05-16 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ 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<d>.8H, V<n>.8B
+ - bf2cvtl V<d>.8H, V<n>.8B
+ - bf1cvtl2 V<d>.8H, V<n>.16B
+ - bf2cvtl2 V<d>.8H, V<n>.16B
+
+ FP8 convert to half-precision (vector):
+ ---------------------------------------
+
+ - f1cvtl V<d>.8H, V<n>.8B
+ - f2cvtl V<d>.8H, V<n>.8B
+ - f1cvtl2 V<d>.8H, V<n>.16B
+ - f2cvtl2 V<d>.8H, V<n>.16B
+
+ Single-precision to FP8 convert and narrow (vector):
+ ----------------------------------------------------
+
+ - fcvtn V<d>.8B, V<n>.4S, V<m>.4S
+ - fcvtn2 V<d>.16B, V<n>.4S, V<m>.4S
+
+ Half-precision to FP8 convert and narrow (vector):
+ --------------------------------------------------
+
+ - fcvtn V<d>.8B, V<n>.4H, V<m>.4H
+ - fcvtn V<d>.16B, V<n>.8H, V<m>.8H
+
+ Floating-point adjust exponent by vector:
+ -----------------------------------------
+
+ - fscale V<d>.4H, V<n>.4H, V<m>.4H
+ - fscale V<d>.8H, V<n>.8H, V<m>.8H
+ - fscale V<d>.2S, V<n>.2S, V<m>.2S
+ - fscale V<d>.4S, V<n>.4S, V<m>.4S
+ - fscale V<d>.2d, V<n>.2d, V<m>.2d
+
+2024-05-16 Victor Do Nascimento <vicdon01@e133397.arm.com>
+
+ aarch64: fp8 convert and scale - add feature flags and related structures
+
+2024-05-16 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-05-16 Matthieu Longo <matthieu.longo@arm.com>
+
+ aarch64: add SPMU feature and its associated registers
+
+2024-05-16 Nick Clifton <nickc@redhat.com>
+
+ Move assembler "IRP \+" test into a separate file. Add XFAILs for targets that do not support it.
+
+2024-05-16 Richard Earnshaw <rearnsha@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-16 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-15 Fangrui Song <maskray@gcc.gnu.org>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 : <no .debug_str_offsets section>
+ ...
+
+ 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 : <no .debug_str_offsets.dwo section>
+ ...
+
+ 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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-15 Joseph Faulls <Joseph.Faulls@imgtec.com>
+
+ 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 <tom@tromey.com>
+
+ Add spaceship operator to cp-name-parser.y
+ While debugging gdb, I saw this:
+
+ During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >'
+
+ This happens because cp-name-parser.y does not handle the spaceship
+ operator. This patch implements this.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-05-14 Tom Tromey <tromey@adacore.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-14 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-14 Pali Roh?r <pali@kernel.org>
+
+ Improve objdump -p output of PE Import and Export Tables
+ PR 31738
+
+2024-05-14 Jason Merrill <jason@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-05-14 Nick Clifton <nickc@redhat.com>
+
+ Fix gas's 'macro count' test for various targets
+
+2024-05-14 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <rearnsha@arm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-13 Nick Clifton <nickc@redhat.com>
+
+ Add new assembler macro pseudo-variable \+ which counts the number of times a macro has been invoked.
+
+2024-05-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-11 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-10 Tom Tromey <tromey@adacore.com>
+
+ 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 <pedro@palves.net>
+
+2024-05-10 Tom Tromey <tom@tromey.com>
+
+ 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 <ahajkova@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-05-10 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <ciaranwoodward@xmos.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-05-10 Nick Clifton <nickc@redhat.com>
+
+ Add --section-ordering command line option to the bfd linker.
+
+2024-05-10 Alan Modra <amodra@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-10 Nick Clifton <nickc@redhat.com>
+
+ Add missing \n to the end of warning messages in dwarf.c.
+ PR 31722
+
+2024-05-10 Pedro Alves <pedro@palves.net>
+
+ 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 <bernd.edlinger@hotmail.de>
+ Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
+ Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
+
+2024-05-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
+
+2024-05-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-09 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tom@tromey.com>
+
+2024-05-09 Eli Zaretskii <eliz@gnu.org>
+
+ Fix typo in gdb/README.
+ Patch from Tiezhu Yang <yangtiezhu@loongson.cn>.
+
+2024-05-09 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-09 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <simark@simark.ca>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-05-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-05-08 Tom de Vries <tdevries@suse.de>
+
+ [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 <Aditya.Kamath1@ibm.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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
+ "<unavailable>",
+ - 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 <aburgess@redhat.com>
+
+ PR python/31437
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437
+
+2024-05-08 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-07 Hannes Domani <ssbssa@yahoo.de>
+
+ 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<symfile_add_flag>) (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<char, gdb::xfree_deleter<char> >&&) (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 <tom@tromey.com>
+
+2024-05-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-05-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+ Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
+
+2024-05-07 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-05-07 Pedro Alves <pedro@palves.net>
+
+ 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 <pedro@palves.net>
+
+ 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 <lancelot.six@amd.com>
+
+ 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 <tdevries@suse.de>
+
+ Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
+
+2024-05-07 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-06 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <mutex> 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 <mutex> in gdb/complaints.c when STD_CXX_THREAD
+ is defined.
+
+ Additionally make the configure script try to #include <mutex>
+ to automatically select --disable-threading when the header file
+ is not able to compile.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-05-06 Tom de Vries <tdevries@suse.de>
+
+ [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 <pedro@palves.net>
+
+2024-05-06 Tom de Vries <tdevries@suse.de>
+
+ [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 <pedro@palves.net>
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
+
+2024-05-06 Cui, Lili <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-04 Hannes Domani <ssbssa@yahoo.de>
+
+ 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<void ()>::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 <tom@tromey.com>
+
+2024-05-04 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-05-04 Alan Modra <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-05-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-03 Pedro Alves <pedro@palves.net>
+
+ 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 <windows.h>
+
+ 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 <aburgess@redhat.com>
+
+2024-05-03 Mark Wielaard <mark@klomp.org>
+
+ [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 <tdevries@suse.de>
+
+ [gdb/testsuite] Use save_vars to restore GDBFLAGS
+ There's a pattern of using:
+ ...
+ set saved_gdbflags $GDBFLAGS
+ set GDBFLAGS "$GDBFLAGS ..."
+ <do something with GDBFLAGS>
+ set GDBFLAGS $saved_gdbflags
+ ...
+
+ Simplify this by using save_vars:
+ ...
+ save_vars { GDBFLAGS } {
+ set GDBFLAGS "$GDBFLAGS ..."
+ <do something with GDBFLAGS>
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+2024-05-03 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <jbeulich@suse.com>
+
+ x86: tidy <sse*> templates
+ Some of them no longer need a separate vvvv attribute, thus allowing
+ them to be simplified. For <aes> 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <luis.machado@arm.com>
+
+2024-05-02 Alan Modra <amodra@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+ PR symtab/31689
+ https://sourceware.org/bugzilla/show_bug.cgi?id=31689
+
+2024-05-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-05-01 Tom de Vries <tdevries@suse.de>
+
+ [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/<pid>/compiler.i.
+
+ Tested on x86_64-linux.
+
+2024-05-01 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-30 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <thiago.bauermann@linaro.org>
+
+ 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 <kevinb@redhat.com>
+
+2024-04-30 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2024-04-30 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2024-04-30 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2024-04-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-29 Pedro Alves <pedro@palves.net>
+
+ 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 <luis.machado@arm.com>
+
+2024-04-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+
+2024-04-29 Nick Clifton <nickc@redhat.com>
+
+ Fix initiali state of DWARF v5 line number table in BFD library
+ PR 30783
+
+2024-04-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-29 Nick Clifton <nickc@redhat.com>
+
+ Fix building Loongarch BFD with a 32-bit compiler
+
+2024-04-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-27 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <signal handler called>
+ #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 <lambda(bfd*, void*, stat*)>::operator()(bfd *,
+ void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400,
+ sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955
+ #19 0x00000000007f015c in <lambda(bfd*, void*, stat*)>::_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=<error reading variable: Cannot access memory at address 0x2d310>)
+ 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 <pedro@palves.net>
+
+ PR remote/31577
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577
+
+2024-04-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <simon.marchi@efficios.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <ssbssa@yahoo.de>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <jimb@codesourcery.com>
+ Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
+ Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
+ Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <jimb@codesourcery.com>
+ Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
+ Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
+ Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-04-26 Pedro Alves <pedro@palves.net>
+
+ 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 <jimb@codesourcery.com>
+ Co-Authored-By: Mike Wrighton <mike_wrighton@mentor.com>
+ Co-Authored-By: Nathan Sidwell <nathan@codesourcery.com>
+ Co-Authored-By: Hafiz Abid Qadeer <abidh@codesourcery.com>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-04-26 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-26 Sébastien Michelland <sebastien.michelland@lcis.grenoble-inp.fr>
+
+ 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 <gintctl_gint_gdb+304>: 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 <simon.marchi@efficios.com>
+
+2024-04-26 Jan Beulich <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-25 Carl Love <cel@linux.ibm.com>
+
+ Fix end_sequence addresses for dw2-lines.exp
+ The patch:
+
+ From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001
+ From: Tom de Vries <tdevries@suse.de>
+ 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 <end_of_sequence>:
+ 4102c4: 52800000 mov w0, #0x0 // #0
+ 4102c8: 9100c3ff add sp, sp, #0x30
+ 4102cc: d65f03c0 ret
+ ...
+ is not described by the line table:
+ ...
+
+ <snip>
+
+ 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 <david.faust@oracle.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-25 Jinyang He <hejinyang@loongson.cn>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-24 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <kevinb@redhat.com>
+
+2024-04-24 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2024-04-24 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tdevries@suse.de>
+
+ PR symtab/31622
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622
+
+2024-04-24 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tdevries@suse.de>
+
+ PR symtab/31268
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268
+
+2024-04-24 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <hex> in main () at threadcrash.c:423^M
+ ...
+ also matches "remaining" in:
+ ...
+ #1 <hex> in __GI___nanosleep (requested_time=<hex>, remaining=<hex>) at \
+ nanosleep.c:27^M
+ ...
+
+ Fix this by checking for "in main" instead.
+
+ Tested on x86_64-linux.
+
+2024-04-24 Nick Clifton <nickc@redhat.com>
+
+ Update readelf's display of RELR sections to include the number of locations relocated
+
+2024-04-24 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <claudio.bantaloukas@arm.com>
+
+ arm: Fix MVE vmla encoding
+
+2024-04-23 Olivier Hainque <hainque@adacore.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove enum precision_type
+ It is unused.
+
+ Change-Id: Ic49a3ef03c21b209594cd567ae80b5441606bef6
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change type of quit_flag to bool
+ Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <whame91@gmail.com>
+
+ objdump: Round ASCII art lines in jump visualization
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move RequireLongest to gdbsupport/traits.h
+ Move it out of defs.h.
+
+ Change-Id: Ie1743d41a57f81667650048563e66073c72230cf
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove extract_long_unsigned_integer
+ It is unused.
+
+ Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-23 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-22 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <tom@tromey.com>
+
+2024-04-22 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-04-22 Cui, Lili <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-21 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-21 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-20 mengqinggang <mengqinggang@loongson.cn>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nvinson234@gmail.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ libctf: fix a debugging typo
+ libctf/
+
+ * ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo.
+
+2024-04-19 Nick Alcock <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <stephen.brennan@oracle.com>.
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <gustavo.romero@linaro.org>
+
+ gdb: Document qIsAddressTagged packet
+ This commit documents the qIsAddressTagged packet.
+
+ Reviewed-by: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ gdb/testsuite: Add unit tests for qIsAddressTagged packet
+ Add unit tests for testing qIsAddressTagged packet request creation and
+ reply checks.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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/<PID>/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/<PID>/smaps via vFile requests.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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 <luis.machado@arm.com>
+
+2024-04-19 Gustavo Romero <gustavo.romero@linaro.org>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-19 Alan Modra <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-18 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR testsuite/31647
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647
+
+2024-04-18 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html
+
+2024-04-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-04-18 Nick Clifton <nickc@redhat.com>
+
+ HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets.
+ PR 30743
+
+2024-04-18 Will Hawkins <hawkinsw@obs.cr>
+
+ 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 <tdevries@suse.de>
+ Tested-By: Tom de Vries <tdevries@suse.de>
+
+2024-04-18 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-17 Tom Tromey <tom@tromey.com>
+
+ 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 <keiths@redhat.com>
+
+2024-04-17 Pedro Alves <pedro@palves.net>
+
+ 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 <ssbssa@yahoo.de>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905
+
+2024-04-17 Pedro Alves <pedro@palves.net>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <godlygeek@gmail.com>
+
+ Fix include guard typo
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-04-17 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-17 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-17 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [gdb/testsuite] Fix end_sequence addresses
+ I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
+ ...
+ 00000000004102c4 <end_of_sequence>:
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <Aditya.Kamath1@ibm.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <obj_name>'.
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <lin1.hu@intel.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-17 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <amodra@gmail.com>
+
+2024-04-16 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-04-16 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <nickc@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-16 Eli Zaretskii <eliz@gnu.org>
+
+ 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 <nickc@redhat.com>
+
+ Remove accidental commit of an experimental change
+
+2024-04-16 Tom de Vries <tdevries@suse.de>
+
+ [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 <class 'MemoryError'>:
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ gas: Free unused memory in scfi_ops_cleanup
+ * scfi.c (scfi_ops_cleanup): Free op->op_data and head.
+
+2024-04-16 Fangrui Song <i@maskray.me>
+
+ Simplify readelf's RELR relocation display.
+
+2024-04-16 Nick Clifton <nickc@redhat.com>
+
+ Gas Doc: Update example of how .altmacro affects the interpretation of macro arguments.
+ PR 31255
+
+2024-04-16 Simon Cook <simon.cook@embecosm.com>
+
+ Remove debug printout from 9dd918142787246ea7ed53494d9cbc6b51486133
+
+2024-04-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-04-15 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Add Felix Willgerodt as the x86 architecture maintainer
+ This includes both the i386 and x86-64 architectures.
+
+2024-04-15 Nick Clifton <nickc@redhat.com>
+
+ Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments.
+ PR 31527
+
+2024-04-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <shank.vijay@yandex.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-15 Christophe Lyon <christophe.lyon@linaro.org>
+
+ gprofng: Fix dvi documentation build rule
+ This patch fixes 'install-dvi'.
+
+2024-04-15 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <aburgess@redhat.com>
+
+2024-04-15 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <aburgess@redhat.com>
+
+2024-04-15 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <aburgess@redhat.com>
+
+2024-04-15 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-12 Pedro Alves <pedro@palves.net>
+
+ 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 <pedro@palves.net>
+
+ 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 <pedro@palves.net>
+
+ 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 <sigq>) 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 <kevinb@redhat.com>
+ Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9
+
+2024-04-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-12 Nick Clifton <nickc@redhat.com>
+
+ Update description of macro keyword argument assignment in assembler documentation.
+ PR 31255
+
+2024-04-12 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-12 Alan Modra <amodra@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ Improve readelf's display of RELR relocs.
+
+ Add -j/--display-section option to readelf.
+
+2024-04-11 Tom de Vries <tdevries@suse.de>
+
+ [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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ gdb: fix format in remote.c
+ Fix space-before-parenthesis format at three spots in remote.c.
+
+2024-04-11 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-10 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <christophe.lyon@linaro.org>
+
+ 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 <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2024-04-10 Nick Clifton <nickc@redhat.com>
+
+ readelf: Add -j/--display-section command line option.
+
+2024-04-10 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-09 Tom Tromey <tom@tromey.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <nickc@redhat.com>
+
+2024-04-09 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <nickc@redhat.com>
+
+2024-04-09 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <alex.coplan@arm.com>
+
+ 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 <alex.coplan@arm.com>
+
+ 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 <alex.coplan@arm.com>
+
+ 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 <jiawei@iscas.ac.cn>
+
+ 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 <charlie.keaney@embecosm.com>
+ Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
+ Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
+ Co-Authored by: Simon Cook <simon.cook@embecosm.com>
+ Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
+ Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <lin1.hu@intel.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-08 H.J. Lu <hjl.tools@gmail.com>
+
+ 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á <ahajkova@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-04-08 Alexandra Hájková <ahajkova@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-08 Simon Marchi <simon.marchi@efficios.com>
+
+ 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:
+ <stdout>: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 <amodra@gmail.com>
+
+ 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 <MIND>): Test for
+ exactly matching indirect symbols before cycling on a defweak.
+
+2024-04-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-07 Cui, Lili <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-06 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-06 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <zhiqxion@qti.qualcomm.com>
+
+ Add support for Windows network paths to the UNC support in _bfd_real_open().
+ PR 31527
+
+2024-04-05 Christophe Lyon <christophe.lyon@linaro.org>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-04 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-04 Bernd Edlinger <bernd.edlinger@hotmail.de>
+
+ 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 <tom@tromey.com>
+
+2024-04-04 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <nandakumar@nandakumar.co.in>
+
+ dlltool: replace unchecked malloc with xmalloc
+
+2024-04-04 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-03 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <lancelot.six@amd.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-03 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <eliz@gnu.org>
+
+2024-04-03 Lancelot SIX <lancelot.six@amd.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-03 Lancelot SIX <lancelot.six@amd.com>
+
+ 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 <tom@tromey.com>
+
+2024-04-03 Nick Clifton <nickc@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-02 Tom Tromey <tom@tromey.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ Run isort
+ This patch is the result of running 'isort .' in the gdb directory.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-04-02 Tom de Vries <tdevries@suse.de>
+
+ [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 '<stdlib.h>' or provide a declaration of 'malloc'
+ +++ |+#include <stdlib.h>
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 \e[7m printf ("hello\n");\e[0m │
+ │ 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 <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR tui/31522
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522
+
+2024-04-02 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <f1-0x5>:
+ 0: b8 00 00 00 00 mov $0x0,%eax
+
+ and objdump --reloc --disassemble=f2 prints
+ 0000000f <f2>:
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-04-02 John David Anglin <danglin@gcc.gnu.org>
+
+ 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 <danglin@gcc.gnu.org>
+
+ 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 <amodra@gmail.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-31 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-30 Tom Tromey <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 '<stdlib.h>' or provide a declaration of 'malloc'
+ +++ |+#include <stdlib.h>
+ 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 '<string.h>' or provide a declaration of \
+ 'strcpy'
+ +++ |+#include <string.h>
+ 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 '<string.h>' or provide a declaration of \
+ 'strlen'
+ ...
+
+ Fix this by adding the missing includes.
+
+ Tested on aarch64-linux.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-03-29 Tom de Vries <tdevries@suse.de>
+
+ [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 <jhb@FreeBSD.org>
+
+2024-03-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-28 Tom Tromey <tom@tromey.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-28 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-03-28 Nelson Chu <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <pedro@palves.net>
+
+2024-03-27 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <pedro@palves.net>
+
+2024-03-27 Simon Marchi <simon.marchi@efficios.com>
+
+ {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 <pedro@palves.net>
+
+2024-03-27 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <pedro@palves.net>
+
+2024-03-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-26 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-03-26 Tom Tromey <tromey@adacore.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-03-26 Simon Marchi <simon.marchi@efficios.com>
+
+ 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<addrmap_mutable>::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<addrmap_mutable>::~unique_ptr' requested here
+ 422 | auto map = std::make_unique<struct addrmap_mutable> ();
+ | ^
+
+ Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too
+ while at it.
+
+ Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-03-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/31460
+ * libcollector/heaptrace.c: Use the __thread variable to check for
+ * reentry. Clean up code.
+
+2024-03-25 Pedro Alves <pedro@palves.net>
+
+ 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 <kevinb@redhat.com>
+ Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2
+
+2024-03-25 Pedro Alves <pedro@palves.net>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <TAB> 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<TAB><TAB>
+ xx 11 xx 22
+ (gdb) thread apply all hel<TAB>
+ (gdb) thread apply all help
+ (gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Keith Seitz <keiths@redhat.com>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Keith Seitz <keiths@redhat.com>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Keith Seitz <keiths@redhat.com>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+ Natalia Saiapova <natalia.saiapova@intel.com>
+ Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Keith Seitz <keiths@redhat.com>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Keith Seitz <keiths@redhat.com>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-25 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR testsuite/31514
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514
+
+2024-03-25 Tom de Vries <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-23 John Baldwin <jhb@FreeBSD.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-22 Pedro Alves <pedro@palves.net>
+
+ 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 <jhb@FreeBSD.org>
+ Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff
+
+2024-03-22 Pedro Alves <pedro@palves.net>
+
+ 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 <jhb@FreeBSD.org>
+ Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5
+
+2024-03-22 Pedro Alves <pedro@palves.net>
+
+ 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 <jhb@FreeBSD.org>
+ Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc
+
+2024-03-22 Pedro Alves <pedro@palves.net>
+
+ 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 <jhb@FreeBSD.org>
+ Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6
+
+2024-03-22 Tom Tromey <tromey@adacore.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-22 Tom Tromey <tromey@adacore.com>
+
+ Remove some unnecessary casts
+ I found a few unnecessary casts when calling
+ set_gdbarch_disassembler_options_implicit.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-03-22 Tom Tromey <tromey@adacore.com>
+
+ Constify get_disassembler_options
+ This changes get_disassembler_options to return a const char *.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-03-22 Tom Tromey <tom@tromey.com>
+
+ 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 <yangtiezhu@loongson.cn>
+
+ 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 <pedro@palves.net>
+
+ 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 <lancelot.six@amd.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1
+
+2024-03-22 Jan Beulich <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-21 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <felix.willgerodt@intel.com>
+
+2024-03-21 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <orgads@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-03-21 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <pedro@palves.net>
+
+2024-03-21 Hui Li <lihui@loongson.cn>
+
+ 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 <nickc@redhat.com>
+
+ New Romanian translation for gas sub-directory
+
+2024-03-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-20 Simon Marchi <simon.marchi@efficios.com>
+
+ .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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR testsuite/31502
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502
+
+2024-03-20 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-03-20 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-03-20 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-03-20 Hannes Domani <ssbssa@yahoo.de>
+
+ 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<LeftRight*>(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<LeftRight*>(r)
+ $2 = (LeftRight *) 0x3bf87c
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-03-20 Simon Marchi <simon.marchi@efficios.com>
+
+ 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/<some-hash>`, 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 <tromey@adacore.com>
+ Acked-By: Guinevere Larsen <blarsen@redhat.com>
+ Acked-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-03-20 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <keiths@redhat.com>
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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.
+
+ <syscall name="fcntl" number="__NR3264_fcntl"/>
+ <syscall name="statfs" number="__NR3264_statfs"/>
+ <syscall name="fstatfs" number="__NR3264_fstatfs"/>
+ <syscall name="truncate" number="__NR3264_truncate"/>
+ <syscall name="ftruncate" number="__NR3264_ftruncate"/>
+ <syscall name="lseek" number="__NR3264_lseek"/>
+ <syscall name="sendfile" number="__NR3264_sendfile"/>
+ <syscall name="mmap" number="__NR3264_mmap"/>
+ <syscall name="fadvise64" number="__NR3264_fadvise64"/>
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Workaround PR gas/31115
+ On arm-linux, with gas 2.40, I run into:
+ ...
+ (gdb) x /i main+8^M
+ 0x4e1 <main+7>: 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-19 Tom Tromey <tromey@adacore.com>
+
+ 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 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-03-19 Saurabh Jha <saurabh.jha@arm.com>
+
+ gas, aarch64: Add faminmax extension
+
+2024-03-19 Nick Clifton <nickc@redhat.com>
+
+ Remove redunant test of ELF size in core note decoder.
+ PR 31469
+
+2024-03-19 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+2024-03-19 Nick Clifton <nickc@redhat.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <tlloyddavies@undo.io>
+
+ 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 <tom@tromey.com>
+
+2024-03-19 Toby Lloyd Davies <tlloyddavies@undo.io>
+
+ Add myself to gdb/MAINTAINERS
+
+2024-03-19 Tom de Vries <tdevries@suse.de>
+
+ [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 <class 'gdb.error'>: 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-18 Nick Clifton <nickc@redhat.com>
+
+ Regenerate AArch64 opcodes files
+
+2024-03-18 Yury Khrustalev <yury.khrustalev@arm.com>
+
+ 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 <yury.khrustalev@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ [PATCH] ld: Improve documentation of -rpath-link search paths
+
+2024-03-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <lancelot.six@amd.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-03-18 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-03-18 Clément Chigot <chigot@adacore.com>
+
+ bfd: add missing include <time.h>
+ 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, <time.h> is pulled by <sys/stat.h> already
+ included in bfd.h. That's why it went unnoticed.
+
+2024-03-18 Nick Clifton <nickc@redhat.com>
+
+ Fix compiling bfd/vms-lib.c for a 32-bit host.
+
+2024-03-18 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-03-18 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-17 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+ PR testsuite/31290
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290
+
+2024-03-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-15 Tom Tromey <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-03-15 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-14 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR build/31483
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483
+
+2024-03-14 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <iconv.h>
+ | ^~~~~~~~~
+
+ 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 <tom@tromey.com>
+
+2024-03-14 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <data+16>
+ ...
+
+ 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 <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ PR tdep/29423
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
+
+2024-03-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-13 Tom Tromey <tromey@adacore.com>
+
+ 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 <christophe.lyon@linaro.org>
+
+ opcodes: Fix build verbosity
+ Add $(AM_V_xxx) in a few places where they were missing.
+
+2024-03-13 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <sys/mman.h>.
+ (MAP_FILE): Removed.
+ (bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for
+ mmap failure.
+ * cache.c: Don't include <sys/mman.h>.
+ (cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap
+ failure.
+ * opncls.c (opncls_bmmap): Likewise.
+ * sysdep.h: Include <sys/mman.h> 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 <hjl.tools@gmail.com>
+
+ 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 <hau.hsu@sifive.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-12 Tom de Vries <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+ PR tdep/31214
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214
+
+2024-03-12 Sam James <sam@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-03-12 Sam James <sam@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-03-12 Schimpe, Christina <christina.schimpe@intel.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-11 Sam James <sam@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-03-11 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-03-11 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-03-11 Tom Tromey <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <nick.alcock@oracle.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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? <arsen@aarsen.me>
+ AuthorDate: Wed Nov 15 12:53:04 2023 +0000
+ Commit: Nick Clifton <nickc@redhat.com>
+ CommitDate: Wed Nov 15 12:53:04 2023 +0000
+
+ Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9
+
+2024-03-11 Markus Metzger <markus.t.metzger@intel.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-03-11 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tdevries@suse.de>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293
+
+2024-03-11 Tom de Vries <tdevries@suse.de>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <lancelot.six@amd.com>
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+ [1] https://linaro.atlassian.net/browse/GNU-1120
+
+2024-03-11 Tom de Vries <tdevries@suse.de>
+
+ 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 <tdevries@suse.de>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <steve@sk2.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-03-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <class 'KeyError'>: '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 <tom@tromey.com>
+
+2024-03-09 Tom de Vries <tdevries@suse.de>
+
+ [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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-08 Tom Tromey <tromey@adacore.com>
+
+ 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 <legouguec@adacore.com>
+
+2024-03-08 Tom Tromey <tromey@adacore.com>
+
+ 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 <eliz@gnu.org>
+
+2024-03-08 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <jiawei@iscas.ac.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-06 Nick Clifton <nickc@redhat.com>
+
+ Add "-j1" to make command lines in the create-a-release README.
+
+2024-03-06 Lulu Cai <cailulu@loongson.cn>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-05 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-02 Hui Li <lihui@loongson.cn>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-03-02 Tom Tromey <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-03-01 Will Hawkins <hawkinsw@obs.cr>
+
+ gdb/jit: Fix missing word in comment
+ ChangeLog:
+
+ * gdb/jit.c: Fix missing word in code comment.
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Be more verbose about missing operand type
+ Provide expected operand type in s390-specific assembler operand parsing
+ error message:
+
+ "error: operand <operand-number>: missing <operand-type> operand"
+
+ With <operand-type> 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Add comments to assembler operand parsing logic
+ gas/
+ * config/tc-s390.c: Add comments to assembler operand parsing
+ logic.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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=<processor>).
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <krebbel@linux.ibm.com>
+
+2024-03-01 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Whitespace fixes in conditional branch flavor descriptions
+ opcodes/
+ * s390-mkopc.c: Whitespace fixes in conditional branch flavor
+ descriptions.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2024-03-01 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-29 Alan Modra <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR dap/31275
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275
+
+2024-02-29 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-02-29 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 = <unavailable>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-02-29 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <ishitatsuyuki@gmail.com>
+
+ 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 <ishitatsuyuki@gmail.com>
+
+ 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 <ishitatsuyuki@gmail.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ PR 31390
+ * gprofng/gp-display-html: One line change to "use bigint".
+
+2024-02-29 John Baldwin <jhb@FreeBSD.org>
+
+ aarch64: Use aarch64_debug_printf in a few more places
+ No functional change
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2024-02-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-28 Alan Modra <amodra@gmail.com>
+
+ 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 <vladislav.belov@syntacore.com>
+
+ Fix implementation of SUBALIGN.
+
+2024-02-28 Tom Tromey <tromey@adacore.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-02-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-02-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-02-27 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+2024-02-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR testsuite/31351
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351
+
+2024-02-27 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
+
+2024-02-27 Tom de Vries <tdevries@suse.de>
+
+ [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 "<string>", line 1, in <module>
+ 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 <tom@tromey.com>
+
+ PR testsuite/31391
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391
+
+2024-02-27 Pedro Alves <pedro@palves.net>
+
+ 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 <takashi.yano@nifty.ne.jp>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f
+
+2024-02-27 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ 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 <kolerov93@gmail.com>
+
+ 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 <shahab@synopsys.com>
+
+2024-02-27 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+ 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 <mengqinggang@loongson.cn>
+
+ LoongArch: Run overflow testcases only on LoongArch target
+
+2024-02-27 ticat_fp <fanpeng@loongson.cn>
+
+ 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 <hejinyang@loongson.cn>
+
+ 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 <hejinyang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/amd-dbgapi: fix indentation
+ Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0
+
+2024-02-26 Tom Tromey <tromey@adacore.com>
+
+ 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 <pedro@palves.net>
+
+ [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 <tdevries@suse.de>
+ Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9
+
+2024-02-26 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-02-26 Tom de Vries <tdevries@suse.de>
+
+ [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 "<snip>/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 "<snip>/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 <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410
+
+2024-02-26 Tom de Vries <tdevries@suse.de>
+
+ [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<const gdb_byte> 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 <yangtiezhu@loongson.cn>
+
+ 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 <kevinb@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-02-26 Andreas Arnez <arnez@linux.ibm.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: Add hardware counter profiling for the Ampere system
+ gprofng should recognize Ampere and other ARM systems.
+
+ gprofng/ChangeLog
+ 2024-02-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * 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 <hejinyang@loongson.cn>
+
+ LoongArch: bfd: Correct the name of R_LARCH_SOP_POP_32_U in howto_table
+
+2024-02-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-24 Tom de Vries <tdevries@suse.de>
+
+ [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<T> (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 <spam_hole@shaw.ca>
+ Reported-By: Simon Marchi <simark@simark.ca>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/31399
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399
+
+2024-02-24 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ 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 <tom@tromey.com>
+
+2024-02-23 Tom Tromey <tromey@adacore.com>
+
+ 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 <pedro@palves.net>
+
+ 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 <tom@tromey.com>
+ Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17
+
+2024-02-23 Pedro Alves <pedro@palves.net>
+
+ 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 <jon.turney@dronecode.org.uk>
+
+ 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 <jon.turney@dronecode.org.uk>
+
+ 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 <pedro@palves.net>
+ Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc
+
+2024-02-23 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ x86: also permit YMM/ZMM use in CFI directives
+ Next to code using %ymm<N> or %zmm<N> it is more natural to have .cfi_*
+ directives also reference those, not the corresponding %xmm<N>. Accept
+ their names as kind of aliases, i.e. resolving to the same numbers.
+
+ While extending the respective 64-bit testcase, also add %bnd<N> there
+ (should have happened right with 633789901c83 ["x86-64: Dwarf2 register
+ numbers for %bnd<N>"], sorry), requiring binutils/dwarf.c to be adjusted
+ accordingly as well.
+
+2024-02-23 Jan Beulich <jbeulich@suse.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <felix.willgerodt@intel.com>
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-02-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-22 Tom Tromey <tromey@adacore.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-02-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR dap/31380
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380
+
+2024-02-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR dap/31386
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386
+
+2024-02-22 Tom de Vries <tdevries@suse.de>
+
+ [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: <msg>
+ ...
+ which is the default name assigned by python, so instead use the more
+ explicit:
+ ...
+ GDB main: <msg>
+ ...
+
+ Tested on aarch64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-21 Tom Tromey <tromey@adacore.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <kevinb@redhat.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2024-02-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <kolerov93@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 "<thread name>: terminating"
+ log entry from thread_wrapper before DAP shutdown.
+
+ Tested on aarch64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR dap/31380
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380
+
+2024-02-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-02-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-02-21 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-02-21 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ 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 <lancelot.six@amd.com>
+
+2024-02-21 Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
+
+ 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 <nelson@rivosinc.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-20 Tom Tromey <tromey@adacore.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-20 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-20 Tom de Vries <tdevries@suse.de>
+
+ [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 <aburgess@redhat.com>
+
+2024-02-20 Paul Iannetta <piannetta@kalrayinc.com>
+
+ 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 <piannetta@kalrayinc.com>
+
+ 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 <piannetta@kalrayinc.com>
+
+ 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 <piannetta@kalrayinc.com>
+
+ 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 <piannetta@kalrayinc.com>
+
+ kvx: gas: fix leak
+ gas/ChangeLog:
+
+ * config/tc-kvx.c (md_apply_fix): Free memory at this end.
+
+2024-02-20 Paul Iannetta <piannetta@kalrayinc.com>
+
+ 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 <piannetta@kalrayinc.com>
+
+ 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 <jose.marchesi@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-19 Will Hawkins <hawkinsw@obs.cr>
+
+ 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 <jose.marchesi@oracle.com>
+
+ 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 <Claudio.Bantaloukas@arm.com>
+
+ arm: Add support for Armv9.5-A
+
+2024-02-19 Yury Khrustalev <Yury.Khrustalev@arm.com>
+
+ 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 <yury.khrustalev@arm.com>
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <zacwalker@microsoft.com>
+
+ 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 <tankut.baris.aktemur@intel.com>
+
+ 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 <andrew.burgess@embecosm.com>
+ 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 [<null>] (<noexec>)]
+ 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<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
+ #25 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
+ #26 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_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<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590
+ #28 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, 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 <execute_command(char const*, int)>, 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 [<null>] (<noexec>)]
+ 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 <class 'gdb.error'>: 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<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
+ #13 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
+ #14 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_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<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590
+ #16 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, 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 <execute_command(char const*, int)>, 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 <class 'gdb.error'>: 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 <oguzhan.karakaya@intel.com>
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-19 Tom de Vries <tdevries@suse.de>
+
+ [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<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(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<false, unsigned char const*, unsigned char*>(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<false, unsigned char const*, unsigned char*>(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<false, unsigned char const*, unsigned char*>(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*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867
+ #6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) 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<void (char const*, symbol*)>::bind<print_variable_and_value_data>(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<void (char const*, symbol*)>::bind<print_variable_and_value_data>(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<void (char const*, symbol*)>::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<void (char const*, symbol*)>) 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<char, gdb::xfree_deleter<char> >&&) 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<range, std::allocator<range> > 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<void (char const*, symbol*)>::bind<print_variable_and_value_data>(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<void (char const*, symbol*)>::bind<print_variable_and_value_data>(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<void (char const*, symbol*)>::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<void (char const*, symbol*)>) 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<char, gdb::xfree_deleter<char> >&&) 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
+ <AddressSanitizer: heap-buffer-overflow>
+ ...
+
+ 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 => <error reading variable: access outside bounds of object>)
+ ...
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-16 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ Update how-to-make-a-release document to reference new git repository for the documentation
+
+2024-02-16 Jan Beulich <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-15 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <hawkinsw@obs.cr>
+
+ 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 <amodra@gmail.com>
+
+ 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 <sam@rfc1149.net> (tiny change)
+
+ gdb/doc: Fix several typos in GDB documentation
+ Approved-by: Eli Zaretskii <eliz@gnu.org>
+
+2024-02-15 Steinar H. Gunderson <steinar+sourceware@gunderson.no>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-14 Tom de Vries <tdevries@suse.de>
+
+ [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 <signal handler called>
+ #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=<optimized out>) 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=<optimized out>) at /usr/include/c++/13/bits/std_function.h:244
+ #13 0x000000000042e654 in std::function<void ()>::~function() (this=0xfffea8001c10,
+ __in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:334
+ #14 0x0000000000b68e60 in std::_Destroy<std::function<void ()> >(...) (...)
+ at /usr/include/c++/13/bits/stl_construct.h:151
+ #15 0x0000000000b68cd0 in std::_Destroy_aux<false>::__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 <runnables>)
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <Yuriy.Kolerov@synopsys.com>
+
+ 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 <ykolerov@synopsys.com>
+
+ * opcode/arc.h (enum insn_class_t): Add DBNZ class.
+
+ opcodes/ChangeLog:
+
+ 2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
+
+ * 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 <ykolerov@synopsys.com>
+
+ * config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ".
+
+2024-02-14 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ Tested on aarch64-linux.
+
+2024-02-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-13 Yuriy Kolerov <kolerov93@gmail.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+ PR testsuite/31374
+ https://sourceware.org/bugzilla/show_bug.cgi?id=31374
+
+2024-02-13 Jaydeep Patil <jaydeep.patil@imgtec.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-13 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <thiago.bauermann@linaro.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ PR tdep/31278
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278
+
+2024-02-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-12 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <signal handler called>
+ #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=<optimized out>)
+ 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<void, gdbpy_event&> (__f=...)
+ at /usr/include/c++/13/bits/invoke.h:61
+ #12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__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<void ()>::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 <tom@tromey.com>
+
+2024-02-12 Tom Tromey <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@polymtl.ca>
+
+ gdb: re-format Python files with black 24.1.1
+ New year, new black version.
+
+ Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d
+
+2024-02-12 Frederic Cambus <fred@statdns.com>
+
+ 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 <cel@linux.ibm.com>
+
+ 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á <ahajkova@redhat.com>
+
+ 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 <thiago.bauermann@linaro.org>
+
+2024-02-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-11 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2024-02-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-10 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-09 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <kevinb@redhat.com>
+
+2024-02-09 Peter Bergner <bergner@linux.ibm.com>
+
+ 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 <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-09 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-09 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-09 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-09 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-09 Pedro Alves <pedro@palves.net>
+
+ 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 <tromey@adacore.com>
+
+2024-02-09 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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<N> 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 <indu.bhagat@oracle.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-08 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-08 Alan Modra <amodra@gmail.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Tom Tromey <tom@tromey.com>
+
+ Use pop_back in tui_register_format
+ tui_register_format can use string::pop_back now.
+
+ Tested-By: Tom de Vries <tdevries@suse.de>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-02-08 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 "<string>", line 1, in <module>
+ 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 "<string>", line 1, in <module>
+ 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 <tom@tromey.com>
+
+2024-02-08 Jens Remus <jremus@linux.ibm.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <rjones@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-07 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 "<string>", line 1, in <module>
+ 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 "<string>", line 1, in <module>
+ 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 <tom@tromey.com>
+
+2024-02-07 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-07 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ 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<warning_hook_handler> m_save;
+ | ^
+
+ By manually implementing the save/restore behaviour, rather
+ than using the helper template, this warning is fixed.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-07 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ memory leak in objdump disassemble_section
+ * objdump.c (disassemble_section): Free rel_ppstart on error path.
+
+2024-02-07 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-06 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <yangtiezhu@loongson.cn>
+
+ 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 <chenfeiyang@loongson.cn>
+
+ 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 <chenfeiyang@loongson.cn> # Framework
+ Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes
+ Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes
+
+2024-02-06 Hui Li <lihui@loongson.cn>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-05 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-05 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-05 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-02-05 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-02-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <luis.machado@arm.com>
+
+2024-02-05 Tom Tromey <tromey@adacore.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <luis.machado@arm.com>
+
+ PR tdep/31254
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254
+
+2024-02-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-04 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-02-04 Xi Ruoyao <xry111@xry111.site>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-02 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <nils-christian.kempke@intel.com>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-02 Bernhard Heckel <bernhard.heckel@intel.com>
+
+ 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 <thiago.bauermann@linaro.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-02-02 Ijaz, Abdul B <abdul.b.ijaz@intel.com>
+
+ 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 <tom@tromey.com>
+
+2024-02-02 Jan Beulich <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <sloosemore@baylibre.com>
+
+ MAINTAINERS: Update my e-mail address.
+
+2024-02-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-02-01 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ gprofng: Remove unused macros
+ gprofng/ChangeLog
+ 2024-02-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <Aditya.Kamath1@ibm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-31 Nick Clifton <nickc@redhat.com>
+
+ Mention support for AMD/znver5 in GAS
+
+2024-01-31 Georg-Johann Lay <avr@gjlay.de>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-30 Tom Tromey <tromey@adacore.com>
+
+ 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 <jhb@FreeBSD.org>
+
+2024-01-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-29 Alan Modra <amodra@gmail.com>
+
+ 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 <jose.marchesi@oracle.com>
+
+ 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 <lancelot.six@amd.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ 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 <jose.marchesi@oracle.com>
+
+ 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 <jose.marchesi@oracle.com>
+
+ * opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and
+ BPF_INSN_LDABSDW instructions.
+
+ opcodes/ChangeLog:
+
+ 2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and
+ BPF_INSN_LDABSDW instructions.
+
+ gas/ChangeLog:
+
+ 2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * 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 <nickc@redhat.com>
+
+ Update release making documentation after 2.42 release
+
+ Remove support for the beos file format
+
+2024-01-29 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <aburgess@redhat.com>
+
+2024-01-29 Nick Clifton <nickc@redhat.com>
+
+ Updated French translations for GOLD and LD
+
+2024-01-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-28 Tom Tromey <tom@tromey.com>
+
+ Document new Python and Guile constants
+ This documents the new Python and Guile constants introduced earlier
+ in this series.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-01-28 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-26 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove get_gdb_program_name
+ Nothing uses it.
+
+ Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7
+
+2024-01-25 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-01-25 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ gas: Update NEWS
+ Groups entries by architecture, and update AArch64 content.
+
+2024-01-25 Tom de Vries <tdevries@suse.de>
+
+ [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<thread_info>
+ +class thread_info : public intrusive_list_node<thread_info>,
+ + 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <eh2+188>^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 <tom@tromey.com>
+
+ PR testsuite/31291
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291
+
+2024-01-25 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-24 Alan Modra <amodra@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <keiths@redhat.com>
+
+2024-01-24 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <aburgess@redhat.com>
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2024-01-24 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ aarch64: Eliminate unused variable warnings with -DNDEBUG
+
+2024-01-24 mengqinggang <mengqinggang@loongson.cn>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <piannetta@kalrayinc.com>
+
+ Add myself as the KVX port maintainer
+ binutils/ChangeLog:
+
+ * MAINTAINERS: Add myself as the KVX port maintainer.
+
+2024-01-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-23 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ 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 <xry111@xry111.site>
+
+ [PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42
+
+2024-01-23 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-23 Mike Frysinger <vapier@gentoo.org>
+
+ 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 <jaydeep.patil@imgtec.com>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-22 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <nickc@redhat.com>
+
+ Updated Serbian translations for th bfd, gold and opcodes directories
+
+2024-01-22 Mark Wielaard <mark@klomp.org>
+
+ 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 <mark@klomp.org>
+
+ 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 <mark@klomp.org>
+
+ 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 <mark@klomp.org>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-01-22 Mark Wielaard <mark@klomp.org>
+
+ 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 <mark@klomp.org>
+
+ 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 <mark@klomp.org>
+
+ 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 <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-22 Guinevere Larsen <blarsen@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-22 Xi Ruoyao <xry111@xry111.site>
+
+ 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 <ishitatsuyuki@gmail.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-21 Lancelot SIX <lancelot.six@amd.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-01-21 mengqinggang <mengqinggang@loongson.cn>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <kevinb@redhat.com>
+
+2024-01-20 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-01-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-19 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-19 Сергей Чернов <klen_s@mail.ru>
+
+ 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<rmprofile/lto>_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 <amerey@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-01-19 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+2024-01-19 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <amodra@gmail.com>
+ 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 <oleg.tolmatcev@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ 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 <jbeulich@suse.com>
+
+ x86-64: Dwarf2 register numbers for %bnd<N>
+ 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 <amerey@redhat.com>
+
+ 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=<optimized out>...
+
+ 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=<optimized out>...
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2024-01-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-18 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <eliz@gnu.org>
+
+2024-01-18 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <nickc@redhat.com>
+
+ Add note to translators not to translate z/Architecture
+
+ Updated translations for various sub-directories
+
+2024-01-18 Tom de Vries <tdevries@suse.de>
+
+ [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 <tom@tromey.com>
+
+2024-01-18 Mike Frysinger <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-17 Alan Modra <amodra@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tdevries@suse.de>
+
+2024-01-17 Tom Tromey <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-01-17 Nick Clifton <nickc@redhat.com>
+
+ Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling.
+
+2024-01-17 Xi Ruoyao <xry111@xry111.site>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-15 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <tdevries@suse.de>
+
+2024-01-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unnecessary braces
+ Change-Id: I5e96c0f38aa788462ab19a9becfe22030e913c2a
+
+2024-01-15 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <nickc@redhat.com>
+
+ Update HOWTO document after creating the 2.42 branch
+
+ Change version to 2.42.50 and regenerate files
+
+2024-01-15 Mark Wielaard <mark@klomp.org>
+
+ 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 <nickc@redhat.com>
+
+ Add markers for 2.42 branch
+
+ Update branch/release creation documentation
+
+2024-01-15 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: rcpc3: Regenerate aarch64-*-2.c files
+
+2024-01-15 Victor Do Nascimento <victor.donascimento@arm.com>
+ Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: rcpc3: Add FP load/store insns
+ Along with the relevant unit-tests, this adds the following rcpc3
+ instructions:
+
+ STL1 { <Vt>.D }[<index>], [<Xn|SP>]
+ LDAP1 { <Vt>.D }[<index>], [<Xn|SP>]
+
+ LDAPUR <Bt>, [<Xn|SP>{, #<simm>}]
+ LDAPUR <Ht>, [<Xn|SP>{, #<simm>}]
+ LDAPUR <St>, [<Xn|SP>{, #<simm>}]
+ LDAPUR <Dt>, [<Xn|SP>{, #<simm>}]
+ LDAPUR <Qt>, [<Xn|SP>{, #<simm>}]
+
+ STLUR <Bt>, [<Xn|SP>{, #<simm>}]
+ STLUR <Ht>, [<Xn|SP>{, #<simm>}]
+ STLUR <St>, [<Xn|SP>{, #<simm>}]
+ STLUR <Dt>, [<Xn|SP>{, #<simm>}]
+ STLUR <Qt>, [<Xn|SP>{, #<simm>}]
+
+ with `#<simm>' 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 <victor.donascimento@arm.com>
+
+ 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 <Wt1>, <Wt2>, [<Xn|SP>]
+ LDIAPP <Wt1>, <Wt2>, [<Xn|SP>], #8
+ LDIAPP <Xt1>, <Xt2>, [<Xn|SP>]
+ LDIAPP <Xt1>, <Xt2>, [<Xn|SP>], #16
+
+ STILP <Wt1>, <Wt2>, [<Xn|SP>]
+ STILP <Wt1>, <Wt2>, [<Xn|SP>, #-8]!
+ STILP <Xt1>, <Xt2>, [<Xn|SP>]
+ STILP <Xt1>, <Xt2>, [<Xn|SP>, #-16]!
+
+ LDAPR <Wt>, [<Xn|SP>], #4
+ LDAPR <Xt>, [<Xn|SP>], #8
+
+ STLR <Wt>, [<Xn|SP>, #-4]!
+ STLR <Xt>, [<Xn|SP>, #-8]!
+
+2024-01-15 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <victor.donascimento@arm.com>
+
+ 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 <mark@klomp.org>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <nickc@redhat.com>
+
+ nm: Replace --with-symbol-versions with --without-symbol-versions in --help output
+ PR 31243
+ nm: Fix --help output
+
+2024-01-15 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ aarch64: Remove unused BTI feature bit
+ OK for master?
+
+2024-01-15 Nick Clifton <nickc@redhat.com>
+
+ Add generated source files and fix thinko in aarch64-asm.c
+
+2024-01-15 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ gas/NEWS: announce the new SCFI command line option
+
+2024-01-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ gas: dw2gencfi: externalize the all_cfi_sections
+ gas/
+ * dw2gencfi.h: Declare all_cfi_sections as extern.
+
+2024-01-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-14 Tom de Vries <tdevries@suse.de>
+
+ [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 <tdevries@suse.de>
+
+ [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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-13 Yang Liu <liuyang22@iscas.ac.cn>
+
+ 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 <aburgess@redhat.com>
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2024-01-13 Yang Liu <liuyang22@iscas.ac.cn>
+
+ Add myself to gdb/MAINTAINERS
+
+2024-01-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30889 can't compile without large file support
+ gprofng/ChangeLog
+ 2024-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR 30889
+ * src/util.h (O_LARGEFILE): Define to 0, if not defined.
+
+2024-01-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ PR gprofng/30438
+ PR gprofng/30439
+ PR gprofng/30942
+ * gp-display-html/gp-display-html.in: fixes the issues.
+
+2024-01-12 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ 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 <david.faust@oracle.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <andrew.carlotti@arm.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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
+ <gdb.Progspace object at 0x7ffad4219c10>
+ >>> 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 "<stdin>", line 1, in <module>
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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()
+ <gdb.Frame object at 0x7fa8cc2df270>
+
+ After this patch, we now see:
+
+ (gdb) pi
+ >>> gdb.selected_frame()
+ <gdb.Frame level=0 frame-id={stack=0x7ffff7da0ed0,code=0x000000000040115d,!special}>
+
+ More verbose, but, I hope, more useful.
+
+ If the gdb.Frame becomes invalid, then we will see:
+
+ (gdb) pi
+ >>> invalid_frame_variable
+ <gdb.Frame (invalid)>
+
+ which is inline with how other invalid objects are displayed.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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()
+ <gdb.InferiorThread object at 0x7f4dcc49b970>
+
+ After this patch, we now see:
+
+ (gdb) pi
+ >>> gdb.selected_thread()
+ <gdb.InferiorThread id=1.2 target-id="Thread 0x7ffff7da1700 (LWP 458134)">
+
+ More verbose, but, I hope, more useful.
+
+ If the gdb.InferiorThread becomes invalid, then we will see:
+
+ (gdb) pi
+ >>> invalid_thread_variable
+ <gdb.InferiorThread (invalid)>
+
+ Which is inline with how other invalid objects are displayed.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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: <TYPENAME (invalid)>.
+
+ 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 <tom@tromey.com>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <lsix@lancelotsix.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-12 Tom de Vries <tdevries@suse.de>
+
+ [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 <indu.bhagat@oracle.com>
+
+ 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 <mengqinggang@loongson.cn>
+
+ 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 <lili.cui@intel.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-11 Simon Marchi <simon.marchi@efficios.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <bar>
+ (gdb) p foo
+ $2 = {void (int, int)} 0x10000698 <foo>
+ (gdb) p foobar
+ $3 = {void (int)} 0x100006d0 <foobar>
+ ...
+
+ 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 <blarsen@redhat.com>
+ Approved-By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
+
+ PR testsuite/31232
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232
+
+2024-01-11 Tom de Vries <tdevries@suse.de>
+
+ [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 "<string>", line 1, in <module>^M
+ File "<string>", 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 <kevinb@redhat.com>
+
+ PR gdb/31203
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203
+
+2024-01-11 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ 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 <cailulu@loongson.cn>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ gdbsupport: tighten up libiberty code a bit with dnl
+ No functional change here, just touch up generated output slightly.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-11 Mike Frysinger <vapier@gentoo.org>
+
+ 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 <vapier@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-01-11 Mike Frysinger <vapier@gentoo.org>
+
+ 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 <tom@tromey.com>
+
+2024-01-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <ruud.vanderpas@oracle.com>
+
+ * examples: Top level directory.
+ * examples/mxv-pthreads: Example program written in C.
+
+2024-01-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ 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 <vladimir.mezentsev@oracle.com>
+
+ 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 <Aditya.Kamath1@ibm.com>
+
+ 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 <nickc@redhat.com>
+
+ Sync top level configure and makefiles
+ This update brings in the following commits from the gcc mainline:
+
+ commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f
+ Author: Tom Tromey <tom@tromey.com>
+ 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 <pierre-emmanuel.patry@embecosm.com>
+ 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 <lhyatt@gmail.com>
+ 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 <iain@sandoe.co.uk>
+ 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 <siarheit@google.com>
+ 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 <thomas@codesourcery.com>
+ 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 <saurabh.jha@arm.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+ PR gdb/31209
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209
+
+2024-01-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+ PR gdb/31211
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211
+
+2024-01-10 Tom de Vries <tdevries@suse.de>
+
+ [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 <kevinb@redhat.com>
+
+2024-01-10 Tom de Vries <tdevries@suse.de>
+
+ 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 <tom@tromey.com>
+
+2024-01-10 Tom de Vries <tdevries@suse.de>
+
+ 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 <ahajkova@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-10 Tom de Vries <tdevries@suse.de>
+
+ 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 <ahajkova@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-10 Tom Tromey <tom@tromey.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2024-01-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ 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 <tom@tromey.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <hjl.tools@gmail.com>
+ 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 <maskray@google.com>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <tom@tromey.com>
+ 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 <tromey@adacore.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <jbeulich@suse.com>
+
+ 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 <nickc@redhat.com>
+
+ Synchronize sourceware version of the libiberty sources with the master gcc versions.
+ This brings in the following commits:
+
+ commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a
+ Author: Jakub Jelinek <jakub@redhat.com>
+ 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 <cpuid.h> 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+ 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 <jason@redhat.com>
+ 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 <class T, T V> T f() { return V; }
+ int main() { return f<int,42>(); }
+
+ template <int i> int max() { return i; }
+ template <int i, int j, int... rest> int max()
+ {
+ int sub = max<j, rest...>();
+ return i > sub ? i : sub;
+ }
+ int main() { return max<1,2,3>(); }
+
+ A third C++11 pattern is changed by this patch:
+
+ template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
+ template <typename> struct A { };
+ int main() { f<A,int>(); }
+
+ I aim to resolve these with the ABI committee before GCC 14.1.
+
+ We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
+ (mangling references to dependent template-ids where the name is fully
+ resolved) as references to concepts in std:: will consistently run into this
+ area. This is why mangle-concepts1.C only refers to concepts in the global
+ namespace so far.
+
+ The library changes are to avoid trying to mangle builtins, which fails.
+
+ Demangler support and test coverage is not complete yet.
+
+ commit f2c52c0dfde581461959b0e2b423ad106aadf179
+ Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+ Date: Thu Nov 30 10:06:23 2023 +0100
+
+ libiberty: Disable hwcaps for sha1.o
+
+ This patch
+
+ commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
+ Author: Jakub Jelinek <jakub@redhat.com>
+ Date: Tue Nov 28 13:14:05 2023 +0100
+
+ libiberty: Use x86 HW optimized sha1
+
+ broke Solaris/x86 bootstrap with the native as:
+
+ libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
+ ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ]
+ gccgo: fatal error: Killed signal terminated program go1
+
+ As is already done in a couple of other similar cases, this patches
+ disables hwcaps support for libiberty.
+
+ Initially, this didn't work because config/hwcaps.m4 uses target_os, but
+ didn't ensure it is defined.
+
+ Tested on i386-pc-solaris2.11 with as and gas.
+
+ commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
+ Author: Jakub Jelinek <jakub@redhat.com>
+ Date: Tue Nov 28 13:14:05 2023 +0100
+
+ libiberty: Use x86 HW optimized sha1
+
+ Nick has approved this patch (+ small ld change to use it for --build-id=),
+ so I'm commiting it to GCC as master as well.
+
+ If anyone from ARM would be willing to implement it similarly with
+ vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
+ speedup on those hosts as well, the intent in sha1.c was that
+ sha1_hw_process_bytes, sha1_hw_process_block functions
+ would be defined whenever
+ defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
+ but the body of sha1_hw_process_block and sha1_choose_process_bytes
+ would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
+ the other arch support, similarly for any target attributes on
+ sha1_hw_process_block if needed.
+
+ commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942
+ Author: Mark Wielaard <mjw@redhat.com>
+ Date: Wed Nov 15 20:27:08 2023 +0100
+
+ Regenerate libiberty/aclocal.m4 with aclocal 1.15.1
+
+ There is a new buildbot check that all autotool files are generated
+ with the correct versions (automake 1.15.1 and autoconf 2.69).
+ https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
+
+ Correct one file that was generated with the wrong version.
+
+ commit 879cf9ff45d94065d89e24b71c6b27c7076ac518
+ Author: Brendan Shanks <bshanks@codeweavers.com>
+ Date: Thu Nov 9 21:01:07 2023 -0700
+
+ [PATCH v3] libiberty: Use posix_spawn in pex-unix when available.
+
+ Hi,
+
+ This patch implements pex_unix_exec_child using posix_spawn when
+ available.
+
+ This should especially benefit recent macOS (where vfork just calls
+ fork), but should have equivalent or faster performance on all
+ platforms.
+ In addition, the implementation is substantially simpler than the
+ vfork+exec code path.
+
+ Tested on x86_64-linux.
+
+ v2: Fix error handling (previously the function would be run twice in
+ case of error), and don't use a macro that changes control flow.
+
+ v3: Match file style for error-handling blocks, don't close
+ in/out/errdes on error, and check close() for errors.
+
+ commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450
+ Author: Jason Merrill <jason@redhat.com>
+ Date: Thu Aug 17 11:36:23 2023 -0400
+
+ c++: constrained hidden friends [PR109751]
+
+ r13-4035 avoided a problem with overloading of constrained hidden friends by
+ checking satisfaction, but checking satisfaction early is inconsistent with
+ the usual late checking and can lead to hard errors, so let's not do that
+ after all.
+
+ We were wrongly treating the different instantiations of the same friend
+ template as the same function because maybe_substitute_reqs_for was failing
+ to actually substitute in the case of a non-template friend. But we don't
+ actually need to do the substitution anyway, because [temp.friend] says that
+ such a friend can't be the same as any other declaration.
+
+ After fixing that, instead of a redefinition error we got an ambiguous
+ overload error, fixed by allowing constrained hidden friends to coexist
+ until overload resolution, at which point they probably won't be in the same
+ ADL overload set anyway.
+
+ And we avoid mangling collisions by following the proposed mangling for
+ these friends as a member function with an extra 'F' before the name. I
+ demangle this by just adding [friend] to the name of the function because
+ it's not feasible to reconstruct the actual scope of the function since the
+ mangling ABI doesn't distinguish between class and namespace scopes.
+
+ PR c++/109751
+
+2024-01-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: ADD FEAT_THE RCWCAS instructions.
+ This patch adds support for FEAT_THE doubleword and quadword instructions.
+ doubleword insturctions are enabled by "+the" flag whereas quadword
+ instructions are enabled on passing both "+the and +d128" flags.
+
+ Support for following sets of instructions is added in this patch.
+ Read check write compare and swap doubleword:
+ (rcwcas, rcwcasa, rcwcasal, rcwcasl)
+ Read check write compare and swap quadword:
+ (rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl)
+ Read check write software compare and swap doubleword:
+ (rcwscas, rcwscasa, rcwscasal, rcwscasl)
+ Read check write software compare and swap quadword:
+ (rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl)
+ Read check write atomic bit clear on doubleword:
+ (rcwclr, rcwclra, rcwclral, rcwclrl)
+ Read check write atomic bit clear on quadword:
+ (rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl)
+ Read check write software atomic bit clear on doubleword:
+ (rcwsclr, rcwsclra, rcwsclral, rcwsclrl)
+ Read check write software atomic bit clear on quadword:
+ (rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl)
+ Read check write atomic bit set on doubleword:
+ (rcwset,rcwseta, rcwsetal,rcwsetl)
+ Read check write atomic bit set on quadword:
+ (rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl)
+ Read check write software atomic bit set on doubleword:
+ (rcwsset,rcwsseta,rcwssetal,rcwssetl)
+ Read check write software atomic bit set on quadword:
+ (rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl)
+ Read check write swap doubleword:
+ (rcwswp,rcwswpa,rcwswpal,rcwswpl)
+ Read check write swap quadword:
+ (rcwswpp,rcwswppa, rcwswppal,rcwswppl)
+ Read check write software swap doubleword:
+ (rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl)
+ Read check write software swap quadword:
+ (rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl)
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Regenerate aarch64-*-2.c files
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ arch64: Add optional operand register pair support tests
+ Add tests to cover the full range of behaviors observed around
+ optional register operands for the `tlbip' and `sysp' instructions,
+ namely:
+
+ * Not all `tlbip' operations take GPR operands. When this is the
+ case, we should check that neither optional operand was supplied.
+ * When a `tlbip' operation is labeled with the `F_HASXT' flag, xzr
+ is not a valid optional operand. In such case, at least the fist
+ optional register needs to be specified with a non-xzr value.
+ * The first operand for both insns should be either xzr or an
+ even-numbered register (n % 2 == 0). In the former scenario, the
+ second operand should default to xzr too, while in the latter, it
+ should default to n + 1.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add support for 128-bit system register mrrs and msrr insns
+ With the addition of 128-bit system registers to the Arm architecture
+ starting with Armv9.4-a, a mechanism for manipulating their contents
+ is introduced with the `msrr' and `mrrs' instruction pair.
+
+ These move values from one such 128-bit system register into a pair of
+ contiguous general-purpose registers and vice-versa, as for example:
+
+ msrr ttlb0_el1, x0, x1
+ mrrs x0, x1, ttlb0_el1
+
+ This patch adds the necessary support for these instructions, adding
+ checks for system-register width by defining a new operand type in the
+ form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p'
+ predicate, responsible for checking whether the requested system
+ register table entry is marked as implemented in the 128-bit mode via
+ the F_REG_128 flag.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add TLBIP tests
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add xs variants of tlbip operands
+ The 2020 Architecture Extensions to the Arm A-profile architecture
+ added FEAT_XS, the XS attribute feature, giving cores the ability to
+ identify devices which can be subject to long response delays. TLB
+ invalidate (TLBI) operations and barriers can also be annotated with
+ this attribute[1].
+
+ With the introduction of the 128-bit translation tables with the
+ Armv8.9-a/Armv9.4-a Translation Hardening Extension, a series of new
+ TLB invalidate operations are introduced which make use of this
+ extension. These are added to aarch64_sys_regs_tlbi[] for use
+ with the `tlbip' insn.
+
+ [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Implement TLBIP 128-bit instruction
+ The addition of 128-bit page table descriptors and, with it, the
+ addition of 128-bit system registers for these means that special
+ "invalidate translation table entry" instructions are needed to cope
+ with the new 128-bit model. This is introduced with the `tlbpi'
+ instruction, implemented here.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Create QL_SRC_X2 and QL_DEST_X2 qualifier macros
+ Some 128-bit system operations (mrrs, msrr, tlbip, and sysp) take two
+ qualified operands and one of unqualified type (e.g. system register
+ name, tlbip operation). This creates the need for adequate qualifiers
+ to handle this.
+
+ This patch therefore introduces the `QL_SRC_X2' and `QL_DST_X2' qualifier
+ specifiers, which expand to `QLF3(NIL,X,X)' and `QLF3(X,X,NIL)',
+ respectively.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Apply narrowing of allowed immediate values for SYSP
+ While CRn and CRm fields in the SYSP instruction are 4-bit wide and
+ are thus able to accommodate values in the range 0-15, the
+ specifications for the SYSP instructions limit their ranges to 8-9 for
+ CRm and 0-7 in the case of CRn.
+
+ This led to the need to signal in some way to the operand parser that
+ a given operand is under special restrictions regarding its use. This
+ is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the
+ range of operand values for fields in the instruction tagged with the
+ flag.
+
+ The flag is then used in `parse_operands' when the instruction is
+ assembled, but needs not be taken into consideration during
+ disassembly.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add support for the SYSP 128-bit system instruction
+ Mirroring the use of the `sys' - System Instruction assembly
+ instruction, this implements its 128-bit counterpart, `sysp'.
+
+ This optionally takes two contiguous general-purpose registers
+ starting at an even number or, when these are omitted, by default
+ sets both of these to xzr.
+
+ Syntax:
+
+ sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add support for optional operand pairs
+ Two of the instructions added by the `+d128' architectural extension
+ add the flexibility to have two optional operands. Prior to the
+ addition of the `tlbip' and `sysp' instructions, no mnemonic allowed
+ more than one such optional operand.
+
+ With `tlbip' as an example, some TLBIP instruction names do not allow
+ for any optional operands, while others allow for both to be optional.
+ In the latter case, it is possible that either the second operand
+ alone is omitted or both operands are omitted.
+ Therefore, a considerable degree of flexibility needed to be added to
+ the way operands were parsed. It was, however, possible to achieve
+ this with relatively few changes to existing code.
+
+ it is noteworthy that opcode flags specifying the optional operand
+ number are non-orthogonal. For example, we have:
+
+ #define F_OPD1_OPT (2 << 12) : 0b10 << 12
+ #define F_OPD2_OPT (3 << 12) : 0b11 << 12
+
+ such that by virtue of the observation that
+
+ (F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT
+
+ it is impossible to mark both operands 1 and 2 as optional for an
+ instruction and it is assumed that a maximum of 1 operand can ever be
+ optional. This is not overly-problematic given that, for optional
+ pairs, the second optional operand is always found immediately after
+ the first. Thus, it suffices for us to flag that there is a second
+ optional operand. With this fact, we can infer its position in the
+ mnemonic from the position of the first (e.g. if the second operand in
+ the mnemonic is optional, we know the third is too). We therefore
+ define the `F_OPD_PAIR_OPT' flag and calculate its position in the
+ mnemonic from the value encoded by the `F_OPD<n>_OPT' flag.
+
+ Another observation is that there is a tight coupling between default
+ values assigned to the two registers when one (or both) are omitted
+ from the mnemonic. Namely, if Xt1 has a value of 0x1f (the zero
+ register is specified), Xt2 defaults to the same value, otherwise Xt2
+ will be assigned Xt + 1. This meant that where you have default value
+ validation, in checking the second optional operand's value, it is
+ also necessary to look at the value assigned to the
+ previously-processed operand value before deciding its validity. Thus
+ `process_omitted_operand' needs not only access to its `operand'
+ argument, but also to the global `inst' struct.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add support for xzr register in register pair operands
+ Analysis of the allowed operand values for `sysp' and `tlbip' reveals
+ a significant departure from the allowed behavior for operand register
+ pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other
+ insns in this category.
+
+ For instructions `casp', `mrrs' and `msrr' the register pair must
+ always start at an even index and the second register in the pair is
+ the index + 1. This precludes the use of xzr as the first register,
+ given it corresponds to register number 31.
+
+ This is different in the case of `sysp' and `tlbip', however. These
+ allow the use of xzr and, where the first operand in the pair is
+ omitted, this is the default value assigned to it. When this
+ operand is assigned xzr, it is expected that the second operand will
+ likewise take on a value of xzr.
+
+ These two instructions therefore "break" two rules of register pairs:
+
+ * The first of the two registers is odd-numbered.
+ * The index of the second register is equal to that of the first,
+ and not n+1.
+
+ To allow for this departure from hitherto standard behavior, we
+ extend the functionality of the assembler by defining an extension of
+ the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR.
+
+ It is used in defining `sysp' and `tlbip' and allows
+ `operand_general_constraint_met_p' to allow the pair to both take on
+ the value of xzr.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Expand maximum number of operands from 5 to 6
+ Given the introduction of the new Armv9.4-a `sysp' insn using the
+ following syntax:
+
+ sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}
+
+ and by extension the need to encode 6 assembly operands, extend
+ Binutils to handle instructions taking 6 operands, up from a previous
+ maximum of 5.
+
+2024-01-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add +d128 architectural feature support
+ Indicating the presence of the Armv9.4-a features concerning 128-bit
+ Page Table Descriptors, 128-bit System Registers and Instructions,
+ the "+d128" architectural extension flag is added to the list of
+ possible -march options in Binutils, together with the necessary macro
+ for encoding d128 instructions.
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: compile build tools with -Werror too
+ Add support for compiling build tools with various -Werror settings.
+ Since the tools don't compile cleanly with the same set of flags as
+ the rest of the sim code, we need to maintain & test a separate list.
+
+ Only bother when not cross-compiling so we don't have to test all the
+ flags against the build compiler. This should be good enough for our
+ actual development flows.
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: igen: fix format-zero-length warnings
+ Fix warnings from calling printf functions with "" which normally
+ is useless.
+
+ sim: m68hc11: gencode: add printf markings
+
+ sim: m32c: fix declaration-after-statement warnings
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: fix unused variable warnings
+ Leave the igen code in place as it's meant to be used with newer
+ (to-be-written) code ported from the ppc version.
+
+ The sh code isn't really necessary as the opcodes enums have been
+ maintained independently from here, and the lists are out-of-sync
+ already.
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: mark local funcs/vars as static
+ These are only used in the respective files, so mark them as static.
+ This fixes missing prototype warnings at build time.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Back out some parallel_for_each features
+ Now that the DWARF reader does not use parallel_for_each, we can
+ remove some of the features that were added just for it: return values
+ and task sizing.
+
+ The thread_pool typed tasks feature could also be removed, but I
+ haven't done so here. This one seemed less intrusive and perhaps more
+ likely to be needed at some point.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Avoid language-based lookups in startup path
+ The previous patches are nearly enough to enable background DWARF
+ reading. However, this hack in language_defn::get_symbol_name_matcher
+ causes an early computation of current_language:
+
+ /* If currently in Ada mode, and the lookup name is wrapped in
+ '<...>', hijack all symbol name comparisons using the Ada
+ matcher, which handles the verbatim matching. */
+ if (current_language->la_language == language_ada
+ && lookup_name.ada ().verbatim_p ())
+ return current_language->get_symbol_name_matcher_inner (lookup_name);
+
+ I considered various options here -- reversing the order of the
+ checks, or promoting the verbatim mode to not be a purely Ada feature
+ -- but in the end found that the few calls to this during startup
+ could be handled more directly.
+
+ In the JIT code, and in create_exception_master_breakpoint_hook, gdb
+ is really looking for a certain kind of symbol (text or data) using a
+ linkage name. Changing the lookup here is clearer and probably more
+ efficient as well.
+
+ In create_std_terminate_master_breakpoint, the lookup can't really be
+ done by linkage name (it would require relying on a certain mangling
+ scheme, and also may trip over versioned symbols) -- but we know that
+ this spot is C++-specific, and so the language ought to be temporarily
+ set to C++ here.
+
+ After this patch, the "file" case is much faster:
+
+ (gdb) file /tmp/gdb
+ 2023-10-23 13:16:54.456 - command started
+ Reading symbols from /tmp/gdb...
+ 2023-10-23 13:16:54.520 - command finished
+ Command execution time: 0.225906 (cpu), 0.064313 (wall)
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Optimize lookup_minimal_symbol_text
+ lookup_minimal_symbol_text always loops over all objfiles, even when
+ an objfile is passed in as an argument. This patch changes the
+ function to loop over the minimal number of objfiles in the latter
+ situation.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Lazy language setting
+ When gdb starts up with a symbol file, it uses the program's "main" to
+ decide the "static context" and the initial language. With background
+ DWARF reading, this means that gdb has to wait for a significant
+ amount of DWARF to be read synchronously.
+
+ This patch introduces lazy language setting. The idea here is that in
+ many cases, the prompt can show up early, making gdb feel more
+ responsive.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Change current_language to be a macro
+ This changes the 'current_language' global to be a macro that wraps a
+ function call. This change will let a subsequent patch introduce lazy
+ language setting.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Remove two quick_symbol_functions methods
+ quick_symbol_functions::read_partial_symbols is no longer implemented,
+ so both it and quick_symbol_functions::can_lazily_read_symbols can be
+ removed. This allows for other functions to be removed as well.
+
+ Note that SYMFILE_NO_READ is now pretty much dead. I haven't removed
+ it here -- but could if that's desirable. I tend to think that this
+ functionality would be better implemented in the core; but whenever I
+ dive into the non-DWARF readers it is pretty depressing.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Simplify the public DWARF API
+ dwarf2_has_info and dwarf2_initialize_objfile are only separate
+ because the DWARF reader implemented lazy psymtab reading. However,
+ now that this is gone, we can simplify the public DWARF API again.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Do more DWARF reading in the background
+ This patch rearranges the DWARF reader so that more work is done in
+ the background. This is PR symtab/29942.
+
+ The idea here is that there is only a small amount of work that must
+ be done on the main thread when scanning DWARF -- before the main
+ scan, the only part is mapping the section data.
+
+ Currently, the DWARF reader uses the quick_symbol_functions "lazy"
+ functionality to defer even starting to read. This patch instead
+ changes the reader to start reading immediately, but doing more in
+ worker tasks.
+
+ Before this patch, "file" on my machine:
+
+ (gdb) file /tmp/gdb
+ 2023-10-23 12:29:56.885 - command started
+ Reading symbols from /tmp/gdb...
+ 2023-10-23 12:29:58.047 - command finished
+ Command execution time: 5.867228 (cpu), 1.162444 (wall)
+
+ After the patch, more work is done in the background and so this takes
+ a bit less time:
+
+ (gdb) file /tmp/gdb
+ 2023-10-23 13:25:51.391 - command started
+ Reading symbols from /tmp/gdb...
+ 2023-10-23 13:25:51.712 - command finished
+ Command execution time: 1.894500 (cpu), 0.320306 (wall)
+
+ I think this could be further sped up by using the shared library load
+ map to avoid objfile loops like the one in expand_symtab_containing_pc
+ -- it seems like the correct objfile could be chosen more directly.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Change how cooked index waits for threads
+ This changes the cooked index code to wait for threads in its
+ public-facing API. That is, the waits are done in cooked_index now,
+ and never in the cooked_index_shard. Centralizing this decision makes
+ it easier to wait for other events here as well.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Add "maint set dwarf synchronous"
+ For testing, it's sometimes convenient to be able to request that
+ DWARF reading be done synchronously. This patch adds a new "maint"
+ setting for this purpose.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Move cooked_index_storage to cooked-index.h
+ This moves cooked_index_storage to cooked-index.h. This is needed by
+ a subsequent patch.
+
+ Add gdb::task_group
+ This adds gdb::task_group, a convenient way to group background tasks
+ and then call a function when all the tasks have completed.
+
+ Add quick_symbol_functions::compute_main_name
+ This adds a new compute_main_name method to quick_symbol_functions.
+ Currently there are no implementations of this, but a subsequent patch
+ will add one.
+
+ Add deferred_warnings parameter to read_addrmap_from_aranges
+ When DWARF reading is done in the background,
+ read_addrmap_from_aranges will be called from a worker thread.
+ Because warnings can't be emitted from these threads, this patch adds
+ a new deferred_warnings parameter to the function, letting the caller
+ control exactly how the warnings are emitted.
+
+ Refactor complaint thread-safety approach
+ This patch changes the way complaint works in a background thread.
+ The new approach requires installing a complaint interceptor in each
+ worker, and then the resulting complaints are treated as one of the
+ results of the computation. This change is needed for a subsequent
+ patch, where installing a complaint interceptor around a parallel-for
+ is no longer a viable approach.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Add thread-safety to gdb's BFD wrappers
+ This changes gdb to ensure that gdb's BFD cache is guarded by a lock.
+ This avoids any races when multiple threads might open a BFD (and thus
+ use the BFD cache) at the same time.
+
+ Currently, this change is not needed because the the main thread waits
+ for some DWARF scanning to be completed before returning. The only
+ locking that's required is when opening DWO files, and there's a local
+ lock to this end in dwarf2/read.c.
+
+ However, in the coming patches, the DWARF reader will begin its work
+ earlier, in the background. This means there is the potential for the
+ DWARF reader and other code on the main thread to both attempt to open
+ BFDs at the same time.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Add a couple of bfd_cache_close calls
+ This adds a couple of calls to bfd_cache_close at points where a BFD
+ isn't actively needed by gdb. Normally at these points, all the
+ needed section data is already mapped, so we can simply close the file
+ descriptor. This is harmless at worst, because if this is needed
+ after all, the BFD file descriptor cache will reopen it.
+
+ Pre-read DWZ section data
+ This changes the DWZ code to pre-read the section data and somewhat
+ simplify the DWZ API. This makes it easier to add the bfd_cache_close
+ call to the new dwarf2_read_dwz_file function -- after this is done,
+ there shouldn't be a reason to keep the BFD's file descriptor open.
+
+2024-01-09 Tom Tromey <tom@tromey.com>
+
+ Don't use objfile::intern in DWO code
+ The DWO code in the DWARF reader currently uses objfile::intern. This
+ accesses a shared data structure and so would be racy when used from
+ multiple threads. I don't believe this can happen right now, but
+ background reading could provoke this, and in any case it's better to
+ avoid this, just to be sure.
+
+ This patch changes this code to just use a std::string. A new type is
+ introduced to do hash table lookups, to avoid unnecessary copies.
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: clean more generated outputs
+
+ sim: mips: drop old clean workaround
+ This logic dates back to the original import, and seems to be for
+ handling systems where `rm -f` (i.e. no files) would error out.
+ None of that is relevant for us with current automake, so drop it.
+
+ sim: ppc: workaround uninitialized variable compiler warnings
+ Some compilers don't understand the semctl API and think it's an input
+ argument even when it's used as an output, and then complains that it
+ is being used uninitialized. Zero it out explicitly to workaround it.
+ This adds some runtime overhead, but should be fairly minor as it's a
+ small stack buffer, and shouldn't be that relevant relative to all the
+ other logic in these functions.
+
+ sim: warnings: enable -Wshift-negative-value
+ Now that all the relevant sources are fixed, enable the warning.
+
+ sim: sh: avoid left shifting negative values
+ We just want to create a bitmask here, so cast the mask to unsigned
+ to avoid left shifting a negative value which is undefined behavior.
+
+ sim: bfin: avoid left shifting negative values
+ We just want to create a bitmask here, so cast the mask to unsigned
+ to avoid left shifting a negative value which is undefined behavior.
+
+2024-01-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: rework DI macros to avoid signed left shifts
+ The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros
+ are used to construct 64-bit values from 32-bit values (for the low
+ and high parts). The MAKEDI macro casts the high 32-bit value to a
+ signed 32-bit value before shifting. If this created a negative
+ value, this would be undefined behavior according to the C standard.
+ All we care about is shifting the 32-bits as they are to the high
+ 32-bits, not caring about sign extension (since there's nothing left
+ to shift into), and the low 32-bits being empty. This is what we
+ get from shifting an unsigned value, so cast it to unsigned 32-bit
+ to avoid undefined behavior.
+
+ While we're here, change the SETLODI macro to truncate the lower
+ value to 32-bits before we set it. If it was passing in a 64-bit
+ value, those high bits would get included too, and that's not what
+ we want.
+
+ Similarly, tweak the SETHIDI macro to cast the value to an unsigned
+ 64-bit instead of a signed 64-bit. If the value was only 32-bits,
+ the behavior would be the same. If it happened to be signed 64-bit,
+ it would trigger the undefined behavior too.
+
+2024-01-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-08 Cupertino Miranda <cupertino.miranda@oracle.com>
+
+ bpf: Added linker support for R_BPF_64_NODYLD32.
+ This patch adds linker support to patch R_BPF_64_NODYLD32 relocations.
+ The implementation was based on comments and code in LLVM, as the GNU
+ toolchain does not uses this relocation type.
+
+2024-01-08 Joseph Myers <josmyers@redhat.com>
+
+ MAINTAINERS: Update my email address
+
+2024-01-08 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/GAS: mips.exp, mark all mipsisa32*-linux as addr32
+ Currently, only mipsisa32-linux and mipsisa32el-linux is marked
+ as addr32, which make mipsisa32rN(el) not marked.
+
+ This change can fix 2 test failures on mipsisa32rN(el)-linux:
+ FAIL: MIPS MIPS64 MIPS-3D ASE instructions (-mips3d flag)
+ FAIL: MIPS MIPS64 MDMX ASE instructions (-mdmx flag)
+
+ These failures don't happen for mipsisa32rN-mti-elf etc,
+ due to that, the output is set as NO_ABI instead of O32, then
+ gas won't warn:
+ `fp=64' used with a 32-bit ABI
+ Maybe, we should change this behaivour in future.
+
+2024-01-08 srinath <srinath.parvathaneni@arm.com>
+
+ arm: Add support for Armv8.9-A and Armv9.4-A
+ This patch adds AArch32 support for -march=armv8.9-a and
+ -march=armv9.4-a. The behaviour of the new options can be
+ expressed using a combination of existing feature flags
+ and tables.
+
+ The cpu_arch_ver entries for ARM_ARCH_V9_4A and ARM_ARCH_V8_9A
+ are technically redundant but it including them for macro code
+ consistency across architectures.
+
+2024-01-08 srinath <srinath.parvathaneni@arm.com>
+
+ aarch64: Add ite feature system registers.
+ This patch adds ite feature (FEAT_ITE) system registers,
+ trcitecr_el1, trcitecr_el12, trcitecr_el2 and trciteedcr.
+
+2024-01-08 Samuel Tardieu <sam@rfc1149.net>
+
+ gas/doc: fix several typos
+
+2024-01-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing -no-prompt-anchor in gdb.base/vfork-follow-parent.exp
+ When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but
+ when running it with "taskset -c 0" I run into:
+ ...
+ (gdb) inferior 1^M
+ [Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M
+ [Switching to thread 1.1 (process 26606)]^M
+ (gdb) Reading symbols from vfork-follow-parent-exit...^M
+ FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \
+ non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout)
+ ...
+
+ Fix this by using -no-prompt-anchor.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/31166
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31166
+
+2024-01-08 Sergey Bugaev <bugaevc@gmail.com>
+
+ Add support for the aarch64-gnu target (GNU/Hurd on AArch64)
+ Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or
+ aarch64-unknown-gnu.
+
+ The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh,
+ or to aarch64linux.sh with Linux-specific logic removed; and mainly different
+ from the generic aarch64elf.sh in that it does not set EMBEDDED=yes.
+
+ Coupled with a corresponding GCC patch, this produces a toolchain that can
+ sucessfully build working binaries targeting aarch64-gnu.
+
+2024-01-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make gdb.base/solib-search.exp more robust
+ On aarch64-linux, with gcc 13.2.1, I run into:
+ ...
+ (gdb) backtrace^M
+ #0 break_here () at solib-search.c:30^M
+ #1 0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M
+ #2 0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M
+ #3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
+ #4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
+ #5 0x00000000004101b4 in main () at solib-search.c:23^M
+ (gdb) PASS: gdb.base/solib-search.exp: \
+ backtrace (with wrong libs) (data collection)
+ FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs)
+ ...
+
+ The FAIL is generated by this code in the test-case:
+ ...
+ if { $expect_fail } {
+ # If the backtrace output is correct the test isn't sufficiently
+ # testing what it should.
+ if { $count == $total_expected } {
+ set fail 1
+ }
+ ...
+
+ The test-case:
+ - builds two versions of two shared libs, a "right" and "wrong" version, the
+ difference being an additional dummy function (called spacer function),
+ - uses the "right" version to generate a core file,
+ - uses the "wrong" version to interpret the core file, and
+ - generates a backtrace.
+
+ The intent is that the backtrace is incorrect due to using the "wrong"
+ version, but actually it's correct. This is because the spacer functions
+ aren't large enough.
+
+ Fix this by increasing the size of the spacer functions by adding a dummy
+ loop, after which we have, as expected, an incorrect backtrace:
+ ...
+ (gdb) backtrace^M
+ #0 break_here () at solib-search.c:30^M
+ #1 0x0000fffff7f201c0 in ?? ()^M
+ #2 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
+ #3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
+ #4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
+ #5 0x00000000004101b4 in main () at solib-search.c:23^M
+ (gdb) PASS: gdb.base/solib-search.exp: \
+ backtrace (with wrong libs) (data collection)
+ PASS: gdb.base/solib-search.exp: backtrace (with wrong libs)
+ ...
+
+ Tested on aarch64-linux.
+
+2024-01-08 Hu, Lin1 <lin1.hu@intel.com>
+
+ i386: Use .insn describe jmpabs's testcases.
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Use .insn instead
+ of .byte to describe test cases.
+
+2024-01-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-07 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Correct adcx suffix in disassembler
+ Since 0x66 is the opcode prefix for adcx, it is wrong to use the 'S'
+ prefix:
+
+ 'S' => print 'w', 'l' or 'q' if suffix_always is true
+
+ on adcx. Add
+
+ 'L' => print 'l' or 'q' if suffix_always is true
+
+ replace S with L on adcx and adox.
+
+ gas/
+
+ PR binutils/31219
+ * testsuite/gas/i386/suffix.d: Updated.
+ * testsuite/gas/i386/x86-64-suffix.d: Likewise.
+ * testsuite/gas/i386/suffix.s: Add tests for adcx and adox.
+ * testsuite/gas/i386/x86-64-suffix.s: Likewise.
+
+ opcodes/
+
+ PR binutils/31219
+ * i386-dis.c: Add the 'L' suffix.
+ (prefix_table): Replace S with L on adcx and adox.
+ (putop): Handle the 'L' suffix.
+
+2024-01-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: enable -Wshadow=local
+ This brings us in sync with current set of gdb warnings (for C).
+
+2024-01-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: change temp var name slightly to avoid shadowing
+ Rename the temp var to avoid shadowing another one:
+
+ .../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local]
+ 11032 | tmp_tmpb = ({ SI tmp_tmpb;
+ | ^~~~~~~~
+ .../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here
+ 11031 | tmp_tmpres = ({ SI tmp_tmpb;
+ | ^~~~~~~~
+
+2024-01-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: add error fallbacks when decoding condition & swap codes
+ The condition & swap code decoder only checks known bits and sets
+ based on that. If the variable is out of range, it ends up returning
+ uninitialized data. Turn that case into a hard error.
+
+ This fixes build warnings like:
+ sim/cris/semcrisv10f-switch.c:13115:11: error:
+ variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
+
+2024-01-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-06 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Adjust x86 and x86-64 tests for -z mark-plt
+ To support -z mark-plt enabled by default, adjust x86 tests to accept
+ non-zero r_addend for JUMP_SLOT relocation and pass -z nomark-plt to
+ x86-64 tests if -z mark-plt changes the expected outputs.
+
+ * testsuite/ld-elf/indirect-extern-access-2.rd: Allow non-zero
+ r_addend for JUMP_SLOT relocation.
+ * testsuite/ld-elf/pr23161d.rd: Likewise.
+ * testsuite/ld-ifunc/ifunc-25c-x86.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-16-x86-64-now.d: Pass -z nomark-plt
+ to linker.
+ * testsuite/ld-ifunc/ifunc-16-x86-64.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-local-x86-64.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-x86-64.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-20-x86-64.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-5b-x86-64.d: Likewise.
+ * testsuite/ld-ifunc/pr17154-x86-64-now.d: Likewise.
+ * testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1a.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1b.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2d.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2e.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2f.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2l.d: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Pass -z nomark-plt to linker
+ in 6 tests.
+
+2024-01-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: fix some typos in code comments
+
+2024-01-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ x86: relax AMD Zen5 testcase expectations
+ One item was too strict for PE/COFF, and there's really no need to check
+ for specific comment contents here.
+
+2024-01-05 Tejas Joshi <TejasSanjay.Joshi@amd.com>
+
+ Add AMD znver5 processor support
+ gas/
+
+ * config/tc-i386.c (cpu_arch): Add znver5 ARCH.
+ * doc/c-i386.texi: Add znver5.
+ * testsuite/gas/i386/arch-15.d: New.
+ * testsuite/gas/i386/arch-15.s: Likewise.
+ * testsuite/gas/i386/arch-15-znver5.d: Likewise.
+ * testsuite/gas/i386/i386.exp: Add new znver5 test cases.
+ * testsuite/gas/i386/x86-64.exp: Likewise.
+ * testsuite/gas/i386/x86-64-arch-5.d: Likewise.
+ * testsuite/gas/i386/x86-64-arch-5.s: Likewise.
+ * testsuite/gas/i386/x86-64-arch-5-znver5.d: Likewise.
+
+ opcodes/
+
+ * i386-gen.c (isa_dependencies): Add ZNVER5 dependencies.
+ * i386-init.h: Re-generated.
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ Arm/doc: separate @code from @item for older makeinfo
+ At least 4.12 doesn't like the constructs without a separator.
+
+ x86: corrections to CPU attribute/flags splitting
+ There are a number of issues with 734dfd1cc966 ("x86: pack CPU flags in
+ opcode table"):
+ - the condition when two array slots need writing wasn't correct (with
+ enough new Cpu* added an out of bounds array access would validly have
+ been complained about by the compiler),
+ - table generation didn't take into account CpuAttrUnused and CpuUnused
+ being independent, and hence there not always (not) being an "unused"
+ bitfield member in both structures,
+ - cpu_flags_from_attr() wasn't ready for use on big-endian hosts,
+ - there were two style violations.
+
+ ELF: test certain .text/.data usages
+ Various targets have / had overrides for .text and/or .data. Make sure
+ that in such cases sub-section specifiers are accepted, as mandated by
+ the doc.
+
+ ELF: test certain .bss usages
+ Various targets have / had overrides for .bss. Make sure that in such
+ cases
+ - .previous still works correctly (requiring such targets to invoke
+ obj_elf_section_change_hook() from their overriding handlers),
+ - sub-section specifiers are accepted as far as feasible (mandated by
+ the doc).
+
+ gas: correct .bss documentation for non-ELF
+ Only ELF permits the specification of a subsection, and even there not
+ consistently: csky, mcore, and spu handle .bss similar to .lcomm.
+
+ z80: drop .bss override
+ It doesn't look to be a good idea to override the custom handlers that
+ ELF and COFF have; afaict doing so broke .previous on ELF, and a sub-
+ section specifier wasn't accepted either.
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ visium: drop .bss and .skip overrides
+ The comment in s_bss() looks bogus (perhaps simply stale, or wrongly
+ copied from another target). It also doesn't look to be a good idea to
+ override the custom handler that ELF has (afaict doing so broke
+ .previous as well as sub-section specification).
+
+ The override for .skip is simply pointless, for read.c having exactly
+ the same.
+
+ While there also drop two adjacent redundant (with read.h) declarations
+ (which would be outright dangerous if read.h wasn't included anyway).
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ v850: drop .bss override
+ While there doesn't look to be anything wrong with this override,
+ there's also no apparent reason why this override would be needed. Drop
+ it, reducing overall size a tiny bit.
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ score: drop .bss override
+ The comment looks bogus (perhaps simply stale, or wrongly copied from
+ another target). It also doesn't look to be a good idea to override the
+ custom handler that ELF has (afaict doing so broke .previous as well as
+ sub-section specification).
+
+ While there also fold the identical handlers for .text (there likely is
+ more room for such folding).
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ s390: drop .bss override
+ The comment looks bogus (perhaps simply stale), and there are also no
+ other precautions against subsections being used on ELF with .bss. It
+ also doesn't look to be a good idea to override the custom handler that
+ ELF has (afaict doing so further broke .previous).
+
+ rx: drop .bss override
+ It doesn't look to be a good idea to override the custom handler that
+ ELF has; afaict doing so broke .previous.
+
+ rl78: drop .bss override
+ It doesn't look to be a good idea to override the custom handler that
+ ELF has; afaict doing so broke .previous.
+
+ pru: fix .text/.data interaction with .previous
+ Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
+ need calling for .text/.data.
+
+ microblaze: drop/restrict override of .text, .data, and .bss
+ While only ELF is supported right now, (stub) code generally is in place
+ for the non-ELF case as well. Don't override .bss for ELF - that's
+ unlikely to be a good idea anyway and prevented the sub-section
+ specifier from being usable. Don't override .text and .data at all - for
+ .data and ELF for the same reason, while for .text and ELF obj-elf.c's is
+ all we need, and for (hypothetical) non-ELF read.c's identical handling
+ would have been invoked anyway.
+
+ m68k: drop .bss override
+ The comment looks bogus (perhaps simply stale), and there are also no
+ other precautions against subsections being used on ELF with .bss. It
+ also doesn't look to be a good idea to override the custom handler that
+ ELF has (afaict doing so further broke .previous).
+
+ m32c: drop .bss override
+ It doesn't look to be a good idea to override the custom handler that
+ ELF has; afaict doing so broke .previous.
+
+ IA64: drop .bss override
+ It doesn't look to be a good idea to override the custom handlers that
+ ELF and COFF have. While in this case interaction with ELF's .previous
+ wasn't screwed, the sub-section specifier wasn't permitted.
+
+ d30v: fix .text/.data interaction with .previous
+ Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
+ need calling for .text/.data.
+
+ bfin: drop .bss override
+ It doesn't look to be a good idea to override the custom handler that
+ ELF has; afaict doing so broke .previous.
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: drop .bss override
+ The comment looks bogus (perhaps simply stale, perhaps wrongly copied
+ from Arm in the first place), and there are also no other precautions
+ against subsections being used on ELF with .bss. It also doesn't look
+ to be a good idea to override the custom handlers that ELF and COFF
+ have (afaict doing so further broke .previous on ELF).
+
+ As to the mapping state update - such also doesn't appear to be done
+ for other section switching, so its original purpose was at best
+ questionable as well.
+
+2024-01-05 Jan Beulich <jbeulich@suse.com>
+
+ Arm: drop .bss override
+ The comment looks bogus (perhaps simply stale), and there are also no
+ other precautions against subsections being used on ELF with .bss. It
+ also doesn't look to be a good idea to override the custom handlers that
+ ELF and COFF have (afaict doing so further broke .previous on ELF).
+
+2024-01-05 Tamar Christina <tamar.christina@arm.com>
+
+ Enforce C++11 as a minimum for building gold [PR30867]
+ The attempt in 5e9091dab885 to correct gold for modern LLVM has broken
+ gold for older compilers. This commit introduced C++11 types without
+ changing the build system to require a C++ compiler. More importantly
+ it depends on the compiler having at least C++11 as the default
+ language. Older compilers which support C++11 but not as the default
+ language needlessly break. Fix that.
+
+ PR gold/30867
+ * configure.ac (AX_CXX_COMPILE_STDCXX): Require C++11.
+ * Makefile.in: Regenerate.
+ * aclocal.m4: Regenerate.
+ * config.in: Regenerate.
+ * configure: Regenerate.
+ * testsuite/Makefile.in: Regenerate.
+
+2024-01-05 Alan Modra <amodra@gmail.com>
+
+ loongarch: 'index' shadows global
+ Avoid an error when compiling with older versions of gcc.
+
+ * elfnn-loongarch.c (loongarch_relax_align): Rename "index" to
+ "sym_index".
+
+2024-01-05 Alan Modra <amodra@gmail.com>
+
+ Tidy bfd_scan_vma
+ In commit 83c79df86bf4 I removed configure tests for strtoull among
+ other library functions part of C99, but didn't remove what is now
+ dead code.
+
+ * bfd.c (bfd_scan_vma): Delete fall-back for strtoull.
+
+2024-01-05 Alan Modra <amodra@gmail.com>
+
+ PR31120, ld-scripts/fill2 fails when bfd_vma is 32 bits
+ The ld lexer converts strings to integers without overflow checking,
+ so I don't think there is any problem in truncating an integer that
+ exceeds the size of a bfd_vma rather than using (bfd_vma) -1.
+
+ PR 31120
+ * ldlex.l: Don't use bfd_scan_vma for integer conversion, use
+ strtoull.
+
+2024-01-05 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: T-HEAD: Fix wrong instruction encoding for th.vsetvli
+ Since the particularity of "th.vsetvli" was not taken into account in the
+ initial support patches for XTheadVector, the program operation failed
+ due to instruction coding errors. According to T-Head SPEC ([1]), the
+ "vsetvl" in the XTheadVector extension consists of SEW, LMUL and EDIV,
+ which is quite different from the "V" extension. Therefore, we cannot
+ simply reuse the processing of vsetvl in V extension.
+
+ We have set up tens of thousands of test cases to ensure that no
+ further encoding issues are there, and and execute all compiled test
+ files on real HW and make sure they don't trigger SIGILL.
+
+ Ref:
+ [1] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Add handling for
+ th.vsetvli.
+ (my_getThVsetvliExpression): New function.
+ (riscv_ip): Likewise.
+ * testsuite/gas/riscv/x-thead-vector.d: Likewise.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (OP_MASK_XTHEADVLMUL): New macro.
+ (OP_SH_XTHEADVLMUL): Likewise.
+ (OP_MASK_XTHEADVSEW): Likewise.
+ (OP_SH_XTHEADVSEW): Likewise.
+ (OP_MASK_XTHEADVEDIV): Likewise.
+ (OP_SH_XTHEADVEDIV): Likewise.
+ (OP_MASK_XTHEADVTYPE_RES): Likewise.
+ (OP_SH_XTHEADVTYPE_RES): Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Likewise.
+ * riscv-opc.c: Likewise.
+
+2024-01-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle PAC marker
+ On aarch64-linux, I run into:
+ ...
+ FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
+ ...
+ due to the PAC marker showing up:
+ ...
+ ^Z^Zframe-address^M
+ 0x000000000041025c [PAC]^M
+ ^Z^Zframe-address-end^M
+ ...
+
+ In the docs the marker is documented as follows:
+ ...
+ When GDB is debugging the AArch64 architecture, and the program is using the
+ v8.3-A feature Pointer Authentication (PAC), then whenever the link register
+ $lr is pointing to an PAC function its value will be masked. When GDB prints
+ a backtrace, any addresses that required unmasking will be postfixed with the
+ marker [PAC]. When using the MI, this is printed as part of the addr_flags
+ field.
+ ...
+
+ Update the test-case to allow the PAC marker.
+
+ Likewise in a few other test-cases.
+
+ While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
+ a more readable form. Likewise for the corresponding pat_end.
+
+ Tested on aarch64-linux.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ PR testsuite/31202
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202
+
+2024-01-04 Alan Modra <amodra@gmail.com>
+
+ Update year range in copyright notice of binutils files
+ Adds two new external authors to etc/update-copyright.py to cover
+ bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
+ updates copyright messages as follows:
+
+ 1) Update cgen/utils.scm emitted copyrights.
+ 2) Run "etc/update-copyright.py --this-year" with an extra external
+ author I haven't committed, 'Kalray SA.', to cover gas testsuite
+ files (which should have their copyright message removed).
+ 3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
+ 4) Check out */po/*.pot which we don't update frequently.
+
+2024-01-04 Nick Clifton <nickc@redhat.com>
+
+ Synchronize config.sub and config.guess with their upstream master versions.
+ Brings in:
+ commit 28ea239c53a2d5d8800c472bc2452eaa16e37af2 config.sub: Remove windows-gnu
+ commit a6976af01b0c6206561782183a0db42124b19f7b config.sub: recognise ARM64EC machine type
+ commit 4e60c54be77f743ff8018ab58fb36fd8bc055e2a config.sub: allow aarch64c-unknown-freebsd
+ commit e4786449e1c26716e3f9ea182caf472e4dbc96e0 config.guess: invoke "uname -p" from PATH for non-arm FreeBSD
+ commit 021155df7fad97a5ae1baa354e15a03ea14500b4 config.guess: Detect Android (as opposed to GNU/Linux)
+ commit 6c78704d542cebfb56d17474fe9f8395e9defb94 config.sub: add javascript-*-ghcjs
+ commit 2a7c4b64d4aec5c3a8a975625f0f8c369d365667 testsuite: add coverage for vendor-clobbering
+ commit 39c49ea712cba8ae6613ef85ab22fe7c552b48b0 config.sub: Systematize parsing of machine code formats
+ commit d4e37b5868ef910e3e52744c34408084bb13051c config.sub: Handle arbitrary MIPS CPU names
+ commit af8d803a82436779d35ea389888788c78677804e config.guess (aarch64:Linux:*:*): Detect 32-bit ABI
+ commit 602766470c886df7ae07bcfd7dcf532f0783d3e0 Add KVX MPPA detection
+ commit be68d790b6bc7dd84982fa6760f1448e92849e63 config.sub: Add Apple tvOS and watchOS
+ commit 998ba1414387b4ce1a519be234e1609bc7912e0c config.sub: Accept $cpu-$vendor-none-{coff,elf}
+
+2024-01-04 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix linker generate PLT entry for data symbol
+ With old "medium" code model, we call a function with a pair of PCALAU12I
+ and JIRL instructions. The assembler produces something like:
+
+ 8: 1a00000c pcalau12i $t0, 0
+ 8: R_LARCH_PCALA_HI20 g
+ c: 4c000181 jirl $ra, $t0, 0
+ c: R_LARCH_PCALA_LO12 g
+
+ The linker generates a "PLT entry" for data without any diagnostic.
+ If "g" is a data symbol and ld with -shared option, it may load two
+ instructions in the PLT.
+
+ Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT
+ entry.
+
+ For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC
+ and STT_GNU_IFUNC symbols.
+
+2024-01-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: improve error reporting from expression parser
+ This commits changes how errors are reported from the expression
+ parser. Previously, parser errors were reported like this:
+
+ (gdb) p a1 +}= 432
+ A syntax error in expression, near `}= 432'.
+ (gdb) p a1 +
+ A syntax error in expression, near `'.
+
+ The first case is fine, a user can figure out what's going wrong, but
+ the second case is a little confusing; as the error occurred at the
+ end of the expression GDB just reports the empty string to the user.
+
+ After this commit the first case is unchanged, but the second case now
+ reports like this:
+
+ (gdb) p a1 +
+ A syntax error in expression, near the end of `a1 +'.
+
+ Which I think is clearer. There is a possible issue if the expression
+ being parsed is very long, GDB will repeat the whole expression. But
+ this issue already exists in the standard case; if the error occurs
+ early in a long expression GDB will repeat everything after the syntax
+ error. So I've not worried about this case in my new code either,
+ which keeps things simpler.
+
+ I did consider trying to have multi-line errors here, in the style
+ that gcc produces, with some kind of '~~~~~^' marker on the second
+ line to indicate where the error occurred; but I rejected this due to
+ the places in GDB where we catch an error and repackage the message
+ within some longer string, I don't think multi-line error messages
+ would work well in that case. At a minimum it would require some
+ significant work in order to make all our error handling multi-line
+ aware.
+
+ I've added a couple of extra tests in gdb.base/exprs.exp.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-01-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: merge error handling from different expression parsers
+ Many (all?) of the expression parsers implement yyerror to handle
+ parser errors, and all of these functions are basically identical.
+
+ This commit adds a new parser_state::parse_error() function, which
+ implements the common error handling code, this function can then be
+ called from all the different yyerror functions.
+
+ The benefit of this is that (in a future commit) I can improve the
+ error output, and all the expression parsers will benefit.
+
+ This commit is pure refactoring though, and so, there should be no
+ user visible changes after this commit.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-01-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't try to style content in error calls
+ While working on a later commit in this series I realised that the
+ error() function doesn't support output styling. Due to the way that
+ output from error() calls is passed around within the exception
+ object and often combined with other output, it's not immediately
+ obvious to me if we should be trying to support styling in this
+ context or not.
+
+ On inspection, I found one place in GDB where we apparently try to
+ apply styling within the error() output (in procfs.c). I suspect this
+ error() call might not be tested.
+
+ Rather than try to implement styling in the error() output, right now
+ I'm proposing to just remove the attempt to style error() output.
+
+ This doesn't mean that someone shouldn't add error() styling in the
+ future, but right now, I'm not planning to do that, I just wanted to
+ fix this in passing.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2024-01-04 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Fix loongarch*-elf target ld testsuite failure
+ The loongarch*-elf target does not support SHARED and PIE, so this
+ target is skipped for some tests that require these options.
+
+2024-01-04 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Fix some macro that cannot be expanded properly
+ Suppose we want to use la.got to generate 32 pcrel and
+ 32 abs instruction sequences respectively. According to
+ the existing conditions, to generate 32 pcrel sequences
+ use -mabi=ilp32*, and to generate 32 abs use -mabi=ilp32*
+ and -mla-global-with-abs.
+
+ Due to the fact that the conditions for generating 32 abs
+ also satisfy 32 pcrel, using -mabi=ilp32* and -mla-global-with-abs
+ will result in only generating instruction sequences of 32 pcrel.
+
+ By modifying the conditions for macro expansion and adjusting
+ the matching order of macro instructions, it is ensured that
+ the correct sequence of instructions can be generated.
+
+2024-01-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: unify igen filter modules
+ The common igen code was forked from the ppc long ago. The filter
+ module is still pretty similar in API, so we can unfork them with
+ a little bit of effort.
+
+ The filter.c module is still here because of the unique it_is API.
+ The common igen code doesn't seem to have an equiv API as this only
+ operates on two strings and not an actual filter object, and it's
+ easy enough to leave behind to unfork the rest.
+
+2024-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: unify igen line number output modules
+ The common igen code was forked from the ppc long ago. The lf module
+ is still pretty similar in API, so we can unfork them with a little
+ bit of effort.
+
+ Some of the generated ppc code is now slightly different, but that's
+ because of fixes the common igen code has gained, but not the ppc igen
+ code (e.g. fixing of #line numbers).
+
+ The ppc code retains lf_print__c_code because the common igen code
+ rewrote the logic to a new table.c API. Let's delay that in the ppc
+ code to at least unfork all this code.
+
+2024-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: igen: clean up headers a bit
+ Add standard multiple inclusion protection, and add a few missing
+ local includes when one header uses another. This isn't complete,
+ but fixes some short comings seen when merging the ppc igen.
+
+ sim: ppc: switch to common endian code
+ The common sim-endian is a forked & updated version of the ppc code.
+ Fortunately, they didn't diverge from the basic APIs, so they are
+ still compatible, which means we can just delete the ppc version now
+ that the build env is merged at the top-level.
+
+ sim: common: include sim-types.h in the endian header directly
+ This is a bit redundant for most ports as they go through sim-basics.h
+ which always includes sim-types.h before including sim-endian.h, but in
+ order to unify ppc's sim-endian code, we need this include here. Plus,
+ it's the directly we generally want to go to get away from one header
+ that defines all APIs and causes hard to untangle dependencies.
+
+ sim: ppc: rename local ALU SIGNED64 macros
+ The common/ code has macros with the same name but different behavior:
+ it's for declaring integer constants as 64-bit, not for casting them.
+ Rename ppc's local variant since it's only used in this file in order
+ to avoid conflicts.
+
+ sim: ppc: sync WITH_TARGET_{ADDRESS,CELL}_BITSIZE with common/
+ This will make it easier to share common/ code that rely on these
+ additional defines.
+
+ sim: cr16: cleanup unused variable compiler warnings
+
+ sim: configure: switch to m4_map
+ Minor reduction in boilerplate here. No real functional changes.
+
+ sim: drop support for recursive makes entirely
+ Now that all ports have been merged to the top-level, we no longer need
+ this framework to pass settings down to sub-makefiles. Delete it all.
+
+ sim: ppc: hoist compilation up to top-level
+ This removes all recursive makes from the ppc port.
+
+ sim: drop support for automatic subdir recursion
+ No port relies on this anymore, so we can scrub it all.
+
+2024-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. It adds some overhead, so it's not great, but it shouldn't
+ be a big deal. This will go away once compilation is hoisted up.
+
+2024-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: move main.o compilation to top-level
+
+2024-01-03 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: delete bfd/.elfnn-loongarch.c.swp
+
+2024-01-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-02 Carl Love <cel@linux.ibm.com>
+
+ Fix GDB reverse-step and reverse-next command behavior
+ Currently GDB when executing in reverse over multiple statements in a single
+ line of source code, GDB stops in the middle of the line. Thus requiring
+ multiple commands to reach the previous line. GDB should stop at the first
+ instruction of the line, not in the middle of the line.
+
+ The following description of the incorrect behavior was taken from an
+ earlier message by Pedro Alves <pedro@palves.net>:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html
+
+ ---------------------------------
+
+ The source line looks like:
+
+ func1 (); func2 ();
+
+ in the test case:
+
+ (gdb) list 1
+ 1 void func1 ()
+ 2 {
+ 3 }
+ 4
+ 5 void func2 ()
+ 6 {
+ 7 }
+ 8
+ 9 int main ()
+ 10 {
+ 11 func1 (); func2 ();
+ 12 }
+
+ compiled with:
+
+ $ gcc reverse.c -o reverse -g3 -O0
+ $ gcc -v
+ ...
+ gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
+
+ Now let's debug it with target record, using current gdb git master
+ (f3d8ae90b236),
+
+ $ gdb ~/reverse
+ GNU gdb (GDB) 14.0.50.20230124-git
+ ...
+ Reading symbols from /home/pedro/reverse...
+ (gdb) start
+ Temporary breakpoint 1 at 0x1147: file reverse.c, line 11.
+ Starting program: /home/pedro/reverse
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ Temporary breakpoint 1, main () at reverse.c:11
+ 11 func1 (); func2 ();
+ (gdb) record
+
+ (gdb) disassemble /s
+ Dump of assembler code for function main:
+ reverse.c:
+ 10 {
+ 0x000055555555513f <+0>: endbr64
+ 0x0000555555555143 <+4>: push %rbp
+ 0x0000555555555144 <+5>: mov %rsp,%rbp
+
+ 11 func1 (); func2 ();
+ => 0x0000555555555147 <+8>: mov $0x0,%eax
+ 0x000055555555514c <+13>: call 0x555555555129 <func1>
+ 0x0000555555555151 <+18>: mov $0x0,%eax
+ 0x0000555555555156 <+23>: call 0x555555555134 <func2>
+ 0x000055555555515b <+28>: mov $0x0,%eax
+
+ 12 }
+ 0x0000555555555160 <+33>: pop %rbp
+ 0x0000555555555161 <+34>: ret
+ End of assembler dump.
+
+ (gdb) n
+ 12 }
+
+ So far so good, a "next" stepped over the whole of line 11 and stopped at
+ line 12.
+
+ Let's confirm where we are now:
+
+ (gdb) disassemble /s
+ Dump of assembler code for function main:
+ reverse.c:
+ 10 {
+ 0x000055555555513f <+0>: endbr64
+ 0x0000555555555143 <+4>: push %rbp
+ 0x0000555555555144 <+5>: mov %rsp,%rbp
+
+ 11 func1 (); func2 ();
+ 0x0000555555555147 <+8>: mov $0x0,%eax
+ 0x000055555555514c <+13>: call 0x555555555129 <func1>
+ 0x0000555555555151 <+18>: mov $0x0,%eax
+ 0x0000555555555156 <+23>: call 0x555555555134 <func2>
+ 0x000055555555515b <+28>: mov $0x0,%eax
+
+ 12 }
+ => 0x0000555555555160 <+33>: pop %rbp
+ 0x0000555555555161 <+34>: ret
+ End of assembler dump.
+
+ Good, we're at the first instruction of line 12.
+
+ Now let's undo the "next", with "reverse-next":
+
+ (gdb) reverse-next
+ 11 func1 (); func2 ();
+
+ Seemingly stopped at line 11. Let's see exactly where:
+
+ (gdb) disassemble /s
+ Dump of assembler code for function main:
+ reverse.c:
+ 10 {
+ 0x000055555555513f <+0>: endbr64
+ 0x0000555555555143 <+4>: push %rbp
+ 0x0000555555555144 <+5>: mov %rsp,%rbp
+
+ 11 func1 (); func2 ();
+ 0x0000555555555147 <+8>: mov $0x0,%eax
+ 0x000055555555514c <+13>: call 0x555555555129 <func1>
+ => 0x0000555555555151 <+18>: mov $0x0,%eax
+ 0x0000555555555156 <+23>: call 0x555555555134 <func2>
+ 0x000055555555515b <+28>: mov $0x0,%eax
+
+ 12 }
+ 0x0000555555555160 <+33>: pop %rbp
+ 0x0000555555555161 <+34>: ret
+ End of assembler dump.
+ (gdb)
+
+ And lo, we stopped in the middle of line 11! That is a bug, we should have
+ stepped back all the way to the beginning of the line. The "reverse-next"
+ should have fully undone the prior "next" command.
+
+ --------------------
+
+ This patch fixes the incorrect GDB behavior by ensuring that GDB stops at
+ the first instruction in the line.
+
+ The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite
+ to verify this fix when the line table information is and is not available.
+
+2024-01-02 Carl Love <cel@linux.ibm.com>
+
+ PowerPC and aarch64: Fix reverse stepping failure
+ When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
+ the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
+ gdb.reverse/solib-reverse.exp.
+
+ The failure happens around the following code:
+
+ 38 b[1] = shr2(17); /* middle part two */
+ 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */
+ 42 shr1 ("message 1\n"); /* shr1 one */
+
+ Normal execution:
+
+ - step from line 38 will land on line 40.
+ - step from line 40 will land on line 42.
+
+ Reverse execution:
+ - step from line 42 will land on line 40.
+ - step from line 40 will land on line 40.
+ - step from line 40 will land on line 38.
+
+ The problem here is that line 40 contains two contiguous but distinct
+ PC ranges in the line table, like so:
+
+ Line 40 - [0x7ec ~ 0x7f4]
+ Line 40 - [0x7f4 ~ 0x7fc]
+
+ The two distinct ranges are generated because GCC started outputting source
+ column information, which GDB doesn't take into account at the moment.
+
+ When stepping forward from line 40, we skip both of these ranges and land on
+ line 42. When stepping backward from line 42, we stop at the start PC of the
+ second (or first, going backwards) range of line 40.
+
+ Since we've reached ecs->event_thread->control.step_range_start, we stop
+ stepping backwards.
+
+ The above issues were fixed by introducing a new function that looks for
+ adjacent PC ranges for the same line, until we notice a line change. Then
+ we take that as the start PC of the range. The new start PC for the range
+ is used for the control.step_range_start when setting up a step range.
+
+ The test case gdb.reverse/map-to-same-line.exp is added to test the fix
+ for the above reverse step issues.
+
+ Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
+
+2024-01-02 Carl Love <cel@us.ibm.com>
+
+ Add gdb_compile options column-info and no-column-info
+ This patch adds two new options to gdb_compile to specify if the compile
+ should or should not generate the line table information. The
+ options are supported on clang and gcc version 7 and newer.
+
+ Patch has been tested on PowerPC with both gcc and clang.
+
+2024-01-02 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table
+ This commit adds a mechanism for GDB to detect the linetable opcode
+ DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
+ that a certain instruction marks the point where the frame is destroyed.
+
+ While the standard allows for multiple points marked with epilogue_begin
+ in the same function, for performance reasons, the function that
+ searches for the epilogue address will only find the last address that
+ sets this flag for a given block.
+
+ This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
+ use the epilogue begin directly, and only if an epilogue can't be found
+ will it attempt heuristics based on the current instruction.
+
+ Finally, this commit also changes the dwarf assembler to be able to emit
+ epilogue-begin instructions, to make it easier to test this patch
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2024-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: hoist pk.h creation to top-level
+
+ sim: ppc: hoist hw.[ch] creation to top-level
+
+ sim: ppc: hoist igen execution to top-level
+ Invoke ppc's igen from the top-level like we do for all other ports.
+
+ sim: ppc: merge configure logic into top-level
+ Now that the ppc configure script is just namespaced options, we can
+ move it to ppc/acinclude.m4 and include it directly in the top-level
+ configure script and kill off the last subdir configure script.
+
+ sim: ppc: scope configure options to --enable-sim-ppc-xxx
+ To prepare for moving these into the top-level configure, namespace
+ then with the port name like we do with all other ports.
+
+ sim: ppc: standardize configure option processing
+ Switch from ad-hoc $silent checks & echo calls to standard
+ AC_MSG_CHECKING & AC_MSG_RESULT calls. Also delete pointless
+ variable setting after calling AC_MSG_ERROR.
+
+ sim: ppc: switch to AS_HELP_STRING for automatic formatting
+
+ sim: ppc: drop now unused config.in
+
+ sim: ppc: move defines.h generation to the top-level
+ Since we rely on the top-level config.h now, the defines.h generation
+ step should live here too.
+
+ sim: ppc: drop configure compiler checks
+ Now that the ppc script only checks configure options and sets up
+ variables in the Makefile from those, delete all the compile related
+ logic to greatly simplify the configure script.
+
+ sim: ppc: drop custom config.h header
+ Now that everything has moved to the top-level, we can drop the
+ custom ppc config.h and reuse the common one.
+
+ sim: ppc: stop including headers from gdb/
+ The common sim code doesn't snoop in gdb/, and the ppc code doesn't
+ need to either. Any common code we pull from gnulib/ now only.
+
+ sim: ppc: move termios probes to top-level
+ This is the last compile-time logic in the ppc subdir.
+
+ sim: ppc: switch to AC_CACHE_CHECK
+ This macro replaces the AC_MSG_CHECKING+AC_CACHE_VAL+AC_MSG_RESULT
+ which reduces the boilerplate in here a little bit.
+
+ sim: ppc: switch struct member checks to AC_CHECK_MEMBER
+ This covers a lot of the AC_MSG_CHECKING+AC_TRY_COMPILE+AC_MSG_RESULT
+ boilerplate and matches what we do in the top-level platform checks.
+
+ sim: ppc: move termio defines to config.h
+ Move the defines from explicit -D options to config.h defines to simplify
+ the build and make it easier to move to the top-level configure.
+
+ sim: ppc: move struct statfs to top-level
+
+ sim: ppc: move long long test to top-level
+ While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
+ (like libiberty) seem to, so check for it in the top-level for all
+ ports to leverage.
+
+ sim: ppc: hoist sysv tests to top-level
+ Now that the sysv tests turn into config.h defines and everything
+ checks that, we can move the tests to the top-level and out of the
+ ppc subdir.
+
+2024-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: always compile in the sysv sem & shm device files
+ Move the stub logic to the device files themselves. This makes the
+ configure & build logic more static which will make it easier to move
+ to the top-level build, and matches what we did with the common/ hw
+ tree already.
+
+ This also decouples the logic from the two -- in the past, you needed
+ both sem & shm in order to enable the device models, but now each one
+ is tied to its own independent knob. Practically speaking, this will
+ probably not make a difference, but it simplifies the build a bit.
+
+2024-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: change SysV sem & shm tests to compile-time
+ Instead of executing code to see if SysV semaphores & shared memory
+ are available, switch to just a compile-time test. The system used
+ to compile might not match the system used to run the code wrt the
+ current kernel & OS settings, but the library APIs should. So move
+ the failures from compile-time to runtime so the program is more
+ portable, and works correctly even when cross-compiling.
+
+2024-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: merge System V semaphores checks
+ Compile tests can use earlier defines, so hoist the HAVE_UNION_SEMUN
+ define to before the semaphore check, and use it in the test so that
+ we can merge the 2 versions into one.
+
+ This also defines HAVE_UNION_SEMUN even when ac_cv_sysv_sem is not
+ set, but that's OK as this define is only about a type existing, not
+ about whether the overall code is usable.
+
+2024-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: fix bad AC_CACHE_CHECK call with semun
+ The first arg is the cache var name, and this one was typoed relative
+ to what the call actually set. We also don't need the manual call to
+ AC_MSG_RESULT as the AC_CACHE_CHECK takes care of it for us.
+
+ sim: ppc: delete unused build compile & link settings
+ These should have been removed as part of the ppc/igen merging into the
+ top-level, but they were missed. Clean up now.
+
+2024-01-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2024-01-01 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: merge misc igen APIs
+ The common igen code provides the same misc APIs as the ppc version,
+ so delete the ppc code and pull in the common one. There is one
+ minor difference: the ppc code has a unique dumpf function. The
+ common code switched to lf_printf for the same functionality, but
+ since that requires changes throughout the igen codebase, delay that
+ cleanup for now so we can merge the rest.
+
+ sim: ppc: rework igen error to match common
+ Switch to an ERROR macro and tweak the error signature to match the
+ common igen version in preparation for merging the two implementations.
+
+ sim: igen: extend error to take arguments
+ The ppc igen error helper allows arbitrary printf calls, so extend
+ the common one to do the same.
+
+ sim: ppc: rename igen max_insn_bit_size
+ We want to avoid conflicts with the common igen enums. This should
+ get migrated over to the common parsing logic, but for now, switch
+ the name to avoid redefinition.
+
+ sim: igen: minor constify logic
+ Copy some improvements from the ppc igen code.
+
+ sim: ppc: unify igen filter_filename implementations
+ Now that both igen implementations are in the top-level, we can unify
+ the filter_filename implementation between them since they're the same
+ (literally the same code).
+
+ sim: ppc: replace filter_filename with lbasename
+ The lbasename function from libiberty provides the same API as this
+ custom function. The common/ code already made the switch, so make
+ the same change to the ppc code to avoid target duplication.
+
+ sim: ppc: hoist igen compilation into top-level
+ This simplifies the build a bit (especially for deps in port subdirs),
+ and avoids recursive make. This in turn speeds up the build, and lets
+ us reuse existing build-time vs host-time logic from Makefile.am.
+
+ sim: ppc: drop build-config.h usage
+ This header is only used by the igen tool, and none of the igen code
+ depends on the configure-time checks. Delete the logic to simplify
+ to prepare for moving it to the local.mk code.
+
+ sim: ppc: simplify filter_host.c logic
+ Switch this from a build-time generation to a static include. This
+ makes the build rules a bit simpler, especially as we move them to
+ Automake from hand-written makefiles.
+
+ sim: igen: remove libigen.a when cleaning
+
+ sim: ppc: drop unused host bitsize settings
+ This is never set anywhere, so it's always empty. Scrub it.
+
+ sim: frv: fix cmpb uninitialized variable usage
+ This code sets up the cc variable based on the comparison of other
+ registers, but it does so incrementally with bit operations, and it
+ never initializes the cc variable. Initialize it to 0 which the
+ cmpba insn is already doing.
+
+ sim: arm: mark local read-only arrays as static const
+ Move it into read-only data sections to avoid constructing them on the
+ stack at runtime.
+
+ sim: warnings: enable -Wunused-variable
+
+ cpu: or1k: drop unused l.swa flag
+ The "flag" argument isn't set/used in this insn, so drop it.
+ This fixes an unused variable warning in the generated sim.
+
+2024-01-01 Tom Tromey <tom@tromey.com>
+
+ sim: fix pervasive typo
+ I noticed a typo in a sim constant. This patch fixes it.
+ permenant -> permanent
+
+2024-01-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-31 Tom Tromey <tom@tromey.com>
+
+ Run 'black' on tui-window.py
+ Mark pointed out that a recent patch of mine caused the buildbot to
+ complain about the formatting of some Python test code. This patch
+ re-runs 'black' to fix the problem.
+
+2023-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix typo in gdb.base/catch-syscall.exp
+ On aarch64-linux with a gdb build without libexpat, I run into:
+ ...
+ (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+ catch syscall 59
+ continue
+ Continuing.
+
+ Catchpoint 5 (call to syscall 59), 0x0000fffff7e04578 in pipe () from \
+ /lib64/libc.so.6
+ (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
+ ...
+
+ In the test-case, this pattern handles either the syscall name or number for
+ the pipe syscall:
+ ...
+ -re -wrap "Catchpoint $decimal \\(call to syscall (pipe|$SYS_pipe)\\).*" {
+ ...
+ but the pattern for the pipe2 syscall mistakenly uses SYS_pipe instead of
+ SYS_pipe2:
+ ...
+ -re -wrap "Catchpoint $decimal \\(call to syscall (pipe2|$SYS_pipe)\\).*" {
+ ...
+ and consequently doesn't handle the pipe2 syscall number.
+
+ Fix the typo by using SYS_pipe2 instead.
+
+ Tested on aarch64-linux.
+
+2023-12-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-30 Tom Tromey <tom@tromey.com>
+
+ Add keywords to TuiWindow.write
+ The gdb docs promise that methods with more than two or more arguments
+ will accept keywords. However, I found that TuiWindow.write didn't
+ allow them. This patch adds the missing support.
+
+2023-12-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/gdb-index-err.exp for root user
+ When running test-case gdb.base/gdb-index-err.exp in a container as root user,
+ I run into:
+ ...
+ FAIL: gdb.base/gdb-index-err.exp: flag=: \
+ try to write index to a non-writable directory
+ FAIL: gdb.base/gdb-index-err.exp: flag=-dwarf-5: \
+ try to write index to a non-writable directory
+ ...
+
+ The test-case creates a directory without write permissions:
+ ...
+ $ ls -ald private
+ dr-xr-xr-x 2 root root 4096 Dec 29 06:26 private/
+ ...
+ but apparently the root user is still able to write in it.
+
+ Fix this by making the test unsupported for the root user.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+ PR testsuite/31197
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31197
+
+2023-12-30 Alan Modra <amodra@gmail.com>
+
+ LoongArch: Commas inside double quotes
+ This adds an extra feature: Commas inside double quotes are not an
+ arg delimiter, and thus can be part of the arg.
+
+ * loongarch-coder.c (loongarch_split_args_by_comma): Commas
+ inside quotes are not arg delimiters.
+
+2023-12-30 Alan Modra <amodra@gmail.com>
+
+ Regen bfd-in2.h
+ Please DON'T edit this file. READ THE COMMENT!
+
+2023-12-30 Joseph Myers <jsm@polyomino.org.uk>
+
+ MAINTAINERS: Update my email address
+ There will be another update in January.
+
+2023-12-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-29 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Append "#pass" to APX tests
+ Append "#pass" to APX tests for targets which pad text sections with NOPs.
+
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Append
+ "#pass".
+ * testsuite/gas/i386/x86-64-apx-ndd-optimize.d: Likewise.
+ * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp.d: Likewise.
+
+2023-12-29 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Don't use .insn with '/'
+ '/' starts a comment for some targets. Use .byte instead of .insn with
+ '/'.
+
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Use .byte
+ instead of .insn with '/'.
+
+2023-12-29 H.J. Lu <hjl.tools@gmail.com>
+
+ Fix x86-64: Add R_X86_64_CODE_4_GOTPCRELX
+ commit 3d5a60de52556f6a53d71d7e607c6696450ae3e4
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Thu Jun 8 10:01:03 2023 -0700
+
+ x86-64: Add R_X86_64_CODE_4_GOTPCRELX
+
+ added a new field, fx_tcbit3, to fix. But it didn't initialize it.
+ Fix it by clearing it in fix_new_internal.
+
+ * wrtite.c (fix_new_internal): Clear fx_tcbit3.
+
+2023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+ Bernhard Heckel <bernhard.heckel@intel.com>
+ Tim Wiederhake <tim.wiederhake@intel.com>
+
+ dwarf, fortran: add support for DW_TAG_entry_point
+ Fortran provides additional entry points for subroutines and functions.
+ These entry points may use only a subset (or a different set) of the
+ parameters of the original subroutine. The entry points may be described
+ via the DWARF tag DW_TAG_entry_point.
+
+ This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
+ Currently, between ifx/ifort/gfortran, only ifort is actually emitting
+ this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
+ workaround/alternative. Thus, this patch really only adds more ifort
+ support. Even so, some of the attached tests still fail for ifort, due
+ to some wrong line info generated for the entry points in ifort.
+
+ After this patch it is possible to set a breakpoint in gdb with the
+ ifort compiled example at the entry points 'foo' and 'foobar', which was not
+ possible before.
+
+ As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
+ which uses some underlying c compiled code and adds some Fortran style DWARF
+ to it emitting the DW_TAG_entry_point. Before this patch it was not
+ possible to actually define breakpoint at the entry point tags.
+
+ For gfortran there actually exists a bug on bugzilla, asking for the use
+ of DW_TAG_entry_point over DW_TAG_subprogram:
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
+
+ This patch was originally posted here
+
+ https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
+
+ but its review/pinging got lost after a while. I reworked it to fit the
+ current GDB.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, dwarf: add assert to dwarf2_get_pc_bounds
+ In dwarf2_get_pc_bounds we were writing unchecked to *lowpc. This
+ commit adds a gdb_assert to first check that lowpc != nullptr.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-12-29 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, dwarf: move part of dwarf2_get_pc_bounds into separate function
+ This commit is in preparation of the next commit. There, we will add
+ a second variation to retrieve the pc bounds for DIEs tagged with
+ DW_TAG_entry_point. Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc
+ we will call a separate method for entry points. As the validity checks
+ at the endo f dwarf2_get_pc_bounds are the same for both variants,
+ we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method,
+ outsourcing part of dwarf2_get_pc_bounds.
+
+ This commit should have no functional impact on GDB.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ LoongArch: ld: Add support for tls le relax.
+ Add tls le relax related testsuites in ld.
+
+ The new test cases are mainly tested in three aspects:
+
+ 1. tls le relax function correctness test.
+ 2. tls le relax boundary check test.
+ 3. tls le relax function compatibility test.
+
+ ld/testsuite/ChangeLog:
+
+ * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.
+ * ld/testsuite/ld-loongarch-elf/old-tls-le.s: New test.
+ * ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s: Likewise.
+ * ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s: Likewise.
+ * ld/testsuite/ld-loongarch-elf/relax-tls-le.s: Likewise.
+ * ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s: Likewise.
+
+2023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ LoongArch: gas: Add support for tls le relax.
+ Add tls le relax related relocs support and testsuites in gas.
+
+ The main test is three new relocation items,
+ R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_HI20_R,
+ R_LARCH_TLS_LE_LO12_R can be generated properly
+ and tls le insn format check.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c:
+ (loongarch_args_parser_can_match_arg_helper): Add support for relax.
+ * gas/testsuite/gas/loongarch/reloc.d: Likewise.
+ * gas/testsuite/gas/loongarch/reloc.s: Likewise.
+ * gas/testsuite/gas/loongarch/loongarch.exp: Likewise.
+ * gas/testsuite/gas/loongarch/tls_le_insn_format_check.s: New test.
+
+2023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ LoongArch: opcodes: Add support for tls le relax.
+ Add new opcode for tls le relax.
+
+ opcode/ChangeLog:
+
+ * loongarch-opc.c: Add new loongarch opcode.
+
+2023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ LoongArch: include: Add support for tls le relax.
+ Add new relocs number for tls le relax.
+
+ include/ChangeLog:
+
+ * elf/loongarch.h:
+ (RELOC_NUMBER (R_LARCH_TLS_LE_HI20_R, 121)): New relocs number.
+ (RELOC_NUMBER (R_LARCH_TLS_LE_ADD_R, 122)): Likewise.
+ (RELOC_NUMBER (R_LARCH_TLS_LE_LO12_R, 123)): Likewise.
+
+2023-12-29 changjiachen <changjiachen@stu.xupt.edu.cn>
+
+ LoongArch: bfd: Add support for tls le relax.
+ Add tls le relax support and related relocs in bfd.
+
+ New relocation related explanation can refer to the following url:
+ https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc
+
+ This support does two main things:
+
+ 1. Implement support for three new relocation items in bfd.
+
+ The three new relocation items are shown below:
+
+ R_LARCH_TLS_LE_ADD_R
+ R_LARCH_TLS_LE_HI20_R
+ R_LARCH_TLS_LE_LO12_R
+
+ 2. ADD a new macro RELOCATE_TLS_TP32_HI20
+
+ Handle problems caused by symbol extensions in TLS LE, The processing
+ is similar to the macro RELOCATE_CALC_PC32_HI20 method.
+
+ 3. Implement the tls le relax function.
+
+ bfd/ChangeLog:
+
+ * bfd-in2.h: Add relocs related to tls le relax.
+ * elfnn-loongarch.c:
+ (loongarch_relax_tls_le): New function.
+ (RELOCATE_TLS_TP32_HI20): New macro.
+ (loongarch_elf_check_relocs): Add new reloc support.
+ (perform_relocation): Likewise.
+ (loongarch_elf_relocate_section): Handle new relocs related to relax.
+ (loongarch_elf_relax_section): Likewise.
+ * elfxx-loongarch.c:
+ (LOONGARCH_HOWTO (R_LARCH_TLS_LE_ADD_R)): New reloc how to type.
+ (LOONGARCH_HOWTO (R_LARCH_TLS_LE_HI20_R)): Likewise.
+ (LOONGARCH_HOWTO (R_LARCH_TLS_LE_LO12_R)): Likewise.
+ * libbfd.h: Add relocs related to tls le relax.
+ * reloc.c: Likewise.
+
+2023-12-29 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: THEAD: Add 5 assembly pseudoinstructions for XTheadVector extension
+ In order to make it easier to complete the compiler's support for
+ the XTheadVector extension and to be as compatible as possible
+ with the programming model of the 'V' extension ([1]), we consider
+ adding a few pseudo instructions ([2]).
+
+ th.vmmv.m vd,vs => th.vmand.mm vd,vs,vs
+ th.vneg.v vd,vs => th.vrsub.vx vd,vs,x0
+ th.vncvt.x.x.v vd,vs,vm => th.vnsrl.vx vd,vs,x0,vm
+ th.vfneg.v vd,vs => th.vfsgnjn.vv vd,vs,vs
+ th.vfabs.v vd,vs => th.vfsgnjx.vv vd,vs,vs
+
+ Ref:
+ [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641302.html
+ [2] https://github.com/T-head-Semi/thead-extension-spec/pull/40
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for new
+ pseudoinstructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add new pseudoinstructions.
+
+2023-12-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Mention support for Intel APX relocations in NEWS
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ Gold: Handle R_X86_64_CODE_4_GOTPC32_TLSDESC/R_X86_64_CODE_4_GOTTPOFF
+ Handle R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
+ Convert
+
+ add name@gottpoff(%rip), %reg
+ mov name@gottpoff(%rip), %reg
+
+ to
+
+ add $name@tpoff, %reg
+ mov $name@tpoff, %reg
+
+ and
+
+ lea name@tlsdesc(%rip), %reg
+
+ to
+
+ mov $name@tpoff, %reg
+ mov name@gottpoff(%rip), %reg
+
+ if the instruction is encoded with the REX2 prefix when possible.
+
+ elfcpp/
+
+ * x86_64.h (R_X86_64_CODE_4_GOTTPOFF): New.
+ (R_X86_64_CODE_4_GOTPC32_TLSDESC): Likewise.
+
+ gold/
+
+ * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle
+ R_X86_64_CODE_4_GOTPC32_TLSDESC and R_X86_64_CODE_4_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_desc_gd_to_ie): Handle
+ R_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (Target_x86_64::Relocate::tls_desc_gd_to_le): Likewise.
+ (Target_x86_64::Relocate::tls_ie_to_le): Handle.
+ R_X86_64_CODE_4_GOTTPOFF.
+ * testsuite/Makefile.am: Add x86_64_ie_to_le test.
+ * testsuite/Makefile.in: Regenerated.
+ * testsuite/x86_64_gd_to_le.s: Add R_X86_64_CODE_4_GOTPC32_TLSDESC
+ test.
+ * testsuite/x86_64_gd_to_le.sh: Check GDesc to LE conversion.
+ * testsuite/x86_64_ie_to_le.s: New file.
+ * testsuite/x86_64_ie_to_le.sh: Likewise.
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Add R_X86_64_CODE_4_GOTTPOFF/R_X86_64_CODE_4_GOTPC32_TLSDESC
+ For
+
+ add name@gottpoff(%rip), %reg
+ mov name@gottpoff(%rip), %reg
+
+ add
+
+ # define R_X86_64_CODE_4_GOTTPOFF 44
+
+ and for
+
+ lea name@tlsdesc(%rip), %reg
+
+ add
+
+ # define R_X86_64_CODE_4_GOTPC32_TLSDESC 45
+
+ if the instruction starts at 4 bytes before the relocation offset.
+ They are similar to R_X86_64_GOTTPOFF and R_X86_64_GOTPC32_TLSDESC,
+ respectively. Linker can covert GOTTPOFF to
+
+ add $name@tpoff, %reg
+ mov $name@tpoff, %reg
+
+ and GOTPC32_TLSDESC to
+
+ mov $name@tpoff, %reg
+ mov name@gottpoff(%rip), %reg
+
+ if the instruction is encoded with the REX2 prefix when possible.
+
+ bfd/
+
+ * elf64-x86-64.c (x86_64_elf_howto_table): Add
+ R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (R_X86_64_standard): Updated.
+ (x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTTPOFF
+ and BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_4_GOTTPOFF
+ and R_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (elf_x86_64_tls_transition): Likewise.
+ (elf_x86_64_scan_relocs): Likewise.
+ (elf_x86_64_relocate_section): Likewise.
+ * reloc.c (bfd_reloc_code_real): Add
+ BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
+ BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
+ * bfd-in2.h: Regenerated.
+ * libbfd.h: Likewise.
+
+ gas/
+
+ * config/tc-i386.c (tc_i386_fix_adjustable): Handle
+ BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
+ BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (md_assemble): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF.
+ (output_insn): Don't add empty REX prefix with REX2 prefix.
+ (output_disp): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
+ BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
+ (md_apply_fix): Likewise.
+ (i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTTPOFF or
+ BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC if ixp->fx_tcbit3 is set.
+ (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
+ BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
+ * testsuite/gas/i386/x86-64-gottpoff.d: New file.
+ * testsuite/gas/i386/x86-64-gottpoff.s: Likewise.
+ * testsuite/gas/i386/x86-64-tlsdesc.d: Likewise.
+ * testsuite/gas/i386/x86-64-tlsdesc.s: Likewise.
+
+ include/
+
+ * elf/x86-64.h (elf_x86_64_reloc_type): Add
+ R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC
+
+ ld/
+
+ * testsuite/ld-x86-64/tlsbindesc.d: Updated.
+ * testsuite/ld-x86-64/tlsbindesc.rd: Likewise.
+ * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_4_GOTTPOFF
+ and R_X86_64_CODE_4_GOTPC32_TLSDESC tests.
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ gold: Handle R_X86_64_CODE_4_GOTPCRELX
+ Handle R_X86_64_CODE_4_GOTPCRELX and convert
+
+ mov name@GOTPCREL(%rip), %r31
+
+ to
+
+ lea name@GOTPCREL(%rip), %r31
+
+ if the instruction is encoded with the REX2 prefix when possible.
+
+ elfcpp/
+
+ * x86_64.h (R_X86_64_CODE_4_GOTPCRELX): New.
+
+ gold/
+
+ * x86_64.cc (Target_x86_64::can_convert_mov_to_lea): Handle
+ R_X86_64_CODE_4_GOTPCRELX.
+ (Target_x86_64::Scan::get_reference_flags): Likewise.
+ (Target_x86_64::Scan::local): Likewise.
+ (Target_x86_64::Scan::possible_function_pointer_reloc): Likewise.
+ (Target_x86_64::Scan::global): Likewise.
+ (Target_x86_64::Relocate::relocate): Likewise.
+ * testsuite/x86_64_mov_to_lea1.s: Add a test for
+ R_X86_64_CODE_4_GOTPCRELX.
+ * testsuite/x86_64_mov_to_lea2.s: Likewise.
+ * testsuite/x86_64_mov_to_lea3.s: Likewise.
+ * testsuite/x86_64_mov_to_lea4.s: Likewise.
+ * testsuite/x86_64_mov_to_lea5.s: Likewise.
+ * testsuite/x86_64_mov_to_lea.sh: Updated.
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Add R_X86_64_CODE_4_GOTPCRELX
+ For
+
+ mov name@GOTPCREL(%rip), %reg
+ test %reg, name@GOTPCREL(%rip)
+ binop name@GOTPCREL(%rip), %reg
+
+ where binop is one of adc, add, add, cmp, or, sbb, sub, xor instructions,
+ add
+
+ # define R_X86_64_CODE_4_GOTPCRELX 43
+
+ if the instruction starts at 4 bytes before the relocation offset. It
+ similar to R_X86_64_GOTPCRELX. Linker can treat R_X86_64_CODE_4_GOTPCRELX
+ as R_X86_64_GOTPCREL or convert the above instructions to
+
+ lea name(%rip), %reg
+ mov $name, %reg
+ test $name, %reg
+ binop $name, %reg
+
+ if the instruction is encoded with the REX2 prefix when possible.
+
+ bfd/
+
+ * elf64-x86-64.c (x86_64_elf_howto_table): Add
+ R_X86_64_CODE_4_GOTPCRELX.
+ (R_X86_64_standard): Updated.
+ (x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
+ (elf_x86_64_convert_load_reloc): Handle R_X86_64_CODE_4_GOTPCRELX.
+ (elf_x86_64_scan_relocs): Likewise.
+ (elf_x86_64_relocate_section): Likewise.
+ * reloc.c (bfd_reloc_code_real): Add
+ BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
+ * bfd-in2.h: Regenerated.
+ * libbfd.h: Likewise.
+
+ gas/
+
+ * write.h (fix): Add fx_tcbit3. Change fx_unused to 1 bit.
+ * config/tc-i386.c (tc_i386_fix_adjustable): Handle
+ BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
+ (tc_gen_reloc): Likewise.
+ (output_disp): Set fixP->fx_tcbit3 for REX2 prefix.
+ (i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTPCRELX
+ if fixp->fx_tcbit3 is set.
+ * config/tc-i386.h (TC_FORCE_RELOCATION_LOCAL): Add
+ BFD_RELOC_X86_64_CODE_4_GOTPCRELX.
+ (TC_FORCE_RELOCATION_ABS): Likewise.
+ * testsuite/gas/i386/x86-64-gotpcrel.s: Add tests for
+ R_X86_64_CODE_4_GOTPCRELX.
+ * testsuite/gas/i386/x86-64-localpic.s: Likewise.
+ * testsuite/gas/i386/x86-64-gotpcrel.d: Updated.
+ * testsuite/gas/i386/x86-64-localpic.d: Likewise.
+ * testsuite/gas/i386/ilp32/x86-64-localpic.d: Likewise.
+
+ include/
+
+ * elf/x86-64.h (elf_x86_64_reloc_type): Add
+ R_X86_64_CODE_4_GOTPCRELX.
+
+ ld/
+
+ * testsuite/ld-x86-64/apx-load1.s: New file.
+ * testsuite/ld-x86-64/apx-load1a.d: Likewise.
+ * testsuite/ld-x86-64/apx-load1b.d: Likewise.
+ * testsuite/ld-x86-64/apx-load1c.d: Likewise.
+ * testsuite/ld-x86-64/apx-load1d.d: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Run apx-load1a, apx-load1b,
+ apx-load1c and apx-load1d.
+
+2023-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ gas: Mention initial support for Intel APX in NEWS
+
+2023-12-28 Schimpe, Christina <christina.schimpe@intel.com>
+
+ x86: Add NT_X86_SHSTK note
+ Define NT_X86_SHSTK which is the note for x86 Shadow Stack (SHSTK) to
+ support Intel SHSTK in Linux kernel.
+ For now only userspace shadow stack and kernel IBT are supported by the
+ linux kernel. This note should be used instead of NT_X86_CET introduced
+ in the commit "x86: Add NT_X86_CET note", as it is outdated and only
+ used by old binutils versions.
+
+2023-12-28 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support APX JMPABS for disassembler
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/x86-64-apx-jmpabs-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-jmpabs-inval.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-jmpabs-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-apx-jmpabs.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-jmpabs.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (JMPABS_Fixup): New Fixup function to disassemble jmpabs.
+ (print_insn): Add #UD exception for jmpabs.
+ (dis386): Modify a1 unit for support jmpabs.
+ * i386-mnem.h: Regenerated.
+ * i386-opc.tbl: New insns.
+ * i386-tbl.h: Regenerated.
+
+2023-12-28 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support APX NDD optimized encoding.
+ This patch aims to optimize:
+
+ add %r16, %r15, %r15 -> add %r16, %r15
+
+ gas/ChangeLog:
+
+ * config/tc-i386.c (check_Rex_required): New function.
+ (can_convert_NDD_to_legacy): Ditto.
+ (match_template): If we can optimzie APX NDD insns, so rematch
+ template.
+ * testsuite/gas/i386/x86-64.exp: Add test.
+ * testsuite/gas/i386/x86-64-apx-ndd-optimize.d: New test.
+ * testsuite/gas/i386/x86-64-apx-ndd-optimize.s: Ditto.
+
+2023-12-28 Cui, Lili <lili.cui@intel.com>
+
+ Support APX pushp/popp
+ gas/ChangeLog:
+
+ * config/tc-i386.c (process_operands): Handle "PUSHP/POPP requires
+ rex2.w == 1."
+ * testsuite/gas/i386/x86-64.exp: Add new test for PUSHP/POPP.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp-intel.d: New test.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-pushp-popp.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (putop): print pushp and popp.
+ * i386-opc.tbl: Added new insns.
+ * i386-init.h : Regenerated.
+ * i386-mnem.h : Regenerated.
+ * i386-tbl.h: Regenerated.
+
+2023-12-28 Mo, Zewei <zewei.mo@intel.com>
+
+ Support APX Push2/Pop2
+ PPX functionality for PUSH/POP is not implemented in this patch
+ and will be implemented separately.
+
+ gas/ChangeLog:
+
+ 2023-12-28 Zewei Mo <zewei.mo@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ * config/tc-i386.c: (enum i386_error):
+ New unsupported_rsp_register and invalid_src_register_set.
+ (md_assemble): Add handler for unsupported_rsp_register and
+ invalid_src_register_set.
+ (check_APX_operands): Add invalid check for push2/pop2.
+ (match_template): Handle check_APX_operands.
+ * testsuite/gas/i386/i386.exp: Add apx-push2pop2 tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/x86-64-apx-push2pop2.d: New test.
+ * testsuite/gas/i386/x86-64-apx-push2pop2.s: Ditto.
+ * testsuite/gas/i386/x86-64-apx-push2pop2-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-push2pop2-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-apx-push2pop2-inval.s: Ditto.
+ * testsuite/gas/i386/apx-push2pop2-inval.s: Ditto.
+ * testsuite/gas/i386/apx-push2pop2-inval.d: Ditto.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added bad
+ testcases for POP2.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis-evex-reg.h: Add REG_EVEX_MAP4_8F.
+ * i386-dis-evex-w.h: Add EVEX_W_MAP4_8F_R_0 and EVEX_W_MAP4_FF_R_6
+ * i386-dis-evex.h: Add REG_EVEX_MAP4_8F.
+ * i386-dis.c (PUSH2_POP2_Fixup): Add special handling for PUSH2/POP2.
+ (get_valid_dis386): Add handler for vector length and address_mode for
+ APX-Push2/Pop2 insn.
+ (nd): define nd as b for EVEX-promoted instrutions.
+ (OP_VEX): Add handler of 64-bit vvvv register for APX-Push2/Pop2 insn.
+ * i386-gen.c: Add Push2Pop2 bitfield.
+ * i386-opc.h: Regenerated.
+ * i386-opc.tbl: Regenerated.
+
+2023-12-28 konglin1 <lingling.kong@intel.com>
+
+ Support APX NDD
+ opcodes/ChangeLog:
+
+ * opcodes/i386-dis-evex-reg.h: Handle for REG_EVEX_MAP4_80,
+ REG_EVEX_MAP4_81, REG_EVEX_MAP4_83, REG_EVEX_MAP4_F6,
+ REG_EVEX_MAP4_F7, REG_EVEX_MAP4_FE, REG_EVEX_MAP4_FF.
+ * opcodes/i386-dis-evex.h: Add NDD insn.
+ * opcodes/i386-dis.c (nd): New define.
+ (VexGb): Ditto.
+ (VexGv): Ditto.
+ (get_valid_dis386): Change for NDD decode.
+ (print_insn): Ditto.
+ (putop): Ditto.
+ (intel_operand_size): Ditto.
+ (OP_E_memory): Ditto.
+ (OP_VEX): Ditto.
+ * opcodes/i386-opc.h (VexVVVV_DST): New.
+ * opcodes/i386-opc.tbl: Add APX NDD instructions and adjust VexVVVV.
+ * opcodes/i386-tbl.h: Regenerated.
+
+ gas/ChangeLog:
+
+ * gas/config/tc-i386.c (operand_size_match):
+ Support APX NDD that the number of operands is 3.
+ (build_apx_evex_prefix): Change for ndd encode.
+ (process_operands): Ditto.
+ (build_modrm_byte): Ditto.
+ (match_template): Support swap the first two operands for
+ APX NDD.
+ * testsuite/gas/i386/x86-64.exp: Add x86-64-apx-ndd.
+ * testsuite/gas/i386/x86-64-apx-ndd.d: New test.
+ * testsuite/gas/i386/x86-64-apx-ndd.s: Ditto.
+ * testsuite/gas/i386/x86-64-pseudos.d: Add test.
+ * testsuite/gas/i386/x86-64-pseudos.s: Ditto.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d : Ditto.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s : Ditto.
+
+2023-12-28 Cui, Lili <lili.cui@intel.com>
+
+ Add tests for APX GPR32 with extend evex prefix
+ gas/ChangeLog:
+
+ 2023-12-28 Lingling Kong <lingling.kong@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Lili Cui <lili.cui@intel.com>
+ Lin Hu <lin1.hu@intel.com>
+
+ * testsuite/gas/i386/x86-64-apx-egpr-inval.l: Add some insn don't
+ support gpr32.
+ * testsuite/gas/i386/x86-64-apx-egpr-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64.exp: Add new test.
+ * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: New test.
+ * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-egpr.d: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-egpr.s: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted.d: New test.
+ * testsuite/gas/i386/x86-64-apx-evex-promoted.s: New test.
+
+2023-12-28 Cui, Lili <lili.cui@intel.com>
+
+ Support APX GPR32 with extend evex prefix
+ This patch adds non-ND, non-NF forms of EVEX promotion insn.
+
+ EVEX extension of legacy instructions:
+ All promoted legacy instructions are placed in EVEX map 4, which is
+ currently reserved.
+ EVEX extension of EVEX instructions:
+ All existing EVEX instructions are extended by APX using the extended
+ EVEX prefix, so that they can access all 32 GPRs.
+ EVEX extension of VEX instructions:
+ Promoting a VEX instruction into the EVEX space does not change the map
+ id, the opcode, or the operand encoding of the VEX instruction.
+
+ Note: The promoted versions of MOVBE will be extended to include the “MOVBE
+ reg1, reg2”.
+
+ gas/ChangeLog:
+
+ 2023-12-28 Lingling Kong <lingling.kong@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Lili Cui <lili.cui@intel.com>
+ Lin Hu <lin1.hu@intel.com>
+
+ * config/tc-i386.c (struct _i386_insn): Add has_egpr.
+ (need_evex_encoding): Adjusted for apx.
+ (cpu_flags_match): Ditto.
+ (install_template): Handled APX combines.
+ (is_apx_evex_encoding): Test apx evex encoding.
+ (build_apx_evex_prefix): Enabe APX evex prefix.
+ (md_assemble): Handle apx with evex encoding.
+ (process_suffix): Handle apx map4 prefix.
+ (check_register): Assign i.vec_encoding for APX evex instructions.
+ * testsuite/gas/i386/x86-64-evex.d: Adjust test cases.
+ * testsuite/gas/i386/x86-64.exp: Adjust x86-64-inval-movbe.
+
+ opcodes/ChangeLog:
+
+ * i386-dis-evex-len.h: Handle EVEX_LEN_0F38F2, EVEX_LEN_0F38F3.
+ * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_0F38F2_L_0,
+ PREFIX_EVEX_0F38F3_L_0, PREFIX_EVEX_MAP4_D8,
+ PREFIX_EVEX_MAP4_DA, PREFIX_EVEX_MAP4_DB,
+ PREFIX_EVEX_MAP4_DC, PREFIX_EVEX_MAP4_DD,
+ PREFIX_EVEX_MAP4_DE, PREFIX_EVEX_MAP4_DF,
+ PREFIX_EVEX_MAP4_F0, PREFIX_EVEX_MAP4_F1,
+ PREFIX_EVEX_MAP4_F2, PREFIX_EVEX_MAP4_F8.
+ * i386-dis-evex-reg.h: Handle REG_EVEX_0F38F3_L_0_P_0.
+ * i386-dis-evex.h: Add EVEX_MAP4_ for legacy insn
+ promote to apx to use gpr32
+ * opcodes/i386-dis-evex-x86-64.h: Handle Add X86_64_EVEX_0F90,
+ X86_64_EVEX_0F92, X86_64_EVEX_0F93, X86_64_EVEX_0F38F2,
+ X86_64_EVEX_0F38F3, X86_64_EVEX_0F38F5, X86_64_EVEX_0F38F6,
+ X86_64_EVEX_0F38F7, X86_64_EVEX_0F3AF0, X86_64_EVEX_0F91.
+ * i386-dis.c
+ (struct instr_info): Deleted bool r.
+ (PREFIX_NP_OR_DATA): New.
+ (NO_PREFIX): New.
+ (putop): Ditto.
+ (X86_64_EVEX_FROM_VEX_TABLE): Diito.
+ (get_valid_dis386): Decode insn erex in extend evex prefix.
+ Handle EVEX_MAP4
+ (print_insn): Handle PREFIX_DATA_AND_NP_ONLY.
+ (print_register): Handle apx instructions decode.
+ (OP_E_memory): Diito.
+ (OP_G): Diito.
+ (OP_XMM): Diito.
+ (DistinctDest_Fixup): Diito.
+ * i386-gen.c (process_i386_opcode_modifier): Add EVEXMAP4.
+ * i386-opc.h (SPACE_EVEXMAP4): Add legacy insn
+ promote to evex.
+ * i386-opc.tbl: Handle some legacy and vex insns don't
+ support gpr32. And add some legacy insn (map2 / 3) promote
+ to evex.
+
+2023-12-28 Cui, Lili <lili.cui@intel.com>
+
+ Created an empty EVEX_MAP4_ sub-table for EVEX instructions.
+ opcode/ChangeLog:
+
+ * i386-dis-evex.hi: Added an empty EVEX_MAP4_ sub-table for
+ legacy insn promote to EVEX insn.
+ * opcodes/i386-dis-evex.h: Add EVEX_MAP4.
+
+2023-12-28 Cui, Lili <lili.cui@intel.com>
+
+ Support APX GPR32 with rex2 prefix
+ APX uses the REX2 prefix to support EGPR for map0 and map1 of legacy
+ instructions. We added the NoEgpr flag in i386-gen.c for instructions
+ that do not support EGPR.
+
+ gas/ChangeLog:
+
+ 2023-12-28 Lingling Kong <lingling.kong@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Lili Cui <lili.cui@intel.com>
+ Lin Hu <lin1.hu@intel.com>
+
+ * config/tc-i386.c
+ (enum i386_error): Add unsupported_EGPR_for_addressing
+ and invalid_pseudo_prefix.
+ (struct _i386_insn): Add rex2 and rex2_encoding for
+ gpr32.
+ (cpu_arch): Add apx_f.
+ (is_cpu): Ditto.
+ (register_number): Handle RegRex2 for gpr32.
+ (is_apx_rex2_encoding): New func. Test rex2 prefix encoding.
+ (build_rex2_prefix): New func. Build legacy insn in
+ opcode 0/1 use gpr32 with rex2 prefix.
+ (establish_rex): Handle rex2 and rex2_encoding.
+ (optimize_encoding): Handel add r16-r31 for registers.
+ (md_assemble): Handle apx encoding.
+ (parse_insn): Handle Prefix_REX2.
+ (check_EgprOperands): New func. Check if Egprs operands
+ are valid for the instruction
+ (match_template): Handle Egpr operands check.
+ (set_rex_rex2): New func. set i.rex and i.rex2.
+ (build_modrm_byte): Ditto.
+ (output_insn): Handle rex2 2-byte prefix output.
+ (check_register): Handle check egpr illegal without
+ target apx, 64-bit mode and with rex_prefix.
+ * doc/c-i386.texi: Document .apx.
+ * testsuite/gas/i386/ilp32/x86-64-opcode-inval-intel.d: D5 valid
+ in 64-bit mode.
+ * testsuite/gas/i386/ilp32/x86-64-opcode-inval.d: Ditto.
+ * testsuite/gas/i386/rex-bad: Adjust rex testcase.
+ * testsuite/gas/i386/x86-64-opcode-inval-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-opcode-inval.d: Ditto.
+ * testsuite/gas/i386/x86-64-opcode-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-pseudos-bad.l: Add illegal rex2 test.
+ * testsuite/gas/i386/x86-64-pseudos-bad.s: Ditto.
+ * testsuite/gas/i386/x86-64-pseudos.d: Add rex2 test.
+ * testsuite/gas/i386/x86-64-pseudos.s: Ditto.
+ * testsuite/gas/i386/x86-64.exp: Run APX tests.
+ * testsuite/gas/i386/x86-64-apx-egpr-inval.l: New test.
+ * testsuite/gas/i386/x86-64-apx-egpr-inval.s: New test.
+ * testsuite/gas/i386/x86-64-apx-rex2.d: New test.
+ * testsuite/gas/i386/x86-64-apx-rex2.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/i386.h (REX2_OPCODE): New.
+ (REX2_M): Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (struct instr_info): Add erex for gpr32.
+ Add last_erex_prefix for rex2 prefix.
+ (REX2_M): Extend for gpr32.
+ (PREFIX_REX2): Ditto.
+ (PREFIX_REX2_ILLEGAL): Ditto.
+ (ckprefix): Ditto.
+ (prefix_name): Ditto.
+ (print_insn): Ditto.
+ (print_register): Ditto.
+ (OP_E_memory): Ditto.
+ (OP_REG): Ditto.
+ (OP_EX): Ditto.
+ * i386-gen.c (rex2_disallowed): Some instructions are not allowed rex2 prefix.
+ (process_i386_opcode_modifier): Set NoEgpr for VEX and some special instructions.
+ (output_i386_opcode): Handle if_entry_needs_special_handle.
+ * i386-init.h : Regenerated.
+ * i386-mnem.h : Regenerated.
+ * i386-opc.h (enum i386_cpu): Add CpuAPX_F.
+ (NoEgpr): New.
+ (Prefix_NoOptimize): Ditto.
+ (Prefix_REX2): Ditto.
+ (RegRex2): Ditto.
+ * i386-opc.tbl: Add rex2 prefix.
+ * i386-reg.tbl: Add egprs (r16-r31).
+ * i386-tbl.h: Regenerated.
+
+2023-12-28 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ sim: pru: Fix emulation of carry bit
+ The PRU architecture documentation [1] was used for the initial GNU
+ simulator implementation. But recently [2] TI confirmed the carry
+ behaviour was wrongly documented. In reality, the PRU carry behaves
+ like the carry in ARM processors.
+
+ This patch fixes simulator to align with latest recommendations from TI.
+
+ The new carry.s test was also validated to pass on real hardware -
+ a BeaglePlay board [3]. That test is a bit long because TI still
+ has not released official updates for the PRU documents. And I wanted
+ to ensure simulator handles all edge cases exactly as the real hardware
+ does.
+
+ [1] https://www.ti.com/lit/pdf/spruij2
+ [2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1244359/sk-am64b-am64x-pru-assembler-how-works-this-bloody-carry
+ [3] https://www.beagleboard.org/boards/beagleplay
+
+2023-12-28 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: PR31179, The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
+ * Problematic fix commit,
+ 2029e13917d53d2289d3ebb390c4f40bd2112d21
+ RISC-V: Clarify the behaviors of SET/ADD/SUB relocations
+
+ * Bugzilla,
+ https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5
+
+ The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it
+ non-zero by accident in assembler before. This causes troubles by applying
+ the above commit, since the calculation is changed to support .reloc *SUB*
+ relocations with non-zero addend.
+
+ We encourage people to rebuild their stuff to get the non-zero addend of
+ SUB_ULEB128, but that might need some times, so report warnings to inform
+ people need to rebuild their stuff if --check-uleb128 is enabled.
+
+ Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use,
+ it may acceptable that stop supproting them until people rebuld their stuff,
+ maybe half-year or a year later. Or maybe we should teach people that don't
+ write the .reloc R_RISCV_SUB* with non-zero constant, and then report
+ warnings/errors in assembler.
+
+ bfd/
+ * elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of
+ R_RISCV_SUB_ULEB128.
+ (riscv_elf_relocate_section): Report warnings to inform people need
+ to rebuild their stuff if --check-uleb128 is enabled. So that can
+ get the right non-zero addend of R_RISCV_SUB_ULEB128.
+ * elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128.
+ ld/
+ * NEWS: Updated.
+ * emultempl/riscvelf.em: Added linker risc-v target options,
+ --[no-]check-uleb128, to enable/disable checking if the addend of
+ uleb128 is non-zero or not. So that people will know they need to
+ rebuild the objects with binutils 2.42 and up, to get the right zero
+ addend of SUB_ULEB128 relocation, or they may get troubles if using
+ .reloc.
+ * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+ * ld/testsuite/ld-riscv-elf/pr31179*: New test cases.
+
+2023-12-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-27 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflow in loongarch_elf_rtype_to_howto
+ Seen when running ld-loongarch-elf/tlsdesc-dso test.
+ elfxx-loongarch.c:1844:32: runtime error: index 125 out of bounds for
+ type 'loongarch_reloc_howto_type [124]'
+
+ So either the loongarch_howto_table needs three more
+ LOONGARCH_EMPTY_HOWTO entries, or loongarch_elf_rtype_to_howto should
+ be testing for r_type < ARRAY_SIZE (loongarch_howto_table). I figure
+ it's worth wasting a little more space to get faster lookup.
+
+ * elfxx-loongarch.c (loongarch_howto_table): Add
+ LOONGARCH_EMPTY_HOWTO entries for 121..123.
+ (loongarch_elf_rtype_to_howto): Don't support slow lookup.
+ Assert exact table size and r_type indexing. Omit return cast.
+ (loongarch_reloc_name_lookup): Omit assertion and return cast.
+ (loongarch_reloc_type_lookup): Likewise.
+
+2023-12-27 Alan Modra <amodra@gmail.com>
+
+ PR31191, objcopy leaves temporary files
+ Fix the ENOTDIR rmdir too.
+
+ PR 31191
+ * objcopy.c (copy_archive): Localise uses of "l". Remove
+ const from name_list.name. Unlink output element on bfd_close
+ error, and NULL list->name to indicate file is removed. Adjust
+ cleanup to prevent rmdir on non-existent file.
+
+2023-12-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: common: pull in newlib extensions for Linux compatibility
+ Since newlib allows people to opt-in to extra errno names, pull them
+ into our table too. The values don't conflict with each other -- the
+ newlib names & values are distinct from newlib's Linux compatibility.
+
+2023-12-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-25 Mike Frysinger <vapier@gentoo.org>
+
+ binutils: SECURITY: use https URI
+
+2023-12-25 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Add testsuit for DESC and tls transition and tls relaxation.
+
+2023-12-25 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add support for TLS LD/GD/DESC relaxation
+ The pcalau12i + addi.d of TLS LD/GD/DESC relax to pcaddi.
+ Relaxation is only performed when the TLS model transition is not possible.
+
+2023-12-25 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: Add tls transition support.
+ Transitions between DESC->IE/LE and IE->LE are supported now.
+ 1. For DESC -> LE:
+ pcalau12i $a0,%desc_pc_hi20(var) => lu12i.w $a0,%le_hi20(var)
+ addi.d $a0,$a0,%desc_pc_lo12(var) => ori $a0,$a0,%le_lo12(var)
+ ld.d $a1,$a0,%desc_ld(var) => NOP
+ jirl $ra,$a1,%desc_call(var) => NOP
+ add.d $a0,$a0,$tp
+ 2. For DESC -> IE:
+ pcalau12i $a0,%desc_pc_hi20(var) => pcalau12i $a0,%ie_pc_hi20(var)
+ addi.d $a0,$a0,%desc_pc_lo12(var) => ld.d $a0,$a0,%ie_pc_lo12(var)
+ ld.d $a1,$a0,%desc_ld(var) => NOP
+ jirl $ra,$a1,%desc_call(var) => NOP
+ add.d $a0,$a0,$tp
+ 3. For IE -> LE:
+ pcalau12i $a0,%ie_pc_hi20(var) => lu12i.w $a0,%le_hi20(var)
+ ld.d $a0,$a0,%ie_pc_lo12(var) => ori $a0,$a0,%le_lo12(var)
+ add.d $a0,$a0,$tp
+ 4. When a tls variable is accessed using both DESC and IE, DESC transitions
+ to IE and uses the same GOT entry as IE.
+
+ LoongArch: Add support for TLSDESC in ld.
+ 1.The linker for each DESC generates a R_LARCH_TLS_DESC64 dynamic
+ relocation, which relocation is placed at .rela.dyn.
+ TLSDESC always allocates two GOT slots and one dynamic relocation
+ space to TLSDESC.
+ 2. When using multiple ways to access the same TLS variable, a
+ maximum of 5 GOT slots are used. For example, using GD, TLSDESC,
+ and IE to access the same TLS variable, GD always uses the first
+ two of the five GOT, TLSDESC uses the third and fourth, and IE
+ uses the last.
+
+ LoongArch: Add new relocs and macro for TLSDESC.
+ The normal DESC instruction sequence is:
+ pcalau12i $a0,%desc_pc_hi20(var) #R_LARCH_TLS_DESC_PC_HI20
+ addi.d $a0,$a0,%desc_pc_lo12(var) #R_LARCH_TLS_DESC_PC_LO12
+ ld.d $ra,$a0,%desc_ld(var) #R_LARCH_TLS_DESC_LD
+ jirl $ra,$ra,%desc_call(var) #R_LARCH_TLS_DESC_CALL
+ add.d $a0,$a0,$tp
+
+2023-12-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-24 Alan Modra <amodra@gmail.com>
+
+ Re: LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1">
+ This fixes the buffer overflow added in commit 22b78fad28, and a few
+ other problems.
+
+ * loongarch-coder.c (loongarch_split_args_by_comma): Don't
+ overflow buffer when args == "". Don't remove unbalanced
+ quotes. Don't trim last arg if max number of args exceeded.
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make value::allocate_register_lazy store id of next non-inline frame
+ Some spots loop on the frame chain to find the first next non-inline
+ frame, and pass that as the "next frame" to
+ value::allocate_register_lazy / value::allocate_register. This is
+ necessary if the value is used in the process of computing the id of
+ "this frame". If the frame next to "this frame" is inlined into "this
+ frame", then you that next frame won't have a computed id yet. You have
+ to go past that to find the next non-inline frame, which will have a
+ computed id.
+
+ In other cases, it's fine to store the id of an inline frame as the
+ "next frame id" in a register struct value. When trying to unwind a
+ register from it, it will just call inline_frame_prev_register, which
+ will forward the request to the next next frame, until we hit the next
+ physical frame.
+
+ I think it would make things simpler to just never store the id of an
+ inline frame as the next frame id of register struct values, and go with
+ the first next non-inline frame directly. This way, we don't have to
+ wonder which code paths have to skip inline frames when creating
+ register values and which don't.
+
+ So, change value::allocate_register_lazy to do that work, and remove the
+ loops for the callers that did it.
+
+ Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310
+
+2023-12-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove VALUE_REGNUM, add value::regnum
+ Remove VALUE_REGNUM, replace it with a method on struct value. Set
+ `m_location.reg.regnum` directly from value::allocate_register_lazy,
+ which is fine because allocate_register_lazy is a static creation
+ function for struct value.
+
+ Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove VALUE_NEXT_FRAME_ID, add value::next_frame_id
+ Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set
+ `m_location.reg.next_frame_id` directly from value::allocate_register_lazy,
+ which is fine because allocate_register_lazy is a static creation
+ function for struct value.
+
+ Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: implement address_from_register using value_from_register
+ As explained in the comment removed by the previous commit "gdb: pass
+ non-nullptr frame to gdbarch_value_from_register in
+ address_from_register", address_from_register copies some implementation
+ bits from value_from_register:
+
+ /* This routine may be called during early unwinding, at a time
+ where the ID of FRAME is not yet known. Calling value_from_register
+ would therefore abort in get_frame_id. However, since we only need
+ a temporary value that is never used as lvalue, we actually do not
+ really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement
+ the core of value_from_register, but use the null_frame_id. */
+
+ This is no longer relevant, since we now create a value with a valid next
+ frame id, so change address_from_register to use value_from_register.
+
+ Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove read_frame_register_value's frame parameter
+ By now, all register struct values should have a valid next frame id
+ (assuming they are created using value::allocate_register or
+ value::allocate_register_lazy), so there should be no need to pass a
+ frame alongside the value to read_frame_register_value. Remove the
+ frame parameter and adjust read_frame_register_value accordingly.
+
+ While at it, make read_frame_register_value static, it's only used in
+ findvar.c.
+
+ Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add type parameter to value::allocate_register and add value::allocate_register_lazy
+ Some places that create register struct values don't use register_type
+ to obtain the value type. This prevents them from using the current
+ version of value::allocate_register. One spot (value_of_register_lazy)
+ also creates a lazy register value.
+
+ Add a value::allocate_register_lazy method. Add some type parameters
+ to value::allocate_register and value::allocate_register_lazy, to let
+ the caller specify the type to use for the value. The parameters
+ default to nullptr, in which case we use register_type to obtain the
+ type.
+
+ Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register
+ address_from_register used to pass null_frame_id to
+ gdbarch_value_from_register as "this frame"'s id, because it's possible
+ for it to be called during unwind, when "this frame"'s id is not yet
+ known. This create an oddity where those register struct values are
+ created without a valid next frame id. I would much prefer for things
+ to be consistent and have all register struct values to have a valid
+ next frame id.
+
+ Since gdbarch_value_from_register takes a frame_info_ptr now, rather
+ than a frame_id, we can pass down "this frame", even if it doesn't have
+ a valid id. gdbarch_value_from_register implementations can obtain the
+ next frame from it.
+
+ However, it's possible for the "this frame"'s next frame to be an
+ inline frame, inlined in "this frame", in which case that next frame's
+ id is also not known. So, loop until we get to the next non-inline
+ frame (which is actually the frame where registers for "this frame" are
+ unwound from). This is the same thing that we do in
+ value_of_register_lazy, for the same reason. A later patch will factor
+ out this "while next frame is inline" loop to apply it to all register
+ struct values, so this is somewhat temporary.
+
+ Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: pass frame_info_ptr to gdbarch_value_from_register
+ Pass a frame_info_ptr rather than a frame_id. This avoids having to do
+ a frame lookup on the callee side, when we can just pass the frame down
+ directly.
+
+ I think this fixes a bug in rs6000-tdep.c where the id of the wrong
+ frame was set to `VALUE_NEXT_FRAME_ID (v)`.
+
+ Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565
+
+2023-12-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: don't set frame id after calling cooked_read_value
+ I don't think that setting the next frame id is needed there, all code
+ paths in cooked_read_value do set it properly, AFAIK.
+
+ Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d
+
+2023-12-24 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: rvdummy: delete unused variable
+
+2023-12-24 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: mark cgen_rtx_error noreturn
+ Since this function never returns, mark it as such to fix some unused
+ variable warnings in error code paths.
+
+ For example, cris triggers:
+ sim/cris/semcrisv10f-switch.c:3558:11: error:
+ variable 'tmp_newval' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
+
+ Even though it has an "else" path that calls this error function.
+
+2023-12-24 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: regenerate decode tables
+ Integrate some changes from upstream cgen that tightened up the
+ generated output. Shouldn't be any functional changes here.
+
+ sim: sh: refine pwsb & pwad nops
+ Since these insns don't do anything and are effectively ignored,
+ return early to avoid doing any common processing at the end as
+ that requires initializing variables like "res" with something.
+
+ sim: sh: fix plds Dz,MACL implementation
+ The plds Dz,MACL insn stores the Dz bit into MACL. The current code
+ was storing the "res" variable into Dz and then into MACL, but not
+ setting "res" to anything. Delete that logic and make it match the
+ existing plds Dz,MACH insn.
+
+2023-12-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: rework individual flag disable into dedicated vars
+ The -Wshadow=local is too new for some compilers, so move it to a var
+ that we test at configure time.
+
+2023-12-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build problems on linux-musl
+ ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl.
+ Fixed by declaring these types for linux-musl.
+
+ 2023-12-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30779
+ PR gprofng/29593
+ * common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl.
+ * libcollector/unwind.c: Define __u64 for linux-musl.
+ * src/util.h: Define dbe_stat_t.
+ * src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64".
+ * src/Dbe.cc: Likewise.
+ * src/DbeFile.cc: Likewise.
+ * src/DbeFile.h: Likewise.
+ * src/DbeSession.cc: Likewise.
+ * src/Experiment.cc: Likewise.
+ * src/checks.cc: Likewise.
+ * src/util.cc: Likewise.
+
+2023-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: fix -Wshadow=local warnings
+ Rename the var to avoid shadowing & clobbering the higher context.
+
+ sim: riscv: fix -Wshadow=local warnings
+ Inline the one usage of sd in these macros to avoid possible shadowing.
+
+ sim: ppc: fix -Wshadow=local warnings
+ Use a local name in the macro to avoid shadowing wherever it's used.
+
+ sim: mips: fix -Wshadow=local warnings
+ Delete redundant decls when the existing scope has the same var and
+ type available for use.
+
+ sim: m68hc11: fix -Wshadow=local warnings
+ Delete redundant decls when the existing scope has the same var and
+ type available for use.
+
+ sim: m32c: fix -Wshadow=local warnings
+ These decoders declare a lot of common variables for use by substeps,
+ and then shadows a few because of how the opc generator is implemented.
+ Easiest way around it is to rename the per-substep vars as needed as
+ anything more would require substantial changes to the opc logic.
+
+ sim: iq2000: fix -Wshadow=local warnings
+ Delete redundant decls.
+
+ sim: h8300: fix -Wshadow=local warnings
+ Delete conflicting decls when the existing scope has vars of the same
+ name & type for this exact use.
+
+ sim: frv: fix -Wshadow=local warnings
+ Delete redundant decls, and rename conflicting vars.
+
+ sim: erc32: fix -Wshadow=local warnings
+ Rename shadowed vars with different types to avoid confusion.
+
+2023-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: disable -Wshadow=local in generated mloop files
+ The mloop files include CGEN generated switch files which have some
+ nested assignments that expand into repeated shadowed variables.
+ Fixing this looks fairly non-trivial as it appears to be interplay
+ between the common CGEN code and how this particular set of cris
+ insns are defined. Disable the warning instead.
+
+ In file included from sim/cris/mloop.in:286:
+ sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’:
+ sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local]
+ 12383 | SI opval = tmp_addr;
+ | ^~~~~
+ sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here
+ 12371 | USI opval = ({ SI tmp_addr;
+ | ^~~~~
+
+ And the code looks like:
+ USI opval = ({
+ ...
+ {
+ SI opval = tmp_addr;
+ ...
+ }
+ ...
+ });
+
+ Since the CGEN code treats "opval" as an internal variable that the cpu
+ definitions don't have direct access to, the likelihood of this being a
+ real bug is low, so leave it be. The warning is suppressed for more code
+ that is hand written (e.g. the mloop logic), but disabling for the entire
+ file is the easiest way to suppress while keeping it on everywhere else in
+ the sim.
+
+2023-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: fix -Wshadow=local warnings
+ Delete redundant local decls.
+
+ sim: common: fix -Wshadow=local warnings
+ Rename shadowed vars with different types, and delete redundant decls.
+
+ sim: bfin: fix -Wshadow=local warnings
+ Rename the shadowed var to avoid confusion with the function argument
+ as to which address this code is using.
+
+ sim: arm: fix -Wshadow=local warnings
+ Remove duplicate nested variable declarations, rename some to avoid
+ confusion when the type is different or the original value should be
+ retained, and fix some weirdness with nested enums in structs.
+
+ sim: aarch64: fix -Wshadow=local warnings
+ These functions have local vars named "val" of type float, and
+ then create nested vars named "val" of type double. This is a
+ bit confusing and causes build time warnings.
+
+2023-12-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Check for rogue DAP exceptions in test suite
+ This changes the test suite to look for rogue DAP exceptions in the
+ log file, and issue a "fail" if one is found.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Avoid exception from attach in DAP
+ I noticed that the DAP attach test case (and similarly
+ remoted-dap.exp) had a rogue exception stack trace in the log. It
+ turns out that an attach will generate a stop that does not have a
+ reason.
+
+ This patch fixes the problem in the _on_stop event listener by making
+ it a bit more careful when examining the event reason. It also adds
+ some machinery so that attach stops can be suppressed, which I think
+ is the right thing to do.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Add DAP log level parameter
+ This adds a new parameter to control the DAP logging level. By
+ default, "expected" exceptions are not logged, but the parameter lets
+ the user change this when more logging is desired.
+
+ This also changes a couple of spots to avoid logging the stack trace
+ for a DAPException.
+
+ This patch also documents the existing DAP logging parameter. I
+ forgot to document this before.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Introduce and use DAPException
+ This introduces a new DAPException class, and then changes various
+ spots in the DAP implementation to wrap "expected" exceptions in this.
+ This class will help detect rogue exceptions caused by bugs in the
+ implementation.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Fix build with clang 16
+ clang 16 reports a missing declaration in new-op.cc. We believed
+ these operators to be declared starting with C++14, but apparently
+ that is not the case.
+
+ This patch reverts the earlier change and then updates the comment to
+ reflect the current state.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31141
+
+2023-12-22 Kévin Le Gouguec <legouguec@adacore.com>
+
+ gdb: fix refactoring hiccup in rs6000_register_to_value
+ In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame"
+ (9fc79b42369), *_register_to_value functions were made to (a) call
+ get_next_frame_sentinel_okay (frame) (b) pass that next frame to
+ get_frame_register_bytes.
+
+ Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on
+ PPC platforms for e.g. O2_float_param: instead of seeing…
+
+ Temporary breakpoint 1, callee.increment (val=val@entry=99.0, msg=...) at callee.adb:19
+
+ … we get "optimized_out" for val. Passing next_frame to
+ get_frame_register_bytes fixes the issue.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-12-22 Tom Tromey <tromey@adacore.com>
+
+ Add 'program' to DAP 'attach' request
+ In many cases, it's not possible for gdb to discover the executable
+ when a DAP 'attach' request is used. This patch lets the IDE supply
+ this information.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-12-22 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: regenerate decode tables to avoid shadow warnings
+ Use latest cgen to regenerate the decode tables which has some shadow
+ warning fixes with "val" variables.
+
+ sim: cris: regen cgen decoders to fix build warnings [PR sim/31181]
+ Bug: https://sourceware.org/PR31181
+
+2023-12-22 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb: add git trailer information on gdb/MAINTAINERS
+ The project has been using Tested-By (tb), Reviewed-By (rb) and
+ Approved-By (ab) for some time, but there has been no information to be
+ found in the actual repository. This commit changes that by adding
+ information about all git trailers to the MAINTAINERS file, so that it
+ can be easily double-checked. Simply put, the trailers in use work as
+ follows:
+
+ * Tested-by: The person tested the patch and it fixes the problem, or
+ introduces no regressions (or both).
+ * Acked-by: The general outline looks good, but the maintainer hasn't
+ looked at the code
+ * Reviewed-by: The code looks good, but the reviewer has not approved
+ the patch to go upstream
+ * Approved-by: The patch is ready to be pushed to master
+
+ These last 3 trailers can also be restricted to one or more areas of GDB
+ by adding the areas in a comma separated list in parenthesis after the
+ trailers.
+
+ Finally, for completeness sake, the trailers Co-Authored-By and Bug
+ were added, even though they have been in use for a long time already
+
+ Reviewed-By: Kevin Buettner <kevinb@redhat.com>
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-22 Jan Beulich <jbeulich@suse.com>
+
+ nios2: fix .text/.data interaction with .previous
+ Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
+ need calling for .text/.data.
+
+2023-12-22 Jan Beulich <jbeulich@suse.com>
+
+ hppa/ELF: fix .text/.data interaction with .previous
+ For some ELF targets .text/.data are overridden. In that case
+ obj_elf_{text,data}() need calling, just like .code vectors to that
+ function for the remaining ELF targets.
+
+ While there also hand on the function arguments, even if right now
+ they're meaningless. This matches what other targets' code does.
+
+2023-12-22 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: drop .bss override
+ It doesn't look to be a good idea to override the custom handler that
+ ELF has; afaict doing so broke .previous, and a sub-section specifier
+ wasn't accepted either.
+
+2023-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: refuse "high" 8-bit regs with .insn and VEX/XOP/EVEX encodings
+ Much like REX, those encodings - if permitting 8-bit regs at all, i.e.
+ only starting with APX - permit use of "new" 8-bit registers only. %ah,
+ %ch, %dh, and %bh cannot be encoded and hence should be rejected.
+
+ Permit their use outside of 64-bit code though, as "new" registers
+ simply don't exist there.
+
+2023-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: properly respect rex/{rex}
+ This addresses two issues: For one, a user specified "rex" did not cause
+ the diagnostic to trigger when there was no other need for a REX prefix;
+ instead, another than the specified insn+operands was encoded. And then
+ (which is what this started from) .insn didn't respect {rex} (and was
+ otherwise similarly flawed as ordinary insns).
+
+ The latter requires splitting out code from md_assemble(), for it to
+ become re-usable. Besides the addition to address the first issue, that
+ code then also needs generalizing to account for immediate operands, as
+ with .insn we can't make assumptions anymore on all respective templates
+ having at most two operands (we still can build upon there being at most
+ two non-immediate operands, though). While moving the code also simplify
+ the first if(), by folding redundant checks.
+
+ In the new testcase also test a few more things which afaics weren't
+ tested till now.
+
+2023-12-22 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add support for the third expression of .align for R_LARCH_ALIGN
+ If the symbol index is not zero, the addend is used to represent
+ the first and the third expressions of the .align.
+
+ The lowest 8 bits are used to represent the first expression.
+ Other bits are used to represent the third expression.
+
+ The addend of R_LARCH_ALIGN for ".align 5, ,4" is 0x405.
+ The addend of R_LARCH_ALIGN for ".balign 32, ,4" is 0x405.
+
+2023-12-22 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: igen: fix -G handling
+ We weren't using the enable_p flag to see whether the option should
+ be enabled or disabled, and we weren't breaking out when done parsing.
+
+ sim: warnings: enable -Wreturn-type
+ Older versions of gcc support this warning flag. We're already clean.
+
+ sim: warnings: fix -Wreturn-mismatch typo
+
+ sim: m32c: fix initial #line number in generated code
+ This emits #line 2 for the first line in the output when it should be 1.
+
+ sim: mloop: add #line pragmas everywhere
+ This will make compiler diagnostics much better with generated code
+ so people can understand the original source file.
+
+2023-12-22 Mike Frysinger <vapier@gentoo.org>
+
+ sim: common: add $LINENO rewriting support to genmloop scripts
+ The generated mloop files can trigger compile time warnings. It can
+ be difficult to see/understand where the original code is coming from
+ as all the diagnostics point to the generated output. Using #line
+ pragmas, we can point people to the original source files.
+
+ Unfortunately, this code is written in POSIX shell, and that lacks
+ support for line number tracking. The $LINENO variable, even when
+ available, can just be plain wrong. For example, when using dash
+ and subshells, $LINENO can end up having negative values. Add a
+ wrapper script that will uses awk to rewrite the $LINENO variable
+ to the right value to avoid all that.
+
+ Basically lineno.sh takes an input script, rewrites all uses of
+ $LINENO into the actual line number (and $0 into the original file
+ name), and then executes the temporary script.
+
+ This commit doesn't actually add #line pragmas to any files. That
+ comes next.
+
+2023-12-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-21 Tom Tromey <tom@tromey.com>
+
+ Rename TUI locator window -> status
+ The TUI status window is called the "locator" in the source, but
+ "status" in the documentation. Whenever I've needed to find the code,
+ I've had to search to "locate" it (ha, ha). This patch renames the
+ window to match the public name of the window.
+
+ Rename tui-stack -> tui-status
+ The TUI status line is called the "status" window in the
+ documentation, but not in the source. There, the relevant files are
+ named "tui-stack", which to me makes it sound like they have something
+ to do with backtraces. This patch renames them to "tui-status".
+
+2023-12-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64
+ GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when
+ the linked libraries have dependencies on shared objects themselves:
+
+ $ gcc -m32 -o ei ei.c -lexecinfo
+ /var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
+ warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found
+ (try using -rpath or -rpath-link)
+ /var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
+ /usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0'
+ [...]
+
+ Fixed by handling FreeBSD/amd64 like Linux/x86.
+
+ Tested on amd64-pc-freebsd14.0.
+
+2023-12-21 Pedro Alves <pedro@palves.net>
+
+ Fix Clang build issue with flexible array member and non-trivial dtor
+ Commit d5cebea18e7a ("Make cached_reg_t own its data") added a
+ destructor to cached_reg_t.
+
+ That caused a build problem with Clang, which errors out like so:
+
+ > CXX python/py-unwind.o
+ > gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction
+ > 126 | cached_reg_t reg[];
+ > | ^
+
+ This is is not really a problem for our code, which allocates the
+ whole structure with xmalloc, and then initializes the array elements
+ with in-place new, and then takes care to call the destructor
+ manually. Like, commit d5cebea18e7a did:
+
+ @@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache)
+ cached_frame_info *cached_frame = (cached_frame_info *) cache;
+
+ for (int i = 0; i < cached_frame->reg_count; i++)
+ - xfree (cached_frame->reg[i].data);
+ + cached_frame->reg[i].~cached_reg_t ();
+
+ Maybe we should get rid of the flexible array member and use a bog
+ standard std::vector. I doubt this would cause any visible
+ performance issue.
+
+ Meanwhile, to unbreak the build, this commit switches from C99-style
+ flexible array member to 0-length array. It behaves the same, and
+ Clang doesn't complain. I got the idea from here:
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11
+
+ GCC 9, our oldest support version, already supported this:
+
+ https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html
+
+ but the extension is actually much older than that. Note that
+ C99-style flexible array members are not standard C++ either.
+
+ Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce
+
+2023-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: enable -Wimplicit-fallthrough=5
+ It caught some legitimate bugs, so clearly it's helpful.
+
+ sim: sh: fix -Wimplicit-fallthrough warnings
+ These generate conditional insns where it tests, then fallsthru.
+
+ sim: rx: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: rl78: fix -Wimplicit-fallthrough warnings
+ Seems like this code was meant to fallthru.
+
+ sim: riscv: fix -Wimplicit-fallthrough warnings
+
+ sim: ppc: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: or1k: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: mips: fix -Wimplicit-fallthrough warnings
+ Seems like these cases were meant to fallthru.
+
+ sim: mcore: fix Wimplicit-fallthrough warnings
+ Seems like these decodes were intended to fallthru.
+
+ sim: m68hc11: fix -Wimplicit-fallthrough warnings
+ Seems like these register operations intended on falling thru.
+
+ sim: frv: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: erc32: fix -Wimplicit-fallthrough warnings
+ Add the attribute where it seems to make sense.
+
+ sim: cris: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: bfin: fix -Wimplicit-fallthrough warnings
+ Add the attribute to places where we want to fall thru.
+
+ sim: avr: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: arm: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: aarch64: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute, and add some
+ default abort calls when the compiler can't figure out that the set
+ of values were already fully enumerated in the switch statement.
+
+ sim: common: fix -Wimplicit-fallthrough warnings
+ Replace some fall through comments with the attribute.
+
+ sim: add ATTRIBUTE_FALLTHROUGH for local code
+ We'll replace various /* fall through */ comments so compilers can
+ actually understand what the code is doing.
+
+ sim: signal: mark signal callback funcs as noreturn since they don't return
+ All funcs already call other funcs that don't return. The mips port is
+ the only exception because its generic exception handler can return in
+ the case of normal exceptions. So while the exceptions its signal handler
+ triggers doesn't return, we can't express that conditional logic. So add
+ some useless abort calls to make the compiler happy.
+
+ sim: sh: add missing breaks to bit processing
+ Doesn't seem like we want to cascade in this section when bit processing.
+
+ sim: rx: mark abort func as noreturn since it doesn't
+
+ sim: rx: add missing break to memory write
+ It doesn't seem like we want to keep executing the next block of code
+ after processing the request.
+
+ sim: iq2000: add fallback for exit syscall
+ Make sure this syscall always exits regardless of the exit code.
+
+ sim: cr16: add missing break statement
+ Doesn't seem to make sense for this to fall through
+ (although I'm not an expert in this ISA).
+
+ sim: arm: add missing breaks to SWI processing
+ Seems unlikely we want the remove syscall to fallthrough into the
+ rename syscall since we can't rename files that have been removed.
+
+ sim: common: mark engine restart as noreturn
+ This helps the compiler with optimization and fixes fallthru warnings.
+
+ sim: ppc: phb: add missing break to address decoder
+ I don't know what this emulation does exactly, but it missing a break
+ statement seems kind of obvious based on the 32-bit case above it.
+
+ sim: ppc: mark halt & restart funcs as noreturn
+ This helps the compiler with optimization and fixes fallthru warnings.
+
+ sim: warnings: enable -Wduplicated-cond
+
+ sim: mn10300: fix LAST_TIMER_REG typo
+ The compiler pointed out that we're testing LAST_TIMER_REG and
+ LAST_COUNTER which are the same value ... and that's because we
+ set LAST_TIMER_REG to the wrong register. Fix the typo.
+
+2023-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bfin: clean up astat reg name decode a little
+ The compiler pointed out we checked AZ twice. Sort by name to avoid
+ that in the future, and to make it clearer that we have coverage of
+ all the bits. And add the bits we were missing.
+
+ The order here doesn't matter as it's just turning a pointer into a
+ human readable string when store tracing is enabled.
+
+2023-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: common: delete unused scache in some mloop paths
+ The scache vars aren't used by ports in the pbb & fast codepaths,
+ nor are they documented as inputs to the callbacks, so delete them
+ to avoid unused variable compiler warnings.
+
+ sim: cgen: unify the genmloop logic a bit
+ Pull out the common parts of the genmloop invocation into the common
+ code. This will make it easier to add more, and make the per-port
+ differences a little more obvious.
+
+2023-12-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 31169 Source code locations can not be found in a C++ application
+ gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF
+ Version 3 or later.
+ From DWARF specification:
+ References that use the attribute form DW_FORM_ref_addr are specified to
+ be four bytes in the DWARF 32-bit format and eight bytes in the DWARF
+ 64-bit format, while DWARF Version 2 specifies that such references have
+ the same size as an address on the target system.
+
+ 2023-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/31169
+ * src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr.
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Fix handling of vanishing threads that were stepping/stopping
+ Downstream, AMD is carrying a testcase
+ (gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues
+ with the amd-dbgapi target's handling of exited threads. The test
+ can't be added upstream yet, unfortunately, due to dependency on DWARF
+ extensions that can't be upstreamed yet. However, it can be found on
+ the mailing list on the same series as this patch.
+
+ The test spawns a kernel with a number of waves. The waves do nothing
+ but exit. There is a breakpoint on the s_endpgm instruction. Once
+ that breakpoint is hit, the test issues a "continue" command. We
+ should see one breakpoint hit per wave, and then the whole program
+ exiting. We do see that, however we also see this:
+
+ [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
+ [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
+ *repeat for other waves*
+ ...
+ [Thread 0x7ffff626f640 (LWP 3048491) exited]
+ [Thread 0x7fffeb7ff640 (LWP 3048488) exited]
+ [Inferior 1 (process 3048475) exited normally]
+
+ That "New AMDGPU Wave" output comes from infrun.c itself adding the
+ thread to the GDB thread list, because it got an event for a thread
+ not on the thread list yet. The output shows "?"s instead of proper
+ coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED,
+ i.e., the wave was already gone when infrun.c added the thread to the
+ thread list.
+
+ That shouldn't ever happen for the amd-dbgapi target, threads should
+ only ever be added by the backend.
+
+ Note "New AMDGPU Wave ?:?:?:1" is for wave 1. What happened was that
+ wave 1 terminated previously, and a previous call to
+ amd_dbgapi_target::update_thread_list() noticed the wave had vanished
+ and removed it from the GDB thread list. However, because the wave
+ was stepping when it terminated (due to the displaced step over the
+ s_endpgm) instruction, it is guaranteed that the amd-dbgapi library
+ queues a WAVE_COMMAND_TERMINATED event for the exit.
+
+ When we process that WAVE_COMMAND_TERMINATED event, in
+ amd-dbgapi-target.c:process_one_event, we return it to the core as a
+ TARGET_WAITKIND_THREAD_EXITED event:
+
+ static void
+ process_one_event (amd_dbgapi_event_id_t event_id,
+ amd_dbgapi_event_kind_t event_kind)
+ {
+ ...
+ if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID
+ && event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED)
+ ws.set_thread_exited (0);
+ ...
+ }
+
+ Recall the wave is already gone from the GDB thread list. So when GDB
+ sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't
+ know about, it adds the thread to the thread list, resulting in that:
+
+ [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
+
+ and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB
+ marks the thread exited right afterwards:
+
+ [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
+
+ The fix is to make amd_dbgapi_target::update_thread_list() _not_
+ delete vanishing waves iff they were stepping or in progress of being
+ stopped. These two cases are the ones dbgapi guarantees will result
+ in a WAVE_COMMAND_TERMINATED event if the wave terminates:
+
+ /**
+ * A command for a wave was not able to complete because the wave has
+ * terminated.
+ *
+ * Commands that can result in this event are ::amd_dbgapi_wave_stop and
+ * ::amd_dbgapi_wave_resume in single step mode. Since the wave terminated
+ * before stopping, this event will be reported instead of
+ * ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP.
+ *
+ * The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE
+ * query. However, the wave will be invalid since it has already terminated.
+ * It is the client's responsibility to know what command was being performed
+ * and was unable to complete due to the wave terminating.
+ */
+ AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2,
+
+ As the comment says, it's GDB's responsability to know whether the
+ wave was stepping or being stopped. Since we now have a wave_info map
+ with one entry for each wave, that seems like the place to store that
+ information. However, I still decided to put all the coordinate
+ information in its own structure. I.e., basically renamed the
+ existing wave_info to wave_coordinates, and then added a new wave_info
+ structure that holds the new state, plus a wave_coordinates object.
+ This seemed cleaner as there are places where we only need to
+ instantiate a wave_coordinates object.
+
+ There's an extra twist. The testcase also exercises stopping at a new
+ kernel right after the first kernel fully exits. In that scenario, we
+ were hitting this assertion after the first kernel fully exits and the
+ hit of the breakpoint at the second kernel is handled:
+
+ [amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP
+ [amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list)
+ ../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+
+ This is the exact same problem as above, just a different
+ manifestation. In this scenario, we end up in update_thread_list
+ successfully deleting the exited thread (because it was no longer the
+ current thread) that was incorrectly added by infrun.c. Because it
+ was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread,
+ it doesn't have an entry in the wave_info map, so
+ amd_dbgapi_thread_deleted trips on this assertion:
+
+ gdb_assert (it != info->wave_info_map.end ());
+
+ here:
+
+ ...
+ -> stop_all_threads
+ -> update_thread_list
+ -> target_update_thread_list
+ -> amd_dbgapi_target::update_thread_list
+ -> thread_db_target::update_thread_list
+ -> linux_nat_target::update_thread_list
+ -> delete_exited_threads
+ -> delete_thread
+ -> delete_thread_1
+ -> gdb::observers::observable<thread_info*>::notify
+ -> amd_dbgapi_thread_deleted
+ -> internal_error_loc
+
+ The testcase thus tries both running to exit after the first kernel
+ exits, and running to a breakpoint in a second kernel after the first
+ kernel exits.
+
+ Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
+ Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Fix thread target ID of exited waves
+ Currently, if you step over kernel exit, you see:
+
+ stepi
+ [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
+ Command aborted, thread exited.
+ (gdb)
+
+ Those '?' are because the thread/wave is already gone by the time GDB
+ prints the "exited" notification, we can't ask dbgapi for any info
+ about the wave anymore.
+
+ This commit fixes it by caching the wave's coordinates as soon as GDB
+ sees the wave for the first time, and making
+ amd_dbgapi_target::pid_to_str use the cached info.
+
+ At first I thought of clearing the wave_info object from a
+ thread_exited observer. However, that is too soon, resulting in this:
+
+ (gdb) si
+ [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
+ Command aborted, thread exited.
+ (gdb) thread
+ [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)]
+
+ We need instead to clear the wave info when the thread is ultimately
+ deleted, so we get:
+
+ (gdb) si
+ [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
+ Command aborted, thread exited.
+ (gdb) thread
+ [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)]
+
+ And for that, we need a new thread_deleted observable.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
+ Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Step over thread exit, always delete the thread non-silently
+ With AMD GPU debugging, I noticed that when stepping over a breakpoint
+ placed on top of the s_endpgm instruction inline (displaced=off), GDB
+ would behave differently -- it wouldn't print the wave exit. E.g:
+
+ With displaced stepping, or no breakpoint at all:
+
+ stepi
+ [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
+ Command aborted, thread exited.
+ (gdb)
+
+ With inline stepping:
+
+ stepi
+ Command aborted, thread exited.
+ (gdb)
+
+ In the cases we see the "exited" notification, handle_thread_exit is
+ what first called delete_thread on the exiting thread, which is
+ non-silent.
+
+ With inline stepping, however, handle_thread_exit ends up in
+ update_thread_list (via restart_threads) before any delete_thread
+ call. Thus, amd_dbgapi_target::update_thread_list notices that the
+ wave is gone and deletes it with delete_thread_silent.
+
+ This commit fixes it, by making handle_thread_exited call
+ set_thread_exited (with the default silent=false) early, which emits
+ the user-visible notification.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ displaced_step_finish: Don't fetch the regcache of exited threads
+ displaced_step_finish can be called with event_status.kind ==
+ TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to
+ get at the already-exited thread's registers.
+
+ This patch moves the get_thread_regcache calls to branches that
+ actually need it, where we know the thread is still alive.
+
+ It also adds an assertion to get_thread_regcache, to help catching
+ these broken cases sooner.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Ensure selected thread after thread exit stop
+ While making step over thread exit work properly on AMDGPU, I noticed
+ that if there's a breakpoint on top of the exit syscall, and,
+ displaced stepping is off, then when GDB reports "Command aborted,
+ thread exited.", GDB also switches focus to a random thread, instead
+ of leaving the exited thread as selected:
+
+ (gdb) thread
+ [Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])]
+ (gdb) si
+ Command aborted, thread exited.
+ (gdb) thread
+ [Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))]
+ (gdb)
+
+ The previous patch extended gdb.threads/step-over-thread-exit.exp to
+ exercise this on GNU/Linux (on the CPU side), and there, after that
+ "si", we always end up with the exiting thread as selected even
+ without this fix, but that's just a concidence, there's a code path
+ that happens to select the exiting thread for an unrelated reason.
+
+ This commit add the explict switch, fixing the latent problem for
+ GNU/Linux, and the actual problem on AMDGPU. I wrote a gdb.rocm/
+ testcase for this, but it can't be upstreamed yet, until more pieces
+ of the DWARF machinery are upstream as well.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ gdb.threads/step-over-thread-exit.exp improvements
+ This commit makes the following improvements to
+ gdb.threads/step-over-thread-exit.exp:
+
+ - Add a third axis to stepping over the breakpoint with displaced vs
+ inline stepping -- also test with no breakpoint at all.
+
+ - Check that when GDB reports "Command aborted, thread exited.", the
+ selected thread is the thread that exited. This is always true
+ currently on GNU/Linux by coincidence, but a similar testcase on AMD
+ GPU exposed a problem here. Better make the testcase catch any
+ potential regression.
+
+ - Fixes a race that Simon ran into with GDBserver testing.
+
+ (gdb) next
+ [New Thread 2143071.2143438]
+
+ Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
+ 74 SYSCALL (my_exit, __NR_exit)
+ (gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits
+
+ I was not able to reproduce it, but I believe that what happens is
+ the following:
+
+ Once we continue, the thread 2 exits, and the main thread thus
+ unblocks from its pthread_join, and spawns a new thread. That new
+ thread may hit the breakpoint at my_exit_syscall very quickly. GDB
+ could then see/process that breakpoint event before the thread exit
+ event for the thread we care about, which would result in the
+ failure seen above.
+
+ The fix here is to not loop and start a new thread at all in the
+ scenario where the race can happen. We only need to loop and spawn
+ new threads when testing with "cmd=continue" and schedlock off, in
+ which case GDB doesn't abort the command when the thread exits.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Fix bug in previous remote unique_ptr change
+ By inspection, I noticed that the previous patch went too far, here:
+
+ @@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior *inf)
+ if (rs->remote_desc == NULL)
+ return;
+
+ - reply = (struct stop_reply *) rns->pending_event[notif_client_stop.id];
+ + stop_reply_up reply
+ + = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id]));
+
+ /* Discard the in-flight notification. */
+ if (reply != NULL && reply->ptid.pid () == inf->pid)
+
+ That is always moving the stop reply from pending_event, when we only
+ really want to peek into it. The code further below that even says:
+
+ /* Discard the in-flight notification. */
+ if (reply != NULL && reply->ptid.pid () == inf->pid)
+ {
+ /* Leave the notification pending, since the server expects that
+ we acknowledge it with vStopped. But clear its contents, so
+ that later on when we acknowledge it, we also discard it. */
+
+ This commit reverts that hunk back, adjusted to use unique_ptr::get().
+
+ Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Complete use of unique_ptr with notif_event and stop_reply
+ We already use unique_ptr with notif_event and stop_reply in some
+ places around the remote target, but not fully. There are several
+ code paths that still use raw pointers. This commit makes all of the
+ ownership of these objects tracked by unique pointers, making the
+ lifetime flow much more obvious, IMHO.
+
+ I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't
+ destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE
+ kind.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c
+
+2023-12-20 Pedro Alves <pedro@palves.net>
+
+ Make cached_reg_t own its data
+ struct cached_reg_t owns its data buffer, but currently that is
+ managed manually. Convert it to use a unique_xmalloc_ptr.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b
+
+2023-12-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove stale comment and ctor in gdbarch_info
+ tdesc_data is not part of a union, since commit 4f3681cc3361 ("Fix thread's
+ gdbarch when SVE vector length changes"). Remove the stale comment and
+ constructor.
+
+ Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Add suffix to conditional branch instruction descriptions
+ Suffix the instruction description of conditional branch extended
+ mnemonics with their condition (e.g. "on A high"). This complements
+ the optional printing of instruction descriptions as comments in the
+ disassembly.
+
+ Due to the added text the maximum description length is increased from
+ 80 to 128 characters (including the trailing '\0' character).
+
+ opcodes/
+ * s390-mkopc.c: Add suffix to conditional branch extended
+ mnemonic instruction descriptions.
+
+ gas/
+ * testsuite/gas/s390/zarch-insndesc.s: Add test cases for
+ printing of suffixed instruction description of conditional
+ branch extended mnemonics.
+ * testsuite/gas/s390/zarch-insndesc.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Optionally print instruction description in disassembly
+ Print instruction description as comment in disassembly with s390
+ architecture specific option "insndesc":
+
+ - For objdump it can be enabled with option "-M insndesc"
+ - In gdb it can be enabled with "set disassembler-options insndesc"
+
+ Since comments are not column aligned the output can enhanced for
+ readability by postprocessing using a filter such as "expand":
+
+ ... | expand -t 8,16,24,32,40,80
+
+ Or when using in combination with objdump option --visualize-jumps:
+
+ ... | expand | sed -e 's/ *#/\t#/' | expand -t 1,80
+
+ Note that the instruction descriptions add about 128 KB to s390-opc.o:
+
+ s390-opc.o without instruction descriptions: 216368 bytes
+ s390-opc.o with instruction descriptions : 348432 bytes
+
+ binutils/
+ * NEWS: Mention new s390-specific disassembler option
+ "insndesc".
+
+ include/
+ * opcode/s390.h (struct s390_opcode): Add field to hold
+ instruction description.
+
+ opcodes/
+ * s390-mkopc.c: Copy instruction description from s390-opc.txt
+ into generated operation code table s390-opc.tab.
+ * s390-opc.c (s390_opformats): Provide NULL as description in
+ .insn pseudo-mnemonics opcode table.
+ * s390-dis.c: Add s390-specific disassembler option "insndesc"
+ and optionally print the instruction description as comment in
+ the disassembly when it is specified.
+
+ gas/
+ * testsuite/gas/s390/s390.exp: Add new test disassembly test
+ case "zarch-insndesc".
+ * testsuite/gas/s390/zarch-insndesc.s: New test case for s390-
+ specific disassembler option "insndesc".
+ * testsuite/gas/s390/zarch-insndesc.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Use safe string functions and length macros in s390-mkopc
+ Use strncpy() and snprintf() instead of strcpy() and strcat(). Define
+ and use macros for string lengths, such as mnemonic, instruction
+ format, and instruction description.
+
+ This is a mechanical change, although some buffers have increased in
+ length by one character. This has been confirmed by verifying that the
+ generated opcode/s390-opc.tab is unchanged.
+
+ opcodes/
+ * s390-mkopc.c: Use strncpy() and strncat().
+
+ Suggested-by: Nick Clifton <nickc@redhat.com>
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Enhance error handling in s390-mkopc
+ When the s390-mkopc utility detects an error it prints an error message
+ to strerr and either continues processing or exists with a non-zero
+ return code. If it continues without detecting any further error the
+ final return code was zero, potentially hiding the detected error.
+
+ Introduce a global variable to hold the final return code and initialize
+ it to EXIT_SUCCESS. Introduce a helper function print_error() that
+ prints an error message to stderr and sets the final return code to
+ EXIT_FAILURE. Use it to print all error messages. Return the final
+ return code at the end of the processing.
+
+ While at it enhance error messages to state more clearly which mnemonic
+ an error was detected for. Also continue processing for cases where
+ subsequent mnemonics can be processed.
+
+ opcodes/
+ * s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE
+ in case of an error, otherwise EXIT_SUCCESS.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Provide IBM z16 (arch14) instruction descriptions
+ Provide descriptions for instructions introduced with commit ba2b480f103
+ ("IBM Z: Implement instruction set extensions"). This complements commit
+ 69341966def ("IBM zSystems: Add support for z16 as CPU name."). Use
+ instruction names from IBM z/Architecture Principles of Operation [1] as
+ instruction description.
+
+ [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
+ https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
+
+ opcodes/
+ * s390-opc.txt: Add descriptions for IBM z16 (arch14)
+ instructions.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Align letter case of instruction descriptions
+ Change the bitwise operations names "and" and "or" to lower case. Change
+ the register name abbreviations "FPR", "GR", and "VR" to upper case.
+
+ opcodes/
+ * s390-opc.txt: Align letter case of instruction descriptions.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Fix build when using EXEEXT_FOR_BUILD
+ Suffix the s390-mkopc build utility executable file name with
+ EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with
+ EXEEXT_FOR_BUILD. Use pattern used for other architecture build
+ utilities and compile and link s390-mkopc in two steps.
+
+ While at it also specify the dependencies of s390-mkopc.c.
+
+ opcodes/
+ * Makefile.am: Add target to build s390-mkopc.o. Correct
+ target to build s390-mkopc$(EXEEXT_FOR_BUILD).
+ * Makefile.in: Regenerate.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-20 Mike Frysinger <vapier@gentoo.org>
+
+ sim: frv: enable warnings in memory.c
+ Fix one minor pointer-sign warning to enable warnings in general
+ for this file. Reading the data as signed and then returning it
+ as unsigned should be functionally the same in this case.
+
+2023-12-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-19 Alan Modra <amodra@gmail.com>
+
+ Re: PR31145, potential memory leak in binutils/ld
+ Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY
+ iostream in io_reinit.
+
+ PR 31145
+ * format.c (io_reinit): Revert last change. Comment.
+ * opncls.c (_bfd_delete_bfd): Likewise.
+
+2023-12-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw
+ Here, we write single complete registers, we don't need the
+ functionality of put_frame_register_bytes, use put_frame_register
+ instead.
+
+ Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove stale comment in value_assign
+ This comment is no longer relevant, put_frame_register_bytes now accepts
+ the "next frame".
+
+ Change-Id: I077933a03f8bdb886f8ba10a98d1202a38bce0a9
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-19 Andrea Corallo <andrea.corallo@arm.com>
+
+ aarch64: Add FEAT_ITE support
+ This patch add support for FEAT_ITE "Instrumentation Extension" adding
+ the "trcit" instruction.
+
+ This is enabled by the +ite march flag.
+
+2023-12-19 Andrea Corallo <andrea.corallo@arm.com>
+
+ aarch64: Add FEAT_ECBHB support
+ This patch add support for FEAT_ECBHB "Exploitative control using
+ branch history information" adding the "clrbhb" instruction. AFAIU
+ the same alias was originally added as "clearbhb" before the
+ architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional
+ v8.0-a+/v9.0-a+).
+
+2023-12-19 Andrea Corallo <andrea.corallo@arm.com>
+
+ aarch64: Add FEAT_SPECRES2 support
+ This patch add supports for FEAT_SPECRES2 "Enhanced speculation
+ restriction instructions" adding the "cosp" instruction.
+
+ This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+. It is
+ enabled by the +predres2 march flag.
+
+2023-12-19 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb: register frame_destroyed function for amd64 gdbarch
+ gdbarches usually register functions to check when a frame is destroyed
+ which is used with software watchpoints, since the expression of the
+ watchpoint is no longer vlaid at this point. On amd64, this wasn't done
+ anymore because GCC started using CFA for variable locations instead.
+
+ However, clang doesn't use the CFA and instead relies on specifying when
+ an epilogue has started, meaning software watchpoints get a spurious hit
+ when a frame is destroyed. This patch re-adds the code to register the
+ function that detects when a frame is destroyed, but only uses this when
+ the producer is LLVM, so gcc code isn't affected. The logic that
+ identifies the epilogue has been factored out into the new function
+ amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
+ directly, and its behavior isn't changed.
+
+ This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
+ that handled this exact flaw in clang.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-19 Mike Frysinger <vapier@gentoo.org>
+
+ sim: common: delete unused argbuf in generated mloop code
+ This function only uses prev_abuf, not abuf, and doesn't inline code
+ from the various ports on the fly, so abuf will never be used.
+
+ sim: v850: fix -Wunused-variable warnings
+
+ sim: sh: fix -Wunused-variable warnings
+
+ sim: moxie: fix -Wunused-variable warnings
+
+ sim: msp430: fix -Wunused-variable warnings
+
+ sim: mn10300: fix -Wunused-variable warnings
+
+ sim: mips: fix -Wunused-variable warnings
+
+ sim: microblaze: fix -Wunused-variable warnings
+
+ sim: mcore: fix -Wunused-variable warnings
+
+ sim: m32r: fix -Wunused-variable warnings
+
+ sim: lm32: fix -Wunused-variable warnings
+
+ sim: iq2000: fix -Wunused-variable warnings
+
+ sim: h8300: fix -Wunused-variable warnings
+
+ sim: ft32: fix -Wunused-variable warnings
+
+ sim: frv: fix -Wunused-variable warnings
+
+ sim: erc32: fix -Wunused-variable warnings
+
+ sim: cris: fix -Wunused-variable warnings
+
+ sim: cr16: fix -Wunused-variable warnings
+
+ sim: bpf: fix -Wunused-variable warnings
+
+ sim: bfin: fix -Wunused-variable warnings
+
+ sim: aarch64: fix -Wunused-variable warnings
+
+ sim: common: fix -Wunused-variable warnings
+
+ cpu: cris: drop some unused vars
+ These fix unused variable warnings in the generated sim.
+
+2023-12-19 Haochen Jiang <haochen.jiang@intel.com>
+
+ x86: Remove the restriction for size of the mask register in AVX10
+ Since AVX10.1/256 will also allow 64 bit mask register, we will
+ remove the restriction for size of the mask register in AVX10.
+
+ gas/ChangeLog:
+
+ * config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
+ (VEX_check_encoding): Remove opcode_modifier check for vsz.
+ * testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
+ registers since they are not needed.
+ * testsuite/gas/i386/avx10-vsz.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-gen.c: Remove Vsz.
+ * i386-opc.h: Ditto.
+ * i386-opc.tbl: Remove kvsz.
+ * i386-tbl.h: Regenerated.
+
+2023-12-19 Xi Ruoyao <xry111@xry111.site>
+
+ LoongArch: Allow la.got -> la.pcrel relaxation for shared object
+ Even in shared objects, la.got -> la.pcrel relaxation can still be
+ performed for symbols with hidden visibility. For example, if a.c is:
+
+ extern int x;
+ int f() { return x++; }
+
+ and b.c is:
+
+ int x = 114514;
+
+ If compiling and linking with:
+
+ gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c
+
+ Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
+ should be like:
+
+ pcaddi $t0, x
+ ldptr.w $a0, $t0, 0
+ addi.w $t1, $a0, 1
+ stptr.w $t1, $t0, 0
+ ret
+
+ Remove bfd_link_executable from the condition of la.got -> la.pcrel
+ relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL
+ check is enough not to wrongly relax preemptable symbols (for e.g.
+ when -fvisibility=hidden is not used).
+
+ Note that on x86_64 this is also relaxed and the produced code is like:
+
+ lea x(%rip), %rdx
+ mov (%rdx), %rax
+ lea 1(%rax), %ecx
+ mov %ecx, (%rdx)
+ ret
+
+ Tested by running ld test suite, bootstrapping and regtesting GCC with
+ the patched ld, and building and testing Glibc with the patched ld. No
+ regression is observed.
+
+2023-12-19 Jeff Law <jeffreyalaw@gmail.com>
+
+ Yet another fix for mcore-sim (rotli)
+ This came up testing the CRC optimization work from Mariam@RAU.
+ Basically to optimize some CRC loops into table lookups or carryless
+ multiplies, we may need to do a bit reflection, which on the mcore
+ processor is done using a rotate instruction.
+
+ Unfortunately the simulator implementation of rotates has the exact same
+ problem as we saw with right shifts. The input value may have been sign
+ extended from 32 to 64 bits. When we rotate the extended value, we get
+ those sign extension bits and thus the wrong result.
+
+ The fix is the same. Rather than using a "long", use a uint32_t for the
+ type of the temporary. This fixes a handful of tests in the GCC testsuite:
+
+2023-12-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-18 Arsen Arsenović <arsen@aarsen.me>
+
+ gettext: disable install, docs targets, libasprintf, threads
+ This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by
+ Eric Gallager <egallager@gcc.gnu.org>.
+
+ ChangeLog:
+
+ * Makefile.def (gettext): Disable (via missing)
+ {install-,}{pdf,html,info,dvi} and TAGS targets. Set no_install
+ to true. Add --disable-threads --disable-libasprintf.
+ * Makefile.in: Regenerate.
+
+2023-12-18 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ ld: Print 0 size in B and not in GB
+ When using --print-memory-usage, the printed size can be zero and in
+ that case, the unit should be B and not GB.
+
+ ld/
+ * ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
+ * testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
+ * testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.
+
+2023-12-18 Alan Modra <amodra@gmail.com>
+
+ PR31162, Memory Leak in ldwrite.c
+ This isn't a particularly worrying memory leak, but fix it anyway.
+
+ PR 31162
+ * ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
+ Add %E to error messages.
+
+2023-12-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp
+ The gdb.threads/thread-specific-bp.exp test has been a little
+ problematic, see commits:
+
+ commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
+ Date: Thu Mar 9 12:31:26 2023 +0100
+
+ [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
+
+ and
+
+ commit 2e5843d87c4050bf1109921481fb29e1c470827f
+ Date: Fri Nov 19 14:33:39 2021 +0100
+
+ [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp
+
+ But I recently saw a test failure for that test, which looked like
+ this:
+
+ ...
+ (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
+ continue -a
+ Continuing.
+
+ Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
+ 29 }
+ (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
+ Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
+ FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
+ ...
+
+ This only crops up (for me) when running on a loaded machine, and
+ still only occurs sometimes. I've had to leave the test running in a
+ loop for 10+ minutes sometimes in order to see the failure.
+
+ The problem is that we use gdb_test_multiple to try and match two
+ patterns:
+
+ (1) The 'Thread-specific breakpoint 3 deleted ....' message, and
+ (2) The GDB prompt.
+
+ As written in the test, we understand that these patterns can occur in
+ any order, and we have a flag for each pattern. Once both patterns
+ have been seen then we PASS the test.
+
+ The problem is that once expect has matched a pattern, everything up
+ to, and including the matched text is discarded from the input
+ buffer. Thus, if the input buffer contains:
+
+ <PATTERN 2><PATTERN 1>
+
+ Then expect will first try to match <PATTERN 1>, which succeeds, and
+ then expect discards the entire input buffer up to the end of the
+ <PATTERN 1>. As a result, we will never spot <PATTERN 2>.
+
+ Obviously we can't just reorder the patterns within the
+ gdb_test_multiple, as the output can legitimately (and most often
+ does) occur in the other order, in which case the test would mostly
+ fail, and only occasionally pass!
+
+ I think the easiest solution here is just to have the
+ gdb_test_multiple contain two patterns, each pattern consists of the
+ two parts, but in the alternative orders, thus, for a particular
+ output configuration, only one regexp will match. With this change in
+ place, I no longer see the intermittent failure.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-18 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add call36 and tail36 pseudo instructions for medium code model
+ For tail36, it is necessary to explicitly indicate the temporary register.
+ Therefore, the compiler and users will know that the tail will use a register.
+
+ call36 func
+ pcalau18i $ra, %call36(func)
+ jirl $ra, $ra, 0;
+
+ tail36 $t0, func
+ pcalau18i $t0, %call36(func)
+ jirl $zero, $t0, 0;
+
+2023-12-18 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add new relocation R_LARCH_CALL36
+ R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
+ these two instructions must adjacent.
+
+ The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.
+
+2023-12-18 Georg-Johann Lay <avr@gjlay.de>
+
+ PR31177: Let region text start at __TEXT_REGION_ORIGIN___
+ The start of MEMORY region text currently starts hard-coded at 0.
+
+ The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.
+
+ For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.
+
+ If ok, please apply to master.
+ This one is also fine to back-port.
+
+ Johann
+
+ --
+
+ AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.
+
+ ld/
+ PR 31177
+ * scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
+ (MEMORY): Use as start address for the text region.
+
+2023-12-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-17 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: add more flags
+ We already build cleanly with these.
+
+2023-12-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-16 Hannes Domani <ssbssa@yahoo.de>
+
+ Use function entry point record only for entry values
+ PR28987 notes that optimized code sometimes shows the wrong
+ value of variables at the entry point of a function, if some
+ code was optimized away and the variable has multiple values
+ stored in the debug info for this location.
+
+ In this example:
+ ```
+ void foo()
+ {
+ int l_3 = 5, i = 0;
+ for (; i < 8; i++)
+ ;
+ test(l_3, i);
+ }
+ ```
+ When compiled with optimization, the entry point of foo is at
+ the test() function call, since everything else is optimized
+ away.
+ The debug info of i looks like this:
+ ```
+ (gdb) info address i
+ Symbol "i" is multi-location:
+ Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0
+ Range 0x13fd41600-0x13fd41600: the constant 1
+ Range 0x13fd41600-0x13fd41600: the constant 2
+ Range 0x13fd41600-0x13fd41600: the constant 3
+ Range 0x13fd41600-0x13fd41600: the constant 4
+ Range 0x13fd41600-0x13fd41600: the constant 5
+ Range 0x13fd41600-0x13fd41600: the constant 6
+ Range 0x13fd41600-0x13fd41600: the constant 7
+ Range 0x13fd41600-0x13fd4160f: the constant 8
+ (gdb) p i
+ $1 = 0
+ ```
+
+ Currently, when at the entry point of a function, it will
+ always show the initial value (here 0), while the user would
+ expect the last value (here 8).
+ This logic was introduced for showing the entry-values of
+ function arguments if they are available, but for some
+ reason this was added for non-entry-values as well.
+
+ One of the tests of amd64-entry-value.exp shows the same
+ problem for function arguments, if you "break stacktest"
+ in the following example, you stop at this line:
+ ```
+ 124 static void __attribute__((noinline, noclone))
+ 125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
+ 126 double d1, double d2, double d3, double d4, double d5, double d6,
+ 127 double d7, double d8, double d9, double da)
+ 128 {
+ 129 s1 = 3;
+ 130 s2 = 4;
+ 131 d9 = 3.5;
+ 132 da = 4.5;
+ 133 -> e (v, v);
+ 134 asm ("breakhere_stacktest:");
+ 135 e (v, v);
+ 136 }
+ ```
+ But `bt` still shows the entry values:
+ ```
+ s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
+ ```
+
+ I've fixed this by only using the initial values when
+ explicitely looking for entry values.
+
+ Now the local variable of the first example is as expected:
+ ```
+ (gdb) p i
+ $1 = 8
+ ```
+
+ And the test of amd64-entry-value.exp shows the expected
+ current and entry values of the function arguments:
+ ```
+ s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
+ Tested-By: Guinevere Larsen <blarsen@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Remove dependency on _rl_term_autowrap
+ Commit deb1ba4e38b ("[gdb/tui] Fix TUI resizing for TERM=ansi") introduced a
+ dependency on readline private variable _rl_term_autowrap.
+
+ There is precedent for this, but it's something we want to get rid of
+ (PR build/10723).
+
+ Remove the dependency on _rl_term_autowrap, and instead calculate
+ readline_hidden_cols by comparing the environment variable COLS with cols as
+ returned by rl_get_screen_size.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10723
+
+2023-12-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Show regs when switching to regs layout
+ When starting gdb in CLI mode, running to main and switching into the TUI regs
+ layout:
+ ...
+ $ gdb -q a.out -ex start -ex "layout regs"
+ ...
+ we get:
+ ...
+ +---------------------------------+
+ | |
+ | [ Register Values Unavailable ] |
+ | |
+ +---------------------------------+
+ ...
+
+ Fix this by handling this case in tui_data_window::rerender.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR tui/28600
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600
+
+2023-12-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Use more box_width in tui-regs.c
+ While experimenting with can_box () == false by default, I noticed two places
+ in tui-regs.c where we can replace a hardcoded 1 with box_width ().
+
+ It also turned out to be necessary to set scrollok to false, otherwise writing
+ the last char of the last line with register info will cause a scroll.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cr16: clean up unused insn operands
+ The push/pop insns only have 2 operands, so delete unused "c".
+
+ The pushret/popret insns use 2 operands, but they don't implement the
+ logic directly, they call the push/pop implementations. So delete the
+ unused "a" & "b".
+
+2023-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: adjust some dsp insn masks
+ The pmuls encoding is incorrect -- it looks like a copy & paste error
+ from the padd pmuls variant. The SuperH software manual covers this.
+
+ On the flip side, the manual lists pwsb & pwad as insns that exist,
+ but no description of what they do, what the insn name means, or the
+ actual encoding. Our sim implementation stubs them both out as nops.
+ Let's mark the fields to avoid unused variable warnings.
+
+2023-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: tidy up gencode slightly
+ Mark a few things static/const, and clean up trailing whitespace.
+
+ sim: bfin: fix typo in bf52x ports
+ These should be using the BF52x set of ports, not BF51x.
+
+ sim: warnings: enable -Wunused-but-set-variable
+
+ sim: mn10300: fix incorrect implementation of a few insns
+ Fix a few problems caught by compiler warnings:
+ * Some of the asr & lsr insns were setting up the c state flag,
+ but then forgetting to set it in the PSW. Add it like the other
+ asr & lsr variants.
+ * Some of the dmulh insns were multiplying one of the source regs
+ against itself instead of against the other source reg.
+ * The sat16_cmp parallel insn was using the wrong register in the
+ compare -- the reg1 src/dst pair are used in the sat16 op, and
+ the reg2 src/dst pair are used in the add op.
+
+2023-12-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-15 Tom Tromey <tromey@adacore.com>
+
+ Refine Ada overload matching
+ Currently, the overload handling in Ada assumes that any two array
+ types are compatible. However, this is obviously untrue, and a user
+ reported an oddity where comparing two Ada strings resulted in a call
+ to the "=" function for packed boolean arrays.
+
+ This patch improves the situation somewhat, by requiring that the two
+ arrays have the same arity and compatible base element types. This is
+ still over-broad, but it seems safe and is better than the status quo.
+
+2023-12-15 Tom Tromey <tromey@adacore.com>
+
+ Boolify ada_type_match
+ This changes ada_type_match to return bool.
+
+2023-12-15 John David Anglin <danglin@gcc.gnu.org>
+
+ Fix segmentation fault in bfd/elf32-hppa.c
+ 2023-12-15 John David Anglin <danglin@gcc.gnu.org>
+
+ PR ld/31148
+
+ bfd/ChangeLog:
+
+ * elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output
+ relative reloc only when eh->root.type is bfd_link_hash_defined
+ or bfd_link_hash_defweak.
+
+2023-12-15 Matthieu Longo <matthieu.longo@arm.com>
+
+ arm: reformat -march option section in gas documentation
+ Hi,
+
+ This patch contains a reformatting of -march option section in gas documentation.
+
+ For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options),
+ before all the options were on one line:
+ For armv8-a:
+ +crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables
+ Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier
+ Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction
+ Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions.
+ +nocrypto: Disables Cryptography Extensions.
+
+ Now, the readability is improved thanks to the itemization of the options:
+ For armv8-a:
+ +crc: Enables CRC32 Extension.
+ +simd: Enables VFP and NEON for Armv8-A.
+ +crypto: Enables Cryptography Extensions for Armv8-A, implies +simd.
+ +sb: Enables Speculation Barrier Instruction for Armv8-A.
+ +predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A.
+ +nofp: Disables all FPU, NEON and Cryptography Extensions.
+ +nocrypto: Disables Cryptography Extensions.
+
+ Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
+
+ Regards,
+ Matthieu.
+
+2023-12-15 Matthieu Longo <matthieu.longo@arm.com>
+
+ aarch64: Enable Cortex-X3 CPU
+ Hi,
+
+ This patch adds support for the Cortex-X3 CPU to binutils.
+
+ Gas regression testing for aarch64-none-linux-gnu target and found no regressions.
+
+ Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
+
+ Regards,
+
+ Matthieu.
+
+2023-12-15 Matthieu Longo <matthieu.longo@arm.com>
+
+ arm: document -march=armv9.[123]-a binutils options
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: last-insn recording should be per-subsection
+ Otherwise intermediate subsection switches result in inconsistent
+ behavior. Leverage ELF's section change hook to switch state as
+ necessary, limiting overhead to the bare minimum when subsections aren't
+ used.
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ ELF: reliably invoke md_elf_section_change_hook()
+ ... after any (sub)section change. While certain existing target hooks
+ only look at now_seg, for a few others it looks as if failing to do so
+ could have caused anomalies if sub-sections were used. In any event a
+ subsequent x86 change is going to require the sub-section to be properly
+ in place at the time the hook is invoked.
+
+ This primarily means for obj_elf_section() to pass the new subsection
+ into change_section(), for it to be set right away (ahead of invoking
+ the hook).
+
+ Also adjust obj_elf_ident() to invoke the hook after all section
+ changes. (Note that obj_elf_version(), which also changes sections and
+ then changes them back, has no hook invocation at all so far, so none
+ are added. Presumably there is a reason for this difference in
+ behavior.)
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ ELF: drop "push" parameter from obj_elf_change_section()
+ No caller outside of obj-elf.c cares about the parameter - drop it by
+ introducing an obj-elf.c-internal wrapper.
+
+ While adding the new function parameter, take the opportunity and change
+ the adjacent boolean one to "bool".
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't needlessly override .bss
+ ELF, COFF, and Mach-O all have custom handlers for .bss. Don't override
+ those; install a handler only for a.out.
+
+ revert "x86: allow 32-bit reg to be used with U{RD,WR}MSR"
+ This reverts commit 1f865bae65db9588f6994c02a92355bfb4e3d955. The
+ specification is going to by updated in a way rendering this change
+ wrong.
+
+ x86: fold assembly dialect attributes
+ Now that ATTSyntax and ATTMnemonic aren't use in combination anymore,
+ fold them and IntelSyntax into a single, enum-like attribute. Note that
+ this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's
+ not for long, seeing in-flight additions for APX).
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: Intel syntax implies Intel mnemonics
+ As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly
+ of fsub*/fdiv*") there's no such thing as Intel syntax without Intel
+ mnemonics. Enforce this on the assembler side, and disentangle command
+ line option handling on the disassembler side accordingly.
+
+ As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes
+ redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and
+ remove the then no longer accessible templates.
+
+2023-12-15 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: fix build for certain gcc versions
+ Some complain (by default) about isalpha shadowing ctype.h's isalpha().
+ Some also complain about signed/unsigned comparison a few lines later.
+
+2023-12-15 Georg-Johann Lay <avr@gjlay.de>
+
+ Addendum to PR31124
+ This is a small addendum to PR31124 "rodata in flash for
+ more AVR devices".
+
+ It adds some symbols so the startup code can set a lock
+ on the FLMAP bit field as specified by the user.
+
+ New symbols are introduced because otherwise, all the
+ computations / decisions would have to be performed at
+ run-time.
+
+ It approved, please apply to master.
+
+ Johann
+
+ --
+
+ ld/
+ PR 31124
+ * scripttempl/avr.sc: Adjust comments.
+ [MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock.
+ Remove __flmap_lsl4.
+
+2023-12-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: fix mloop.in variant stamp deps
+ The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053
+ accidentally listed the deps for all mloop steps as mloop.in instead of the
+ various variants that m32r uses.
+
+ Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
+
+2023-12-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: use @cpu@_fill_argbuf_tp to set trace & profile state
+ The mloop.in code does this, but these variants do not. Use it to
+ avoid unused function warnings. The fast_p logic in these files
+ also looks off, but that'll require a bit more work to fixup.
+
+ CC m32r/mloopx.o
+ m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
+ 37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
+ | ^~~~~~~~~~~~~~~~~~~~~
+
+ CC m32r/mloop2.o
+ m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
+ 37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
+ | ^~~~~~~~~~~~~~~~~~~~~
+
+ Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
+ Tested-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2023-12-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: igen: do not reindent literal semantics output
+ When generating semantics.c from .igen source files, indenting the code
+ makes it more readable, but confuses compiler diagnostics. The latter
+ is a bit more important than the former, so bias towards that.
+
+ For example, with an introduced error, we can see w/gcc-13:
+
+ (before this change)
+ CC mn10300/semantics.o
+ ../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
+ ../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function)
+ 11 | srcreg = translate_rreg (SD_, RN2);
+ | ^~~~~~
+
+ (with this change)
+ CC mn10300/semantics.o
+ ../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
+ ../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function)
+ 11 | srcreg = translate_rreg (SD_, RN2);
+ | ^~~~~~
+
+2023-12-15 Alan Modra <amodra@gmail.com>
+
+ regen ld POTFILES
+
+ PR31145, potential memory leak in binutils/ld
+ PR 31145
+ * bfd.c (BFD_IN_MEMORY): Mention that bim is malloc'd.
+ * format.c (io_reinit): Free BFD_IN_MEMORY iostream.
+ * opncls.c (_bfd_delete_bfd): Likewise.
+ (bfd_make_readable): Delete unnecessary code.
+ * bfd-in2.h: Regenerate.
+
+ Re: readelf..debug-dump=loc displays bogus base addresses
+ Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to
+ prevent segfaults when debug_info_p is NULL, which can be the case
+ with fuzzed objects. Restore those checks. Also, for dwo look at
+ rnglists_dwo rather than rnglists.
+
+2023-12-15 Xiao Zeng <zengxiao@eswincomputing.com>
+
+ RISC-V: Imply 'Zicntr' and 'Zihpm' implicitly depended on 'Zicsr'
+ This commit adds support for ratified extensions:
+ 'Zicntr' and 'Zihpm', Which are all implicitly depend on 'Zicsr'.
+
+ This is based on:
+ <https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Add 'Zicntr' and 'Zihpm' -> 'Zicsr'.
+ (riscv_supported_std_z_ext) Add 'Zicntr' and 'Zihpm' to the list.
+
+2023-12-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix -Wuse-after-free warning
+ Removed incorrect unnecessary code.
+
+ gprofng/ChangeLog
+ 2023-12-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/collctrl.cc (set_synctrace): Fix -Wuse-after-free warning.
+
+2023-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/options: fix copy&paste error in string_option_def
+ Spotted what appears to be a copy&paste error in string_option_def,
+ the code for string handling writes the address fetching callback
+ function into the option_def::var_address::enumeration location,
+ rather than option_def::var_address::string.
+
+ Of course, this works just fine as option_def::var_address is a union,
+ and all of its members are function pointers, so they're going to be
+ the same size on every target GDB cares about.
+
+ But it doesn't hurt to be correct, so fixed in this commit.
+
+ There should be no user visible changes after this commit.
+
+2023-12-14 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: add tests for unwinding of pseudo registers
+ This patch adds tests to exercise the previous patches' changes.
+
+ All three tests:
+
+ - aarch64-pseudo-unwind
+ - amd64-pseudo-unwind
+ - arm-pseudo-unwind
+
+ follow the same pattern, just with different registers.
+
+ The other test, arm-pseudo-unwind-legacy, tests the special case where
+ the unwind information contains an entry for a register considered a
+ pseudo-register by GDB.
+
+ Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Reviewed-by: Luis Machado <luis.machado@arm.com>
+ Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
+ Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: migrate arm to new gdbarch_pseudo_register_write
+ Make arm use the new gdbarch_pseudo_register_write. This fixes writing
+ pseudo registers to non-current frames for that architecture.
+
+ Change-Id: Icb2a649ab6394817844230e9e94c3d0564d2f765
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-by: Luis Machado <luis.machado@arm.com>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: migrate arm to gdbarch_pseudo_register_read_value
+ Make arm use the "newer" gdbarch_pseudo_register_read_value. This fixes
+ reading pseudo registers in non-current frames on that architecture.
+
+ Change-Id: Ic4d3d5d96957a4addfa3443c7b567dc4a31794a9
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-by: Luis Machado <luis.machado@arm.com>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: migrate aarch64 to new gdbarch_pseudo_register_write
+ Make aarch64 use the new gdbarch_pseudo_register_write. This fixes
+ writing pseudo registers to non-current frames on this architecture.
+
+ Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add missing raw register read in aarch64_sme_pseudo_register_write
+ It seems like the intention here is to read the contents of the ZA
+ register and only write part of it. However, there's no actual read of
+ the ZA register, so it looks like we'll write uninitialized bytes to the
+ target, for the portion of the raw register where we don't write the
+ pseudo register. Add a call to raw_read to fix this.
+
+ I don't know how to test this though.
+
+ Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-by: Luis Machado <luis.machado@arm.com>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make aarch64_za_offsets_from_regnum return za_offsets
+ This is not necessary, but it seems more natural to me to make
+ aarch64_za_offsets_from_regnum return a za_offsets object, rather than
+ fill an instance passed by parameter.
+
+ Change-Id: I40a185f055727da887ce7774be193eef1f4b9147
+ Approved-by: Luis Machado <luis.machado@arm.com>
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_write
+ Make i386 and amd64 use the new gdbarch_pseudo_register_write. This
+ fixes writing to pseudo registers in non-current frames for those
+ architectures.
+
+ Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add gdbarch_pseudo_register_write that takes a frame
+ Add a new variant of gdbarch_pseudo_register_write that takes a
+ frame_info in order to write raw registers. Use this new method when
+ available:
+
+ - in put_frame_register, when trying to write a pseudo register to a given frame
+ - in regcache::cooked_write
+
+ No implementation is migrated to use this new method (that will come in
+ subsequent patches), so no behavior change is expected here.
+
+ The objective is to fix writing pseudo registers to non-current
+ frames. See previous commit "gdb: read pseudo register through
+ frame" for a more detailed explanation.
+
+ Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename gdbarch_pseudo_register_write to gdbarch_deprecated_pseudo_register_write
+ The next patch introduces a new variant of gdbarch_pseudo_register_write
+ that takes a frame instead of a regcache for implementations to write
+ raw registers. Rename to old one to make it clear it's deprecated.
+
+ Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: change parameter name in frame_unwind_register_unsigned declaration
+ For consistency with the declarations around.
+
+ Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: read pseudo register through frame
+ Change gdbarch_pseudo_register_read_value to take a frame instead of a
+ regcache. The frame (and formerly the regcache) is used to read raw
+ registers needed to make up the pseudo register value. The problem with
+ using the regcache is that it always provides raw register values for
+ the current frame (frame 0).
+
+ Let's say the user wants to read the ebx register on amd64. ebx is a pseudo
+ register, obtained by reading the bottom half (bottom 4 bytes) of the
+ rbx register, which is a raw register. If the currently selected frame
+ is frame 0, it works fine:
+
+ (gdb) frame 0
+ #0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36
+ 36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
+ (gdb) p/x $ebx
+ $1 = 0x24252627
+ (gdb) p/x $rbx
+ $2 = 0x2021222324252627
+
+ But if the user is looking at another frame, and the raw register behind
+ the pseudo register has been saved at some point in the call stack, then
+ we get a wrong answer:
+
+ (gdb) frame 1
+ #1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
+ 56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
+ (gdb) p/x $ebx
+ $3 = 0x24252627
+ (gdb) p/x $rbx
+ $4 = 0x1011121314151617
+
+ Here, the value of ebx was computed using the value of rbx in frame 0
+ (through the regcache), it should have been computed using the value of
+ rbx in frame 1.
+
+ In other to make this work properly, make the following changes:
+
+ - Make dwarf2_frame_prev_register return nullptr if it doesn't know how
+ to unwind a register and that register is a pseudo register.
+ Previously, it returned `frame_unwind_got_register`, meaning, in our
+ example, "the value of ebx in frame 1 is the same as the value of ebx
+ in frame 0", which is obviously false. Return nullptr as a way to
+ say "I don't know".
+
+ - In frame_unwind_register_value, when prev_register (for instance
+ dwarf2_frame_prev_register) returns nullptr, and we are trying to
+ read a pseudo register, try to get the register value through
+ gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
+ If using gdbarch_pseudo_register_read, the behavior is known to be
+ broken. Implementations should be migrated to use
+ gdbarch_pseudo_register_read_value to fix that.
+
+ - Change gdbarch_pseudo_register_read_value to take a frame_info
+ instead of a regcache, update implementations (aarch64, amd64, i386).
+ In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
+ uses a frame instead of a regcache. The version using the regcache
+ is still used by i386_pseudo_register_write. It will get removed in
+ a subsequent patch.
+
+ - Add some helpers in value.{c,h} to implement the common cases of
+ pseudo registers: taking part of a raw register and concatenating
+ multiple raw registers.
+
+ - Update readable_regcache::{cooked_read,cooked_read_value} to pass the
+ current frame to gdbarch_pseudo_register_read_value. Passing the
+ current frame will give the same behavior as before: for frame 0, raw
+ registers will be read from the current thread's regcache.
+
+ Notes:
+
+ - I do not plan on changing gdbarch_pseudo_register_read to receive a
+ frame instead of a regcache. That method is considered deprecated.
+ Instead, we should be working on migrating implementations to use
+ gdbarch_pseudo_register_read_value instead.
+
+ - In frame_unwind_register_value, we still ask the unwinder to try to
+ unwind pseudo register values. It's apparently possible for the
+ debug info to provide information about [1] pseudo registers, so we
+ want to try that first, before falling back to computing them
+ ourselves.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/
+
+ Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add value::allocate_register
+ Add value::allocate_register, to facilitate allocating a value
+ representing a register in a given frame (or rather, in the given
+ frame's previous frame). It will be used in a subsequent patch. I
+ changed one relatively obvious spot that could use it, to at least
+ exercise the code path.
+
+ Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make get_frame_register_bytes take the next frame
+ Similar to the previous patches, change get_frame_register_bytes to take
+ the "next frame" instead of "this frame".
+
+ Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make put_frame_register_bytes take the next frame
+ Similar to the previous patches, change put_frame_register_bytes to take
+ the "next frame" instead of "this frame".
+
+ Change-Id: I27bcb26573686d99b231230823cff8db6405a788
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make put_frame_register take the next frame
+ Similar to the previous patches, change put_frame_register to take the
+ "next frame" instead of "this frame".
+
+ Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove frame_register
+ I was going to change frame_register to take the "next frame", but I
+ realized that doing so would make it a useless wrapper around
+ frame_register_unwind. So, just remove frame_register and replace uses
+ with frame_register_unwind.
+
+ Change-Id: I185868bc69f8e098124775d0550d069220a4678a
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: change value_of_register and value_of_register_lazy to take the next frame
+ Some functions related to the handling of registers in frames accept
+ "this frame", for which we want to read or write the register values,
+ while other functions accept "the next frame", which is the frame next
+ to that. The later is needed because we sometimes need to read register
+ values for a frame that does not exist yet (usually when trying to
+ unwind that frame-to-be).
+
+ value_of_register and value_of_register_lazy both take "this frame",
+ even if what they ultimately want internally is "the next frame". This
+ is annoying if you are in a spot that currently has "the next frame" and
+ need to call one of these functions (which happens later in this
+ series). You need to get the previous frame only for those functions to
+ get the next frame again. This is more manipulations, more chances of
+ mistake.
+
+ I propose to change these functions (and a few more functions in the
+ subsequent patches) to operate on "the next frame". Things become a bit
+ less awkward when all these functions agree on which frame they take.
+
+ So, in this patch, change value_of_register_lazy and value_of_register
+ to take "the next frame" instead of "this frame". This adds a lot of
+ get_next_frame_sentinel_okay, but if we convert the user registers API
+ to also use "the next frame" instead of "this frame", it will get simple
+ again.
+
+ Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make put_frame_register take an array_view
+ Change put_frame_register to take an array_view instead of a raw
+ pointer.
+
+ Add an assertion to verify that the number of bytes we try to write
+ matches the length of the register.
+
+ Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix bugs in {get,put}_frame_register_bytes
+ I found this only by inspection: the myaddr pointer in
+ {get,put}_frame_register_bytes is reset to `buffer.data ()` at each
+ iteration. This means that we will always use the bytes at the
+ beginning of `buffer` to read or write to the registers, instead of
+ progressing in `buffer`.
+
+ Fix this by re-writing the functions to chip away the beginning of the
+ buffer array_view as we progress in reading or writing the data.
+
+ These bugs was introduced almost 3 years ago [1], and yet nobody
+ complained. I'm wondering which architecture relies on that register
+ "overflow" behavior (reading or writing multiple consecutive registers
+ with one {get,put}_frame_register_bytes calls), and in which situation.
+ I find these functions a bit dangerous, if a caller mis-calculates
+ things, it could end up silently reading or writing to the next
+ register, even if it's not the intent.
+
+ If I could change it, I would prefer to have functions specifically made
+ for that ({get,put}_frame_register_bytes_consecutive or something like
+ that) and make {get,put}_frame_register_bytes only able to write within
+ a single register (which I presume represents most of the use cases of
+ the current {get,put}_frame_register_bytes). If a caller mis-calculates
+ things and an overflow occurs while calling
+ {get,put}_frame_register_bytes, it would hit an assert. The problem is
+ knowing which callers rely on the overflow behavior and which don't.
+
+ [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43
+
+ Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: change regcache interface to use array_view
+ Change most of regcache (and base classes) to use array_view when
+ possible, instead of raw pointers. By propagating the use of array_view
+ further, it enables having some runtime checks to make sure the what we
+ read from or write to regcaches has the expected length (such as the one
+ in the `copy(array_view, array_view)` function. It also integrates well
+ when connecting with other APIs already using gdb::array_view.
+
+ Add some overloads of the methods using raw pointers to avoid having to
+ change all call sites at once (which is both a lot of work and risky).
+
+ I tried to do this change in small increments, but since many of these
+ functions use each other, it ended up simpler to do it in one shot than
+ having a lot of intermediary / transient changes.
+
+ This change extends into gdbserver as well, because there is some part
+ of the regcache interface that is shared.
+
+ Changing the reg_buffer_common interface to use array_view caused some
+ build failures in nat/aarch64-scalable-linux-ptrace.c. That file
+ currently "takes advantage" of the fact that
+ reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which
+ IMO is dangerous. It uses raw_supply/raw_collect directly on
+ uint64_t's, which I guess is fine because it is expected that native
+ code will have the same endianness as the debugged process. To
+ accomodate that, add some overloads of raw_collect and raw_supply that
+ work on uint64_t.
+
+ This file also uses raw_collect and raw_supply on `char` pointers.
+ Change it to use `gdb_byte` pointers instead. Add overloads of
+ raw_collect and raw_supply that work on `gdb_byte *` and make an
+ array_view on the fly using the register's size. Those call sites could
+ be converted to use array_view with not much work, in which case these
+ overloads could be removed, but I didn't want to do it in this patch, to
+ avoid starting to dig in arch-specific code.
+
+ During development, I inadvertently changed reg_buffer::raw_compare's
+ behavior to not accept an offset equal to the register size. This
+ behavior (effectively comparing 0 bytes, returning true) change was
+ caught by the AArch64 SME core tests. Add a selftest to make sure that
+ this raw_compare behavior is preserved in the future.
+
+ Change-Id: I9005f04114543ddff738949e12d85a31855304c2
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_part
+ Make a few simplifications in these functions.
+
+ 1. When checking if we need to do nothing, if the length is 0, we don't
+ need to do anything, regardless of the value of offset. Remove the
+ offset check.
+
+ 2. When check if transferring the whole register, if the length is equal
+ to the register size, then we transfer the whole register, no need to
+ check the offset. Remove the offset check.
+
+ 3. In the gdb_asserts, it is unnecessary to check for:
+
+ offset <= reg_size
+
+ given that right after we check for:
+
+ len >= 0 && offset + len <= reg_size
+
+ If `offset + len` is <= reg_size and len is >= 0, then necessarily
+ offset is <= reg_size. Remove the `offset <= reg_size` check.
+
+ Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make store_integer take an array_view
+ Change store_integer, store_signed_integer and store_unsigned_integer to
+ accept an array_view. Add some backwards compatibility overloads to
+ avoid changing all callers at once.
+
+ Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h
+ Right now, gdbsupport/common-regcache.h contains two abstractons for a
+ regcache. An opaque type `regcache` (gdb and gdbserver both have their
+ own regcache that is the concrete version of this) and an abstract base
+ class `reg_buffer_common`, that is the base of regcaches on both sides.
+ These abstractions allow code to be written for both gdb and gdbserver,
+ for instance in the gdb/arch sub-directory.
+
+ However, having two
+ different abstractions is impractical. If some common code has a regcache,
+ and wants to use an operation defined on reg_buffer_common, it can't.
+ It would be better to have just one. Change all instances of `regcache
+ *` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix
+ fallouts.
+
+ Implementations in gdb and gdbserver now need to down-cast (using
+ gdb::checked_static_cast) from reg_buffer_common to their concrete
+ regcache type. Some of them could be avoided by changing free functions
+ (like regcache_register_size) to be virtual methods on
+ reg_buffer_common. I tried it, it seems to work, but I did not include
+ it in this series to avoid adding unnecessary changes.
+
+ Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: don't handle i386 k registers as pseudo registers
+ I think that i386 k registers are raw registers, and therefore shouldn't
+ be handled in the various functions handling pseudo registers.
+
+ What tipped me off is the code in i386_pseudo_register_read_into_value:
+
+ else if (i386_k_regnum_p (gdbarch, regnum))
+ {
+ regnum -= tdep->k0_regnum;
+
+ /* Extract (always little endian). */
+ status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf);
+
+ We take regnum (the pseudo register number we want to read), subtract
+ k0_regnum, add k0_regnum, and pass the result to raw_read. So we would
+ end up calling raw_read with the same regnum as the function received
+ which is supposedly a pseudo register number.
+
+ Other hints are:
+
+ - The command `maint print raw-registers` shows the k registers.
+ - Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be
+ called.
+ - There's code in i387-tdep.c to save/restore the k registers.
+
+ Remove handling of the k registers from:
+
+ - i386_pseudo_register_read_into_value
+ - i386_pseudo_register_write
+ - i386_ax_pseudo_register_collect
+
+ Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-14 Hannes Domani <ssbssa@yahoo.de>
+
+ Allow calling of variadic C++ functions
+ Currently, it's not possible to call a variadic C++ function:
+ ```
+ (gdb) print sum_vararg_int(1, 10)
+ Cannot resolve function sum_vararg_int to any overloaded instance
+ (gdb) print sum_vararg_int(2, 20, 30)
+ Cannot resolve function sum_vararg_int to any overloaded instance
+ ```
+
+ It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
+ rank by rank_function, which disqualifies the function.
+
+ To fix this, I've created the new VARARG_BADNESS rank, which is
+ used only for additional arguments of variadic functions, allowing
+ them to be called:
+ ```
+ (gdb) print sum_vararg_int(1, 10)
+ $1 = 10
+ (gdb) print sum_vararg_int(2, 20, 30)
+ $2 = 50
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-14 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Fix the wrong encoding and operand of the XTheadFmv extension.
+ The description of instructions 'th.fmv.hw.x' and 'th.fmv.x.hw' of the
+ XTheadFmv extension in T-Head specific is incorrect, and it also has
+ some impact on the implementation of the binutils, so this patch
+ corrects this.
+
+ For details see:
+ https://github.com/T-head-Semi/thead-extension-spec/pull/34
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-fmv.d: Correct test.
+ * testsuite/gas/riscv/x-thead-fmv.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_FMV_HW_X): Correct coding.
+ (MASK_TH_FMV_HW_X): Likewise.
+ (MATCH_TH_FMV_X_HW): Likewise.
+ (MASK_TH_FMV_X_HW): Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Correct operands.
+
+2023-12-14 Cui, Lili <lili.cui@intel.com>
+
+ Remove redundant Byte, Word, Dword and Qword from insn templates.
+ opcodes/ChangeLog:
+
+ * i386-opc.tbl: Remove redundant Byte, Word, Dword and Qword.
+
+2023-12-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-13 Tom Tromey <tom@tromey.com>
+
+ Use unique_xmalloc_ptr in explicit_location_spec
+ This changes explicit_location_spec to use unique_xmalloc_ptr,
+ removing some manual memory management.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-13 Tom Tromey <tom@tromey.com>
+
+ Use unique_xmalloc_ptr in linespec_location_spec
+ This changes linespec_location_spec to use unique_xmalloc_ptr,
+ removing some manual memory management.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-13 H.J. Lu <hjl.tools@gmail.com>
+
+ Update Make const_1_mode print $1 in AT&T syntax
+ commit b70a487d5945b13e5ab503be4fc37b964819ec0e
+ Author: Cui, Lili <lili.cui@intel.com>
+ Date: Wed Dec 13 06:07:36 2023 +0000
+
+ Make const_1_mode print $1 in AT&T syntax
+
+ changes disassembler output from
+
+ d1 f8 sar %eax
+
+ to
+
+ d1 f8 sar $1,%eax
+
+ Adjust pe-x86-64-6.od accordingly.
+
+ * testsuite/ld-x86-64/pe-x86-64-6.od: Adjusted.
+
+2023-12-13 Magne Hov <mhov@undo.io>
+
+ [gdb/tui] add SingleKey bindings for reverse execution commands
+ The bindings for the reverse execution commands are the same letters
+ as the forward execution command, but with the opposite case. This way
+ one can simply hold down the Shift modifier key or tap the Caps Lock key
+ to change the direction of execution.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: avoid use of _PyOS_ReadlineTState
+ In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState,
+ however, this variable is no longer public in Python 3.13, and so GDB
+ no longer builds.
+
+ We are making use of _PyOS_ReadlineTState in order to re-acquire the
+ Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState
+ variable is set in Python's outer readline code prior to calling the
+ user (GDB) supplied readline callback function, which for us is
+ gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called
+ without the GIL held.
+
+ Instead of using _PyOS_ReadlineTState, I propose that we switch to
+ calling PyGILState_Ensure() and PyGILState_Release(). These functions
+ will acquire the GIL based on the current thread. I think this should
+ be sufficient; I can't imagine why we'd be running
+ gdbpy_readline_wrapper on one thread on behalf of a different Python
+ thread.... that would be unexpected I think.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-13 Alexandra Hájková <ahajkova@redhat.com>
+
+ gdb: move gdbpy_gil into python-internal.h
+ Move gdbpy_gil class into python-internal.h, the next
+ commit wants to make use of this class from a file other
+ than python.c.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: improve error reporting for 'save gdb-index'
+ While making recent changes to 'save gdb-index' command I triggered
+ some errors -- of the kind a user might be expected to trigger if they
+ do something wrong -- and I didn't find GDB's output as helpful as it
+ might be.
+
+ For example:
+
+ $ gdb -q /tmp/hello.x
+ ...
+ (gdb) save gdb-index /non_existing_dir
+ Error while writing index for `/tmp/hello': mkstemp: No such file or directory.
+
+ That the error message mentions '/tmp/hello', which does exist, but
+ doesn't mention '/non_existing_dir', which doesn't is, I think,
+ confusing.
+
+ Also, I find the 'mkstemp' in the error message confusing for a user
+ facing error. A user might not know what mkstemp means, and even if
+ they do, that it appears in the error message is an internal GDB
+ detail. The user doesn't care what function failed, but wants to know
+ what was wrong with their input, and what they should do to fix
+ things.
+
+ Similarly, for a directory that does exist, but can't be written to:
+
+ (gdb) save gdb-index /no_access_dir
+ Error while writing index for `/tmp/hello': mkstemp: Permission denied.
+
+ In this case, the 'Permission denied' might make the user thing there
+ is a permissions issue with '/tmp/hello', which is not the case.
+
+ After this patch, the new errors are:
+
+ (gdb) save gdb-index /non_existing_dir
+ Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.
+
+ and:
+
+ (gdb) save gdb-index /no_access_dir
+ Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.
+
+ we also have:
+
+ (gdb) save gdb-index /tmp/not_a_directory
+ Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.
+
+ I think these do a better job of guiding the user towards fixing the
+ problem.
+
+ I've added a new test that exercises all of these cases, and also
+ checks the case where a user tries to use an executable that already
+ contains an index in order to generate an index. As part of the new
+ test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
+ into a new proc (get_index_type), which I've then used in the new
+ test. I've confirmed that all the tests that use ensure_gdb_index
+ still pass.
+
+ During review it was pointed out that the testsuite proc
+ have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
+ I've rewritten have_index to also use get_index_type, I've confirmed
+ that all the tests that use have_index still pass.
+
+ Nothing that worked correctly before this patch should give an error
+ after this patch; I've only changed the output when the user was going
+ to get an error anyway.
+
+ Reviewed-By: Tom de Vries <tdevries@suse.de>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-13 Cui, Lili <lili.cui@intel.com>
+
+ Make const_1_mode print $1 in AT&T syntax
+ Make const_1_mode print $1 in AT&T syntax, otherwise
+ there will be correctness issues when it is extended
+ to support APX NDD,
+
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/intel.d: Adjust testcase.
+ * testsuite/gas/i386/lfence-load.d: Ditto.
+ * testsuite/gas/i386/noreg16-data32.d: Ditto.
+ * testsuite/gas/i386/noreg16.d: Ditto.
+ * testsuite/gas/i386/noreg32-data16.d: Ditto.
+ * testsuite/gas/i386/noreg32.d: Ditto.
+ * testsuite/gas/i386/noreg64-data16.d: Ditto.
+ * testsuite/gas/i386/noreg64-rex64.d: Ditto.
+ * testsuite/gas/i386/noreg64.d: Ditto.
+ * testsuite/gas/i386/opcode-suffix.d: Ditto.
+ * testsuite/gas/i386/opcode.d: Ditto.
+ * testsuite/gas/i386/x86-64-lfence-load.d: Ditto.
+ * testsuite/gas/i386/x86-64-opcode.d: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (OP_I): Make const_1_mode print $1 in AT&T syntax.
+
+2023-12-13 Cui, Lili <lili.cui@intel.com>
+
+ Clean base_reg and assign correct values to regs for input_output_operand (%dx).
+ For special processing of input and output operands (%dx),
+ the state of some variables needs to be cleaned.
+
+ gas/ChangeLog:
+
+ * config/tc-i386.c (i386_att_operand): Assign values to regs and
+ clean i.base_reg for input output operand (%dx).
+
+2023-12-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-12 Stefano Moioli <smxdev4@gmail.com>
+
+ gdbserver/win32: fix crash on detach
+ this patch fixes a crash in gdbserver whenever a process is detached.
+ the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors`
+
+ error message:
+
+ Detaching from process 184
+ ../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec
+ ted.
+ remove_process: Assertion `find_thread_process (process) == NULL' failed.
+
+ This application has requested the Runtime to terminate it in an unusual way.
+ Please contact the application's support team for more information.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-12 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix gdb.FinishBreakpoint when returning to an inlined function
+ Currently, when creating a gdb.FinishBreakpoint in a function
+ called from an inline frame, it will never be hit:
+ ```
+ (gdb) py fb=gdb.FinishBreakpoint()
+ Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
+ (gdb) c
+ Continuing.
+ Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list.
+ [Inferior 1 (process 1208) exited normally]
+ ```
+
+ The reason is that the frame_id of a breakpoint has to be the
+ ID of a real frame, ignoring any inline frames.
+
+ With this fixed, it's working correctly:
+ ```
+ (gdb) py fb=gdb.FinishBreakpoint()
+ Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
+ (gdb) c
+ Continuing.
+
+ Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47
+ (gdb) py print(fb.return_value)
+ -8
+ ```
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-12 Hannes Domani <ssbssa@yahoo.de>
+
+ Support dynamically computed convenience variables in get_internalvar_integer
+ When using $_thread in info threads to showonly the current thread,
+ you get this error:
+ ```
+ (gdb) info thread $_thread
+ Convenience variable must have integer value.
+ Args must be numbers or '$' variables.
+ ```
+
+ It's because $_thread is a dynamically computed convenience
+ variable, which isn't supported yet by get_internalvar_integer.
+
+ Now the output looks like this:
+ ```
+ (gdb) info threads $_thread
+ Id Target Id Frame
+ * 1 Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-12 Georg-Johann Lay <avr@gjlay.de>
+
+ Support rodata in flash for more AVR devices
+ PR 31124
+ * Makefile.am (ALL_EMULATION_SOURCES): Add eavrxmega2_flmap.c and eavrxmega4_flmap.c.
+ * Makefile.in: Regenerate.
+ * configure.tgt: Add eavrxmega2_flmap and eavrxmega4_flmap to avr's targ_extra_emuls list.
+ * emulparams/avrxmega2.sh (MAYBE_FLMAP): Define.
+ * emulparams/avrxmega2_flmap.sh: New file.
+ * emulparams/avrxmega4.sh (MAYBE_FLMAP): Define.
+ * emulparams/avrxmega4_flmap.sh: New file.
+ * scripttempl/avr.sc: Add support for HAVE_FLMAP.
+
+2023-12-12 Nick Clifton <nickc@redhat.com>
+
+ Fix whitespace snafu in tc-riscv.c
+
+2023-12-12 Rui Ueyama <rui314@gmail.com>
+
+ RISC-V: Emit R_RISCV_RELAX for the la/lga pseudo instruction
+ Some psABIs define a relaxation to turn a GOT load into a PC-relative
+ address materialization. For example, the AArch64's psABI allows
+ adrp+ldr to be rewritten to nop+adr to eliminate the memory load.
+ This patch is part of the effort to make such optimization possible
+ for RISC-V.
+
+ For RISC-V, we use the la assembly pseudo instruction to load a symbol
+ address from the GOT. The pseudo instruction is expanded to auipc+ld.
+ If the address loaded by the instruction pair is actually a PC-relative
+ link-time constant, we want the linker to rewrite the instruction pair
+ with auipc+addi.
+
+ We can't rewrite all existing auipc+ld pairs with auipc+addi in the
+ linker because there might be code that jumps to the middle of the
+ instruction pair. That should be extremely rare, if ever exists, but
+ you can at least in theory write a program in assembly that jumps to
+ the ld instruction of the instruction pair. We need a marker to
+ identify that an auipc+ld can be safely relaxed (i.e. they are emitted
+ for la).
+
+ This patch is to annotate R_RISCV_GOT_HI20 with R_RISCV_RELAX only
+ when the relocation is emitted for the la pseudo instruction. The
+ linker will use it as a signal that the instruction pair can be safely
+ relaxed.
+
+ Proposal to the RISC-V psABI:
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/397
+
+ gas/
+ * config/tc-riscv.c (source_macro): New static int variable.
+ The identifier of the assembler macro we are expanding, if any.
+ (append_insn): Updated source_macro to tc_fix_data, to record
+ which macro expands, if any.
+ (macro): Record which macro expands into source_macro. Reset
+ source_macro to -1 at the end.
+ (md_apply_fix): Apply R_RISCV_RELAX if pcrel_got_hi is expanded
+ from macro LA/LGA.
+ * config/tc-riscv.h (struct riscv_fix, TC_FIX_TYPE, TC_INIT_FIX_DATA):
+ Defined to record source_macro into fixups for riscv target.
+ * testsuite/gas/riscv/la-variants.d: Updated.
+
+2023-12-12 Lifang Xia <lifang_xia@linux.alibaba.com>
+
+ RISC-V: Resolve PCREL_HI20/LO12_I/S fixups with local symbols while `-mno-relax'
+ In the scenario of generating .ko files, the kernel does not relax the .ko
+ files. However, due to the large amount of relax and local relocation
+ information, this increases the size of the .ko files. In this patch, it
+ will finish the fixup of the local relocations while with `-mno-relax' option.
+ This can reduce the size of the relocation table.
+
+ The implemntation is based on the code from bfd/elfnn-riscv.c. We probably
+ can move the code to bfd/elfxx-riscv.c, so that can reduce duplicate code,
+ just like what we did for the architecture parser.
+
+ Besides, maybe not only pcrel_hi/lo12 relocation with local symbols can be
+ resolved at assembler time. Other pc-relative relocation, like branch,
+ may also be able to perform related optimizations.
+
+ Passed the gcc/binutils regressions of riscv-gnu-toolchain.
+
+ gas/
+ * config/tc-riscv.c (riscv_pcrel_hi_reloc): New structure. Record all
+ PC-relative high-part relocation that we have encountered to help us
+ resolve the corresponding low-part relocation later.
+ (riscv_pcrel_hi_fixup_hash): The hash table to record pcrel_hi fixups.
+ (riscv_pcrel_fixup_hash): New function. Likewise.
+ (riscv_pcrel_fixup_eq): Likewise.
+ (riscv_record_pcrel_fixup): Likewise.
+ (md_begin): Init pcrel_hi hash table.
+ (md_apply_fix): For PCREL_HI20 relocation, do fixup and record
+ the pcrel_hi relocs, mark as done while with `-mno-relax'. For
+ PCREL_LO12_I/S relocation, do fixup and mark as done while with
+ `-mno-relax'.
+ (riscv_md_end): New function. Free pcrel_hi hash table.
+ * config/tc-riscv.h (md_end): Define md_end with riscv_md_end.
+ gas/
+ * testsuite/gas/riscv/fixup-local*: New tests.
+
+2023-12-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP cancellation
+ This implements DAP cancellation. A new object is introduced that
+ handles the details of cancellation. While cancellation is inherently
+ racy, this code attempts to make it so that gdb doesn't inadvertently
+ cancel the wrong request.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Catch KeyboardInterrupt in send_gdb_with_response
+ Cancellation will generally be seen by the DAP code as a
+ KeyboardInterrupt. However, this derives from BaseException and not
+ Exception, so a small change is needed to send_gdb_with_response, to
+ forward the exception to the DAP server thread.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Rename a couple of DAP procs in the testsuite
+ This renames a couple of DAP procs in the testsuite, to clarify that
+ they are now exported. The cancellation test will need these.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Introduce gdb.interrupt
+ DAP cancellation needs a way to interrupt whatever is happening on
+ gdb's main thread -- whether that is the inferior, a gdb CLI command,
+ or Python code.
+
+ This patch adds a new gdb.interrupt() function for this purpose. It
+ simply sets the quit flag and lets gdb do the rest.
+
+ No tests in this patch -- instead this is tested via the DAP
+ cancellation tests.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Move DAP JSON reader to its own thread
+ This changes the DAP server to move the JSON reader to a new thread.
+ This is key to implementing request cancellation, as now requests can
+ be read while an earlier one is being serviced.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Clean up handling of DAP not-stopped response
+ This patch introduces a new NotStoppedException type and changes the
+ DAP implementation of "not stopped" to use it. I was already touching
+ some code in this area and I thought this looked a little cleaner.
+ This also has the advantage that we can now choose not to log the
+ exception -- previously I was sometimes a bit alarmed when seeing this
+ in the logs, even though it is harmless.
+
+ Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Simplify DAP stop-reason code
+ Now that gdb adds stop-reason details to stop events, we can simplify
+ the DAP code to emit correct stop reasons in its own events. For the
+ most part a simple renaming of gdb reasons is sufficient; however,
+ "pause" must still be handled specially.
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Emit stop reason details in Python stop events
+ This changes Python stop events to carry a "details" dictionary, that
+ holds any relevant information about the stop. The details are
+ constructed using more or less the same procedure as is done for MI.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Move py_ui_out to a new header
+ This moves the declaration of py_ui_out to a new header, so that it
+ can more readily be used by other code.
+
+2023-12-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix $eol regexp usage in some test-cases
+ Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced:
+ ...
+ set eol "\[\r\n\]+"
+ ...
+ with the more strict:
+ ...
+ set eol "\r\n"
+ ...
+ in a few test-cases, but didn't update all uses of eol accordingly.
+
+ Fix this in three gdb.ada test-cases.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-11 Tom Tromey <tom@tromey.com>
+
+ Use TARGET_SYSROOT_PREFIX in more places
+ I found some spots using "target:"; I think it's better to use the
+ define everywhere, so this changes these to use TARGET_SYSROOT_PREFIX.
+ In some spots, is_target_filename is used rather than an explicit
+ check.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-11 Tom Tromey <tromey@adacore.com>
+
+ Add DAP items to NEWS
+ Now that DAP is in GDB 14, significant changes to it should be noted
+ in NEWS. This patch adds a note for a fix that's already gone in. I
+ started a new section in NEWS because more changes are coming.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-12-11 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix dynamic_cast
+ PR29011 notes that dynamic_cast does not work correctly if
+ classes with virtual methods are involved, some of the results
+ wrongly point into the vtable of the derived class:
+ ```
+ (gdb) p vlr
+ $1 = (VirtualLeftRight *) 0x162240
+ (gdb) p vl
+ $2 = (VirtualLeft *) 0x162240
+ (gdb) p vr
+ $3 = (VirtualRight *) 0x162250
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
+ $4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vl)
+ $5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vr)
+ $6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
+ (gdb) p dynamic_cast<VirtualLeft*>(vlr)
+ $7 = (VirtualLeft *) 0x162240
+ (gdb) p dynamic_cast<VirtualLeft*>(vl)
+ $8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
+ (gdb) p dynamic_cast<VirtualLeft*>(vr)
+ $9 = (VirtualLeft *) 0x162240
+ (gdb) p dynamic_cast<VirtualRight*>(vlr)
+ $10 = (VirtualRight *) 0x162250
+ (gdb) p dynamic_cast<VirtualRight*>(vl)
+ $11 = (VirtualRight *) 0x162250
+ (gdb) p dynamic_cast<VirtualRight*>(vr)
+ $12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
+ ```
+
+ For the cases where the dynamic_cast type is the same as the
+ original type, it used the ARG value for the result, which in
+ case of pointer types was already the dereferenced value.
+
+ And the TEM value at the value address was created with the
+ pointer/reference type, not the actual class type.
+
+ With these fixed, the dynamic_cast results make more sense:
+ ```
+ (gdb) p vlr
+ $1 = (VirtualLeftRight *) 0x692240
+ (gdb) p vl
+ $2 = (VirtualLeft *) 0x692240
+ (gdb) p vr
+ $3 = (VirtualRight *) 0x692250
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
+ $4 = (VirtualLeftRight *) 0x692240
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vl)
+ $5 = (VirtualLeftRight *) 0x692240
+ (gdb) p dynamic_cast<VirtualLeftRight*>(vr)
+ $6 = (VirtualLeftRight *) 0x692240
+ (gdb) p dynamic_cast<VirtualLeft*>(vlr)
+ $7 = (VirtualLeft *) 0x692240
+ (gdb) p dynamic_cast<VirtualLeft*>(vl)
+ $8 = (VirtualLeft *) 0x692240
+ (gdb) p dynamic_cast<VirtualLeft*>(vr)
+ $9 = (VirtualLeft *) 0x692240
+ (gdb) p dynamic_cast<VirtualRight*>(vlr)
+ $10 = (VirtualRight *) 0x692250
+ (gdb) p dynamic_cast<VirtualRight*>(vl)
+ $11 = (VirtualRight *) 0x692250
+ (gdb) p dynamic_cast<VirtualRight*>(vr)
+ $12 = (VirtualRight *) 0x692250
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-11 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add support for <b ".L1"> and <beq, $t0, $t1, ".L1">
+ Support symbol names enclosed in double quotation marks.
+
+2023-12-11 Konstantin Isakov <ikm@zbackup.org>
+
+ bfd_find_nearest_line leaks dwarf_rnglists_buffer
+ * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free dwarf_rnglists_buffer.
+
+2023-12-11 Alan Modra <amodra@gmail.com>
+
+ regen bfd POTFILES
+
+2023-12-11 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V/gas: Clarify the definition of `relaxable' in md_apply_fix
+ The `relaxable' in md_apply_fix means if the relocation can be relaxed or not
+ in link-time generally. We can use `.option relax/norelax' to enable/disable
+ relaxations for some specific areas, so the value of `riscv_opts.relax'
+ will be changed dynamically. The `fixP->fx_tcbit' records the correct value
+ of `riscv_opts.relax' for every relocation. Therefore, set `relaxable' to
+ `riscv_opts.relax' will cause unexpected behavior for the following case,
+
+ .option norelax
+ lla a1, foo1
+ .option relax
+ lla a2, foo2
+ .option norelax
+ lla a3, foo3
+
+ For the current assembler, the final value of `riscv_opts.relax' is false, so
+ the second `lla a2, foo2' won't have R_RISCV_RELAX relocation, but should have.
+
+ gas/
+ * config/tc-riscv.c (md_apply_fix): Set the value of `relaxable' to
+ `riscv_opts.relax' is wrong. It should be `true' generally.
+
+2023-12-11 Alan Modra <amodra@gmail.com>
+
+ R_MICROMIPS_GPREL7_S2
+ This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
+ match/mask encoding in `micromips_opcodes'. It is correctly specified
+ to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
+ and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
+ code like _bfd_mips_elf32_gprel16_reloc.
+
+ Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
+ is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
+ when little-endian. Big-endian behaviour is unchanged after this
+ patch and little-endian correctly applies the reloc to byte 0x11.
+
+ The patch also corrects REL addend extraction from section contents,
+ and overflow checking. gold had all of the bfd problems with this
+ reloc and additionally did not apply the rightshift by two.
+
+ bfd/
+ * elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
+ R_MICROMIPS_GPREL7_S2.
+ (mips_elf_calculate_relocation): Correct sign extension and
+ overflow calculation for R_MICROMIPS_GPREL7_S2.
+ (_bfd_mips_elf_relocate_section): Update small-data overflow
+ message.
+ gold/
+ * mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
+ Return false for R_MICROMIPS_GPREL7_S2.
+ (Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
+ (Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
+ handling.
+ (Mips_relocate_functions::relgprel7): New function.
+ (Target_mips::Relocate::relocate): Adjust to suit.
+ ld/
+ * testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
+ * testsuite/ld-mips-elf/reloc-5.d: Likewise.
+
+2023-12-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-10 Tom Tromey <tom@tromey.com>
+
+ Fix "not not" in Python documentation
+ I noticed a "not not" in the Python documentation where just "not" was
+ meant. This patch fixes the error.
+
+2023-12-10 Tom Tromey <tom@tromey.com>
+
+ Add some new DW_IDX_* constants
+ I've reimplemented the .debug_names code in GDB -- it was quite far
+ from being correct, and the new implementation is much closer to what
+ is specified by DWARF.
+
+ However, the new writer in GDB needs to emit some symbol properties,
+ so that the reader can be fully functional. This patch adds a few new
+ DW_IDX_* constants, and tries to document the existing extensions as
+ well. (My patch series add more documentation of these to the GDB
+ manual as well.)
+
+ 2023-12-10 Tom Tromey <tom@tromey.com>
+
+ * dwarf2.def (DW_IDX_GNU_internal, DW_IDX_GNU_external): Comment.
+ (DW_IDX_GNU_main, DW_IDX_GNU_language, DW_IDX_GNU_linkage_name):
+ New constants.
+
+2023-12-10 Jeff Law <jeffreyalaw@gmail.com>
+
+ Improve performance of the H8 simulator
+ Running the H8 port through the GCC testsuite currently takes 4h 30m on my
+ fastest server -- that's roughly 1.5hrs per multilib tested and many tests are
+ disabled for various reasons.
+
+ To put that 1.5hr/multilib in perspective, that's roughly 3X the time for other
+ embedded targets. Clearly something isn't working as well as it should.
+
+ A bit of digging with perf shows that we're spending a crazy amount of time
+ decoding instructions in the H8 simulator. It's not hard to see why --
+ basically we take a blob of instruction data, then try to match it to every
+ instruction in the H8 opcode table starting at the beginning. That table has
+ ~8000 entries (each different addressing mode is considered a different
+ instruction in the table).
+
+ Naturally my first thought was to sort the table and use a binary search to
+ find the right entry. That's made excessively complex due to the encoding on
+ the H8. Just getting the sort right would be much more complex than I'd
+ consider advisable.
+
+ Another thought was to build a mapping to the right entry for all the
+ instructions that can be disambiguated based on the first nibble (4 bits) of
+ instruction data and a mapping for those which can be disambiguated based on
+ the first byte of instruction data.
+
+ That seemed feasible until I realized that the H8/SX did some truly horrid
+ things with encoding branches in the 0x4XYY opcode space. It uses an "always
+ zero" bit in the offset to encode new semantic information. So we can't select
+ on just 0x4X. Ugh!
+
+ We could always to a custom decoder. I've done several through the years, they
+ can be very fast. But no way I can justify the time to do that.
+
+ So what I settled on was to first sort the opcode table by the first nibble,
+ then find the index of the first instruction for each nibble. Decoding uses
+ that index to start its search. This cuts the overall build/test by more than
+ half.
+
+ Next I adjusted the sort so that instructions that are not available on the
+ current sub architecture are put at the end of the table. This shaves another
+ ~15% off the total cycle time.
+
+ The net of the two changes is on my fastest server we've gone from 4:30 to 1:40
+ running the GCC testsuite. Same test results before/after, of course. It's
+ still not fast, but it's a hell of a lot better.
+
+2023-12-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Handle shared border in fixed-sized layout
+ In tui_layout_split::apply I noticed that for variable-size layouts we take
+ share_box into account by decreasing used_size:
+ ...
+ used_size += info[i].size;
+ if (info[i].share_box)
+ --used_size;
+ ...
+ but not for fixed-size layouts:
+ ...
+ if (info[i].min_size == info[i].max_size)
+ available_size -= info[i].min_size;
+ ...
+
+ Fix this by increasing available_size for fixed-size layouts with shared box.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Show focus window in status line
+ The focused window is highlighted by using active-border-kind instead of
+ border-kind.
+
+ But if the focused window is the cmd window (which is an unboxed window), then
+ no highlighting is done, and it's not obvious from looking at the screen which
+ window has the focus. Instead, you have to notice the absence of highlighting
+ on boxed windows, and then infer that the focus is on the unboxed window.
+
+ That approach stops working if there are multiple unboxed windows.
+
+ Likewise if highlighting is switched off by setting active-border-kind to the
+ same value as border-kind.
+
+ Make it more explicit which window has the focus by mentioning it in the status
+ window, like so:
+ ...
+ native process 8282 (src) In: main L7 PC: 0x400525
+ ...
+
+ Tested on x86_64-linux and ppc64le-linux.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix printing of global variable stubs if no inferior is running
+ Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
+ to print a global variable stub without a running inferior, because of
+ a missing nullptr-check (the block_scope function took care of that
+ check before it was converted to a method).
+
+ With this check it works again:
+ ```
+ (gdb) print s
+ $1 = <incomplete type>
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: tighten up some end-of-line patterns
+ Following on from the previous commit, I searched the testsuite for
+ places where we did:
+
+ set eol "<some pattern>"
+
+ in most cases the <some pattern> could be replaced with "\r\n" though
+ in the stabs test I've switched to using the multi_line proc as that
+ seemed like a better choice.
+
+ In gdb.ada/info_types.exp I did need to add an extra use of $eol as
+ the previous pattern would match multiple newlines, and in this one
+ place we were actually expecting to match multiple newlines. The
+ tighter pattern only matches a single newline, so we now need to be
+ explicit when multiple newlines are expected -- I think this is a good
+ thing.
+
+ All the tests are still passing for me after these changes.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.ada/complete.exp timeout in READ1 mode
+ While reviewing another patch I spotted a timeout in
+ gdb.ada/complete.exp when testing in READ1 mode, e.g.:
+
+ $ make check-read1 TESTS="gdb.ada/complete.exp"
+ ...
+ FAIL: gdb.ada/complete.exp: complete break ada (timeout)
+ ...
+
+ The problem is an attempt to match the entire output from GDB within a
+ single gdb_test_multiple pattern, for a completion command that
+ returns a large number of completions.
+
+ This commit changes the gdb_test_multiple to process the output line
+ by line. I don't use the gdb_test_multiple -lbl option, as I've
+ always found that option backward -- it checks for the \r\n at the
+ start of each line rather than the end, I think it's much clearer to
+ use '^' at the start of each pattern, and '\r\n' at the end, so that's
+ what I've done here.
+
+ .... Or I would, if this test didn't already define $eol as the end of
+ line regexp ... except that $eol was set to '[\r\n]*', which isn't
+ that helpful, so I've updated $eol to be just '\r\n' the actual end of
+ line regexp.
+
+ And now, the test passes without a timeout when using READ1.
+
+ There should be no change in what is tested after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use
+ Building on the last commit, which added a general --debug=COMPONENT
+ option to the gdbserver command line, this commit updates the monitor
+ command to allow for general:
+
+ (gdb) monitor set debug COMPONENT off|on
+
+ style commands. Just like with the previous commit, the COMPONENT can
+ be any one of all, threads, remote, event-loop, and correspond to the
+ same set of global debug flags.
+
+ While on the command line it is possible to do:
+
+ --debug=remote,event-loop,threads
+
+ the components have to be entered one at a time with the monitor
+ command. I guess there's no reason why we couldn't allow component
+ grouping within the monitor command, but (to me) what I have here
+ seemed more in the spirit of GDB's existing 'set debug ...' commands.
+ If people want it then we can always add component grouping later.
+
+ Notice in the above that I use 'off' and 'on' instead of '0' and '1',
+ which is what the 'monitor set debug' command used to use. The 0/1
+ can still be used, but I now advertise off/on in all the docs and help
+ text, again, this feels more inline with GDB's existing boolean
+ settings.
+
+ I have removed the two existing monitor commands:
+
+ monitor set remote-debug 0|1
+ monitor set event-loop-debug 0|1
+
+ These are replaced by:
+
+ monitor set debug remote off|on
+ monitor set debug event-loop off|on
+
+ respectively.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: allow the --debug command line option to take a value
+ Currently, gdbserver has the following command line options related to
+ debugging output:
+
+ --debug
+ --remote-debug
+ --event-loop-debug
+
+ This doesn't scale well. If I want an extra debug component I need to
+ add another command line flag.
+
+ This commit changes --debug to take a list of components.
+
+ The currently supported components are: all, threads, remote, and
+ event-loop. The 'threads' component represents the debug we currently
+ get from the --debug option. And if --debug is used without a
+ component list then the threads component is assumed as the default.
+
+ Currently the threads component actually includes a lot of output that
+ is not really threads related. In the future I'd like to split this
+ up into some new, separate components. But that is not part of this
+ commit, or even this series.
+
+ The special component 'all' does what you'd expect: enables debug
+ output from all supported components.
+
+ The component list is parsed left to write, and you can prefix a
+ component with '-' to disable that component, so I can write:
+
+ target> gdbserver --debug=all,-event-loop
+
+ to get debug for all components except the event-loop component.
+
+ I've removed the existing --remote-debug and --event-loop-debug
+ command line options, these are equivalent to --debug=remote and
+ --debug=event-loop respectively, or --debug=remote,event-loop to
+ enable both components.
+
+ In this commit I've only update the command line options, in the next
+ commit I'll update the monitor commands to support a similar
+ interface.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables
+ The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
+ flags, which can be passed to make in order to enable debugging within
+ GDB or gdbserver respectively.
+
+ However, when I do:
+
+ make check-gdb GDB_DEBUG=infrun
+
+ I don't see the corresponding debug feature within GDB being enabled.
+ Nor does:
+
+ make check-gdb GDBSERVER_DEBUG=debug \
+ RUNTESTFLAGS="--target_board=native-extended-gdbserver"
+
+ Appear to enable gdbserver debugging.
+
+ I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
+ missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
+ variable already contains lots of testing related flags, like
+ RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
+ GDBSERVER_DEBUG here too.
+
+ With this done, this debug feature is now working as expected.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Hannes Domani <ssbssa@yahoo.de>
+
+ Use pretty printers for struct member stubs
+ PR29079 shows that pretty printers can be used for an incomplete
+ type (stub), but only when printing it directly, not if it's
+ part of another struct:
+ ```
+ (gdb) p s
+ $1 = {pp m_i = 5}
+ (gdb) p s2
+ $2 = {m_s = <incomplete type>, m_l = 20}
+ ```
+
+ The reason is simply that in common_val_print the check for stubs
+ is before any pretty printer is tried.
+ It works if the pretty printer is tried before the stub check:
+ ```
+ (gdb) p s
+ $1 = {pp m_i = 5}
+ (gdb) p s2
+ $2 = {m_s = {pp m_i = 10}, m_l = 20}
+ ```
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix displaying main after resizing
+ A TUI src window is displaying either:
+ - the source for the current frame,
+ - the source for main, or
+ - the string "[ No Source Available ]".
+
+ Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
+ we're able to resize the TUI to 1 line without crashing.
+
+ I noticed that if TUI is displaying main, and we resize to 1 line (destroying
+ the src window) and then back to a larger terminal (reconstructing the src
+ window), the TUI displays "[ No Source Available ]" instead of main.
+
+ Fix this by moving the responsibility for showing main from tui_enable to
+ tui_source_window_base::rerender.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Tom Tromey <tom@tromey.com>
+
+ Allow cast of 128-bit integer to pointer
+ PR rust/31082 points out that casting a 128-bit integer to a pointer
+ will fail. This happens because a case in value_cast was not
+ converted to use GMP.
+
+ This patch fixes the problem. I am not really sure that testing
+ against the negative value here makes sense, but I opted to just
+ preserve the existing behavior rather than change it.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082
+
+2023-12-08 Tom Tromey <tom@tromey.com>
+
+ Fix dynamic type resolution for LOC_CONST and LOC_CONST_BYTES symbols
+ PR rust/31005 points out that dynamic type resolution of a LOC_CONST
+ or LOC_CONST_BYTES symbol will fail, leading to output like:
+
+ from_index=<error reading variable: Cannot access memory at address 0x0>
+
+ This patch fixes the problem by using the constant value or bytes when
+ performing type resolution.
+
+ Thanks to tpzker@thepuzzlemaker.info for a first version of this
+ patch.
+
+ I also tested this on a big-endian PPC system (cfarm203).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
+
+2023-12-08 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb: Guarantee that an SAL's end is right before the next statement
+ When examining a failure that happens when testing
+ gdb.python/py-symtab.c with clang, I noticed that it was going wrong
+ because the test assumed that whenever we get an SAL, its end would
+ always be right before statement in the line table. This is true for GCC
+ compiled binaries, since gcc only adds statements to the line table, but
+ not true for clang compiled binaries.
+
+ This is the second time I run into a problem where GDB doesn't handle
+ non-statement line table entries correctly. The other was eventually
+ committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
+ behavior with trailing !is_stmt lines", but that commit only changes the
+ behavior for the 'until' command. In this patch I propose a more general
+ solution, making it so every time we generate the SAL for a given pc, we
+ set the end of the SAL to before the next statement or the first
+ instruciton in the next line, instead of naively assuming that to be the
+ case.
+
+ With this new change, the edge case is removed from the processing of
+ the 'until' command without regressing the accompanying test case, and
+ no other regressions were observed in the testsuite.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: aarch64: fix -Wunused-but-set-variable warnings
+
+ sim: common: fix -Wunused-but-set-variable warnings
+
+ sim: ppc: fix -Wunused-but-set-variable warnings
+
+ sim: v850: fix -Wunused-but-set-variable warnings
+
+ sim: sh: fix -Wunused-but-set-variable warnings
+
+ sim: msp430: fix -Wunused-but-set-variable warnings
+
+ sim: mips: fix -Wunused-but-set-variable warnings
+
+ sim: mcore: fix -Wunused-but-set-variable warnings
+
+ sim: m68hc11: fix -Wunused-but-set-variable warnings
+
+ sim: h8300: fix -Wunused-but-set-variable warnings
+
+ sim: ft32: fix -Wunused-but-set-variable warnings
+
+ sim: frv: fix -Wunused-but-set-variable warnings
+
+ sim: erc32: fix -Wunused-but-set-variable warnings
+
+ sim: d10v: fix -Wunused-but-set-variable warnings
+
+ sim: cris: fix -Wunused-but-set-variable warnings
+ We suppress the warning in the generated switch file because the cris
+ cpu file has a hack to workaround a cgen bug, but that generates a set
+ but unused variable which makes the compiler upset.
+
+ sim: bfin: fix -Wunused-but-set-variable warnings
+
+ sim: bfin: gui: fix -Wunused-but-set-variable warnings
+ Rework the code to use static inline functions when it's disabled
+ rather than macros so the compiler knows the various function args
+ are always used. The ifdef macros are a bit ugly, but get the job
+ done without duplicating the function prototypes.
+
+ sim: arm: fix -Wunused-but-set-variable warnings
+
+ sim: m32r: fix syslog call
+ The function returns void, not int. We only pass one argument to
+ syslog (the format), so use %s as the static format instead since
+ the emulation layer doesn't handle passing additional arguments.
+
+2023-12-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: include more glibc headers for the funcs we use [PR sim/29752]
+ Not exactly portable, but doesn't make the situation worse here, and
+ fixes a lot of implicit function warnings.
+
+ Bug: https://sourceware.org/PR29752
+
+2023-12-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: add more cgen prototypes for traps
+ The traps file uses a bunch of functions directly without prototypes,
+ and we can't safely include the relevant cpu*.h files for them.
+
+2023-12-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: add more cgen prototypes to enable -Werror in most files
+
+2023-12-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: disable -Wenum-conversion fow now [PR sim/29752]
+ The cgen code mixes virtual insn enums with insn enums, and there isn't
+ an obvious (to me) way to unravel this atm, so disable the warning.
+
+ sim/lm32/decode.c:45:5: error:
+ implicit conversion from enumeration type 'CGEN_INSN_VIRTUAL_TYPE'
+ to different enumeration type 'CGEN_INSN_TYPE' (aka 'enum cgen_insn_type')
+ [-Werror,-Wenum-conversion]
+ 45 | { VIRTUAL_INSN_X_INVALID, LM32BF_INSN_X_INVALID, LM32BF_SFMT_EMPTY },
+ | ~ ^~~~~~~~~~~~~~~~~~~~~~
+
+ Bug: https://sourceware.org/PR29752
+
+2023-12-07 Cupertino Miranda <cupertino.miranda@oracle.com>
+
+ gdb/record: Support for rdtscp in i386_process_record.
+ This patch adds support for process recording of the instruction rdtscp in
+ x86 architecture.
+ Debugging applications with "record full" fail to record with the error
+ message "Process record does not support instruction 0xf01f9".
+
+ Approved-by: Guinevere Larsen <blarsen@redhat.com>
+
+2023-12-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: support dlopen in -lc
+ Stop assuming that dlopen is only available via -ldl. Newer versions
+ of glibc have merged it into -lc which broke this configure test.
+
+ sim: cris: move generated file to right place
+ Not sure why this ended up in the topdir, but it belongs under cris/.
+
+ sim: warnings: add more flags
+ Sync with the list of flags from gdbsupport, and add a few more of
+ our own to catch recent issues. Comment out the C++-specific flags
+ as we don't build with C++.
+
+2023-12-07 Kevin Buettner <kevinb@redhat.com>
+
+ Add more 'step' tests to gdb.base/watchpoint.exp
+ The test gdb.base/watchpoint.exp has a proc named 'test_stepping'
+ which claims to "Test stepping and other mundane operations with
+ watchpoints enabled". It sets a watchpoint on ival2, performs an
+ inferior function call (which is not at all mundane), and uses 'next',
+ 'until', and, finally, does a 'step'.
+
+ However, that final 'step' command steps to (but not over/through) the
+ line at which the assignment to ival2 takes place. At no time while
+ performing these operations is a watchpoint hit.
+
+ This commit adds a test to see what happens when stepping over/through
+ the assignment to ival2. The watchpoint on ival2 should be triggered
+ during this step. I've added another 'step' to make sure that the
+ correct statement is reached after performing the watchpoint-hitting
+ step.
+
+ After running the 'test_stepping' proc, gdb.base/watchpoint.exp does
+ a clean_restart before doing further tests, so nothing depends upon
+ 'test_stepping' to stop at the particular statement at which it had
+ been stopping.
+
+ I've examined all tests which set watchpoints and step. I haven't
+ been able to identify a(nother) test case which tests what happens
+ when stepping over/through a statement which triggers a watchpoint.
+ Therefore, adding these new 'step' tests is testing something which
+ hasn't being tested elsewhere.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-12-07 Palmer Dabbelt <palmer@rivosinc.com>
+
+ RISC-V: Fix "withand" in LEB128 error messages
+ This was split over multiple lines and ended up missing a space.
+
+ Reported-by: David Abdurachmanov <davidlt@rivosinc.com>
+
+2023-12-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-06 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix DLL export forwarding
+ I noticed it when I was trying to set a breakpoint at ExitProcess:
+ ```
+ (gdb) b ExitProcess
+ Breakpoint 1 at 0x14001fdd0
+ (gdb) r
+ Starting program: C:\qiewer\heob\heob64.exe
+ Warning:
+ Cannot insert breakpoint 1.
+ Cannot access memory at address 0x3dbf4120
+ Cannot insert breakpoint 1.
+ Cannot access memory at address 0x77644120
+ ```
+
+ The problem doesn't exist in gdb 13.2, and the difference can easily be
+ seen when printing ExitProcess.
+ gdb 14.1:
+ ```
+ (gdb) p ExitProcess
+ $1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
+ ```
+ gdb 13.2:
+ ```
+ (gdb) p ExitProcess
+ $1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
+ ```
+
+ The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
+ where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
+ relative to DLL_NAME before.
+
+ Fixed by calculating VMA relative to DLL_NAME again.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-06 Tom Tromey <tromey@adacore.com>
+
+ Fix minor grammar error in gdb.texinfo
+ This fixes a small grammar issue in gdb.texinfo -- "additional" was
+ written where "additionally" is correct.
+
+ Remove quick_symbol_functions::expand_matching_symbols
+ The only caller of quick_symbol_functions::expand_matching_symbols was
+ removed, so now this method and all implementations of it can be
+ removed.
+
+ Remove split_style::UNDERSCORE
+ The recent changes to the way Ada names are matched means that
+ split_style::UNDERSCORE is no longer used. This patch removes it.
+
+2023-12-06 Tom Tromey <tromey@adacore.com>
+
+ Always use expand_symtabs_matching in ada-lang.c
+ The previous patch fixed the immediate performance problem with Ada
+ name matching, by having a subset of matches call
+ expand_symtabs_matching rather than expand_matching_symbols. However,
+ it seemed to me that expand_matching_symbols should not be needed at
+ all.
+
+ To achieve this, this patch changes ada_lookup_name_info::split_name
+ to use the decoded name, rather than the encoded name. In order to
+ make this work correctly, a new decoded form is used: one that does
+ not decode operators (this is already done) and also does not decode
+ wide characters. The latter change is done so that changes to the Ada
+ source charset don't affect the DWARF index.
+
+ With this in place, we can change ada-lang.c to always use
+ expand_symtabs_matching rather than expand_matching_symbols.
+
+2023-12-06 Tom Tromey <tromey@adacore.com>
+
+ Improve performance of Ada name searches
+ A user reported that certain operations -- like printing a large
+ structure -- could be slow. I tracked this down to
+ ada-lang.c:map_matching_symbols taking an inordinate amount of time.
+ Specifically, calls like the one to look for a parallel "__XVZ"
+ variable, in ada_to_fixed_type_1, could result in gdb walking over all
+ the entries in the cooked index over and over.
+
+ Looking into this reveals that
+ cooked_index_functions::expand_matching_symbols is not written
+ efficiently -- it ignores its "ordered_compare" parameter. While
+ fixing this would be good, it turns out that this entire method isn't
+ needed; so this series removes it.
+
+ However, the deletion is not done in this patch. This one, instead,
+ fixes the immediate cause of the slowdown, by using
+ objfile::expand_symtabs_matching when possible. This approach is
+ faster because it is more selective about which index entries to
+ examine.
+
+2023-12-06 Tom Tromey <tom@tromey.com>
+
+ Start abbrevs at 1 in DWARF assembler
+ I noticed that the DWARF assembler starts abbrevs at 2.
+ I think 1 should be preferred.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2023-12-06 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix hardware watchpoints in replay mode
+ Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
+ caused a regression that meant hardware watchpoint stops would not
+ trigger in reverse execution or replay mode. This was documented in
+ PR breakpoints/21969.
+ The problem is that record_check_stopped_by_breakpoint always overwrites
+ record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
+ value which would be checked afterwards.
+
+ This commit fixes that by not overwriting the stop-reason in
+ record_full_stop_reason if we're not stopped at a breakpoint.
+
+ And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
+ tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
+ doesn't convert enabled watchpoints to use hardware.
+ This is fixed by disabling said watchpoint while enabling hw watchpoints.
+ The same is not done for gdb.reverse/watch-precsave.exp, since it's not
+ possible to use hw watchpoints in restored recordings anyways.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969
+ Approved-by: Guinevere Larsen <blarsen@redhat.com>
+
+2023-12-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix libstdc++ assert caused by invalid use of std::clamp
+ After this commit:
+
+ commit 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2
+ Date: Mon Dec 4 14:23:17 2023 +0000
+
+ gdb: Enable early init of thread pool size
+
+ I am now seeing this assert from libstdc++:
+
+ /usr/include/c++/9/bits/stl_algo.h:3715: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed.
+
+ This may only be visible because I compile with:
+
+ -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1
+
+ but I haven't checked. The issue the assert is highlighting is real,
+ and is caused by this block of code:
+
+ if (n_threads < 0)
+ {
+ const int hardware_threads = std::thread::hardware_concurrency ();
+ /* Testing in #29959 indicates that parallel efficiency drops between
+ n_threads=5 to 8. Therefore, clamp the default value to 8 to avoid an
+ excessive number of threads in the pool on many-core systems. */
+ const int throttle = 8;
+ n_threads = std::clamp (hardware_threads, hardware_threads, throttle);
+ }
+
+ The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if
+ we have more than 8 hardware threads available the LOW will be greater
+ than the HIGH, which is triggering the assert I see above.
+
+ I believe std::clamp is the wrong tool to use here. Instead std::min
+ would be a better choice; we want the smaller value of
+ HARDWARE_THREADS or THROTTLE. If h/w threads is 2, then we want 2,
+ but if h/w threads is 16 we want 8, this is what std::min gives us.
+
+ After this commit, I no longer see the assert.
+
+2023-12-06 Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
+
+ [gdb/symtab] Redo "Fix assert in set_length"
+ This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
+ to a regression reported in PR29572, and implements a different fix for PR29453.
+
+ The fix is to not use the CU table in a .debug_names section to construct
+ all_units, but instead use create_all_units, and then verify the CU
+ table from .debug_names. This also fixes PR25969, so remove the KFAIL.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
+
+2023-12-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: warnings: sync some build logic from gdbsupport
+ This fixes testing of -Wno flags, and adds some more portable ones.
+
+2023-12-06 Alan Modra <amodra@gmail.com>
+
+ PR31096, nm shows 32bit addresses as 64bit addresses
+ Prior to commit 0e3c1eebb2 nm output depended on the host unsigned
+ long when printing "negative" symbol values for 32-bit targets.
+ Commit 0e3c1eebb22 made the output match that seen with a 64-bit host
+ unsigned long. The fact that nm output changed depending on host is
+ of course a bug, but it is reasonable to expect 32-bit target output
+ is only 32 bits. So this patch makes 32-bit target output the same as
+ it was on 32-bit hosts prior to 0e3c1eebb2.
+
+ PR 31096
+ * nm.c (print_format_string): Make it a static buffer.
+ (get_print_format): Merge into..
+ (set_print_format): ..this, renamed from set_print_width. When
+ print_width is 32, set up print_format_string for an int32_t
+ value. Don't malloc print_format_string. Adjust calls.
+ (print_value): Correct printing of 32-bit values.
+
+2023-12-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-05 Jakub Jelinek <jakub@redhat.com>
+
+ 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 <cpuid.h> 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.
+
+ 2023-12-05 Jakub Jelinek <jakub@redhat.com>
+
+ * configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and
+ __get_cpuid_count are not implicitly declared.
+ * configure: Regenerated.
+
+2023-12-05 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix breakpoints on symbols with multiple trampoline symbols
+ On mingw targets it's possible that there are multiple trampoline
+ symbols for __cxa_throw, in each module where a throw is done, but
+ without a corresponding global symbol.
+ Since commit 77f2120b200be6cabbf6f610942fc1173a8df6d3 they cancel each
+ other out in search_minsyms_for_name, which makes it impossible to set
+ a breakpoint there:
+
+ (gdb) b __cxa_throw
+ Function "__cxa_throw" not defined.
+ Make breakpoint pending on future shared library load? (y or [n]) y
+ Breakpoint 2 (__cxa_throw) pending.
+ (gdb) c
+ Continuing.
+ [Inferior 1 (process 10004) exited with code 03]
+
+ With catch throw it also doesn't work, and you don't even get an error
+ message:
+
+ (gdb) catch throw
+ Catchpoint 2 (throw)
+ (gdb) c
+ Continuing.
+ [Inferior 1 (process 5532) exited with code 03]
+ (gdb)
+
+ The fix is to simply ignore other trampoline symbols when looking for
+ corresponding global symbols, and it's working as expected:
+
+ (gdb) b __cxa_throw
+ Breakpoint 2 at 0x13f091590 (2 locations)
+ (gdb) c
+ Continuing.
+
+ Breakpoint 2.1, 0x000000013f091590 in __cxa_throw ()
+ (gdb)
+
+ And catch throw also works again:
+
+ (gdb) catch throw
+ Catchpoint 2 (throw)
+ (gdb) c
+ Continuing.
+
+ Catchpoint 2.1 (exception thrown), 0x000000013f181590 in __cxa_throw ()
+ (gdb)
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29548
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-05 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb/testsuite: Update worker thread show assertion
+ Commit 33ae45434d0 updated the text reported by GDB when showing the
+ number of worker threads. However, it neglected to update the assertions
+ using this text, which caused index-file.exp to fail. This commit
+ corrects this omission.
+
+ Tested index-file.exp is fixed on my local machine.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-05 Tom Tromey <tromey@adacore.com>
+
+ Remove some DAP helper functions
+ Now that DAP requests are normally run on the gdb thread, some DAP
+ helper functions are no longer needed. Removing these simplifies the
+ code.
+
+2023-12-05 Nick Clifton <nickc@redhat.com>
+
+ Fix: strip --strip-debug breaks relocations
+ PR 31106
+ * elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation.
+
+2023-12-05 Tom Tromey <tom@tromey.com>
+
+ Fix off-by-one error in compute_delayed_physnames
+ compute_delayed_physnames does this:
+
+ size_t len = strlen (physname);
+ ...
+ if (physname[len] == ')') /* shortcut */
+ break;
+
+ However, physname[len] will always be \0.
+
+ This patch changes it to the correct len-1.
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: fix sim_fpu usage
+ Fix some of the sim_fpu calls to use the right types. While I'm
+ not familiar with the MIPS ISA in these cases, these look like
+ simple oversights due to the name/type mismatches. This at least
+ fixes compiling with -Wenum-conversion.
+
+ sim: sh: trim trailing whitespace in generated code
+ No functional change here, but makes it a little easier to read the
+ generated code when editors aren't highlighting all the spurious
+ trailing whitespace on lines.
+
+ sim: mn10300: fix sim_engine_halt call
+ The sim_stop argument is an enum and should only be one of those
+ values, not a signal constant. Fix the logic to pass the right
+ sim_xxx & SIM_xxx values in the right arguments.
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32c: use UTF-8 encoding
+ We only support UTF-8 nowadays, so stop using ISO-8859-1.
+
+ Maybe we should delete this logic entirely, but for now,
+ do the bare min conversion to keep it compiling.
+
+2023-12-05 Andreas Schwab <schwab@suse.de>
+
+ Add basic support for RISC-V 64-bit EFI objects
+ This adds a new PEI target pei-riscv64-little. Only objdump and objcopy
+ are supported.
+
+ bfd:
+ * .gitignore: Add pe-riscv64igen.c.
+ * Makefile.am (BFD64_BACKENDS): Add pei-riscv64.lo,
+ pe-riscv64igen.lo.
+ (BFD64_BACKENDS_CFILES): Add pei-riscv64.c.
+ (BUILD_CFILES): Add pe-riscv64igen.c.
+ (pe-riscv64igen.c): New rule.
+ * Makefile.in: Regenerate.
+ * bfd.c (bfd_get_sign_extend_vma): Add pei-riscv64-little.
+ * coff-riscv64.c: New file.
+ * coffcode.h (coff_set_arch_mach_hook, coff_set_flags)
+ (coff_write_object_contents): Add riscv64 (riscv64_pei_vec)
+ support.
+ * config.bfd (targ_selvecs): Add riscv64_pei_vec to all riscv*
+ targets.
+ * configure.ac: Handle riscv64_pei_vec.
+ * configure: Regenerate.
+ * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE)
+ (GET_OPTHDR_SIZE_OF_STACK_RESERVE)
+ (PUT_OPTHDR_SIZE_OF_STACK_RESERVE)
+ (GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT)
+ (GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE)
+ (GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT)
+ (GET_PDATA_ENTRY, _bfd_XX_bfd_copy_private_bfd_data_common)
+ (_bfd_XX_bfd_copy_private_section_data)
+ (_bfd_XX_get_symbol_info, _bfd_XX_only_swap_filehdr_out)
+ (_bfd_XX_print_private_bfd_data_common)
+ (_bfd_XXi_final_link_postscript, _bfd_XXi_only_swap_filehdr_out)
+ (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out)
+ (_bfd_XXi_swap_aux_in, _bfd_XXi_swap_aux_out)
+ (_bfd_XXi_swap_lineno_in, _bfd_XXi_swap_lineno_out)
+ (_bfd_XXi_swap_scnhdr_out, _bfd_XXi_swap_sym_in)
+ (_bfd_XXi_swap_sym_out, _bfd_XXi_swap_debugdir_in)
+ (_bfd_XXi_swap_debugdir_out, _bfd_XXi_write_codeview_record)
+ (_bfd_XXi_slurp_codeview_record) [COFF_WITH_peRiscV64]: Define.
+ (_bfd_peRiscV64_print_ce_compressed_pdata): Declare.
+ * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out)
+ (_bfd_XXi_swap_scnhdr_out, pe_print_pdata)
+ (_bfd_XX_print_private_bfd_data_common)
+ (_bfd_XX_bfd_copy_private_section_data)
+ (_bfd_XXi_final_link_postscript): Support COFF_WITH_peRiscV64.
+ * pei-riscv64.c: New file.
+ * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd)
+ (pe_ILF_object_p): Support COFF_WITH_peRiscV64.
+ (jtab): Add dummy entry that traps.
+ * targets.c (_bfd_target_vector): Add riscv64_pei_vec.
+
+ binutils:
+ * testsuite/binutils-all/riscv/pei-riscv64.d: New.
+ * testsuite/binutils-all/riscv/pei-riscv64.s: New.
+
+ include:
+ * coff/riscv64.h: New file.
+ * coff/pe.h (IMAGE_FILE_MACHINE_RISCV32)
+ (IMAGE_FILE_MACHINE_RISCV64): Define.
+
+2023-12-05 Alan Modra <amodra@gmail.com>
+
+ alpha_ecoff_get_relocated_section_contents buffer overflow
+ This is aimed at fixing holes in two alpha-ecoff relocation functions
+ that access section contents without first bounds checking offsets.
+ I've also rewritten ALPHA_R_OP_STORE handling to support writing to
+ the bytes near the end of the section.
+
+ * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't
+ bother checking ALPHA_R_LITERAL insn. Range check before reading
+ contents for ALPHA_R_GPDISP, and simplify handling. Rewrite
+ ALPHA_R_OP_STORE handling. Correct error callback args.
+ (alpha_relocate_section): Similarly. Don't abort, report errors.
+
+2023-12-05 Alan Modra <amodra@gmail.com>
+
+ memory leak in display_debug_addr
+ * dwarf.c (display_debug_addr): Free dummy debug_addr_info entry.
+ Don't return without freeing debug_addr_info on error paths.
+
+2023-12-05 Alan Modra <amodra@gmail.com>
+
+ Don't use free_contents in _bfd_elf_slurp_version_tables
+ In commit 7ac6d0c38c36 I made more use of free_contents in
+ _bfd_elf_slurp_version_tables, a variable added to tag the case where
+ raw verneed and verdefs have been read locally by the function, and
+ thus should be freed before returning. In retrospect it may have been
+ better to do without the extra variable entirely. It's easy to infer
+ when "contents" should be freed, costing a little extra on an error
+ path but costing less elsewhere.
+
+ * elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents.
+
+2023-12-05 Peter Jones <pjones@redhat.com>
+
+ Handle "efi-app-riscv64" and similar targets in objcopy.
+ This adds the efi target name handling for riscv64 to objcopy.
+
+ binutils:
+ * binutils/objcopy.c: add riscv64 handling to
+ convert_efi_target()
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: rx: mark unused static var as unused
+ This seems like a useful utility func that mirrors the int2float
+ helper, so mark it as unused rather than delete.
+
+ sim: rx: constify some read-only global vars
+
+ sim: warnings: enable only for development builds
+ Reuse the bfd/development.sh script like most other project to
+ determine whether the current source tree is a dev build (e.g.
+ git) or a release build, and disable the warnings for releases.
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: fix implicit enum conversion
+ This code tries to use attach_type enums as hw_phb_decode, and while
+ they're setup to have compatible values, the compiler doesn't like it
+ when the cast is missing. So cast it explicitly and then use that.
+
+ sim/ppc/hw_phb.c:322:28: error:
+ implicit conversion from enumeration type 'attach_type'
+ (aka 'enum _attach_type') to different enumeration type
+ 'hw_phb_decode' [-Werror,-Wenum-conversion]
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: fix -Wmisleading-indentation warnings
+ Fix building with -Wmisleading-indentation.
+
+2023-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: cleanup getrusage decls
+ Don't conflate HAVE_GETRUSAGE & HAVE_SYS_RESOURCE_H. Use the latter
+ to include the header and nothing else. Use the former to determine
+ whether to use the function and nothing else. If we find a system
+ that doesn't follow POSIX and provides only one of these, we can
+ figure out how to support it then. The manual local definition is
+ clashing with the system ones and leading to build failures with
+ newer C standards.
+
+ sim/ppc/emul_netbsd.c:51:5: error: a function declaration without a
+ prototype is deprecated in all versions of C and is treated as a
+ zero-parameter prototype in C2x, conflicting with a previous
+ declaration [-Werror,-Wdeprecated-non-prototype]
+
+2023-12-05 Alan Modra <amodra@gmail.com>
+
+ aarch64-elf: FAIL: indirect call stub to BTI stub relaxation
+ aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs
+ being emitted in a different order to that of aarch64-linux. They are
+ emitted in a different order due to stub names for local symbols
+ having the section id in the stub name. aarch64-linux-ld generates
+ one more section than aarch64-elf-ld. That section is .gnu.hash. So
+ the stub names differ and are hashed to different slots in
+ stub_hash_table.
+
+ Fix this by running the test with --hash-style=sysv, and adjust
+ expected output. I've also changed the branch over stubs emitted at
+ the start of a group of stubs to not care about the symbol, for all
+ groups not just the one that needed changing.
+
+ * ld-aarch64/bti-far-3.d: Add --hash-style=sysv. Adjust
+ expected output.
+
+2023-12-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix directory name in test name
+ In the commit:
+
+ commit 4793f551a5aa68522fd5fbbb7e8f621148f410cd
+ Date: Mon Nov 27 13:33:17 2023 +0000
+
+ gdb: allow use of ~ in 'save gdb-index' command
+
+ I added a test which has a directory name within the GDB command,
+ which then appears in the test name as I failed to give the test a
+ better name.
+
+ Fixed in this commit.
+
+2023-12-04 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ [gdb/doc] Escape the '@' symbols in generated texinfo files.
+ '@' is a special symbol meaning 'command' in GNU texinfo.
+
+ If the GDBINIT or GDBINIT_DIR path during configuration
+ included an '@' character, the makeinfo command would fail,
+ as it interpreted the '@' in the path as a start of a command
+ when expanding the path in the docs.
+
+ This patch simply escapes any '@' characters in the path,
+ by replacing them with '@@'. This was already done for the
+ bugurl variable.
+
+ This was detected because the 'Jenkins' tool sometimes puts
+ an '@' in the workspace path.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-04 Tom Tromey <tom@tromey.com>
+
+ Fix two buglets in .debug_names dumping
+ While working on gdb's .debug_names writer, I found a couple of small
+ bugs in binutils .debug_names dumping.
+
+ First, the DWARF spec (section 6.1.1.4.6 Name Table) says:
+
+ These two arrays are indexed starting at 1, [...]
+
+ I think it is clearer for binutils to follow this, particularly
+ because DW_IDX_parent refers to this number.
+
+ Second, I think the handling of an empty hash table is slightly wrong.
+ Currently the dumping 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.)
+
+ This patch fixes both of these problems. FWIW I have some gdb patches
+ in progress that change gdb both to omit the hash table and to use
+ DW_IDX_parent.
+
+ 2023-12-04 Tom Tromey <tom@tromey.com>
+
+ * dwarf.c (display_debug_names): Handle empty .debug_names hash
+ table. Name entries start at 1.
+
+2023-12-04 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ gdb: add Ciaran Woodward to gdb/MAINTAINERS
+
+2023-12-04 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Support for jump visualization in disassembly
+ Add support for jump visualization for the s390 architecture in
+ disassembly:
+
+ objdump -d --visualize-jumps ...
+
+ Annotate the (conditional) jump and branch relative instructions with
+ information required for jump visualization:
+ - jump: Unconditional jump / branch relative.
+ - condjump: Conditional jump / branch relative.
+ - jumpsr: Jump / branch relative to subroutine.
+
+ Unconditional jump and branch relative instructions are annotated as
+ jump.
+ Conditional jump and branch relative instructions, jump / branch
+ relative on count/index, and compare and jump / branch relative
+ instructions are annotated as condjump.
+ Jump and save (jas, jasl) and branch relative and save (bras, brasl)
+ instructions are annotated as jumpsr (jump to subroutine).
+
+ Provide instruction information required for jump visualization during
+ disassembly.
+ The instruction type is provided after determining the opcode.
+ For non-code it is set to dis_noninsn. Otherwise it defaults to
+ dis_nonbranch. No annotation is done for data reference instructions
+ (i.e. instruction types dis_dref and dis_dref2). Note that the
+ instruction type needs to be provided before printing of the
+ instruction, as it is used in print_address_func() to translate the
+ argument value into an address if it is assumed to be a PC-relative
+ offset. Note that this is never the case on s390, as
+ print_address_func() is only called with addresses and never with
+ offsets.
+ The target of the (conditional) jump and branch relative instructions
+ is provided during print, when the PC relative operand is decoded.
+
+ include/
+ * opcode/s390.h: Define opcode flags to annotate instruction
+ class information for jump visualization:
+ S390_INSTR_FLAG_CLASS_BRANCH, S390_INSTR_FLAG_CLASS_RELATIVE,
+ S390_INSTR_FLAG_CLASS_CONDITIONAL, and
+ S390_INSTR_FLAG_CLASS_SUBROUTINE.
+ Define opcode flags mask S390_INSTR_FLAG_CLASS_MASK for above
+ instruction class information.
+ Define helpers for common instruction class flag combinations:
+ S390_INSTR_FLAGS_CLASS_JUMP, S390_INSTR_FLAGS_CLASS_CONDJUMP,
+ and S390_INSTR_FLAGS_CLASS_JUMPSR.
+
+ opcodes/
+ * s390-mkopc.c: Add opcode flags to annotate information
+ for jump visualization: jump, condjump, and jumpsr.
+ * s390-opc.txt: Annotate (conditional) jump and branch relative
+ instructions with information for jump visualization.
+ * s390-dis.c (print_insn_s390, s390_print_insn_with_opcode):
+ Provide instruction information for jump visualization.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-12-04 Tom Tromey <tromey@adacore.com>
+
+ Remove incorrect "fall-through" comment
+ I found a "fall-through" comment in gdb/remote.c that was incorrect --
+ the code here cannot in fact fall through.
+
+2023-12-04 Tom Tromey <tromey@adacore.com>
+
+ Update fall-through comment in gdbserver
+ I noticed that gdbserver/win32-low.cc has a fall-through comment that
+ should have been converted to use the annotation instead.
+
+ This patch makes the change.
+
+2023-12-04 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb: Enable early init of thread pool size
+ This commit enables the early initialization commands (92e4e97a9f5) to
+ modify the number of threads used by gdb's thread pool.
+
+ The motivation here is to prevent gdb from spawning a detrimental number
+ of threads on many-core systems under environments with restrictive
+ ulimits.
+
+ With gdb before this commit, the thread pool takes the following sizes:
+
+ 1. Thread pool size is initialized to 0.
+
+ 2. After the maintenance commands are defined, the thread pool size is
+ set to the number of system cores (if it has not already been set).
+
+ 3. Using early initialization commands, the thread pool size can be
+ changed using "maint set worker-threads".
+
+ 4. After the first prompt, the thread pool size can be changed as in the
+ previous step.
+
+ Therefore after step 2. gdb has potentially launched hundreds of threads
+ on a many-core system.
+
+ After this change, step 2 and 3 are reversed so there is an opportunity
+ to set the required number of threads without needing to default to the
+ number of system cores first.
+
+ There does exist a configure option (added in 261b07488b9) to disable
+ multithreading, but this does not allow for an already deployed gdb to
+ be configured.
+
+ Additionally, the default number of worker threads is clamped at eight
+ to control the number of worker threads spawned on many-core systems.
+ This value was chosen as testing recorded on bugzilla issue 29959
+ indicates that parallel efficiency drops past this point.
+
+ GDB built with GCC 13.
+
+ No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
+ LLVM, NVHPC; Platforms: x86_64, aarch64.
+
+ The scenario that interests me the most involves preventing GDB from
+ spawning any worker threads at all. This was tested by counting the
+ number of clones observed by strace:
+
+ strace -e clone,clone3 gdb/gdb -q \
+ --early-init-eval-command="maint set worker-threads 0" \
+ -ex q ./gdb/gdb |& grep --count clone
+
+ The new test relies on "gdb: install CLI uiout while processing early
+ init files" developed by Andrew Burgess. This patch will need pushing
+ prior to this change.
+
+ The clamping was tested on machines with both 16 cores and a single
+ core. "maint show worker-threads" correctly reported eight and one
+ respectively.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: install CLI uiout while processing early init files
+ The next commit wants to use a 'show' command within an early
+ initialisation file, despite these commands not being in the list of
+ acceptable commands for use within an early initialisation file.
+
+ The problem we run into is that the early initialisation files are
+ processed before GDB has installed the top level interpreter. The
+ interpreter is responsible to installing the default uiout (accessed
+ through current_uiout), and as a result code that depends on
+ uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and
+ crashing GDB.
+
+ I did consider moving the interpreter installation before the early
+ initialisation, and this would work fine except for the new DAP
+ interpreter, which relies on having Python available during its
+ initialisation. Which means we can't install the interpreter until
+ after Python has been initialised, and the early initialisation
+ handling has to occur before Python is setup -- that's the whole point
+ of this feature (to allow customisation of how Python is setup).
+
+ So, what I propose is that early within captured_main_1, we install a
+ temporary cli_ui_out as the current_uiout. This will remain in place
+ until the top-level interpreter is installed, at which point the
+ temporary will be replaced.
+
+ What this means is that current_uiout will no longer be nullptr,
+ instead, any commands within an early initialisation file that trigger
+ output, will perform that output in a CLI style.
+
+ I propose that we don't update the documentation for early
+ initialisation files, we leave the user advice as being only 'set' and
+ 'source' commands are acceptable. But now, if a user does try a
+ 'show' command, then instead of crashing, GDB will do something
+ predictable.
+
+ I've not added a test in this commit. The next commit relies on this
+ patch and will serve as a test.
+
+ Tested-By: Richard Bunt <richard.bunt@linaro.org>
+
+2023-12-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix wrapping strings
+ I noticed that after resizing to a narrow window, I got:
+ ...
+ ┌────────────────┐
+ │ │
+ │[ No Source Avail
+ able ] │
+ │ │
+ └────────────────┘
+ ...
+
+ Fix this by adding two new functions:
+ - tui_win_info::display_string (int y, int x, const char *str)
+ - tui_win_info::display_string (const char *str)
+ that make sure that borders are not overwritten, which get us instead:
+ ...
+ ┌────────────────┐
+ │ │
+ │[ No Source Avai│
+ │ │
+ │ │
+ └────────────────┘
+ ...
+
+ Tested on x86_64-linux.
+
+2023-12-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-03 Kevin Buettner <kevinb@redhat.com>
+
+ Fix detach bug when lwp has exited/terminated
+ When using GDB on native linux, it can happen that, while attempting
+ to detach an inferior, the inferior may have been exited or have been
+ killed, yet still be in the list of lwps. Should that happen, the
+ assert in x86_linux_update_debug_registers in
+ gdb/nat/x86-linux-dregs.c will trigger. The line in question looks
+ like this:
+
+ gdb_assert (lwp_is_stopped (lwp));
+
+ For this case, the lwp isn't stopped - it's dead.
+
+ The bug which brought this problem to my attention is one in which the
+ pwntools library uses GDB to to debug a process; as the script is
+ shutting things down, it kills the process that GDB is debugging and
+ also sends GDB a SIGTERM signal, which causes GDB to detach all
+ inferiors prior to exiting. Here's a link to the bug:
+
+ https://bugzilla.redhat.com/show_bug.cgi?id=2192169
+
+ The following shell command mimics part of what the pwntools
+ reproducer script does (with regard to shutting things down), but
+ reproduces the bug much less reliably. I have found it necessary to
+ run the command a bunch of times before seeing the bug. (I usually
+ see it within 5-10 repetitions.) If you choose to try this command,
+ make sure that you have no running "cat" or "gdb" processes first!
+
+ cat </dev/zero >/dev/null & \
+ (sleep 5; (kill -KILL `pgrep cat` & kill -TERM `pgrep gdb`)) & \
+ sleep 1 ; \
+ gdb -q -iex 'set debuginfod enabled off' -ex 'set height 0' \
+ -ex c /usr/bin/cat `pgrep cat`
+
+ So, basically, the idea here is to kill both gdb and cat at roughly
+ the same time. If we happen to attempt the detach before the process
+ lwp has been deleted from GDB's (linux native) LWP data structures,
+ then the assert will trigger. The relevant part of the backtrace
+ looks like this:
+
+ #8 0x00000000008a83ae in x86_linux_update_debug_registers (lwp=0x1873280)
+ at gdb/nat/x86-linux-dregs.c:146
+ #9 0x00000000008a862f in x86_linux_prepare_to_resume (lwp=0x1873280)
+ at gdb/nat/x86-linux.c:81
+ #10 0x000000000048ea42 in x86_linux_nat_target::low_prepare_to_resume (
+ this=0x121eee0 <the_amd64_linux_nat_target>, lwp=0x1873280)
+ at gdb/x86-linux-nat.h:70
+ #11 0x000000000081a452 in detach_one_lwp (lp=0x1873280, signo_p=0x7fff8ca3441c)
+ at gdb/linux-nat.c:1374
+ #12 0x000000000081a85f in linux_nat_target::detach (
+ this=0x121eee0 <the_amd64_linux_nat_target>, inf=0x16e8f70, from_tty=0)
+ at gdb/linux-nat.c:1450
+ #13 0x000000000083a23b in thread_db_target::detach (
+ this=0x1206ae0 <the_thread_db_target>, inf=0x16e8f70, from_tty=0)
+ at gdb/linux-thread-db.c:1385
+ #14 0x0000000000a66722 in target_detach (inf=0x16e8f70, from_tty=0)
+ at gdb/target.c:2526
+ #15 0x0000000000a8f0ad in kill_or_detach (inf=0x16e8f70, from_tty=0)
+ at gdb/top.c:1659
+ #16 0x0000000000a8f4fa in quit_force (exit_arg=0x0, from_tty=0)
+ at gdb/top.c:1762
+ #17 0x000000000070829c in async_sigterm_handler (arg=0x0)
+ at gdb/event-top.c:1141
+
+ My colleague, Andrew Burgess, has done some recent work on other
+ problems with detach. Upon hearing of this problem, he came up a test
+ case which reliably reproduces the problem and tests for a few other
+ problems as well. In addition to testing detach when the inferior has
+ terminated due to a signal, it also tests detach when the inferior has
+ exited normally. Andrew observed that the linux-native-only
+ "checkpoint" command would be affected too, so the test also tests
+ those cases when there's an active checkpoint.
+
+ For the LWP exit / termination case with no checkpoint, that's handled
+ via newly added checks of the waitstatus in detach_one_lwp in
+ linux-nat.c.
+
+ For the checkpoint detach problem, I chose to pass the lwp_info
+ to linux_fork_detach in linux-fork.c. With that in place, suitable
+ tests were added before attempting a PTRACE_DETACH operation.
+
+ I added a few asserts at the beginning of linux_fork_detach and
+ modified the caller code so that the newly added asserts shouldn't
+ trigger. (That's what the 'pid == inferior_ptid.pid' check is about
+ in gdb/linux-nat.c.)
+
+ Lastly, I'll note that the checkpoint code needs some work with regard
+ to background execution. This patch doesn't attempt to fix that
+ problem, but it doesn't make it any worse. It does slightly improve
+ the situation with detach because, due to the check noted above,
+ linux_fork_detach() won't be called for the wrong inferior when there
+ are multiple inferiors. (There are at least two other problems with
+ the checkpoint code when there are multiple inferiors. See:
+ https://sourceware.org/bugzilla/show_bug.cgi?id=31065)
+
+ This commit also adds a new test,
+ gdb.base/process-dies-while-detaching.exp. Andrew Burgess is the
+ primary author of this test case. Its design is similar to that of
+ gdb.threads/main-thread-exit-during-detach.exp, which was also written
+ by Andrew.
+
+ This test checks that GDB correctly handles several cases that can
+ occur when GDB attempts to detach an inferior process. The process
+ can exit or be terminated (e.g. via SIGKILL) prior to GDB's event
+ loop getting a chance to remove it from GDB's internal data
+ structures. To complicate things even more, detach works differently
+ when a checkpoint (created via GDB's "checkpoint" command) exists for
+ the inferior. This test checks all four possibilities: process exit
+ with no checkpoint, process termination with no checkpoint, process
+ exit with a checkpoint, and process termination with a checkpoint.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-02 Petr Tesarik <petr@tesarici.cz>
+
+ binutils: Fix documentation typo in the --set-sect-name option
+ Fix a --set-sect-name typo in the description of objcopy
+ --rename-section.
+
+ gdb: Update Petr Tesarik's email address in gdb/MAINTAINERS
+
+2023-12-02 H.J. Lu <hjl.tools@gmail.com>
+
+ Fix ld/x86: reduce testsuite dependency on system object files
+ commit eab996435fe65a421541f59557c5f1fd427573a3
+ Author: Jan Beulich <jbeulich@suse.com>
+ Date: Tue Nov 7 13:58:32 2023 +0100
+
+ ld/x86: reduce testsuite dependency on system object files
+
+ changed some C compiler tests to assembler/linker tests which introduced
+ 2 problems:
+
+ 1. It broke x32 binutils tests since --64 was passed to assembler, but
+ -m elf_x86_64 wasn't passed to linker.
+ 2. -nostdlib was passed to C compiler driver to exclude standard run-time
+ files which should be avoided with -r option for linker tests.
+
+ Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for
+ linker tests with -r.
+
+ PR ld/30722
+ * testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker
+ for tests with --64. Remove -nostdlib for tests with -r.
+
+2023-12-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-12-01 Tom Tromey <tromey@adacore.com>
+
+ Bail out of "attach" if a thread cannot be traced
+ On Linux, threads are treated much like separate processes by the
+ kernel. In particular, it's possible to ptrace just a single thread.
+ If gdb tries to attach to a multi-threaded inferior, where a non-main
+ thread is already being traced (e.g., by strace), then gdb will get
+ into an infinite loop attempting to attach.
+
+ This patch fixes this problem by having the attach fail if ptrace
+ fails to attach to any thread of the inferior.
+
+2023-12-01 Tom Tromey <tromey@adacore.com>
+
+ Use gdb_dir_up in linux_proc_attach_tgid_threads
+ This changes linux_proc_attach_tgid_threads to use gdb_dir_up. This
+ makes it robust against exceptions.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-12-01 Tom Tromey <tromey@adacore.com>
+
+ Minor cleanup in linux_proc_attach_tgid_threads
+ linux_proc_attach_tgid_threads computes a file name, and then
+ re-computes it for a warning. It is better to reuse the
+ already-computed name here.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-12-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add missing regcache_map_entry array null terminators in aarch64-linux-tdep.c
+ Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry
+ arrays without a null terminator. The null terminators are needed for
+ regcache::transfer_regset and regcache_map_entry_size to work properly.
+
+ Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-12-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: return when exceeding buffer size in regcache::transfer_regset
+ regcache::transfer_regset iterates over an array of regcache_map_entry,
+ transferring the registers (between regcache and buffer) described by
+ those entries. It stops either when it reaches the end of the
+ regcache_map_entry array (marked by a null entry) or (it seems like the
+ intent is) when it reaches the end of the buffer (in which case not all
+ described registers are transferred).
+
+ I said "seems like the intent is", because there appears to be a small
+ bug. transfer_regset is made of two loops:
+
+ foreach regcache_map_entry:
+ foreach register described by the regcache_map_entry:
+ if the register doesn't fit in the remainder of the buffer:
+ break
+
+ transfer register
+
+ When stopping because we have reached the end of the buffer, the break
+ only breaks out of the inner loop.
+
+ This problem causes some failures when I run tests such as
+ gdb.arch/aarch64-sme-core-3.exp (on AArch64 Linux, in qemu). This is
+ partly due to aarch64_linux_iterate_over_regset_sections failing to add
+ a null terminator in its regcache_map_entry array, but I think there is
+ still a problem in transfer_regset.
+
+ The sequence to the crash is:
+
+ - The `regcache_map_entry za_regmap` object built in
+ aarch64_linux_iterate_over_regset_sections does not have a null
+ terminator.
+ - When the target does not have a ZA register,
+ aarch64_linux_collect_za_regset calls `regcache->collect_regset` with
+ a size of 0 (it's actually pointless, but still it should work).
+ - transfer_regset gets called with a buffer size of 0.
+ - transfer_regset detects that the register to transfer wouldn't fit in
+ 0 bytes, so it breaks out of the inner loop.
+ - The outer loop tries to go read the next regcache_map_entry, but
+ there isn't one, and we start reading garbage.
+
+ Obviously, this would get fixed by making
+ aarch64_linux_iterate_over_regset_sections use a null terminator (which
+ is what the following patch does). But I think that when detecting that
+ there is not enough buffer left for the current register,
+ transfer_regset should return, not only break out of the inner loop.
+
+ This is a kind of contrived scenario, but imagine we have these two
+ regcache_map_entry objects:
+
+ - 2 registers of 8 bytes
+ - 2 registers of 4 bytes
+
+ For some reason, the caller passes a buffer of 12 bytes.
+ transfer_regset will detect that the second 8 byte register does not
+ fit, and break out of the inner loop. However, it will then go try the
+ next regcache_map_entry. It will see that it can fit one 4 byte
+ register in the remaining buffer space, and transfer it from/to there.
+ This is very likely not an expected behavior, we wouldn't expect to
+ read/write this sequence of registers from/to the buffer.
+
+ In this example, whether passing a 12 bytes buffer makes sense or
+ whether it is a size computation bug in the caller, we don't know, but I
+ think that exiting as soon as a register doesn't fit is the sane thing
+ to do.
+
+ Change-Id: Ia349627d2e5d281822ade92a8e7a4dea4f839e07
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+
+2023-12-01 Tom Tromey <tromey@adacore.com>
+
+ Add link to Debugger Adapter Protocol node in documentation
+ I noticed that the interpreters node in the docs links to the DAP
+ protocol docs, but I thought the DAP node ought to as well. This
+ patch adds a bit of introductory text there.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-12-01 Jeff Law <jeffreyalaw@gmail.com>
+
+ Fix right shifts in mcore simulator on 64 bit hosts.
+ If the value to be shifted has the sign bit set, the sign
+ bit would get copied into bits 32..63 of the temporary. Those
+ would then be right shifted into the final value giving an
+ incorrect final result.
+
+ This was observed with upcoming GCC improvements which eliminate
+ unnecessary extensions.
+
+2023-12-01 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix completion tests when using READ1
+ The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced
+ regressions when testing using the READ1 mechanism. The reason for that
+ is the new failure path in proc test_gdb_complete_tab_unique, which
+ looks for GDB suggesting more than what the test inputted, but not the
+ correct answer, followed by a white space. Consider the following case:
+
+ int foo(int bar, int baz);
+
+ Sending the command "break foo<tab>" to GDB will return
+
+ break foo(int, int)
+
+ which easily fits the buffer in normal testing, so everything works, but
+ when reading one character at a time, the test will find the partial
+ "break foo(int, " and assume that there was a mistake, so we get a
+ spurious FAIL.
+
+ That change was added because we wanted to avoid forcing a completion
+ failure to fail through timeout, which it had to do because there is no
+ way to verify that the output is done, mostly because when I was trying
+ to solve a different problem I kept getting reading errors and testing
+ completion was frustrating.
+
+ This commit implements a better way to avoid that frustration, by first
+ testing gdb's complete command and only if that passes we will test tab
+ completion. The difference is that when testing with the complete
+ command, we can tell when the output is over when we receive the GDB
+ prompt again, so we don't need to rely on timeouts. With this, the
+ change to test_gdb_complete_tab_unique has been removed as that test
+ will only be run and fail in the very unlikely scenario that tab
+ completion is different than command completion.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-12-01 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Remove unnecessary returns and unused variables in AIX.
+ This is a patch to simplify the pd_activate () in aix-thread.c incase of a failure to start a thread session
+ , since pd_activate () now has return type void.
+
+ Also this patch fixes the shadow declarartion warning in sync-threadlists.
+
+2023-12-01 Nick Clifton <nickc@redhat.com>
+
+ Fix: nm -U short flag erroneously consumes argument
+ PR 31105
+ * nm.c (main): Remove spurious colon after U in the call to getopt_long
+
+2023-12-01 Jan Beulich <jbeulich@suse.com>
+
+ ld: fix build with old makeinfo
+ Makeinfo 4.12 is unhappy about the new "Special Sections" without that
+ also having a @chapter line.
+
+ binutils/Dwarf: avoid "shadowing" of glibc function name
+ Yet once again: Old enough glibc has an (unguarded) declaration of
+ index() in string.h, which triggers a "shadows a global declaration"
+ warning with at least some gcc versions.
+
+ gas: drop unused fields from struct segment_info_struct
+ user_stuff, dot, and lineno_list_{head,tail} have no users (left), while
+ bfd_section was only ever written.
+
+ x86: adjust NOP generation after potential non-insn
+ Just like avoiding to do certain transformations potentially affected by
+ stand-alone prefixes or direct data emission, also avoid emitting
+ optimized NOPs right afterwards; insert a plain old NOP first in such
+ cases.
+
+ x86: i386_cons_align() badly affects diagnostics
+ Warning without knowing what's going to follow isn't useful, the more
+ that appropriate warnings are emitted elsewhere in all cases. Not
+ updating state (file/line in particular) also isn't helpful, as it's
+ always the last directive ahead of a construct potentially needing
+ fiddling with that's "guilty" in that fiddling being suppressed.
+
+ gas: no md_cons_align() for .nop{,s}
+ .nop and .nops generate code, not data. Hence them invoking
+ md_cons_align() is at best inappropriate. In fact it actually gets in
+ the of x86'es state maintenance involving i386_cons_align().
+
+ x86: suppress optimization after potential non-insn
+ Just like avoiding to do other transformations potentially affected by
+ stand-alone prefixes or direct data emission, also avoid optimization
+ on the following insn.
+
+2023-12-01 Jan Beulich <jbeulich@suse.com>
+
+ x86: last-insn recording should be per-section
+ Otherwise intermediate section switches result in inconsistent behavior.
+ Note, however, that intermediate sub-section switches will continue to
+ result in inconsistent or even inappropriate behavior.
+
+ While there also add recording of state to s_insn().
+
+2023-12-01 Jan Beulich <jbeulich@suse.com>
+
+ x86: allow 32-bit reg to be used with U{RD,WR}MSR
+ ... as MSR index specifier: It is unreasonable to demand that people
+ write less readable / understandable code, just because the present
+ documentation mentions only Reg64. Whether to also adjust the
+ disassembler is a separate question, perhaps indeed more tightly tied
+ to what the spec says.
+
+2023-12-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix warnings about invalid [[fallthrough]] usage
+ Fix these two warnings, when building on macos:
+
+ CXX cp-name-parser.o
+ /Users/smarchi/src/binutils-gdb/gdb/cp-name-parser.y:1644:7: error: fallthrough annotation does not directly precede switch label
+ [[fallthrough]];
+ ^
+
+ CXX dbxread.o
+ /Users/smarchi/src/binutils-gdb/gdb/dbxread.c:2809:7: error: fallthrough annotation does not directly precede switch label
+ [[fallthrough]];
+ ^
+
+ In these two cases, we [[fallthrough]], followed by a regular label,
+ followed by a case label. Move the [[fallthrough]] below the regular
+ label.
+
+ Change-Id: If4a3145139e050bdb6950c7f239badd5778e6f64
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-12-01 Patrick O'Neill <patrick@rivosinc.com>
+
+ RISC-V: Make riscv_is_mapping_symbol stricter
+ riscv_is_mapping_symbol currently accepts any symbol that starts with $x
+ or $d. This patch makes the check more strict, requiring exactly $x, $d,
+ or $xrv. It also makes use of this stricter mapping in
+ riscv_is_valid_mapping_symbol.
+
+ ChangeLog:
+
+ * bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only
+ strings that are exactly $x, $d, or $xrv.
+ * opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use
+ riscv_elf_is_mapping_symbols.
+
+2023-12-01 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Update gas/NEWS for RISC-V vendor extension news.
+ gas/
+ * NEWS: Update RISC-V vendor extension news.
+
+2023-12-01 Nelson Chu <nelson.chu@sifive.com>
+ Hau Hsu <hau.hsu@sifive.com>
+ Kito Cheng <kito.cheng@sifive.com>
+
+ RISC-V: Add SiFive custom vector coprocessor interface instructions v1.0
+ SiFive has define as set of flexible instruction for extending vector
+ coprocessor, it able to encoding opcode like .insn but with predefined
+ format.
+
+ List of instructions:
+ sf.vc.x
+ sf.vc.i
+ sf.vc.vv
+ sf.vc.xv
+ sf.vc.iv
+ sf.vc.fv
+ sf.vc.vvv
+ sf.vc.xvv
+ sf.vc.ivv
+ sf.vc.fvv
+ sf.vc.vvw
+ sf.vc.xvw
+ sf.vc.ivw
+ sf.vc.fvw
+ sf.vc.v.x
+ sf.vc.v.i
+ sf.vc.v.vv
+ sf.vc.v.xv
+ sf.vc.v.iv
+ sf.vc.v.fv
+ sf.vc.v.vvv
+ sf.vc.v.xvv
+ sf.vc.v.ivv
+ sf.vc.v.fvv
+ sf.vc.v.vvw
+ sf.vc.v.xvw
+ sf.vc.v.ivw
+ sf.vc.v.fvw
+
+ Spec of Xsfvcp
+ https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software
+
+2023-12-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Zv*: Add support for Zvkb ISA extension
+ Back then when the support for the RISC-V vector crypto extensions
+ was merged, the specification was frozen, but not ratified.
+ A frozen specification is allowed to change within tight bounds
+ before ratification and this has happend with the vector crypto
+ extensions.
+
+ The following changes were applied:
+ * A new extension Zvkb was defined, which is a strict subset of Zvbb.
+ * Zvkn and Zvks include now Zvkb instead of Zvbb.
+
+ This patch implements these changes between the frozen and the
+ ratified specification.
+
+ Note, that this technically an incompatible change of Zvkn and Zvks,
+ but I am not aware of any project that depends on the currently
+ implemented behaviour of Zvkn and Zvks. So this patch should be fine.
+
+ Reported-By: Jerry Shih <jerry.shih@sifive.com>
+ Reported-By: Eric Biggers <ebiggers@kernel.org>
+
+2023-12-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix adding -DNDEBUG to python flags of release build
+ In gdb/configure the line:
+ ...
+ $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
+ ...
+ intends to ensure that -DNDEBUG is added to the python flags of a release
+ build.
+
+ However, when building gdb-14-branch we have:
+ ...
+ configure:22024: checking compiler flags for python code
+ ...
+ configure:22047: result: -fno-strict-aliasing -fwrapv
+ ...
+
+ This is a regression since commit db6878ac553 ("Move sourcing of development.sh
+ to GDB_AC_COMMON"), which introduced a reference before assignment:
+ ...
+ $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
+ ...
+ . $srcdir/../bfd/development.sh
+ ...
+ and consequently -DNDEBUG is never added.
+
+ [ This was not obvious to me, but apparently evaluating an empty or undefined
+ variable in this context is similar to using ':' or 'true', so the line is
+ evaluated as:
+ ...
+ true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
+ ... ]
+
+ Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that
+ was done for gdbserver/configure.ac in commit db6878ac553.
+
+ [ Unfortunately, the move might introduce issues similar to the one we're
+ fixing, and I'm not sure how to check for this. Shellcheck doesn't detect
+ this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the
+ src/gdb directory to make sure ../bfd/development.sh is taken into account)
+ before and after and observed that the number of lines/words/chars in the
+ shellcheck output is identical. ]
+
+ Build & tested on top of trunk.
+
+ Also build on top of gdb-14-branch, and observed this in gdb/config.log:
+ ...
+ configure:25214: checking compiler flags for python code
+ ...
+ configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG
+ ...
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/31099
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
+
+2023-11-30 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/GAS: Add -march=loongson2f to loongson-2f-3 test
+ On MIPSr6, the encoding of JR instruction has been chaned.
+ This patch can fix these failures for r6 default triples:
+ ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
+
+2023-11-30 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Set r6 as default arch if vendor is img
+ This behavior is used by downstream toolchain since 2014,
+ and has been in GCC since the same year.
+
+ We don't support mips64*-img* due to GCC doesn't support it,
+ and we believe that the multilib should be used for this case.
+
+2023-11-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Fix procfs.c compilation
+ procfs.c doesn't currently compile on Solaris:
+
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’:
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’?
+ 3017 | type *ptr_type
+ | ^~~~~~~~
+ | var_types
+
+ This was caused by this patch:
+
+ commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee
+ Author: Simon Marchi <simon.marchi@efficios.com>
+ Date: Fri Sep 29 14:24:38 2023 -0400
+
+ gdb: remove target_gdbarch
+
+ Partially undoing it restores the build.
+
+ Tested on amd64-pc-solaris2.11.
+
+2023-11-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ libiberty: Disable hwcaps for sha1.o
+ This patch
+
+ commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
+ Author: Jakub Jelinek <jakub@redhat.com>
+ Date: Tue Nov 28 13:14:05 2023 +0100
+
+ libiberty: Use x86 HW optimized sha1
+
+ broke Solaris/x86 bootstrap with the native as:
+
+ libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
+ ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ]
+ gccgo: fatal error: Killed signal terminated program go1
+
+ As is already done in a couple of other similar cases, this patches
+ disables hwcaps support for libiberty.
+
+ Initially, this didn't work because config/hwcaps.m4 uses target_os, but
+ didn't ensure it is defined.
+
+ Tested on i386-pc-solaris2.11 with as and gas.
+
+ 2023-11-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ config:
+ * hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require
+ AC_CANONICAL_TARGET.
+
+ libiberty:
+ * configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke.
+ * configure, aclocal.m4: Regenerate.
+ * Makefile.in (COMPILE.c): Add HWCAP_CFLAGS.
+
+2023-11-30 Patrick O'Neill <patrick@rivosinc.com>
+
+ RISC-V: Avoid updating state until symbol is found
+ Currently objdump gets and updates the map state once per symbol. Updating the
+ state (partiularly riscv_parse_subset) is expensive and grows quadratically
+ since we iterate over all symbols. By deferring this until once we've found the
+ symbol of interest, we can reduce the time to dump a 4k insn file of .norvc and
+ .rvc insns from ~47 seconds to ~0.13 seconds.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_get_map_state): Remove state updating logic
+ and rename to riscv_is_valid_mapping_symbol.
+ (riscv_update_map_state): Add state updating logic to seperate function.
+ (riscv_search_mapping_symbol): Use new riscv_update_map_state.
+ (riscv_data_length): Ditto.
+
+2023-11-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: support double-slash line comments in BPF assembly
+ This patch makes the BPF assembler to support double-slash line
+ comments, like the llvm BPF assembler does. At this point both
+ assemblers support the same commenting styles:
+
+ - Line comments preceded by # or //.
+ - Non-nestable block comments delimited by /* and */.
+
+ This patch also adds a couple of tests to make sure all the comment
+ styles work in both normal and pseudoc syntax. The manual is also
+ updated to mention double-slash line comments.
+
+2023-11-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Remove gdb_static_assert
+ C++17 makes the second parameter to static_assert optional, so we can
+ remove gdb_static_assert now.
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Use C++17 void_t
+ C++17 has void_t and make_void, so gdbsupport/traits.h can be
+ simplified.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Rely on copy elision in scope-exit.h
+ gdbsupport/scope-exit.h has a couple of comments about being able to
+ rely on copy elision in C++17. This patch makes the change.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Rely on C++17 <new> in new-op.cc
+ gdbsupport/new-op.cc has a comment about relying on the C++-17 <new>
+ header. This patch implements the suggestion.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Use try_emplace in index-write.c
+ index-write.c has a comment indicating that C++17's try_emplace could
+ be used. This patch makes the change.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Enable some C++14 code in array-view.h
+ This changes gdbsupport/array-view.h to enable some code that is
+ C++14-specific.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Switch to -Wimplicit-fallthrough=5
+ This changes the various gdb-related directories to use
+ -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute
+ can be used in switches -- special 'fallthrough' comments will no
+ longer be usable.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Tom Tromey <tom@tromey.com>
+
+ Use C++17 [[fallthrough]] attribute
+ This changes gdb to use the C++17 [[fallthrough]] attribute rather
+ than special comments.
+
+ This was mostly done by script, but I neglected a few spellings and so
+ also fixed it up by hand.
+
+ I suspect this fixes the bug mentioned below, by switching to a
+ standard approach that, presumably, clang supports.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: support GNU option syntax in gp-display-html, plus various fixes
+ This is a major update of gp-display-html. The option handling has been
+ modified to support the GNU style long option syntax. Compatibility with
+ the previous syntax has been preserved. If still used, a warning is issued.
+ Through the --nowarnings option, this can be suppressed.
+ In addition to this, various lay-out changes have been implemented. In
+ particular to reduce the number of lines that extend beyond column 79.
+ Several bugs have been fixed, for example in the handling of directory names.
+
+ gprofng/ChangeLog
+ 2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ * gp-display-html/gp-display-html.in: Change option syntax plus fixes.
+
+2023-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: updated man pages and user guide
+ This is a major update of all the man pages. Bugs 30679 and 30895 are
+ addressed. In addition to fixes for typos, the texts have been expanded
+ and clarified, and line lengths no longer extend beyond column 79. In
+ case of gp-display-html, the new option syntax is documented. The user
+ guide has a new section on the gprofng GUI.
+
+ gprofng/ChangeLog
+ 2023-11-28 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR 30679
+ PR 30895
+ * doc/gp-archive.texi: Expand the description of the options.
+ * doc/gp-collect-app.texi: Fix various typos and textual improvements.
+ * doc/gp-display-html.texi: Cover the new GNU long option syntax.
+ * doc/gp-display-src.texi: Fix various typos and textual improvements.
+ * doc/gp-display-text.texi: Fix typos fixed and textual improvements.
+ * doc/gp-macros.texi: Fix a bug in the vspace macro and add new macro.
+ * doc/gprofng.texi: Cover the GPROFNG_SYSCONFDIR environment variable.
+ * doc/gprofng_ug.texi: Fix various typos and textual improvements.
+ * doc/version.texi: Adapt the date and version number.
+
+2023-11-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: display errors from command completion
+ This commit makes the gdb.Command.complete methods more verbose when
+ it comes to error handling.
+
+ Previous to this commit if any commands implemented in Python
+ implemented the complete method, and if there were any errors
+ encountered when calling that complete method, then GDB would silently
+ hide the error and continue as if there were no completions.
+
+ This makes is difficult to debug any errors encountered when writing
+ completion methods, and encourages the idea that Python extensions can
+ be broken, and GDB will just silently work around them.
+
+ I don't think this is a good idea. GDB should encourage extensions to
+ be written correctly, and robustly, and one way in which GDB can (I
+ think) support this, is by pointing out when an extension goes wrong.
+
+ In this commit I've gone through the Python command completion code,
+ and added calls to gdbpy_print_stack() or gdbpy_print_stack_or_quit()
+ in places where we were either clearing the Python error, or, in some
+ cases, just not handling the error at all.
+
+ One thing I have not changed is in cmdpy_completer (py-cmd.c) where we
+ process the list of completions returned from the Command.complete
+ method; this routine includes a call to gdbpy_is_string to check a
+ possible completion is a string, if not the completion is ignored.
+
+ I was tempted to remove this check, attempt to complete each result to
+ a string, and display an error if the conversion fails. After all,
+ returning anything but a string is surely a mistake by the extension
+ author.
+
+ However, the docs clearly say that only strings within the returned
+ list will be considered as completions. Anything else is ignored. As
+ such, and to avoid (what I think is pretty unlikely) breakage of
+ existing code, I've retained the gdbpy_is_string check.
+
+ After the gdbpy_is_string check we call python_string_to_host_string,
+ if this call fails then I do now print the error, where before we
+ ignored the error. I think this is OK; if GDB thinks something is a
+ string, but still can't convert it to a string, then I think it's OK
+ to display the error in that case.
+
+ Another case which I was a little unsure about was in
+ cmdpy_completer_helper, and the call to PyObject_CallMethodObjArgs,
+ which is when we actually call Command.complete. Previously, if this
+ call resulted in an exception then we would ignore this and just
+ pretend there were no completions.
+
+ Of all the changes, this is possibly the one with the biggest
+ potential for breaking existing scripts, but also, is, I think, the
+ most useful change. If the user code is wrong in some way, such that
+ an exception is raised, then previously the user would have no obvious
+ feedback about this breakage. Now GDB will print the exception for
+ them, making it, I think, much easier to debug their extension. But,
+ if there is user code in the wild that relies on raising an exception
+ as a means to indicate there are no completions .... well, that code
+ is going to break after this commit. I think we can live with this
+ though, the exceptions means no completions thing was never documented
+ behaviour.
+
+ I also added a new error() call if the PyObject_CallMethodObjArgs call
+ raises an exception. This causes the completion mechanism within GDB
+ to stop. Within GDB the completion code is called twice, the first
+ time to compute the work break characters, and then a second time to
+ compute the actual completions.
+
+ If PyObject_CallMethodObjArgs raises an exception when computing the
+ word break character, and we print it by calling
+ gdbpy_print_stack_or_quit(), but then carry on as if
+ PyObject_CallMethodObjArgs had returns no completions, GDB will
+ call the Python completion code again, which results in another call
+ to PyObject_CallMethodObjArgs, which might raise the same exception
+ again. This results in the Python exception being printed twice.
+
+ By throwing a C++ exception after the failed
+ PyObject_CallMethodObjArgs call, the completion mechanism is aborted,
+ and no completions are offered. But importantly, the Python exception
+ is only printed once. I think this gives a much better user
+ experience.
+
+ I've added some tests to cover this case, as I think this is the most
+ likely case that a user will run into.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: improve test regexp in gdb_get_worker_threads
+ I spotted I made a small mistake in this commit:
+
+ commit aff250145af6c7a8ea9332bc1306c1219f4a63db
+ Date: Fri Nov 24 12:04:36 2023 +0000
+
+ gdb: generate gdb-index identically regardless of work thread count
+
+ In this commit I added a new proc in testsuite/lib/gdb.exp called
+ gdb_get_worker_threads. This proc uses gdb_test_multiple with two
+ possible patterns. One pattern is anchored with '^', while the other
+ is missing the '^' which it could use.
+
+ This commit adds the missing '^'.
+
+2023-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ gnulib: mark configure +x
+
+2023-11-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix call to breakpoint_inserted_here_p in darwin-nat.c
+ Fixes this issue, introduced by f9582a22dba7 ("[gdb] Fix segfault in
+ for_each_block, part 1"):
+
+ CXX darwin-nat.o
+ /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1169:7: error: no matching function for call to 'breakpoint_inserted_here_p'
+ if (breakpoint_inserted_here_p (inf->aspace, pc))
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Change-Id: I3bb6be75b650319f0fa1dbdceb379b18531da96c
+
+2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: add NEWS entry for change of comment syntax in BPF assembler
+ 2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * NEWS: Add entry about change of comment syntax in the BPF
+ assembler.
+
+2023-11-28 Tom Tromey <tromey@adacore.com>
+
+ Emit DAP "process" event
+ DAP specifies a "process" event that is sent when a process is started
+ or attached to. gdb was not emitting this (several DAP clients appear
+ to ignore it entirely), but it looked easy and harmless to implement.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30473
+
+2023-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Use const std::string for string literals in tui-stack.c
+ I noticed in gdb/tui/tui-stack.c a source-level micro-optimization where
+ strlen with a string literal argument:
+ ...
+ strlen ("bla")
+ ...
+ is replaced with sizeof:
+ ...
+ sizeof ("bla") - 1
+ ...
+
+ The benefit of this is that the optimization is also done at O0, but the
+ drawback is that it makes the expression harder to read.
+
+ Use const std::string to encapsulate the string literals, and use
+ std::string::size () instead.
+
+ I tried making the string names (PROC_PREFIX, LINE_PREFIX, PC_PREFIX and
+ SINGLE_KEY) lower-case, but that clashed with a pre-existing pc_prefix, so
+ I've left them upper-case.
+
+ Tested on x86_64-linux.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ sim: bpf: do not use semicolon to begin comments
+ The BPF assembler has been updated to follow the clang convention in
+ the interpretation of semicolons: they separate statements and
+ directives, and do not start line comments.
+
+2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: change meaning of ; in the BPF assembler
+ The BPF assembler in clang uses semi-colon (;) to separate statements,
+ not to be begin line comments. This patch adapts the GNU assembler
+ accordingly.
+
+ Testsuite and documentation updated accordingly.
+
+ 2023-11-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-bpf.c: Semicolon does not start a comment, but
+ separates multiple commands on a single line.
+ * testsuite/gas/bpf/alu-pseudoc.s: Adapt test accordingly.
+ * testsuite/gas/bpf/spacing-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/offset16-overflow.s: Likewise.
+ * testsuite/gas/bpf/jump-relax-jump.s: Likewise.
+ * testsuite/gas/bpf/jump-relax-ja.s: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp16-overflow-relax.s: Likewise.
+ * testsuite/gas/bpf/disp16-overflow.s: Likewise.
+ * doc/c-bpf.texi (BPF Special Characters): Update.
+
+2023-11-28 Jakub Jelinek <jakub@redhat.com>
+
+ libiberty, ld: Use x86 HW optimized sha1
+ The following patch attempts to use x86 SHA ISA if available to speed
+ up in my testing about 2.5x sha1 build-id processing (in my case on
+ AMD Ryzen 5 3600) while producing the same result.
+ I believe AArch64 has similar HW acceleration for SHA1, perhaps it
+ could be added similarly.
+
+ Note, seems lld uses BLAKE3 rather than md5/sha1. I think it would be
+ a bad idea to lie to users, if they choose --buildid=sha1, we should
+ be using SHA1, not some other checksum, but perhaps we could add some other
+ --buildid= styles and perhaps make one of the new the default.
+
+ Tested on x86_64-linux, both on Intel i9-7960X (which doesn't have
+ sha_ni ISA support) without/with the patch and on AMD Ryzen 5 3600
+ (which does have it) without/with the patch.
+
+ 2023-11-28 Jakub Jelinek <jakub@redhat.com>
+
+ include/
+ * sha1.h (sha1_process_bytes_fn): New typedef.
+ (sha1_choose_process_bytes): Declare.
+ libiberty/
+ * configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
+ * sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
+ and cpuid.h.
+ (sha1_hw_process_bytes, sha1_hw_process_block,
+ sha1_choose_process_bytes): New functions.
+ * config.in: Regenerated.
+ * configure: Regenerated.
+ ld/
+ * ldbuildid.c (generate_build_id): Use sha1_choose_process_bytes ()
+ instead of &sha1_process_bytes.
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add a new check-all-boards target
+ The make-check-all.sh script (gdb/testsuite/make-check-all.sh) is
+ great, it makes it super easy to run some test(s) using all the
+ available board files.
+
+ This commit aims to make this script even easier to access by adding a
+ check-all-boards target to the GDB Makefile. This new target checks
+ for (and requires) a number of environment variables, so the target
+ should be used like this:
+
+ make check-all-boards GDB_TARGET_USERNAME=remote-target \
+ GDB_HOST_USERNAME=remote-host \
+ TESTS="gdb.base/break.exp"
+
+ Where GDB_TARGET_USERNAME and GDB_HOST_USERNAME are the user names
+ that should be passed to the make-check-all.sh --target-user and
+ --host-user command line options respectively.
+
+ My personal intention is to set these variables in my environment, so
+ all I'll need to do is:
+
+ make check-all-boards TESTS="gdb.base/break.exp"
+
+ The make rule always passes --keep-results to the make-check-all.sh
+ script, as I find that the most useful. It's super frustrating to run
+ the tests and realise you forgot that option and the results have been
+ discarded.
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: log 'make check' command in make-check-all.sh
+ I have been making more use of the make-check-all.sh script to run
+ tests against all boards.
+
+ But one thing is pretty annoying. When a test fails on some random
+ board, I have to run make-check-all.sh with --verbose and --dry-run in
+ order to see what RUNTESTFLAGS I should be using.
+
+ I always run with --keep-results on, so, in this commit, I propose
+ that, when --keep-results is on the 'make check' command will be
+ written out to a file within the stored results directory, like:
+
+ check-all/BOARD_NAME/make-check.sh
+
+ then, if I want to rerun a test, I can just:
+
+ sh check-all/BOARD_NAME/make-check.sh
+
+ and the test will be re-run for me.
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: generate dwarf-5 index identically as worker-thread count changes
+ Similar to the previous commit, this commit ensures that the dwarf-5
+ index files are generated identically as the number of worker-threads
+ changes.
+
+ Building the dwarf-5 index makes use of a closed hash table, the
+ bucket_hash local within debug_names::build(). Entries are added to
+ bucket_hash from m_name_to_value_set, which, in turn, is populated
+ by calls to debug_names::insert() in write_debug_names. The insert
+ calls are ordered based on the entries within the cooked_index, and
+ the ordering within cooked_index depends on the number of worker
+ threads that GDB is using.
+
+ My proposal is to sort each chain within the bucket_hash closed hash
+ table prior to using this to build the dwarf-5 index.
+
+ The buckets within bucket_hash will always have the same ordering (for
+ a given GDB build with a given executable), and by sorting the chains
+ within each bucket, we can be sure that GDB will see each entry in a
+ deterministic order.
+
+ I've extended the index creation test to cover this case.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: generate gdb-index identically regardless of work thread count
+ It was observed that changing the number of worker threads that GDB
+ uses (maintenance set worker-threads NUM) would have an impact on the
+ layout of the generated gdb-index.
+
+ The cause seems to be how the CU are distributed between threads, and
+ then symbols that appear in multiple CU can be encountered earlier or
+ later depending on whether a particular CU moves between threads.
+
+ I certainly found this behaviour was reproducible when generating an
+ index for GDB itself, like:
+
+ gdb -q -nx -nh -batch \
+ -eiex 'maint set worker-threads NUM' \
+ -ex 'save gdb-index /tmp/'
+
+ And then setting different values for NUM will change the generated
+ index.
+
+ Now, the question is: does this matter?
+
+ I would like to suggest that yes, this does matter. At Red Hat we
+ generate a gdb-index as part of the build process, and we would
+ ideally like to have reproducible builds: for the same source,
+ compiled with the same tool-chain, we should get the exact same output
+ binary. And we do .... except for the index.
+
+ Now we could simply force GDB to only use a single worker thread when
+ we build the index, but, I don't think the idea of reproducible builds
+ is that strange, so I think we should ensure that our generated
+ indexes are always reproducible.
+
+ To achieve this, I propose that we add an extra step when building the
+ gdb-index file. After constructing the initial symbol hash table
+ contents, we will pull all the symbols out of the hash, sort them,
+ then re-insert them in sorted order. This will ensure that the
+ structure of the generated hash will remain consistent (given the same
+ set of symbols).
+
+ I've extended the existing index-file test to check that the generated
+ index doesn't change if we adjust the number of worker threads used.
+ Given that this test is already rather slow, I've only made one change
+ to the worker-thread count. Maybe this test should be changed to use
+ a smaller binary, which is quicker to load, and for which we could
+ then try many different worker thread counts.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: C++-ify mapped_symtab from dwarf2/index-write.c
+ Make static the functions add_index_entry, find_slot, and hash_expand,
+ member functions of the mapped_symtab class.
+
+ Fold an additional snippet of code from write_gdbindex into
+ mapped_symtab::minimize, this code relates to minimisation, so this
+ seems like a good home for it.
+
+ Make the n_elements, data, and m_string_obstack member variables of
+ mapped_symtab private. Provide a new obstack() member function to
+ provide access to the obstack when needed, and also add member
+ functions begin(), end(), cbegin(), and cend() so that the
+ mapped_symtab class can be treated like a contained and iterated
+ over.
+
+ I've also taken this opportunity to split out the logic for whether
+ the hash table (m_data) needs expanding, this is the new function
+ hash_needs_expanding. This will be useful in a later commit.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: reduce size of generated gdb-index file
+ I noticed in passing that out algorithm for generating the gdb-index
+ file is incorrect. When building the hash table in add_index_entry we
+ count every incoming entry rehash when the number of entries gets too
+ large. However, some of the incoming entries will be duplicates,
+ which don't actually result in new items being added to the hash
+ table.
+
+ As a result, we grow the gdb-index hash table far too often.
+
+ With an unmodified GDB, generating a gdb-index for GDB, I see a file
+ size of 90M, with a hash usage (in the generated index file) of just
+ 2.6%.
+
+ With a patched GDB, generating a gdb-index for the _same_ GDB binary,
+ I now see a gdb-index file size of 30M, with a hash usage of 41.9%.
+
+ This is a 67% reduction in gdb-index file size.
+
+ Obviously, not every gdb-index file is going to see such big savings,
+ however, the larger a program, and the more symbols that are
+ duplicated between compilation units, the more GDB would over count,
+ and so, over-grow the index.
+
+ The gdb-index hash table we create has a minimum size of 1024, and
+ then we grow the hash when it is 75% full, doubling the hash table at
+ that time. Given this, then we expect that either:
+
+ a. The hash table is size 1024, and less than 75% full, or
+ b. The hash table is between 37.5% and 75% full.
+
+ I've include a test that checks some of these constraints -- I've not
+ bothered to check the upper limit, and over full hash table isn't
+ really a problem here, but if the fill percentage is less than 37.5%
+ then this indicates that we've done something wrong (obviously, I also
+ check for the 1024 minimum size).
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: small refactor in selftest-support.exp
+ Split out the code that makes a copy of the GDB executable ready for
+ self testing into a new proc. A later commit in this series wants to
+ load the GDB executable into GDB (for creating an on-disk debug
+ index), but doesn't need to make use of the full do_self_tests proc.
+
+ There should be no changes in what is tested after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: option completion for 'save gdb-index' command
+ Add proper support for option completion to the 'save gdb-index'
+ command. Update save_gdb_index_command function to make use of the
+ new option_def data structures for parsing the '-dwarf-5' option.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: allow use of ~ in 'save gdb-index' command
+ Add a call to gdb_tilde_expand in the save_gdb_index_command function,
+ this means that we can now do:
+
+ (gdb) save gdb-index ~/blah/
+
+ Previous this wouldn't work.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-28 Nick Clifton <nickc@redhat.com>
+
+ New Romanian translation for ld
+
+2023-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix segfault in for_each_block, part 2
+ The previous commit describes PR gdb/30547, a segfault when running test-case
+ gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x).
+
+ The root cause for the segmentation fault is that linux_is_uclinux gives an
+ incorrect result: it returns true instead of false.
+
+ So, why does linux_is_uclinux:
+ ...
+ int
+ linux_is_uclinux (void)
+ {
+ CORE_ADDR dummy;
+
+ return (target_auxv_search (AT_NULL, &dummy) > 0
+ && target_auxv_search (AT_PAGESZ, &dummy) == 0);
+ ...
+ return true?
+
+ This is because ppc_linux_target_wordsize returns 4 instead of 8, causing
+ ppc_linux_nat_target::auxv_parse to misinterpret the auxv vector.
+
+ So, why does ppc_linux_target_wordsize:
+ ...
+ int
+ ppc_linux_target_wordsize (int tid)
+ {
+ int wordsize = 4;
+
+ /* Check for 64-bit inferior process. This is the case when the host is
+ 64-bit, and in addition the top bit of the MSR register is set. */
+ long msr;
+
+ errno = 0;
+ msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0);
+ if (errno == 0 && ppc64_64bit_inferior_p (msr))
+ wordsize = 8;
+
+ return wordsize;
+ }
+ ...
+ return 4?
+
+ Specifically, we get this result because because tid == 0, so we get
+ errno == ESRCH.
+
+ The tid == 0 is caused by the switch_to_no_thread in
+ handle_vfork_child_exec_or_exit:
+ ...
+ /* Switch to no-thread while running clone_program_space, so
+ that clone_program_space doesn't want to read the
+ selected frame of a dead process. */
+ scoped_restore_current_thread restore_thread;
+ switch_to_no_thread ();
+
+ inf->pspace = new program_space (maybe_new_address_space ());
+ ...
+ but moving the maybe_new_address_space call to before that gives us the
+ same result. The tid is no longer 0, but we still get ESRCH because the
+ thread has exited.
+
+ Fix this in handle_vfork_child_exec_or_exit by doing the
+ maybe_new_address_space call in the context of the vfork parent.
+
+ Tested on top of trunk on x86_64-linux and ppc64le-linux.
+ Tested on top of gdb-14-branch on ppc64-linux.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+ PR gdb/30547
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547
+
+2023-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix segfault in for_each_block, part 1
+ When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise
+ on s390x), I run into:
+ ...
+ (gdb) PASS: gdb.base/vfork-follow-parent.exp: \
+ exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \
+ resolution_method=schedule-multiple: print unblock_parent = 1
+ continue^M
+ Continuing.^M
+ Reading symbols from vfork-follow-parent-exit...^M
+ ^M
+ ^M
+ Fatal signal: Segmentation fault^M
+ ----- Backtrace -----^M
+ 0x1027d3e7 gdb_internal_backtrace_1^M
+ src/gdb/bt-utils.c:122^M
+ 0x1027d54f _Z22gdb_internal_backtracev^M
+ src/gdb/bt-utils.c:168^M
+ 0x1057643f handle_fatal_signal^M
+ src/gdb/event-top.c:889^M
+ 0x10576677 handle_sigsegv^M
+ src/gdb/event-top.c:962^M
+ 0x3fffa7610477 ???^M
+ 0x103f2144 for_each_block^M
+ src/gdb/dcache.c:199^M
+ 0x103f235b _Z17dcache_invalidateP13dcache_struct^M
+ src/gdb/dcache.c:251^M
+ 0x10bde8c7 _Z24target_dcache_invalidatev^M
+ src/gdb/target-dcache.c:50^M
+ ...
+ or similar.
+
+ The root cause for the segmentation fault is that linux_is_uclinux gives an
+ incorrect result: it should always return false, given that we're running on a
+ regular linux system, but instead it returns first true, then false.
+
+ In more detail, the segmentation fault happens as follows:
+ - a program space with an address space is created
+ - a second program space is about to be created. maybe_new_address_space
+ is called, and because linux_is_uclinux returns true, maybe_new_address_space
+ returns false, and no new address space is created
+ - a second program space with the same address space is created
+ - a program space is deleted. Because linux_is_uclinux now returns false,
+ gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns
+ false, and the address space is deleted
+ - when gdb uses the address space of the remaining program space, we run into
+ the segfault, because the address space is deleted.
+
+ Hardcoding linux_is_uclinux to false makes the test-case pass.
+
+ We leave addressing the root cause for the following commit in this series.
+
+ For now, prevent the segmentation fault by making the address space a refcounted
+ object.
+
+ This was already suggested here [1]:
+ ...
+ A better solution might be to have the address spaces be reference counted
+ ...
+
+ Tested on top of trunk on x86_64-linux and ppc64le-linux.
+ Tested on top of gdb-14-branch on ppc64-linux.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+ PR gdb/30547
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html
+
+2023-11-28 Haochen Jiang <haochen.jiang@intel.com>
+
+ testsuite: Clean up .allow_index_reg in i386 tests
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/adx.s: Remove .allow_index_reg.
+ * testsuite/gas/i386/amx-complex-inval.l: Ditto.
+ * testsuite/gas/i386/amx-complex-inval.s: Ditto.
+ * testsuite/gas/i386/avx-ifma.s: Ditto.
+ * testsuite/gas/i386/avx-ne-convert.s: Ditto.
+ * testsuite/gas/i386/avx-scalar-2.s: Ditto.
+ * testsuite/gas/i386/avx-vnni-int8.s: Ditto.
+ * testsuite/gas/i386/avx-vnni.s: Ditto.
+ * testsuite/gas/i386/avx-wig.s: Ditto.
+ * testsuite/gas/i386/avx2-wig.s: Ditto.
+ * testsuite/gas/i386/avx2.s: Ditto.
+ * testsuite/gas/i386/avx256int.s: Ditto.
+ * testsuite/gas/i386/avx512_4fmaps.s: Ditto.
+ * testsuite/gas/i386/avx512_4vnniw.s: Ditto.
+ * testsuite/gas/i386/avx512_bf16.s: Ditto.
+ * testsuite/gas/i386/avx512_bf16_vl-inval.l: Ditto.
+ * testsuite/gas/i386/avx512_bf16_vl-inval.s: Ditto.
+ * testsuite/gas/i386/avx512_bf16_vl.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl.s: Ditto.
+ * testsuite/gas/i386/avx512_vpopcntdq.s: Ditto.
+ * testsuite/gas/i386/avx512bitalg.s: Ditto.
+ * testsuite/gas/i386/avx512bitalg_vl.s: Ditto.
+ * testsuite/gas/i386/avx512bw-opts.s: Ditto.
+ * testsuite/gas/i386/avx512bw-wig.s: Ditto.
+ * testsuite/gas/i386/avx512bw.s: Ditto.
+ * testsuite/gas/i386/avx512bw_vl-opts.s: Ditto.
+ * testsuite/gas/i386/avx512bw_vl-wig.s: Ditto.
+ * testsuite/gas/i386/avx512bw_vl.s: Ditto.
+ * testsuite/gas/i386/avx512cd.s: Ditto.
+ * testsuite/gas/i386/avx512cd_vl.s: Ditto.
+ * testsuite/gas/i386/avx512dq-rcig.s: Ditto.
+ * testsuite/gas/i386/avx512dq.s: Ditto.
+ * testsuite/gas/i386/avx512dq_vl.s: Ditto.
+ * testsuite/gas/i386/avx512er-rcig.s: Ditto.
+ * testsuite/gas/i386/avx512er.s: Ditto.
+ * testsuite/gas/i386/avx512f-opts.s: Ditto.
+ * testsuite/gas/i386/avx512f-rcig.s: Ditto.
+ * testsuite/gas/i386/avx512f.s: Ditto.
+ * testsuite/gas/i386/avx512f_gfni.s: Ditto.
+ * testsuite/gas/i386/avx512f_vaes.s: Ditto.
+ * testsuite/gas/i386/avx512f_vl-opts.s: Ditto.
+ * testsuite/gas/i386/avx512f_vl-wig.s: Ditto.
+ * testsuite/gas/i386/avx512f_vl.s: Ditto.
+ * testsuite/gas/i386/avx512f_vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/avx512ifma.s: Ditto.
+ * testsuite/gas/i386/avx512ifma_vl.s: Ditto.
+ * testsuite/gas/i386/avx512pf.s: Ditto.
+ * testsuite/gas/i386/avx512vbmi.s: Ditto.
+ * testsuite/gas/i386/avx512vbmi2.s: Ditto.
+ * testsuite/gas/i386/avx512vbmi2_vl.s: Ditto.
+ * testsuite/gas/i386/avx512vbmi_vl.s: Ditto.
+ * testsuite/gas/i386/avx512vl_gfni.s: Ditto.
+ * testsuite/gas/i386/avx512vl_vaes.s: Ditto.
+ * testsuite/gas/i386/avx512vl_vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/avx512vnni.s: Ditto.
+ * testsuite/gas/i386/avx512vnni_vl.s: Ditto.
+ * testsuite/gas/i386/bmi.s: Ditto.
+ * testsuite/gas/i386/bmi2.s: Ditto.
+ * testsuite/gas/i386/cldemote.s: Ditto.
+ * testsuite/gas/i386/clflushopt.s: Ditto.
+ * testsuite/gas/i386/clwb.s: Ditto.
+ * testsuite/gas/i386/cmpccxadd-inval.l: Ditto.
+ * testsuite/gas/i386/cmpccxadd-inval.s: Ditto.
+ * testsuite/gas/i386/enqcmd-inval.l: Ditto.
+ * testsuite/gas/i386/enqcmd-inval.s: Ditto.
+ * testsuite/gas/i386/enqcmd.s: Ditto.
+ * testsuite/gas/i386/evex-lig-2.s: Ditto.
+ * testsuite/gas/i386/evex-lig.s: Ditto.
+ * testsuite/gas/i386/evex-wig.s: Ditto.
+ * testsuite/gas/i386/evex.s: Ditto.
+ * testsuite/gas/i386/fma-scalar.s: Ditto.
+ * testsuite/gas/i386/fma.s: Ditto.
+ * testsuite/gas/i386/fma4.s: Ditto.
+ * testsuite/gas/i386/gfni.s: Ditto.
+ * testsuite/gas/i386/hle.s: Ditto.
+ * testsuite/gas/i386/ilp32/enqcmd.s: Ditto.
+ * testsuite/gas/i386/ilp32/movdir.s: Ditto.
+ * testsuite/gas/i386/lwp.s: Ditto.
+ * testsuite/gas/i386/movdir.s: Ditto.
+ * testsuite/gas/i386/movdir64b-reg.l: Ditto.
+ * testsuite/gas/i386/movdir64b-reg.s: Ditto.
+ * testsuite/gas/i386/mpx-inval-1.l: Ditto.
+ * testsuite/gas/i386/mpx-inval-1.s: Ditto.
+ * testsuite/gas/i386/mpx.s: Ditto.
+ * testsuite/gas/i386/msrlist-inval.l: Ditto.
+ * testsuite/gas/i386/msrlist-inval.s: Ditto.
+ * testsuite/gas/i386/notrack.s: Ditto.
+ * testsuite/gas/i386/notrackbad.l: Ditto.
+ * testsuite/gas/i386/notrackbad.s: Ditto.
+ * testsuite/gas/i386/optimize-1.s: Ditto.
+ * testsuite/gas/i386/optimize-2.s: Ditto.
+ * testsuite/gas/i386/optimize-3.s: Ditto.
+ * testsuite/gas/i386/optimize-6.s: Ditto.
+ * testsuite/gas/i386/optimize-6a.l: Ditto.
+ * testsuite/gas/i386/optimize-7.l: Ditto.
+ * testsuite/gas/i386/optimize-7.s: Ditto.
+ * testsuite/gas/i386/opts.s: Ditto.
+ * testsuite/gas/i386/prefetchwt1.s: Ditto.
+ * testsuite/gas/i386/raoint.s: Ditto.
+ * testsuite/gas/i386/sha.s: Ditto.
+ * testsuite/gas/i386/sse2avx.s: Ditto.
+ * testsuite/gas/i386/tbm.s: Ditto.
+ * testsuite/gas/i386/vaes.s: Ditto.
+ * testsuite/gas/i386/vex-lig-2.s: Ditto.
+ * testsuite/gas/i386/vp2intersect-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/vp2intersect-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/x86-64-adx.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ifma.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-scalar-2.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-swap.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-vnni.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx2-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx2.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx256int.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_4fmaps.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_4vnniw.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16_vl-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_vpopcntdq.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw-opts.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl-opts.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq-rcig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512er-rcig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512er.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-opts.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-rcig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_gfni.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vaes.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl-opts.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512pf.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_gfni.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vaes.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx_gfni.s: Ditto.
+ * testsuite/gas/i386/x86-64-bmi.s: Ditto.
+ * testsuite/gas/i386/x86-64-bmi2.s: Ditto.
+ * testsuite/gas/i386/x86-64-cldemote.s: Ditto.
+ * testsuite/gas/i386/x86-64-clflushopt.s: Ditto.
+ * testsuite/gas/i386/x86-64-clwb.s: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto.
+ * testsuite/gas/i386/x86-64-enqcmd-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-enqcmd-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-enqcmd.s: Ditto.
+ * testsuite/gas/i386/x86-64-evex-lig-2.s: Ditto.
+ * testsuite/gas/i386/x86-64-evex-lig.s: Ditto.
+ * testsuite/gas/i386/x86-64-evex-wig.s: Ditto.
+ * testsuite/gas/i386/x86-64-evex-wig2.s: Ditto.
+ * testsuite/gas/i386/x86-64-fma-scalar.s: Ditto.
+ * testsuite/gas/i386/x86-64-fma.s: Ditto.
+ * testsuite/gas/i386/x86-64-fma4.s: Ditto.
+ * testsuite/gas/i386/x86-64-fred.s: Ditto.
+ * testsuite/gas/i386/x86-64-gfni.s: Ditto.
+ * testsuite/gas/i386/x86-64-hle.s: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.s: Ditto.
+ * testsuite/gas/i386/x86-64-lwp.s: Ditto.
+ * testsuite/gas/i386/x86-64-movdir.s: Ditto.
+ * testsuite/gas/i386/x86-64-movdir64b-reg.l: Ditto.
+ * testsuite/gas/i386/x86-64-movdir64b-reg.s: Ditto.
+ * testsuite/gas/i386/x86-64-mpx-inval-1.l: Ditto.
+ * testsuite/gas/i386/x86-64-mpx-inval-1.s: Ditto.
+ * testsuite/gas/i386/x86-64-mpx-inval-2.l: Ditto.
+ * testsuite/gas/i386/x86-64-mpx-inval-2.s: Ditto.
+ * testsuite/gas/i386/x86-64-mpx.s: Ditto.
+ * testsuite/gas/i386/x86-64-notrack.s: Ditto.
+ * testsuite/gas/i386/x86-64-notrackbad.l: Ditto.
+ * testsuite/gas/i386/x86-64-notrackbad.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-1.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-2.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-3.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-4.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-7.s: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-7a.l: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-8.l: Ditto.
+ * testsuite/gas/i386/x86-64-optimize-8.s: Ditto.
+ * testsuite/gas/i386/x86-64-opts.s: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchi-warn.s: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchi.s: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchwt1.s: Ditto.
+ * testsuite/gas/i386/x86-64-raoint.s: Ditto.
+ * testsuite/gas/i386/x86-64-sha.s: Ditto.
+ * testsuite/gas/i386/x86-64-sse2avx.s: Ditto.
+ * testsuite/gas/i386/x86-64-tbm.s: Ditto.
+ * testsuite/gas/i386/x86-64-vaes.s: Ditto.
+ * testsuite/gas/i386/x86-64-vex-lig-2.s: Ditto.
+ * testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/x86-64-vp2intersect-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/x86-64-vpclmulqdq.s: Ditto.
+ * testsuite/gas/i386/x86-64-xop.s: Ditto.
+ * testsuite/gas/i386/x86-64-xsavec.s: Ditto.
+ * testsuite/gas/i386/x86-64-xsaves.s: Ditto.
+ * testsuite/gas/i386/xop.s: Ditto.
+ * testsuite/gas/i386/xsavec.s: Ditto.
+ * testsuite/gas/i386/xsaves.s: Ditto.
+
+2023-11-28 Haochen Jiang <haochen.jiang@intel.com>
+
+ testsuite: Clean up #as in dump file for i386 tests
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/avx-gather-intel.d: Remove unused #as.
+ * testsuite/gas/i386/avx-gather.d: Ditto.
+ * testsuite/gas/i386/avx-ifma-intel.d: Ditto.
+ * testsuite/gas/i386/avx-ifma.d: Ditto.
+ * testsuite/gas/i386/avx-ne-convert-intel.d: Ditto.
+ * testsuite/gas/i386/avx-ne-convert.d: Ditto.
+ * testsuite/gas/i386/avx-vnni-int8-intel.d: Ditto.
+ * testsuite/gas/i386/avx-vnni-int8.d: Ditto.
+ * testsuite/gas/i386/avx512_bf16.d: Ditto.
+ * testsuite/gas/i386/avx512_bf16_vl.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16-intel.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl.d: Ditto.
+ * testsuite/gas/i386/avx512_vpopcntdq-intel.d: Ditto.
+ * testsuite/gas/i386/avx512_vpopcntdq.d: Ditto.
+ * testsuite/gas/i386/avx512bitalg-intel.d: Ditto.
+ * testsuite/gas/i386/avx512bitalg.d: Ditto.
+ * testsuite/gas/i386/avx512bitalg_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512bitalg_vl.d: Ditto.
+ * testsuite/gas/i386/avx512bw-opts-intel.d: Ditto.
+ * testsuite/gas/i386/avx512bw-opts.d: Ditto.
+ * testsuite/gas/i386/avx512bw_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512bw_vl-opts-intel.d: Ditto.
+ * testsuite/gas/i386/avx512bw_vl-opts.d: Ditto.
+ * testsuite/gas/i386/avx512bw_vl.d: Ditto.
+ * testsuite/gas/i386/avx512cd-intel.d: Ditto.
+ * testsuite/gas/i386/avx512cd.d: Ditto.
+ * testsuite/gas/i386/avx512cd_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512cd_vl.d: Ditto.
+ * testsuite/gas/i386/avx512dq-intel.d: Ditto.
+ * testsuite/gas/i386/avx512dq.d: Ditto.
+ * testsuite/gas/i386/avx512dq_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512dq_vl.d: Ditto.
+ * testsuite/gas/i386/avx512er-intel.d: Ditto.
+ * testsuite/gas/i386/avx512er.d: Ditto.
+ * testsuite/gas/i386/avx512f-nondef.d: Ditto.
+ * testsuite/gas/i386/avx512f-opts-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f-opts.d: Ditto.
+ * testsuite/gas/i386/avx512f_gfni-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f_gfni.d: Ditto.
+ * testsuite/gas/i386/avx512f_vaes-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f_vaes.d: Ditto.
+ * testsuite/gas/i386/avx512f_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f_vl-opts-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f_vl-opts.d: Ditto.
+ * testsuite/gas/i386/avx512f_vl.d: Ditto.
+ * testsuite/gas/i386/avx512f_vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/avx512f_vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/avx512ifma-intel.d: Ditto.
+ * testsuite/gas/i386/avx512ifma.d: Ditto.
+ * testsuite/gas/i386/avx512ifma_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512ifma_vl.d: Ditto.
+ * testsuite/gas/i386/avx512pf-intel.d: Ditto.
+ * testsuite/gas/i386/avx512pf.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi2-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi2.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi2_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi2_vl.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vbmi_vl.d: Ditto.
+ * testsuite/gas/i386/avx512vl_gfni-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vl_gfni.d: Ditto.
+ * testsuite/gas/i386/avx512vl_vaes-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vl_vaes.d: Ditto.
+ * testsuite/gas/i386/avx512vl_vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vl_vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/avx512vnni-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vnni.d: Ditto.
+ * testsuite/gas/i386/avx512vnni_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512vnni_vl.d: Ditto.
+ * testsuite/gas/i386/bmi-intel.d: Ditto.
+ * testsuite/gas/i386/bmi.d: Ditto.
+ * testsuite/gas/i386/bmi2-intel.d: Ditto.
+ * testsuite/gas/i386/bmi2.d: Ditto.
+ * testsuite/gas/i386/cldemote-intel.d: Ditto.
+ * testsuite/gas/i386/cldemote.d: Ditto.
+ * testsuite/gas/i386/clflushopt-intel.d: Ditto.
+ * testsuite/gas/i386/clflushopt.d: Ditto.
+ * testsuite/gas/i386/clwb-intel.d: Ditto.
+ * testsuite/gas/i386/clwb.d: Ditto.
+ * testsuite/gas/i386/enqcmd-intel.d: Ditto.
+ * testsuite/gas/i386/enqcmd.d: Ditto.
+ * testsuite/gas/i386/gfni-intel.d: Ditto.
+ * testsuite/gas/i386/gfni.d: Ditto.
+ * testsuite/gas/i386/hreset.d: Ditto.
+ * testsuite/gas/i386/invpcid-intel.d: Ditto.
+ * testsuite/gas/i386/invpcid.d: Ditto.
+ * testsuite/gas/i386/keylocker-intel.d: Ditto.
+ * testsuite/gas/i386/keylocker.d: Ditto.
+ * testsuite/gas/i386/movdir-intel.d: Ditto.
+ * testsuite/gas/i386/movdir.d: Ditto.
+ * testsuite/gas/i386/pr27198.d: Ditto.
+ * testsuite/gas/i386/pr30248.d: Ditto.
+ * testsuite/gas/i386/prefetchwt1-intel.d: Ditto.
+ * testsuite/gas/i386/prefetchwt1.d: Ditto.
+ * testsuite/gas/i386/ptwrite-intel.d: Ditto.
+ * testsuite/gas/i386/ptwrite.d: Ditto.
+ * testsuite/gas/i386/raoint-intel.d: Ditto.
+ * testsuite/gas/i386/raoint.d: Ditto.
+ * testsuite/gas/i386/serialize.d: Ditto.
+ * testsuite/gas/i386/tbm-intel.d: Ditto.
+ * testsuite/gas/i386/tdx.d: Ditto.
+ * testsuite/gas/i386/tsxldtrk.d: Ditto.
+ * testsuite/gas/i386/vp2intersect-intel.d: Ditto.
+ * testsuite/gas/i386/vp2intersect.d: Ditto.
+ * testsuite/gas/i386/vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/waitpkg-intel.d: Ditto.
+ * testsuite/gas/i386/waitpkg.d: Ditto.
+ * testsuite/gas/i386/wrmsrns-intel.d: Ditto.
+ * testsuite/gas/i386/wrmsrns.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-gather-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-gather.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ifma-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ifma.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_bf16_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_vpopcntdq-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_vpopcntdq.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bitalg_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw-opts-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw-opts.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl-opts-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl-opts.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512bw_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512cd_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512dq_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512er-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512er.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-nondef.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-opts-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f-opts.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_gfni-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_gfni.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vaes-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vaes.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl-opts-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl-opts.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512f_vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512ifma_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512pf-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512pf.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi2_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vbmi_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_gfni-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_gfni.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vaes-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vaes.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vl_vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512vnni_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx_gfni-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx_gfni.d: Ditto.
+ * testsuite/gas/i386/x86-64-bmi-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-bmi.d: Ditto.
+ * testsuite/gas/i386/x86-64-bmi2-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-bmi2.d: Ditto.
+ * testsuite/gas/i386/x86-64-cldemote-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-cldemote.d: Ditto.
+ * testsuite/gas/i386/x86-64-clflushopt-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-clflushopt.d: Ditto.
+ * testsuite/gas/i386/x86-64-clwb-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-clwb.d: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred.d: Ditto.
+ * testsuite/gas/i386/x86-64-gfni-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-gfni.d: Ditto.
+ * testsuite/gas/i386/x86-64-hreset.d: Ditto.
+ * testsuite/gas/i386/x86-64-invpcid-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-invpcid.d: Ditto.
+ * testsuite/gas/i386/x86-64-keylocker-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-keylocker.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.d: Ditto.
+ * testsuite/gas/i386/x86-64-movsxd-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-movsxd.d: Ditto.
+ * testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-msrlist.d: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchi-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchi.d: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchwt1-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-prefetchwt1.d: Ditto.
+ * testsuite/gas/i386/x86-64-ptwrite-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-ptwrite.d: Ditto.
+ * testsuite/gas/i386/x86-64-raoint-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-raoint.d: Ditto.
+ * testsuite/gas/i386/x86-64-serialize.d: Ditto.
+ * testsuite/gas/i386/x86-64-sysenter.d: Ditto.
+ * testsuite/gas/i386/x86-64-tbm-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-tdx.d: Ditto.
+ * testsuite/gas/i386/x86-64-tsxldtrk.d: Ditto.
+ * testsuite/gas/i386/x86-64-uintr.d: Ditto.
+ * testsuite/gas/i386/x86-64-vp2intersect-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-vp2intersect.d: Ditto.
+ * testsuite/gas/i386/x86-64-vpclmulqdq-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-vpclmulqdq.d: Ditto.
+ * testsuite/gas/i386/x86-64-waitpkg-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-waitpkg.d: Ditto.
+ * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto.
+ * testsuite/gas/i386/x86-64-xsavec-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-xsavec.d: Ditto.
+ * testsuite/gas/i386/x86-64-xsaves-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-xsaves.d: Ditto.
+ * testsuite/gas/i386/xsavec-intel.d: Ditto.
+ * testsuite/gas/i386/xsavec.d: Ditto.
+ * testsuite/gas/i386/xsaves-intel.d: Ditto.
+ * testsuite/gas/i386/xsaves.d: Ditto.
+
+2023-11-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-27 John Baldwin <jhb@FreeBSD.org>
+
+ i386: Use a fallback XSAVE layout for remote targets
+ If a target provides a target description including registers from the
+ XSAVE extended region, but does not provide an XSAVE layout, use a
+ fallback XSAVE layout based on the included registers. This fallback
+ layout matches GDB's behavior in earlier releases which assumes the
+ layout from Intel CPUs.
+
+ This fallback layout is currently only used for remote targets since
+ native targets which support XSAVE provide an explicit layout derived
+ from CPUID.
+
+ PR gdb/30912
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-11-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add boards/cc-with-index-cache.exp
+ We have a target board cc-with-gdb-index that uses the gdb-add-index script to
+ add a .gdb_index index to an exec.
+
+ There is however an alternative way of adding a .gdb_index: the index-cache.
+
+ Add a new target board cc-with-index-cache.
+
+ This is not superfluous for two reasons:
+ - there is functionality that gdb-add-index doesn't support, but the
+ index-cache does: the index-cache can add an index to an exec with a
+ .gnu_debugaltlink (note that when using the cc-with-gdb-index board this
+ case is quietly ignored), and
+ - using the index-cache is excercised in only a few test-cases, and having
+ this target board extends the test coverage to the entire test suite. This
+ is for instance relevant because the index-cache is written by a worker
+ thread in the background, so we can check more thoroughly for data races
+ (see PR symtab/30837).
+
+ Tested on x86_64-linux.
+
+ Shell script changes checked with shellcheck.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Change serial_readchar to throw
+ This changes serial_readchar to throw an exception rather than trying
+ to set and preserve errno.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Change serial_send_break and serial_write to throw
+ This changes serial_send_break and serial_write to throw exceptions
+ rather than attempt to set errno and return an error indicator. This
+ lets us correctly report failures on Windows.
+
+ Both functions had to be converted in a single patch because one
+ implementation of send_break works via write.
+
+ This also introduces remote_serial_send_break to handle error checking
+ when attempting to send a break. This was previously ignored.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Change serial "open" functions to throw exception
+ remote.c assumes that a failure to open the serial connection will set
+ errno. This is somewhat true, because the Windows code tries to set
+ errno appropriately -- but only somewhat, because it isn't clear that
+ the "pex" code sets it, and the tcp code seems to do the wrong thing.
+ It seems better to simply have the serial open functions throw on
+ error.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Change serial_setbaudrate to throw exception
+ remote.c has this code:
+
+ if (serial_setbaudrate (rs->remote_desc, baud_rate))
+ {
+ /* The requested speed could not be set. Error out to
+ top level after closing remote_desc. Take care to
+ set remote_desc to NULL to avoid closing remote_desc
+ more than once. */
+ serial_close (rs->remote_desc);
+ rs->remote_desc = NULL;
+ perror_with_name (name);
+
+ The perror here cannot be correct, because if serial_setbaudrate did
+ set errno, it may be obscured by serial_close.
+
+ This patch changes serial_setbaudrate to throw an exception instead.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Introduce throw_winerror_with_name
+ This introduces throw_winerror_with_name, a Windows analog of
+ perror_with_name, and changes various places in gdb to call it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Fix latent bug in ser_windows_send_break
+ The ClearCommBreak documentation says:
+
+ If the function fails, the return value is zero.
+
+ ser_windows_send_break inverts this check. This has never been
+ noticed because the caller doesn't check the result.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
+
+2023-11-27 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in DAP handling of 'pause' requests
+ While working on cancellation, I noticed that a DAP 'pause' request
+ would set the "do not emit the continue" flag. This meant that a
+ subsequent request that should provoke a 'continue' event would
+ instead suppress the event.
+
+ I then tried writing a more obvious test case for this, involving an
+ inferior call -- and discovered that gdb.events.cont does not fire for
+ an inferior call.
+
+ This patch installs a new event listener for gdb.events.inferior_call
+ and arranges for this to emit continue and stop events when
+ appropriate. It also fixes the original bug, by adding a check to
+ exec_and_expect_stop.
+
+2023-11-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make catch_syscall_enabled return bool
+ Make it return a bool and adjust a few comparisons where it's used.
+
+ Change-Id: Ic77d23b0dcfcfc9195dfe65e4c7ff9cf3229f6fb
+
+2023-11-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: handle completion returning a non-sequence
+ GDB's Python API documentation for gdb.Command.complete() says:
+
+ The 'complete' method can return several values:
+ * If the return value is a sequence, the contents of the
+ sequence are used as the completions. It is up to 'complete'
+ to ensure that the contents actually do complete the word. A
+ zero-length sequence is allowed, it means that there were no
+ completions available. Only string elements of the sequence
+ are used; other elements in the sequence are ignored.
+
+ * If the return value is one of the 'COMPLETE_' constants
+ defined below, then the corresponding GDB-internal completion
+ function is invoked, and its result is used.
+
+ * All other results are treated as though there were no
+ available completions.
+
+ So, returning a non-sequence, and non-integer from a complete method
+ should be fine; it should just be treated as though there are no
+ completions.
+
+ However, if I write a complete method that returns None, I see this
+ behaviour:
+
+ (gdb) complete completefilenone x
+ Python Exception <class 'TypeError'>: 'NoneType' object is not iterable
+ warning: internal error: Unhandled Python exception
+ (gdb)
+
+ Which is caused because we currently assume that anything that is not
+ an integer must be iterable, and we call PyObject_GetIter on it. When
+ this call fails a Python exception is set, but instead of
+ clearing (and therefore ignoring) this exception as we do everywhere
+ else in the Python completion code, we instead just return with the
+ exception set.
+
+ In this commit I add a PySequence_Check call. If this call returns
+ false (and we've already checked the integer case) then we can assume
+ there are no completion results.
+
+ I've added a test which checks returning a non-sequence.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-27 Jiajie Chen <c@jia.je>
+
+ as: Add new estimated reciprocal instructions in LoongArch v1.1
+ New estimated reciprocal instructions in LoongArch v1.1:
+
+ - frecipe.s/d
+ - frsqrte.s/d
+ - vfrecipe.s/d
+ - vfrsqrte.s/d
+ - xvfrecipe.s/d
+ - xvfrsqrte.s/d
+
+2023-11-27 Jiajie Chen <c@jia.je>
+
+ as: Add new atomic instructions in LoongArch v1.1
+ LoongArch V1.1 release is out at
+ https://github.com/loongson/LoongArch-Documentation.
+
+ New atomic instructions in LoongArch v1.1:
+
+ - sc.q
+ - llacq.w/d
+ - screl.w/d
+ - amcas{_db}.b/h/w/d
+ - amswap{_db}.b/h
+ - amadd{_db}.b/h
+
+2023-11-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use more %progbits for arm
+ On pinebook I ran into:
+ ...
+ Running gdb.tui/tui-layout-asm-short-prog.exp ...
+ gdb compile failed, gdb.tui/tui-layout-asm-short-prog.S: Assembler messages:
+ gdb.tui/tui-layout-asm-short-prog.S:23: Error: \
+ junk at end of line, first unrecognized character is `,'
+ ...
+
+ Fix this by using %progbits instead of @progbits for arm.
+
+ Approved-by: Luis Machado <luis.machado@arm.com>
+
+ Tested on x86_64-linux and pinebook.
+
+2023-11-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Two fixes in gdb.python/tui-window-disabled.exp
+ I ran test-case gdb.python/tui-window-disabled.exp on a configuration without
+ python support, and ran into:
+ ...
+ PASS: $exp: cleanup_properly=True: initial restart: set pagination off
+ UNSUPPORTED: $exp: cleanup_properly=True: couldn't restart GDB
+ PASS: $exp: cleanup_properly=False: initial restart: set pagination off
+ UNSUPPORTED: $exp: cleanup_properly=False: couldn't restart GDB
+ ...
+
+ After looking into the test-case, I realized that this is a consequence of
+ !allow_python_tests.
+
+ Handle this instead by requiring allow_python_tests, such that we get the usual
+ and more clear:
+ ...
+ UNSUPPORTED: $exp: require failed: allow_python_tests
+ ...
+
+ Also fix a return without value in clean_restart_and_setup, which if triggered
+ would cause:
+ ...
+ ERROR: expected boolean value but got ""
+ ...
+
+ Tested on x86_64-linux.
+
+2023-11-24 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ gdb: Fix "target file /proc/.../cmdline contained unexpected null characters"
+ When using the gcore command, GDB prints the following warning:
+
+ (gdb) gcore
+ warning: target file /proc/.../cmdline contained unexpected null characters
+
+ The reason is that cmdline is read with target_fileio_read_stralloc(),
+ which warns on seeing null characters. However, it's perfectly valid
+ for cmdline to contain \0s, so switch to target_fileio_read_alloc().
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-24 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: drop leftover match_never() references
+ Commit 27b33966b18e "RISC-V: disallow x0 with certain macro-insns"
+ wasn't properly re-based over recent opcode table additions.
+
+ x86: shrink opcode sets table
+ Have i386-gen produce merely the offsets into i386_optab[]. Besides
+ allowing to shrink the table even on 32-bit builds, this results in
+ removing a level of indirection from the frequently accessed
+ current_templates, in return for adding a level of indirection when
+ looking up mnemonics (commonly happening just once per insn). Plus for
+ PIE builds of gas it also reduces the number of relocations by about two
+ thousand. Finally a somewhat ugly static variable can also be eliminated
+ from i386_displacement().
+
+ x86: also prefer VEX encoding over EVEX one for VCVTNEPS2BF16 when possible
+ Deal with what 58bceb182740 ("x86: prefer VEX encodings over EVEX ones
+ when possible") left out, for being slightly less straightforward.
+
+2023-11-24 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: reduce redundancy in sign/zero extension macro insn handling
+ Fold M_{S,Z}EXTH, deriving signed-ness from the incoming mnemonic. Fold
+ riscv_ext()'s calls md_assemblef(), the first of which were entirely
+ identical, while the other pair differed in just a single character.
+
+ Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-11-24 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: disallow x0 with certain macro-insns
+ While for some of the macro insns using x0 is kind of okay, as they
+ would merely resolve to a sequence of hint insns (and hence not cause
+ misbehavior at runtime), several of them have the degenerate AUIPC
+ followed by a load, store, or branch using other than the designated
+ symbol as address and hence causing runtime issues. Refuse to assemble
+ those, leveraging that the matching function so far wasn't really used
+ for macro insns: NULL is now allowed, indicating a match (which imo is
+ preferable over converting match_never() to match_always()), while
+ other matching functions now (also) used for macro insns need to avoid
+ calling match_opcode().
+
+ Note that for LA the restriction is slightly too strict: In non-PIC mode
+ using x0 would be okay-ish as per above (as it's just LLA there). Yet
+ libopcodes doesn't know what mode gas is presently assembling for, so we
+ want to err on the safe side.
+
+ Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-11-24 Nick Clifton <nickc@redhat.com>
+
+ Fix building for the s390 target with clang
+
+2023-11-24 zengxiao <zengxiao@eswincomputing.com>
+
+ RISC-V: Update 'Zfa' extension version
+ Because the 'Zfa' extension has a version number of 1.0
+ (not 0.1). This commit updates the number.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
+ number of the 'Zfa' extension since it's ratified.
+
+2023-11-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Correct prno instruction name
+ IBM z13 (arch11) introduced ppno (Perform Pseudorandom Number Operation).
+ IBM z14 (arch12) introduced prno (Perform Random Number Operation) and
+ deprecated ppno.
+
+ opcodes/
+ * s390-opc.txt: Correct prno instruction name.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Add missing extended mnemonics
+ Add extended mnemonics specified in the z/Architecture Principles of
+ Operation [1] and z/Architecture Reference Summary [2], that were
+ previously missing from the opcode table.
+
+ The following added extended mnemonics are synonyms to a base mnemonic
+ and therefore disassemble into their base mnemonic:
+ jc, jcth, lfi, llgfi, llghi
+
+ The following added extended mnemonics are more specific than their base
+ mnemonic and therefore disassemble into the added extended mnemonic:
+ risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt
+
+ The following added extended mnemonics are more specific than their base
+ mnemonic, but disassemble into their base mnemonic due to design
+ constraints:
+ notr, notgr
+
+ The missing extended mnemonic jl* conditional jump long flavors cannot
+ be added, as they would clash with the existing non-standard extended
+ mnemonic j* conditional jump flavors jle and jlh. The missing extended
+ mnemonic jlc jump long conditional is not added, as the related jl*
+ flavors cannot be added.
+ Note that these missing jl* conditional jump long flavors are already
+ defined as non-standard jg* flavors instead. While the related missing
+ extended mnemonic jlc could be added as non-standard jgc instead it is
+ forgone in favor of not adding further non-standard mnemonics.
+
+ The missing extended mnemonics sllhh, sllhl, slllh, srlhh, srlhl, and
+ srllh cannot be implemented using the current design, as they require
+ computed operands. For that reason the following missing extended
+ mnemonics are not added as well, as they fall into the same category of
+ instructions that operate on high and low words of registers. They
+ should better be added together, not to confuse the user, which of those
+ instructions are currently implemented or not.
+ lhhr, lhlr, llhfr, llchhr, llchlr, llclhr, llhhhr, llhhlr, llhlhr,
+ nhhr, nhlr, nlhr, ohhr, ohlr, olhr, xhhr, xhlr, xlhr
+
+ [1] IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
+ https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
+ [2] IBM z/Architecture Reference Summary, SA22-7871-11,
+ https://www.ibm.com/support/pages/sites/default/files/2022-09/SA22-7871-11.pdf
+
+ opcodes/
+ * s390-opc.c: Define operand formats R_CP16_28, U6_18, and
+ U5_27. Define instruction formats RIE_RRUUU3, RIE_RRUUU4,
+ and RRF_R0RR4.
+ * s390-opc.txt: Add extended mnemonics jc, jcth, lfi, llgfi,
+ llghi, notgr, notr, risbhgz, risblgz, rnsbgt, rosbgt, and
+ rxsbgt.
+
+ gas/
+ * config/tc-s390.c: Add support to insert operand for format
+ R_CP16_28, reusing existing logic for format V_CP16_12.
+ * testsuite/gas/s390/esa-g5.s: Add test for extended mnemonic
+ jc.
+ * testsuite/gas/s390/esa-g5.d: Likewise.
+ * testsuite/gas/s390/zarch-z900.s: Add test for extended
+ mnemonic llghi.
+ * testsuite/gas/s390/zarch-z900.d: Likewise.
+ * testsuite/gas/s390/zarch-z9-109.s: Add tests for extended
+ mnemonics lfi and llgfi.
+ * testsuite/gas/s390/zarch-z9-109.d: Likewise.
+ * testsuite/gas/s390/zarch-z10.s: Add tests for extended
+ mnemonics rnsbgt, rosbgt, and rxsbgt.
+ * testsuite/gas/s390/zarch-z10.d: Likewise.
+ * testsuite/gas/s390/zarch-z196.s: Add tests for extended
+ mnemonics jcth, risbhgz, and risblgz.
+ * testsuite/gas/s390/zarch-z196.d: Likewise.
+ * testsuite/gas/s390/zarch-arch13.s: Add tests for extended
+ mnemonics notr and notgr.
+ * testsuite/gas/s390/zarch-arch13.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Align optional operand definition to specs
+ The IBM z/Architecture Principle of Operation [1] specifies the last
+ operand(s) of some (extended) mnemonics to be optional. Align the
+ mnemonic definitions in the opcode table according to specification.
+
+ This changes the last operand of the following (extended) mnemonics to
+ be optional:
+ risbg, risbgz, risbgn, risbgnz, risbhg, risblg, rnsbg, rosbg, rxsbg
+
+ Note that efpc and sfpc actually have only one operand, but had
+ erroneously been defined to have two. For backwards compatibility the
+ wrong RR register format must be retained. Since the superfluous second
+ operand is defined as optional the instruction can still be coded as
+ specified.
+
+ [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
+ https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
+
+ opcodes/
+ * s390-opc.txt: Align optional operand definition to
+ specification.
+
+ testsuite/
+ * zarch-z10.s: Add test cases for risbg, risbgz, rnsbg, rosbg,
+ and rxsbg.
+ * zarch-z10.d: Likewise.
+ * zarch-z196.s: Add test cases for risbhg and risblg.
+ * zarch-z196.d: Likewise.
+ * zarch-zEC12.s: Add test cases for risbgn and risbgnz.
+ * zarch-zEC12.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Make operand table indices relative to each other
+ This is a purely mechanical change. It allows subsequent insertions into
+ the operands table without having to renumber all operand indices.
+
+ The only differences in the resulting ELF object are in the .debug_info
+ section. This has been confirmed by diffing the following xxd and readelf
+ output:
+
+ xxd s390-opc.o
+ readelf -aW -x .text -x .data -x .bss -x .rodata -x .debug_info \
+ -x .symtab -x .strtab -x .shstrtab --debug-dump s390-opc.o
+
+ opcodes/
+ * s390-opc.c: Make operand table indices relative to each other.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Add brasl edge test cases from ESA to z/Architecture
+ The ESA opcode test cases for IBM z900 contain a few edge cases. They
+ exercise the brasl mnemonic with its largest allowed negative and
+ positive offsets. Linux on zSeries in ESA mode executes in 31-bit
+ addressing mode. Therefore the ESA test cases are assembled with -m31.
+ In 31-bit addressing mode the address computation using those large
+ offsets wraps, which is correctly reflected in the disassembly.
+
+ Linux on Z in z/Architecture mode executes in 64-bit addressing mode.
+ Therefore the z/Architecture (zarch) test cases are assembled with -m64.
+ In 64-bit addressing mode the address computation using those large
+ offsets does not necessarily wrap.
+
+ gas/
+ * testsuite/gas/s390/zarch-z900.s: Add brasl tests from ESA that
+ exercise edge cases.
+ * testsuite/gas/s390/zarch-z900.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 Jens Remus <jremus@linux.ibm.com>
+
+ s390: Position independent verification of relative addressing
+ Opcode test cases for z/Architecture instructions that use relative
+ addressing contained hardcoded offsets in the test verification
+ patterns. Inserting or reordering of instructions into those test cases
+ therefore required updating of those hardcoded offsets.
+
+ Use regular expressions with backreferences to verify results of test
+ cases containing instructions with relative addressing. This makes the
+ verification position independent.
+
+ gas/
+ * testsuite/gas/s390/esa-g5.d: Make opcode test verification
+ pattern position independent where possible.
+ * testsuite/gas/s390/esa-z900.d: Likewise.
+ * testsuite/gas/s390/zarch-z900.d: Likewise.
+ * testsuite/gas/s390/zarch-z10.d: Likewise.
+ * testsuite/gas/s390/zarch-z196.d: Likewise.
+ * testsuite/gas/s390/zarch-zEC12.d: Likewise.
+
+ Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
+
+2023-11-23 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/GAS: Use addiu instead of addi in test elf-rel.
+
+ MIPS/GAS: Fix test failures due to jr encoding changes on r6
+
+2023-11-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Reformat missing_debug.py using black
+ Reformat gdb/python/lib/gdb/missing_debug.py with black after commit
+ e8c3dafa5f5 ("[gdb/python] Don't import curses.ascii module unless necessary").
+
+2023-11-23 Tom Tromey <tromey@adacore.com>
+
+ Fix build with GCC 7.5
+ A recent change to 'struct field' caused a build failure with GCC
+ 7.5.0, as reported by Tom de Vries:
+
+ /data/vries/gdb/src/gdb/gdbtypes.h:721:51: error:
+ ‘field::m_accessibility’ is too small to hold all values of ‘enum
+ class accessibility’ [-Werror]
+ ENUM_BITFIELD (accessibility) m_accessibility : 2;
+ ^
+
+ Mark Wielaard pointed out that this was a GCC bug:
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
+
+ This patch works around the bug by changing several members not to be
+ bitfields. It reduces the size of the enum's underlying type,
+ instead.
+
+ I also changed m_bitsize to no longer be a bitfield -- that was done
+ for packing reasons in ancient times, but with m_accessibility not
+ being a bitfield, this no longer matters.
+
+ I removed fn_field::dummy. In earlier times it was somewhat normal in
+ gdb to have these dummy fields to keep track of any available padding.
+ However, since the advent of "ptype/o", there doesn't seem to be any
+ need for this.
+
+ This patch does not change the size of struct field, fn_field, or
+ decl_field on 64-bit hosts.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add vector permutation instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds permutation instructions for the "XTheadVector"
+ extension. The 'th' prefix and the "XTheadVector" extension
+ are documented in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ permutation instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VMVXS): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add vector mask instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds mask instructions for the "XTheadVector"
+ extension. The 'th' prefix and the "XTheadVector" extension
+ are documented in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ mask instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VMPOPCM): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add reductions instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds reductions instructions for the "XTheadVector"
+ extension. The 'th' prefix and the "XTheadVector" extension
+ are documented in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ reductions instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add floating-point arithmetic instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds floating-point arithmetic instructions for the
+ "XTheadVector" extension. The 'th' prefix and the
+ "XTheadVector" extension are documented in a PR for the
+ RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ floating-point arithmetic instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VFSQRTV): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add fixed-point arithmetic instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds fixed-point arithmetic instructions for the
+ "XTheadVector" extension. The 'th' prefix and the
+ "XTheadVector" extension are documented in a PR for the
+ RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ fixed-point arithmetic instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VAADDVV): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add integer arithmetic instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds integer arithmetic instructions for the
+ "XTheadVector" extension. The 'th' prefix and the
+ "XTheadVector" extension are documented in a PR for the
+ RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ integer arithmetic instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VADCVVM): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add sub-extension XTheadZvamo for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds the sub-extension "XTheadZvamo" for the
+ "XTheadVector" extension, and it provides AMO instructions
+ for T-Head VECTOR vendor extension. The 'th' prefix and the
+ "XTheadVector" extension are documented in a PR for the
+ RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add support
+ for "XTheadZvamo" extension.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * doc/c-riscv.texi:
+ * testsuite/gas/riscv/x-thead-vector-zvamo.d: New test.
+ * testsuite/gas/riscv/x-thead-vector-zvamo.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VAMOADDWV): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add insn class.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add load/store segment instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore it
+ makes sense to group them into smaller chunks in form of vendor
+ extensions.
+
+ This patch adds provides load/store segment instructions for T-Head VECTOR
+ vendor extension, which same as the "Zvlsseg" extension in RVI 0.71 vector
+ extension, but belongs to the "XTheadVector" extension. The 'th' prefix
+ and the "XTheadVector" extension are documented in a PR for the
+ RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add test.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VLSEG2BV): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add load/store instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions. Therefore
+ it makes sense to group them into smaller chunks in form of
+ vendor extensions.
+
+ This patch adds load/store instructions for the "XTheadVector"
+ extension. The 'th' prefix and the "XTheadVector" extension are
+ documented in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: Add tests for
+ load/store instructions.
+ * testsuite/gas/riscv/x-thead-vector.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_TH_VLBV): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add configuration-setting instructions for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds configuration-setting instructions for the "XTheadVector"
+ extension. The 'th' prefix and the "XTheadVector" extension are documented
+ in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-vector.d: New test.
+ * testsuite/gas/riscv/x-thead-vector.s: New test.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Likewise..
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add CSRs for T-Head VECTOR vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the CSRs for XTheadVector. Because of the
+ conflict between encoding and teh 'V' extension, it is implemented
+ by alias. The 'th' prefix and the "XTheadVector" extension are
+ documented in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Add the class for
+ the CSRs of the "XTheadVector" extension.
+ (riscv_csr_address): Likewise.
+ * testsuite/gas/riscv/x-thead-vector-csr-warn.d: New test.
+ * testsuite/gas/riscv/x-thead-vector-csr-warn.l: New test.
+ * testsuite/gas/riscv/x-thead-vector-csr.d: New test.
+ * testsuite/gas/riscv/x-thead-vector-csr.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (DECLARE_CSR_ALIAS): Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Prefix the CSRs disassembly with 'th'.
+
+2023-11-23 Jin Ma <jinma@linux.alibaba.com>
+
+ RISC-V: Add T-Head VECTOR vendor extension.
+ T-Head has a range of vendor-specific instructions ([2]).
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the "XTheadVector" extension, a collection of
+ T-Head-specific vector instructions. The 'th' prefix and the
+ "XTheadVector" extension are documented in a PR for the RISC-V
+ toolchain conventions ([1]).
+
+ Here are some things that need to be explained:
+ The "XTheadVector" extension is not a custom-extension, but
+ a non-standard non-conforming extension. The encoding space
+ of the "TheadVector" instructions overlaps with those of
+ the 'V' extension. This encoding space conflict is not on
+ purpose, but the result of issues in the past that have
+ been resolved since. Therefore, the "XTheadVector" extension
+ and the 'V' extension are in conflict.
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+ [2] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+ Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): The
+ "XTheadVector" extension and the 'V' extension are in conflict.
+ (riscv_multi_subset_supports): Likewise..
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * doc/c-riscv.texi:
+ * testsuite/gas/riscv/x-thead-vector-fail.d: New test.
+ * testsuite/gas/riscv/x-thead-vector-fail.l: New test.
+ * testsuite/gas/riscv/x-thead-vector.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class):
+
+2023-11-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-22 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix AIX thr!= NULL assertion failure during fork.
+ In AIX, while we followed the child process and detach on fork was on we hit thr!= NULL assertion failure.
+
+ The reason for the same was GDB core trying to switch to a child thread with tid not set that does not
+ exist, since child's ptid was changed to ptid_t (pid, 0, tid) in sync_threadlists() as it was threaded.
+
+ The way this happened was when a new child process is born, its object file will be loaded, calling the new_objfile ()
+ in aix-thread.c file from clone_program_space, which is
+ called from within follow_fork_inferior. Therefore it end ups syncing threadlists via pd_update ().
+
+ This patch is a fix for the same where pd_update () is called in the wait () or in update_thread_list() hook only.
+
+2023-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix resizing of terminal to 1 or 2 lines
+ When starting TUI in a terminal with 3 lines:
+ ...
+ $ echo $LINES
+ 3
+ $ gdb -q -tui
+ ...
+ and resizing the terminal to 2 lines we run into a segfault.
+
+ The problem is that for the source window:
+ - the minimum height is 3 (the default), but
+ - the maximum height is only 2 because there are only 2 lines.
+
+ This discrepancy eventually leads to a call to newwin in make_window with:
+ ...
+ (gdb) p height
+ $1 = 3
+ (gdb) p width
+ $2 = 56
+ (gdb) p y
+ $3 = -1
+ (gdb) p x
+ $4 = 0
+ ...
+ which results in a nullptr.
+
+ This violates the assumption here in tui_apply_current_layout:
+ ....
+ /* Get the new list of currently visible windows. */
+ std::vector<tui_win_info *> new_tui_windows;
+ applied_layout->get_windows (&new_tui_windows);
+ ...
+ that get_windows only returns visible windows, which leads to tui_windows
+ holding a dangling pointer, which results in the segfault.
+
+ Fix this by:
+ - making sure get_windows only returns visible windows, and
+ - detecting the situation and dropping windows from the layout if
+ there's no room for them.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR tui/31044
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
+
+2023-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Allow command window of 1 or 2 lines
+ When starting TUI in a terminal with 2 lines (likewise with 1 line):
+ ...
+ $ echo $LINES
+ 2
+ $ gdb -q -tui
+ ...
+ we run into this assert in tui_apply_current_layout:
+ ...
+ /* This should always be made visible by a layout. */
+ gdb_assert (TUI_CMD_WIN != nullptr);
+ ...
+
+ The problem is that for the command window:
+ - the minimum height is 3 (the default), but
+ - the maximum height is only 2 because there are only 2 lines.
+
+ This discrepancy eventually leads to a call to newwin in make_window with:
+ ...
+ (gdb) p height
+ $1 = 3
+ (gdb) p width
+ $2 = 66
+ (gdb) p y
+ $3 = -1
+ (gdb) p x
+ $4 = 0
+ (gdb)
+ ...
+ which results in a nullptr, which eventually triggers the assert.
+
+ The easiest way to fix this is to change the minimum height of the command
+ window to 1. However, that would also change behaviour for the case that the
+ screen size is 3 lines or more. For instance, in gdb.tui/winheight.exp the
+ number of lines in the terminal is 24, and the test-case checks that the user
+ cannot increase the source window height to the point that the command window
+ height would be less than 3.
+
+ Fix this by calculating the minimum height of the command window as follows:
+ - the default (3) if max_height () allows it, and
+ - max_height () otherwise.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR tui/31044
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
+
+2023-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Don't import curses.ascii module unless necessary
+ I ran into a failure in test-case gdb.python/py-missing-debug.exp with python
+ 3.6, which was fixed by commit 7db795bc67a ("gdb/python: remove use of
+ str.isascii()").
+
+ However, I subsequently ran into a failure with python 3.11:
+ ...
+ (gdb) PASS: $exp: initial checks: debug info no longer found
+ source py-missing-debug.py^M
+ Traceback (most recent call last):^M
+ File "py-missing-debug.py", line 17, in <module>^M
+ from gdb.missing_debug import MissingDebugHandler^M
+ File "missing_debug.py", line 21, in <module>^M
+ from curses.ascii import isascii, isalnum^M
+ File "/usr/lib64/python3.11/_import_failed/curses.py", line 16, in <module>^M
+ raise ImportError(f"""Module '{failed_name}' is not installed.^M
+ ImportError: Module 'curses' is not installed.^M
+ Use:^M
+ sudo zypper install python311-curses^M
+ to install it.^M
+ (gdb) FAIL: $exp: source python script
+ ...
+
+ Apparently I have the curses module installed for 3.6, but not 3.11.
+
+ I could just install it, but the test-case worked fine with 3.11 before commit
+ 7db795bc67a.
+
+ Fix this by only using the curses module when necessary, for python <= 3.7.
+
+ Tested on x86_64-linux, with both python 3.6 and 3.11.
+
+2023-11-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: cleanup monitor_show_help
+ After this commit:
+
+ commit 0b04e52316079981b2b77124198a405d826a05cd
+ Date: Sun Jan 19 14:33:37 2014 -0700
+
+ link gdbserver against libiberty
+
+ we can cleanup how the help text is generated in monitor_show_help.
+ This doesn't change the output that the user will see -- it just folds
+ multiple monitor_output calls into one.
+
+ There should be no user visible change after this commit.
+
+2023-11-22 Lulu Cai <cailulu@loongson.cn>
+
+ LoongArch: fix internal error when as handling unsupported modifier.
+
+2023-11-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Simplify C++ type-printing
+ The C++ type-printing code had its own variant of the accessibility
+ enum. This patch removes this and changes the code to use the new one
+ from gdbtypes.h.
+
+ This patch also changes the C++ code to recognize the default
+ accessibility of a class. This makes ptype a bit more C++-like, and
+ lets us remove a chunk of questionable code.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Use enum accessibility in types and member functions
+ This changes nested types and member functions to use the new
+ 'accessibility' enum, rather than separate private/protected flags.
+ This is done for consistency, but it also lets us simplify some other
+ code in the next patch.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Remove char-based bitfield macros
+ This removes the char-based bitfield macros from gdbtypes.h, as they
+ are no longer used.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Remove some type field accessor macros
+ This removes TYPE_FIELD_PRIVATE, TYPE_FIELD_PROTECTED,
+ TYPE_FIELD_IGNORE, and TYPE_FIELD_VIRTUAL.
+
+ In c-varobj.c, match_accessibility can be removed entirely now. Note
+ that the comment before this function was incorrect.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Remove some QUIT calls from need_access_label_p
+ I think these invocations of QUIT in need_access_label_p are overkill.
+ QUIT is already called from its caller. This just removes them.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Add field::is_public
+ This adds a field::is_public convenience method, and updates one spot
+ to use it.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Remove byte vectors from cplus_struct_type
+ This removes some byte vectors from cplus_struct_type, moving the
+ information into bitfields in holes in struct field.
+
+ A new 'enum accessibility' is added to hold some of this information.
+ A similar enum is removed from c-varobj.c.
+
+ Note that the stabs reader treats "ignored" as an accessibility.
+ However, the stabs texinfo documents this as a public field that is
+ optimized out -- unfortunately nobody has updated the stabs reader to
+ use the better value-based optimized-out machinery. I looked and
+ apparently gcc never emitted this visibility value, so whatever
+ compiler generated this stab is unknown. I left a comment in
+ gdbtypes.h to this effect.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Print field accessibility inline
+ This changes recursive_dump_type to print field accessibility
+ information "inline". This is clearer and preserves the information
+ when the byte vectors are removed.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Use .def file to stringify type codes
+ This changes recursive_dump_type to reuse the type-codes.def file when
+ stringifying type codes.
+
+ This version of the patch changes the "unknown" case to an assert.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-21 Cupertino Miranda <cupertino.miranda@oracle.com>
+
+ bpf: Fixed register parsing disambiguating with possible symbol.
+ This changes parse_bpf_register to detect possible symbols that start with valid
+ register name, however due some following characters are not.
+ Also changed the regs-for-symbols-pseudo.s, adding some entries that
+ should not error if parser is properly detecting the symbol.
+
+2023-11-21 Jan-Benedict Glaw <jbglaw@lug-owl.de>
+
+ [opcodes] ARC + PPC: Fix -Walloc-size warnings
+ Recently, -Walloc-size warnings started to kick in. Fix these two
+ calloc() calls to match the intended usage pattern.
+
+ opcodes/ChangeLog:
+
+ * arc-dis.c (init_arc_disasm_info): Fix calloc() call.
+ * ppc-dis.c (powerpc_init_dialect): Ditto.
+
+2023-11-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix build of darwin-nat.c
+ Patch 743877128 ("gdb: remove regcache's address space") changed the
+ signature of darwin_nat_target::cancel_breakpoint, but missing updating
+ the class declaration, resulting in:
+
+ CXX darwin-nat.o
+ /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1154:20: error: out-of-line definition of 'cancel_breakpoint' does not match any declaration in 'darwin_nat_target'
+ darwin_nat_target::cancel_breakpoint (inferior *inf, ptid_t ptid)
+ ^~~~~~~~~~~~~~~~~
+ /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1290:9: error: too many arguments to function call, expected single argument 'ptid', have 2 arguments
+ ptid_t (inf->pid, 0, thread->gdb_port)))
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.h:129:7: note: 'cancel_breakpoint' declared here
+ int cancel_breakpoint (ptid_t ptid);
+ ^
+
+ Fix that.
+
+ Change-Id: Iedd58b36777eb77bca9e23f94882b217c9c87059
+
+2023-11-21 Tom Tromey <tromey@adacore.com>
+
+ Refactor DAP queue handling
+ A couple of spots in the DAP code use the same workaround for the
+ absence of queue.SimpleQueue before Python 3.6. This patch
+ consolidates these into a single spot.
+
+2023-11-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Handle memory error in s390_linux_get_syscall_number
+ In s390_linux_get_syscall_number, we use read_memory_unsigned_integer, which
+ can throw a memory error.
+
+ According to the function comment though, it should return -1 on error:
+ ...
+ /* Retrieve the syscall number at a ptrace syscall-stop. Return -1
+ upon error. */
+ ...
+
+ Catch the memory error by using safe_read_memory_unsigned_integer instead,
+ similar to how that was fixed for arm in commit eb42bb14895 ("[gdb/tdep] Fix
+ catching syscall execve exit for arm").
+
+ Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
+
+2023-11-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix spurious FAILs with examine-backward.exp, again
+ Commit 59a561480d5 ("Fix spurious FAILs with examine-backward.exp") describes
+ the problem that:
+ ...
+ The test case examine-backward.exp issues the command "x/-s" after the end
+ of the first string in TestStrings, but without making sure that this
+ string is preceded by a string terminator. Thus GDB may spuriously print
+ some random characters from before that string, and then the test fails.
+ ...
+
+ The commit fixes the problem by adding a Barrier variable before the TestStrings
+ variable:
+ ...
+ +const char Barrier[] = { 0x0 };
+ const char TestStrings[] = {
+ ...
+
+ There is however no guarantee that Barrier is placed immediately before
+ TestStrings.
+
+ Before recent commit 169fe7ab54b ("Change gdb.base/examine-backwards.exp for
+ AIX.") on x86_64-linux, I see:
+ ...
+ 0000000000400660 R Barrier
+ 0000000000400680 R TestStrings
+ ...
+
+ So while the Barrier variable is the first before the TestStrings variable,
+ it's not immediately preceding TestStrings.
+
+ After commit 169fe7ab54b:
+ ...
+ 0000000000402259 B Barrier
+ 0000000000402020 D TestStrings
+ ...
+ they're not even in the same section anymore.
+
+ Fix this reliably by adding the zero in the array itself:
+ ...
+ char TestStringsBase[] = {
+ 0x0,
+ ...
+ };
+ char *TestStrings = &TestStringsBase[1];
+ ...
+ and do likewise for TestStringsH and TestStringsW.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/31064
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31064
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: Use initializers in lambda captures unconditionally
+ Initializers in lambda captures were introduced in C++14, and
+ conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c.
+
+ Since C++17 is now required by GDB, use this feature unconditionally.
+
+ Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/disasm.h: Mark callbacks noexcept unconditionally
+ Given that C++17 is now a requirement for GDB, update gdb/disasm.h to
+ define callback function types noexcept unconditionally. The pre-C++17
+ configuration is not supported anymore.
+
+ Change-Id: I0a38e22b7912c70a11425363a991f0b01614343e
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdbsupport: Replace gdb::invoke_result with std::invoke_result
+ Given that GDB now requires C++17, we can replace gdb::invoke_result
+ with std::invoke_result which is provided by <type_traits>.
+
+ This patch also removes gdbsupport/invoke-result.h as it is not used
+ anymore.
+
+ Change-Id: I7e567356d38d6b3d85d8797d61cfc83f6f933f22
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdbsupport: Remove gdb::string_view
+ Now that all places using gdb::string_view have been updated to use
+ std::string_view, this patch drops the gdb::string_view implementation
+ and the tests which came with it.
+
+ As this drops the unittests/string_view-selftests.c, this also
+ implicitly solves PR build/23676, as pointed-out by Tom Tromey.
+
+ Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: Remove uses of gdb::to_string (const std::string_view &)
+ This patch removes all uses of to_string(const std::string_view&) and
+ use the std::string ctor or implicit conversion from std::string_view to
+ std::string instead.
+
+ A later patch will remove this gdb::to_string while removing
+ gdbsupport/gdb_string_view.h.
+
+ Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: Use std::string_view instead of gdb::string_view
+ Given that GDB now requires a C++17, replace all uses of
+ gdb::string_view with std::string_view.
+
+ This change has mostly been done automatically:
+ - gdb::string_view -> std::string_view
+ - #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
+
+ One things which got brought up during review is that gdb::stging_view
+ does support being built from "nullptr" while std::sting_view does not.
+ Two places are manually adjusted to account for this difference:
+ gdb/tui/tui-io.c:tui_getc_1 and
+ gdbsupport/format.h:format_piece::format_piece.
+
+ The above automatic change transformed
+ "gdb::to_string (const gdb::string_view &)" into
+ "gdb::to_string (const std::string_view &)". The various direct users
+ of this function are now explicitly including
+ "gdbsupport/gdb_string_view.h". A later patch will remove the users of
+ gdb::to_string.
+
+ The implementation and tests of gdb::string_view are unchanged, they will
+ be removed in a following patch.
+
+ Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdbsupport: remove gdb::optional
+ The previous patch migrated all the uses of gdb::optional to use
+ std::optional instead, so gdb::optional can be removed entirely
+ as well as the self-tests which came with it.
+
+ Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: Replace gdb::optional with std::optional
+ Since GDB now requires C++17, we don't need the internally maintained
+ gdb::optional implementation. This patch does the following replacing:
+ - gdb::optional -> std::optional
+ - gdb::in_place -> std::in_place
+ - #include "gdbsupport/gdb_optional.h" -> #include <optional>
+
+ This change has mostly been done automatically. One exception is
+ gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
+ already lives in the gdb namespace.
+
+ Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: Use C++17's std::make_unique instead of gdb::make_unique
+ gdb::make_unique is a wrapper around std::make_unique when compiled with
+ C++17. Now that C++17 is required, use std::make_unique directly in the
+ codebase, and remove gdb::make_unique.
+
+ Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net
+
+2023-11-21 Nick Clifton <nickc@redhat.com>
+
+ Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
+ PR 31067
+ Fix typo in previous delta: defined -> referenced.
+
+2023-11-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix catching syscall execve exit for arm
+ When running test-case gdb.base/catch-syscall.exp on a pinebook (64-bit
+ aarch64 kernel, 32-bit userland) I run into:
+ ...
+ (gdb) PASS: $exp: execve: syscall(s) execve appears in 'info breakpoints'
+ continue^M
+ Continuing.^M
+ ^M
+ Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from \
+ /lib/arm-linux-gnueabihf/libc.so.6^M
+ (gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve
+ continue^M
+ Continuing.^M
+ process 32392 is executing new program: catch-syscall^M
+ Cannot access memory at address 0xf77c6a7c^M
+ (gdb) FAIL: $exp: execve: syscall execve has returned
+ ...
+
+ The memory error is thrown by arm_linux_get_syscall_number, when doing:
+ ...
+ /* PC gets incremented before the syscall-stop, so read the
+ previous instruction. */
+ unsigned long this_instr =
+ read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
+ ...
+
+ The reason for the error is that we're stopped at the syscall exit of syscall
+ execve, and the pc is at the first insn of the new exec, which also happens to
+ be the first insn in the code segment, so consequently we cannot read the
+ previous insn.
+
+ Fix this by detecting the situation by looking at the register state, similar
+ to what is done in aarch64_linux_get_syscall_number.
+
+ Furthermore, catch the memory error by using safe_read_memory_unsigned_integer
+ and return -1 instead, matching the documented behaviour of
+ arm_linux_get_syscall_number.
+
+ Finally, rather than using a hardcoded constant 11, introduce an ad-hoc
+ arm_sys_execve.
+
+ Tested on pinebook.
+
+ PR tdep/31071
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31071
+
+2023-11-21 Nick Clifton <nickc@redhat.com>
+
+ Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
+ PR 31067
+ * linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton.
+ * ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave.
+
+2023-11-21 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix gdb.bas/sigall.exp testcase in AIX.
+ In AIX, we are not able to see the message of a signal recieved if a debugee recieves a signal.
+ This is a patch to fix the signal handling done incorrectly in AIX.
+
+ We remove the status that represent program recieving a signal and allow host_status_to_waitstatus to
+ handle it for us.
+
+2023-11-21 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb: Fix segfault with a big .dynamic section size
+ Consider a binary with an erroneous size of the .dynamic section:
+
+ $ readelf -S a.out
+ ...
+ [24] .dynamic DYNAMIC 0000000000004c20 00003c20
+ 000000fffffffa40 0000000000000010 WA 7 0 8
+ ...
+
+ This binary causes a segfault in GDB. GDB is trying to write the .dynamic
+ section into memory allocated on the stack with alloca(). However, the
+ allocation silently fails and the subsequent access to the memory is
+ causing the segfault. (On my node at least.)
+
+ Stack allocation is a bad idea for something of variable size that GDB has
+ no control over. So I changed the code to heap allocation.
+
+ In addition, I changed the type of sect_size to the type that bfd actually
+ returns.
+
+ There should be no user visible change after this.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-20 Tom Tromey <tom@tromey.com>
+
+ Restore .gdb_index v9 display in readelf
+ An earlier patch (commit b05efa39 "readelf..debug-dump=loc displays
+ bogus base addresses") inadvertently removed support for displaying
+ .gdb_index v9 sections.
+
+ This patch corrects the oversight. I tested this by using readelf on
+ an appropriate file.
+
+ * dwarf.c (display_gdb_index): Restore v9 display code.
+
+2023-11-20 Carl Love <cel@linux.ibm.com>
+
+ PowerPC: Fix test gdb.ada/finish-large.exp
+ Function Create_large returns a large data structure. On PowerPC, register
+ r3 contains the address of where the data structure to be returned is to
+ be stored. However, on exit the ABI does not guarantee that r3 has not
+ been changed. The GDB finish command prints the return value of the
+ function at the end of the function. GDB needs to use the
+ DW_TAG_call_site information to determine the value of r3 on entry to
+ the function to correctly print the return value at the end of the
+ function. The test must be compiled with -fvar-tracking for the
+ DW_TAG_call_site information to be included in the executable file.
+
+ This patch adds the -fvar-tracking option to the compile line if the
+ option is supported.
+
+ The patch fixes the one regression error for the test on PowerPC.
+
+ The patch has been tested on Power 10 and X86-64 with no regressions.
+
+2023-11-20 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: adding CU mappings should be idempotent
+ When CTF finds conflicting types, it usually shoves each definition
+ into a CTF dictionary named after the compilation unit.
+
+ The intent of the obscure "cu-mapped link" feature is to allow you to
+ implement custom linkers that shove the definitions into other, more
+ coarse-grained units (say, one per kernel module, even if a module consists
+ of more than one compilation unit): conflicting types within one of these
+ larger components are hidden from name lookup so you can only look up (an
+ arbitrary one of) them by name, but can still be found by chasing type graph
+ links and are still fully deduplicated.
+
+ You do this by calling
+ ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly,
+ with different "CU name"s: the ctf_link() following that will put all
+ conflicting types found in "CU name"s sharing a "bigger lump name" into a
+ child dict in an archive member named "bigger lump name".
+
+ So it's clear enough what happens if you call it repeatedly with the same
+ "bigger lump name" more than once, because that's the whole point of it: but
+ what if you call it with the same "CU name" repeatedly?
+
+ ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name");
+ ctf_link_add_cu_mapping (fp, "CU name", "other name");
+
+ This is meant to be the same as just doing the second of these, as if the
+ first was never called. Alas, this isn't what happens, and what you get is
+ instead a bit of an inconsistent mess: more or less, the first takes
+ precedence, which is the exact opposite of what we wanted.
+
+ Fix this to work the right way round.
+
+ (I plan to add support for CU-mapped links to GNU ld, mainly so that we can
+ properly *test* this machinery.)
+
+ libctf/ChangeLog:
+
+ * ctf-link.c (ctf_create_per_cu): Note the behaviour of
+ repeatedly adding FROMs.
+ (ctf_link_add_cu_mapping): Implement that behavour.
+
+2023-11-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix reopen_exec_file for files with target: prefix
+ Following on from this commit:
+
+ commit f2c4f78c813a9cef38b7e9c9ad18822fb9e19345
+ Date: Thu Sep 21 16:35:30 2023 +0100
+
+ gdb: fix reread_symbols when an objfile has target: prefix
+
+ In this commit I update reopen_exec_file to correctly handle
+ executables with a target: prefix. Before this commit we used the
+ system 'stat' call, which obviously isn't going to work for files with
+ a target: prefix (files located on a possibly remote target machine).
+
+ By switching to bfd_stat we will use remote fileio to stat the remote
+ files, which means we should now correctly detect changes in a remote
+ executable.
+
+ The program_space::ebfd_mtime variable, with which we compare the
+ result of bfd_stat is set with a call to bfd_get_mtime, which in turn
+ calls bfd_stat, so comparing to the result of calling bfd_stat makes
+ sense (I think).
+
+ As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
+ BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
+ will always return the time at which the BFD was created. As a result
+ comparing the results will always show the file having changed.
+
+ I don't believe that GDB can set the main executable to an in-memory
+ BFD object, so, in this commit, I simply assert that the executable is
+ not in-memory. If this ever changes then we would need to decide how
+ to handle this case -- always reload, or never reload. The assert
+ doesn't appear to trigger for our current test suite.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move all bfd_cache_close_all calls in gdb_bfd.c
+ In the following commit I ran into a problem. The next commit aims to
+ improve GDB's handling of the main executable being a file on a remote
+ target (i.e. one with a 'target:' prefix).
+
+ To do this I have replaced a system 'stat' call with a bfd_stat call.
+
+ However, doing this caused a regression in gdb.base/attach.exp.
+
+ The problem is that the bfd library caches open FILE* handles for bfd
+ objects that it has accessed, which is great for short-lived, non
+ interactive programs (e.g. the assembler, or objcopy, etc), however,
+ for GDB this caching causes us a problem.
+
+ If we open the main executable as a bfd then the bfd library will
+ cache the open FILE*. If some time passes, maybe just sat at the GDB
+ prompt, or with the inferior running, and then later we use bfd_stat
+ to check if the underlying, on-disk file has changed, then the bfd
+ library will actually use fstat on the underlying file descriptor.
+ This is of course slightly different than using system stat on with
+ the on-disk file name.
+
+ If the on-disk file has changed then system stat will give results for
+ the current on-disk file. But, if the bfd cache is still holding open
+ the file descriptor for the original on-disk file (from before the
+ change) then fstat will return a result based on the original file,
+ and so show no change as having happened.
+
+ This is a known problem in GDB, and so far this has been solved by
+ scattering bfd_cache_close_all() calls throughout GDB. But, as I
+ said, in the next commit I've made a change and run into a
+ problem (gdb.base/attach.exp) where we are apparently missing a
+ bfd_cache_close_all() call.
+
+ Now I could solve this problem by adding a bfd_cache_close_all() call
+ before the bfd_stat call that I plan to add in the next commit, that
+ would for sure solve the problem, but feels a little crude.
+
+ Better I think would be to track down where the bfd is being opened
+ and add a corresponding bfd_cache_close_all() call elsewhere in GDB
+ once we've finished doing whatever it is that caused us to open the
+ bfd in the first place.
+
+ This second solution felt like the better choice, so I tracked the
+ problem down to elf_locate_base and fixed that. But that just exposed
+ another problem in gdb_bfd_map_section which was also re-opening the
+ bfd, so I fixed this (with another bfd_cache_close_all() call), and
+ that exposed another issue in gdbarch_lookup_osabi... and at this
+ point I wondered if I was approaching this problem the wrong way...
+
+ .... And so, I wonder, is there a _better_ way to handle these
+ bfd_cache_close_all() calls?
+
+ I see two problems with the current approach:
+
+ 1. It's fragile. Folk aren't always aware that they need to clear
+ the bfd cache, and this feels like something that is easy to
+ overlook in review. So adding new code to GDB can innocently touch
+ a bfd, which populates the cache, which will then be a bug that can
+ lie hidden until an on-disk file just happens to change at the wrong
+ time ... and GDB fails to spot the change. Additionally,
+
+ 2. It's in efficient. The caching is intended to stop the bfd
+ library from continually having to re-open the on-disk file. If we
+ have a function that touches a bfd then often that function is the
+ obvious place to call bfd_cache_close_all. But if a single GDB
+ command calls multiple functions, each of which touch the bfd, then
+ we will end up opening and closing the same on-disk file multiple
+ times. It feels like we would be better postponing the
+ bfd_cache_close_all call until some later point, then we can benefit
+ from the bfd cache.
+
+ So, in this commit I propose a new approach. We now clear the bfd
+ cache in two places:
+
+ (a) Just before we display a GDB prompt. We display a prompt after
+ completing a command, and GDB is about to enter an idle state
+ waiting for further input from the user (or in async mode, for an
+ inferior event). If while we are in this idle state the user
+ changes the on-disk file(s) then we would like GDB to notice this
+ the next time it leaves its idle state, e.g. the next time the user
+ executes a command, or when an inferior event arrives,
+
+ (b) When we resume the inferior. In synchronous mode, resuming the
+ inferior is another time when GDB is blocked and sitting idle, but
+ in this case we don't display a prompt. As with (a) above, when an
+ inferior event arrives we want GDB to notice any changes to on-disk
+ files.
+
+ It turns out that there are existing observers for both of these
+ cases (before_prompt and target_resumed respectively), so my initial
+ thought was that I should attach to these observers in gdb_bfd.c, and
+ in both cases call bfd_cache_close_all().
+
+ And this does indeed solve the gdb.base/attach.exp problem that I see
+ with the following commit.
+
+ However, I see a problem with this solution.
+
+ Both of the observers I'm using are exposed through the Python API as
+ events that a user can hook into. The user can potentially run any
+ GDB command (using gdb.execute), so Python code might end up causing
+ some bfds to be reopened, and inserted into the cache.
+
+ To solve this one solution would be to add a bfd_cache_close_all()
+ call into gdbpy_enter::~gdbpy_enter(). Unfortunately, there's no
+ similar enter/exit object for Guile, though right now Guile doesn't
+ offer the same event API, so maybe we could just ignore that
+ problem... but this doesn't feel great.
+
+ So instead, I think a better solution might be to not use observers
+ for the bfd_cache_close_all() calls. Instead, I'll call
+ bfd_cache_close_all() directly from core GDB after we've notified the
+ before_prompt and target_resumed observers, this was we can be sure
+ that the cache is cleared after the observers have run, and before GDB
+ enters an idle state.
+
+ This commit also removes all of the other bfd_cache_close_all() calls
+ from GDB. My claim is that these are no longer needed.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-20 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/infrun: simplify process_event_stop_test
+ The previous commit introduced some local variables to make some if
+ statements simpler. This commit uses them more liberally throughout the
+ process_event_stop_test in order to simplify the function a little more.
+ No functional changes are expected.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-20 Guinevere Larsen <blarsen@redhat.com>
+
+ 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
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-18 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: bpf: do not allow referring to register names as symbols in operands
+ 2023-11-18 Jose E. Marchesi <jemarch@gnu.org>
+
+ * config/tc-bpf.c (parse_bpf_register): Move before
+ bpf_parse_name.
+ (bpf_parse_name): Do not allow using symbols that are also
+ register names as operands in pseudo-c syntax.
+ * testsuite/gas/bpf/regs-for-symbols-pseudoc.d: New file.
+ * testsuite/gas/bpf/regs-for-symbols-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/regs-for-symbols-pseudoc.l: Likewise.
+ * doc/c-bpf.texi (BPF Registers): Document that it is not possible
+ to refer to register names as symbols in instruction operands.
+
+2023-11-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-17 David Faust <david.faust@oracle.com>
+
+ bpf: avoid creating wrong symbols while parsing
+ To support the "pseudo-C" asm dialect in BPF, the BPF parser must often
+ attempt multiple different templates for a single instruction. In some
+ cases this can cause the parser to incorrectly parse part of the
+ instruction opcode as an expression, which leads to the creation of a
+ new undefined symbol.
+
+ Once the parser recognizes the error, the expression is discarded and it
+ tries again with a new instruction template. However, symbols created
+ during the process are added to the symbol table and are not removed
+ even if the expression is discarded.
+
+ This is a problem for BPF: generally the assembled object will be loaded
+ directly to the Linux kernel, without being linked. These erroneous
+ parser-created symbols are rejected by the kernel BPF loader, and the
+ entire object is refused.
+
+ This patch remedies the issue by tentatively creating symbols while
+ parsing instruction operands, and storing them in a temporary list
+ rather than immediately inserting them into the symbol table. Later,
+ after the parser is sure that it has correctly parsed the instruction,
+ those symbols are committed to the real symbol table.
+
+ This approach is modeled directly after Jan Beulich's patch for RISC-V:
+
+ commit 7a29ee290307087e1749ce610207e93a15d0b78d
+ RISC-V: adjust logic to avoid register name symbols
+
+ Many thanks to Jan for recognizing the problem as similar, and pointing
+ me to that patch.
+
+ gas/
+
+ * config/tc-bpf.c (parsing_insn_operands): New.
+ (parse_expression): Set it here.
+ (deferred_sym_rootP, deferred_sym_lastP): New.
+ (orphan_sym_rootP, orphan_sym_lastP): New.
+ (bpf_parse_name): New.
+ (parse_error): Clear deferred symbol list on error.
+ (md_assemble): Clear parsing_insn_operands. Commit deferred
+ symbols to symbol table on successful parse.
+ * config/tc-bpf.h (md_parse_name): Define to...
+ (bpf_parse_name): ...this. New prototype.
+ * testsuite/gas/bpf/asm-extra-sym-1.s: New test source.
+ * testsuite/gas/bpf/asm-extra-sym-1.d: New test.
+ * testsuite/gas/bpf/bpf.exp: Run new test.
+
+2023-11-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: pass address_space to target dcache functions
+ A simple refactor to make the reference to current_program_space bubble
+ up one level. No behavior changes expected.
+
+ Change-Id: I237cf2f45ae73c35bcb433ce40e3c03cef6b87e2
+
+2023-11-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove get_current_regcache
+ Remove get_current_regcache, inlining the call to get_thread_regcache in
+ callers. When possible, pass the right thread_info object known from
+ the local context. Otherwise, fall back to passing `inferior_thread ()`.
+
+ This makes the reference to global context bubble up one level, a small
+ step towards the long term goal of reducing the number of references to
+ global context (or rather, moving those references as close as possible
+ to the top of the call tree).
+
+ No behavior change expected.
+
+ Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
+
+2023-11-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove regcache's address space
+ While looking at the regcache code, I noticed that the address space
+ (passed to regcache when constructing it, and available through
+ regcache::aspace) wasn't relevant for the regcache itself. Callers of
+ regcache::aspace use that method because it appears to be a convenient
+ way of getting the address space for a thread, if you already have the
+ regcache. But there is always another way to get the address space, as
+ the callers pretty much always know which thread they are dealing with.
+ The regcache code itself doesn't use the address space.
+
+ This patch removes anything related to address_space from the regcache
+ code, and updates callers to get it from the thread in context. This
+ removes a bit of unnecessary complexity from the regcache code.
+
+ The current get_thread_arch_regcache function gets an address_space for
+ the given thread using the target_thread_address_space function (which
+ calls the target_ops::thread_address_space method). This suggest that
+ there might have been the intention of supporting per-thread address
+ spaces. But digging through the history, I did not find any such case.
+ Maybe this method was just added because we needed a way to get an
+ address space from a ptid (because constructing a regcache required an
+ address space), and this seemed like the right way to do it, I don't
+ know.
+
+ The only implementations of thread_address_space and
+ process_stratum_target::thread_address_space and
+ linux_nat_target::thread_address_space, which essentially just return
+ the inferior's address space. And thread_address_space is only used in
+ the current get_thread_arch_regcache, which gets removed. So, I think
+ that the thread_address_space target method can be removed, and we can
+ assume that it's fine to use the inferior's address space everywhere.
+ Callers of regcache::aspace are updated to get the address space from
+ the relevant inferior, either using some context they already know
+ about, or in last resort using the current global context.
+
+ So, to summarize:
+
+ - remove everything in regcache related to address spaces
+ - in particular, remove get_thread_arch_regcache, and rename
+ get_thread_arch_aspace_regcache to get_thread_arch_regcache
+ - remove target_ops::thread_address_space, and
+ target_thread_address_space
+ - adjust all users of regcache::aspace to get the address space another
+ way
+
+ Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7
+
+2023-11-17 Tom Tromey <tom@tromey.com>
+
+ Remove extraneous blocks from dwarf2/read.c:new_symbol
+ dwarf2/read.c:new_symbol has some extra braces in a couple of 'case's.
+ These read weirdly to me, and since they aren't necessary, this patch
+ removes the braces and reindents the bodies. Tested by rebuilding.
+
+2023-11-17 Joseph Myers <joseph@codesourcery.com>
+
+ Fix read_ranges for 32-bit long
+ bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which
+ doesn't work correctly when long is 32-bit and bfd_vma is 64-bit
+ (observed as "nm -l" being very slow for mingw64 host; probably causes
+ issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64).
+ Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere.
+
+2023-11-17 Tom Tromey <tromey@adacore.com>
+
+ Ignore static members in NoOpStructPrinter
+ Hannes' patch to show local variables in the TUI pointed out that
+ NoOpStructPrinter should ignore static members. This patch implements
+ this.
+
+2023-11-17 Tom Tromey <tromey@adacore.com>
+
+ Implement the notStopped DAP response
+ DAP specifies that a request can fail with the "notStopped" message if
+ the inferior is running but the request requires that it first be
+ stopped.
+
+ This patch implements this for gdb. Most requests are assumed to
+ require a stopped inferior, and the exceptions are noted by a new
+ 'request' parameter.
+
+ You may notice that the implementation is a bit racy. I think this is
+ inherent -- unless the client waits for a stop event before sending a
+ request, the request may be processed at any time relative to a stop.
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=31037
+
+ Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-11-17 Tom Tromey <tromey@adacore.com>
+
+ Remove ExecutionInvoker
+ ExecutionInvoker is no longer really needed, due to the previous DAP
+ refactoring. This patch removes it in favor of an ordinary function.
+ One spot (the 'continue' request) could still have used it, but is
+ more succinctly expressed as a lambda.
+
+ Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-11-17 Tom Tromey <tromey@adacore.com>
+
+ Automatically run (most) DAP requests in gdb thread
+ Nearly every DAP request implementation forwards its work to the gdb
+ thread, using send_gdb_with_response. This patch refactors the
+ 'request' decorator to make this automatic, and to provide some
+ parameters so that the unusual requests can express their needs as
+ well.
+
+ In a few spots this simplifies the code by removing an unnecessary
+ helper function. This could be done in more places as well if we
+ wanted.
+
+ The main motivation for this patch is that I thought it would be
+ helpful for cancellation. I am still working on that, but meanwhile
+ the parameterization of 'request' makes it easy to handle the
+ 'notStopped' response as well.
+
+ Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
+
+2023-11-17 YunQiang Su <yunqiang.su@cipunited.com>
+
+ Gold/MIPS: Add targ_extra_size=64 for mips32 triples
+
+2023-11-17 Tom Tromey <tromey@adacore.com>
+
+ Handle StackFrameFormat in DAP
+ DAP specifies a StackFrameFormat object that can be used to change how
+ the "name" part of a stack frame is constructed. While this output
+ can already be done in a nicer way (and also letting the client choose
+ the formatting), nevertheless it is in the spec, so I figured I'd
+ implement it.
+
+ While implementing this, I discovered that the current code does not
+ correctly preserve frame IDs across requests. I rewrote frame
+ iteration to preserve this, and it turned out to be simpler to combine
+ these patches.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475
+
+2023-11-17 Pedro Alves <pedro@palves.net>
+
+ Fix AMD_DBGAPI_SCOPED_DEBUG_START_END wrong setting
+ The AMD_DBGAPI_SCOPED_DEBUG_START_END macro in gdb/amd-dbgapi-target.c
+ is incorrectly controlled by "set debug infrun", while it should be
+ controlled by "set debug amd-dbgapi" instead. This commit fixes it.
+
+ Change-Id: I8ec2b1a4b9980c2d565a8aafd060ed070eeb3b29
+
+2023-11-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: improve a few diagnostics
+ PR gas/31043
+ "unsupported instruction ..." can mean about anything, and can also be
+ mistaken to mean something that isn't meant. Replace most of its uses by
+ more specific diagnostics,
+
+ While there also take the opportunity and purge the no longer used
+ invalid_register_operand enumerator.
+
+2023-11-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't allow pseudo-prefixes to be overridden by legacy suffixes
+ Deprecated functionality would better not win over its modern
+ counterparts.
+
+ x86: CPU-qualify {disp16} / {disp32}
+ {disp16} is invalid to use in 64-bit mode, while {disp32} is invalid to
+ use on pre-386 CPUs. The latter, also affecting other (real) prefixes,
+ further requires that like for insns we fully check the CPU flags; till
+ now only Cpu64/CpuNo64 were taken into consideration.
+
+ x86: use IS_ELF
+ ... instead of (inefficiently) open-coding it.
+
+2023-11-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: conditionally hide object-format-specific functions
+ ELF-only functions don't need to be built when dealing with a non-ELF
+ target. md_section_align() also doesn't need to be a function when
+ dealing with non-AOUT targets. Similarly tc_fix_adjustable() can be a
+ simple macro when building non-ELF targets.
+
+ Furthermore x86_elf_abi is already used in ELF-only code sections, with
+ one exception. By adjusting that, the otherwise bogusly named variable
+ can also be confined to just ELF builds.
+
+2023-11-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold conditionals in check_long_reg()
+ Simplify the code follow ing what check_{,q}word_reg() already do. This
+ the also eliminates a stale comment talking about a warning when an
+ error is raised. While there, correct a similarly stale comment in
+ check_qword_reg() while there.
+
+2023-11-17 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: extend expected-size check in check_qword_reg()
+ Due to a missing check "crc32q %al, %rax" was wrongly translated to the
+ encoding of "crc32q %rax, %rax", rather than being rejected as invalid.
+ (The mnemonic suffix describes the source operand, not the destination
+ one.)
+
+ Note that check_{word,long}_reg() do not (currently) appear to require
+ similar amending, as there are no insn templates permitting an L or W
+ suffix and having an operand which allows for Reg8 and Reg64, but
+ neither Reg16 nor Reg32.
+
+2023-11-17 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add more relaxation testcases
+ 1. .so relaxation testcase
+ 2. ld --no-relax testcase
+ 3. segment alignment testcase
+
+ LoongArch: Modify link_info.relax_pass from 3 to 2
+ The first pass handles R_LARCH_RELAX relocations, the second pass
+ handles R_LARCH_ALIGN relocations.
+
+ LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition
+ Previously the condition prevented shared objects from being relaxed.
+ To remove the limitation, we need to update program header size and
+ .eh_frame_hdr size before relaxation.
+
+ LoongArch: Multiple relax_trip in one relax_pass
+ If deleting instructions in one relax_trip, set again to true to start the
+ next relax_trip.
+
+ LoongArch: Directly delete relaxed instuctions in first relaxation pass
+ Directly delete relaxed instuctions in first relaxation pass, not use
+ R_LARCH_DELETE relocation. If not, the PC-relative offset may increase.
+
+ LoongArch: Fix ld --no-relax bug
+ When calling ld with --no-relax, pcalau12i + ld.d still can be relaxed.
+ This patch fix this bug and pcalau12i + ld.d can be relaxed with --relax.
+
+2023-11-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove two uses of obstack
+ Remove uses of obstack in the code generating the libraries XML for
+ Windows and AIX. Use std::string instead. I'm not able to test this
+ change, unfortunately.
+
+ Change-Id: I28480913337e3fe8d6c31e551626931e6b1367ef
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-16 Tom Tromey <tom@tromey.com>
+
+ Fix small bug in compile.exp
+ compile.exp generally does not work for me on Fedora 38. However, I
+ sent a GCC patch to fix the plugin crash. With that patch, I get this
+ error from one test in compile.exp:
+
+ gdb command line:1:22: warning: initialization of 'int (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]
+
+ This patch adds a cast to compile.exp. This makes the test pass.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-11-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: remove use of str.isascii()
+ This commit:
+
+ commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
+ Date: Sun Oct 15 22:48:42 2023 +0100
+
+ gdb: implement missing debug handler hook for Python
+
+ introduced a use of str.isascii(), which was only added in Python 3.7.
+
+ This commit switches to use curses.ascii.isascii(), as this was
+ available in 3.6.
+
+ The same is true for str.isalnum(), which is replaced with
+ curses.ascii.isalnum().
+
+ There should be no user visible changes after this commit.
+
+2023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support for VMSA feature enhancements.
+ This patch adds the permission model enhancement and memory
+ attribute index enhancement features and their corresponding
+ system registers in AArch64 assembler.
+ Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE)
+ Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE)
+ Memory Attribute Index Enhancement (FEAT_AIE)
+ Extension to Translation Control Registers (FEAT_TCR2)
+
+ These features are available by default from Armv9.4-A architecture.
+
+2023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add new AT system instructions.
+ This patch adds 3 new AT system instructions through FEAT_ATS1A
+ feature, which are available by default from Armv9.4-A architecture.
+
+2023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support to new features in RAS extension.
+ This patch also adds support for:
+ 1. FEAT_RASv2 feature and "ERXGSR_EL1" system register.
+ RASv2 feature is enabled by passing +rasv2 to -march
+ (eg: -march=armv8-a+rasv2).
+
+ 2. FEAT_SCTLR2 and following system registers.
+ SCTLR2_EL1, SCTLR2_EL12, SCTLR2_EL2 and SCTLR2_EL3.
+
+ 3. FEAT_FGT2 and following system registers.
+ HDFGRTR2_EL2, HDFGWTR2_EL2, HFGRTR2_EL2, HFGWTR2_EL2
+
+ 4. FEAT_PFAR and following system registers.
+ PFAR_EL1, PFAR_EL2 and PFAR_EL12.
+
+ FEAT_RASv2, FEAT_SCTLR2, FEAT_FGT2 and FEAT_PFAR features are by default
+ enabled from Armv9.4-A architecture.
+
+ This patch also adds support for two read only system registers
+ id_aa64mmfr3_el1 and id_aa64mmfr4_el1, which are available from
+ Armv8-A Architecture.
+
+2023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add features to the Statistical Profiling Extension.
+ This patch adds features to the Statistical Profiling Extension,
+ identified as FEAT_SPEv1p4, FEAT_SPE_FDS, and FEAT_SPE_CRR, which
+ are enabled by default from Armv9.4-A.
+
+ Also adds support for system register "pmsdsfr_el1".
+
+2023-11-16 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add SLC target for PRFM instruction.
+ This patch adds support for FEAT_PRFMSLC feature which enables
+ SLC target for PRFM instructions.
+
+2023-11-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/NEWS: merge two 'New commands' sections
+ Spotted that we'd gained two 'New commands' sections in our 'Changes
+ since GDB 14' NEWS file block. I've merged them together.
+
+ Also, one of these two sections was actually called 'New Commands',
+ however, all the other places in the NEWS file use 'New commands', so
+ I've changed to use that.
+
+2023-11-16 Vladislav Khmelevsky <och95@yandex.ru>
+
+ Fix emit-relocs for aarch64 gold
+ Fix relocation offsets values for the relaxed input sections the same
+ way it was fixed for the sections in PR21430.
+
+2023-11-16 Ying Huang <ying.huang@oss.cipunited.com>
+
+ sim: mips: Change E_MIPS_* to EF_MIPS_*
+ According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
+ and glibc, we also need to change it here to keep same style.
+ We can refer to this commit record:
+ https://sourceware.org/pipermail/binutils/2023-October/129904.html
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-16 Ying Huang <ying.huang@oss.cipunited.com>
+
+ gdb: mips: Change E_MIPS_* to EF_MIPS_*
+ According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
+ and glibc, we also need to change it here to keep same style.
+ We can refer to this commit record:
+ https://sourceware.org/pipermail/binutils/2023-October/129904.html
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-15 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/threads-after-exec.exp race
+ Simon noticed that gdb.threads/threads-after-exec.exp was racy. You
+ can consistenly reproduce it (at git hash
+ 319b460545dc79280e2904dcc280057cf71fb753), with:
+
+ $ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp"
+
+ gdb.log shows:
+
+ (...)
+ Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290
+ in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec
+ info threads
+ Id Target Id Frame
+ * 3 process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads
+ (...)
+ maint info linux-lwps
+ LWP Ptid Thread ID
+ 1443269.1443269.0 1.3
+ (gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps
+
+ The FAILs happen because the .exp file expects that after the exec,
+ the only thread has GDB thread number 1, but it has instead 3.
+
+ This is yet another case of zombie leader detection making things a
+ bit fuzzy.
+
+ In the passing case, we have:
+
+ continue
+ Continuing.
+ [New Thread 0x7ffff7bff640 (LWP 603183)]
+ [Thread 0x7ffff7bff640 (LWP 603183) exited]
+ process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec
+
+ While in the failing case, we have (note remarks on the rhs):
+
+ continue
+ Continuing.
+ [New Thread 0x7ffff7bff640 (LWP 600205)]
+ [Thread 0x7ffff7f95740 (LWP 600202) exited] <<< gdb deletes leader thread, thread 1.
+ [New LWP 600202] <<< gdb adds it back -- this is now thread 3.
+ [Thread 0x7ffff7bff640 (LWP 600205) exited]
+ process 600202 is executing new program: .../threads-after-exec/threads-after-exec
+
+ The testcase only has two threads, yet GDB presented the exec for
+ thread 3. This is GDB deleting the leader (the backend detected it
+ was zombie, due to the exec), and then adding the leader back when it
+ saw the exec event.
+
+ I've recorded some thoughts about this in PR gdb/31069.
+
+ For now, this commit just makes the testcase cope with the non-one
+ thread number, as the number is not important for what this test is
+ exercising.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069
+ Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae
+
+2023-11-15 Tom Tromey <tromey@adacore.com>
+
+ Check gdb_python_module in gdbpy_handle_missing_debuginfo
+ If you run gdb in the build tree without --data-directory, on a
+ program that does not have debug info, it will crash, because
+ gdbpy_handle_missing_debuginfo unconditionally uses gdb_python_module.
+
+ Other code in gdb using gdb_python_module checks it first and it
+ seemes harmless to do the same thing here. (gdb_python_initialized
+ does not cover this case so that python can be partially initialized
+ and still somewhat work.)
+
+2023-11-15 Tom Tromey <tromey@adacore.com>
+
+ Minor cleanups in ada-nested.exp
+ This changes ada-nested.exp to fix a test name (the test expects three
+ variables but is named "two"), and to iterate over all the variables
+ that are found. It also adds a workaround to a problem Tom de Vries
+ found with an older version of GNAT -- it emits a duplicate "x".
+
+2023-11-15 Sam James <sam@gentoo.org>
+
+ Finalized intl-update patches (trois)
+ Doing this on behalf of Arsen as obvious. Hopefully the last fixup.
+
+ * gdb: Regenerate.
+ * gnulib: Regenerate.
+
+2023-11-15 Sam James <sam@gentoo.org>
+
+ Finalized intl-update patches (deux)
+ Doing this on behalf of Arsen as obvious.
+
+ * gdb: Regenerate.
+ * gdbserver: Regenerate.
+ * gprofng: Regenerate.
+
+2023-11-15 YunQiang Su <yunqiang.su@cipunited.com>
+
+ GAS/MIPS: add "--defsym r6=" for default when it's r6
+ * testsuite/gas/mips/mips.exp (mips_arch_create): Add "--defsym r6=" to as_flags for r6 targets.
+
+2023-11-15 Arsen Arsenovi? <arsen@aarsen.me>
+
+ Finalized intl-update patches
+ * intl: Remove directory. Replaced with out-of-tree GNU gettext.
+ * .gitignore: Add '/gettext*'.
+ * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing.
+ * configure: Regenerate.
+ * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext.
+ * Makefile.in: Regenerate.
+ * src-release.sh: Remove references to the intl/ directory.
+
+2023-11-15 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Fix Irix gas testcases about pdr section
+ * testsuite/gas/elf/elf.exp (section2): Add -mpdr option to assembler command line for mips-irix targets.
+ * testsuite/gas/mips/elf-rel26.d: Add -mpdr command line option.
+ * testsuite/gas/mips/mips16-e.d: Likewise.
+ * testsuite/gas/mips/mips16-f.d: Likewise.
+ * testsuite/gas/mips/mips16-hilo-match.d: Likewise.
+ * testsuite/gas/mips/mips16-e-irix.d: Likewise.
+ * testsuite/gas/mips/call-nonpic-1.d: Adjust regexp to allow for mips-irix targets.
+ * testsuite/gas/mips/irix-no-pdr.d: New test file.
+ * testsuite/gas/mips/mips.exp: Run new test for mips-irix targets.
+
+2023-11-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Remove path name from test case
+ 'runtest' complains about a path in a test name, from the new test
+ case py-missing-debug.exp.
+
+ This patch fixes the problem by providing an explicit test name to
+ gdb_test. I chose something very basic because the block in question
+ is already wrapped in with_test_prefix.
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Remove some redundant "break"s
+ I found some "break" statements that follow "return" or a call to a
+ noreturn function. These aren't needed, and the compiler would warn
+ if they were. So, this patch removes them.
+
+ Tested by rebuilding.
+
+2023-11-14 Tom Tromey <tom@tromey.com>
+
+ Filter invalid encodings from Linux thread names
+ On Linux, a thread can only be 16 bytes (including the trailing \0).
+ A user sent in a test case where this causes a truncated UTF-8
+ sequence, causing gdbserver to create invalid XML.
+
+ I went back and forth about different ways to solve this, and in the
+ end decided to fix it in gdbserver, with the reason being that it
+ seems important to generate correct XML for the <thread> response.
+
+ I am not totally sure whether the call to setlocale could have
+ unplanned consequences. This is needed, though, for nl_langinfo to
+ return the correct result.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Update gdb.Symbol.is_variable documentation
+ Kévin found a bug in an earlier version of this series that was based
+ on a misconception I had about Symbol.is_variable. This patch fixes
+ the documentation to explain the method a bit better.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Handle the static link in FrameDecorator
+ A co-worker requested that the DAP scope for a nested function's frame
+ also show the variables from outer frames. DAP doesn't directly
+ support this notion, so this patch arranges to put these variables
+ into the inner frames "Locals" scope.
+
+ I chose to do this only for DAP. For CLI and MI, gdb currently does
+ not do this, so this preserves the behavior.
+
+ Note that an earlier patch (see commit 4a1311ba) removed some code
+ that seemed to do something similar. However, that code did not
+ actually work.
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Fix a bug in DAP scopes code
+ While working on static links, I noticed that the DAP scopes code does
+ not handle the scenario where a frame decorator returns None. This
+ situation should be handled identically to a frame decorator returning
+ an empty iterator.
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.Frame.static_link method
+ This adds a new gdb.Frame.static_link method to the gdb Python layer.
+ This can be used to find the static link frame for a given frame.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-11-14 Tom Tromey <tromey@adacore.com>
+
+ Move follow_static_link to frame.c
+ This moves the follow_static_link function to frame.c and exports it
+ for use elsewhere. The API is changed slightly to make it more
+ generically useful.
+
+ Add block::function_block
+ This adds the method block::function_block, to easily access a block's
+ enclosing function block.
+
+ Add two convenience methods to block
+ This adds a couple of convenience methods, block::is_static_block and
+ block::is_global_block.
+
+2023-11-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/MAINTAINERS: add Guinevere Larsen as record-full maintainer
+ Change-Id: I67d8361560ce0fa553b2983184c9d18df8dbeb4a
+
+ gdb/MAINTAINERS: add Luis Machado as global maintainer
+ Change-Id: I211d64393f5c0da3c9ce1fcf5486504d34ed38f4
+
+ gdb/MAINTAINERS: add John Baldwin as global maintainer
+ Change-Id: Ic9164fd19c3da1381302a17176e8f0f814e9ac6c
+
+2023-11-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: normalize whitespaces in MAINTAINERS
+ Replace some spaces with tabs.
+
+ Change-Id: I89bbabd6610219649e7e99cd0dd7b0ed66d69b09
+
+2023-11-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Factor out tui_noscroll_window et al
+ I noticed that tui_locator_window has an empty do_scroll_vertical and
+ do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't
+ have:
+ ...
+ bool can_scroll () const override
+ {
+ return false;
+ }
+ ...
+
+ I suspect that it probably doesn't matter, but regardless it's good to have
+ the same implementations of basic properties in all windows.
+
+ Ensure this by adding a class tui_noscroll_window, that has:
+ - an empty do_scroll_vertical and do_scroll_horizontal, and
+ - a can_scroll returning false
+ which both tui_locator_window and tui_cmd_window inherit.
+
+ Make all methods final to ensure no accidental overrides are left in the
+ inheriting classes.
+
+ Likewise add new classes representing basic window properties:
+ - tui_nofocus_window,
+ - tui_oneline_window,
+ - tui_nobox_window,
+ - tui_norefresh_window, and
+ - tui_always_visible_window.
+
+ The changes are only a refactoring, apart from adding the "final", which does
+ limit the range of behaviours for subclasses.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb: refactor make-target-delegates.py's ARGTYPES
+ Refactor the ARGTYPES regular expression in make-target-delegates.py
+ to eliminate '.*' for better control on what is matched. Also,
+ simplify the "E" match group, for which the optional SYMBOL becomes
+ redundant because that case can be matched by the "T" group.
+
+ After applying this patch, running './make-target-delegates.py' does not
+ change anything in 'target-delegates.c'.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb: regenerate target-delegates.c
+ I ran './make-target-delegates.py' and there is one minor difference,
+ where an older style declaration is converted to a newer
+ initialization style. Add this change.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-11-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/stepi-over-clone.exp regexp
+ I ran into the following FAIL:
+ ...
+ (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
+ continue^M
+ Continuing.^M
+ ^M
+ Catchpoint 2 (call to syscall clone), clone () at \
+ ../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M
+ warning: 78 ../sysdeps/unix/sysv/linux/x86_64/clone.S: \
+ No such file or directory^M
+ (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
+ ...
+
+ All but one regexps in the .exp file use "clone\[23\]?" with "?" to
+ also accept "clone", except the failing case. This commit fixes that
+ case to also use "?".
+
+ Furthermore, there are FAILs like this:
+ ...
+ (gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \
+ non-stop=on: displaced=off: i=0: continue
+ stepi^M
+ [New Thread 0x7ffff7ff8700 (LWP 15301)]^M
+ Hello from the first thread.^M
+ 78 in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M
+ (gdb) XXX: Consume the initial command
+ XXX: Consume new thread line
+ XXX: Consume first worker thread message
+ FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \
+ displaced=off: i=0: stepi
+ ...
+ because this output is expected instead:
+ ...
+ Hello from the first thread.^M
+ 0x00000000004212cd in clone3 ()^M
+ ...
+
+ The root cause for the difference is the presence of .debug_line info for
+ clone.
+
+ Fix this by updating the relevant regexps.
+
+ Tested on x86_64-linux, specifically:
+ - openSUSE Leap 15.4 (where the FAILs where observed), and
+ - openSUSE Tumbleweed (where the FAILs where not observed).
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+ Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c
+
+2023-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: implement missing debug handler hook for Python
+ This commit builds on the previous commit, and implements the
+ extension_language_ops::handle_missing_debuginfo function for Python.
+ This hook will give user supplied Python code a chance to help find
+ missing debug information.
+
+ The implementation of the new hook is pretty minimal within GDB's C++
+ code; most of the work is out-sourced to a Python implementation which
+ is modelled heavily on how GDB's Python frame unwinders are
+ implemented.
+
+ The following new commands are added as commands implemented in
+ Python, this is similar to how the Python unwinder commands are
+ implemented:
+
+ info missing-debug-handlers
+ enable missing-debug-handler LOCUS HANDLER
+ disable missing-debug-handler LOCUS HANDLER
+
+ To make use of this extension hook a user will create missing debug
+ information handler objects, and registers these handlers with GDB.
+ When GDB encounters an objfile that is missing debug information, 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_debug
+
+ class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
+ def __init__(self):
+ super().__init__("my_first_handler")
+
+ def __call__(self, objfile):
+ # This handler does nothing useful.
+ return None
+
+ gdb.missing_debug.register_handler(None, MyFirstHandler())
+
+ Returning None from the __call__ method tells GDB that this handler
+ was unable to find the missing debug information, and GDB should ask
+ any other registered handlers.
+
+ By extending the __call__ method it is possible for the Python
+ extension to locate the debug information for objfile and return a
+ value that tells GDB how to use the information that has been located.
+
+ 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 debug information
+ for the objfile still couldn't be found. GDB will not call
+ any other handlers, and will continue without the debug
+ information for objfile.
+
+ - True: The handler has installed the debug information into a
+ location where GDB would normally expect to find it. GDB
+ should look again for the debug information.
+
+ - A string: The handler can return a filename, which is the file
+ containing the missing debug information. GDB will load
+ this file.
+
+ When a handler returns True, GDB will look again for the debug
+ information, but only using the standard built-in build-id and
+ .gnu_debuglink based lookup strategies. It is not possible for an
+ extension to trigger another debuginfod lookup; the assumption is that
+ the debuginfod server is remote, and out of the control of extensions
+ running within GDB.
+
+ 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 objfile, at which point GDB continues.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add an extension language hook for missing debug info
+ This commit adds a new extension_language_ops hook which allows an
+ extension to handle the case where GDB can't find a separate debug
+ information file for a particular objfile.
+
+ This commit doesn't actually implement the hook for any of GDB's
+ extension languages, the next commit will do that. This commit just
+ adds support for the hook to extension-priv.h and extension.[ch], and
+ then reworks symfile-debug.c to call the hook.
+
+ Right now the hook will always return its default value, which means
+ GDB should do nothing different. As such, there should be no user
+ visible changes after this commit.
+
+ I'll give a brief description of what the hook does here so that we
+ can understand the changes in symfile-debug.c. The next commit adds a
+ Python implementation for this new hook, and gives a fuller
+ description of the new functionality.
+
+ Currently, when looking for separate debug information GDB tries three
+ things, in this order:
+
+ 1. Use the build-id to find the required debug information,
+
+ 2. Check for .gnu_debuglink section and use that to look up the
+ required debug information,
+
+ 3. Check with debuginfod to see if it can supply the required
+ information.
+
+ The new extension_language_ops::handle_missing_debuginfo hook is
+ called if all three steps fail to find any debug information. The
+ hook has three possible return values:
+
+ a. Nothing, no debug information is found, GDB continues without the
+ debug information for this objfile. This matches the current
+ behaviour of GDB, and is the default if nothing is implementing this
+ new hook,
+
+ b. Install debug information into a location that step #1 or #2
+ above would normally check, and then request that GDB repeats steps
+ #1 and #2 in the hope that GDB will now find the debug information.
+ If the debug information is still not found then GDB carries on
+ without the debug information. If the debug information is found
+ the GDB loads it and carries on,
+
+ c. Return a filename for a file containing the required debug
+ information. GDB loads the contents of this file and carries on.
+
+ The changes in this commit mostly involve placing the core of
+ objfile::find_and_add_separate_symbol_file into a loop which allows
+ for steps #1 and #2 to be repeated.
+
+ We take care to ensure that debuginfod is only queried once, the first
+ time through. The assumption is that no extension is going to be able
+ to control the replies from debuginfod, so there's no point making a
+ second request -- and as these requests go over the network, they
+ could potentially be slow.
+
+ The warnings that find_and_add_separate_symbol_file collects are
+ displayed only once assuming that no debug information is found. If
+ debug information is found, even after the extension has operated,
+ then the warnings are not shown; remember, these are warnings from GDB
+ about failure to find any suitable debug information, so it makes
+ sense to hide these if debug information is found.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: refactor objfile::find_and_add_separate_symbol_file
+ This is purely a refactoring commit.
+
+ This commit splits objfile::find_and_add_separate_symbol_file into
+ some separate helper functions. My hope is that the steps for looking
+ up separate debug information are now clearer.
+
+ In a later commit I'm going to extend
+ objfile::find_and_add_separate_symbol_file, with some additional
+ logic, so starting with a simpler function will make the following
+ changes easier.
+
+ When reading objfile::find_and_add_separate_symbol_file after this
+ commit, you might be tempted to think that removing the `has_dwarf`
+ local variable would be a good additional cleanup. After the next
+ commit though it makes more sense to retain this local, so I've left
+ this in place for now.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: merge debug symbol file lookup code from coffread & elfread paths
+ This commit merges the code that looks for and loads the separate
+ debug symbol files from coffread.c and elfread.c. The factored out
+ code is moved into a new objfile::find_and_add_separate_symbol_file()
+ method.
+
+ For the elfread.c path there should be no user visible changes after
+ this commit.
+
+ For the coffread.c path GDB will now attempt to perform a debuginfod
+ lookup for the missing debug information, assuming that GDB can find a
+ build-id in the COFF file.
+
+ I don't know if COFF files can include a build-id, but I the existing
+ coffread.c code already includes a call to
+ find_separate_debug_file_by_build-id, so I know that it is at least OK
+ for GDB to ask a COFF file for a build-id. If the COFF file doesn't
+ include a build-id then the debuginfod lookup code will not trigger
+ and the new code is harmless.
+
+ If the COFF file does include a build-id, then we're going to end up
+ asking debuginfod for the debug file. As build-ids should be unique,
+ this should be harmless, even if debuginfod doesn't contain any
+ suitable debug data, it just costs us one debuginfod lookup, so I'm
+ not too worried about this for now.
+
+ As with the previous commit, I've done some minimal testing using the
+ mingw toolchain on a Linux machine, GDB seems to still access the
+ split debug information just fine.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/coffread: bring separate debug file logic into line with elfread.c
+ In this commit:
+
+ commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07
+ Date: Fri Feb 1 19:39:04 2013 +0000
+
+ the logic for when we try to load a separate debug file in elfread.c
+ was extended. The new code checks that the objfile doesn't already
+ have a separate debug objfile linked to it, and that the objfile isn't
+ itself a separate debug objfile for some other objfile.
+
+ The coffread code wasn't extended at the same time.
+
+ I don't know if it's possible for the coffread code to get into the
+ same state where these checks are needed, but I don't see why having
+ these checks would be a problem. In a later commit I plan to merge
+ this part of the elfread and coffread code, so bringing these two
+ pieces of code into line first makes that job easier.
+
+ I've tested this with a simple test binary compiled with the mingw
+ toolchain on a Linux host. After compiling the binary and splitting
+ out the debug info GDB still finds and loads the separate debug info.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-14 Nick Clifton <nickc@redhat.com>
+
+ Fix another linker command line option that was not being recognised in its long form.
+ PR 28910
+ * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised.
+
+ Improve objdump's handling of compressed sections.
+ PR 31062
+ * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option.
+ * NEWS: Mention the new feature.
+ * doc/binutils.texi: Document the new feature.
+ * testsuite/binutils-all/objdump.s: Update expected output.
+ * testsuite/binutils-all/objdump.exp: Add test of -Z -s.
+ * testsuite/binutils-all/objdump.Zs: New file.
+ * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions. Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise.
+
+2023-11-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Don't include border_width in left_margin
+ Currently left_margin does not match its documentation:
+ ...
+ /* Return the size of the left margin space, this is the space used to
+ display things like breakpoint markers. */
+ int left_margin () const
+ { return box_width () + TUI_EXECINFO_SIZE + extra_margin (); }
+ ...
+
+ It is stated that the left margin is reserved to display things, but
+ the box_width is not used for that.
+
+ Fix this by dropping box_width () from the left_margin calculation.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Add tui_win_info::{box_width,box_size}
+ In tui_source_window::set_contents we have:
+ ...
+ /* Take hilite (window border) into account, when
+ calculating the number of lines. */
+ int nlines = height - 2;
+ ...
+
+ The '2' represents the total size of the window border (or box, in can_box
+ terms), in this case one line at the top and one line at the bottom.
+
+ Likewise, '1' is used to represent the width of the window border.
+
+ Introduce new functions:
+ - tui_win_info::box_width () and
+ - tui_win_info::box_size ()
+ that can be used instead instead of these hardcoded constants.
+
+ Implement these such that they return 0 when can_box () == false.
+
+ Tested patch completeness by making all windows unboxed:
+ ...
+ @@ -85,7 +85,7 @@ struct tui_win_info
+ /* Return true if this window can be boxed. */
+ virtual bool can_box () const
+ {
+ - return true;
+ + return false;
+ }
+
+ int box_width () const
+ ...
+ and test-driving TUI.
+
+ This required eliminating an assert in
+ tui_source_window_base::show_source_content, I've included that part as well.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_window
+ Currently the call to prefresh in tui_source_window_base::refresh_window looks
+ like:
+ ...
+ prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin,
+ y + m_content.size (), x + left_margin + view_width - 1);
+ ...
+
+ This is hard to parse. It's not obvious what the arguments mean, and there's
+ repetition in the argument calculation.
+
+ Fix this by rewriting the call as follows:
+ - use sminrow, smincol, smaxrow and smaxcol variables for the last
+ 4 arguments, and
+ - calculate the smaxrow and smaxcol variables based on the sminrow and
+ smincol variables.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-13 Carl Love <cel@linux.ibm.com>
+
+ Fix the gdb.ada/inline-section-gc.exp test
+ The original intention of the test appears to be checking to make sure
+ setting a breakpoint in an inlined function didn't set multiple
+ breakpoints where one of them was at address 0.
+
+ The gdb.ada/inline-section-gc.exp test may pass or fail depending on the
+ version of gnat. Per the discussion on IRC, the ada inlining appears to
+ have some target dependencies. In this test there are two functions,
+ callee and caller. Function calee is inlined into caller. The test sets
+ a breakpoint in function callee. The reported location where the
+ breakpoint is set may be at the requested location in callee or the
+ location in caller after callee has been inlined. The test needs to
+ accept either location as correct provided the breakpoint address is not
+ zero.
+
+ This patch checks to see if the reported breakpoint is in function callee
+ or function caller and fails if the breakpoint address is 0x0. The line
+ number where the breakpoint is set will match the requested line if the
+ breakpoint location is reported is callee.adb. If the breakpoint is
+ reported in caller.adb, the line number in caller is the breakpoint
+ location in callee where it is inlined into caller.
+
+ This patch fixes the single regression failure for the test on PowerPC.
+ It does not introduce any failures on X86-64.
+
+2023-11-13 Nick Clifton <nickc@redhat.com>
+
+ GNU-ld: ARM: Issues when trying to set target output architecture
+ PR 28910
+ * lexsup.c (ld_options): Ensure that the --format option is correctly recognised.
+
+2023-11-13 Mark Wielaard <mark@klomp.org>
+
+ Regenerate gas/config.in and ld/configure
+ commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*"
+ changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32
+ this new name sorts differently when regenerating gas/config.in
+
+ commit e922d1eaa "Add ability to change linker warning messages into
+ errors when reporting executable stacks and/or executable segments."
+ Introduced two new help strings for --enable-error-execstack and
+ --enable-error-rwx-segments in configure.ac which weren't included
+ in ld/configure when regenerated.
+
+ * gas/config.in: Regenerate.
+ * ld/configure: Likewise.
+
+2023-11-13 Nick Clifton <nickc@redhat.com>
+
+ Add documentation for the MIPS assembler's -march=from-abi command line option
+
+2023-11-13 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Fix binutils-all tests for r6 triples
+
+2023-11-13 Chung-Ju Wu <jasonwucj@gmail.com>
+
+ Fix redundant space typo in linker documentation.
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Cancel execution command on thread exit, when stepping, nexting, etc.
+ If your target has no support for TARGET_WAITKIND_NO_RESUMED events
+ (and no way to support them, such as the yet-unsubmitted AMDGPU
+ target), and you step over thread exit with scheduler-locking on, this
+ is what you get:
+
+ (gdb) n
+ [Thread ... exited]
+ *hang*
+
+ Getting back the prompt by typing Ctrl-C may not even work, since no
+ inferior thread is running to receive the SIGINT. Even if it works,
+ it seems unnecessarily harsh. If you started an execution command for
+ which there's a clear thread of interest (step, next, until, etc.),
+ and that thread disappears, then I think it's more user friendly if
+ GDB just detects the situation and aborts the command, giving back the
+ prompt.
+
+ That is what this commit implements. It does this by explicitly
+ requesting the target to report thread exit events whenever the main
+ resumed thread has a thread_fsm. Note that unlike stepping over a
+ breakpoint, we don't need to enable clone events in this case.
+
+ With this patch, we get:
+
+ (gdb) n
+ [Thread 0x7ffff7d89700 (LWP 3961883) exited]
+ Command aborted, thread exited.
+ (gdb)
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Document remote clone events, and QThreadOptions packet
+ This commit documents in both manual and NEWS:
+
+ - the new remote clone event stop reply,
+ - the new QThreadOptions packet and its current defined options,
+ - the associated "set/show remote thread-events-packet" command,
+ - and the associated QThreadOptions qSupported feature.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Change-Id: Ic1c8de1fefba95729bbd242969284265de42427e
+
+2023-11-13 Simon Marchi <simon.marchi@efficios.com>
+ Pedro Alves <pedro@palves.net>
+
+ Testcases for stepping over thread exit syscall (PR gdb/27338)
+ Add new gdb.threads/step-over-thread-exit.exp and
+ gdb.threads/step-over-thread-exit-while-stop-all-threads.exp
+ testcases, exercising stepping over thread exit syscall. These make
+ use of lib/my-syscalls.S to define the exit syscall.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+ Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro
+ Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S
+ behind a SYSCALL macro so that it's easy to add new syscalls without
+ duplicating code.
+
+ Note that the way the macro is implemented, it only works correctly
+ for syscalls with up to 3 arguments, and, if the syscall doesn't
+ return (the macro doesn't bother to save/restore callee-saved
+ registers).
+
+ The following patch will want to use the macro to define a wrapper for
+ the "exit" syscall, so the limitations continue to be sufficient.
+
+ Change-Id: I8acf1463b11a084d6b4579aaffb49b5d0dea3bba
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Report thread exit event for leader if reporting thread exit events
+ If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the
+ thread disappears from the thread list, GDB expects to shortly see a
+ thread exit event for it. See e.g., here, in
+ remote_target::update_thread_list():
+
+ /* Do not remove the thread if we've requested to be
+ notified of its exit. For example, the thread may be
+ displaced stepping, infrun will need to handle the
+ exit event, and displaced stepping info is recorded
+ in the thread object. If we deleted the thread now,
+ we'd lose that info. */
+ if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0)
+ continue;
+
+ There's one scenario that is deleting a thread from the
+ remote/gdbserver thread list without ever reporting a corresponding
+ thread exit event though -- check_zombie_leaders. This can lead to
+ GDB getting confused. For example, with a following patch that
+ enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see
+ this regression:
+
+ $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp"
+ ...
+ Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ...
+ FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)
+ ... some more cascading FAILs ...
+
+ gdb.log shows:
+
+ (gdb) continue
+ Continuing.
+ FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout)
+
+ A passing run would have resulted in:
+
+ (gdb) continue
+ Continuing.
+ No unwaited-for children left.
+ (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
+
+ note how the leader thread is not listed in the remote-reported XML
+ thread list below:
+
+ (gdb) set debug remote 1
+ (gdb) set debug infrun 1
+ (gdb) info threads
+ Id Target Id Frame
+ * 1 Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65
+ 3 Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39
+ (gdb) c
+ Continuing.
+ [infrun] clear_proceed_status_thread: 1163850.1163850.0
+ ...
+ [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f
+ [remote] Sending packet: $QPassSignals:#f3
+ [remote] Packet received: OK
+ [remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3
+ [remote] Packet received: OK
+ ...
+ [infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3]
+ ...
+ [infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0
+ [remote] Sending packet: $vCont;c:p11c24a.11c24a#98
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+ [infrun] fetch_inferior_event: exit
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] random_pending_event_thread: None found.
+ [remote] wait: enter
+ [remote] Packet received: N
+ [remote] wait: exit
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: -1.0.0 [process -1],
+ [infrun] print_target_wait_results: status->kind = NO_RESUMED
+ [infrun] handle_inferior_event: status->kind = NO_RESUMED
+ [remote] Sending packet: $Hgp0.0#ad
+ [remote] Packet received: OK
+ [remote] Sending packet: $qXfer:threads:read::0,1000#92
+ [remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n
+ [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
+ ...
+
+ ... however, infrun decided there was a resumed thread still, so
+ ignored the TARGET_WAITKIND_NO_RESUMED event. Debugging GDB, we see
+ that the "found resumed" thread that GDB finds, is the leader thread.
+ Even though that thread is not on the remote-reported thread list, it
+ is still on the GDB thread list, due to the special case in remote.c
+ mentioned above.
+
+ This commit addresses the issue by fixing GDBserver to report a thread
+ exit event for the zombie leader too, i.e., making GDBserver respect
+ the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit"
+ invariant. To do that, it takes a bit more code than one would
+ imagine off hand, due to the fact that we currently always report LWP
+ exit pending events as TARGET_WAITKIND_EXITED, and then decide whether
+ to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting
+ the event to GDBserver core. For the zombie leader scenario
+ described, we need to record early on that we want to report a
+ THREAD_EXITED event, and then make sure that decision isn't lost along
+ the way to reporting the event to GDBserver core.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I1e68fccdbc9534434dee07163d3fd19744c8403b
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Don't resume new threads if scheduler-locking is in effect
+ If scheduler-locking is in effect, e.g., with "set scheduler-locking
+ on", and you step over a function that spawns a new thread, the new
+ thread is allowed to run free, at least until some event is hit, at
+ which point, whether the new thread is re-resumed depends on a number
+ of seemingly random factors. E.g., if the target is all-stop, and the
+ parent thread hits a breakpoint, and GDB decides the breakpoint isn't
+ interesting to report to the user, then the parent thread is resumed,
+ but the new thread is left stopped.
+
+ I think that letting the new threads run with scheduler-locking
+ enabled is a defect. This commit fixes that, making use of the new
+ clone events on Linux, and of target_thread_events() on targets where
+ new threads have no connection to the thread that spawned them.
+
+ Testcase and documentation changes included.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Queue no-resumed event after thread exit
+ Normally, if the last resumed thread on the target exits, the server
+ sends a no-resumed event to GDB. If however, GDB enables the
+ GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the
+ server sends a thread exit event for that thread instead.
+
+ In all-stop RSP mode, since events can only be forwarded to GDB one at
+ a time, and the whole target stops whenever an event is reported, GDB
+ resumes the target again after getting a THREAD_EXITED event, and then
+ the server finally reports back a no-resumed event if/when
+ appropriate.
+
+ For non-stop RSP though, events are asynchronous, and if the server
+ sends a thread-exit event for the last resumed thread, the no-resumed
+ event is never sent. This patch makes sure that in non-stop mode, the
+ server queues a no-resumed event after the thread-exit event if it was
+ the last resumed thread that exited.
+
+ Without this, we'd see failures in step-over-thread-exit testcases
+ added later in the series, like so:
+
+ continue
+ Continuing.
+ - No unwaited-for children left.
+ - (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits
+ + FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout)
+
+ (and other similar ones)
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I927d78b30f88236dbd5634b051a716f72420e7c7
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ stop_all_threads: (re-)enable async before waiting for stops
+ Running the
+ gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcase
+ added later in the series against gdbserver, after the
+ TARGET_WAITKIND_NO_RESUMED fix from the following patch, would run
+ into an infinite loop in stop_all_threads, leading to a timeout:
+
+ FAIL: gdb.threads/step-over-thread-exit-while-stop-all-threads.exp: displaced-stepping=off: target-non-stop=on: iter 0: continue (timeout)
+
+ The is really a latent bug, and it is about the fact that
+ stop_all_threads stops listening to events from a target as soon as it
+ sees a TARGET_WAITKIND_NO_RESUMED, ignoring that
+ TARGET_WAITKIND_NO_RESUMED may be delayed. handle_no_resumed knows
+ how to handle delayed no-resumed events, but stop_all_threads was
+ never taught to.
+
+ In more detail, here's what happens with that testcase:
+
+ #1 - Multiple threads report breakpoint hits to gdb.
+
+ #2 - gdb picks one events, and it's for thread 1. All other stops are
+ left pending. thread 1 needs to move past a breakpoint, so gdb
+ stops all threads to start an inline step over for thread 1.
+ While stopping threads, some of the threads that were still
+ running report events that are also left pending.
+
+ #2 - gdb steps thread 1
+
+ #3 - Thread 1 exits while stepping (it steps over an exit syscall),
+ gdbserver reports thread exit for thread 1
+
+ #4 - Thread 1 was the last resumed thread, so gdbserver also reports
+ no-resumed:
+
+ [remote] Notification received: Stop:w0;p3445d0.3445d3
+ [remote] Sending packet: $vStopped#55
+ [remote] Packet received: N
+ [remote] Sending packet: $vStopped#55
+ [remote] Packet received: OK
+
+ #5 - gdb processes the thread exit for thread 1, finishes the step
+ over and restarts threads.
+
+ #6 - gdb picks the next event to process out of one of the resumed
+ threads with pending events:
+
+ [infrun] random_resumed_with_pending_wait_status: Found 32 events, selecting #11
+
+ #7 - This is again a breakpoint hit and the breakpoint needs to be
+ stepped over too, so gdb starts a step-over dance again.
+
+ #8 - We reach stop_all_threads, which finds that some threads need to
+ be stopped.
+
+ #9 - wait_one finally consumes the no-resumed event queue by #4.
+ Seeing this, wait_one disable target async, to stop listening for
+ events out of the remote target.
+
+ #10 - We still haven't seen all the stops expected, so
+ stop_all_threads tries another iteration.
+
+ #11 - Because the remote target is no longer async, and there are no
+ other targets, wait_one return no-resumed immediately without
+ polling the remote target.
+
+ #12 - We still haven't seen all the stops expected, so
+ stop_all_threads tries another iteration. goto #11, looping
+ forever.
+
+ Fix this by explicitly enabling/re-enabling target async on targets
+ that can async, before waiting for stops.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: Ie3ffb0df89635585a6631aa842689cecc989e33f
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+ Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: clear step over information on thread exit (PR gdb/27338)
+ GDB doesn't handle correctly the case where a thread steps over a
+ breakpoint (using either in-line or displaced stepping), and the
+ executed instruction causes the thread to exit.
+
+ Using the test program included later in the series, this is what it
+ looks like with displaced-stepping, on x86-64 Linux, where we have two
+ displaced-step buffers:
+
+ $ ./gdb -q -nx --data-directory=data-directory build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit -ex "b my_exit_syscall" -ex r
+ Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
+ Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
+ Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+ [New Thread 0x7ffff7c5f640 (LWP 2915510)]
+ [Switching to Thread 0x7ffff7c5f640 (LWP 2915510)]
+
+ Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
+ 68 syscall
+ (gdb) c
+ Continuing.
+ [New Thread 0x7ffff7c5f640 (LWP 2915524)]
+ [Thread 0x7ffff7c5f640 (LWP 2915510) exited]
+ [Switching to Thread 0x7ffff7c5f640 (LWP 2915524)]
+
+ Thread 3 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
+ 68 syscall
+ (gdb) c
+ Continuing.
+ [New Thread 0x7ffff7c5f640 (LWP 2915616)]
+ [Thread 0x7ffff7c5f640 (LWP 2915524) exited]
+ [Switching to Thread 0x7ffff7c5f640 (LWP 2915616)]
+
+ Thread 4 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
+ 68 syscall
+ (gdb) c
+ Continuing.
+ ... hangs ...
+
+ The first two times we do "continue", we displaced-step the syscall
+ instruction that causes the thread to exit. When the thread exits,
+ the main thread, waiting on pthread_join, is unblocked. It spawns a
+ new thread, which hits the breakpoint on the syscall again. However,
+ infrun was never notified that the displaced-stepping threads are done
+ using the displaced-step buffer, so now both buffers are marked as
+ used. So when we do the third continue, there are no buffers
+ available to displaced-step the syscall, so the thread waits forever
+ for its turn.
+
+ When trying the same but with in-line step over (displaced-stepping
+ disabled):
+
+ $ ./gdb -q -nx --data-directory=data-directory \
+ build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit \
+ -ex "b my_exit_syscall" -ex "set displaced-stepping off" -ex r
+ Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit...
+ Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68.
+ Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+ [New Thread 0x7ffff7c5f640 (LWP 2928290)]
+ [Switching to Thread 0x7ffff7c5f640 (LWP 2928290)]
+
+ Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68
+ 68 syscall
+ (gdb) c
+ Continuing.
+ [Thread 0x7ffff7c5f640 (LWP 2928290) exited]
+ No unwaited-for children left.
+ (gdb) i th
+ Id Target Id Frame
+ 1 Thread 0x7ffff7c60740 (LWP 2928285) "step-over-threa" 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0
+
+ The current thread <Thread ID 2> has terminated. See `help thread'.
+ (gdb) thread 1
+ [Switching to thread 1 (Thread 0x7ffff7c60740 (LWP 2928285))]
+ #0 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0
+ (gdb) c
+ Continuing.
+ ^C^C
+ ... hangs ...
+
+ The "continue" causes an in-line step to occur, meaning the main
+ thread is stopped while we step the syscall. The stepped thread exits
+ when executing the syscall, the linux-nat target notices there are no
+ more resumed threads to be waited for, so returns
+ TARGET_WAITKIND_NO_RESUMED, which causes the prompt to return. But
+ infrun never clears the in-line step over info. So if we try
+ continuing the main thread, GDB doesn't resume it, because it thinks
+ there's an in-line step in progress that we need to wait for to
+ finish, and we are stuck there.
+
+ To fix this, infrun needs to be informed when a thread doing a
+ displaced or in-line step over exits. We can do that with the new
+ target_set_thread_options mechanism which is optimal for only enabling
+ exit events of the thread that needs it; or, if that is not supported,
+ by using target_thread_events, which enables thread exit events for
+ all threads. This is done by this commit.
+
+ This patch then modifies handle_inferior_event in infrun.c to clean up
+ any step-over the exiting thread might have been doing at the time of
+ the exit. The cases to consider are:
+
+ - the exiting thread was doing an in-line step-over with an all-stop
+ target
+ - the exiting thread was doing an in-line step-over with a non-stop
+ target
+ - the exiting thread was doing a displaced step-over with a non-stop
+ target
+
+ The displaced-stepping buffer implementation in displaced-stepping.c
+ is modified to account for the fact that it's possible that we
+ "finish" a displaced step after a thread exit event. The buffer that
+ the exiting thread was using is marked as available again and the
+ original instructions under the scratch pad are restored. However, it
+ skips applying the fixup, which wouldn't make sense since the thread
+ does not exist anymore.
+
+ Another case that needs handling is if a displaced-stepping thread
+ exits, and the event is reported while we are in stop_all_threads. We
+ should call displaced_step_finish in the handle_one function, in that
+ case. It was already called in other code paths, just not the "thread
+ exited" path.
+
+ This commit doesn't make infrun ask the target to report the
+ TARGET_WAITKIND_THREAD_EXITED events yet, that'll be done later in the
+ series.
+
+ Note that "stop_print_frame = false;" line is moved to normal_stop,
+ because TARGET_WAITKIND_THREAD_EXITED can also end up with the event
+ transmorphed into TARGET_WAITKIND_NO_RESUMED. Moving it to
+ normal_stop keeps it centralized.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I745c6955d7ef90beb83bcf0ff1d1ac8b9b6285a5
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Implement GDB_THREAD_OPTION_EXIT support for native Linux
+ This implements support for the new GDB_THREAD_OPTION_EXIT thread
+ option for native Linux.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: Ia69fc0b9b96f9af7de7cefc1ddb1fba9bbb0bb90
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Implement GDB_THREAD_OPTION_EXIT support for Linux GDBserver
+ This implements support for the new GDB_THREAD_OPTION_EXIT thread
+ option for Linux GDBserver.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Introduce GDB_THREAD_OPTION_EXIT thread option, fix step-over-thread-exit
+ When stepping over a breakpoint with displaced stepping, GDB needs to
+ be informed if the stepped thread exits, otherwise the displaced
+ stepping buffer that was allocated to that thread leaks, and this can
+ result in deadlock, with other threads waiting for their turn to
+ displaced step, but their turn never comes.
+
+ Similarly, when stepping over a breakpoint in line, GDB also needs to
+ be informed if the stepped thread exits, so that is can clear the step
+ over state and re-resume threads.
+
+ This commit makes it possible for GDB to ask the target to report
+ thread exit events for a given thread, using the new "thread options"
+ mechanism introduced by a previous patch.
+
+ This only adds the core bits. Following patches in the series will
+ teach the Linux backends (native & gdbserver) to handle the
+ GDB_THREAD_OPTION_EXIT option, and then a later patch will make use of
+ these thread exit events to clean up displaced stepping and inline
+ stepping state properly.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to core
+ Currently, infrun assumes that when TARGET_WAITKIND_THREAD_EXITED is
+ reported, the corresponding GDB thread has already been removed from
+ the GDB thread list.
+
+ Later in the series, that will no longer work, as infrun will need to
+ refer to the thread's thread_info when it processes
+ TARGET_WAITKIND_THREAD_EXITED.
+
+ As preparation, this patch makes deleting the GDB thread
+ responsibility of infrun, instead of the target.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I013d87f61ffc9aaca49f0d6ce2a43e3ea69274de
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE
+ gdbserver's linux_process_target::wait loops if:
+
+ - called in sync mode, and,
+ - wait_1 returns TARGET_WAITKIND_IGNORE, _and_,
+ - wait_1 also returns null_ptid.
+
+ The null_ptid check fails however when this path is taken:
+
+ ptid_t
+ linux_process_target::filter_exit_event (lwp_info *event_child,
+ target_waitstatus *ourstatus)
+ {
+ ...
+ if (!is_leader (thread))
+ {
+ if (report_exit_events_for (thread))
+ ourstatus->set_thread_exited (0);
+ else
+ ourstatus->set_ignore (); <<<<<<<
+
+ delete_lwp (event_child);
+ }
+ return ptid;
+ }
+
+ This makes linux_process_target::wait return TARGET_WAITKIND_IGNORE in
+ sync mode, which is unexpected by the core and fails an assertion.
+
+ This commit fixes it by just making linux_process_target::wait loop if
+ it got a TARGET_WAITKIND_IGNORE, irrespective of event_ptid.
+
+ Change-Id: I39776908a6c75cbd68aa04139ffcf7be334868cf
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ all-stop/synchronous RSP support thread-exit events
+ Currently, GDB does not understand the THREAD_EXITED stop reply in
+ remote all-stop mode. There's no good reason for this, it just
+ happened that THREAD_EXITED was only ever reported in non-stop mode so
+ far. This patch teaches GDB to parse that event in all-stop RSP too.
+ There is no need to add a qSupported feature for this, because the
+ server won't send a THREAD_EXITED event unless GDB explicitly asks for
+ it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT
+ QThreadOptions option added in the next patch.
+
+ Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Remove gdb/19675 kfails (displaced stepping + clone)
+ Now that gdb/19675 is fixed for both native and gdbserver GNU/Linux,
+ remove the gdb/19675 kfails.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I95c1c38ca370100675d303cd3c8995860bef465d
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Hide and don't detach pending clone children
+ This commit extends the logic added by these two commits from a while
+ ago:
+
+ #1 7b961964f866 (gdbserver: hide fork child threads from GDB),
+ #2 df5ad102009c (gdb, gdbserver: detach fork child when detaching from fork parent)
+
+ ... to handle thread clone events, which are very similar to (v)fork
+ events.
+
+ For #1, we want to hide clone children as well, so just update the
+ comments.
+
+ For #2, unlike (v)fork children, pending clone children aren't full
+ processes, they're just threads, so don't detach them in
+ handle_detach. linux-low.cc will take care of detaching them along
+ with all other threads of the process, there's nothing special that
+ needs to be done.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I7f5901d07efda576a2522d03e183994e071b8ffc
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Thread options & clone events (Linux GDBserver)
+ This patch teaches the Linux GDBserver backend to report clone events
+ to GDB, when GDB has requested them with the GDB_THREAD_OPTION_CLONE
+ thread option, via the new QThreadOptions packet.
+
+ This shuffles code in linux_process_target::handle_extended_wait
+ around to a more logical order when we now have to handle and
+ potentially report all of fork/vfork/clone.
+
+ Raname lwp_info::fork_relative -> lwp_info::relative as the field is
+ no longer only about (v)fork.
+
+ With this, gdb.threads/stepi-over-clone.exp now cleanly passes against
+ GDBserver, so remove the native-target-only requirement from that
+ testcase.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I3a19bc98801ec31e5c6fdbe1ebe17df855142bb2
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Thread options & clone events (native Linux)
+ This commit teaches the native Linux target about the
+ GDB_THREAD_OPTION_CLONE thread option. It's actually simpler to just
+ continue reporting all clone events unconditionally to the core.
+ There's never any harm in reporting a clone event when the option is
+ disabled. All we need to do is to report support for the option,
+ otherwise GDB falls back to use target_thread_events().
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: If90316e2dcd0c61d0fefa0d463c046011698acf9
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Thread options & clone events (core + remote)
+ A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
+ event kind, and made the Linux target report clone events.
+
+ A following patch will teach Linux GDBserver to do the same thing.
+
+ However, for remote debugging, it wouldn't be ideal for GDBserver to
+ report every clone event to GDB, when GDB only cares about such events
+ in some specific situations. Reporting clone events all the time
+ would be potentially chatty. We don't enable thread create/exit
+ events all the time for the same reason. Instead we have the
+ QThreadEvents packet. QThreadEvents is target-wide, though.
+
+ This patch makes GDB instead explicitly request that the target
+ reports clone events or not, on a per-thread basis.
+
+ In order to be able to do that with GDBserver, we need a new remote
+ protocol feature. Since a following patch will want to enable thread
+ exit events on per-thread basis too, the packet introduced here is
+ more generic than just for clone events. It lets you enable/disable a
+ set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.
+
+ IOW, this commit introduces a new QThreadOptions packet, that lets you
+ specify a set of per-thread event options you want to enable. The
+ packet accepts a list of options/thread-id pairs, similarly to vCont,
+ processed left to right, with the options field being a number
+ interpreted as a bit mask of options. The only option defined in this
+ commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
+ to report clone events. Another patch later in the series will
+ introduce another option.
+
+ For example, this packet sets option "1" (clone events) on thread
+ p1000.2345:
+
+ QThreadOptions;1:p1000.2345
+
+ and this clears options for all threads of process 1000, and then sets
+ option "1" (clone events) on thread p1000.2345:
+
+ QThreadOptions;0:p1000.-1;1:p1000.2345
+
+ This clears options of all threads of all processes:
+
+ QThreadOptions;0
+
+ The target reports the set of supported options by including
+ "QThreadOptions=<supported options>" in its qSupported response.
+
+ infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
+ over a breakpoint.
+
+ Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
+ their parent's thread options. This is so that GDB can send e.g.,
+ "QThreadOptions;0;1:TID" without worrying about threads it doesn't
+ know about yet.
+
+ Documentation for this new remote protocol feature is included in a
+ documentation patch later in the series.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Avoid duplicate QThreadEvents packets
+ Similarly to QProgramSignals and QPassSignals, avoid sending duplicate
+ QThreadEvents packets.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: Iaf5babb0b64e1527ba4db31aac8674d82b17e8b4
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ Support clone events in the remote protocol
+ The previous patch taught GDB about a new
+ TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target
+ report clone events.
+
+ A following patch will teach Linux GDBserver to do the same thing.
+
+ But before we get there, we need to teach the remote protocol about
+ TARGET_WAITKIND_THREAD_CLONED. That's what this patch does. Clone is
+ very similar to vfork and fork, and the new stop reply is likewise
+ handled similarly. The stub reports "T05clone:...".
+
+ GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and
+ forward it to GDB in this patch, but no backend actually emits it yet.
+ That will be done in a following patch.
+
+ Documentation for this new remote protocol feature is included in a
+ documentation patch later in the series.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: If271f20320d864f074d8ac0d531cc1a323da847f
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+ Andrew Burgess <aburgess@redhat.com>
+
+ Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED
+ (A good chunk of the problem statement in the commit log below is
+ Andrew's, adjusted for a different solution, and for covering
+ displaced stepping too. The testcase is mostly Andrew's too.)
+
+ This commit addresses bugs gdb/19675 and gdb/27830, which are about
+ stepping over a breakpoint set at a clone syscall instruction, one is
+ about displaced stepping, and the other about in-line stepping.
+
+ Currently, when a new thread is created through a clone syscall, GDB
+ sets the new thread running. With 'continue' this makes sense
+ (assuming no schedlock):
+
+ - all-stop mode, user issues 'continue', all threads are set running,
+ a newly created thread should also be set running.
+
+ - non-stop mode, user issues 'continue', other pre-existing threads
+ are not affected, but as the new thread is (sort-of) a child of the
+ thread the user asked to run, it makes sense that the new threads
+ should be created in the running state.
+
+ Similarly, if we are stopped at the clone syscall, and there's no
+ software breakpoint at this address, then the current behaviour is
+ fine:
+
+ - all-stop mode, user issues 'stepi', stepping will be done in place
+ (as there's no breakpoint to step over). While stepping the thread
+ of interest all the other threads will be allowed to continue. A
+ newly created thread will be set running, and then stopped once the
+ thread of interest has completed its step.
+
+ - non-stop mode, user issues 'stepi', stepping will be done in place
+ (as there's no breakpoint to step over). Other threads might be
+ running or stopped, but as with the continue case above, the new
+ thread will be created running. The only possible issue here is
+ that the new thread will be left running after the initial thread
+ has completed its stepi. The user would need to manually select
+ the thread and interrupt it, this might not be what the user
+ expects. However, this is not something this commit tries to
+ change.
+
+ The problem then is what happens when we try to step over a clone
+ syscall if there is a breakpoint at the syscall address.
+
+ - For both all-stop and non-stop modes, with in-line stepping:
+
+ + user issues 'stepi',
+ + [non-stop mode only] GDB stops all threads. In all-stop mode all
+ threads are already stopped.
+ + GDB removes s/w breakpoint at syscall address,
+ + GDB single steps just the thread of interest, all other threads
+ are left stopped,
+ + New thread is created running,
+ + Initial thread completes its step,
+ + [non-stop mode only] GDB resumes all threads that it previously
+ stopped.
+
+ There are two problems in the in-line stepping scenario above:
+
+ 1. The new thread might pass through the same code that the initial
+ thread is in (i.e. the clone syscall code), in which case it will
+ fail to hit the breakpoint in clone as this was removed so the
+ first thread can single step,
+
+ 2. The new thread might trigger some other stop event before the
+ initial thread reports its step completion. If this happens we
+ end up triggering an assertion as GDB assumes that only the
+ thread being stepped should stop. The assert looks like this:
+
+ infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
+
+ - For both all-stop and non-stop modes, with displaced stepping:
+
+ + user issues 'stepi',
+ + GDB starts the displaced step, moves thread's PC to the
+ out-of-line scratch pad, maybe adjusts registers,
+ + GDB single steps the thread of interest, [non-stop mode only] all
+ other threads are left as they were, either running or stopped.
+ In all-stop, all other threads are left stopped.
+ + New thread is created running,
+ + Initial thread completes its step, GDB re-adjusts its PC,
+ restores/releases scratchpad,
+ + [non-stop mode only] GDB resumes the thread, now past its
+ breakpoint.
+ + [all-stop mode only] GDB resumes all threads.
+
+ There is one problem with the displaced stepping scenario above:
+
+ 3. When the parent thread completed its step, GDB adjusted its PC,
+ but did not adjust the child's PC, thus that new child thread
+ will continue execution in the scratch pad, invoking undefined
+ behavior. If you're lucky, you see a crash. If unlucky, the
+ inferior gets silently corrupted.
+
+ What is needed is for GDB to have more control over whether the new
+ thread is created running or not. Issue #1 above requires that the
+ new thread not be allowed to run until the breakpoint has been
+ reinserted. The only way to guarantee this is if the new thread is
+ held in a stopped state until the single step has completed. Issue #3
+ above requires that GDB is informed of when a thread clones itself,
+ and of what is the child's ptid, so that GDB can fixup both the parent
+ and the child.
+
+ When looking for solutions to this problem I considered how GDB
+ handles fork/vfork as these have some of the same issues. The main
+ difference between fork/vfork and clone is that the clone events are
+ not reported back to core GDB. Instead, the clone event is handled
+ automatically in the target code and the child thread is immediately
+ set running.
+
+ Note we have support for requesting thread creation events out of the
+ target (TARGET_WAITKIND_THREAD_CREATED). However, those are reported
+ for the new/child thread. That would be sufficient to address in-line
+ stepping (issue #1), but not for displaced-stepping (issue #3). To
+ handle displaced-stepping, we need an event that is reported to the
+ _parent_ of the clone, as the information about the displaced step is
+ associated with the clone parent. TARGET_WAITKIND_THREAD_CREATED
+ includes no indication of which thread is the parent that spawned the
+ new child. In fact, for some targets, like e.g., Windows, it would be
+ impossible to know which thread that was, as thread creation there
+ doesn't work by "cloning".
+
+ The solution implemented here is to model clone on fork/vfork, and
+ introduce a new TARGET_WAITKIND_THREAD_CLONED event. This event is
+ similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except
+ that we end up with a new thread in the same process, instead of a new
+ thread of a new process. Like FORKED and VFORKED, THREAD_CLONED
+ waitstatuses have a child_ptid property, and the child is held stopped
+ until GDB explicitly resumes it. This addresses the in-line stepping
+ case (issues #1 and #2).
+
+ The infrun code that handles displaced stepping fixup for the child
+ after a fork/vfork event is thus reused for THREAD_CLONE, with some
+ minimal conditions added, addressing the displaced stepping case
+ (issue #3).
+
+ The native Linux backend is adjusted to unconditionally report
+ TARGET_WAITKIND_THREAD_CLONED events to the core.
+
+ Following the follow_fork model in core GDB, we introduce a
+ target_follow_clone target method, which is responsible for making the
+ new clone child visible to the rest of GDB.
+
+ Subsequent patches will add clone events support to the remote
+ protocol and gdbserver.
+
+ displaced_step_in_progress_thread becomes unused with this patch, but
+ a new use will reappear later in the series. To avoid deleting it and
+ readding it back, this patch marks it with attribute unused, and the
+ latter patch removes the attribute again. We need to do this because
+ the function is static, and with no callers, the compiler would warn,
+ (error with -Werror), breaking the build.
+
+ This adds a new gdb.threads/stepi-over-clone.exp testcase, which
+ exercises stepping over a clone syscall, with displaced stepping vs
+ inline stepping, and all-stop vs non-stop. We already test stepping
+ over clone syscalls with gdb.base/step-over-syscall.exp, but this test
+ uses pthreads, while the other test uses raw clone, and this one is
+ more thorough. The testcase passes on native GNU/Linux, but fails
+ against GDBserver. GDBserver will be fixed by a later patch in the
+ series.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
+ Change-Id: I95c06024736384ae8542a67ed9fdf6534c325c8e
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-11-13 Pedro Alves <pedro@palves.net>
+
+ gdb/linux: Delete all other LWPs immediately on ptrace exec event
+ I noticed that on an Ubuntu 20.04 system, after a following patch
+ ("Step over clone syscall w/ breakpoint,
+ TARGET_WAITKIND_THREAD_CLONED"), the gdb.threads/step-over-exec.exp
+ was passing cleanly, but still, we'd end up with four new unexpected
+ GDB core dumps:
+
+ === gdb Summary ===
+
+ # of unexpected core files 4
+ # of expected passes 48
+
+ That said patch is making the pre-existing
+ gdb.threads/step-over-exec.exp testcase (almost silently) expose a
+ latent problem in gdb/linux-nat.c, resulting in a GDB crash when:
+
+ #1 - a non-leader thread execs
+ #2 - the post-exec program stops somewhere
+ #3 - you kill the inferior
+
+ Instead of #3 directly, the testcase just returns, which ends up in
+ gdb_exit, tearing down GDB, which kills the inferior, and is thus
+ equivalent to #3 above.
+
+ Vis (after said patch is applied):
+
+ $ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true
+ ...
+ (top-gdb) r
+ ...
+ (gdb) b main
+ ...
+ (gdb) r
+ ...
+ Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69
+ 69 argv0 = argv[0];
+ (gdb) c
+ Continuing.
+ [New Thread 0x7ffff7d89700 (LWP 2506975)]
+ Other going in exec.
+ Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
+ process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
+
+ Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28
+ 28 foo ();
+ (gdb) k
+ ...
+ Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
+ 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
+ 393 return m_suspend.waitstatus_pending_p;
+ (top-gdb) bt
+ #0 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
+ #1 0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345
+ #2 0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564
+ #3 0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284
+ #4 0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278
+ #5 0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247
+ #6 0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864
+ #7 0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590
+ #8 0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911
+ ...
+
+ The root of the problem is that when a non-leader LWP execs, it just
+ changes its tid to the tgid, replacing the pre-exec leader thread,
+ becoming the new leader. There's no thread exit event for the execing
+ thread. It's as if the old pre-exec LWP vanishes without trace. The
+ ptrace man page says:
+
+ "PTRACE_O_TRACEEXEC (since Linux 2.5.46)
+ Stop the tracee at the next execve(2). A waitpid(2) by the
+ tracer will return a status value such that
+
+ status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))
+
+ If the execing thread is not a thread group leader, the thread
+ ID is reset to thread group leader's ID before this stop.
+ Since Linux 3.0, the former thread ID can be retrieved with
+ PTRACE_GETEVENTMSG."
+
+ When the core of GDB processes an exec events, it deletes all the
+ threads of the inferior. But, that is too late -- deleting the thread
+ does not delete the corresponding LWP, so we end leaving the pre-exec
+ non-leader LWP stale in the LWP list. That's what leads to the crash
+ above -- linux_nat_target::kill iterates over all LWPs, and after the
+ patch in question, that code will look for the corresponding
+ thread_info for each LWP. For the pre-exec non-leader LWP still
+ listed, won't find one.
+
+ This patch fixes it, by deleting the pre-exec non-leader LWP (and
+ thread) from the LWP/thread lists as soon as we get an exec event out
+ of ptrace.
+
+ GDBserver does not need an equivalent fix, because it is already doing
+ this, as side effect of mourning the pre-exec process, in
+ gdbserver/linux-low.cc:
+
+ else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events)
+ {
+ ...
+ /* Delete the execing process and all its threads. */
+ mourn (proc);
+ switch_to_thread (nullptr);
+
+
+ The crash with gdb.threads/step-over-exec.exp is not observable on
+ newer systems, which postdate the glibc change to move "libpthread.so"
+ internals to "libc.so.6", because right after the exec, GDB traps a
+ load event for "libc.so.6", which leads to GDB trying to open
+ libthread_db for the post-exec inferior, and, on such systems that
+ succeeds. When we load libthread_db, we call
+ linux_stop_and_wait_all_lwps, which, as the name suggests, stops all
+ lwps, and then waits to see their stops. While doing this, GDB
+ detects that the pre-exec stale LWP is gone, and deletes it.
+
+ If we use "catch exec" to stop right at the exec before the
+ "libc.so.6" load event ever happens, and issue "kill" right there,
+ then GDB crashes on newer systems as well. So instead of tweaking
+ gdb.threads/step-over-exec.exp to cover the fix, add a new
+ gdb.threads/threads-after-exec.exp testcase that uses "catch exec".
+ The test also uses the new "maint info linux-lwps" command if testing
+ on Linux native, which also exposes the stale LWP problem with an
+ unfixed GDB.
+
+ Also tweak a comment in infrun.c:follow_exec referring to how
+ linux-nat.c used to behave, as it would become stale otherwise.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I21ec18072c7750f3a972160ae6b9e46590376643
+
+2023-11-13 Andrew Burgess <aburgess@redhat.com>
+
+ Add "maint info linux-lwps" command
+ This adds a maintenance command that lets you list all the LWPs under
+ control of the linux-nat target.
+
+ For example:
+
+ (gdb) maint info linux-lwps
+ LWP Ptid Thread ID
+ 560948.561047.0 None
+ 560948.560948.0 1.1
+
+ This shows that "560948.561047.0" LWP doesn't map to any thread_info
+ object, which is bogus. We'll be using this in a testcase in a
+ following patch.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Change-Id: Ic4e9e123385976e5cd054391990124b7a20fb3f5
+
+2023-11-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix Wmaybe-uninitialized in tui_find_disassembly_address
+ When building gdb with -O2, we run into:
+ ...
+ gdb/tui/tui-disasm.c: In function ‘CORE_ADDR tui_find_disassembly_address \
+ (gdbarch*, CORE_ADDR, int)’:
+ gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used uninitialized \
+ in this function [-Wmaybe-uninitialized]
+ if (last_addr < pc)
+ ^~
+ ...
+
+ The warning triggers since commit 72535eb14bd ("[gdb/tui] Fix segfault in
+ tui_find_disassembly_address").
+
+ Fix the warning by ensuring that last_addr is initialized at the point of
+ use:
+ ...
+ + last_addr = asm_lines.back ().addr;
+ if (last_addr < pc)
+ ...
+
+ Tested on x86_64-linux.
+
+2023-11-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Make assert in tui_find_disassembly_address more strict
+ In tui_find_disassembly_address we find an assert:
+ ...
+ if (asm_lines.size () < max_lines)
+ {
+ if (!possible_new_low.has_value ())
+ return new_low;
+
+ /* Take the best possible match we have. */
+ new_low = *possible_new_low;
+ next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
+ last_addr = asm_lines.back ().addr;
+ gdb_assert (asm_lines.size () >= max_lines);
+ }
+ ...
+
+ The comment right above:
+ ...
+ /* If we failed to disassemble the required number of lines then the
+ following walk forward is not going to work, it assumes that
+ ASM_LINES contains exactly MAX_LINES entries. Instead we should
+ consider falling back to a previous possible start address in
+ POSSIBLE_NEW_LOW. */
+ ...
+ claims that the more strict asm_lines.size () == max_line is required.
+
+ Update the assert to reflect this, and move it to after the if because it's
+ supposed to hold in general, not just when entering the if.
+
+ Tested on x86_64-linux.
+
+2023-11-13 Tom Tromey <tom@tromey.com>
+
+ Remove declaration of re_comp
+ defs.h declares re_comp, but it shouldn't. If this is needed, it
+ should be picked up from xregex.h via gdb_regex.h.
+
+ Tested by rebuilding.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-11-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-10 Simon Marchi <simon.marchi@efficios.com>
+
+ bfd, binutils: add gfx11 amdgpu architectures
+ Teach bfd and readelf about some recent gfx11 architectures. This code
+ is taken from the rocgdb 5.7.x branch [1].
+
+ [1] https://github.com/rocm-Developer-Tools/rocgdb/tree/rocm-5.7.x
+
+ bfd/ChangeLog:
+
+ * archures.c (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
+ bfd_mach_amdgcn_gfx1102): New.
+ * bfd-in2.h (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
+ bfd_mach_amdgcn_gfx1102): New.
+ * cpu-amdgcn.c (arch_info_struct): Add entries for
+ bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
+ bfd_mach_amdgcn_gfx1102.
+
+ binutils/ChangeLog:
+
+ * readelf.c (decode_AMDGPU_machine_flags): Handle gfx1100,
+ gfx1101, gfx1102.
+
+ include/ChangeLog:
+
+ * elf/amdgpu.h (EF_AMDGPU_MACH_AMDGCN_GFX1100,
+ EF_AMDGPU_MACH_AMDGCN_GFX1101,
+ EF_AMDGPU_MACH_AMDGCN_GFX1102): New.
+
+ Change-Id: I95a8a62942e359781a1c9fa2079950fbcf2a78b8
+ Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
+ Cc: Lancelot Six <lancelot.six@amd.com>
+
+2023-11-10 Michael J. Eager <eager@eagercon.com>
+
+ Correct formatting errors in elf32-microblaze.c
+
+2023-11-10 YunQiang Su <yunqiang.su@cipunited.com>
+
+ Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian
+
+ GAS/MIPS: Fix testcase module-defer-warn2 for r2+ triples
+
+2023-11-10 Vsevolod Alekseyev <sevaa@sprynet.com>
+
+ readelf..debug-dump=loc displays bogus base addresses
+ PR 30880
+ * dwarf.c (read_and_display_attr_value): Fix loclist handling. (display_loclists_list): Likewise.
+
+2023-11-10 YunQiang Su <yunqiang.su@cipunited.com>
+
+ GAS/MIPS: Add mips16-e-irix.d testcase
+
+2023-11-10 Ying Huang <ying.huang@oss.cipunited.com>
+
+ MIPS: Change all E_MIPS_* to EF_MIPS_*
+
+2023-11-10 Nick Clifton <nickc@redhat.com>
+
+ Add ability to change linker warning messages into errors when reporting executable stacks and/or executable segments.
+ include
+ * bfdlink.h (struct bfd_link_info): Update descriptions of the 'execstack', 'noexecstack' and 'warn_execstack' fields. Add 'error_exectack' and 'warn_is_error_for_rwx_segments' fields.
+
+ bfd
+ * elf.c (assign_file_positions_except_relocs): Turn warnings about executable segments into errors if so requested.
+ * elflink.c (bfd_elf_size_dynamic_sections): Turn warnings about executable stacks into errors if so requested.
+
+ ld
+ * ldlex.h (enum option_values): Add OPTION_ERROR_EXECSTACK, OPTION_NO_ERROR_EXECSTACK, OPTION_WARN_EXECSTACK_OBJECTS, OPTION_ERROR_RWX_SEGMENTS and OPTION_NO_ERROR_RWX_SEGMENTS. (struct ld_option): Add new long options. (parse_args): Parse new long options. (elf_static_list_options): Display the new options.
+ * ld.texi: Document the new command line options.
+ * configure.ac (error-execstack): New configuration option. (error-rwx-segments): New configuration option.
+ * emultempl/elf.em (_before_parse): Initialse the new linkinfo fields.
+ * NEWS: Mention the new features.
+ * config.in: Regenerate.
+ * configure: Regenerate.
+ * testsuite/ld-elf/commonpage2.d: Disable errors for RWX segments and/or executable stacks.
+ * testsuite/ld-elf/elf.exp: Likewise.
+ * testsuite/ld-elf/header.d: Likewise.
+ * testsuite/ld-elf/loadaddr1.d: Likewise.
+ * testsuite/ld-elf/loadaddr2.d: Likewise.
+ * testsuite/ld-elf/maxpage4.d: Likewise.
+ * testsuite/ld-elf/nobits-1.d: Likewise.
+ * testsuite/ld-elf/note-1.d: Likewise.
+ * testsuite/ld-elf/orphan-10.d: Likewise.
+ * testsuite/ld-elf/orphan-11.d: Likewise.
+ * testsuite/ld-elf/orphan-12.d: Likewise.
+ * testsuite/ld-elf/orphan-5.d: Likewise.
+ * testsuite/ld-elf/orphan-7.d: Likewise.
+ * testsuite/ld-elf/orphan-8.d: Likewise.
+ * testsuite/ld-elf/orphan-9.d: Likewise.
+ * testsuite/ld-elf/orphan-region.d: Likewise.
+ * testsuite/ld-elf/orphan.d: Likewise.
+ * testsuite/ld-elf/pr19539.d: Likewise.
+ * testsuite/ld-elf/pr26256-1a.d: Likewise.
+ * testsuite/ld-elf/pr26907.d: Likewise.
+ * testsuite/ld-elf/pr28597.d: Likewise.
+ * testsuite/ld-elf/retain2.d: Likewise.
+ * testsuite/ld-elf/shared.exp: Likewise.
+ * testsuite/ld-elf/size-1.d: Likewise.
+ * testsuite/ld-elf/textaddr7.d: Likewise.
+ * testsuite/ld-elf/warn1.d: Likewise.
+ * testsuite/ld-elf/warn2.d: Likewise.
+ * testsuite/ld-i386/discarded1.d: Likewise.
+ * testsuite/ld-i386/pr19175.d: Likewise.
+ * testsuite/ld-i386/pr19539.d: Likewise.
+ * testsuite/ld-i386/pr23189.d: Likewise.
+ * testsuite/ld-plugin/lto-3r.d: Likewise.
+ * testsuite/ld-plugin/lto-5r.d: Likewise.
+ * testsuite/ld-plugin/lto.exp: Likewise.
+ * testsuite/ld-powerpc/ppc476-shared.d: Likewise.
+ * testsuite/ld-powerpc/ppc476-shared2.d: Likewise.
+ * testsuite/ld-powerpc/pr28827-2.d: Likewise.
+ * testsuite/ld-s390/s390.exp: Likewise.
+ * testsuite/ld-scripts/align2a.d: Likewise.
+ * testsuite/ld-scripts/align2b.d: Likewise.
+ * testsuite/ld-scripts/align5.d: Likewise.
+ * testsuite/ld-scripts/alignof.exp: Likewise.
+ * testsuite/ld-scripts/crossref.exp: Likewise.
+ * testsuite/ld-scripts/defined2.d: Likewise.
+ * testsuite/ld-scripts/defined3.d: Likewise.
+ * testsuite/ld-scripts/defined5.d: Likewise.
+ * testsuite/ld-scripts/pr14962.d: Likewise.
+ * testsuite/ld-scripts/pr18963.d: Likewise.
+ * testsuite/ld-scripts/pr20302.d: Likewise.
+ * testsuite/ld-scripts/print-memory-usage.exp: Likewise.
+ * testsuite/ld-scripts/rgn-at1.d: Likewise.
+ * testsuite/ld-scripts/rgn-at10.d: Likewise.
+ * testsuite/ld-scripts/rgn-at4.d: Likewise.
+ * testsuite/ld-scripts/rgn-at6.d: Likewise.
+ * testsuite/ld-scripts/rgn-at8.d: Likewise.
+ * testsuite/ld-scripts/rgn-at9.d: Likewise.
+ * testsuite/ld-scripts/rgn-over1.d: Likewise.
+ * testsuite/ld-scripts/rgn-over2.d: Likewise.
+ * testsuite/ld-scripts/rgn-over4.d: Likewise.
+ * testsuite/ld-scripts/rgn-over5.d: Likewise.
+ * testsuite/ld-scripts/rgn-over6.d: Likewise.
+ * testsuite/ld-scripts/script.exp: Likewise.
+ * testsuite/ld-scripts/sizeof.exp: Likewise.
+ * testsuite/ld-scripts/sort-file.d: Likewise.
+ * testsuite/ld-x86-64/discarded1.d: Likewise.
+ * testsuite/ld-x86-64/pr19175.d: Likewise.
+ * testsuite/ld-x86-64/pr19539a.d: Likewise.
+ * testsuite/ld-x86-64/pr19539b.d: Likewise.
+ * testsuite/ld-x86-64/pr23189.d: Likewise.
+
+2023-11-10 Nick Clifton <nickc@redhat.com>
+
+ Move new features above the 'Changes in 2.41' comment
+
+2023-11-10 Lulu Cai <cailulu@loongson.cn>
+
+ Add support for ilp32 register alias.
+
+2023-11-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-09 Michael Matz <matz@suse.de>
+
+ bfd: use less memory in string merging
+ the offset-to-entry mappings are allocated in blocks, which may
+ become a bit wasteful in case there are extremely many small
+ input files or sections. This made it so that a large project
+ (Qt5WebEngine) didn't build anymore on x86 32bit due to address
+ space limits. It barely fit into address space before the new
+ string merging, and then got pushed over the limit by this.
+
+ So instead of leaving the waste reallocate the maps to their final
+ size once known. Now the link barely fits again.
+
+ bfd/
+ * merge.c (record_section): Reallocate offset maps to their
+ final size.
+
+2023-11-09 Michael Matz <matz@suse.de>
+
+ ld: Avoid overflows in string merging
+ as the bug report shows we had an overflow in the test if
+ hash table resizing is needed. Reorder the expression to avoid
+ that. There's still a bug somewhere in gracefully handling
+ failure in resizing (e.g. out of memory), but this pushes the
+ boundary for that occurring somewhen into the future and
+ immediately helps the reporter.
+
+ bfd/
+
+ PR ld/31009
+ * merge.c (NEEDS_RESIZE): New macro avoiding overflow.
+ (sec_merge_maybe_resize): Use it.
+ (sec_merge_hash_insert): Ditto.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ ld: aarch64: Use lp64 abi in recent BTI stub tests
+ The tests are not compatible with ilp32 abi: the GNU property
+ note is ABI dependent (size changes) and the disasm is ABI
+ dependent too. Making the test portable between the ABIs is
+ not trivial.
+
+ For now force lp64 abi.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ ld: aarch64: Add BTI stub insertion test PR30930
+ The test creates a large shared library and covers a number of
+ BTI stub insertion cases.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Avoid BTI stub for a PLT that has BTI
+ We decide to emit BTI stubs based on the instruction at the target
+ location. But PLT code is generated later than the stubs so we always
+ read 0 which is not a valid BTI.
+
+ Fix the logic to special case the PLT section: this is code the linker
+ generates so we know when it will have BTI.
+
+ This avoids BTI stubs in large executables where the PLTs have them
+ already. An alternative is to never emit BTI stubs for PLTs, instead
+ use BTI in the PLT if a library gets too big, however that may be
+ more tricky given the ordering of PLT sizing and stub insertion.
+
+ Related to bug 30957.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Fix leaks in case of BTI stub reuse
+ BTI stub parameters were recomputed even if those were already set up.
+ This is unnecessary work and leaks the symbol name that is allocated
+ for the stub.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Fix broken BTI stub PR30930
+ Input sections are grouped together that can use the same stub area
+ (within reach) and these groups have a stable id.
+
+ Stubs have a name generated from the stub group id and target symbol.
+ When a relocation requires a stub with a name that already exists, the
+ stub is reused instead of adding a new one.
+
+ For an indirect branch stub another BTI stub may be inserted near the
+ target to provide a BTI landing pad.
+
+ The BTI stub can end up with the same stub group id and thus the same
+ name as the indirect stub. This happens if the target symbol is within
+ reach of the indirect branch stub. Then, due to the name collision,
+ only a single stub was emmitted which branched to itself causing an
+ infinite loop at runtime.
+
+ A possible solution is to just name the BTI stubs differently, but
+ since in the problematic case the indirect and BTI stub are in the
+ same stub area, a better solution is to emit a single stub with a
+ direct branch. The stub is still needed since the caller cannot reach
+ the target directly and we also want a BTI landing pad in the stub in
+ case other indirect stubs target the same symbol and thus need a BTI
+ stub.
+
+ In short we convert an indirect branch stub into a BTI stub when the
+ target is within reach and has no BTI. It is a hassle to change the
+ symbol of the stub so a BTI stub may end up with *_veneer instead of
+ *_bti_veneer after the conversion, but this should not matter much.
+ (Refactoring some of _bfd_aarch64_add_call_stub_entries would be
+ useful but too much for this bug fix patch.)
+
+ The same conversion to direct branch could be done even if the target
+ did not need a BTI. The stub groups are fixed in the current logic so
+ linking can fail if too many stubs are inserted and the section layout
+ is changed too much, but this only happens in extreme cases that can
+ be reasonably ignored. Because of this the target cannot go out of
+ reach during stub insertion so the optimization is valid, but not
+ implemented by this patch for the non-BTI case.
+
+ Fixes bug 30930.
+
+2023-11-09 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Fix BTI stub optimization PR30957
+ The instruction was looked up in the wrong input file (file of branch
+ source instead of branch target) when optimizing away BTI stubs in
+
+ commit 5834f36d93cabf1a8bcc7dd7654141aed3d296bc
+ bfd: aarch64: Optimize BTI stubs PR30076
+
+ This can cause adding BTI stubs when they are not necessary or removing
+ them when they are (the latter is a correctness issue but it is very
+ unlikely in practice).
+
+ Fixes bug 30957.
+
+2023-11-09 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Fix error in THE system register checking
+ The erroneous omission of a "reg_value == " in the THE system register
+ encoding check added in [1] led to an error which was not picked up in
+ GCC but which was flagged in Clang due to its use of
+ [-Werror,-Wconstant-logical-operand] check. Together with this fix we
+ add a new test for the THE registers to pick up their illegal use,
+ adding an extra and important layer of validation.
+
+ Furthermore, in separating system register from instruction
+ implementation (with which only the former was of concern in the cited
+ patch), additions made to `aarch64-tbl.h' are rolled back so
+ that these can be added later when adding THE instructions to the
+ codebase, a more natural place for these changes.
+
+ [1] https://sourceware.org/pipermail/binutils/2023-November/130314.html
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo.
+ * aarch64-tbl.h (THE): Remove.
+ (aarch64_feature_set aarch64_feature_the): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE
+ system registers.
+ * testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise.
+
+2023-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86: rework UWRMSR operand swapping
+ As indicated during review already, doing the swapping early is overall
+ cheaper than doing it only after operand matching.
+
+2023-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86: do away with is_evex_encoding()
+ As we have grown more uses of it, it becomes increasingly more desirable
+ to replace it by a simpler check. Have i386-gen do at build time what so
+ far was done at runtime: Deal with templates indicating EVEX-encoding by
+ other than the EVex attribute, and set that to "dynamic" in such cases.
+
+ This then allows simplifying a number of other conditionals as well.
+
+2023-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86: split insn templates' CPU field
+ Right now the opcode table has entries with ISA restrictions of the form
+ FEAT1|FEAT2, the meaning of which depends on context and requires
+ special treatment in tc-i386.c: Sometimes this means "both features
+ requires", whereas originally it was intended to solely mean "all of
+ these features required". Split the field, with the original one
+ regaining its original meaning. The new field now truly means "any of
+ these". The combination of both fields is still and &&-type check, i.e.
+ (all of these) && (any of these). In the opcode table more involved
+ combinations of features then also need expressing this way: "all"
+ entities first, follow by "any" entities enclosed in parentheses, e.g.
+ x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be
+ added around the "any" part (unless parsing logic was further relaxed).
+
+ Note that this way AVX512VL no longer needs as much special treatment,
+ and hence templates previously using AVX512F|AVX512VL are switched to
+ just AVX512VL.
+
+ Note further that this requires FMA handling as resulting from
+ da0784f961d8 ("x86: fold FMA VEX and EVEX templates") to be slightly
+ re-done: FMA now becomes more similar to AVX and AVX2.
+
+2023-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86: Cpu64 handling improvements
+ First of all we want to also accumulate its reverse dependencies, such
+ that we can use them in cpu_flags_match(). This is in particular in
+ preparation of APX additions, such that e.g. BMI VEX-encoding templates
+ can become combined VEX/EVEX ones.
+
+ Once we have the reverse dependencies, we can further leverage them to
+ omit explicit "&x64" from any insn templates dealing with 64-bit-mode-
+ only ISA extensions. Besides helping readability for several insn
+ templates we already have, this will also help with what is going to be
+ added for APX (as all of the new templates would otherwise need to have
+ "&x64").
+
+ Note that rather than leaving a meaningless CPU_64_FLAGS (which is
+ unused anyway), its emitting is now also suppressed.
+
+2023-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86: Intel Core processors do not support CMPXCHG16B
+ This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot
+ possibly be supported by CPUs not supporting 64-bit mode.
+
+2023-11-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-08 Carl Love <cel@linux.ibm.com>
+
+ rs6000, Fix test gdb.base/store.exp
+ The test currently fails for IEEE 128-bit floating point types. PowerPC
+ supports the IBM double 128-bit floating point format and IEEE 128-bit
+ format. The IBM double 128-bit floating point format uses two 64-bit
+ floating point registers to store the 128-bit value. The IEEE 128-bit
+ floating point format stores the value in a single 128-bit vector-scalar
+ register (vsr).
+
+ The various floating point values, 32-bit float, 64-bit double, IBM double
+ 128-bit float and IEEE 128-bit floating point numbers are all mapped to the
+ DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are
+ actually stored in a vsr not the fprs. This patch changes the register
+ mapping for the vsrs from the fpr to the vsr registers so the value is
+ properly accessed by GDB. The functions rs6000_linux_register_to_value,
+ rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
+ the value is an IEEE 128-bit floating point value and adjust the register
+ number as needed. The test in function rs6000_convert_register_p is fixed
+ so it is only true for floating point values.
+
+ This patch fixes three regression tests in gdb.base/store.exp.
+
+ The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
+ with no regressions.
+
+2023-11-08 Carl Love <cel@us.ibm.com>
+
+ rs6000, Fix Linux DWARF register mapping
+ Overview of issues fixed by the patch.
+
+ The primary issue this patch fixes is the DWARF register mapping for
+ Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping
+ issues. The register mapping issue is responsible for two of the
+ five regression bugs seen in gdb.base/store.exp.
+
+ Once the register mapping was fixed, an underlying issue with the unwinding
+ of the signal trampoline in common-code in ifrun.c was found. This
+ underlying bug is best described by Ulrich in the following description.
+
+ The unwinder bug shows up on platforms where the kernel uses a trampoline
+ to dispatch "calls to" the signal handler (not just *returns from* the
+ signal handler). Many platforms use a trampoline for signal return, and
+ that is working fine, but the only platform I'm (Ulrich) aware of that
+ uses a trampoline for signal handler calls is (recent kernels for)
+ PowerPC. I believe the rationale for using a trampoline here
+ is to improve performance by avoiding unbalancing of the
+ branch predictor's call/return stack.
+
+ However, on PowerPC the bug is dormant as well as it is hidden
+ by *another* bug that prevents correct unwinding out of the
+ signal trampoline. This is because the custom CFI for the
+ trampoline uses a register number (VSCR) that is not ever used
+ by compiler-generated CFI, and that particular register is
+ mapped to an invalid number by the current PowerPC DWARF mapper.
+
+ The underlying unwinder bug is exposed by the "new" regression failures
+ in gdb.base/sigstep.exp. These failures were previously masked by
+ the fact that GDB was not seeing a valid frame when it tried to unwind
+ the frames. The sigstep.exp test is specifically testing stepping into
+ a signal handler. With the correct DWARF register mapping in place,
+ specifically the VSCR mapping, the signal trampoline code now unwinds to a
+ valid frame exposing the pre-existing bug in how the signal handler on
+ PowerPC works. The one line change infrun.c fixes the exiting bug in
+ the common-code for platforms that use a trampoline to dispatch calls
+ to the signal handler by not stopping in the SIGTRAMP_FRAME.
+
+ Detailed description of the DWARF register mapping fix.
+
+ The PowerPC DWARF register mapping is the same for the .eh_frame and
+ .debug_frame on Linux. PowerPC uses different mapping for .eh_frame and
+ .debug_frame on other operating systems. The current GDB support for
+ mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
+ rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
+ The files have some legacy mappings for spe_acc, spefscr, EV which was
+ removed from GCC in 2017.
+
+ This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
+ and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
+ the DWARF register mappings on Linux. Function
+ rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
+ and gdbarch_stab_reg_to_regnum since the mappings are the same.
+
+ The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
+ call set_gdbarch_dwarf2_reg_to_regnum map the new function
+ rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly,
+ dwarf2_frame_set_adjust_regnum is called to map
+ rs6000_linux_adjust_frame_regnum into the architecture.
+
+ Additional detail on the signal handling fix.
+
+ The specific sequence of events for handling a signal on most
+ architectures is as follows:
+
+ 1) Some code is running when a signal arrives.
+ 2) The kernel handles the signal and dispatches to the handler.
+ ...
+
+ However on PowerPC the sequence of events is:
+
+ 1) Some code is running when a signal arrives.
+ 2) The kernel handles the signal and dispatches to the trampoline.
+ 3) The trampoline performs a normal function call to the handler.
+ ...
+
+ We want the "nexti" to step into, not over, signal handlers invoked by
+ the kernel. This is the case for most platforms as the kernel puts a
+ signal trampoline frame onto the stack to handle proper return after the
+ handler. However, on some platforms such as PowerPC, the kernel actually
+ uses a trampoline to handle *invocation* of the handler. We do not
+ want GDB to stop in the SIGTRAMP_FRAME. The issue is fixed in function
+ process_event_stop_test by adding a check that the frame is not a
+ SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This
+ prevents GDB from erroneously detecting the trampoline invocation as a
+ subroutine call.
+
+ This patch fixes two regression test failures in gdb.base/store.exp.
+
+ The patch then fixes an exposed, dormant, signal handling issue that
+ is exposed in the signal handling test gdb.base/sigstep.exp.
+
+ The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
+ no new regressions. Note, only two of the five failures in store.exp
+ are fixed. The remaining three failures are fixed in a following
+ patch.
+
+2023-11-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: call update_thread_list after completing an inferior call
+ I noticed that if GDB is using a remote or extended-remote target,
+ then, if an inferior call caused a new thread to appear, or for an
+ existing thread to exit, then these events are not reported to the
+ user.
+
+ The problem is that for these targets GDB relies on a call to
+ update_thread_list to learn about changes to the inferior's thread
+ list.
+
+ If GDB doesn't pass through the normal stop code then GDB will not
+ call update_thread_list, and so will not report changes in the thread
+ list.
+
+ This commit adds an additional update_thread_list call, after which
+ thread events are correctly reported.
+
+2023-11-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: call update_thread_list for $_inferior_thread_count function
+ I noticed that sometimes the value returned by $_inferior_thread_count
+ can become out of sync with the actual thread count of the inferior,
+ and will disagree with the number of threads reported by 'info
+ threads'. This commit fixes this issue.
+
+ The cause of the problem is that 'info threads' includes a call to
+ update_thread_list, this can be seen in print_thread_info_1 in
+ thread.c, while $_inferior_thread_count doesn't include a similar
+ call, see the function inferior_thread_count_make_value also in
+ thread.c.
+
+ Of course, this is only a problem when GDB is running on a target that
+ relies on update_thread_list calls to learn about new threads,
+ e.g. remote or extended-remote targets. Native targets generally
+ learn about new threads as soon as they appear and will not have this
+ problem.
+
+ I ran into this issue when writing a test for the next commit which
+ uses inferior function calls to add an remove threads from an
+ inferior. But for testing I've made use of non-stop mode and
+ asynchronous inferior execution; by reading the inferior state I can
+ know when a new thread has been created, at which point I can print
+ $_inferior_thread_count while the inferior is still running. This is
+ important, if I stop the inferior then GDB will pass through an
+ update_thread_list call in the normal stop code, which will
+ synchronise the thread list, after which $_inferior_thread_count will
+ report the correct value.
+
+ With this change in place $_inferior_thread_count is now correct.
+
+2023-11-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add a custom command completer for disassemble command
+ Add a new command completer function for the disassemble command.
+ There are two things that this completion function changes. First,
+ after the previous commit, the new function calls skip_over_slash_fmt,
+ which means that hitting tab after entering a /OPT flag now inserts a
+ space ready to start typing the address to disassemble at:
+
+ (gdb) disassemble /r<TAB>
+ (gdb) disassemble /r <CURSOR>
+
+ But also, we now get symbol completion after a /OPT option set,
+ previously this would do nothing:
+
+ (gdb) disassemble /r mai<TAB>
+
+ But now:
+
+ (gdb) disassemble /r mai<TAB>
+ (gdb) disassemble /r main <CURSOR>
+
+ Which was my main motivation for working on this commit.
+
+ However, I have made a second change in the completion function.
+ Currently, the disassemble command calls the generic
+ location_completer function, however, the disassemble docs say:
+
+ Note that the 'disassemble' command's address arguments are specified
+ using expressions in your programming language (*note Expressions:
+ Expressions.), not location specs (*note Location Specifications::).
+ So, for example, if you want to disassemble function 'bar' in file
+ 'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble
+ foo.c:bar'.
+
+ And indeed, if I try:
+
+ (gdb) disassemble hello.c:main
+ No symbol "hello" in current context.
+ (gdb) disassemble hello.c::main
+ No symbol "hello" in current context.
+ (gdb) disassemble 'hello.c'::main
+ Dump of assembler code for function main:
+ ... snip ...
+
+ But, if I do this:
+
+ (gdb) disassemble hell<TAB>
+ (gdb) disassemble hello.c:<CURSOR>
+
+ which is a consequence of using the location_completer function. So
+ in this commit, after calling skip_over_slash_fmt, I forward the bulk
+ of the disassemble command completion to expression_completer. Now
+ when I try this:
+
+ (gdb) disassemble hell<TAB>
+
+ gives nothing, which I think is an improvement. There is one slight
+ disappointment, if I do:
+
+ (gdb) disassemble 'hell<TAB>
+
+ I still get nothing. I had hoped that this would expand to:
+ 'hello.c':: but I guess this is a limitation of the current
+ expression_completer implementation, however, I don't think this is a
+ regression, the previous expansion was just wrong. Fixing
+ expression_completer is out of scope for this commit.
+
+ I've added some disassembler command completion tests, and also a test
+ that disassembling using 'FILE'::FUNC syntax works, as I don't think
+ that is tested anywhere.
+
+2023-11-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make skip_over_slash_fmt available outside printcmd.c
+ Move the function skip_over_slash_fmt into completer.c, and make it
+ extern, with a declaration in completer.h.
+
+ This is a refactor in order to support the next commit. I've not
+ changed any of the code in skip_over_slash_fmt.
+
+ There should be no user visible changes after this commit.
+
+2023-11-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: error if /r and /b are used with disassemble command
+ The disassembler gained a new /b flag in this commit:
+
+ commit d4ce49b7ac077a9882d6a5e689e260300045ca88
+ Date: Tue Jun 21 20:23:35 2022 +0100
+
+ gdb: disassembler opcode display formatting
+
+ The /b and /r flags result in the instruction opcodes displayed in
+ different formats, so it's not possible to have both at the same
+ time. Currently the /b flag overrides the /r flag.
+
+ We have a similar situation with the /m and /s flags, but here, if the
+ user tries to use both flags then they will get an error.
+
+ I think the error is clearer, so in this commit I propose that we add
+ an error if /r and /b are both used.
+
+ Obviously this change breaks backwards compatibility. I don't have a
+ compelling argument for why we should make the change beyond my
+ feeling that it was a mistake not to add this error from the start,
+ and that the new behaviour is better.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-11-08 Jan Beulich <jbeulich@suse.com>
+
+ gas: S_GET_{NAME,SEGMENT}() don't alter their input symbol
+ Make their parameters pointer-to-const, thus allowing callers to also be
+ const-correct where possible.
+
+2023-11-08 Clément Chigot <chigot@adacore.com>
+
+ ld: print branch fixups into the map file for ppc elf targets
+ In a safety context, it could interesting to track the trampolines being
+ generated, ensuring there are expected or not.
+
+ bfd/ChangeLog:
+
+ * elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.
+
+ ld/ChangeLog:
+
+ * ld.texi (--print-map): Add new item about fixups.
+
+2023-11-08 Tom Tromey <tom@tromey.com>
+
+ Add minimal thread-safety to BFD
+ This patch provides some minimal thread-safety to BFD.
+
+ The BFD client can request thread-safety by providing a lock and
+ unlock function. The globals used during BFD creation (e.g.,
+ bfd_id_counter) are then locked, and the file descriptor cache is also
+ locked. A function to clean up any thread-local data is now provided
+ for BFD clients.
+
+ * bfd-in2.h: Regenerate.
+ * bfd.c (lock_fn, unlock_fn): New globals.
+ (bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
+ functions.
+ * cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
+ (cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
+ and unlock.
+ (cache_bclose): Add comment.
+ (cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
+ (_bfd_cache_init_unlocked): New function.
+ (bfd_cache_init): Use it. Lock and unlock.
+ (_bfd_cache_close_unlocked): New function.
+ (bfd_cache_close, bfd_cache_close_all): Use it. Lock and unlock.
+ (_bfd_open_file_unlocked): New function.
+ (bfd_open_file): Use it. Lock and unlock.
+ * doc/bfd.texi (BFD front end): Add Threading menu item.
+ * libbfd.h: Regenerate.
+ * opncls.c (_bfd_new_bfd): Lock and unlock.
+ * po/bfd.pot: Regenerate.
+
+2023-11-08 Tom Tromey <tom@tromey.com>
+
+ Make various error-related globals thread-local
+ This changes bfd_error et al to be thread-local.
+
+ * Makefile.in: Regenerate.
+ * aclocal.m4: Include ax_tls.m4.
+ * ax_tls.m4: New file.
+ * bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf):
+ Now thread-local.
+ (bfd_asprintf): Update docs.
+ * config.in, configure: Regenerate.
+ * configure.ac: Call AX_TLS.
+ * po/bfd.pot: Regenerate.
+
+2023-11-08 Tom Tromey <tom@tromey.com>
+
+ Make _bfd_error_buf static
+ This makes _bfd_error_buf static and adds a way to clear it. I felt
+ that this made the subsequent patches a little cleaner.
+
+ * bfd.c (_bfd_error_buf): Now static.
+ (bfd_set_input_error): Use _bfd_clear_error_data.
+ (_bfd_clear_error_data): New function.
+ (bfd_init): Use _bfd_clear_error_data.
+ * libbfd.h: Regenerate.
+ * opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
+ * po/bfd.pot: Regenerate.
+
+2023-11-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-07 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add LSE128 instructions
+ Implement, together with the necessary tests, the following new LSE128
+ atomic instructions:
+
+ * Atomic bit clear on quadword in memory (ldclrp{a|l|al});
+ * Atomic bit set on quadword in memory (ldsetp{a|l|al});
+ * Swap quadword in memory (swpp{a|l|al});
+
+ gas/ChangeLog:
+
+ * testsuite/gas/aarch64/lse128-atomic.d: New.
+ * testsuite/gas/aarch64/lse128-atomic.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * aarch64-tbl.h (ldclrp): new _LSE128_INSN entry.
+ (ldclrpa): Likewise.
+ (ldclrpal): Likewise.
+ (ldclrpl): Likewise.
+ (ldsetp): Likewise.
+ (ldsetpa): Likewise.
+ (ldsetpal): Likewise.
+ (ldsetpl): Likewise.
+ (swpp): Likewise.
+ (swppa): Likewise.
+ (swppal): Likewise.
+ (swppl): Likewise.
+ * aarch64-asm-2.c: Regenerate.
+ * aarch64-dis-2.c: Likewise.
+ * aarch64-opc-2.c: Likewise.
+
+2023-11-07 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add arch support for LSE128 extension
+ Enable the `+lse128' feature modifier which, together with new
+ internal feature flags, enables LSE128 instructions, which are
+ represented via the new `_LSE128_INSN' macro.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (aarch64_features): Add new "lse128"
+ entry.
+
+ include/ChangeLog:
+
+ * include/opcode/aarch64.h (enum aarch64_feature_bit): New
+ AARCH64_FEATURE_LSE128 feature bit.
+ (enum aarch64_insn_class): New lse128_atomic instruction class.
+
+ opcodes/ChangeLog:
+
+ * opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
+ (LSE128): Likewise.
+ (_LSE128_INSN): Likewise.
+
+2023-11-07 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add LSE128 instruction operand support
+ Given the particular encoding of the LSE128 instructions, create the
+ necessary shared input+output operand register description and
+ handling in the code to allow for the encoding of the LSE128 128-bit
+ atomic operations.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_operands):
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd):
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.c (fields):
+ (aarch64_print_operand):
+ * aarch64-opc.h (enum aarch64_field_kind):
+ * aarch64-tbl.h (AARCH64_OPERANDS):
+
+2023-11-07 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add 128-bit system register flags
+ In preparation for the implementation of 128-bit system register
+ support across the toolchain, this patch adds the feature flag
+ F_REG_128 and adds it to relevant system registers in
+ `aarch64-sys-regs.def'.
+
+ Given the shared nature of this file, this change is made necessary
+ initially to implement argument validation in the `__arm_rsr128' and
+ `__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in
+ the binutils implementation of the corresponding `mrrs' and `msrr'
+ instructions.
+
+ Regression tested on aarch64-linux-gnu, no regressions.
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.h (F_REG_128): New flag.
+ * aarch64-sys-regs.def (par_el1): Add F_REG_128 flag.
+ (rcwmask_el1): Likewise.
+ (rcwsmask_el1): Likewise.
+ (ttbr0_el1): Likewise.
+ (ttbr0_el12): Likewise.
+ (ttbr0_el2): Likewise.
+ (ttbr1_el1): Likewise.
+ (ttbr1_el12): Likewise.
+ (ttbr1_el2): Likewise.
+ (vttbr_el2): Likewise.
+
+2023-11-07 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Add THE system register support
+ Add Binutils support for system registers associated with the
+ Translation Hardening Extension (THE).
+
+ In doing so, we also add core feature support for THE, enabling its
+ associated feature flag and implementing the necessary
+ feature-checking machinery.
+
+ Regression tested on aarch64-linux-gnu, no regressions.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
+ * doc/c-aarch64.texi (AArch64 Extensions): Update
+ documentation for `the' option.
+ * testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
+ associated system registers.
+ * testsuite/gas/aarch64/sysreg-8.d: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_feature_bit): Add
+ AARCH64_FEATURE_THE.
+
+ opcode/ChangeLog:
+
+ * aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
+ system register check support.
+ * aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
+ * aarch64-tbl.h: Define `THE' preprocessor macro.
+
+2023-11-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/arm: remove thumb bit in arm_adjust_breakpoint_address
+ When compiling gdb with -fsanitize=address on ARM, I get a crash in test
+ gdb.arch/arm-disp-step.exp, reproduced easily with:
+
+ $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
+ Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
+ =================================================================
+ ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494
+
+ Since it doesn't require running the program, it can be reproduced locally on a
+ dev machine other than ARM, after acquiring the test binary.
+
+ The length of the allocate buffer `buf` is 1, and we try to extract an
+ integer of size 2 from it. The length of 1 comes from the subtraction
+ `bpaddr - boundary`. Normally, on ARM, all instructions are aligned on
+ a multiple of 2, so it's weird for this subtraction to result in 1. In
+ this case, boundary comes from the result of find_pc_partial_function
+ returning 0x549:
+
+ (gdb) p/x bpaddr
+ $2 = 0x54a
+ (gdb) p/x boundary
+ $3 = 0x549
+ (gdb) p/x bpaddr - boundary
+ $4 = 0x1
+
+ 0x549 is the address of the test_call_subr label, 0x548, with the thumb
+ bit enabled. Before doing some math with the address, I think we need
+ to strip the thumb bit, like is done elsewhere (for instance for bpaddr
+ earlier in the same function).
+
+ I wonder if find_pc_partial_function should do that itself, in order to
+ return an address that is suitable for arithmetic. In any case, that
+ would be a change with a broad impact, so for now just fix the issue
+ locally.
+
+ After the patch:
+
+ $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
+ Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
+ Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103.
+
+ Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-11-07 Jan Beulich <jbeulich@suse.com>
+
+ ld/x86: reduce testsuite dependency on system object files
+ PR ld/30722
+ Tests looking for certain .note-section recorded properties may not
+ involve object files from the underlying platform (e.g. via using the C
+ compiler for linking): Such object files may themselves have similar
+ note sections, and hence they may influence the overall outcome.
+
+ For now convert just the tests known to be affected by crt*.o coming
+ with "ISA v3 needed" notes. Eventually other tests ought to be
+ converted, too.
+
+2023-11-07 Jan Beulich <jbeulich@suse.com>
+
+ Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA"
+ This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1.
+ It wrongly altered testcase expectations; the issue will need
+ taking care of differently.
+
+2023-11-07 Mary Bennett <mary.bennett@embecosm.com>
+
+ RISC-V: Add support for XCValu extension in CV32E40P
+ Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
+
+ Contributors:
+ Mary Bennett <mary.bennett@embecosm.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
+ instruction class.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Added the necessary
+ operands for the extension.
+ (riscv_ip): Likewise.
+ * doc/c-riscv.texi: Noted XCValu as an additional ISA extension
+ for CORE-V.
+ * testsuite/gas/riscv/cv-alu-boundaries.d: New test.
+ * testsuite/gas/riscv/cv-alu-boundaries.l: New test.
+ * testsuite/gas/riscv/cv-alu-boundaries.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-march.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-march.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-march.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
+ * testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
+ * testsuite/gas/riscv/cv-alu-insns.d: New test.
+ * testsuite/gas/riscv/cv-alu-insns.s: New test.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Disassemble xcb operand.
+ * riscv-opc.c: Defined the MASK and added XCValu instructions.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
+ for XCValu.
+ * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
+ for XCValu.
+ (enum riscv_insn_class): Added the XCValu instruction class.
+
+2023-11-07 Mary Bennett <mary.bennett@embecosm.com>
+
+ RISC-V: Add support for XCVmac extension in CV32E40P
+ Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
+
+ Contributors:
+ Mary Bennett <mary.bennett@embecosm.com>
+ Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Pietra Ferreira <pietra.ferreira@embecosm.com>
+ Charlie Keaney
+ Jessica Mills
+ Craig Blackmore <craig.blackmore@embecosm.com>
+ Simon Cook <simon.cook@embecosm.com>
+ Jeremy Bennett <jeremy.bennett@embecosm.com>
+ Helene Chelin <helene.chelin@embecosm.com>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
+ instruction class.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Added the necessary
+ operands for the extension.
+ (riscv_ip): Likewise.
+ * doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
+ for CORE-V.
+ * testsuite/gas/riscv/cv-mac-fail-march.d: New test.
+ * testsuite/gas/riscv/cv-mac-fail-march.l: New test.
+ * testsuite/gas/riscv/cv-mac-fail-march.s: New test.
+ * testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
+ * testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
+ * testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
+ * testsuite/gas/riscv/cv-mac-insns.d: New test.
+ * testsuite/gas/riscv/cv-mac-insns.s: New test.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Disassemble information with
+ the EXTRACT macro implemented.
+ * riscv-opc.c: Defined the MASK and added
+ XCVmac instructions.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
+ for XCVmac.
+ * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
+ for uimm.
+ (enum riscv_insn_class): Added the XCVmac instruction class.
+
+2023-11-07 Tom Tromey <tom@tromey.com>
+
+ Remove EXTERN_C and related defines
+ common-defs.h has a few defines that I suspect were used during the
+ transition to C++. These aren't needed any more, so remove them.
+
+ Tested by rebuilding.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-11-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-06 Carl Love <cel@linux.ibm.com>
+
+ gdb: Update email address for Carl Love in gdb/MAINTAINERS
+
+2023-11-06 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix resizing of TUI python windows
+ When resizing from a big to small terminal size, and you have a
+ TUI python window that would then be outside of the new size,
+ valgrind shows this error:
+
+ ==3389== Invalid read of size 1
+ ==3389== at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
+ ==3389== by 0xC3E3C9: wrefresh (lib_refresh.c:63)
+ ==3389== by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
+ ==3389== by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
+ ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
+ ==3389== by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
+ ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
+ ==3389== by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
+ ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525)
+ ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
+ ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
+ ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
+ ==3389== Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
+ ==3389== at 0x4A0A430: free (vg_replace_malloc.c:446)
+ ==3389== by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
+ ==3389== by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
+ ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525)
+ ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
+ ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
+ ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
+ ==3389== by 0x8E40E9: captured_command_loop() (main.c:407)
+ ==3389== by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
+ ==3389== by 0x62AC04: main (gdb.c:39)
+
+ It's because tui_py_window::m_inner_window still has the outside
+ coordinates, and wnoutrefresh then does an out-of-bounds access.
+
+ Fix this by resetting m_inner_window on every resize, it will anyways
+ be recreated in the next rerender call.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-11-06 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Change gdb.base/examine-backwards.exp for AIX.
+ In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump
+ an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating
+ it cannot access memory.
+
+ This patch is a small change to get it working in AIX as well.
+
+2023-11-06 Nick Clifton <nickc@redhat.com>
+
+ ld: =fillexp different behaviors for hexidecimal literal
+ PR 30865
+ * ld.texi: Update description of the FILL command.
+ * testsuite/ld-scripts/fill2.d: New test.
+ * testsuite/ld-scripts/fill2.t: New test source.
+ * testsuite/ld-scripts/data.exp: Run the new test.
+
+2023-11-06 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase.
+ Same as commit 4352c0ac04a.
+
+ gas/
+ * testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2.
+
+2023-11-06 Nelson Chu <nelson@rivosinc.com>
+ Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Moved out linker internal relocations after R_RISCV_max.
+ Just the lightest modifications about this, without any further checks and
+ considering --emit-relocs. We will need to improve it in the future, but
+ first do this to avoid conflicts between linker internal relocations and the
+ new definition of psabi. For example, TLSDESC relocs.
+
+ Passed riscv-gnu-toolchain regressions, so should be safe enough to commit.
+
+
+ bfd/
+ * reloc.c: Removed linker internal relocations.
+ * bfd-in2.h: Regenerated.
+ * libbfd.h: Regenerated.
+ * elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h.
+ * elfxx-riscv.c (howto_table, howto_table_internal): Moved linker
+ internal relocations from howto_table into howto_table_internal.
+ (riscv_reloc_map): Removed linker internal relocations mapping.
+ (riscv_elf_rtype_to_howto): Return howto of linker internal
+ relocations from howto_table_internal.
+ include/
+ * elf/riscv.h: Defined linker internal relocations after R_RISCV_max.
+
+2023-11-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.exp
+ Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
+ - passes when gdb is configured using $(cd ../src; pwd)/configure, but
+ - fails when using ../src/configure.
+
+ Fix this by making the matching more precise:
+ ...
+ - -re -wrap "$objdir.*" {
+ + -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
+ ...
+ such that we only fail on the line:
+ ...
+ [symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
+ /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
+ ...
+
+ Reported-By: Carl Love <cel@us.ibm.com>
+
+2023-11-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-05 Tom Tromey <tom@tromey.com>
+
+ Pre-read DWZ file in DWARF reader
+ While working on background reading of DWARF, I came across the
+ DWZ-reading code. This code can query the user (via the debuginfod
+ support) -- something that cannot be done off the main thread.
+
+ Looking into it, I realized that this code can be run much earlier,
+ avoiding this problem. Digging a bit deeper, I also found a
+ discrepancy here between how the DWARF reader works in "readnow" mode
+ as compared to the normal modes.
+
+ This patch cleans this up by trying to read the DWZ file earlier, and
+ also by having the DWARF reader convert any exception here into a
+ warning. This unifies the various cases, but also makes it so that
+ errors do not prevent gdb from continuing on to the extent possible.
+
+ Regression tested on x86-64 Fedora 38.
+
+2023-11-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-03 Tom Tromey <tromey@adacore.com>
+
+ Remove unused declaration
+ I found a declaration in py-stopevent.h for which there is no
+ definition. This patch removes it.
+
+2023-11-03 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: mark array_view::slice with [[nodiscard]]
+ I (almost) had a bug where I did:
+
+ buffer.slice (...)
+
+ but I meant:
+
+ buffer = buffer.slice (...)
+
+ The first one does nothing, it creates a new array_view but without
+ using it, it's useless. Mark the slice methods with [[nodiscard]]
+ (which is standard C++17) so that error would generate a warning.
+
+ I guess that many functions could be marked as nodiscard, essentially
+ function that is pure (doesn't have side-effects). But this one seems
+ particularly easy to mis-use.
+
+ Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-03 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: record and print failed selftest names
+ Since "maint selftest" now runs quite a lot of tests (especially in an
+ all-targets build), I thought it would be useful to print a summary at
+ the end of what failed. So, implement that.
+
+ Print the summary before the "Ran %d unit tests, %zu failed\n" line, so
+ that that one remains the last line, and the gdb.gdb/unittest.exp
+ doesn't need to be changed.
+
+ The output looks like (if I force a failure in a test):
+
+ (gdb) maint selftest
+ ...
+ Running selftest value_copy.
+ Running selftest xml_escape_text.
+ Running selftest xml_escape_text_append.
+
+ Failures:
+ aarch64-analyze-prologue
+
+ Ran 4134 unit tests, 1 failed
+ (gdb)
+
+ Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-11-03 Jan Beulich <jbeulich@suse.com>
+
+ gas: correct ignoring of C-style number suffixes
+ First of all the respective original changes didn't deal with just 0
+ having such a suffix - this needs additional logic outside of
+ integer_constant(). Further bogus suffixes having more than two L-s
+ were accepted, while valid suffixes with U following the L(s) weren't.
+ Finally respective tests were introduced for Sparc only.
+
+ Reviewed-by: Neal Frager <neal.frager@amd.com>
+
+2023-11-03 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: reduce redundancy in load/store macro insn handling
+ Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and
+ FS{H,W,D,Q} the sole difference between the handling is the insn
+ mnemonic passed to the common handling functions. The intended mnemonic,
+ however, can easily be retrieved. Furthermore leverags that Sx and FSx
+ are then handled identically, too, and hence their cases can also be
+ folded.
+
+ RISC-V: Lx/Sx macro insn tests
+ Make sure these (continue to) work as intended.
+
+ RISC-V: add F- and D-extension testcases
+ Make sure future changes won't regress any of this. Also cover the FLH
+ and FSH macro insns of the Zfh extension.
+
+ RISC-V: make FLQ/FSQ macro-insns work
+ When support for the Q extension was added, the libopcodes side of these
+ macro-insns was properly covered, but no backing support in gas was
+ added. In new testcases cover not just these, but all Q-extension insns.
+
+2023-11-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix nr array elements in ppc64_aggregate_candidate
+ On AlmaLinux 9.2 powerpc64le I run into:
+ ...
+ (gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector
+ finish^M
+ Run till exit from #0 pck.create_small_float_vector () at pck.adb:30^M
+ 0x00000000100022d4 in p () at p.adb:25^M
+ 25 Vector := Create_Small_Float_Vector;^M
+ Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M
+ (gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector
+ ...
+ while this is expected:
+ ...
+ Value returned is $3 = (4.25, 4.25)^M
+ ...
+
+ The problem is here in ppc64_aggregate_candidate:
+ ...
+ if (!get_array_bounds (type, &low_bound, &high_bound))
+ return -1;
+ count *= high_bound - low_bound
+ ...
+
+ The array type (containing 2 elements) is:
+ ...
+ type Small_Float_Vector is array (1 .. 2) of Float;
+ ...
+ so we have:
+ ...
+ (gdb) p low_bound
+ $1 = 1
+ (gdb) p high_bound
+ $2 = 2
+ ...
+ but we calculate the number of elements in the array using
+ "high_bound - low_bound", which is 1.
+
+ Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous
+ aggregate.
+
+ Fix this by calculating the number of elements in the array by using
+ "high_bound - low_bound + 1" instead.
+
+ Furthermore, high_bound can (in general, though perhaps not here) also be
+ smaller than low_bound, so to be safe take that into account as well:
+ ...
+ LONGEST nr_array_elements = (low_bound > high_bound
+ ? 0
+ : (high_bound - low_bound + 1));
+ count *= nr_array_elements;
+ ...
+
+ Tested on powerpc64le-linux.
+
+ Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
+
+ PR tdep/31015
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015
+
+2023-11-02 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add GCS system registers.
+ This patch adds support for 10 new AArch64 system registers
+ (gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3,
+ gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3),
+ which are enabled on using Guarded Control Stack (+gcs flag)
+ feature.
+
+ aarch64: Add support for GCSB DSYNC instruction.
+ This patch adds support for Guarded control stack data synchronization
+ instruction (GCSB DSYNC). This instruction is allocated to existing
+ HINT space and uses the HINT number 19 and to match this an entry is
+ added to the aarch64_hint_options array.
+
+2023-11-02 srinath <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support for GCS extension.
+ This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
+ optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
+ (eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.
+
+ Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
+ gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.
+
+2023-11-02 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support for Check Feature Status Extension.
+ This patch adds support for Check Feature Status Extension (CHK) which
+ is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
+ (hint #40).
+
+2023-11-02 srinath <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures.
+ This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a)
+ and Armv9.4-A architecture (-march=armv9.4-a).
+
+2023-11-02 Nick Clifton <nickc@redhat.com>
+
+ ld x86_64 tests: Accept x86-64-v3 as a needed ISA
+ * testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3.
+ * testsuite/ld-x86-64/property-4.r: Likewise.
+ * testsuite/ld-x86-64/property-5.r: Likewise.
+
+2023-11-02 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: remove dependency on help2man
+ help2man is no longer used to create the gprofng man pages.
+
+ gprofng/ChangeLog
+ 2023-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * configure.ac: Remove HELP2MAN.
+ * Makefile.in: Rebuild.
+ * configure: Rebuild.
+ * doc/Makefile.in: Rebuild.
+ * gp-display-html/Makefile.in: Rebuild.
+ * src/Makefile.in: Rebuild.
+
+2023-11-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-11-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte>
+ Use the gdb::byte_vector typedef when possible.
+
+ Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a
+
+2023-11-01 Nick Clifton <nickc@redhat.com>
+
+ Fix typo in recent update to the ld/NEWS file
+
+ ld: Support input section description keyword: REVERSE
+ PR 27565
+ * ldlex.l: Add REVERSE.
+ * ldgram.y: Allow REVERSE to be used wherever a sorting command can be used.
+ * ld.h (struct wildcard_spec): Add 'reversed' field.
+ * ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field.
+ * ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field.
+ * ld.texi: Document the new feature.
+ * NEWS: Mention the new feature.
+ * testsuite/ld-scripts/sort-file-reversed-1.d: New test driver.
+ * testsuite/ld-scripts/sort-file-reversed-1.t: New test source.
+ * testsuite/ld-scripts/sort-file-reversed-2.t: New test source.
+ * testsuite/ld-scripts/sort-file-reversed-2.d: New test driver.
+ * testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver.
+ * testsuite/ld-scripts/sort-sections-reversed-1.t: New test source.
+ * testsuite/ld-scripts/sort-sections-reversed-2.t: New test source.
+ * testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver.
+ * testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver.
+ * testsuite/ld-scripts/sort-sections-reversed-3.t: New test source.
+
+2023-11-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Work around gas PR28629
+ When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2
+ ppc64le, I run into:
+ ...
+ FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
+ ...
+
+ The problem is that we get:
+ ...
+ 7 [ No Assembly Available ]
+ ...
+ because tui_get_begin_asm_address doesn't succeed.
+
+ In more detail, tui_get_begin_asm_address calls:
+ ...
+ find_line_pc (sal.symtab, sal.line, &addr);
+ ...
+ with:
+ ...
+ (gdb) p *sal.symtab
+ $5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0,
+ filename = "tui-layout-asm-short-prog.S",
+ filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S",
+ m_language = language_asm, fullname = 0x0}
+ (gdb) p sal.line
+ $6 = 1
+ ...
+
+ The problem is the filename_for_id which is the source file prefixed with the
+ compilation dir rather than the source dir.
+
+ This is due to faulty debug info generated by gas, PR28629:
+ ...
+ <1a> DW_AT_name : tui-layout-asm-short-prog.S
+ <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
+ <22> DW_AT_producer : GNU AS 2.35.2
+ ...
+
+ The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry,
+ making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S.
+
+ The bug is fixed starting version 2.38, where we get instead:
+ ...
+ <1a> DW_AT_name :
+ $gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S
+ <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
+ <22> DW_AT_producer : GNU AS 2.38
+ ...
+
+ Work around the faulty debug info by constructing the filename_for_id using
+ the second directory from the directory table in the .debug_line header:
+ ...
+ The Directory Table (offset 0x22, lines 2, columns 1):
+ Entry Name
+ 0 $gdb/build/gdb/testsuite
+ 1 $gdb/src/gdb/testsuite/gdb.tui
+ ...
+
+ Note that the used gas contains a backport of commit 3417bfca676 ("GAS:
+ DWARF-5: Ensure that the 0'th entry in the directory table contains the
+ current working directory."), because directory 0 is correct. With the
+ unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of
+ entry 1.
+
+ Add a dwarf assembly test-case that reflects the debug info as generated by
+ unpatched gas 2.35.2.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add producer_is_gas
+ Add producer_is_gas, a generic way to get the gas version from the
+ producer string.
+
+ Tested on x86_64-linux.
+
+2023-10-31 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP setVariable request
+ This patch implements the DAP setVariable request.
+
+ setVariable is a bit odd in that it specifies the variable to modify
+ by passing in the variable's container and the name of the variable.
+ This approach can't handle variable shadowing (there are a couple of
+ open DAP bugs on this topic), so this patch renames duplicates to
+ avoid the problem.
+
+2023-10-31 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support Intel USER_MSR
+ This patches aims to support Intel USER_MSR. In addition to the usual
+ support, this patch includes encoding and decoding support for MAP7 and
+ immediate numbers as the last operand (ATT style).
+
+ gas/ChangeLog:
+
+ * NEWS: Support Intel USER_MSR.
+ * config/tc-i386.c (smallest_imm_type): Reject imm32 in 64bit
+ mode.
+ (build_vex_prefix): Add VEXMAP7.
+ (md_assemble): Handling the imm32 of USER_MSR.
+ (match_template): Handling the unusual immediate.
+ * doc/c-i386.texi: Document .user_msr.
+ * testsuite/gas/i386/i386.exp: Run USER_MSR tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/user_msr-inval.l: New test.
+ * testsuite/gas/i386/user_msr-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-user_msr-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-user_msr-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-user_msr-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-user_msr.d: Ditto.
+ * testsuite/gas/i386/x86-64-user_msr.s: Ditto.
+
+ opcodes/ChangeLog:
+ * i386-dis.c (struct instr_info): Add a new attribute
+ has_skipped_modrm.
+ (Gq): New.
+ (Rq): Ditto.
+ (q_mm_mode): Ditto.
+ (Nq): Change mode from q_mode to q_mm_mode.
+ (VEX_LEN_TABLE):
+ (get_valid_dis386): Add VEX_MAP7 in VEX prefix.
+ and handle the map7_f8 for save space.
+ (OP_Skip_MODRM): Set has_skipped_modrm.
+ (OP_E): Skip codep++ when has skipped modrm byte.
+ (OP_R): Support q_mode and q_mm_mode.
+ (REG_VEX_MAP7_F8_L_0_W_0): New.
+ (PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64): Ditto.
+ (X86_64_VEX_MAP7_F8_L_0_W_0_R_0): Ditto.
+ (VEX_LEN_MAP7_F8): Ditto.
+ (VEX_W_MAP7_F8_L_0): Ditto.
+ (MOD_0F38F8): Ditto.
+ (PREFIX_0F38F8_M_0): Ditto.
+ (PREFIX_0F38F8_M_1_X86_64): Ditto.
+ (X86_64_0F38F8_M_1): Ditto.
+ (PREFIX_0F38F8): Remove.
+ (prefix_table): Add PREFIX_0F38F8_M_1_X86_64.
+ Remove PREFIX_0F38F8.
+ (reg_table): Add REG_VEX_MAP7_F8_L_0_W_0,
+ PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64.
+ (x86_64_table): Add X86_64_0F38F8_PREFIX_3_M_1,
+ X86_64_VEX_MAP7_F8_L_0_W_0_R_0 and X86_64_0F38F8_M_1.
+ (vex_table): Add VEX_MAP7.
+ (vex_len_table): Add VEX_LEN_MAP7_F8,
+ VEX_W_MAP7_F8_L_0.
+ (mod_table): New entry for USER_MSR and
+ add MOD_0F38F8.
+ * i386-gen.c (cpu_flag_init): Add CPU_USER_MSR_FLAGS and
+ CPU_ANY_USER_MSR_FLAGS. Add add VEXMAP7.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (SPACE_VEXMAP7): New.
+ (CPU_USER_MSR_FLAGS): Ditoo.
+ (CPU_ANY_USER_MSR_FLAGS): Ditto.
+ (i386_cpu_flags): Add cpuuser_msr.
+ * i386-opc.tbl: Add USER_MSR instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-10-31 Tom Tromey <tom@tromey.com>
+
+ Remove some frame invalidation code
+ I stumbled across a few spots that mention that a function
+ "invalidates frame" and also assignments of NULL to a frame_info_ptr.
+ This code isn't harmful, but is also unnecessary since the
+ introduction of frame_info_ptr -- nowadays frame invalidations are
+ handled automatically.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-30 Nick Clifton <nickc@redhat.com>
+
+ New Georgian translation for the ld sub-directory
+
+2023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: bpf: new test for MOV with C-like numbers ll suffix
+ The BPF pseudo-c syntax supports both MOV and LDDW instructions:
+
+ mov: r1 = EXPR
+ lddw: r1 = EXPR ll
+
+ Note that the white space between EXPR and `ll' is necessary in order
+ to avoid ambiguity with the assembler's support for C-like numerical
+ suffixes. This patch adds a new test to the GAS BPF testsuite to make
+ sure that instructions like:
+
+ r1 = 666ll
+
+ are interpreted as `mov %r1,666', not as `lddw %r1,666'.
+
+ This matches clang's assembler behavior.
+
+ 2023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like
+ suffix `ll' is not interpreted as lddw syntax.
+ * testsuite/gas/bpf/alu-pseudoc.d: Update expected results.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+
+2023-10-30 Tom Tromey <tromey@adacore.com>
+
+ Fix fixed-point "return" on ARM
+ On a big-endian ARM machine, the "return" command resulted in the
+ wrong value being returned when the function had a fixed-point return
+ type. This patch fixes the problem by unpacking and repacking the
+ fixed-point type appropriately.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-10-30 Tom Tromey <tromey@adacore.com>
+
+ Fix range-type "return" command on ARM
+ On big-endian ARM, "return"ing from a function that returned a range
+ type did not work. This patch strips the range type to treat the
+ function as though it were returning the underlying type instead.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-10-30 Tom Tromey <tromey@adacore.com>
+
+ Fix "finish" for vector types on ARM
+ On a big-endian ARM system, "finish" printed the wrong value when
+ finishing from a function that returned a vector type. Similarly,
+ calls to a function also resulted in the wrong value being passed. I
+ think both the read- and write-functions here should ignore the
+ endian-ness.
+
+ I tested this using the AdaCore internal test suite; the test case
+ that caught this is identical to gdb.base/gnu_vector.exp.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-10-30 Tom Tromey <tromey@adacore.com>
+
+ Fix "finish" with range types on ARM
+ On ARM (I tested big-endian but it may not matter), "finish" can
+ sometimes print the wrong result when the return type is a range type.
+ Range types should really be treated as their underlying type
+ (normally integer, but sometimes fixed-point). This patch implements
+ this.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-10-30 Tom Tromey <tromey@adacore.com>
+
+ Fix calls with small integers on ARM
+ On big-endian ARM, an inferior call with a small integer will pass the
+ wrong value. This patch fixes the problem. Because the code here
+ works using scalar values, and not just bytes, left-shifting is
+ unnecessary.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-10-30 Nick Clifton <nickc@redhat.com>
+
+ Accept and ignore the R_BPF_64_NODLYD32 relocation.
+
+2023-10-30 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Update aarch64-sys-regs.def header
+ Given the shared use of the aarch64-sys-regs.def file across Binutils
+ and GCC, add instructions for keeping the file synchronized across the
+ two codebases.
+
+ Namely, it should be made clear that all changes are first to be made
+ in Binutils and the updated file copied across to GCC.
+
+ opcodes/ChangeLog
+
+ * opcodes/aarch64-sys-regs.def: Update file-description header
+ comment.
+
+2023-10-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-29 Tom Tromey <tom@tromey.com>
+
+ Move read_addrmap_from_aranges to new file
+ In the interest of shrinking dwarf2/read.c a little more, this patch
+ moves the code that deciphers .debug_aranges into a new file.
+
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+
+2023-10-29 Tom Tromey <tom@tromey.com>
+
+ Pre-read .debug_aranges section
+ While working on background DWARF reading, I found a race case that I
+ tracked down to the handling of the .debug_aranges section. Currently
+ the section data is only read in after the CUs have all been created.
+ However, there's no real reason to do this -- it seems fine to read it
+ a little earlier, when all the other necessary sections are read in.
+
+ This patch makes this change, and updates the
+ read_addrmap_from_aranges API to assert that the section is read in.
+
+ This patch slightly changes the read_addrmap_from_aranges API as well,
+ to reject an empty section. This seems better to me than what the
+ current code does, which is try to read an empty section but then do
+ no work.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+
+2023-10-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-28 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/gdbsupport/gdbserver: Require c++17
+ This patch proposes to require a C++17 compiler to build gdb /
+ gdbsupport / gdbserver. Before this patch, GDB required a C++11
+ compiler.
+
+ The general policy regarding bumping C++ language requirement in GDB (as
+ stated in [1]) is:
+
+ Our general policy is to wait until the oldest compiler that
+ supports C++NN is at least 3 years old.
+
+ Rationale: We want to ensure reasonably widespread compiler
+ availability, to lower barrier of entry to GDB contributions, and to
+ make it easy for users to easily build new GDB on currently
+ supported stable distributions themselves. 3 years should be
+ sufficient for latest stable releases of distributions to include a
+ compiler for the standard, and/or for new compilers to appear as
+ easily installable optional packages. Requiring everyone to build a
+ compiler first before building GDB, which would happen if we
+ required a too-new compiler, would cause too much inconvenience.
+
+ See the policy proposal and discussion
+ [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).
+
+ The first GCC release which with full C++17 support is GCC-9[2],
+ released in 2019[3], which is over 4 years ago. Clang has had C++17
+ support since Clang-5[4] released in 2018[5].
+
+ A discussions with many distros showed that a C++17-able compiler is
+ always available, meaning that this no hard requirement preventing us to
+ require it going forward.
+
+ [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
+ [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
+ [3] https://gcc.gnu.org/gcc-9/
+ [4] https://clang.llvm.org/cxx_status.html
+ [5] https://releases.llvm.org/
+
+ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-10-28 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/ax_cxx_compile_stdcxx.m4: upgrade
+ This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes
+ available in [1] and regenerates the configure script.
+
+ [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
+
+ Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-10-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: tc-bpf.c: fix formatting of comment
+
+ opcodes: bpf-dis.c: fix typo in comment
+
+2023-10-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: trim trailing spaces in i386-tdep.{c,h}
+ Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df
+
+2023-10-27 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Clarify the behaviors of SET/ADD/SUB relocations.
+ We are used to generate these kinds of relocations by data directives.
+ Considering the following example,
+ .word (A + 3) - (B + 2)
+ The GAS will generate a pair of ADD/SUB for this,
+ R_RISCV_ADD, A + 1
+ R_RISCV_SUB, 0
+
+ The addend of R_RISCV_SUB will always be zero, and the summary of the
+ constants will be stored in the addend of R_RISCV_ADD/SET. Therefore,
+ we can always add the addend of these data relocations when doing relocations.
+
+ But unfortunately, I had heard that if we are using .reloc to generate
+ the data relocations will make the relocations failed. Refer to this,
+ .reloc offset, R_RISCV_ADD32, A + 3
+ .reloc offset, R_RISCV_SUB32, B + 2
+ .word 0
+ Then we can get the relocations as follows,
+ R_RISCV_ADD, A + 3
+ R_RISCV_SUB, B + 2
+ Then... Current LD does the relocation, B - A + 3 + 2, which is wrong
+ obviously...
+
+ So first of all, this patch fixes the wrong relocation behavior of
+ R_RISCV_SUB* relocations.
+
+ Afterwards, considering the uleb128 direcitve, we will get a pair of
+ SET_ULEB128/SUB_ULEB128 relocations for it for now,
+ .uleb128 (A + 3) - (B + 2)
+ R_RISCV_SET_ULEB128, A + 1
+ R_RISCV_SUB_ULEB128, B + 1
+
+ Which looks also wrong obviously, the summary of the constants should only
+ be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should
+ be zero like other SUB relocations. But the current LD will still get the right
+ relocation values since we only add the addend of SUB_ULEB128 by accident...
+ Anyway, this patch also fixes the behaviors above, to make sure that no matter
+ using .uleb128 or .reloc directives, we should always get the right values.
+
+ bfd/
+ * elfnn-riscv.c (perform_relocation): Clarify that SUB relocations
+ should substract the addend, rather than add.
+ (riscv_elf_relocate_section): Since SET_ULEB128 won't go into
+ perform_relocation, we should add it's addend here in advance.
+ gas/
+ * config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of
+ SUB_ULEB128 to zero since it should already be added into the addend
+ of SET_ULEB128.
+
+2023-10-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: Add new gdb.Value.bytes attribute
+ Add a gdb.Value.bytes attribute. This attribute contains the bytes of
+ the value (assuming the complete bytes of the value are available).
+
+ If the bytes of the gdb.Value are not available then accessing this
+ attribute raises an exception.
+
+ The bytes object returned from gdb.Value.bytes is cached within GDB so
+ that the same bytes object is returned each time. The bytes object is
+ created on-demand though to reduce unnecessary work.
+
+ For some values we can of course obtain the same information by
+ reading inferior memory based on gdb.Value.address and
+ gdb.Value.type.sizeof, however, not every value is in memory, so we
+ don't always have an address.
+
+ The gdb.Value.bytes attribute will convert any value to a bytes
+ object, so long as the contents are available. The value can be one
+ created purely in Python code, the value could be in a register,
+ or (of course) the value could be in memory.
+
+ The Value.bytes attribute can also be assigned too. Assigning to this
+ attribute is similar to calling Value.assign, the value of the
+ underlying value is updated within the inferior. The value assigned
+ to Value.bytes must be a buffer which contains exactly the correct
+ number of bytes (i.e. unlike value creation, we don't allow oversized
+ buffers).
+
+ To support this assignment like behaviour I've factored out the core
+ of valpy_assign. I've also updated convert_buffer_and_type_to_value
+ so that it can (for my use case) check the exact buffer length.
+
+ The restrictions for when the Value.bytes can or cannot be written too
+ are exactly the same as for Value.assign.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13267
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle main thread exiting during detach
+ Overview
+ ========
+
+ Consider the following situation, GDB is in non-stop mode, the main
+ thread is running while a second thread is stopped. The user has the
+ second thread selected as the current thread and asks GDB to detach.
+ At the exact moment of detach the main thread exits.
+
+ This situation currently causes crashes, assertion failures, and
+ unexpected errors to be reported from GDB for both native and remote
+ targets.
+
+ This commit addresses this situation for native and remote targets.
+ There are a number of different fixes, but all are required in order
+ to get this functionality working correct for native and remote
+ targets.
+
+ Native Linux Target
+ ===================
+
+ For the native Linux target, detaching is handled in the function
+ linux_nat_target::detach. In here we call stop_wait_callback for each
+ thread, and it is this callback that will spot that the main thread
+ has exited.
+
+ GDB then detaches from everything except the main thread by calling
+ detach_callback.
+
+ After this the first problem is this assert:
+
+ /* Only the initial process should be left right now. */
+ gdb_assert (num_lwps (pid) == 1);
+
+ The num_lwps call will return 0 as the main thread has exited and all
+ of the other threads have now been detached. I fix this by changing
+ the assert to allow for 0 or 1 lwps at this point. As the 0 case can
+ only happen in non-stop mode, the assert becomes:
+
+ gdb_assert (num_lwps (pid) == 1
+ || (target_is_non_stop_p () && num_lwps (pid) == 0));
+
+ The next problem is that we do:
+
+ main_lwp = find_lwp_pid (ptid_t (pid));
+
+ and then proceed assuming that main_lwp is not nullptr. In the case
+ that the main thread has exited though, main_lwp will be nullptr.
+
+ However, we only need main_lwp so that GDB can detach from the
+ thread. If the main thread has exited, and GDB has already detached
+ from every other thread, then GDB has finished detaching, GDB can skip
+ the calls that try to detach from the main thread, and then tell the
+ user that the detach was a success.
+
+ For Remote Targets
+ ==================
+
+ On remote targets there are two problems.
+
+ First is that when the exit occurs during the early phase of the
+ detach, we see the stop notification arrive while GDB is removing the
+ breakpoints ahead of the detach. The 'set debug remote on' trace
+ looks like this:
+
+ [remote] Sending packet: $z0,7f1648fe0241,1#35
+ [remote] Notification received: Stop:W0;process:2a0ac8
+ # At this point an unpatched gdbserver segfaults, and the connection
+ # is broken. A patched gdbserver continues as below...
+ [remote] Packet received: E01
+ [remote] Sending packet: $z0,7f1648ff00a8,1#68
+ [remote] Packet received: E01
+ [remote] Sending packet: $z0,7f1648ff132f,1#6b
+ [remote] Packet received: E01
+ [remote] Sending packet: $D;2a0ac8#3e
+ [remote] Packet received: E01
+
+ I was originally running into Segmentation Faults, from within
+ gdbserver/mem-break.cc, in the function find_gdb_breakpoint. This
+ function calls current_process() and then dereferences the result to
+ find the breakpoint list.
+
+ However, in our case, the current process has already exited, and so
+ the current_process() call returns nullptr. At the point of failure,
+ the gdbserver backtrace looks like this:
+
+ #0 0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982
+ #1 0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093
+ #2 0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372
+ #3 0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498
+ ...
+
+ The problem is that, as a result non-stop being on, the process
+ exiting is only reported back to GDB after the request to remove a
+ breakpoint has been sent. Clearly gdbserver can't actually remove
+ this breakpoint -- the process has already exited -- so I think the
+ best solution is for gdbserver just to report an error, which is what
+ I've done.
+
+ The second problem I ran into was on the gdb side, as the process has
+ already exited, but GDB has not yet acknowledged the exit event, the
+ detach -- the 'D' packet in the above trace -- fails. This was being
+ reported to the user with a 'Can't detach process' error. As the test
+ actually calls detach from Python code, this error was then becoming a
+ Python exception.
+
+ Though clearly the detach has returned an error, and so, maybe, having
+ GDB throw an error would be fine, I think in this case, there's a good
+ argument that the remote error can be ignored -- if GDB tries to
+ detach and gets back an error, and if there's a pending exit event for
+ the pid we tried to detach, then just ignore the error and pretend the
+ detach worked fine.
+
+ We could possibly check for a pending exit event before sending the
+ detach packet, however, I believe that it might be possible (in
+ non-stop mode) for the stop notification to arrive after the detach is
+ sent, but before gdbserver has started processing the detach. In this
+ case we would still need to check for pending stop events after seeing
+ the detach fail, so I figure there's no point having two checks -- we
+ just send the detach request, and if it fails, check to see if the
+ process has already exited.
+
+ Testing
+ =======
+
+ In order to test this issue I needed to ensure that the exit event
+ arrives at the same time as the detach call. The window of
+ opportunity for getting the exit to arrive is so small I've never
+ managed to trigger this in real use -- I originally spotted this issue
+ while working on another patch, which did manage to trigger this
+ issue.
+
+ However, if we trigger both the exit and the detach from a single
+ Python function then we never return to GDB's event loop, as such GDB
+ never processes the exit event, and so the first time GDB gets a
+ chance to see the exit is during the detach call. And so that is the
+ approach I've taken for testing this patch.
+
+ Tested-By: Kevin Buettner <kevinb@redhat.com>
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-10-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.exp
+ If we make writing an index-cache entry very slow by doing this in
+ index_cache::store:
+ ...
+ try
+ {
+ + sleep (15);
+ index_cache_debug ("writing index cache for objfile %s",
+ bfd_get_filename (per_bfd->obfd));
+ ...
+ we run into:
+ ...
+ FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
+ couldn't remove files in temporary cache dir
+ ...
+
+ The FAIL happens because there is no index-cache entry in the cache dir.
+
+ The problem is that gdb is killed (by gdb_exit) before the index-cache entry
+ is written.
+
+ Fix this by using "maint wait-for-index-cache".
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30528
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528
+
+2023-10-26 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itself
+ GCC doesn't complain, but it's still wrong.
+
+2023-10-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-25 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.exp
+ Clang doesn't use CFA information for variable locations. This makes it
+ so software breakpoints get a false hit when rbp gets popped, causing
+ a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with
+ GDB itself, add an xfail to reduce noise.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-25 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix running gdb.python/py-explore-cc with clang
+ The test gdb.python/py-explore-cc.exp was showing one unexpected
+ failure. This was due to how clang mapped instructions to lines,
+ resulting in the inferior seemingly stopping at a different location.
+
+ This patch adds a nop line in the relevant location so we don't need to
+ add XFAILs for existing clang releases, if this gets solved in future
+ versions.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: don't leak program name in handle_v_run
+ I noticed that in handle_v_run (gdbserver/server.cc) we leak
+ new_program_name (a string) each time GDB starts an inferior, in the
+ case where GDB passes a program name to gdbserver.
+
+ This bug was introduced with this commit:
+
+ commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c
+ Date: Wed Apr 13 17:31:02 2022 -0400
+
+ gdbsupport: make gdb_abspath return an std::string
+
+ When gdbserver receives a program name from GDB, this is first placed
+ into a malloc'd buffer within handle_v_run, and this buffer is then
+ used in this call:
+
+ program_path.set (new_program_name);
+
+ Prior to the above commit this call took ownership of the buffer
+ passed to it, but now this call uses the buffer to initialise a
+ std::string, which copies the buffer contents, leaving ownership with
+ the caller. So now, after this call (in handle_v_run)
+ new_program_name still owns a buffer.
+
+ At no point in handle_v_run do we free new_program_name, as a result
+ we are leaking the program name each time GDB starts a remote
+ inferior.
+
+ I could solve this by adding a 'free' call into handle_v_run, but I'd
+ rather automate the memory management.
+
+ So, to this end, I have added a new function in gdbserver/server.cc,
+ decode_v_run_arg. This function takes care of allocating the memory
+ buffer and decoding the vRun packet into the buffer, but returns a
+ gdb::unique_xmalloc_ptr<char> (or nullptr on error).
+
+ Back in handle_v_run I have converted new_program_name to also be a
+ gdb::unique_xmalloc_ptr<char>.
+
+ Now, after we call program_path.set(), the allocated buffer will be
+ automatically released when it is no longer needed.
+
+ It is worth highlighting that within the new decode_v_run_arg
+ function, I have wrapped the call to hex2bin in a try/catch block.
+ The hex2bin function can throw an exception if it encounters an
+ invalid (non-hex) character. Back in handle_v_run, we have a local
+ argument new_argv, which is of type std::vector<char *>. Each
+ 'char *' in this vector is a malloc'd buffer. If we allow
+ hex2bin to throw an exception and don't catch it in either
+ decode_v_run_arg or handle_v_run then we are going to leak memory from
+ new_argv.
+
+ I chose to catch the exception in decode_v_run_arg, this seemed
+ cleanest, but I'm not sure it really matters, so long as the exception
+ is caught before we leave handle_v_run. I am working on a patch that
+ changes new_argv to automatically manage its memory, but that isn't
+ ready for posting yet. I think what I have here would be fine if my
+ follow on patch never arrives.
+
+ Additionally, within the handle_v_run loop I have changed an
+ assignment of nullptr to new_program_name into an assert. Previously,
+ the assignment could only trigger on the first iteration of the loop,
+ if we had no new program name to assign. However, new_program_name
+ always starts as nullptr, so, on the first loop iteration, if we have
+ nothing to assign to new_program_name, its value must already be
+ nullptr.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make get_symbol_address a private method of symbol
+ get_symbol_address is only used symbol::value_address, make it a private
+ helper method.
+
+ Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make get_msymbol_address a private method of minimal_symbol
+ get_msymbol_address is only used in minimal_symbol::value_address. Make
+ it a private helper method.
+
+ Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Fix -Wformat= warnings
+ Added format attribute to several gprofng functions.
+ Fixed -Wformat= warnings.
+
+ gprofng/ChangeLog
+ 2023-10-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * libcollector/heaptrace.c: Fixed -Wformat= warnings.
+ * libcollector/hwprofile.c: Likewise.
+ * libcollector/iolib.c: Likewise.
+ * libcollector/iotrace.c: Likewise.
+ * libcollector/jprofile.c: Likewise.
+ * libcollector/profile.c: Likewise.
+ * libcollector/synctrace.c: Likewise.
+ * src/ClassFile.cc: Likewise.
+ * src/SourceFile.cc: Likewise.
+ * libcollector/libcol_util.h: Added format attribute.
+ * src/Emsg.h: Likewise.
+ * src/collector_module.h: Likewise.
+ * src/data_pckts.h: Define fld_sizeof.
+
+2023-10-25 Alan Modra <amodra@gmail.com>
+
+ asan: _bfd_elf_slurp_version_tables memory leak
+ Extends commit 6136093c0d00 to handle verdefs as well as verrefs.
+
+ PR 30886
+ * elf.c (_bfd_elf_slurp_version_tables): See free_contents for
+ verdefs too. Use free_contents rather than elf_tdata fields.
+
+2023-10-25 Alan Modra <amodra@gmail.com>
+
+ asan: out of memory in som_set_reloc_info
+ Sections without SEC_HAS_CONTENTS avoid the file size checks, and of
+ course it doesn't make sense to read such as the contents are all
+ zero.
+
+ * som.c (som_set_reloc_info): Don't read sections without contents.
+
+2023-10-25 Alan Modra <amodra@gmail.com>
+
+ asan: NULL deref in alpha_ecoff_get_relocated_section_contents
+ This fixes some holes found by fuzzers, and removes aborts that can be
+ triggered by user input to objdump. Abort should only be used within
+ bfd to show programming errors in bfd.
+
+ * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle
+ NULL howto. Don't abort on stack errors or on unexpected relocs.
+ Show more bfd reloc status messages.
+
+2023-10-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Add gnu-source-highlight selftest
+ Add a selftest gnu-source-highlight:
+ ...
+ $ gdb -q -batch -ex "maint selftest gnu-source-highlight"
+ Running selftest gnu-source-highlight.
+ Ran 1 unit tests, 0 failed
+ ...
+
+ Tested on x86_64-linux.
+
+2023-10-24 Tom de Vries <tdevries@suse.de>
+
+ [readelf] Handle unknown name of main in .gdb_index section
+ When compiling hello world and adding a v9 .gdb-index section:
+ ...
+ $ gcc -g hello.c
+ $ gdb-add-index a.out
+ ...
+ readelf shows it as:
+ ...
+ Shortcut table:
+ Language of main: unknown: 0
+ Name of main: ^A
+ ...
+
+ The documentation of gdb says about the "Name of main" that:
+ ...
+ This value must be ignored if the value for the language of main is zero.
+ ...
+
+ Implement this approach in display_gdb_index, such that we have instead:
+ ...
+ Shortcut table:
+ Language of main: unknown: 0
+ Name of main: <unknown>
+ ...
+
+ Tested on x86_64-linux.
+
+ Approved-By: Jan Beulich <jbeulich@suse.com>
+
+2023-10-24 Lulu Cai <cailulu@loongson.cn>
+
+ as: fixed internal error when immediate value of relocation overflow.
+ The as and ld use _bfd_error_handler to output error messages when
+ checking relocation alignment and relocation overflow. However, the
+ abfd value passed by as to the function is NULL, resulting in an
+ internal error. The ld passes a non-null value to the function,
+ so it can output an error message normally.
+
+2023-10-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Only include gdbsupport/selftest.h if GDB_SELF_TEST
+ I noticed that gdb/python/python.c unconditionally includes
+ gdbsupport/selftest.h.
+
+ Make this conditional on GDB_SELF_TEST.
+
+ Tested on x86_64-linux.
+
+2023-10-23 Jan Beulich <jbeulich@suse.com>
+
+ gas: make .nops output visible in listing
+ Due to using a different frag type (in turn due to storing data
+ differently), making the resulting code appear in listings requires
+ special handling.
+
+ x86: fold NOP testcase expectations where possible
+ Like done earlier for files needing adjustment anyway, also do this for
+ the remaining set.
+
+ x86: fold a few of the "alternative" NOP patterns
+ Since named objects may not overlap, the compiler is not permitted to do
+ this for us, to avoid wasting space and cache bandwidth/capacity.
+
+2023-10-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: add a few more NOP patterns
+ First of all add f32_5[], allowing to eliminate the extra slot-is-NULL
+ code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[]
+ following the same concept of adding a %cs segment override prefix.
+
+ Also re-use patterns when possible and correct comments as applicable.
+ Similarly re-use testcase expectations as much as possible, where they
+ need touching anyway.
+
+2023-10-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't record full i386_cpu_flags in struct i386_tc_frag_data
+ We only use a single bit of this ever growing structure.
+
+2023-10-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: i686 != PentiumPro
+ The two are distinct in opcodes/, distinguished precisely by CpuNOP
+ that's relevant in i386_generate_nops(), yet the function has the PPro
+ case label in the other group. Simply removing it revealed that
+ cpu_arch[] had a wrong entry for i686.
+
+ While there also add PROCESSOR_IAMCU to the respective comment.
+
+2023-10-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: respect ".arch nonop" when selecting which NOPs to emit
+ Making GENERIC64 a special case was never correct; prior to the
+ generalization of ".arch .no*" to cover all ISA extensions other
+ processor families supporting long NOPs should have been covered as
+ well. When introducing ".arch .nonops" (among others) it wasn't
+ apparent that a hidden implication of .cpunop not being possible to
+ separately turn off existed here. Seeing that the two large case label
+ blocks in the 2nd switch() already had identical behavior, simply
+ collapse all of the (useful) case labels into a single "default" one.
+
+ x86: don't use operand size override with NOP in 16-bit code
+ Since we don't key the NOP selection to user-controlled properties, we
+ may not use i386 features; otherwise we would violate a possible .arch
+ directive restricting ISA to pre-386.
+
+ x86: don't use 32-bit LEA as NOP surrogate in 64-bit code
+ Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi
+ (by zero-extending %esi to %rsi). Introduce separate 64-bit patterns
+ which keep %rsi intact.
+
+ x86: i386_generate_nops() may not derive decisions from global variables
+ What matters is what was in effect at the time the original directive
+ was issued. Later changes to global state (bitness or ISA) must not
+ affect what code is generated.
+
+ x86: record flag_code in tc_frag_data
+ The recorded value, and not the global variable, will want using in
+ TC_FRAG_INIT(). The so far file scope variable therefore needs to become
+ external, to be accessible there.
+
+2023-10-23 Clément Chigot <chigot@adacore.com>
+
+ objcopy: fix typo in --heap and --stack parser
+ The help says that <reserve> and <commit> should be separated by a ","
+ but the implementation is checking for ".". Having two numbers being
+ separated by a "." could be confusing, thus adjust the implementation to
+ match the help syntax.
+
+ binutils/ChangeLog:
+
+ * objcopy.c (copy_main): Set separator to "," between <reserve>
+ and <commit> for --heap and --stack.
+ * doc/binutils.texi: Add <commit> for --heap and --stack.
+
+2023-10-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-23 Alan Modra <amodra@gmail.com>
+
+ bfd-in2.h BFD_RELOC_* comments
+ I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't
+ match that committed to bfd-in2.h, and was just going to regen
+ bfd-in2.h but then decided to do something about the silly formatting
+ of these comments in bfd-in2.h. eg. the BFD_RELOC_MICROBLAZE_32_NONE
+ comment:
+
+ -/* This is a 32 bit reloc that stores the 32 bit pc relative
+ -value in two words (with an imm instruction).No relocation is
+ -done here - only used for relaxing */
+ + /* This is a 32 bit reloc that stores the 32 bit pc relative value in
+ + two words (with an imm instruction). No relocation is done here -
+ + only used for relaxing. */
+ BFD_RELOC_MICROBLAZE_32_NONE,
+
+ You'll notice how the second and third line of the original comment
+ aren't indented properly relative to the first line, and the whole
+ comment needs to be indented to match the code.
+
+ I've also edited reloc.c ENUMDOC paragraphs. Some of these had excess
+ indentation, presumably in an attempt to properly indent bfd-in2.h
+ comments but that fails due to chew.c removing leading whitespace
+ early by skip_white_and_stars. COMMENT was used in reloc.c to add
+ extra blank lines in bfd-in2.h. I've removed them too as I don't
+ think they add anything to readability of that file. (Perhaps more
+ usefully, they also add blank lines to libbfd.h separating relocs for
+ one target from others, but this isn't done consistently.)
+
+ * doc/chew.c (drop, idrop): Move earlier.
+ (strip_trailing_newlines): Check index before accessing array,
+ not after.
+ (wrap_comment): New function.
+ (main): Add "wrap_comment" intrinsic.
+ * doc/proto.str (ENUMDOC): Use wrap_comment.
+ (make_enum_header, ENDSENUM): Put start and end braces on
+ separate lines.
+ * reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs.
+ * libbfd.h: Regenerate.
+ * bfd-in2.h: Regenerate.
+
+2023-10-22 Tom Tromey <tom@tromey.com>
+
+ Style history variable output
+ When printing a value, I think the history reference -- the "$1" in
+ the output -- should be styled using the "variable" style. This patch
+ implements this.
+
+2023-10-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix owner passed to remove_target_sections in clear_solib
+ Commit 8971d2788e7 ("gdb: link so_list using intrusive_list") introduced
+ a bug in clear_solib. Instead of passing an `so_list *` to
+ remove_target_sections, it passed an `so_list **`. This was not caught
+ by the compiler, because remove_target_sections takes a `void *` as the
+ "owner", so you can pass it any pointer and it won't complain.
+
+ This happened because I previously had a patch to change the type of the
+ disposer parameter to be a reference rather than a pointer, so had to
+ change `so` to `&so`. When dropping that patch, I forgot to revert this
+ bit and / or it got re-introduced when handling subsequent merge
+ conflicts. And I didn't properly retest.
+
+ Fix that, but try to make things less error prone. Add a union to
+ represent the possible owner kinds for a target_section. Trying to pass
+ a pointer to another type than those will not compile.
+
+ Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c
+
+2023-10-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Allow source-highlight to autodetect language
+ Currently when gdb asks the source-highlight library to highlight a file, it
+ tells it what language file to use.
+
+ For instance, if gdb learns from the debug info that the file is language_c,
+ the language file "c.lang" is used. This mapping is hardcoded in
+ get_language_name.
+
+ However, if gdb doesn't know what language file to use, it falls back to using
+ python pygments, and in absence of that, unhighlighted source text.
+
+ In the case of python pygments, it autodetects which language to use based on
+ the file name.
+
+ Add the same capability when using the source-highlight library.
+
+ Tested on x86_64-linux.
+
+ Verified that it works by:
+ - making get_language_name return nullptr for language_c, and
+ - checking that source-highlight still manages to highlight a hello world.
+
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR cli/30966
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
+
+2023-10-20 Tom Tromey <tom@tromey.com>
+
+ Don't include cooked-index.h from dwarf2/read.h
+ dwarf2/read.h includes cooked-index.h, but it doesn't need to. This
+ patch removes the inclusion from this header, and adds one to
+ index-write.c to make up for the absence.
+
+2023-10-20 Neal Frager <neal.frager@amd.com>
+
+ gas: testsuite: microblaze: cosmetic fix
+ This patch makes a cosmetic change to the reloc_weaksym.s
+ by making the bneid instruction all lower case like all of
+ the other instructions in the example.
+
+2023-10-20 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: fix creation-time parent/child dict confusions
+ The fixes applied a few years ago to resolve confusions between parent and
+ child dicts at lookup time also apply in various forms to creation. In
+ general, if you have a type in a parent dict ctf_imported into a child and
+ you do something to it, and the parent dict is writable (created via
+ ctf_create, not opened via ctf_open*) it should work just the same to make
+ changes to that type via a child dict as it does to make the change
+ to the parent dict directly -- and nothing you're prohibited from doing
+ to the parent dict when done directly should be allowed just because
+ you're doing it via a child.
+
+ Specifically, the following don't work when doing things from the child, but
+ should:
+
+ - adding a member of a type in the parent to a struct or union in the
+ parent via ctf_add_member or ctf_add_member_offset: this yields
+ ECTF_BADID
+
+ - adding a member of a type in the parent to a struct or union in the
+ parent via ctf_add_member_encoded: this dumps core (!).
+
+ - adding an enumerand to an enumerator in the parent: this yields
+ ECTF_BADID
+
+ - setting the properties of an array in the parent via ctf_set_array;
+ this yields ECTF_BADID
+
+ Relatedly, some things work when doing things via a child that should fail,
+ yielding a CTF dictionary with invalid content (readable, but meaningless):
+ in particular, you can add a child type to a struct in the parent via
+ any of the ctf_add_member* family and nothing complains at all, even though
+ you should never be able to add references to children to parents (since any
+ given parent can be associated with many different children).
+
+ A family of tests is added to check each of these cases independently, since
+ some can result in coredumps and it would be nice to test the other cases
+ even if some dump core. They use a common library to do all the actual
+ work. The set of affected API calls was determined by code inspection
+ (auditing all calls to ctf_dtd_lookup): it's possible that I missed a few,
+ but I doubt it, since other cases use ctf_lookup* functions, which already
+ climb to the parent where appropriate.
+
+ libctf/ChangeLog:
+
+ PR libctf/30985
+ * ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary.
+ (ctf_set_array): Likewise. Report errors on the child; require
+ both parent and child to be writable.
+ (ctf_add_enumerator): Likewise.
+ (ctf_add_member_offset): Likewise. Prohibit addition of child types
+ to structs in the parent.
+ (ctf_add_member_encoded): Do not dereference a NULL dtd: report
+ ECTF_BADID instead.
+ * ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the
+ dict if addition of a string ref fails.
+ * testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library.
+ * testsuite/libctf-writable/parent-child-dtd-enum.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-set-array.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-struct.*: New test.
+ * testsuite/libctf-writable/parent-child-dtd-union.*: New test.
+
+2023-10-20 Neal Frager <neal.frager@amd.com>
+
+ bfd: microblaze: Add 32_NONE reloc type
+ This patch adds the R_MICROBLAZE_32_NONE relocation type.
+ This is a 32-bit reloc that stores the 32-bit pc relative
+ value in two words (with an imm instruction).
+
+ Add test case to gas test suite.
+
+2023-10-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix more style issues in v9 .gdb_index section support
+ I noticed a few more style issues in commit 8b9c08eddac ("[gdb/symtab] Add
+ name_of_main and language_of_main to the DWARF index"), after checking it
+ with gcc's check_GNU_style.{sh,py}.
+
+ Fix these.
+
+ Build on x86_64-linux.
+
+2023-10-20 Neal Frager <neal.frager@amd.com>
+
+ opcodes: microblaze: Fix bit masking bug
+ There is currently a bug in the bit masking for the barrel shift
+ instructions because the bit mask is not including all of the
+ register bits which must be zero. With this patch, the disassembler
+ can be sure that the 32-bit value is indeed a barrel shift instruction
+ and not a data value in memory.
+
+ This fix can be verified by assembling and disassembling the following:
+
+ .text
+ .long 0x65005f5f
+
+ With this patch, the bug is fixed, and the objdump will know that
+ 0x65005f5f is not a barrel shift instruction.
+
+2023-10-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-19 Tom Tromey <tom@tromey.com>
+
+ Fix race in DWARF reader
+ The recent change to record the DWARF language in the per-CU data
+ yielded a race warning in my testing:
+
+ ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit
+
+ This patch fixes the bug by applying the same style of fix that was
+ done for the ordinary (gdb) language.
+
+ I wonder if this code could be improved. Requiring an atomic for the
+ language in particular seems unfortunate, as it is often consulted
+ during index finalization. However, I haven't investigated this.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Reviewed-by: Tom de Vries <tdevries@suse.de>
+
+2023-10-19 Alan Modra <amodra@gmail.com>
+
+ PR30984, assertion fail elf.c:8485
+ PR 30984
+ * ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as
+ a potential output section.
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix no-expat build of solib-target.c
+ Fixes:
+
+ CXX solib-target.o
+ /home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type
+ 57 | static lm_info_vector
+ | ^~~~~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’:
+ /home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope
+ 244 | = solib_target_parse_libraries (library_document->data ());
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Change-Id: Ib477d3343b401017d79729118242143bc95f24b2
+
+2023-10-19 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ ld: fix typo in ld.texi metdata->metadata
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename struct so_list to shobj
+ Now that so_list lists are implemented using intrusive_list, it doesn't
+ really make sense for the element type to be named "_list". Rename to
+ just `struct shobj` (`struct so` was deemed to be not greppable enough).
+
+ Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove free_so function
+ Remove this function, replace it with deleting the so_list in callers.
+
+ Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: don't call so_list::clear in free_so
+ I think this `so.clear ()` call is not useful.
+
+ - so_list::clear deletes some things that now get automatically deleted
+ when the so_list gets deleted right after in free_so.
+ - so_list::clear resets some scalar fields of so_list, which we don't
+ really care about since the so_list gets deleted right after.
+ - so_list::clear calls target_so_ops::clear_so, of which there is a
+ single implementation, svr4_clear_so. That implementation just
+ resets a field in lm_info_svr4, which we don't care about, as it will
+ get deleted when the so_list gets deleted right after.
+
+ Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: link so_list using intrusive_list
+ Replace the hand-made linked list implementation with intrusive_list,
+ simplying management of list items.
+
+ Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make so_list::{so_original_name,so_name} std::strings
+ Change these two fields, simplifying memory management and copying.
+
+ Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make so_list::abfd a gdb_bfd_ref_ptr
+ Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically
+ manage the reference.
+
+ Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make so_list::sections not a pointer
+ Make the field a vector directly, instead of a pointer to a vector.
+ This was needed when so_list had to be a trivial type, which is not the
+ case anymore.
+
+ Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove target_section_table typedef
+ Remove this typedef. I think that hiding the real type (std::vector)
+ behind a typedef just hinders readability.
+
+ Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make clear_so a method of struct so_list
+ ... just because it seems to make sense to do so.
+
+ Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make so_list::lm_info a unique_ptr
+ Make it a unique_ptr, so it gets automatically deleted when the so_list
+ is deleted.
+
+ Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove lm_info_vector typedef
+ I think this typedef hinders readability. First, it's not well named
+ (it's not clear it contains lm_info_target objects). And hiding the
+ fact that it contains unique pointers is not very useful either. I was
+ looking at the code in solib_target_current_sos where the unique
+ pointers get moved from the vector, and it wasn't obvious at all what
+ the source of the move was.
+
+ Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make solib-rocm not use so_list internally
+ Same rationale as the previous patch, but for solib-rocm.
+
+ - Introduce rocm_so, which is a name a unique_name (see comment in
+ rocm_update_solib_list for that) and a unique_ptr to the
+ lm_info_svr4.
+ - Change the internal lists from so_list lists to vectors of rocm_so.
+ - Remove rocm_free_solib_list, as everything is automatic now.
+ - Replace rocm_solib_copy_list with so_list_from_rocm_sos.
+
+ Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make solib-svr4 not use so_list internally
+ A subsequent patch makes use of non-trivial types in struct so_list.
+ This trips on the fact that svr4_copy_library_list uses memcpy to copy
+ so_list objects:
+
+ so_list *newobj = new so_list;
+ memcpy (newobj, src, sizeof (struct so_list));
+
+ solib-svr4 maintains lists of so_list objects in its own internal data
+ structures. When requested to return a list of so_list objects (through
+ target_so_ops::current_sos), it duplicates the internal so_list lists,
+ using memcpy. When changing so_list to make it non-trivial, we would
+ need to replace this use of memcpy somehow. That would mean making
+ so_list copyable, with all the complexity that entails, just to satisfy
+ this internal usage of solib-svr4 (and solib-rocm, which does the same).
+
+ Change solib-svr4 to use its own data type for its internal lists. The
+ use of so_list is a bit overkill anyway, as most fields of so_list are
+ irrelevant for this internal use.
+
+ - Introduce svr4_so, which contains just an std::string for the name
+ and a unique_ptr for the lm_info.
+ - Change the internal so_list lists to be std::vector<svr4_so>. Vector
+ seems like a good choice for this, we don't need to insert/remove
+ elements in the middle of these internal lists.
+ - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
+ everything is managed automatically now.
+ - Replace svr4_copy_library_list (which duplicated internal lists in
+ order to return them to the core) with so_list_from_svr4_sos, which
+ creates an so_list list from a vector of svr4_so.
+ - Generalize svr4_same a bit, because find_debug_base_for_solib now
+ needs to compare an so_list and an svr4_so to see if they are the
+ same.
+
+ Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use gdb::checked_static_cast when casting lm_info
+ Now that the lm_info class hierarchy has a virtual destructor and
+ therefore a vtable, use checked_static_cast instead of C-style cases to
+ ensure (when building in dev mode) that we're casting to the right kind
+ of lm_info.
+
+ Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove target_so_ops::free_so
+ target_so_ops::free_so is responsible for freeing the specific lm_info
+ object. All implementations basically just call delete. Remove that
+ method, make the destructor of lm_info virtual, and call delete directly
+ from the free_so function. Make the sub-classes final, just because
+ it's good practice.
+
+ Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename lm_info_base to lm_info
+ The base class doesn't need to have "_base" in its name, all the
+ sub-classes have a specific suffix.
+
+ Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: allocate so_list with new, deallocate with delete
+ Initialize all fields in the class declaration, change allocations to
+ use "new", change deallocations to use "delete". This is needed by a
+ subsequent patches that use C++ stuff in so_list.
+
+ Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make get_cbfd_soname_build_id static
+ It is only used in solib.c.
+
+ Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: use "reference" and "pointer" type aliases in intrusive_list
+ It seems to me like the code should used the defined type aliases, for
+ consistency.
+
+ Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: replace some so_list parameters to use references
+ A subsequent patch changes so_list to be linked using
+ intrusive_list. Iterating an intrusive_list yields some references to
+ the list elements. Convert some functions accepting so_list objects to
+ take references, to make things easier and more natural. Add const
+ where possible and convenient.
+
+ Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make interps_notify work with references
+ A subsequent patch changes the interp::on_solib_loaded and
+ interp::on_solib_unloaded methods to take references. This highlighted
+ that interps_notify did not work with reference parameters.
+
+ Fix that by changing interps_notify's `args` arg to be a universal
+ reference (&&). Change the type of the method to be auto-deduced as an
+ additional template parameter, otherwise the signature of the callback
+ function would never match:
+
+ CXX interps.o
+ /home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’:
+ /home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’
+ 378 | interps_notify (&interp::on_signal_received, sig);
+ | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’
+ 363 | interps_notify (void (interp::*method) (Args...), Args&&... args)
+ | ^~~~~~~~~~~~~~
+ /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: template argument deduction/substitution failed:
+ /home/simark/src/binutils-gdb/gdb/interps.c:378:18: note: inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’
+ 378 | interps_notify (&interp::on_signal_received, sig);
+ | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add program_space parameter to target_so_ops::clear_solib
+ The clear_solib is implicitly meant to clear the resources associated to
+ the current program space (that's what the solib implementations that
+ actually support multi-program-space / multi-inferior do). Make that
+ explicit by adding a program_space parameter and pass down
+ current_program_space in call sites. The implementation of the
+ clear_solib callbacks is fairly simple, I don't think any of them rely
+ on global state other than accessing current_program_space.
+
+ Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove empty clear_solib functions
+ Make the target_so_ops::clear_solib method optional, remove two empty
+ implementations.
+
+ Change-Id: Ifda297d50c74327d337091c58cdb5b3b60382591
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-19 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Don't do undefweak relaxations for the linker_def symbols.
+ I get the following truncated errors recently when running riscv-gnu-toolchain
+ regressions,
+
+ /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/libc.a(libc-start.o): in function `elf_irela':
+ /scratch/riscv-gnu-toolchain/glibc/csu/../sysdeps/riscv/dl-irel.h:47:(.text+0x88): relocation truncated to fit: R_RISCV_GPREL_I against symbol `__ehdr_start' defined in .note.ABI-tag section in /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/elf/sln
+
+ The linker_def symbols like __ehdr_start that may be undefweak in early stages
+ of linking, including relax stage, but are guaranteed to be defined later.
+ Therefore, it seems like we shouldn't do the undefweak relaxations for these
+ kinds of symbols since they may be defined after relaxations.
+
+ bfd/
+ * elfnn-riscv.c (_bfd_riscv_relax_section): Don't do undefweak
+ relaxations for the linker_def symbols.
+
+2023-10-19 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove semicolons from DECLARE_INSN
+ This is for consistency and to prevent possible unnecessary errors due
+ to this inconsistency.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (DECLARE_INSN): Remove semicolons from the
+ end of each entry.
+
+2023-10-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-18 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp
+ The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
+ command, but this is incorrect. If "continue" is given an argument, it
+ sets the ignore count of the breakpoint the thread stopped at.
+
+ For this testcase it does not really matter since the breakpoint is not
+ meant to be hit anymore, so whatever the ignore count is won't influence
+ the outcome of the test. It is worth fixing nevertheless.
+
+ Change-Id: I0eb674d5529cdeb9e808b74870a29b6077265737
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-18 Jaydeep Patil <Jaydeep.Patil@imgtec.com>
+
+ sim/riscv: fix JALR instruction simulation
+ Fix 32bit 'jalr rd,ra,imm' integer instruction, where RD was written
+ before using it to calculate destination address.
+
+ This commit also improves testutils.inc for riscv; make use of
+ pushsection and popsection when adding things to .data, and setup the
+ %gp global pointer register within the 'start' macro.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-18 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: check for problems with error returns
+ We do this as a writable test because the only known-affected platforms
+ (with ssize_t longer than unsigned long) use PE, and we do not have support
+ for CTF linkage in the PE linker yet.
+
+ PR libctf/30836
+ * libctf/testsuite/libctf-writable/libctf-errors.*: New test.
+
+2023-10-18 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/testsuite/gdb.rocm: Check value returned by hipDeviceSynchronize
+ Functions of the hip runtime returning a hipError_t can be marked
+ nodiscard depending on the configuration[1] (when compiled with C++17).
+
+ This patch makes sure that we always check the value returned by
+ hipDeviceSynchronize and friends, and print an error message when
+ appropriate. This avoid a wall of warnings when running the testsuite
+ if the compiler defaults to using C++17.
+
+ It is always a good practice to check the return values anyway.
+
+ [1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218
+
+ Change-Id: I2a819a8ac45f4bcf814efe9a2ff12c6a7ad22f97
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-18 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ libctf: Return CTF_ERR in ctf_type_resolve_unsliced PR 30836
+ In commit 998a4f589d68503f79695f180fdf1742eeb0a39d, all but one return
+ statement was updated to return the error proper value. This commit
+ rectifies that missed return statement.
+
+ libctf/
+ ctf-types.c (ctf_type_resolve_unsliced): Return CTF_ERR on error.
+
+2023-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/jit-bfd-name.exp
+ When running test-case gdb.base/jit-bfd-name.exp, I run into:
+ ...
+ ERROR: tcl error sourcing gdb/testsuite/gdb.base/jit-bfd-name.exp.
+ ERROR: can't read "start": no such variable
+ ...
+
+ The problem is that commit c96ceed9dce ("gdb: include the end address in
+ in-memory bfd filenames") introduced a use of variable start, but not a
+ definition.
+
+ Fix this by adding the missing definition.
+
+ Tested on x86_64-linux.
+
+2023-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix two style issues in gdb/dwarf2/index-write.c
+ While reviewing gdb/dwarf2/index-write.c I noticed two style issues.
+
+ Fix these.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix style issues in v9 .gdb_index section support
+ Post-commit review pointed out a few style issues in commit 8b9c08eddac
+ ("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index").
+
+ Fix these.
+
+ Tested on x86_64-linux.
+
+ Reported-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-18 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Make sure rv32q conflict won't affect the zfa gas testcases.
+ According to the commit 51498ab9abc6, the q extension was no longer allowed
+ for rv32 since version 2.2. Therefore, make sure the version of q is larger
+ than 2.2, in case the new extension conflict breaks the toolchain regressions,
+ which built with the old -misa-spec.
+
+ gas/
+ * testsuite/gas/riscv/zfa-zvfh.d: Set q to v2.2.
+ * testsuite/gas/riscv/zfa.d: Likewise.
+
+2023-10-18 caiyinyu <caiyinyu@loongson.cn>
+
+ LoongArch: Correct comments.
+
+2023-10-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-17 Neal Frager <neal.frager@amd.com>
+
+ gas: testsuite: microblaze: Add new bit-field tests
+ This patch adds new gas tests for the
+ microblaze bsefi and bsifi instructions.
+
+2023-10-17 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb: include the end address in in-memory bfd filenames
+ Commit
+
+ 66984afd29e gdb: include the base address in in-memory bfd filenames
+
+ added the base address to in-memory bfd filenames. Also add the end
+ address to allow dumping the in-memory bfd using the 'dump memory'
+ command.
+
+2023-10-17 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ libctf: Sanitize error types for PR 30836
+ Made sure there is no implicit conversion between signed and unsigned
+ return value for functions setting the ctf_errno value.
+ An example of the problem is that in ctf_member_next, the "offset" value
+ is either 0L or (ctf_id_t)-1L, but it should have been 0L or -1L.
+ The issue was discovered while building a 64 bit ld binary to be
+ executed on the Windows platform.
+ Example object file that demonstrates the issue is attached in the PR.
+
+ libctf/
+ Affected functions adjusted.
+
+ Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>
+
+2023-10-17 Nick Clifton <nickc@redhat.com>
+
+ Update the documentation of the LINKER_VERSIOn script command to actually mention the name of the command.
+
+2023-10-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Keep track of styling failures in source_cache
+ In source_cache::ensure, keep track of which files failed to be styled, and
+ don't attempt to style them again in case the file dropped out of the cache.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Factor out try_source_highlight
+ Function source_cache::ensure contains some code using the GNU
+ source-highlight library.
+
+ The code is a sizable part of the function, and contains conditional
+ compilation in a slightly convoluted way:
+ ...
+ if (!already_styled)
+ #endif /* HAVE_SOURCE_HIGHLIGHT */
+ {
+ ...
+
+ Fix this by factoring out the code into new function try_source_highlight,
+ such that:
+ - source_cache::ensure is easier to read, and
+ - the conditional compilation is at the level of the function body.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Skip string copy in source_cache::ensure
+ In function source_cache::ensure we have:
+ ...
+ std::ostringstream output;
+ ...
+ contents = output.str ();
+ ...
+ The last line causes an unnecessary string copy.
+
+ C++20 allows us to skip it, like this:
+ ...
+ contents = std::move (output).str ();
+ ...
+
+ Use the more efficient solution.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-10-17 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: readelf -d RELASZ excludes .rela.plt size
+ Before, readelf -d RELASZ is the sum of .rela.dyn size and .rela.plt size.
+ To consistent with LoongArch lld, RELASZ chang to only the size of .rela.dyn.
+
+2023-10-17 Alan Modra <amodra@gmail.com>
+
+ asan: Invalid free in alpha_ecoff_get_relocated_section_contents
+ This fixes an ancient bug in commit a3a33af390 (which makes me think
+ this code has never been used).
+
+ * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Iterate
+ through reloc_vector using a temp.
+
+2023-10-17 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix typo
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h: Fix typo.
+
+2023-10-17 John Baldwin <jhb@FreeBSD.org>
+
+ nat/x86-cpuid.h: Remove non-x86 fallbacks
+ This header is only suitable for use on x86 hosts and is only included
+ there, so these fallbacks should not be needed.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-16 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unnecessary declarations in target.c
+ I found that these local declarations were not needed, remove them.
+ Tested by rebuilding.
+
+ Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22
+
+2023-10-16 Tom Tromey <tromey@adacore.com>
+
+ Have DAP handle non-Value results from 'children'
+ A pretty-printer's 'children' method may return values other than a
+ gdb.Value -- it may return any value that can be converted to a
+ gdb.Value.
+
+ I noticed that this case did not work for DAP. This patch fixes the
+ problem.
+
+2023-10-16 Tom Tromey <tromey@adacore.com>
+
+ Handle gdb.LazyString in DAP
+ Andry pointed out that the DAP code did not properly handle
+ gdb.LazyString results from a pretty-printer, yielding:
+
+ TypeError: Object of type LazyString is not JSON serializable
+
+ This patch fixes the problem, partly with a small patch in varref.py,
+ but mainly by implementing tp_str for LazyString.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-10-16 Tom Tromey <tromey@adacore.com>
+
+ Fix register-setting response from DAP
+ Andry noticed that given a DAP setExpression request, where the
+ expression to set is a register, DAP will return the wrong value -- it
+ will return the old value, not the updated one.
+
+ This happens because gdb.Value.assign (which was recently added for
+ DAP) does not update the value.
+
+ In this patch, I chose to have the assign method update the Value
+ in-place. It's also possible to have it return a new value, but this
+ didn't seem very useful to me.
+
+2023-10-16 Nick Clifton <nickc@redhat.com>
+
+ Fix: GNU-ld: ARM: Issues when trying to set target output architecture
+ PR 28910
+ * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set.
+
+ Fix: GNU-ld: ARM: Issues when trying to set target output architecture
+ PR 28910
+ * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option.
+
+2023-10-16 Tom Tromey <tromey@adacore.com>
+
+ Add DAP scope cache
+ Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
+ with the same frame would yield different variableReference values in
+ the response.
+
+ This patch adds a regression test for this, and adds a scope cache in
+ scopes.py, ensuring that multiple identical requests will get the same
+ response.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2023-10-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Work around PR gas/29517
+ When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
+ ...
+ $ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
+ Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.
+
+ Temporary breakpoint 1, main () at hello.c:6
+ 6 printf ("hello\n");
+ Invalid cast.
+ ...
+ while without glibc debuginfo installed we get the expected result:
+ ...
+ $n = 0x7ffff7daa1b1 "aha"
+ ...
+ and likewise with glibc debuginfo generated with gas 2.40.
+
+ The strstr ifunc resolves to __strstr_sse2_unaligned. The problem is that gas
+ generates dwarf that states that the return type is void:
+ ...
+ <1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <3e1e59> DW_AT_name : __strstr_sse2_unaligned
+ <3e1e5d> DW_AT_external : 1
+ <3e1e5e> DW_AT_low_pc : 0xbbd2e
+ <3e1e66> DW_AT_high_pc : 0xbc1c3
+ ...
+ while the return type should be a DW_TAG_unspecified_type, as is the case
+ with gas 2.40.
+
+ We can still use the workaround of casting to another function type for both
+ __strstr_sse2_unaligned:
+ ...
+ (gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
+ ("haha", "ah")
+ $n = 0x7ffff7daa211 "aha"
+ ...
+ and strstr (which requires using *strstr to dereference the ifunc before we
+ cast):
+ ...
+ gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
+ $n = 0x7ffff7daa251 "aha"
+ ...
+ but that's a bit cumbersome to use.
+
+ Work around this in the dwarf reader, such that we have instead:
+ ...
+ (gdb) p (char *)strstr ("haha", "ah")
+ $n = 0x7ffff7daa1b1 "aha"
+ ...
+
+ This also requires fixing producer_is_gcc to stop returning true for
+ producer "GNU AS 2.39.0".
+
+ Tested on x86_64-linux.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+ PR symtab/30911
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911
+
+2023-10-16 Luis Machado <luis.machado@arm.com>
+
+ Only allow closure lookup by address if there are threads displaced-stepping
+ Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
+ displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
+ is available whenever we have a match between the provided address argument and
+ the buffer address.
+
+ That is fine, but the report in PR30872 shows this assertion triggering when
+ it really shouldn't. After some investigation, here's what I found out.
+
+ The 32-bit Arm architecture is the only one that calls
+ gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
+ 32-bit Arm needs to figure out the thumb state of the original instruction
+ that we displaced-stepped through the displaced-step buffer.
+
+ Before the assertion was put in place by commit
+ 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
+ getting nullptr back, which meant we were not doing a displaced-stepping
+ operation.
+
+ Now, with the assertion in place, this is running into issues.
+
+ It looks like displaced_step_buffers::copy_insn_closure_by_addr is
+ being used to return a couple different answers depending on the
+ state we're in:
+
+ 1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
+ is supposed to return a valid closure for us, so we can determine the
+ thumb mode.
+
+ 2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
+ should return nullptr to signal that there isn't any displaced-step buffers
+ in use, because we don't have a valid closure (but we should always have
+ this).
+
+ Since the displaced-step buffers are always allocated, but not always used,
+ that means the buffers will always contain data. In particular, the buffer
+ addr field cannot be used to determine if the buffer is active or not.
+
+ For instance, we cannot set the buffer addr field to 0x0, as that can be a
+ valid PC in some cases.
+
+ My understanding is that the current_thread field should be a good candidate
+ to signal that a particular displaced-step buffer is active or not. If it is
+ nullptr, we have no threads using that buffer to displaced-step. Otherwise,
+ it is an active buffer in use by a particular thread.
+
+ The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
+ function so we only attempt to return a closure if the buffer has an assigned
+ current_thread and if the buffer address matches the address argument.
+
+ Alternatively, I think we could use a function to answer the question of
+ whether we're actively displaced-stepping (so we have an active buffer) or
+ not.
+
+ I've also added a testcase that exercises the problem. It should reproduce
+ reliably on Arm, as that is the only architecture that faces this problem
+ at the moment.
+
+ Regression-tested on Ubuntu 20.04. OK?
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: replace architecture_changed with new_architecture observer
+ This commit replaces the architecture_changed observer with a
+ new_architecture observer.
+
+ Currently the only user of the architecture_changed observer is the
+ Python code, which uses this observer to register the Python unwinder
+ with the architecture.
+
+ The problem is that the architecture_changed observer is triggered
+ from inferior::set_arch(), which only sees the inferior-wide gdbarch
+ value. For targets that use thread-specific architectures, these
+ never trigger the architecture_changed observer, and so never have the
+ Python unwinder registered with them.
+
+ When it comes to unwinding GDB makes use of the frame's gdbarch, which
+ is based on the thread's regcache gdbarch, which is set in
+ get_thread_regcache to the value returned from
+ target_thread_architecture, which is not always the inferiors gdbarch
+ value, it might be a thread-specific gdbarch which has not passed
+ through inferior::set_arch().
+
+ The new_architecture observer will be triggered from
+ gdbarch_find_by_info, whenever a new gdbarch is created and
+ initialised. As GDB caches and reuses gdbarch values, we should
+ expect to see each new architecture trigger the new_architecture
+ observer just once.
+
+ After this commit, targets that make use of thread-specific
+ architectures should be able to make use of Python unwinders.
+
+ As I don't have access to a machine that makes use of thread-specific
+ architectures right now, I asked Luis to confirm that an AArch64
+ target that uses SVE/SME can't use the Python unwinders in threads
+ that are using a thread-specific architectures, and he confirmed that
+ this is indeed the case, see this discussion:
+
+ https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com
+
+ Tested-By: Lancelot Six <lancelot.six@amd.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-16 Clément Chigot <chigot@adacore.com>
+
+ objcopy: Fix name of the field modified by pe_stack_reserve.
+
+2023-10-16 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add "lp64e" ABI support
+ Since RV32E and RV64E are now ratified, this commit prepares the ABI
+ support for LP64E (LP64 with reduced GPRs).
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_set_abi_by_arch): Update the error
+ message. (md_parse_option): Accept "lp64e".
+ * doc/c-riscv.texi: Update the documentation to allow "lp64e".
+ * testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l:
+ Change error message.
+ * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
+ * testsuite/gas/riscv/mabi-fail-rv32e-lp64q.l: Likewise.
+
+2023-10-16 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove RV64E conflict
+ Since RV32E *and* RV64E are ratified, RV64E is no longer invalid.
+
+ This commit removes a restriction that prevents making base ISA with
+ reduced GPRs with XLEN > 32.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): Remove RV64E
+ conflict since the ratified 'E' base ISAs include RV64E.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-fail-base-02.d: Removed.
+ * testsuite/gas/riscv/march-fail-base-02.l: Removed.
+
+2023-10-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: add distclean dep for gnulib
+
+2023-10-15 Neal Frager <neal.frager@amd.com>
+
+ opcodes: microblaze: Add new bit-field instructions
+ This patches adds new bsefi and bsifi instructions.
+ BSEFI- The instruction shall extract a bit field from a
+ register and place it right-adjusted in the destination register.
+ The other bits in the destination register shall be set to zero.
+ BSIFI- The instruction shall insert a right-adjusted bit field
+ from a register at another position in the destination register.
+ The rest of the bits in the destination register shall be unchanged.
+
+ Further documentation of these instructions can be found here:
+ https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref
+
+ With version 6 of the patch, no new relocation types are added as
+ this was unnecessary for adding the bsefi and bsifi instructions.
+
+ FIXED: Segfault caused by incorrect termination of microblaze_opcodes.
+
+2023-10-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: fix printf string
+
+2023-10-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-13 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] Use SVE_VQ_BYTES instead of __SVE_VQ_BYTES
+ __SVE_VQ_BYTES is only available if SVE definitions are available in
+ the system's headers, and this is not true for all systems.
+
+ For this purpose, we define SVE_VQ_BYTES. This patch fixes the
+ name of the constant being used.
+
+2023-10-13 Clément Chigot <chigot@adacore.com>
+
+ ld: replace wrong bfd_malloc in nto.em
+ xmalloc should be called in ld instead of bfd_malloc.
+
+ ld/ChangeLog:
+
+ * emultempl/nto.em (nto_lookup_QNX_note_section): Replace
+ bfd_malloc by xmalloc.
+
+2023-10-13 Clément Chigot <chigot@adacore.com>
+
+ ld: warn when duplicated QNX stack note are detected
+ This warning is triggered only when a stack parameter is given to
+ the linker.
+
+ ld/ChangeLog:
+
+ * emultempl/nto.em: Add warning when several QNX .note are
+ detected.
+
+2023-10-13 Clément Chigot <chigot@adacore.com>
+
+ ld: correctly handle QNX --lazy-stack without -zstack-size
+ The warning was skipped if -zstack-size is not provided.
+
+ ld/ChangeLog:
+
+ * emultempl/nto.em: Move --lazy-stack warning before missing
+ -zstack-size skip.
+
+2023-10-13 Clément Chigot <chigot@adacore.com>
+
+ ld: allow update of existing QNX stack note
+ Up to now, the linker would always create a QNX stack note from scratch.
+ However, object files could already have such note, ending up into
+ duplicates. QNX loader doesn't handle that.
+
+ Update the mechanism to first search through the input files for a .note
+ section holding a QNX stack note. If none are found, then a new section
+ is created into the stub file as before. This requires this search to be
+ done once the file have been opened, moving the whole logic a bit later
+ in the emulation process.
+
+ As part for this update, also allow to request an executable stack
+ without necessarily having to provide its size as well. In this case, s
+ etup a default lazy stack of 0x1000.
+
+ ld/ChangeLog:
+
+ * emultempl/nto.em (nto_create_QNX_note_section): New Function.
+ (nto_lookup_QNX_note_section): New Function.
+ (nto_add_note_section): Move the creation of the note section
+ in the above new functions.
+ (nto_create_output_section_statements): rename nto_after_open
+ * testsuite/ld-aarch64/aarch64-nto.exp: add new test.
+ * testsuite/ld-aarch64/nto-stack-note-3.d: New test.
+ * testsuite/ld-aarch64/nto-stack-note.s: New test.
+
+2023-10-13 Joseph Faulls <Joseph.Faulls@imgtec.com>
+
+ RISC-V: Add support for numbered ISA mapping strings
+ The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>
+
+ opcodes/
+ * riscv-dis.c (riscv_get_map_state): allow mapping symbol to
+ be suffixed by a unique identifier .<any>
+
+2023-10-13 Tom Tromey <tom@tromey.com>
+
+ Move -lsocket check to common.m4
+ A user pointed out that the -lsocket check in gdb should also apply to
+ gdbserver -- otherwise it can't find the Solaris socketpair. This
+ patch makes the change. It also removes a couple of redundant
+ function checks from gdb's configure.ac.
+
+ This was tested by the person who reported the bug.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-10-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-12 Tom Tromey <tromey@adacore.com>
+
+ Fix test suite failure in file-then-restart.exp
+ Simon pointed out that the new file-then-restart.exp test fails with
+ the extended-remote target board.
+
+ The problem is that the test suite doesn't use gdb_file_cmd -- which
+ handles things like "set remote exec-file". This patch changes
+ gdb_file_cmd to make the "kill" command optional, and then switches
+ the test case to use it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-12 Andrew Burgess <aburgess@redhat.com>
+
+ bfd: add new bfd_cache_size() function
+ In GDB we have a problem with the BFD cache.
+
+ As GDB runs for a potentially extended period of time, if the BFD
+ cache holds a file descriptor for an open on-disk file, this can, on
+ some targets (e.g. Win32) prevent the OS writing to the file.
+
+ This might, for example, prevent a user from recompiling their
+ executable as GDB is (via the BFD cache) holding an open reference to
+ that file.
+
+ Another problem, relates to bfd_stat, for BFDs that are using the BFD
+ cache (i.e. they call cache_bstat to implement bfd_stat). The
+ cache_bstat function finds the BFD in the cache, opening the file if
+ needed, and then uses fstat on the open file descriptor.
+
+ What this means is that, if the on-disk file changes, but the cache
+ was holding an open reference to the file, the bfd_stat will return
+ the 'struct stat' for the old file, not the new file.
+
+ Now, for this second problem, we might be tempted to make use of an
+ actual stat call, instead of calling bfd_stat, however, this isn't
+ ideal as we have some BFDs that use a custom iovec, and implement the
+ various functions over GDB's remote protocol. By using bfd_stat we
+ can have a single call that should work for both local files, and for
+ remote files.
+
+ To solve both of these problems GDB has calls to bfd_cache_close_all
+ sprinkled around its code base. And in theory this should work fine.
+
+ However, I recently ran into a case where we had missed a
+ bfd_cache_close_all call, and as a result some BFDs were held open.
+ This caused a bfd_stat call to return an unexpected result (old file
+ vs new file).
+
+ What I'd like is some way within GDB that I can do:
+
+ gdb_assert ( /* Nothing is held open in the cache. */ );
+
+ As this would allow GDB to quickly identify when we've missed some
+ bfd_cache_close_all calls.
+
+ And so, to support this, I would like to add a new bfd_cache_size
+ function. This function returns an integer, which is the number of
+ open files in the cache. I can then start adding:
+
+ gdb_assert (bfd_cache_size() == 0);
+
+ to GDB in some strategic spots, and start fixing all of the missing
+ bfd_cache_close_all calls that crop up as a result.
+
+2023-10-12 Andrew Burgess <aburgess@redhat.com>
+
+ bfd/cache: change type used to track cached BFDs from int to unsigned
+ Within bfd/cache.c change the type for max_open_files and open_files
+ variables from int to unsigned. As a consequence of this, the return
+ type for bfd_cache_max_open() is also changed from int to unsigned.
+
+ Within bfd_cache_max_open I've left the local 'max' variable as an
+ int, this should ensure that if the sysconf call fails, and returns
+ -1, then the computed max value will be less than 10, which means
+ max_open_files will be set to 10. If 'max' was changed to unsigned
+ then, should the sysconf call fail, we'd end up with max becoming a
+ very large positive number ... which is clearly not what we want.
+
+ And, while I was auditing how open_files is used, I added an assert
+ within bfd_cache_delete to ensure that we don't try to reduce
+ open_files below zero.
+
+ There should be no user visible change with this commit.
+
+2023-10-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-11 Jeff Law <jlaw@ventanamicro.com>
+
+ [RFA] Fix for mcore simulator
+ I was looking for cases where a GCC patch under evaluation would cause test
+ results to change. Quite surprisingly the mcore-elf port showed test
+ differences. After a fair amount of digging my conclusion was the sequences
+ before/after the patch should have been semantically the same.
+
+ Of course if the code is supposed to behave the same, then that points to
+ problems elsewhere (assembler, linker, simulator). Sure enough the mcore
+ simulator was mis-handling the sign extension instructions. The simulator
+ implementation of sextb is via paired shift-by-24 operations. Similarly the
+ simulator implements sexth via paired shift-by-16 operations.
+
+ The temporary holding the value was declared as a "long" thus this approach
+ worked fine for hosts with a 32 bit wide long and failed miserably for hosts
+ with a 64 bit wide long.
+
+ This patch makes the shift count automatically adjust based on the size of the
+ temporary. It includes a simple test for sextb and sexth. I have _not_ done a
+ full audit of the mcore simulator for more 32->64 bit issues.
+
+ This also fixes 443 execution tests in the GCC testsuite
+
+2023-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Use the correct application name in error messages
+ The old application name (er_archive) is used in many places.
+
+ gprofng/ChangeLog
+ 2023-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Experiment.cc: Replace er_archive with gp-archive.
+ * src/Experiment.cc: Likewise.
+
+2023-10-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-10 Hui Li <lihui@loongson.cn>
+
+ gdb: LoongArch: Handle special struct in dummy call
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
+
+ there exist some failed testcases:
+
+ === gdb Summary ===
+
+ # of expected passes 5533
+ # of unexpected failures 367
+
+ The root cause is related with a struct containing floating-point
+ members as function argument or return value for a dummy call.
+
+ (1) Structure consists of one floating-point member within FRLEN bits
+ wide, it is passed in an FAR if available.
+ (2) Structure consists of two floating-point members both within FRLEN
+ bits wide, it is passed in two FARs if available.
+ (3) Structure consists of one integer member within GRLEN bits wide and
+ one floating-point member within FRLEN bits wide, it is passed in a
+ GAR and an FAR if available.
+
+ Note that in the above cases, empty structure or union members are also
+ ignored even in C++.
+
+ Here is a simple test on LoongArch:
+
+ loongson@bogon:~$ cat test.c
+
+ #include<stdio.h>
+
+ struct test {
+ long a;
+ double b __attribute__((aligned(16)));
+ };
+ struct test val = { 88, 99.99 };
+ int check_arg_struct (struct test arg)
+ {
+ printf("arg.a = %ld\n", arg.a);
+ printf("arg.b = %f\n", arg.b);
+ printf("sizeof(val) = %d\n", sizeof(val));
+ return 1;
+ }
+ int main()
+ {
+ check_arg_struct (val);
+ return 0;
+ }
+ loongson@bogon:~$ gcc -g test.c -o test
+ loongson@bogon:~$ ./test
+ arg.a = 88
+ arg.b = 99.990000
+ sizeof(val) = 32
+
+ Before:
+
+ loongson@bogon:~$ gdb test
+ ...
+ (gdb) start
+ ...
+ Temporary breakpoint 1, main () at test.c:19
+ 19 check_arg_struct (val);
+ (gdb) p check_arg_struct (val)
+ arg.a = 140737488286128
+ arg.b = -nan
+ sizeof(val) = 32
+ $1 = 1
+ ...
+
+ After:
+
+ loongson@bogon:~$ gdb test
+ ...
+ (gdb) start
+ ...
+ Temporary breakpoint 1, main () at test.c:19
+ 19 check_arg_struct (val);
+ (gdb) p check_arg_struct (val)
+ arg.a = 88
+ arg.b = 99.990000
+ sizeof(val) = 32
+ $1 = 1
+ ...
+
+ With this patch, there are no failed testcases:
+
+ make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
+
+ === gdb Summary ===
+
+ # of expected passes 5900
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add assertion when marking the remote async flag
+ As reported in bug 30630 [1], we hit a case where the remote target's
+ async flag is marked while the target is not configured (yet) to work
+ async. This should not happen. It is caught thanks to this assert in
+ remote_target::wait:
+
+ /* Start by clearing the flag that asks for our wait method to be called,
+ we'll mark it again at the end if needed. If the target is not in
+ async mode then the async token should not be marked. */
+ if (target_is_async_p ())
+ rs->clear_async_event_handler ();
+ else
+ gdb_assert (!rs->async_event_handler_marked ());
+
+ This is helpful, but I think that we could have caught the problem earlier than
+ that, at the moment we marked the handler. Catching problems earlier
+ makes them easier to debug.
+
+ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630
+
+ Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add remote_state::{is_async_p,can_async_p}
+ A subsequent patch will want to know if the remote is async within a
+ remote_state method. Add a helper method for that, and for "can async"
+ as well, for symmetry.
+
+ Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make remote_state's async token private
+ Make remote_async_inferior_event_token private (rename to
+ m_async_event_handler_token) and add methods for the various operations
+ we do on it. This will help by:
+
+ - allowing to break on those methods when debugging
+ - allowing to add assertions in the methods
+
+ Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove trailing whitespaces in remote.c
+ Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: scope down registers_changed call in inferior::set_arch
+ inferior::set_arch calls registers_changed, which invalidates all
+ regcaches. It would be enough to invalidate only regcaches of threads
+ belonging to this inferior. Call registers_changed_ptid instead, with
+ the proper process target / ptid. If the inferior does not have a
+ process target, there should be no regcaches for that inferior, so no
+ need to invalidate anything.
+
+ Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove target_gdbarch
+ This function is just a wrapper around the current inferior's gdbarch.
+ I find that having that wrapper just obscures where the arch is coming
+ from, and that it's often used as "I don't know which arch to use so
+ I'll use this magical target_gdbarch function that gets me an arch" when
+ the arch should in fact come from something in the context (a thread,
+ objfile, symbol, etc). I think that removing it and inlining
+ `current_inferior ()->arch ()` everywhere will make it a bit clearer
+ where that arch comes from and will trigger people into reflecting
+ whether this is the right place to get the arch or not.
+
+ Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move set_target_gdbarch to inferior::set_arch
+ set_target_gdbarch is basically a setter for the current inferior's
+ arch, that notifies other parts of GDB of the architecture change. Move
+ the code of set_target_gdbarch to the inferior::set_arch method.
+
+ Add gdbarch_initialized_p, so we can keep the assertion.
+
+ Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add inferior parameter to architecture_changed observable
+ This is to make it explicit which inferior's architecture just changed,
+ and that the callbacks should not assume it is the current inferior.
+
+ Update the only caller, pyuw_on_new_gdbarch, to add the parameter,
+ although it doesn't use it currently.
+
+ Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add inferior::{arch, set_arch}
+ Make the inferior's gdbarch field private, and add getters and setters.
+ This helped me by allowing putting breakpoints on set_arch to know when
+ the inferior's arch was set. A subsequent patch in this series also
+ adds more things in set_arch.
+
+ Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflow in elf32_arm_get_synthetic_symtab
+ Guard against fuzzed files where .plt size isn't commensurate with
+ plt relocations.
+
+ * elf32-arm.c (elf32_arm_plt0_size): Add data_size param.
+ Return -1 if data_size is too small.
+ (elf32_arm_plt_size): Likewise. Delete temp var. Formatting.
+ (elf32_arm_get_synthetic_symtab): Adjust to suit.
+
+2023-10-10 Alan Modra <amodra@gmail.com>
+
+ asan: null dereference in read_and_display_attr_value
+ This fixes multiple places in read_and_display_attr_value dealing with
+ range and location lists that can segfault when debug_info_p is NULL.
+ Fuzzed object files can contain arbitrary DW_FORMs.
+
+ * dwarf.c (read_and_display_attr_value): Don't dereference NULL
+ debug_info_p.
+
+2023-10-10 Alan Modra <amodra@gmail.com>
+
+ asan: invalid free in bfd_init_section_compress_status
+ With specially crafted compressed sections, it's possible to tickle a
+ problem when decompressing: If the compression headers says the
+ uncompressed size is zero, this will be seen as an error return from
+ bfd_compress_section_contents. On errors the caller should free any
+ malloc'd input buffers, but this isn't really an error and the section
+ contents have been updated to a bfd_alloc'd buffer which can't be
+ freed.
+
+ * compress.c (bfd_compress_section_contents): Return -1 as error
+ rather than 0.
+ (bfd_init_section_compress_status, bfd_compress_section): Adjust.
+
+2023-10-10 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/python: implement support for sending custom MI async notifications
+ This commit adds a new Python function, gdb.notify_mi, that can be used
+ to emit custom async notification to MI channel. This can be used, among
+ other things, to implement notifications about events MI does not support,
+ such as remote connection closed or register change.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/python: generalize serialize_mi_result()
+ This commit generalizes serialize_mi_result() to make usable in
+ different contexts than printing result of custom MI command.
+
+ To do so, the check whether passed Python object is a dictionary has been
+ moved to the caller - at the very least, different uses require different
+ error messages. Also it has been renamed to serialize_mi_results() to better
+ match GDB/MI output syntax (see corresponding section in documentation,
+ in particular rules 'result-record' and 'async-output'.
+
+ Since it is now more generic function, it has been moved to py-mi.c.
+
+ This is a preparation for implementing Python support for sending custom
+ MI async events.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-10 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch/GAS: Add support for branch relaxation
+ For the instructions of R_LARCH_B16/B21, if the immediate overflow,
+ add a B instruction and R_LARCH_B26 relocation.
+
+ For example:
+
+ .L1
+ ...
+ blt $t0, $t1, .L1
+ R_LARCH_B16
+
+ change to:
+
+ .L1
+ ...
+ bge $t0, $t1, .L2
+ b .L1
+ R_LARCH_B26
+ .L2
+
+2023-10-10 Tom de Vries <tdevries@suse.de>
+
+ [readelf] Handle .gdb_index section version 9
+ Add the abilitity to print a v9 .gdb_index section.
+
+ The v9 section contains an extra table, which is printed as follows:
+ ...
+ Shortcut table:
+ Language of main: Fortran 95
+ Name of main: contains_keyword
+ ...
+
+ [ For the example, I used the exec of gdb test-case
+ gdb.fortran/nested-funcs-2-exp when running the test-case with target board
+ cc-with-gdb-index. ]
+
+ Tested on x86_64-linux.
+
+ Approved-By: Nick Clifton <nickc@redhat.com>
+
+2023-10-10 Matheus Branco Borella <dark.ryu.550@gmail.com>
+
+ [gdb/symtab] Add name_of_main and language_of_main to the DWARF index
+ This patch adds a new section to the DWARF index containing the name
+ and the language of the main function symbol, gathered from
+ `cooked_index::get_main`, if available. Currently, for lack of a better name,
+ this section is called the "shortcut table". The way this name is both saved and
+ applied upon an index being loaded in mirrors how it is done in
+ `cooked_index_functions`, more specifically, the full name of the main function
+ symbol is saved and `set_objfile_main_name` is used to apply it after it is
+ loaded.
+
+ The main use case for this patch is in improving startup times when dealing with
+ large binaries. Currently, when an index is used, GDB has to expand symtabs
+ until it finds out what the language of the main function symbol is. For some
+ large executables, this may take a considerable amount of time to complete,
+ slowing down startup. This patch bypasses that operation by having both the name
+ and language of the main function symbol be provided ahead of time by the index.
+
+ In my testing (a binary with about 1.8GB worth of DWARF data) this change brings
+ startup time down from about 34 seconds to about 1.5 seconds.
+
+ When testing the patch with target board cc-with-gdb-index, test-case
+ gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a
+ pre-existing issue, filed as PR symtab/30946.
+
+ Tested on x86_64-linux, with target board unix and cc-with-gdb-index.
+
+ PR symtab/24549
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-10-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-09 John Baldwin <jhb@FreeBSD.org>
+
+ gdb_unique_ptr.h: Fix a typo in a comment
+
+2023-10-09 Nick Clifton <nickc@redhat.com>
+
+ Fix: Null pointer dereference in ldlex.l
+ PR 30951
+ * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL.
+
+ Fix: A potential null_pointer_deference bug
+ PR 30954
+ * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it.
+
+ Fix: Null pointer dereference in elf32-i386.c
+ PR 30950
+ * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer.
+
+ Fix: A potential bug of null pointer dereference
+ PR 30949
+ * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer.
+
+2023-10-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: match complete lines in gdb.base/maint.exp
+ This thread:
+
+ https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/
+
+ pointed out that within gdb.base/maint.exp, some regexps within a
+ gdb_test_multiple were failing to match a complete line, while later
+ regexps within the gdb_test_multiple made use of the '^' anchor, and
+ so assumed that earlier lines had been completely matched and removed
+ from expect's buffer.
+
+ When testing with READ1 set this assumption was failing.
+
+ Fix this by extending the offending patterns with a trailing '\r\n'.
+
+ Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-08 Joel Brobecker <brobecker@adacore.com>
+
+ Update gdb/NEWS after GDB 14 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.
+
+2023-10-08 Joel Brobecker <brobecker@adacore.com>
+
+ Bump version to 15.0.50.DATE-git.
+ Now that the GDB 14 branch has been created,
+ this commit bumps the version number in gdb/version.in to
+ 15.0.50.DATE-git
+
+ For the record, the GDB 14 branch was created
+ from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588.
+
+ Also, as a result of the version bump, the following changes
+ have been made in gdb/testsuite:
+
+ * gdb.base/default.exp: Change $_gdb_major to 15.
+
+2023-10-08 cailulu <cailulu@loongson.cn>
+
+ Add testsuits for new assembler option of mthin-add-sub.
+
+2023-10-08 cailulu <cailulu@loongson.cn>
+
+ as: add option for generate R_LARCH_32/64_PCREL.
+ Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL,
+ so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default,
+ and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL
+ as much as possible.
+
+ The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL
+ relocation in .eh_frame.
+
+2023-10-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-07 Michael J. Eager <eager@eagercon.com>
+
+ Revert "opcodes: microblaze: Add new bit-field instructions"
+ This reverts commit 6bbf249557ba17cfebe01c67370df4da9e6a56f9.
+
+ Maciej W. Rozycki <macro@orcam.me.uk>:
+ Yet it has caused numerous regressions:
+
+ microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges
+ microblaze-elf +FAIL: binutils-all/pr26548
+ microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
+ microblaze-elf +FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output) Yet it has caused numerous regressions:
+ microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges
+ microblaze-elf +FAIL: binutils-all/pr26548
+ microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output)
+ ...
+
+2023-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/i386-signal.exp on x86_64
+ On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into:
+ ...
+ builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \
+ -fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M
+ /tmp/cc2xydTG.s: Assembler messages:^M
+ /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
+ compiler exited with status 1
+ output is:
+ /tmp/cc2xydTG.s: Assembler messages:^M
+ /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
+
+ gdb compile failed, /tmp/cc2xydTG.s: Assembler messages:
+ /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'
+ UNTESTED: gdb.arch/i386-signal.exp: failed to compile
+ ...
+
+ This is with gas 2.41, it compiles without problems with gas 2.40. Some more
+ strict checking was added in commit 5cc007751cd ("x86: further adjust
+ extend-to-32bit-address conditions"). This may or may not be a gas regression
+ ( https://sourceware.org/pipermail/binutils/2023-October/129818.html ).
+
+ The offending bit is:
+ ...
+ " push $sigframe\n"
+ ...
+ which refers to a function:
+ ...
+ " .globl sigframe\n"
+ "sigframe:\n"
+ ...
+
+ The test-case passes with target board unix/-m32.
+
+ Make the test-case work by using pushq instead of push for the
+ is_amd64_regs_target case.
+
+ Tested on x86_64-linux, with target boards:
+ - unix/-m64 (is_amd64_regs_target == 1), and
+ - unix/-m32 (is_amd64_regs_target == 0),
+
+ PR testsuite/30928
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928
+
+2023-10-07 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ gdb: support rseq auxvs
+ Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size
+ and alignment ELF auxiliary vector entries") introduced two new auxvs:
+ AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN. Support them in GDB. This
+ fixes auxv.exp on kernels >= v6.3.
+
+ Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30910 cross test fail: can't read "CHECK_TARGET": no such variable
+ When TCL_TRY is FALSE, the wrong check-DEJAGNU is generated.
+ Place "if TCL_TRY / endif" in the right place.
+
+ gprofng/ChangeLog
+ 2023-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30910
+ * Makefile.am: Correct "if TCL_TRY / endif".
+ * Makefile.in: Rebuild.
+
+2023-10-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-06 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ process-dies-while-detaching.exp: Exit early if GDB misses sync breakpoint
+ I'm seeing a lot of variability in the failures of
+ gdb.threads/process-dies-while-detaching.exp on aarch64-linux. On this
+ platform, a problem yet to be investigated causes GDB to miss the _exit
+ breakpoint. What happens next is random because after missing that
+ breakpoint, GDB is out of sync with the inferior. This causes the tests
+ following that point in the testcase to fail in a random way.
+
+ In this scenario it's better to exit the testcase early to avoid random
+ results in the testsuite.
+
+ We are relying on gdb_continue_to_breakpoint to return the result of
+ gdb_test_multiple. This is already the case because in Tcl the return
+ value of a function is the return value of the last command it runs. But
+ change gdb_continue_to_breakpoint to explicitly return this value, to make
+ it clear this is the intended behaviour.
+
+ Tested on aarch64-linux.
+
+ Tested-By: Guinevere Larsen <blarsen@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-06 Neal Frager <neal.frager@amd.com>
+
+ opcodes: microblaze: Add new bit-field instructions
+ This patches adds new bsefi and bsifi instructions.
+ BSEFI- The instruction shall extract a bit field from a
+ register and place it right-adjusted in the destination register.
+ The other bits in the destination register shall be set to zero.
+ BSIFI- The instruction shall insert a right-adjusted bit field
+ from a register at another position in the destination register.
+ The rest of the bits in the destination register shall be unchanged.
+
+ Further documentation of these instructions can be found here:
+ https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref
+
+ This patch has been tested for years of AMD Xilinx Yocto
+ releases as part of the following patch set:
+
+ https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/NEWS: reorder some entries in the NEWS file
+ I spotted two entries in the NEWS file that I believe are in the wrong
+ place, these are:
+
+ - An entry about MI v1 being deprecated, this feels like it should
+ be the first entry under the 'MI changes' heading, and
+
+ - An entry for the $_shell convenience function which is currently
+ under the 'New commands' heading (sort of), when I think this
+ should be listed in the general news section.
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: fix gdbserver builds after expedite_regs changes
+ After this commit:
+
+ commit 6a65998a8a94abaaae7ca4ff0ab9c3f25dc2e766
+ Date: Mon Sep 11 12:42:00 2023 +0100
+
+ Convert tdesc's expedite_regs to a string vector
+
+ The risc-v, loongarch, and csky gdbserver builds were broken. A use
+ of target_desc::expedite_regs (for each architecture) was not updated
+ to take account of the type change.
+
+ I've tested that this fixes the risc-v build. I haven't tested the
+ other architectures, but they should be fine.
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: cleanup in gdb.base/args.exp
+ The last few commits resolved the KFAILs in gdb.base/args.exp. With
+ those out of the way we can clean up this test script a little.
+
+ In this commit I have:
+
+ - Stopped passing 'nowarnings' flag when building the source file.
+ I see no reason why this source should issue a warning,
+
+ - Moved setup of GDBFLAGS into args_test proc, callers that passed a
+ newline needed a small tweak, and also the matching code needs
+ updating for newline handling, but I think this is nicer, the
+ argument lists are now given just once,
+
+ - Updated comment on args_test,
+
+ - Updated other comments.
+
+ There should be no change in what is tested after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: cleanup in handle_v_run
+ After the previous commit there is now a redundant string copy in
+ handle_v_run, this commit cleans that up.
+
+ There should be no functional change after this commit.
+
+ During review I was pointed to this older series:
+
+ https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
+
+ which also includes this fix as part of a larger set of changes. I'm
+ giving a Co-Authored-By credit to the author of that original series.
+ I believe this smaller fix brings some benefits on its own, though the
+ original series does offer additional improvements. Once this is
+ merged I'll take a look at rebasing and resubmitting the original series.
+
+ Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: handle newlines in inferior arguments
+ Similarly to how single quotes were mishandled, which was fixed two
+ commits ago, this commit fixes handling of newlines in arguments
+ passed to gdbserver.
+
+ We already had a test that covered this, gdb.base/args.exp, which,
+ when run with the native-extended-gdbserver board contained several
+ KFAIL covering this situation.
+
+ In this commit I remove the unnecessary, attempt to quote incoming
+ newlines within arguments, and do some minimal cleanup of the related
+ code. There is additional cleanup that can be done, but I'm leaving
+ that for the next commit.
+
+ Then I've removed the KFAIL from the test case, and performed some
+ minimal cleanup there too.
+
+ After this commit the gdb.base/args.exp is 100% passing with the
+ native-extended-gdbserver board file.
+
+ During review I was pointed to this older series:
+
+ https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
+
+ which also includes this fix as part of a larger set of changes. I'm
+ giving a Co-Authored-By credit to the author of that original series.
+ I believe this smaller fix brings some benefits on its own, though the
+ original series does offer additional improvements. Once this is
+ merged I'll take a look at rebasing and resubmitting the original series.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989
+
+ Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: fix handling of trailing empty argument
+ When I posted the previous patch for review Andreas Schwab pointed out
+ that passing a trailing empty argument also doesn't work.
+
+ The fix for this is in the same area of code as the previous patch,
+ but is sufficiently different that I felt it deserved a patch of its
+ own.
+
+ I noticed that passing arguments containing single quotes to gdbserver
+ didn't work correctly:
+
+ gdb -ex 'set sysroot' --args /tmp/show-args
+ Reading symbols from /tmp/show-args...
+ (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
+ Remote debugging using | gdbserver --once --multi - /tmp/show-args
+ stdin/stdout redirected
+ Process /tmp/show-args created; pid = 176054
+ Remote debugging using stdio
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) set args abc ""
+ (gdb) run
+ The program being debugged has been started already.
+ Start it from the beginning? (y or n) y
+ Starting program: /tmp/show-args \'
+ stdin/stdout redirected
+ Process /tmp/show-args created; pid = 176088
+ 2 args are:
+ /tmp/show-args
+ abc
+ Done.
+ [Inferior 1 (process 176088) exited normally]
+ (gdb) target native
+ Done. Use the "run" command to start a process.
+ (gdb) run
+ Starting program: /tmp/show-args \'
+ 2 args are:
+ /tmp/show-args
+ abc
+
+ Done.
+ [Inferior 1 (process 176095) exited normally]
+ (gdb) q
+
+ The 'shows-args' program used here just prints the arguments passed to
+ the inferior.
+
+ Notice that when starting the inferior using the extended-remote
+ target there is only a single argument 'abc', while when using the
+ native target there is a second argument, the blank line, representing
+ the empty argument.
+
+ The problem here is that the vRun packet coming from GDB looks like
+ this (I've removing the trailing checksum):
+
+ $vRun;PROGRAM_NAME;616263;
+
+ If we compare this to a packet with only a single argument and no
+ trailing empty argument:
+
+ $vRun;PROGRAM_NAME;616263
+
+ Notice the lack of the trailing ';' character here.
+
+ The problem is that gdbserver processes this string in a loop. At
+ each point we maintain a pointer to the character just after a ';',
+ and then we process everything up to either the next ';' character, or
+ to the end of the string.
+
+ We break out of this loop when the character we start with (in that
+ loop iteration) is the null-character. This means in the trailing
+ empty argument case, we abort the loop before doing anything with the
+ empty argument.
+
+ In this commit I've updated the loop, we now break out using a 'break'
+ statement at the end of the loop if the (sub-)string we just processed
+ was empty, with this change we now notice the trailing empty
+ argument.
+
+ I've updated the test case to cover this issue.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: fix handling of single quote arguments
+ I noticed that passing arguments containing single quotes to gdbserver
+ didn't work correctly:
+
+ gdb -ex 'set sysroot' --args /tmp/show-args
+ Reading symbols from /tmp/show-args...
+ (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
+ Remote debugging using | gdbserver --once --multi - /tmp/show-args
+ stdin/stdout redirected
+ Process /tmp/show-args created; pid = 176054
+ Remote debugging using stdio
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) set args \'
+ (gdb) r
+ The program being debugged has been started already.
+ Start it from the beginning? (y or n) y
+ Starting program: /tmp/show-args \'
+ stdin/stdout redirected
+ Process /tmp/show-args created; pid = 176088
+ 2 args are:
+ /tmp/show-args
+ \'
+ Done.
+ [Inferior 1 (process 176088) exited normally]
+ (gdb) target native
+ Done. Use the "run" command to start a process.
+ (gdb) run
+ Starting program: /tmp/show-args \'
+ 2 args are:
+ /tmp/show-args
+ '
+ Done.
+ [Inferior 1 (process 176095) exited normally]
+ (gdb) q
+
+ The 'shows-args' program used here just prints the arguments passed to
+ the inferior.
+
+ Notice that when starting the inferior using the extended-remote
+ target the second argument is "\'", while when running using native
+ target the argument is "'". The second of these is correct, the \'
+ used with the "set args" command is just to show GDB that the single
+ quote is not opening an argument string.
+
+ It turns out that the extra backslash is injected on the gdbserver
+ side when gdbserver processes the arguments that GDB passes it, the
+ code that does this was added as part of this much larger commit:
+
+ commit 2090129c36c7e582943b7d300968d19b46160d84
+ Date: Thu Dec 22 21:11:11 2016 -0500
+
+ Share fork_inferior et al with gdbserver
+
+ In this commit I propose removing the specific code that adds what I
+ believe is a stray backslash. I've extended an existing test to cover
+ this case, and I now see identical behaviour when using an
+ extended-remote target as with the native target.
+
+ This partially fixes PR gdb/27989, though there are still some issues
+ with newline handling which I'll address in a later commit.
+
+ During review I was pointed to this older series:
+
+ https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
+
+ which also includes this fix as part of a larger set of changes. I'm
+ giving a Co-Authored-By credit to the author of that original series.
+ I believe this smaller fix brings some benefits on its own, though the
+ original series does offer additional improvements. Once this is
+ merged I'll take a look at rebasing and resubmitting the original series.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989
+
+ Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 Nick Clifton <nickc@redhat.com>
+
+ Fix: alpha: ld segfaults in
+ PR 30940
+ * elf64-alpha.c (elf64_alpha_check_relocs): Correct error message.
+
+2023-10-06 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb/configure.ac: Add option --with-additional-debug-dirs
+ If you want to install GDB in a custom prefix, have it look for debug info
+ in that prefix but also in the distro's default location (typically,
+ /usr/lib/debug) and run the GDB testsuite before doing "make install", you
+ have a bit of a problem:
+
+ Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory'
+ parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from
+ looking for distro-installed debug info in /usr/lib/debug. For regular GDB
+ use you could set debug-file-directory to $PREFIX:/usr/lib/debug in
+ $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want
+ to run the testsuite then that doesn't help because in that case GDB runs
+ with the '-nx' option.
+
+ There's the configure option '--with-separate-debug-dir' to set the default
+ value for 'debug-file-directory', but it accepts only one directory and not
+ a list. I considered modifying it to accept a list, but it's not obvious
+ how to do that because its value is also used by BFD, as well as processed
+ for "relocatability".
+
+ I thought it was simpler to add a new option to specify a list of
+ additional directories that will be appended to the debug-file-directory
+ setting.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/go] Handle v3 go_0 mangled prefix
+ With gcc-10 we have:
+ ...
+ (gdb) break package2.Foo^M
+ Breakpoint 2 at 0x402563: file package2.go, line 5.^M
+ (gdb) PASS: gdb.go/package.exp: setting breakpoint 1
+ ...
+ but with gcc-11:
+ ...
+ gdb) break package2.Foo^M
+ Function "package2.Foo" not defined.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo
+ ...
+
+ In the gcc-10 case, though the exec contains dwarf, it's not used to set the
+ breakpoint (which is an independent problem, filed as PR go/30941), instead
+ the minimal symbol information is used.
+
+ The minimal symbol information changed between gcc-10 and gcc-11:
+ ...
+ $ nm a.out.10 | grep Foo
+ 000000000040370d T go.package2.Foo
+ 0000000000404e50 R go.package2.Foo..f
+ $ nm a.out.11 | grep Foo
+ 0000000000403857 T go_0package2.Foo
+ 0000000000405030 R go_0package2.Foo..f
+ ...
+
+ A new v3 mangling scheme was used. The mangling schemes define a separator
+ character and mangling character:
+ - for v2, dot is used both as separator character and mangling character, and
+ - for v3, dot is used as separator character and underscore as mangling
+ character.
+
+ For more details, see [1] and [2].
+
+ In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo:
+ change mangling scheme"), function Special_char_code::Special_char_code. ]
+
+ Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the
+ test-case.
+
+ Note that this doesn't fix this regression:
+ ...
+ $ gccgo-10 package2.go -c -g0
+ $ gccgo-10 package1.go package2.o -g0
+ $ gdb -q -batch a.out -ex "break go.package2.Foo"
+ Breakpoint 1 at 0x40370d
+ $ gccgo-11 package2.go -c -g0
+ $ gccgo-11 package1.go package2.o -g0
+ $ gdb -q -batch a.out -ex "break go.package2.Foo"
+ Function "go.package2.Foo" not defined.
+ ...
+
+ With gcc-10, we set a breakpoint on the mangled minimal symbol. That
+ one has simply changed for gcc-11, so it's equivalent to using:
+ ...
+ $ gdb -q -batch a.out -ex "break go_0package2.Foo"
+ Breakpoint 1 at 0x403857
+ ...
+ which does work.
+
+ Tested on x86_64-linux:
+ - openSUSE Leap 15.4, using gccgo-7,
+ - openSUSE Tumbleweed, using gccgo-13.
+
+ PR go/27238
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238
+
+ [1] https://go-review.googlesource.com/c/gofrontend/+/271726
+ [2] https://github.com/golang/go/issues/41862#issuecomment-707244103
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use objfile->pspace in free_objfile observers
+ Use objfile->pspace instead of current_program_space.
+
+ Change-Id: I127a1788e155b321563114452ed5b530f1d1f618
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unnecessary nullptr check in free_objfile observers
+ The free_objfile observable is never called with a nullptr objfile.
+
+ Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add all_objfiles_removed observer
+ The new_objfile observer is currently used to indicate both when a new
+ objfile is added to program space (when passed non-nullptr) and when all
+ objfiles of a program space were just removed (when passed nullptr).
+ I think this is confusing (and Andrew apparently thinks so too [1]).
+ Add a new "all_objfiles_removed" observer to remove the second role from
+ "new_objfile".
+
+ Some existing users of new_objfile do nothing if the passed objfile is
+ nullptr. For them, we can simply drop the nullptr check. For others,
+ add a new all_objfiles_removed callback, and refactor things a bit to
+ keep the existing behavior as much as possible.
+
+ Some callbacks relied on current_program_space, and following
+ the refactoring now use either objfile->pspace or the pspace passed to
+ all_objfiles_removed. I think this should be relatively safe, and in
+ general a step in the right direction.
+
+ On the notify side, I found only one call site to change from
+ new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
+ entirely clear to me that this is entirely correct. clear_symtab_users
+ appears to be called in spots that don't remove all objfiles
+ (functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
+ do_module_cleanups). But I think that this patch at least makes the
+ current code clearer.
+
+ [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
+
+ Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add program_space parameters to some auto-load functions
+ Make the current_program_space references bubble up a bit.
+
+ Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use objfile->pspace in auto-load.c
+ Use objfile->pspace instead of current_program_space in two spots.
+
+ Change-Id: Idf94fad486252d1250380f295e71b0fe76dce76c
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add program_space parameter to emit_clear_objfiles_event
+ Add program_space space parameters to emit_clear_objfiles_event and
+ create_clear_objfiles_event_object, making the reference to
+ current_program_space bubble up a bit.
+
+ Change-Id: I5fde2071712781e5d45971fa0ab34d85d3a49a71
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add program_space parameters to some functions in symtab.c
+ Add some program_space parameters to functions related to getting and
+ setting the main name, making the references to current_program_space
+ bubble up a bit. find_main_name calls ada_main_name, which implicitly
+ relies on the current program space, so I didn't add a parameter to that
+ function.
+
+ Change-Id: I9996955e8ae56832bbd461964d978e700e6feaf4
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add program_space parameter to ada_clear_symbol_cache
+ Make the references to current_program_space bubble up one level.
+
+ Change-Id: I82acab5628c30f6535d52aa32ce2c1d0375cbeed
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix auxv cache clearing from new_objfile observer
+ It was pointed out on the mailing list that a recently added
+ test (gdb.python/py-progspace-events.exp) was failing when run with
+ the native-extended-gdbserver board. This test was added with this
+ commit:
+
+ commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
+ Date: Tue Sep 19 11:45:36 2023 +0100
+
+ gdb: add Python events for program space addition and removal
+
+ It turns out though that the test is failing due to a existing bug
+ in GDB, the new test just exposes the problem. Additionally, the
+ failure really doesn't even rely on the new functionality added in the
+ above commit. I reduced the test to a simple set of steps that
+ reproduced the failure and tested against GDB 13, and the test passes;
+ so the bug was introduced since then. In fact, the bug was introduced
+ with this commit:
+
+ commit a2827364e2bf19910fa5a54364a594a5ba3033b8
+ Date: Fri Sep 8 15:48:16 2023 +0100
+
+ gdb: remove final user of the executable_changed observer
+
+ This commit changed how the per-inferior auxv data cache is managed,
+ specifically, when the cache is cleared, and it is this that leads to
+ the failure.
+
+ This bug is interesting because it exposes a number of issues with
+ GDB, I'll explain all of the problems I see, though ultimately, I only
+ propose fixing one problem in this commit, which is enough to resolve
+ the crash we are currently seeing.
+
+ The crash that we are seeing manifests like this:
+
+ ...
+ [Inferior 2 (process 3970384) exited normally]
+ +inferior 1
+ [Switching to inferior 1 [process 3970383] (/tmp/build/gdb/testsuite/outputs/gdb.python/py-progspace-events/py-progspace-events)]
+ [Switching to thread 1.1 (Thread 3970383.3970383)]
+ #0 breakpt () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.python/py-progspace-events.c:28
+ 28 { /* Nothing. */ }
+ (gdb) step
+ +step
+ terminate called after throwing an instance of 'gdb_exception_error'
+
+ Fatal signal: Aborted
+ ... etc ...
+
+ What's happening is that GDB attempts to refill the auxv cache as a
+ result of the gdbarch_has_shared_address_space call in
+ program_space::~program_space, the backtrace looks like this:
+
+ #0 0x00007fb4f419a9a5 in raise () from /lib64/libpthread.so.0
+ #1 0x00000000008b635d in handle_fatal_signal (sig=6) at ../../src/gdb/event-top.c:912
+ #2 <signal handler called>
+ #3 0x00007fb4f38e3625 in raise () from /lib64/libc.so.6
+ #4 0x00007fb4f38cc8d9 in abort () from /lib64/libc.so.6
+ #5 0x00007fb4f3c70756 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
+ #6 0x00007fb4f3c7c6dc in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
+ #7 0x00007fb4f3c7b6e9 in __cxa_call_terminate () from /lib64/libstdc++.so.6
+ #8 0x00007fb4f3c7c094 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
+ #9 0x00007fb4f3a80c63 in _Unwind_RaiseException_Phase2 () from /lib64/libgcc_s.so.1
+ #10 0x00007fb4f3a8154e in _Unwind_Resume () from /lib64/libgcc_s.so.1
+ #11 0x0000000000e8832d in target_read_alloc_1<unsigned char> (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2266
+ #12 0x0000000000e73dea in target_read_alloc (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2315
+ #13 0x000000000058248c in target_read_auxv_raw (ops=0x408a3a0) at ../../src/gdb/auxv.c:379
+ #14 0x000000000058243d in target_read_auxv () at ../../src/gdb/auxv.c:368
+ #15 0x000000000058255c in target_auxv_search (match=0x0, valp=0x7ffdee17c598) at ../../src/gdb/auxv.c:415
+ #16 0x0000000000a464bb in linux_is_uclinux () at ../../src/gdb/linux-tdep.c:433
+ #17 0x0000000000a464f6 in linux_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/linux-tdep.c:440
+ #18 0x0000000000510eae in gdbarch_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/gdbarch.c:4889
+ #19 0x0000000000bc7558 in program_space::~program_space (this=0x4544aa0, __in_chrg=<optimized out>) at ../../src/gdb/progspace.c:124
+ #20 0x00000000009b245d in delete_inferior (inf=0x47b3de0) at ../../src/gdb/inferior.c:290
+ #21 0x00000000009b2c10 in prune_inferiors () at ../../src/gdb/inferior.c:480
+ #22 0x00000000009c5e3e in fetch_inferior_event () at ../../src/gdb/infrun.c:4558
+ #23 0x000000000099b4dc in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
+ #24 0x0000000000cbc64f in remote_async_serial_handler (scb=0x4090a30, context=0x408a6b0) at ../../src/gdb/remote.c:14859
+ #25 0x0000000000d83d3a in run_async_handler_and_reschedule (scb=0x4090a30) at ../../src/gdb/ser-base.c:138
+ #26 0x0000000000d83e1f in fd_event (error=0, context=0x4090a30) at ../../src/gdb/ser-base.c:189
+
+ So this is problem #1, if we throw an exception while deleting a
+ program_space then this is not caught, and is going to crash GDB.
+
+ Problem #2 becomes evident when we ask why GDB is throwing an error in
+ this case; the error is thrown because the remote target, operating in
+ non-async mode, can't read the auxv data while an inferior is running
+ and GDB is waiting for a stop reply. The problem here then, is why
+ does GDB get into a position where it tries to interact with the
+ remote target in this way, at this time? The problem is caused by the
+ prune_inferiors call which can be seen in the above backtrace.
+
+ In prune_inferiors we check if the inferior is deletable, and if it
+ is, we delete it. The problem is, I think, we should also check if
+ the target is currently in a state that would allow us to delete the
+ inferior. We don't currently have such a check available, we'd need
+ to add one, but for the remote target, this would return false if the
+ remote is in async mode and the remote is currently waiting for a stop
+ reply. With this change in place GDB would defer deleting the
+ inferior until the remote target has stopped, at which point GDB would
+ be able to refill the auxv cache successfully.
+
+ And then, problem #3 becomes evident when we ask why GDB is needing to
+ refill the auxv cache now when it didn't need to for GDB 13. This is
+ where the second commit mentioned above (a2827364e2bf) comes in.
+ Prior to this commit, the auxv cache was cleared by the
+ executable_changed observer, while after that commit the auxv cache
+ was cleared by the new_objfile observer -- but only when the
+ new_objfile observer is used in the special mode that actually means
+ that all objfiles have been unloaded (I know, the overloading of the
+ new_objfile observer is horrible, and unnecessary, but it's not really
+ important for this bug).
+
+ The difference arises because the new_objfile observer is triggered
+ from clear_symtab_users, which in turn is called from
+ program_space::~program_space. The new_objfile observer for auxv does
+ this:
+
+ static void
+ auxv_new_objfile_observer (struct objfile *objfile)
+ {
+ if (objfile == nullptr)
+ invalidate_auxv_cache_inf (current_inferior ());
+ }
+
+ That is, when all the objfiles are unloaded, we clear the auxv cache
+ for the current inferior.
+
+ The problem is, then when we look at the prune_inferiors ->
+ delete_inferior -> ~program_space path, we see that the current
+ inferior is not going to be an inferior that exists within the
+ program_space being deleted; delete_inferior removes the deleted
+ inferior from the global inferior list, and then only deletes the
+ program_space if program_space::empty() returns true, which is only
+ the case if the current inferior isn't within the program_space to
+ delete, and no other inferior exists within that program_space
+ either.
+
+ What this means is that when the new_objfile observer is called we
+ can't rely on the current inferior having any relationship with the
+ program space in which the objfiles were removed. This was an error
+ in the commit a2827364e2bf, the only thing we can rely on is the
+ current program space. As a result of this mistake, after commit
+ a2827364e2bf, GDB was sometimes clearing the auxv cache for a random
+ inferior. In the native target case this was harmless as we can
+ always refill the cache when needed, but in the remote target case, if
+ we need to refill the cache when the remote target is executing, then
+ we get the crash we observed.
+
+ And additionally, if we think about this a little more, we see that
+ commit a2827364e2bf made another mistake. When all the objfiles are
+ removed, they are removed from a program_space, a program_space might
+ contain multiple inferiors, so surely, we should clear the auxv cache
+ for all of the matching inferiors?
+
+ Given these two insights, that the current_inferior is not relevant,
+ only the current_program_space, and that we should be clearing the
+ cache for all inferiors in the current_program_space, we can update
+ auxv_new_objfile_observer to:
+
+ if (objfile == nullptr)
+ {
+ for (inferior *inf : all_inferiors ())
+ {
+ if (inf->pspace == current_program_space)
+ invalidate_auxv_cache_inf (inf);
+ }
+ }
+
+ With this change we now correctly clear the auxv cache for the correct
+ inferiors, and GDB no longer needs to refill the cache at an
+ inconvenient time, this avoids the crash we were seeing.
+
+ And finally, we reach problem #4. Inspired by the observation that
+ using the current_inferior from within the ~program_space function was
+ not correct, I added some debug to see if current_inferior() was
+ called anywhere else (below ~program_space), and the answer is yes,
+ it's called a often. Mostly the culprit is GDB doing:
+
+ current_inferior ()->top_target ()-> ....
+
+ But I think all of these calls are most likely doing the wrong thing,
+ and only work because the top target in all these cases is shared
+ between all inferiors, e.g. it's the native target, or the remote
+ target for all inferiors. But if we had a truly multi-connection
+ setup, then we might start to see odd behaviour.
+
+ Problem #1 I'm just ignoring for now, I guess at some point we might
+ run into this again, and then we'd need to solve this. But in this
+ case I wasn't sure what a "good" solution would look like. We need
+ the auxv data in order to implement the linux_is_uclinux() function.
+ If we can't get the auxv data then what should we do, assume yes, or
+ assume no? The right answer would probably be to propagate the error
+ back up the stack, but then we reach ~program_space, and throwing
+ exceptions from a destructor is problematic, so we'd need to catch and
+ deal at this point. The linux_is_uclinux() call is made from within
+ gdbarch_has_shared_address_space(), which is used like:
+
+ if (!gdbarch_has_shared_address_space (target_gdbarch ()))
+ delete this->aspace;
+
+ So, we would have to choose; delete the address space or not. If we
+ delete it on error, then we might delete an address space that is
+ shared within another program space. If we don't delete the address
+ space, then we might leak it. Neither choice is great.
+
+ A better solution might be to have the address spaces be reference
+ counted, then we could remove the gdbarch_has_shared_address_space
+ call completely, and just rely on the reference count to auto-delete
+ the address space when appropriate.
+
+ The solution for problem #2 I already hinted at above, we should have
+ a new target_can_delete_inferiors() call, which should be called from
+ prune_inferiors, this would prevent GDB from trying to delete
+ inferiors when a (remote) target is in a state where we know it can't
+ delete the inferior. Deleting an inferior often (always?) requires
+ sending packets to the remote, and if the remote is waiting for a stop
+ reply then this will never work, so the pruning should be deferred in
+ this case.
+
+ The solution for problem #3 is included in this commit.
+
+ And, for problem #4, I'm not sure what the right solution is. Maybe
+ delete_inferior should ensure the inferior to be deleted is in place
+ when ~program_space is called? But that seems a little weird, as the
+ current inferior would, in theory, still be using the current
+ program_space...
+
+ Anyway, after this commit, the gdb.python/py-progspace-events.exp test
+ now passes when run with the native-extended-remote board.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30935
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I41f0e6e2d7ecc1e5e55ec170f37acd4052f46eaf
+
+2023-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30894 bison should be no hard dependency
+ When running from a distribution tarball, bison should not be necessary.
+ The generated files (QLParser.tab.cc, QLParser.tab.hh) should be distributed.
+ configure.ac should not abort if bison is missing.
+ configure.ac should remove temporary files (dummy.c, Simple.class).
+ bison must be run once to create QLParser.tab.cc and QLParser.tab.hh.
+
+ gprofng/ChangeLog
+ 2023-10-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30894
+ * configure.ac: Don't abort if bison is missing. Remove temporary files.
+ * src/Makefile.am: Distribute QLParser.tab.cc and QLParser.tab.hh.
+ * Run bison once to create QLParser.tab.cc and QLParser.tab.hh.
+ * configure: Rebuild.
+ * src/Makefile.in: Rebuild.
+
+2023-10-05 Nick Clifton <nickc@redhat.com>
+
+ Fix: nm: SEGV at bfd/elf.c:2267 in _bfd_elf_get_dynamic_symbols
+ PR 30904
+ * elf.c (_bfd_elf_get_dynamic_symbols): Fix typo when checking to see if the gnuchains array has been successfully created.
+
+2023-10-05 A. Wilcox <awilfox@adelielinux.org>
+
+ Fix: ld: Test case pr28158 fails on x86_64-linux-musl when index is > 19
+ PR 30905
+ * testsuite/ld-elf/pr28158.rd: Adjust regexp to allow for section indicies larger than 9.
+
+ Fix: addr2line testsuite fails when targeting PowerPC 64 big-endian with ELFv2 ABI
+ PR 30916
+ * testsuite/binutils-all/addr2line.exp: Do not use PowerPC specific options when working with a MUSL target.
+
+ Fix: ld testsuite: glibc-specific DT_RELR tests should not be run on musl systems
+ PR 30917
+ * testsuite/ld-elf/dt-relr.exp: Skip for MUSL targets.
+
+ Fix: ld testsuite: non-PIC shared tests fail on powerpc-linux-musl
+ PR 30918
+ * testsuite/ld-shared/shared.exp: Add XFAILs for tests that fail with the MUSL library.
+
+ Fix: ld testsuite: Thumb PLT and GOT tests should be skipped on musl armhf targets
+ PR 30923
+ * testsuite/ld-arm/thumb-plt-got.d: Skip test for configurations using the MUSL library.
+ * testsuite/ld-arm/thumb-plt.d: Likewise.
+
+ Fix: ld testsuite: pr22001-1 test segfaults on musl/x86
+ PR 30925
+ PR 22001
+ * testsuite/ld-i386/i386.exp: Skip the pr22001 test with TEXTREL relocations enabled on configurations using the MUSL library.
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix reread_symbols when an objfile has target: prefix
+ When using a remote target, it is possible to tell GDB that the
+ executable to be debugged is located on the remote machine, like this:
+
+ (gdb) target extended-remote :54321
+ ... snip ...
+ (gdb) file target:/tmp/hello.x
+ Reading /tmp/hello.x from remote target...
+ warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+ Reading /tmp/hello.x from remote target...
+ Reading symbols from target:/tmp/hello.x...
+ (gdb)
+
+ So far so good. However, when we try to start the inferior we run
+ into a small problem:
+
+ (gdb) set remote exec-file /tmp/hello.x
+ (gdb) start
+ `target:/tmp/hello.x' has disappeared; keeping its symbols.
+ Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
+ Starting program: target:/tmp/hello.x
+ ... snip ...
+
+ Temporary breakpoint 1, main () at /tmp/hello.c:18
+ 18 printf ("Hello World\n");
+ (gdb)
+
+ Notice this line:
+
+ `target:/tmp/hello.x' has disappeared; keeping its symbols.
+
+ That's wrong, the executable hasn't been removed, GDB just doesn't
+ know how to check if the remote file has changed, and so falls back to
+ assuming that the file has been removed.
+
+ In this commit I update reread_symbols to use bfd_stat instead of
+ a direct stat call, this adds support for target: files, and fixes the
+ problem.
+
+ This change was proposed before in this commit:
+
+ https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/
+
+ However, that patch never got merged, and seemed to get stuck
+ discussing issues around gnulib stat vs system stat as used by BFD.
+
+ I didn't 100% understand the issues discussed in that thread, however,
+ I think the problem with the previous thread related to the changes in
+ gdb_bfd.c, rather than to the change in symfile.c. As such, I think
+ this change might be acceptable, my reasoning is:
+
+ - the objfile::mtime field is set by a call to bfd_get_mtime (see
+ objfiles.c), which calls bfd_stat under the hood. This will end
+ up using the system stat,
+
+ - In symfile.c we currently call stat directly, which will call the
+ gnulib stat, which, if I understand the above thread correctly,
+ might give a different result to the system stat in some cases,
+
+ - By switching to using bfd_stat in symfile.c we should now be
+ consistently calling the system stat.
+
+ There is another issue that came up during testing that this commit
+ fixes. Consider this GDB session:
+
+ $ gdb -q
+ (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
+ Remote debugging using | ./gdbserver/gdbserver --multi --once -
+ Remote debugging using stdio
+ (gdb) file /tmp/hello.x
+ Reading symbols from /tmp/hello.x...
+ (gdb) set remote exec-file /tmp/hello.x
+ (gdb) start
+ ... snip ...
+ (gdb) load
+ `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
+ Loading section .interp, size 0x1c lma 0x4002a8
+ ... snip ...
+ Start address 0x0000000000401050, load size 2004
+ Transfer rate: 326 KB/sec, 87 bytes/write.
+
+ Notice this line:
+
+ `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
+
+ We actually see the same output, for the same reasons, when using a
+ native target, like this:
+
+ $ gdb -q
+ (gdb) file /tmp/hello.x
+ Reading symbols from /tmp/hello.x...
+ (gdb) start
+ ... snip ...
+ (gdb) load
+ `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
+ You can't do that when your target is `native'
+ (gdb)
+
+ In both cases this line appears because load_command (symfile.c) calls
+ reread_symbols, and reread_symbols loops over every currently loaded
+ objfile and tries to check if the file has changed on disk by calling
+ stat.
+
+ However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory
+ BFD, the filename for this BFD is literally the string
+ 'system-supplied DSO at 0x7ffff7fcf000'.
+
+ Before this commit GDB would try to use the system 'stat' call to stat
+ the file `system-supplied DSO at 0x7ffff7fcf000', which obviously
+ fails; there's no file with that name (usually). As a consequence of
+ the stat failing GDB prints the ' .... has disappeared ...' line.
+
+ Initially, all this commit did was switch from using 'stat' to using
+ 'bfd_stat'. Calling bfd_stat on an in-memory BFD works just fine,
+ however, BFD just fills the 'struct stat' buffer with zeros (except
+ for the file size), see memory_bstat in bfd/bfdio.c.
+
+ However, there is a bit of a weirdness about in-memory BFDs. When
+ they are initially created the libbfd caches an mtime within the bfd
+ object, this is done in bfd_from_remote_memory (elfcode.h), the cached
+ mtime is the time at which the in-memory BFD is created.
+
+ What this means is that when GDB creates the in-memory BFD, and we
+ call bfd_get_mtime(), the value returned, which GDB caches within
+ objfile::mtime is the creation time of the in-memory BFD. But, when
+ this patch changes to use bfd_stat() we now get back 0, and so we
+ believe that the in-memory BFD has changed. This is a change in
+ behaviour.
+
+ To avoid this change in behaviour, in this commit, I propose that we
+ always skip in-memory BFDs in reread_symbols. This preserves the
+ behaviour from before this commit -- mostly.
+
+ As I'm not specifically checking for, and then skipping, in-memory
+ BFDs, we no longer see this line:
+
+ `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
+
+ Which I think is an improvement.
+
+ Co-Authored-By: Tom Tromey <tromey@adacore.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove print_sys_errmsg
+ This started with me running into this comment in symfile.c:
+
+ /* FIXME, should use print_sys_errmsg but it's not filtered. */
+ gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"),
+ styled_string (file_name_style.style (), filename));
+
+ In this particular case I think I disagree with the comment; I think
+ the output should be a warning rather than just a message printed to
+ gdb_stdout, I think when the executable, or some other objfile that is
+ currently being debugged, disappears from disk, this is likely an
+ unexpected situation, and worth warning the user about.
+
+ So, in theory, I could just call print_sys_errmsg and remove the
+ comment, but that would mean loosing the filename styling in the
+ output... so in the end I remove the comment and updated the code to
+ call warning.
+
+ But that got me looking at print_sys_errmsg and how it's used.
+
+ Currently the function takes a string and an errno, and prints, to
+ stderr, the string followed by the result of calling strerror on the
+ errno.
+
+ In some places the string passed to print_sys_errmsg is just a
+ filename, and this is used when something goes wrong. In these cases,
+ I think calling warning rather than gdb_printf to gdb_stderr, would be
+ better, and in fact, in a couple of places we manually print a
+ "warning" prefix, and then call print_sys_errmsg. And so, for these
+ users I have added a new function warning_filename_and_errno, which
+ takes a filename, which is printed with styling, and an errno, which
+ is passed through strerror and the resulting string printed. This new
+ function calls warning to print its output. I then updated some of
+ the print_sys_errmsg users to use this new function.
+
+ Some other users of print_sys_errmsg are also emitting what is clearly
+ a warning, however, the string being passed in is more than just a
+ filename, so the new warning_filename_and_errno function can't be
+ used, it would style the whole string. For these users I have
+ switched to calling warning directly, this allows me to style the
+ warning message correctly.
+
+ Finally, in inflow.c there is one last call to print_sys_errmsg, in
+ this case I just inlined the definition of print_sys_errmsg. This is
+ a really weird case, as after printing this message GDB just does a
+ hard exit. This is pretty old code, dating back to the initial GDB
+ import, I guess it should be updated to call error() maybe, but I'm
+ reluctant to make this change as part of this commit, just in case
+ there's some reason why we can't throw an error at this point.
+
+ With that done there are now no users of print_sys_errmsg, and so the
+ old function can be removed.
+
+ While I was doing all of the above I added some additional filename
+ styling in soure.c, this is in an else block where the if contained
+ the print_sys_errmsg call, so these felt related.
+
+ And finally, while I was updating the uses of print_sys_errmsg in
+ procfs.c, I noticed that we used a static errmsg buffer to format some
+ error strings. As the above changes got rid of one of the users of
+ errmsg I also removed the other two users, and the static buffer.
+
+ There were a couple of tests that depended on the existing output
+ message format that needed updating. In one case we gained an extra
+ 'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ',
+ I think in both cases the new output is an improvement.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove use of a static buffer for building error strings
+ I noticed in procfs.c that we use a static buffer for building error
+ strings when we could easily use std::string and string_printf to
+ achieve the same result, this commit does that.
+
+ I ran into this while performing a further refactor/cleanup that will
+ be presented in a later patch in this series, and thought this was
+ worth splitting out into its own patch.
+
+ As far as I can tell, only Solaris uses procfs.c, so I did a test
+ build on a Solaris machine, and I don't believe that I've broken
+ anything.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use archive name in warning when appropriate
+ While working on some other patch I noticed that in reread_symbols
+ there is a diagnostic message that can be printed, and in some cases
+ we might use the wrong filename in the message.
+
+ The code in question is checking to see if an objfile has changed on
+ disk, we do this by stat-ing the on disk file and checking the mtime.
+ If this file has been removed from disk then we print a message that
+ the file has been removed, however, if the objfile is within an
+ archive then we stat the archive itself, but then warn that the
+ component within the archive has disappeared. I think it makes more
+ sense to say that the archive has disappeared.
+
+ The last related commit is this one:
+
+ commit 02aeec7bde8ec8a04d14a5637e75f1c6ab899e23
+ Date: Tue Apr 27 21:01:30 2010 +0000
+
+ Check library name rather than member name when rereading symbols.
+
+ Though this just makes the code to stat the archive unconditional, the
+ code in question existed before this commit.
+
+ However, the above commit doesn't include any tests, and seems to
+ indicate that the problem being addressed was seen on Darwin. I'm not
+ sure how to setup a test where GDB is using an objfile from within an
+ archive, and so there's no tests for this commit...
+
+ ... but if someone can let me know how I can setup a suitable test,
+ please let me know and I'll try to get something working.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: some additional filename styling
+ Fix up another couple of places where we can apply filename styling.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-05 A. Wilcox <awilfox@adelielinux.org>
+
+ Fix: ld testsuite: 'Version' pattern grabs 'Version5 EABI', breaking test on arm-linux-musleabihf
+ PR 30924
+ * testsuite/ld-elfvers/vers.exp (objdump_emptyverstuff): Handle EABI version information in objdump's output.
+
+2023-10-05 Saurabh Jha <saurabh.jha@arm.com>
+
+ aarch64: Enable Cortex-X4 CPU
+
+2023-10-05 Neal frager <neal.frager@amd.com>
+
+ microblaze: Add address extension instructions
+ * microblaze-opcm.h (struct op_code_struct): Tidy and remove redundant entries.
+ * microblaze-opc.h (MAX_OPCODES): Increase to 300. (op_code_struct): Add address extension instructions.
+
+2023-10-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-04 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: XFAIL some gdb.base/fileio.exp
+ Some gdb.base/fileio.exp tests expect the inferior to not have write
+ access to some files. If the test is being run as root, this is never
+ possible. This commit adds a way to identify if the user is root and
+ xfails the tests that expect no write access.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-10-04 Neal Frager <neal.frager@amd.com>
+
+ ld: microblaze: ignore rwx segments
+ The linker will generate warnings if it is creating an executable
+ stack or a segment with all three read, write and execute permissions.
+ These settings are not appropriate for all targets including
+ MicroBlaze.
+
+2023-10-04 Neal frager <neal.frager@amd.com>
+
+ opcodes: microblaze: Add hibernate and suspend instructions
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: Document SME2 registers and features
+ Document changes introduced by gdb's SME2 support.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: Extend SME tests to include SME2
+ Reusing the SME tests, this patch introduces additional tests to exercise
+ reading/writing ZT0, availability of the register set, signal context reading
+ for ZT0 and also core file generation.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: Core file support for ZT register set
+ This patch adds support for ZT register dumps/reads for core files. The
+ ZT register is available when the SME2 feature is advertised as available
+ by the Linux Kernel.
+
+ Unlike the enablement for SME1 and the ZA register, support for SME2 is rather
+ simple given the fixed size of the ZT0 register.
+
+ Validated on the Fast Models.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: signal frame support
+ Teach gdb about the ZT state on signal frames and how to restore
+ the contents of the registers.
+
+ There is a new ZT_MAGIC context that the Linux Kernel uses to communicate
+ the ZT register state to gdb.
+
+ As mentioned before, the ZT state should only be available when the ZA state
+ is available.
+
+ Validated under Fast Models.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: Enable SME2 support in gdbserver
+ This patch teaches gdbserver about the SME2 and the ZT0 register.
+
+ Since most of the code used by gdbserver for SME2 is shared with gdb, this
+ is a rather small patch that reuses most of the code put in place for native
+ AArch64 Linux.
+
+ Validated under Fast Models.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme2: Enable SME2 for AArch64 gdb on Linux
+ SME2 defines a new 512-bit register named ZT0, and it is only available
+ if SME is also supported. The ZT0 state is valid only if the SVCR ZA bit
+ is enabled. Otherwise its contents are empty (0).
+
+ The target description is dynamic and gets generated at runtime based on the
+ availability of the feature.
+
+ Validated under Fast Models.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Document SME registers and features
+ Provide documentation for the SME feature and other information that
+ should be useful for users that need to debug a SME-capable target.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Add SVE/SME testcases
+ Add 5 SVE/SME tests to exercise all the new features like reading/writing
+ registers, pseudo-registers, signal frames and core files.
+
+ - Sanity check for SME: Gives a brief smoke test to make sure the most basic
+ of features are working correctly.
+
+ - ZA unavailability tests: Validates the behavior/content of the ZA register
+ is correct when no payload is available. It also exercises changing the
+ vector lengths.
+
+ - ZA availability tests: These tests exercise reading/writing to all the
+ possible ZA pseudo-registers, and validates the state is correct.
+
+ - Core file tests: Validates that core file reading and writing works
+ correctly and that all state dumped/loaded is sane. This is exercised for
+ both Linux Kernel core files and gcore core files.
+
+ - Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD
+ values across signal frames.
+
+ Since some of these tests are very lengthy and take a little while to run
+ (under QEMU at the moment), I decided to parallelize them into smaller
+ chunks so we can throw some more CPU power at them so they run faster.
+
+ I'd still like to add a few more tests to give the testsuite more coverage
+ in the areas of SME/SVE. Hopefully in the near future that will happen.
+
+ Just a reminder that these SME tests are currently unsupported when gdb is
+ connected to a remote target. That's because the RSP doesn't support
+ communicating changes in vector lenghts mid-execution, so gdb will always
+ get wrong state from the remote target.
+
+ Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Core file support for Linux
+ This patch enables dumping SME state via gdb's gcore command and also
+ enables gdb to read SME state from a core file generated by the Linux
+ Kernel.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ corefile/bug: Add hook to control the use of target description notes from corefiles
+ Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread
+ can potentially have distinct target descriptions/gdbarches.
+
+ When loading a gcore-generated core file, at the moment GDB gives priority
+ to the target description dumped to NT_GDB_TDESC. Though technically correct
+ for most targets, it doesn't work correctly for AArch64 with SVE or SME
+ support.
+
+ The correct approach for AArch64/Linux is to either have per-thread target
+ description notes in the corefiles or to rely on the
+ gdbarch_core_read_description hook, so it can figure out the proper target
+ description for a given thread based on the various available register notes.
+
+ The former, although more correct, doesn't address the case of existing gdb's
+ that only output a single target description note.
+
+ This patch goes for the latter, and adds a new gdbarch hook to conditionalize
+ the use of the corefile target description note. The hook is called
+ use_target_description_from_corefile_notes.
+
+ The hook defaults to returning true, meaning targets will use the corefile
+ target description note. AArch64 Linux overrides the hook to return false
+ when it detects any of the SVE or SME register notes in the corefile.
+
+ Otherwise it should be fine for AArch64 Linux to use the corefile target
+ description note.
+
+ When we support per-thread target description notes, then we can augment
+ the AArch64 Linux hook to rely on those notes.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ corefile/bug: Use thread-specific gdbarch when dumping register state to core files
+ When we have a core file generated by gdb (via the gcore command), gdb dumps
+ the target description to a note. During loading of that core file, gdb will
+ first try to load that saved target description.
+
+ This works fine for almost all architectures. But AArch64 has a few
+ dynamically-generated target descriptions/gdbarch depending on the vector
+ length that was in use at the time the core file was generated.
+
+ The target description gdb dumps to the core file note is the one generated
+ at the time of attachment/startup. If, for example, the SVE vector length
+ changed during execution, this would not reflect on the core file, as gdb
+ would still dump the initial target description.
+
+ Another issue is that the gdbarch potentially doesn't match the thread's
+ real gdbarch, and so things like the register cache may have different formats
+ and sizes.
+
+ To address this, fetch the thread's architecture before dumping its register
+ state. That way we will always use the correct target description/gdbarch.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ Get rid of linux-core-thread-data
+ This struct type seems to have been used in the past as a callback
+ parameter. Now it seems that case is no longer true, so we can simplify
+ things by passing the individual parameters linux_core_thread_data
+ encapsulates directly to the functions.
+
+ This is just a cleanup before the next change.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Support TPIDR2 signal frame context
+ The Linux Kernel defines a separate context for the TPIDR2 register in a
+ signal frame. Handle this additional context in gdb so this register
+ gets restored properly when unwinding through signal frames.
+
+ The TPIDR2 register is closely related to SME, and is available when SME
+ support is reported.
+
+ This is tested by testcases that are available in a later patch in the series.
+
+ Regressions-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Fixup sigframe gdbarch when vg/svg changes
+ With SME, where you have two different vector lengths (vl and svl), it may be
+ the case that the current frame has a set of vector lengths (A) but the signal
+ context has a distinct set of vector lengths (B).
+
+ In this case, we may run into a situation where GDB attempts to use a gdbarch
+ created for set A, but it is really dealing with a frame that was using set
+ B.
+
+ This is problematic, specially with SME, because now we have a different
+ number of pseudo-registers and types that gets cached on creation of each
+ gdbarch variation.
+
+ For AArch64 we really need to be able to use the correct gdbarch for each
+ frame, and I noticed the signal frame (tramp-frame) doesn't have a settable
+ prev_arch field. So it ends up using the default frame_unwind_arch function
+ and eventually calling get_frame_arch (next_frame). That means the previous
+ frame will always have the same gdbarch as the current frame.
+
+ This patch first refactors the AArch64/Linux signal context code, simplifying
+ it and making it reusable for our purposes of calculating the previous frame's
+ gdbarch.
+
+ I introduced a struct that holds information that we have found in the signal
+ context, and with which we can make various decisions.
+
+ Finally, a small change to tramp-frame.c and tramp-frame.h to expose a
+ prev_arch hook that the architecture can set.
+
+ With this new field, AArch64/Linux can implement a hook that looks at the
+ signal context and infers the gdbarch for the previous frame.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Signal frame support
+ Teach gdb about the ZA/SSVE state on signal frames and how to restore
+ the contents of the registers.
+
+ There is a new ZA_MAGIC context that the Linux Kernel uses to communicate
+ the ZA register state to gdb.
+
+ The SVE_MAGIC context has also been adjusted to contain a flag indicating
+ whether it is a SVE or SSVE state.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sve: Fix signal frame z/v register restore
+ While doing some SME work, I ran into the situation where the Z register
+ contents restored from a signal frame are incorrect if the signal frame
+ only contains fpsimd state and no sve state.
+
+ This happens because we only restore the v register values in that case,
+ and don't do anything for the z registers.
+
+ Fix this by initializing the z registers to 0 and then copying over the
+ overlapping part of the v registers to the z registers.
+
+ While at it, refactor the code a bit to simplify it and make it smaller.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Add support for SME
+ Enable SME support in gdbserver by adjusting the usual fields. There is
+ not much to this patch because the code is either in gdb or it is shared
+ between gdbserver and gdb. One exception is the bump to gdbserver's
+ PBUFSIZ from 18432 to 131104.
+
+ Since the ZA register can be quite big (256 * 256 bytes), the g/G remote
+ packet will also become quite big
+
+ From gdbserver/tdesc.cc:init_target_desc, I estimated the new size should
+ be at least (2 * 256 * 256 + 32), which yields 131104.
+
+ It is also unlikely we will find a process starting up with SVL set to 256.
+
+ Ideally we'd adjust the packet size dynamically based on what we need, but
+ for now this should do.
+
+ Please note we have the same limitation for SME that we have for SVE, and
+ that is the fact gdbserver cannot communicate vector length changes to gdb
+ via the remote protocol.
+
+ Thiago is working on this improvement, which hopefully will be able to be
+ adapted to SME in an easy way.
+
+ Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ refactor: Adjust expedited registers dynamically
+ Instead of using static arrays, build the list of expedited registers
+ dynamically using a std::vector.
+
+ This refactor shouldn't cause any user-visible changes.
+
+ Regression-tested for aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ Convert tdesc's expedite_regs to a string vector
+ Right now the list of expedited registers is stored as an array of char *,
+ with a nullptr element at the end to signal its last element.
+
+ Convert expedite_regs to a std::vector of std::string so it is easier to
+ manage the elements and the storage is handled automatically.
+
+ Eventually we might want to convert all the target functions so they pass a
+ std::vector of std::string as well. Or maybe expose an interface that target can
+ use to add expedited registers on-by-one depending on the target description
+ discovery needs, as opposed to just a static list of char *.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sme: Enable SME registers and pseudo-registers
+ The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with
+ variable sizes. It also exposes a new mode called streaming mode.
+
+ Similarly to SVE, the ZA register size is dictated by a vector length, but the
+ SME vector length is called streaming vetor length. The total size for
+ ZA in a given moment is svl x svl.
+
+ In streaming mode, the SVE registers have their sizes based on svl rather than
+ the regular vector length (vl).
+
+ The feature detection is controlled by the HWCAP2_SME bit, but actual support
+ should be validated by attempting a ptrace call for one of the new register
+ sets: NT_ARM_ZA and NT_ARM_SSVE.
+
+ Due to its large size, the ZA register is exposed as a vector of bytes, but we
+ introduce a number of pseudo-registers that gives various different views
+ into the ZA contents. These can be arranged in a couple categories: tiles and
+ tile slices.
+
+ Tiles are matrices the same size or smaller than ZA. Tile slices are vectors
+ which map to ZA's rows/columns in different ways.
+
+ A new dynamic target description is provided containing the ZA register, the SVG
+ register and the SVCR register. The size of ZA, like the SVE vector registers,
+ is based on the vector length register SVG (VG for SVE).
+
+ This patch enables SME register support for gdb.
+
+ [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture
+
+ Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ sve: Fix return command when using V registers in a SVE-enabled target
+ In a target without SVE support, the V registers have a size of 16 bytes,
+ otherwise they may have a size bigger than 16 bytes (depending on the current
+ vector length for the Z registers, as they overlap the V registers).
+
+ In aarch64-tdep.c:aarch64_store_return_value, the code is laid
+ out in a way that allocates the buffer with the size of the register, but
+ only updates the amount of bytes for the particular type we're returning.
+
+ This may cause a situation where we have a register size of 32 bytes but
+ are returning a floating point value of 8 bytes. The temporary buffer
+ will therefore have 32 bytes, but we'll only update 8 bytes of it.
+
+ When we write the entire register back, it will have potentially 24 bytes
+ of garbage in it.
+
+ Fix this by first reading the original contents of the register and then
+ overriding only the bytes that we need for the return value.
+
+ Tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ refactor: Simplify SVE interface to read/write registers
+ This is a patch in preparation to upcoming patches enabling SME support. It
+ attempts to simplify the gdb/gdbserver shared interface used to read/write
+ SVE registers.
+
+ Where the current code makes use of unique_ptr, allocating a new buffer by
+ hand and passing a buffer around, this patch makes that code use
+ gdb::byte_vector and passes a reference to this byte vector to the functions,
+ allowing the functions to have ready access to the size of the buffer.
+
+ It also shares a bit more code between gdb and gdbserver, in particular around
+ handling of ptrace get/set requests for SVE.
+
+ I think gdbserver could be refactored to handle register reads/writes more
+ like gdb's native layer as opposed to letting the generic linux-low layer do
+ the ptrace calls. This is not very flexible and assumes one size for the
+ responses. If you have something like NT_ARM_SVE, where you can have either
+ FPSIMD or SVE contents, it doesn't work that well.
+
+ I didn't want to change that interface right now as it is a bit too much work
+ and touches all the targets, some of which I can't easily test.
+
+ Hence the reason why the buffer the generic linux-now passes down to
+ linux-aarch64-low is unused or ignored.
+
+ No user-visible changes should happen as part of this refactor other than a
+ slightly reworded warning message.
+
+ While doing the refactor, I also noticed what seems to be a mistake in checking
+ if the register cache contains active (non-zero) SVE data.
+
+ For instance, the original code did something like this in
+ aarch64_sve_regs_copy_from_reg_buf:
+
+ has_sve_state |= reg_buf->raw_compare (AARCH64_SVE_Z0_REGNUM + i
+ reg, sizeof (__int128_t));
+
+ "reg" is a zeroed-out buffer that we compare the Z register contents
+ past the first 128 bits. The problem here is that raw_compare returns
+ 1 if the contents compare the same, which means has_sve_state will be
+ true. But if we compared the Z register contents to 0, it means we
+ *do not* have SVE state, and therefore has_sve_state should be false.
+
+ The consequence of this mistake is that we convert the initial
+ FPSIMD-formatted data we get from ptrace for the NT_ARM_SVE register
+ set to a SVE-formatted one.
+
+ In the end, this doesn't cause user-visible differences because the
+ values of both the Z and V registers will still be the same. But the
+ logic is not correct.
+
+ I used the opportunity to fix this, and it gets tested later on by
+ the additional SME tests.
+
+ I do plan on submitting some SVE-specific tests to make sure we have
+ a bit more coverage in GDB's testsuite.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ refactor: Rename SVE-specific files
+ In preparation to the SME support patches, rename the SVE-specific files to
+ something a bit more meaningful that can be shared with the SME code.
+
+ In this case, I've renamed the "sve" in the names to "scalable".
+
+ No functional changes.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Luis Machado <luis.machado@arm.com>
+
+ Fix register fetch/store order for native AArch64 Linux
+ I noticed we don't handle register reads/writes in the best way for native
+ AArch64 Linux. Some other registers are fetched/stored even if upper level
+ code told us to fetch a particular register number.
+
+ Fix this by being more strict about which registers we touch when
+ reading/writing them in the native AArch64 Linux layer.
+
+ There should be no user-visible changes due to this patch.
+
+ Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
+
+ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+2023-10-04 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: Refactor system register data
+ This patch moves instances of system register definitions, represented
+ by the SYSREG macro, out of their original place in `aarch64-opc.c'
+ and into a dedicated .def file, `aarch64-sys-regs.def'.
+
+ System register entries in this new file are ordered alphabetically by
+ name. This choice is made to enable the use of fast search algorithms
+ such as binary search when validating register names.
+
+ The SYSREG macro, defined as SYSREG (name, encoding, flags, features)
+ is kept as is and used in the def file, but all other SR_* macros
+ which previously served as indirections to SYSREG are removed.
+
+ opcodes/ChangeLog:
+ * aarch64-opc.c (SR_CORE): Macro definition and uses deleted.
+ (SR_FEAT): Likewise.
+ (SR_FEAT2): Likewise.
+ (SR_V8_1_A): Likewise.
+ (SR_V8_4_A): Likewise.
+ (SR_V8A): Likewise.
+ (SR_V8R): Likewise.
+ (SR_V8_1A): Likewise.
+ (SR_V8_2A): Likewise.
+ (SR_V8_3A): Likewise.
+ (SR_V8_4A): Likewise.
+ (SR_V8_6A): Likewise.
+ (SR_V8_7A): Likewise.
+ (SR_V8_8A): Likewise.
+ (SR_GIC): Likewise.
+ (SR_AMU): Likewise.
+ (SR_LOR): Likewise.
+ (SR_PAN): Likewise.
+ (SR_RAS): Likewise.
+ (SR_RNG): Likewise.
+ (SR_SME): Likewise.
+ (SR_SSBS): Likewise.
+ (SR_SVE): Likewise.
+ (SR_ID_PFR2): Likewise.
+ (SR_PROFILE): Likewise.
+ (SR_MEMTAG): Likewise.
+ (SR_SCXTNUM): Likewise.
+ (SR_EXPAND_ELx): Likewise.
+ (SR_EXPAND_EL12): Likewise.
+ * opcodes/aarch64-sys-regs.def: New.
+
+2023-10-04 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ aarch64: system register aliasing detection
+ This patch adds a mechanism for system register name alias detection
+ to register-matching mechanisms.
+
+ A new `F_REG_ALIAS' flag is added to the set of register flags and
+ used to label which entries in aarch64_sys_regs[] correspond to
+ aliases (and thus which CPENC values are non-unique in this array).
+
+ Where this is used is, for example, in `aarch64_print_operand' where,
+ in the case of system register decoding, the aarch64_sys_regs[] array
+ is iterated through until a match in CPENC value is made and the first
+ match accepted. If insufficient care is given in the ordering of
+ system registers in this array, the alias is encountered before the
+ "real" register and used incorrectly as the register name in the
+ disassembled output.
+
+ With this flag and the new `aarch64_sys_reg_alias_p' test, search
+ candidates corresponding to aliases can be conveniently skipped over.
+
+ One concrete example of where this is useful is with the
+ `trcextinselr0' system register. It was initially placed in the
+ system register list before `trcextinselr', in contrast to a more
+ natural alphabetical order.
+
+ include/ChangeLog:
+ * opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype.
+
+ opcodes/ChangeLog:
+ * aarch64-opc.c (aarch64_sys_reg_alias_p): New.
+ (aarch64_print_operand): add aarch64_sys_reg_alias_p check.
+ (aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr"
+ entry.
+ * aarch64-opc.h (F_REG_ALIAS): New.
+
+2023-10-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/corefile: write NT_GDB_TDESC based on signalled thread
+ When creating a core file from within GDB we include a NT_GDB_TDESC
+ that includes the target description of the architecture in use.
+
+ For architectures with dynamic architectures (e.g. AArch64 with
+ sve/sme) the original architecture, calculated from the original
+ target description, might not match the per-thread architecture.
+
+ In the general case, where each thread has a different architecture,
+ then we really need a separate NT_GDB_TDESC for each thread, however,
+ there's currently no way to read in multiple NT_GDB_TDESC.
+
+ This commit is a step towards per-thread NT_GDB_TDESC. In this commit
+ I have updated the function that writes the NT_GDB_TDESC to accept a
+ gdbarch (rather than calling target_gdbarch() to find a gdbarch), and
+ I now pass in the gdbarch of the signalled thread.
+
+ In many cases (though NOT all) targets with dynamic architectures
+ really only use a single architecture, even when there are multiple
+ threads, so in the common case, this should ensure that GDB emits an
+ architecture that is more likely to be correct.
+
+ Additional work will be needed in order to support corefiles with
+ truly per-thread architectures, but that will need to be done in the
+ future.
+
+2023-10-03 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Fix `readelf -S bintest' test for n64 targets
+ Add a 64-bit traditional MIPS dump variant for the `readelf -S bintest'
+ test from binutils-all/readelf.exp, using a filename suffix according to
+ the rules set there, removing:
+
+ FAIL: readelf -S bintest
+
+ regressions with `mips64-linux-gnuabi64', `mips64el-linux-gnuabi64',
+ `mips64-openbsd', and `mips64el-openbsd' targets, which default to the
+ n64 ABI and consequently produce a section layout that is different from
+ what the generic dump pattern covers.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ binutils/
+ * testsuite/binutils-all/readelf.s-64-tmips: New test variant.
+
+2023-10-03 Vsevolod Alekseyev <sevaa@sprynet.com>
+
+ Fix: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
+ PR 29267
+ * dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation. (read_and_display_attr_value): Replace uses of fetch_indexed_value with fetch_indexed_offset.
+
+2023-10-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: reformat file with black
+ Reformat a Python file with black after this commit:
+
+ commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
+ Date: Tue Sep 19 11:45:36 2023 +0100
+
+ gdb: add Python events for program space addition and removal
+
+ There should be no functional change with this commit.
+
+2023-10-02 Tom Tromey <tromey@adacore.com>
+
+ Add regression test for instructionReference change
+ Yesterday I pushed a patch to fix a small oversight in the DAP code
+ that caused an instructionReference to be an array instead of a
+ string.
+
+ This patch adds a test case for that regression. This required
+ exposing the TON form of the response -- something I mentioned might
+ be necessary when this code was changed to return just the Tcl form.
+
+ I tested this by backing out yesterday's bug fix and verifying that a
+ failure is seen.
+
+2023-10-02 Tom Tromey <tromey@adacore.com>
+
+ Clean up intermediate values in val_print_packed_array_elements
+ Following on Tom de Vries' work in the other array-printers, this
+ patch changes val_print_packed_array_elements to also avoid allocating
+ too many values when printing an Ada packed array.
+
+2023-10-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: accept variable number of spaces in gdb.base/jit-reader-simple.exp regex
+ I see this failure:
+
+ FAIL: gdb.base/jit-reader-simple.exp: standalone: change addr: initial run: maint info breakpoints shows jit breakpoint
+
+ The jit breakpoint expected by the test is there, it's just that the
+ number of spaces doesn't match what the test expects, after "jit
+ events":
+
+ -2 jit events keep y 0x0000555555555119 <__jit_debug_register_code> inf 1
+
+ Fix that by relaxing the regex a bit.
+
+ Change-Id: Ia3b04e6d5978399d940fd1a590f95f15275ca7ac
+
+2023-10-02 Aaron Merey <amerey@redhat.com>
+
+ gdb: Add command 'maint set/show debuginfod download-sections'
+ This setting controls whether GDB may attempt to download ELF/DWARF
+ sections from debuginfod servers.
+
+ This setting is enabled by default if gdb is built with debuginfod
+ section download support (requires libdebuginfod 0.188).
+
+ Also update debuginfod command help text and gdb.texinfo with
+ information on section downloading and the new command.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-02 Aaron Merey <amerey@redhat.com>
+
+ gdb/debuginfod: Add debuginfod_section_query
+ Add new function debuginfod_section_query. This function queries
+ debuginfod servers for an individual ELF/DWARF section associated with
+ a given build-id.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-10-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle older gcc in gdb.ada/import.exp
+ When running test-case gdb.ada/import.exp with gcc 7, most test fail:
+ ...
+ FAIL: gdb.ada/import.exp: print imported_var_ada
+ FAIL: gdb.ada/import.exp: print local_imported_var
+ FAIL: gdb.ada/import.exp: print pkg.imported_var_ada
+ FAIL: gdb.ada/import.exp: print pkg.exported_var_ada
+ FAIL: gdb.ada/import.exp: print exported_var_ada
+ FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
+ FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
+ FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func
+ ...
+
+ When running with gcc 8 or 9, only 2 tests fail:
+ ...
+ FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
+ FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
+ ...
+
+ The test-case passes fully with gcc 10, 11, 12 and 13.
+
+ Debug info for pragma import seems to not have been supported before gcc 8, so
+ require that version.
+
+ The two FAILs with gcc 8 and 9 seem to be due to problems in debug info. Add
+ an xfail for these.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add KFAIL for PR ada/30908
+ With gcc 13.2.1, I run into a cluster of fails:
+ ...
+ FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD"
+ FAIL: gdb.ada/widewide.exp: print my_wws = " helo"
+ FAIL: gdb.ada/widewide.exp: print my_ws = "wide"
+ ...
+
+ The problem is that the debug info contains information about function
+ ada.strings.maps."=", and gdb uses it to implement the comparison.
+ The function is supposed to compare two char sets, not strings, so gdb
+ shouldn't use it. This is PR ada/30908.
+
+ I don't see the same problem with gcc 7.5.0, because the exec doesn't contain
+ the debug info for the function, because the corresponding object is not
+ linked in. Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to
+ gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0.
+
+ Add KFAILs for the PR.
+
+ Tested on x86_64-linux:
+ - openSUSE Leap 15.4 (using gcc 7.5.0), and
+ - openSUSE Tumbleweed (using gcc 13.2.1).
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
+
+2023-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add Python events for program space addition and removal
+ Initially I just wanted a Python event for when GDB removes a program
+ space, I'm writing a Python extension that caches information for each
+ program space, and need to know when I should discard entries for a
+ particular program space.
+
+ But, it seemed easy enough to also add an event for when GDB adds a
+ new program space, so I went ahead and added both new events.
+
+ Of course, we don't currently have an observable for program space
+ addition or removal, so I first needed to add these. After that it's
+ pretty simple to add two new Python events and have these trigger.
+
+ The two new event registries are:
+
+ events.new_progspace
+ events.free_progspace
+
+ These emit NewProgspaceEvent and FreeProgspaceEvent objects
+ respectively, each of these new event types has a 'progspace'
+ attribute that contains the relevant gdb.Progspace object.
+
+ There's a couple of things to be mindful of.
+
+ First, it is not possible to catch the NewProgspaceEvent for the very
+ first program space, the one that is created when GDB first starts, as
+ this program space is created before any Python scripts are sourced.
+
+ In order to allow this event to be caught we would need to defer
+ creating the first program space, and as a consequence the first
+ inferior, until some later time. But, existing scripts could easily
+ depend on there being an initial inferior, so I really don't think we
+ should change that -- and so, we end up with the consequence that we
+ can't catch the event for the first program space.
+
+ The second, I think minor, issue, is that GDB doesn't clean up its
+ program spaces upon exit -- or at least, they are not cleaned up
+ before Python is shut down. As a result, any program spaces in use at
+ the time GDB exits don't generate a FreeProgspaceEvent. I'm not
+ particularly worried about this for my use case, I'm using the event
+ to ensure that a cache doesn't hold stale entries within a single GDB
+ session. It's also easy enough to add a Python at-exit callback which
+ can do any final cleanup if needed.
+
+ Finally, when testing, I did hit a slightly weird issue with some of
+ the remote boards (e.g. remote-stdio-gdbserver). As a consequence of
+ this issue I see some output like this in the gdb.log:
+
+ (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
+ step
+ FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10>
+ warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
+ Use the "interrupt" command to stop the target
+ and then try again.
+ warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running.
+ Use the "interrupt" command to stop the target
+ and then try again.
+ warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running.
+ Use the "interrupt" command to stop the target
+ and then try again.
+ do_parent_stuff () at py-progspace-events.c:41
+ 41 ++global_var;
+ (gdb) PASS: gdb.python/py-progspace-events.exp: step
+
+ The 'FreeProgspaceEvent ...' line is expected, that's my test Python
+ extension logging the event. What isn't expected are all the blocks
+ like:
+
+ warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
+ Use the "interrupt" command to stop the target
+ and then try again.
+
+ It turns out that this has nothing to do with my changes, this is just
+ a consequence of reading files over the remote protocol. The test
+ forks a child process which GDB stays attached too. When the child
+ exits, GDB cleans up by calling prune_inferiors, which in turn can
+ result in GDB trying to close some files that are open because of the
+ inferior being deleted.
+
+ If the prune_inferiors call occurs when the remote target is
+ running (and in non-async mode) then GDB will try to send a fileio
+ packet while the remote target is waiting for a stop reply, and the
+ remote target will throw an error, see remote_target::putpkt_binary in
+ remote.c for details.
+
+ I'm going to look at fixing this, but, as I said, this is nothing to
+ do with this change, I just mention it because I ended up needing to
+ account for these warning messages in one of my tests, and it all
+ looks a bit weird.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-10-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove solib::pspace field
+ This backlink is not necessary, we always know the program space from
+ the context. Pass it down the solib_unloaded observer.
+
+ Change-Id: I45a503472dc791f517558b8141901472634e0556
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-10-02 Nick Clifton <nickc@redhat.com>
+
+ Fix memory leak in RiscV assembler.
+ PR 30861
+ * config/tc-riscv.c (riscv_insert_uleb128_fixes): Release duplicated memory.
+
+ Use bfd_get_current_time in places where it is suitable
+
+2023-10-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-10-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-29 Tom Tromey <tom@tromey.com>
+
+ Support the NO_COLOR environment variable
+ I ran across this site:
+
+ https://no-color.org/
+
+ ... which lobbies for tools to recognize the NO_COLOR environment
+ variable and disable any terminal styling when it is seen.
+
+ This patch implements this for gdb.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-09-29 Neal Frager <neal.frager@amd.com>
+
+ tc-microblaze.c - int compare for X_add_number.
+ The range check should be checking for the range
+ ffffffff80000000..7fffffff, not ffffffff70000000.
+
+ This patch has been tested for years of AMD Xilinx Yocto
+ releases as part of the following patch set:
+
+ https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils
+
+2023-09-29 Neal Frager <neal.frager@amd.com>
+
+ bfd: microblaze: Fix bug in TLSTPREL Relocation
+ Fixed the problem related to the fixup/relocations TLSTPREL.
+ When the fixup is applied the addend is not added at the correct offset
+ of the instruction. The offset is hard coded considering its big endian
+ and it fails for Little endian. This patch allows support for both
+ big & little-endian compilers.
+
+ This patch has been tested for years of AMD Xilinx Yocto
+ releases as part of the following patch set:
+
+ https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils
+
+2023-09-29 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Add -z mark-plt and -z nomark-plt
+ The PLT entry in executables and shared libraries contains an indirect
+ branch, like
+
+ jmp *foo@GOTPCREL(%rip)
+ push $index_foo
+ jmp .PLT0
+
+ or
+
+ endbr64
+ jmp *foo@GOTPCREL(%rip)
+ NOP padding
+
+ which is used to branch to the function, foo, defined in another object.
+ Each R_X86_64_JUMP_SLOT relocation has a corresponding PLT entry.
+
+ The dynamic tags have been added to the x86-64 psABI to mark such PLT
+ entries:
+
+ https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6d824a52a42d173eb838b879616c1be5870b593e
+
+ Add an x86-64 linker option, -z mark-plt, to mark PLT entries with
+
+ #define DT_X86_64_PLT (DT_LOPROC + 0)
+ #define DT_X86_64_PLTSZ (DT_LOPROC + 1)
+ #define DT_X86_64_PLTENT (DT_LOPROC + 3)
+
+ 1. DT_X86_64_PLT: The address of the procedure linkage table.
+ 2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage
+ table.
+ 3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table
+ entry.
+
+ and set the r_addend field of the R_X86_64_JUMP_SLOT relocation to the
+ memory offset of the indirect branch instruction. The dynamic linker
+ can use these tags to update the PLT section to direct branch.
+
+ bfd/
+
+ * elf-linker-x86.h (elf_linker_x86_params): Add mark_plt.
+ * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Set the
+ r_addend of R_X86_64_JUMP_SLOT to the indirect branch offset
+ in PLT entry for -z mark-plt.
+ * elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Add
+ DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT for
+ -z mark-plt.
+ (_bfd_x86_elf_finish_dynamic_sections): Set DT_X86_64_PLT,
+ DT_X86_64_PLTSZ and DT_X86_64_PLTENT.
+ (_bfd_x86_elf_get_synthetic_symtab): Ignore addend for
+ JUMP_SLOT relocation.
+ (_bfd_x86_elf_link_setup_gnu_properties): Set
+ plt_indirect_branch_offset.
+ * elfxx-x86.h (elf_x86_plt_layout): Add plt_indirect_branch_offset.
+
+ binutils/
+
+ * readelf.c (get_x86_64_dynamic_type): New function.
+ (get_dynamic_type): Call get_x86_64_dynamic_type.
+
+ include/
+
+ * elf/x86-64.h (DT_X86_64_PLT): New.
+ (DT_X86_64_PLTSZ): Likewise.
+ (DT_X86_64_PLTENT): Likewise.
+
+ ld/
+
+ * ld.texi: Document -z mark-plt and -z nomark-plt.
+ * emulparams/elf32_x86_64.sh: Source x86-64-plt.sh.
+ * emulparams/elf_x86_64.sh: Likewise.
+ * emulparams/x86-64-plt.sh: New file.
+ * testsuite/ld-x86-64/mark-plt-1.s: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1a-x32.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1a.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1b-x32.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1b.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1c-x32.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1c.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise.
+ * testsuite/ld-x86-64/mark-plt-1d.d: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt tests.
+
+2023-09-29 Nick Clifton <nickc@redhat.com>
+
+ Fix: Segmentation fault caused by npd in objdump
+ PR 30906
+ * elf.c (_bfd_elf_slurp_version_tables): Test that the verref section header has been initialised before using it.
+
+ Update README file's installation instructions
+
+2023-09-29 Sam James <sam@gentoo.org>
+
+ gdb: add Sam James to MAINTAINERS
+ Acked-by: Tom de Vries <tdevries@suse.de>
+
+2023-09-29 Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite: Add relative versus absolute LD_LIBRARY_PATH test
+ At one time, circa 2006, there was a bug, which was presumably fixed
+ without adding a test case:
+
+ If you provided some relative path to the shared library, such as
+ with
+
+ export LD_LIBRARY_PATH=.
+
+ then gdb would fail to match the shared library name during the
+ TLS lookup.
+
+ I think there may have been a bit more to it than is provided by that
+ explanation, since the test also takes care to split the debug info
+ into a separate file.
+
+ In any case, this commit is based on one of Red Hat's really old
+ local patches. I've attempted to update it and remove a fair amount
+ of cruft, hopefully without losing any critical elements from the
+ test.
+
+ Testing on Fedora 38 (correctly) shows 1 unsupported test for
+ native-gdbserver and 5 PASSes for the native target as well as
+ native-extended-gdbserver.
+
+ In his review of v1 of this patch, Lancelot SIX observed that
+ 'thread_local' could be used in place of '__thread' in the C source
+ files. But it only became available via the standard in C11, so I
+ used additional_flags=-std=c11 for compiling both the shared object
+ and the main program.
+
+ Also, while testing with CC_FOR_TARGET=clang, I found that
+ 'additional_flags=-Wl,-soname=${binsharedbase}' caused clang
+ to complain that this linker flag was unused when compiling
+ the source file, so I moved this linker option to 'ldflags='.
+
+ My testing for this v2 patch shows the same results as with v1,
+ but I've done additional testing with CC_FOR_TARGET=clang as
+ well. The results are the same as when gcc is used.
+
+ Co-Authored-by: Jan Kratochvil <jan@jankratochvil.net>
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-29 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove nbsd_{ilp32,lp64}_solib_svr4_fetch_link_map_offsets
+ They are unused.
+
+ Change-Id: I9b78837d41126ce1957aa1e8b08c82a422f06cbf
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-29 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unused imports in solib*.[ch]
+ I'm starting to work on these files, I thought it would be a good time
+ to remove unused imports. These were identified by
+ include-what-you-use. Tested by rebuilding.
+
+ Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-28 Michael J. Eager <eager@eagercon.com>
+
+ Added support in gas for mlittle-endian and mbig-endian flags as options.
+ Updated show usage for MicroBlaze specific assembler options
+ to include new entries.
+
+ This patch has been tested for years of AMD Xilinx Yocto
+ releases as part of the following patch set:
+
+ https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils
+
+
+ ---
+ V1->V2:
+ - removed new options which were unnecessary
+ - added documentation for MicroBlaze specific options
+
+2023-09-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix segfault in tui_find_disassembly_address
+ PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
+ and target board unix/-m32.
+
+ The FAIL happens due to the test executable running into an assert, which is
+ caused by a forked child segfaulting, like so:
+ ...
+ Program terminated with signal SIGSEGV, Segmentation fault.
+ #0 0x00000000 in ?? ()
+ ...
+
+ I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
+ TUI layout asm.
+
+ I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
+ following session I ran into a gdb segfault here in
+ tui_find_disassembly_address:
+ ...
+ /* Disassemble forward. */
+ next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
+ last_addr = asm_lines.back ().addr;
+ ...
+ due to asm_lines being empty after the call to tui_disassemble, while
+ asm_lines.back () assumes that it's not empty.
+
+ I have not been able to reproduce that segfault in that original setting, I'm
+ not sure of the exact scenario (though looking back it probably involved
+ "set detach-on-fork off").
+
+ What likely happened is that I managed to reproduce PR29040, and TUI (attempted
+ to) display the disassembly for address 0, which led to the gdb segfault.
+
+ When gdb_print_insn encounters an insn it cannot print because it can't read
+ the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.
+
+ The specific bit that causes the gdb segfault is that if gdb_print_insn throws
+ a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
+ asm_lines.
+
+ FWIW, I did manage to reproduce the gdb segfault as follows:
+ ...
+ $ gdb -q \
+ -iex "set pagination off" \
+ /usr/bin/rustc \
+ -ex "set breakpoint pending on" \
+ -ex "b dl_main" \
+ -ex run \
+ -ex "up 4" \
+ -ex "layout asm" \
+ -ex "print \$pc"
+ ...
+ <TUI>
+ ...
+ $1 = (void (*)()) 0x1
+ (gdb)
+ ...
+ Now press <up>, and the segfault triggers.
+
+ Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
+ tui_find_disassembly_address.
+
+ I've written a unit test that exercises this scenario.
+
+ Tested on x86_64-linux.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+ PR tui/30823
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Remove old gdb_bfd_openr_iovec
+ This removes the old gdb_bfd_openr_iovec entirely. I think any new
+ code should use the type-safe approach.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Convert solib-rocm to new type-safe gdb_bfd_openr_iovec
+ This converts the solib-rocm BFD iovec implementations to the new
+ type-safe gdb_bfd_openr_iovec. They were already essentially using
+ this approach, just without the type-safe wrapper.
+
+ Thanks to Lancelot Six for testing and fixing this patch.
+
+ Co-Authored-By: Lancelot Six <lancelot.six@amd.com>
+ Acked-by: Lancelot Six <lancelot.six@amd.com>
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Convert minidebug to new type-safe gdb_bfd_openr_iovec
+ This converts the minidebug BFD iovec implementation to the new
+ type-safe gdb_bfd_openr_iovec.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Convert target fileio to new type-safe gdb_bfd_openr_iovec
+ This converts the target fileio BFD iovec implementation to use the
+ new type-safe gdb_bfd_openr_iovec.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Convert mem_bfd_iovec to new type-safe gdb_bfd_openr_iovec
+ This converts the mem_bfd_iovec / target_buffer code to use the new
+ type-safe gdb_bfd_openr_iovec.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Small constructor change to target_buffer
+ This changes the target_buffer constructor to initialize m_filename
+ rather than assign to it.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Tom Tromey <tromey@adacore.com>
+
+ Introduce type-safe variant of gdb_bfd_openr_iovec
+ This patch adds a new, type-safe variant of gdb_bfd_openr_iovec. In
+ this approach, the underlying user data is simply an object, the
+ callbacks are methods, and the "open" function is a function view.
+ Nothing uses this new code yet.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use reopen_exec_file from reread_symbols
+ This commit fixes an issue that was discovered while writing the tests
+ for the previous commit.
+
+ I noticed that, when GDB restarts an inferior, the executable_changed
+ event would trigger twice. The first notification would originate
+ from:
+
+ #0 exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
+ #1 0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122
+ #2 0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682
+ #3 0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192
+ #4 0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125
+ #5 0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609
+ #6 0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761
+ #7 0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593
+ #8 0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924
+ #9 0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328
+ #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381
+ #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
+ #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95
+
+ While the second originates from:
+
+ #0 exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
+ #1 0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517
+ #2 0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398
+ #3 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
+ #4 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95
+
+ In the first case the call to exec_file_attach first passes through
+ reopen_exec_file. The reopen_exec_file performs a modification time
+ check on the executable file, and only calls exec_file_attach if the
+ executable has changed on disk since it was last loaded.
+
+ However, in the second case things work a little differently. In this
+ case GDB is really trying to reread the debug symbol. As such, we
+ iterate over the objfiles list, and for each of those we check the
+ modification time, if the file on disk has changed then we reload the
+ debug symbols from that file.
+
+ However, there is an additional check, if the objfile has the same
+ name as the executable then we will call exec_file_attach, but we do
+ so without checking the cached modification time that indicates when
+ the executable was last reloaded, as a result, we reload the
+ executable twice.
+
+ In this commit I propose that reread_symbols be changed to
+ unconditionally call reopen_exec_file before performing the objfile
+ iteration. This will ensure that, if the executable has changed, then
+ the executable will be reloaded, however, if the executable has
+ already been recently reloaded, we will not reload it for a second
+ time.
+
+ After handling the executable, GDB can then iterate over the objfiles
+ list and reload them in the normal way.
+
+ With this done I now see the executable reloaded only once when GDB
+ restarts an inferior, which means I can remove the kfail that I added
+ to the gdb.python/py-exec-file.exp test in the previous commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: make the executable_changed event available from Python
+ This commit makes the executable_changed observable available through
+ the Python API as an event. There's nothing particularly interesting
+ going on here, it just follows the same pattern as many of the other
+ Python events we support.
+
+ The new event registry is called events.executable_changed, and this
+ emits an ExecutableChangedEvent object which has two attributes, a
+ gdb.Progspace called 'progspace', this is the program space in which
+ the executable changed, and a Boolean called 'reload', which is True
+ if the same executable changed on disk and has been reloaded, or is
+ False when a new executable has been loaded.
+
+ One interesting thing did come up during testing though, you'll notice
+ the test contains a setup_kfail call. During testing I observed that
+ the executable_changed event would trigger twice when GDB restarted an
+ inferior. However, the ExecutableChangedEvent object is identical for
+ both calls, so the wrong information is never sent out, we just see
+ one too many events.
+
+ I tracked this down to how the reload_symbols function (symfile.c)
+ takes care to also reload the executable, however, I've split fixing
+ this into a separate commit, so see the next commit for details.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: pass more arguments to the executable_changed observer
+ This commit continues the work of the previous few commits.
+
+ My goal is to expose the executable_changed observer through the
+ Python API as an event.
+
+ At this point adding executable_changed as an event to the Python API
+ is trivial, but before I do that I would like to add some additional
+ arguments to the observable, which currently has no arguments at all.
+
+ The new arguments I wish to add are:
+
+ 1. The program_space in which the executable was changed, and
+
+ 2. A boolean flag that will indicate if the executable changed to a
+ whole new path, or if GDB just spotted that the executable changed on
+ disk (e.g. the user recompiled the executable).
+
+ In this commit I change the signature of the observable and then pass
+ the arguments through at the one place where this observable is
+ notified.
+
+ As there are (currently) no users of this observable nothing else
+ needs updating. In the next commit I'll add a listener for this
+ observable in the Python code, and expose this as an event in the
+ Python API.
+
+ Additionally, with this change, it should be possible to update the
+ insight debugger to make use of this observable rather than using the
+ deprecated_exec_file_display_hook (as it currently does), which will
+ then allow this hook to be removed from GDB.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove unnecessary notification of executable_changed observer
+ This commit continues the work of the previous two commits.
+
+ My goal, in the next couple of commits, is to expose the
+ executable_changed observable in the Python API as an event. However,
+ before I do that I want to remove the use of the executable_changed
+ observable from the reread_symbols function in symfile.c as this use
+ isn't directly associated with a change of the executable file, and so
+ seems wrong.
+
+ In the previous two commits I have removed all users of the
+ executable_changed observer as I believe those users can, and should,
+ actually be listening for the new_objfile observable instead, so now
+ there are no users of the executable_changed observable.
+
+ As such, I think removing the use of executable_changed from the
+ function reread_symbols is perfectly safe, and correct. At this point
+ the executable has not been changed, so we shouldn't be sending an
+ executable_changed notification, and, as there is nobody listening to
+ this observable, we can't break anything by removing this call.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove final user of the executable_changed observer
+ This commit continues with the task started in the previous commit,
+ and is similar in many ways.
+
+ The goal of the next couple of commits is to expose the
+ executable_changed observable in the Python API as an event. Before I
+ do this I would like to remove the additional call to the
+ executable_changed observable which can be found in the reread_symbols
+ function in the symfile.c file, as I don't believe that this use
+ actually corresponds to a change in the current executable.
+
+ The previous commit removed one user of the executable_changed
+ observable and replaced it with a new_obfile observer instead, and
+ this commit does the same thing.
+
+ In auxv.c we use the executable_changed observable to call
+ invalidate_auxv_cache, which then calls:
+
+ invalidate_auxv_cache_inf (current_inferior ());
+
+ The auxv cache is already (additionally) cleared when an inferior
+ exits and when an inferior appears.
+
+ As with the previous commit, I think we can safely replace the use of
+ the executable_changed observable with a use of the new_obfile
+ observable. All the tests still pass, and with some locally placed
+ printf calls, I think that the cache is still being cleared in all the
+ cases that should matter.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove one user of the executable changed observer
+ My goal for the next few commits is to expose the executable_changed
+ observable from the Python API.
+
+ However, there is call to the executable_changed observable in the
+ reread_symbols function (in symfile.c), and this doesn't actually
+ correspond to the executable changing. My idea then, is to remove
+ this use of the executable_changed observable, but, before I can do
+ that, I need to check that nothing is going to break, and that
+ requires my to think about the current users of this observable.
+
+ One current user of executable_changed is in symtab.c. We add an
+ executable_changed observer that calls:
+
+ set_main_name (nullptr, language_unknown);
+
+ to discard all information about the main function when the executable
+ changes.
+
+ However, changing the executable doesn't actually change the debug
+ information. The debug information changes when the symbol-file
+ changes, so I think this observer is in slightly the wrong place.
+
+ The new_objfile observable is (unfortunately) overloaded, it is called
+ when a new objfile is loaded, and also (when its argument is nullptr),
+ when all debug information should be discarded.
+
+ It turns out that there is already a new_objfile observer in
+ symtab.c. I propose that, when the argument is nullptr (indicating
+ all debug info should be discarded), that we should call set_main_name
+ to discard the information about the main function. We can then
+ remove the executable_changed observer from symtab.c.
+
+ All tests still pass, and, in my local world, I added some debug
+ printf calls, and I think we are still discarded the main information
+ everywhere we need to.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: new Progspace.executable_filename attribute
+ Add a new Progspace.executable_filename attribute that contains the
+ path to the executable for this program space, or None if no
+ executable is set.
+
+ The path within this attribute will be set by the "exec-file" and/or
+ "file" commands.
+
+ Accessing this attribute for an invalid program space will raise an
+ exception.
+
+ This new attribute is similar too, but not the same as the existing
+ gdb.Progspace.filename attribute. If I could change the past, I'd
+ change the 'filename' attribute to 'symbol_filename', which is what it
+ actually represents. The old attribute will be set by the
+ 'symbol-file' command, while the new attribute is set by the
+ 'exec-file' command. Obviously the 'file' command sets both of these
+ attributes.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: new Progspace.symbol_file attribute
+ Add a new Progspace.symbol_file attribute. This attribute holds the
+ gdb.Objfile object that corresponds to Progspace.filename, or None if
+ there is no main symbol file currently set.
+
+ Currently, to get this gdb.Objfile, a user would need to use
+ Progspace.objfiles, and then search for the objfile with a name that
+ matches Progspace.filename -- which should work just fine, but having
+ direct access seems a little nicer.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: extend the description for Progspace.filename
+ Extend the description for Progspace.filename in the documentation to
+ mention what the returned string is actually the filename
+ for (e.g. that it is the filename passed to the 'symbol-file' or
+ 'file' command).
+
+ Also document that this attribute will be None if no symbol file is
+ currently loaded.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/x86: use size of XSAVE area of enabled features
+ Since commit b42405a1594 ("gdb: Update x86 Linux architectures to
+ support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD
+ Ryzen 3700X machine:
+
+ FAIL: gdb.base/gcore.exp: corefile restored all registers
+
+ The test gets the register state (saves the output of "info
+ all-registers"), saves a core with the "gcore" command, loads the core,
+ and checks the register state against the one previously saved. The
+ problem is that when reading registers from the core file, the last half
+ of ymm registers is unavailable:
+
+ (gdb) print $ymm0.v32_int8
+ $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, <unavailable> <repeats 16 times>}
+
+ One strange thing with this machine is that the bitset of state
+ components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU",
+ but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX". So, PKRU appears
+ to be supported by the processor, but disabled by the kernel. I didn't
+ find why yet.
+
+ From CPUID leaf EAX=0Dh, ECX=00h, GDB can get:
+
+ - from EBX: max size of the XSAVE area required by features currently
+ enabled in XCR0. On my machine, it's 0x340 (832).
+ - from ECX: max size of the XSAVE area required by all features
+ supported by XCR0. On my machine, it's 0x380 (896).
+
+ At runtime, GDB uses ECX (max size required by all supported features)
+ to fill the x86_xsave_layout::sizeof_xsave. So, when writing the core
+ file note for the XSAVE state, it writes a note of size 896, even though
+ it doesn't write the PKRU state. When loading back the core, GDB tries
+ to figure out the layout of the XSAVE area based on what features are
+ enabled in XCR0 and the size of the note (the size of the XSAVE area).
+ Since my combination of XCR0 and size of XSAVE area doesn't match any
+ combination known by GDB, GDB falls back to a gdbarch supporting only
+ x87 and SSE.
+
+ This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave
+ field (and consequently the size of the XSAVE state note in core files)
+ using EBX, the size of the XSAVE area required by currently enabled
+ features in XCR0. This makes i387_guess_xsave_layout recognize my case
+ with this condition:
+
+ else if (HAS_AVX (xcr0) && xsave_size == 832)
+ {
+ /* Intel and AMD CPUs supporting AVX. */
+ layout.avx_offset = 576;
+ }
+
+ In other words, just as if my machine didn't support PKRU at all.
+
+ Another reason why I think this change makes sense is that XSAVE state
+ notes in kernel-generated cores on this machine have size 832. So this
+ change makes GDB-generated cores more similar to kernel-generated ones,
+ reducing the diversity of XSAVE state notes that GDB needs to be able to
+ figure out.
+
+ Note that if PKRU was enabled on my machine, then the effective XSAVE
+ area size would be 896 bytes. We would need to add a case in
+ i387_guess_xsave_layout for that combination, since there is no
+ currently. But I don't have a way to test that right now, since I don't
+ know why PKRU is disabled.
+
+ Relevant review note from John Baldwin:
+
+ One further note is that the Linux x86 arches use x86_xsave_length()
+ to infer ("guess") the size of the XSAVE register set that the Linux
+ kernel writes out in core dumps. On FreeBSD x86 arches, GDB is able
+ to query this size directly from the kernel via ptrace. My use of ECX
+ for this guess earlier was just not the best guess. In the case that
+ the kernel enables all of the available features, then ECX and EBX
+ have the same values, so this only matters for a system where the
+ kernel has enabled a subset of available XSAVE extensions.
+
+ Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-28 Frederic Cambus <fred@statdns.com>
+
+ Add support to readelf for the PT_OPENBSD_NOBTCFI segment type.
+
+2023-09-28 Nick Clifton <nickc@redhat.com>
+
+ Fix: nm: SEGV on unknow address at nm.c:718 in print_symname
+ PR 30886 * elf-bfd.h (struct elf_obj_tdata): Add dt_strsz field.
+ * elf.c (_bfd_elf_get_dynamic_symbols): Add a NUL byte at the end of the string table. Initialise the dt_strsz field. (_bfd_elf_slurp_version_tables): Only free the contents if they were malloc'ed. Add checks before setting string pointers in the dt_strtab buffer.
+
+2023-09-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add nopie to gdb.base/unwind-on-each-insn-amd64-2.exp
+ When running test-case gdb.base/unwind-on-each-insn-amd64-2.exp with target
+ board unix/-fPIE/-pie, I run into:
+ ...
+ gdb compile failed, ld: unwind-on-each-insn-amd64-21.o: relocation \
+ R_X86_64_32S against `.text' can not be used when making a PIE object; \
+ recompile with -fPIE
+ ld: failed to set dynamic section sizes: bad value
+ ...
+
+ Fix this by hardcoding nopie in the test-case, and for good measure in the
+ other test-cases that source unwind-on-each-insn.exp.tcl and use a .s file.
+
+ Tested on x86_64-linux.
+
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-27 Aaron Merey <amerey@redhat.com>
+
+ config/debuginfod.m4: Add check for libdebuginfod 0.188
+ Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found
+ define macro HAVE_LIBDEBUGINFOD_FIND_SECTION.
+
+ This macro indicates support for downloading ELF sections from
+ debuginfod servers.
+
+2023-09-27 Nick Clifton <nickc@redhat.com>
+
+ nm: heap-buffer-overflow at elfcode.h:1507 in bfd_elf64_slurp_symbol_table
+ PR 30885
+ * elfcode.h (elf_slurp_symbol_table): Compute the symcount for non dynamic symbols in the same way as _bfd_elf_get_symtab_upper_bound.
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: prefer VEX encodings over EVEX ones when possible
+ AVX-* features / insns paralleling earlier introduced AVX512* ones can
+ be encoded more compactly when the respective feature was explicitly
+ enabled by the user.
+
+ x86: drop cpu_arch_tune_flags
+ Apparently from its introduction the variable was only ever written (the
+ only read is merely to determine whether to write it with another value).
+ (Since, due to the need to re-indent, the adjacent lines setting
+ cpu_arch_tune need touching anyway, switch to using PREOCESSOR_*
+ constants where applicable, to make more obvious what the resulting
+ state is going to be.)
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct cpu_arch_isa_flags maintenance
+ These may not be set from a value derived from cpu_arch_flags: That
+ starts with (almost) all functionality enabled, while cpu_arch_isa_flags
+ is supposed to track features that were explicitly enabled (and perhaps
+ later disabled) by the user.
+
+ To avoid needing to do any such adjustment in two places (each),
+ introduce helper functions used by both command line handling and
+ directive processing.
+
+2023-09-27 Pedro Alves <pedro@palves.net>
+
+ Adjust gdb.thread/pthreads.exp for Cygwin
+ The Cygwin runtime spawns a few extra threads, so using hardcoded
+ thread numbers in tests rarely works correctly. Thankfully, this
+ testcase already records the ids of the important threads in globals.
+ It just so happens that they are not used in a few tests. This commit
+ fixes that.
+
+ With this, the test passes cleanly on Cygwin [1]. Still passes cleanly on
+ x86-64 GNU/Linux.
+
+ [1] - with system GDB. Upstream GDB is missing a couple patches
+ Cygwin carries downstream.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I01bf71fcb44ceddea8bd16b933b10b964749a6af
+
+2023-09-27 Pedro Alves <pedro@palves.net>
+
+ In gdb.threads/pthreads.c, handle pthread_attr_setscope ENOTSUP
+ On Cygwin, I see:
+
+ (gdb) PASS: gdb.threads/pthreads.exp: break thread1
+ continue
+ Continuing.
+ pthread_attr_setscope 1: Not supported (134)
+ [Thread 3732.0x265c exited with code 1]
+ [Thread 3732.0x2834 exited with code 1]
+ [Thread 3732.0x2690 exited with code 1]
+
+ Program terminated with signal SIGHUP, Hangup.
+ The program no longer exists.
+ (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread
+
+ ... and then a set of cascading failures.
+
+ Fix this by treating ENOTSUP the same way as if PTHREAD_SCOPE_SYSTEM
+ were not defined. I.e., ignore ENOTSUP errors, and proceed with
+ testing.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Iea68ff8b9937570726154f36610c48ef96101871
+
+2023-09-27 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/pthreads.exp error handling/printing
+ On Cygwin, I noticed:
+
+ (gdb) PASS: gdb.threads/pthreads.exp: break thread1
+ continue
+ Continuing.
+ pthread_attr_setscope 1: No error
+ [Thread 8732.0x28f8 exited with code 1]
+ [Thread 8732.0xb50 exited with code 1]
+ [Thread 8732.0x17f8 exited with code 1]
+
+ Program terminated with signal SIGHUP, Hangup.
+ The program no longer exists.
+ (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread
+
+ Note "No error" in "pthread_attr_setscope 1: No error". That is a bug
+ in the test. It is using perror, but that prints errno, while the
+ pthread functions return the error directly. Fix all cases of the
+ same problem, by adding a new print_error function and using it.
+
+ We now get:
+
+ ...
+ pthread_attr_setscope 1: Not supported (134)
+ ...
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I972ebc931b157bc0f9084e6ecd8916a5e39238f5
+
+2023-09-27 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/pthreads.c formatting
+ Just some GNU formatting fixes throughout.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Ie851e3815b839e57898263896db0ba8ddfefe09e
+
+2023-09-27 Pedro Alves <pedro@palves.net>
+
+ gdb.threads/pthreads.c, K&R -> ANSI function style
+ gdb.threads/pthreads.c is declaring functions with old K&R style.
+ This commit converts them to ANSI style.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I1ce007c67bb4ab1e49248c014c7881e46634f8f8
+
+2023-09-27 Neal Frager <neal.frager@amd.com>
+
+ opcodes: microblaze: Add wdc.ext.clear and wdc.ext.flush insns
+
+2023-09-27 Hsinyuan Xavier <TheLastLin@hotmail.com>
+
+ Fix: Output section type does not been applied to section forced output by `. = .` assignment
+ PR 30875
+ * ldlang.c (get_os_init_flag): New function. (exp_init_os, map_input_to_output_sections): Use it.
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold FMA VEX and EVEX templates
+ Following the folding of some generic AVX/AVX2 templates with their
+ AVX512F counterpart ones, do this for FMA ones as well, requiring one
+ further adjustment to cpu_flags_match().
+
+ x86: fold VAES/VPCLMULQDQ VEX and EVEX templates
+ Following the folding of some generic AVX/AVX2 templates with their
+ AVX512F counterpart ones, do this for VAES and VPCLMULQDQ ones as well.
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold certain VEX and EVEX templates
+ In anticipation of APX introduce logic to reduce the number of templates
+ we have now, allowing to limit some the number of ones we then need to
+ gain.
+
+ The fundamental requirements are that
+ - attributes be compatible, which specifically means VexW needs to be
+ the same in the templates (which often isn't the case, for VEX
+ encodings having far more WIG tha, EVEX ones),
+ - the EVEX form being AVX512F (with or without AVX512VL), not any of its
+ extensions (the same will then be required for APX - it'll need to be
+ APX_F).
+
+ Note that in check_register() there's now a redundant zmm check. Since
+ this logic will need revisiting for APX anyway, I'd like to keep it that
+ way for now. (Similarly a couple of if()-s which could be folded are
+ kept separate, to reduce code churn when adding APX support.)
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: tighten .insn SAE and broadcast checking
+ SAE / embedded rounding are invalid when there's the memory operand, as
+ the bit encoding this specifies broadcast in that case.
+
+ Broadcast needs to be specified on the memory operand.
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: REX.W overrides DATA_PREFIX
+ REX.W needs to be respected when immediate size and relocation type are
+ determined.
+
+2023-09-27 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: fix suffix-less PUSH of symbol address
+ PR gas/30856
+
+ In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
+ conditions") I neglected the case of PUSH, which is the only insn
+ allowing (proper) symbol addresses to be used as immediates (not
+ displacements, like CALL/JMP) in the absence of any register operands.
+ Since it defaults to 64-bit operand size, guessing an L suffix is wrong
+ there.
+
+2023-09-27 Sam James <sam@gentoo.org> (tiny change)
+
+ gdb: Fix an ODR warning with byacc with GDB_YY_REMAP
+ With byacc, we get an ODR warning with YYSTACKDATA between ada-exp.c.tmp
+ and c-exp.c.tmp. Just include it in the list of symbols we rename.
+
+ PR gdb/30839
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30839
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-09-27 mengqinggang <mengqinggang@loongson.cn>
+
+ Add support for "pcaddi rd, symbol"
+ Add a macro pcaddi instruction to support "pcaddi rd, symbol".
+
+ pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative
+ address, and the address should be 4-byte aligned.
+
+2023-09-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: add xfail for gdb/29965 in gdb.threads/process-exit-status-is-leader-exit-status.exp
+ Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently
+ with:
+
+ FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=0: continue (the program exited)
+ ...
+ FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=9: continue (the program exited)
+
+ This is due to a change in Linux kernel behavior [1] that affects
+ exactly what this test tests. That is, if multiple threads (including
+ the leader) call SYS_exit, the exit status of the process should be the
+ exit status of the leader. After that change in the kernel, it is no
+ longer the case.
+
+ Add an xfail in the test, based on the Linux kernel version. The goal
+ is that if a regression is introduced in GDB regarding this feature, it
+ should be caught if running on an older kernel where the behavior was
+ consistent.
+
+ [1] https://bugzilla.suse.com/show_bug.cgi?id=1206926
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965
+ Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-09-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp with newer gcc
+ When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using
+ gcc 13.2.1, I run into (layout adapted for readability):
+ ...
+ -stack-list-arguments 1^M
+ ^done,stack-args=[
+ frame={level="0",args=[]},
+ frame={level="1",args=[{name="<_task>",value="0x464820"},
+ {name="<_taskL>",value="129"}]},
+ frame={level="2",args=[{name="self_id",value="0x464840"}]},
+ frame={level="3",args=[]},
+ frame={level="4",args=[]}
+ ]^M
+ (gdb) ^M
+ FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
+ ...
+
+ On openSUSE Leap 15.4 with gcc 7.5.0 I get instead:
+ ...
+ -stack-list-arguments 1^M
+ ^done,stack-args=[
+ frame={level="0",args=[]},
+ frame={level="1",args=[{name="<_task>",value="0x444830"}]},
+ frame={level="2",args=[{name="self_id",value="0x444850"}]},
+ frame={level="3",args=[]},
+ frame={level="4",args=[]}]^M
+ (gdb) ^M
+ PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1
+ ...
+
+ The difference in gdb output is due to difference in the dwarf generated by
+ the compiler, so I don't see a problem with gdb here.
+
+ Fix this by updating the test-case to accept this output.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-26 Tom Tromey <tromey@adacore.com>
+
+ Remove some unnecessary qualification from printing.py
+ printing.py references "gdb.printing" in a few spots, but there's no
+ need for this. I think this is leftover from when this code was
+ (briefly) in some other module. This patch removes the unnecessary
+ qualifications. Tested on x86-64 Fedora 36.
+
+2023-09-26 Tom Tromey <tromey@adacore.com>
+
+ Add two new pretty-printer methods
+ This adds two new pretty-printer methods, to support random access to
+ children. The methods are implemented for the no-op array printer,
+ and DAP is updated to use this.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-26 Tom Tromey <tromey@adacore.com>
+
+ Introduce gdb.ValuePrinter
+ There was an earlier thread about adding new methods to
+ pretty-printers:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-June/200503.html
+
+ We've known about the need for printer extensibility for a while, but
+ have been hampered by backward-compatibilty concerns: gdb never
+ documented that printers might acquire new methods, and so existing
+ printers may have attribute name clashes.
+
+ To solve this problem, this patch adds a new pretty-printer tag class
+ that signals to gdb that the printer follows new extensibility rules.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30816
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-26 Nick Clifton <nickc@redhat.com>
+
+ Fix a snafu in the new tests for reproducible archives that assumed a umask of 22.
+
+2023-09-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/ext-run.exp in container
+ When running the gdb testsuite inside a container, I run into:
+ ...
+ (gdb) gdb_expect_list pattern: /1 +root +[/a-z]*(init|systemd)/
+ FAIL: gdb.server/ext-run.exp: get process list (pattern 2)
+ ...
+ because there's no process with pid 1 and cmd init or systemd.
+
+ In the host system (where the test passes), I have:
+ ...
+ $ ps -f 1
+ UID PID PPID C STIME TTY STAT TIME CMD
+ root 1 0 0 Sep25 ? Ss 0:03 /usr/lib/systemd/systemd ...
+ ...
+ but in the container instead:
+ ...
+ UID PID PPID C STIME TTY STAT TIME CMD
+ root 1 0 0 11:45 pts/0 Ss 0:00 /bin/bash
+ ...
+
+ Fix this by also accepting bash as a valid cmd.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-26 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Allow feature flags to occupy >64 bits
+ Following on from the previous patch to make the feature macros take
+ a word number, this one increases the number of flag words from 1 to 2.
+
+ The patch uses some dummy features to push the number of features
+ over 64. The intention is that these should be reused by real
+ features rather than kept as-is.
+
+2023-09-26 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Restructure feature flag handling
+ The AArch64 feature-flag code is currently limited to a maximum
+ of 64 features. This patch reworks it so that the limit can be
+ increased more easily. The basic idea is:
+
+ (1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum
+ counting bit positions.
+
+ (2) Make the feature-list macros take an array index argument
+ (currently always 0). The macros then return the
+ aarch64_feature_set contents for that array index.
+
+ An N-element array would then be initialised as:
+
+ { MACRO (0), ..., MACRO (N - 1) }
+
+ (3) Provide convenience macros for initialising an
+ aarch64_feature_set for:
+
+ - a single feature
+ - a list of individual features
+ - an architecture version
+ - an architecture version + a list of additional features
+
+ (2) and (3) use the preprocessor to generate static initialisers.
+ The main restriction was that uses of the same preprocessor macro
+ cannot be nested. So if a macro wants to do something for N individual
+ arguments, it needs to use a chain of N macros to do it. There then
+ needs to be a way of deriving N, as a preprocessor token suitable for
+ pasting.
+
+ The easiest way of doing that was to precede each list of features
+ by the number of features in the list. So an aarch64_feature_set
+ initialiser for three features A, B and C would be written:
+
+ AARCH64_FEATURES (3, A, B, C)
+
+ This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a
+ synonym for SHA2+AES, so the patch expands the former to the latter.
+
+2023-09-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/dap] Fix dap for python < 3.8
+ With any gdb.dap test and python 3.6 I run into:
+ ...
+ Error occurred in Python: 'code' object has no attribute 'co_posonlyargcount'
+ ERROR: eof reading json header
+ ...
+
+ The attribute is not supported before python 3.8, which introduced the
+ "Positional−only Parameters" concept.
+
+ Fix this by using try/except AttributeError.
+
+ Tested on x86_64-linux:
+ - openSUSE Leap 15.4 with python 3.6, and
+ - openSUSE Tumbleweed with python 3.11.5.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-26 Enze Li <enze.li@hotmail.com>
+
+ fbsd-nat: Fix build failure with GCC 12
+ A user pointed out that the build failed on FreeBSD/amd64 with my last
+ commit. The problem is that I'm not using the proper way to tell the
+ compiler that the variable has been "used". This patch fixes this issue
+ as suggested by John. Pushed as obvious.
+
+ Tested both on FreeBSD/amd64 and FreeBSD/aarch64 by rebuilding.
+
+ Suggested-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-26 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix to step instruction due to P10 prefix instruction.
+ In AIX, power 10 instructions like paddi occupy 8 bytes, while the other instructions
+ 4 bytes of space. Due to this when we do a stepi on paddi instruction we get a SIGILL interrupt. Hence, we
+ need to check during stepi if we are able to step 8 bytes during this instruction execution and is the
+ breakpoint to this instruction set correctly in both 32- and 64-bit mode.
+
+ This patch is a fix to the same.
+
+2023-09-26 Nick Clifton <nickc@redhat.com>
+
+ Allow the use of SOURCE_DATE_EPOCH in the timestamps for members of static archives.
+ (For some reason this commit was not applied at the time that the patch was approved).
+
+2023-09-26 Tom Tromey <tromey@adacore.com>
+
+ Use string_file::release in some places
+ I found a few spots like:
+
+ string_file f;
+ std::string x = f.string ();
+
+ However, string_file::string returns a 'const std::string &'... so it
+ seems to me that this must be copying the string (? I find it hard to
+ reason about this in C++).
+
+ This patch changes these spots to use release() instead, which moves
+ the string.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+ Reviewed-by: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-25 Vsevolod Alekseyev <sevaa@sprynet.com>
+
+ Fix readelf's display of dwarf v5 range lists
+ PR 30792
+ * dwarf.h (struct debug_info): Remove range_versions field.
+ * dwarf.c (fetch_indexed_offset): New function. (read_and_display_attr_value): Use it for DW_FORM_rnglistx. Remove code to initialise range_versions. (skip_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (process_debug_info): Call read_bases. (display_debug_rnglists): Rename to display_debug_rnglists_unit_header and only display the range list header information. (display_debug_ranges): Adjust.
+
+2023-09-25 Claudiu Zissulescu <claziss@gmail.com>
+
+ Revert "arc: Add new GAS tests for ARCv3."
+ This reverts commit 462693a455f04fc52c1c91ffc52ea2446a086444.
+
+ Revert "arc: Add new LD tests for ARCv3."
+ This reverts commit 6e467e9a94c1135bd11d985e9263d43204a9258b.
+
+ Revert "arc: Add new ARCv3 ISA to BFD."
+ This reverts commit 06e8d9861d16c5b7e6920ad0e89889ccf45c575a.
+
+ Revert "arc: Add new linker emulation and scripts for ARCv3 ISA."
+ This reverts commit 4deb1ee57fdb711cac6f36fed75b3c8cb5112d99.
+
+ Revert "arc: Update opcode related include files for ARCv3."
+ This reverts commit 04414221df53bb5129e34bec354dae3121db436a.
+
+ Revert "arc: Update ARC's Gnu Assembler backend with ARCv3 ISA."
+ This reverts commit f3d38d7d0b7346515ba603454feeddc58a3fc451.
+
+ Revert "arc: Add new opcode functions for ARCv3 ISA."
+ This reverts commit c99dc76089a2de97ea0ee755aa8e87037a17b6d6.
+
+ Revert "arc: New ARCv3 ISA instruction table"
+ This reverts commit 67036dfacf87e79317984f51892bfc0eda0e597f.
+
+ Revert "arc: Update arc's gas tests"
+ This reverts commit ef90c0991e78c28bebdd3ed31a77c05be0444191.
+
+ Revert "arc: Update NEWS files"
+ This reverts commit a47d304b1229ecf8912fac17ee9c48d1bf3c729a.
+
+ Revert "arc: Update bfd arc pattern file to allow enable-targets=all"
+ This reverts commit 5e5116071b09e187ee3c6b7e86e86114f6a65ef3.
+
+2023-09-25 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Update bfd arc pattern file to allow enable-targets=all
+ The ARC backend uses a BFD pattern file to generate three ARC targets:
+ - an BFD ARC target for ARCv1 and ARCv2 CPU families. It also works
+ for big-endian variants.
+ - an BFD ARC64 target for ARCv3 64bit machines. It also allows working
+ with ARCv3 32bit machines.
+ - an BFD ARC32 target for ARCv4 32bit machines. It also allows working
+ with ARCv3 64bit machines.
+
+ When configuring with `--enable-targets=all` some patterns are defined
+ multiple times. Fix this issue.
+
+2023-09-25 Andreas Schwab <schwab@suse.de>
+
+ RISC-V: Protect .got with relro
+ Move .got before .data so that it can be protected with -zrelro. Also
+ separate .got.plt from .got if -znow is not in effect; the first two words
+ of .got.plt are placed within the relro region.
+
+ ld:
+ PR ld/30877
+ * emulparams/elf32lriscv-defs.sh (DATA_GOT, SEPARATE_GOTPLT):
+ Define.
+ * emulparams/elf64lriscv-defs.sh (SEPARATE_GOTPLT): Define.
+ * testsuite/ld-elf/binutils.exp (binutils_test): Remove riscv*-*-*
+ from relro_got expression.
+
+2023-09-25 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Update NEWS files
+ Add ARCv3 support in NEWS files.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update arc's gas tests
+ The disassembler can recognize the alternative register names ILINK1
+ and ILINK2. Update tests.
+
+ gas/testsuite/gas/arc
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * gas/testsuite/gas/arc/adc.d: Update ILINK1/INLINK2 reg names.
+ * gas/testsuite/gas/arc/add.d: Likewise.
+ * gas/testsuite/gas/arc/and.d: Likewise.
+ * gas/testsuite/gas/arc/asl.d: Likewise.
+ * gas/testsuite/gas/arc/asr.d: Likewise.
+ * gas/testsuite/gas/arc/bic.d: Likewise.
+ * gas/testsuite/gas/arc/lsr.d: Likewise.
+ * gas/testsuite/gas/arc/nps400-1.d: Likewise.
+ * gas/testsuite/gas/arc/or.d: Likewise.
+ * gas/testsuite/gas/arc/ror.d: Likewise.
+ * gas/testsuite/gas/arc/sbc.d: Likewise.
+ * gas/testsuite/gas/arc/sub.d: Likewise.
+ * gas/testsuite/gas/arc/textinsn3op.d: Likewise.
+ * gas/testsuite/gas/arc/warn.exp: Update predicate.
+ * gas/testsuite/gas/arc/arc.exp: Likewise.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: New ARCv3 ISA instruction table
+ opcodes/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * opcodes/arc64-tbl.h: New file.
+
+2023-09-25 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Add new opcode functions for ARCv3 ISA.
+ opcodes/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+ Cupertino Miranda <cmiranda@synopsys.com>
+
+ * opcodes/Makefile.am: Add ARC64 opcode file.
+ * opcodes/Makefile.in: Regenerate.
+ * opcodes/arc-opc.c: Move the common functionality to
+ arcxx-opc.inc. Keep only ARCv2 ARCv1 specifics.
+ * opcodes/arc-ext-tbl.h: Deleted file.
+ * opcodes/arcxx-opc.inc: New file.
+ * opcodes/arc64-opc.c: Likewise.
+ * opcodes/arc-fxi.h (insert_uimm9_a32_11_s): New function.
+ (extract_uimm9_a32_11_s): Likewise.
+ (insert_uimm10_13_s): Likewise.
+ (extract_uimm10_13_s): Likewise.
+ * opcodes/configure: Regenerate.
+ * opcodes/configure.ac: Add ARC64 target.
+ * opcodes/disassemble.c: Likewise.
+ * opcodes/arc-dis.c (regmod_t): New type.
+ (regmods): New structure.
+ (fpnames): New strings with fp-regs name.
+ (REG_PCL, REG_LIMM, REG_LIMM_S, REG_U32, REG_S32): New defines.
+ (getregname): New function.
+ (find_format_from_table): Discriminate between signed and unsigned
+ 32bit immediates.
+ (find_format): Handle extract function for flags.
+ (arc_insn_length): Update insn lengths to various architectures.
+ (print_insn_arc): Update printing for various ARC architectures.
+ * opcodes/arc-flag-classes.def: New file.
+ * opcodes/arc-flag.def: New file.
+ * opcodes/arc-operands.def: New file.
+ * opcodes/arc-regs.h: Changed.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update ARC's Gnu Assembler backend with ARCv3 ISA.
+ The new Synopsys ARCv3 ISA has a similar instruction format like
+ the old ARCv1 and ARCv2 ISA. Thus, the ARCv3 addition is using
+ whatever we have for old ARC processors plus some ARCv3 spcific mods.
+
+ To distinguish between various ARC variants, we introduced two new
+ configure defines named TARGET_ARCv3_32 and TARGET_ARCv3_64 which are
+ set when we choose either an ARC32 (ARCv3/32) ISA toolchain or an
+ ARC64 (ARCv3/64) ISA toolchain.
+
+ gas/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * gas/config/tc-arc.h: Selectively define default target macros.
+ * gas/configure.ac: Add ARC64 target.
+ * gas/configure.tgt: Likewise.
+ * gas/configure: Regenerate
+ * gas/config.in: Regenerate.
+ * gas/config/tc-arc.c (DEFAULT_ARCH): New macro.
+ (default_arch): New variable.
+ (md_pseudo_table): Add xword.
+ (md_shortopts): Only a few options are recognized by the new ARC64
+ assembler.
+ (md_longopts): Likewise.
+ (ARC_CPU_TYPE_A64x): New define.
+ (ARC_CPU_TYPE_A32x): Likewise.
+ (cpu_type): New arch field.
+ (selected_cpu): Update fields.
+ (arc_opcode_hash_entry_iterator_init): Formating.
+ (arc_opcode_hash_entry_iterator_next): Likewise.
+ (arc_select_cpu): Likewise.
+ (arc_option): Likewise.
+ (check_cpu_feature): Likewise.
+ (debug_exp): Recognize new expression operands.
+ (parse_reloc_symbol): Parse new signed/unsigend cases.
+ (parse_opcode_flags): Update for the case when the flags needs
+ insert/extract functions.
+ (find_opcode_match): Match new signed/unsigned 32-bit immediates.
+ (autodetect_attributes): PLT34 only available for ARC64.
+ (md_assemble): Extend match characters.
+ (declare_fp_set): New function.
+ (init_default_arch): Likewise.
+ (md_begin): Detect and initialize the correct CPU and coresponding
+ registers.
+ (md_pcrel_from_section): Add new relocs.
+ (arc_target_format): New function.
+ (md_apply_fix): Add new relocs.
+ (md_parse_option): Update options.
+ (arc_show_cpu_list): Update with ARC64 cpus.
+ (md_show_usage): Update messages.
+ (may_relax_expr): Add PLT34 case.
+ (assemble_insn): Update for ARC64.
+ (arc_make_nops): New function.
+ (arc_handle_align): Refurbish this function, use arc_make_nops.
+ (tc_arc_fix_adjustable): Update messages.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update opcode related include files for ARCv3.
+ Add new ARCv3 CPUs and required bits to decode/encode ARCv3 ISA
+ opcodes. Fix 32 bit relocations which were set as signed but should be
+ bitfield: ARC_32_ME, ARC_GLOB_DAT, ARC_JMP_SLOT, ARC_RELATIVE. Remove
+ non-ABI relocation ARC_32_ME_S.
+
+ include/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+ Cupertino Miranda <cupertinomiranda@gmail.com>
+ Bruno Mauricio <brunoasmauricio@gmail.com>
+
+ * include/elf/arc-cpu.def: Add new HS5x and HS6x CPUs.
+ * include/elf/arc-reloc.def: Add new ARC64 relocations.
+ * include/elf/arc.h (EF_ARC_CPU_ARC64): New define.
+ * include/opcode/arc-attrs.h (FEATURE_LIST_NAME): Update predicate.
+ * include/opcode/arc-func.h: Update formating.
+ (replace_disp8ls): New function.
+ (replace_disp9s): Likewise.
+ (replace_disp6s): Likewise.
+ (replace_disp7s): Likewise.
+ (replace_disp12s): Likewise.
+ * include/opcode/arc.h (ARC_OPCODE_ARC64): New define.
+ (ARC_OPCODE_ARC32): Likewise.
+ (ARC_OPERAND_FP): Likewise.
+ (HARD_FIELDF): Likewise.
+ (ARC_OPCODE_ARCVx): New macro.
+ (arc_flag_class): Update structure to hold new extract/insert
+ functions for flags.
+ (INSN3OP): Update macro.
+ (FP_SIZE, TPOF, DPOF, SOPF, COPF, CONVOPS): New enums.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Add new linker emulation and scripts for ARCv3 ISA.
+ Add ARCv3's linker bits. Remove obsolete tests.
+
+ ld/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * ld/Makefile.am: Add ARC64 targets.
+ * ld/configure.tgt: Likewise.
+ * ld/Makefile.in: Regenerate.
+ * ld/emulparams/arc64elf32.sh: New file.
+ * ld/emulparams/arc64elf64.sh: Likewise.
+ * ld/emulparams/arc64linux32.sh: Likewise.
+ * ld/emulparams/arc64linux64.sh: Likewise.
+ * ld/scripttempl/elfarc.sc: Update stack and heap definitions.
+ * ld/testsuite/ld-arc/got-weak.d: Deleted file.
+ * ld/testsuite/ld-arc/got-weak.s: Likewise.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Add new ARCv3 ISA to BFD.
+ The new Synopsys's ARCv3 ISA is capable to run either 64-bit or
+ 32-bit ISA. The new 32-bit ISA is not compatible with the old
+ Synopsys ARCv1/ARCv2 ISA, however, it retains a lot of common
+ concepts. Thus, this patch is reusing the old ARC BFD backend and
+ adds the necessary bits for the new architecture in a similar way as
+ it is done for RISCV backend.
+
+ bfd/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+ Cupertino Miranda <cupertinomiranda@gmail.com>
+
+ * bfd/Makefile.am: Add ARC64 files.
+ * bfd/Makefile.in: Regerate.
+ * bfd/arc-got.h (TCB_SIZE): Depends on the target architecture.
+ (GOT_ENTRY_SIZE): New define.
+ (write_in_got): Likewise.
+ (read_from_got): Likewise.
+ (align_power): Likewise.
+ (arc_got_entry_type_for_reloc): Use RELA_SIZE and GOT_ENTRY_SIZE.
+ (arc_fill_got_info_for_reloc): Update formating.
+ (relocate_fix_got_relocs_for_got_info): Likewise.
+ (arc_static_sym_data): Deleted structure.
+ (get_static_sym_data): Deleted function.
+ (relocate_fix_got_relocs_for_got_info): Use symbol static data.
+ (create_got_dynrelocs_for_single_entry): Update formating.
+ (create_got_dynrelocs_for_got_info): Likewise.
+ * bfd/arc-plt.c: New file.
+ * bfd/arc-plt.def: Add ARC64 PLT entry.
+ * bfd/arc-plt.h: Clean it up, move functionality to arc-plt.c file.
+ * bfd/archures.c: Add ARC64 target.
+ * bfd/config.bfd: Likewise.
+ * bfd/configure.ac: Likewise.
+ * bfd/bfd-in2.h: Regenerate.
+ * bfd/configure: Likewise.
+ * bfd/libbfd.h: Likewise.
+ * bfd/cpu-arc.c: Clean it up.
+ * bfd/cpu-arc64.c: New file.
+ * bfd/elf32-arc.c: Renamed to elfnn-arc.c.
+ * bfd/elfnn-arc.c: New file.
+ * bfd/reloc.c: Add new ARC64 relocs.
+ * bfd/targets.c: Add ARC64 target.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Add new LD tests for ARCv3.
+ Add new linker tests for ARCv3 ISA. All the new tests are added in a
+ distinct new folder named arc64.
+
+ ld/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * ld/testsuite/ld-arc64/arcv3_64-reloc-near-exe.dd: New file.
+ * ld/testsuite/ld-arc64/arcv3_64-reloc-near-so.dd: Likewise.
+ * ld/testsuite/ld-arc64/arcv3_64-reloc-near.s: Likewise.
+ * ld/testsuite/ld-arc64/arcv3_64.exp: Likewise.
+ * ld/testsuite/ld-arc64/bl34.dd: Likewise.
+ * ld/testsuite/ld-arc64/bl34.s: Likewise.
+ * ld/testsuite/ld-arc64/linkscript.ld: Likewise.
+ * ld/testsuite/ld-arc64/plt34-got.dd: Likewise.
+ * ld/testsuite/ld-arc64/plt34-got.s: Likewise.
+ * ld/testsuite/ld-arc64/plt34-reloc.dd: Likewise.
+ * ld/testsuite/ld-arc64/plt34-reloc.s: Likewise.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Add new GAS tests for ARCv3.
+ Add new assembler tests for ARCv3 ISA. All the new tests are added in
+ a distinct folder named arc64.
+
+ gas/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * gas/testsuite/gas/arc64/arc64.exp: New file.
+ * gas/testsuite/gas/arc64/float01.d: Likewise.
+ * gas/testsuite/gas/arc64/float01.s: Likewise.
+ * gas/testsuite/gas/arc64/ldd.d: Likewise.
+ * gas/testsuite/gas/arc64/ldd.s: Likewise.
+ * gas/testsuite/gas/arc64/lddl.d: Likewise.
+ * gas/testsuite/gas/arc64/lddl.s: Likewise.
+ * gas/testsuite/gas/arc64/load.d: Likewise.
+ * gas/testsuite/gas/arc64/load.s: Likewise.
+ * gas/testsuite/gas/arc64/st.d: Likewise.
+ * gas/testsuite/gas/arc64/st.s: Likewise.
+ * gas/testsuite/gas/arc64/std.d: Likewise.
+ * gas/testsuite/gas/arc64/std.s: Likewise.
+ * gas/testsuite/gas/arc64/stdl.d: Likewise.
+ * gas/testsuite/gas/arc64/stdl.s: Likewise.
+ * gas/testsuite/gas/arc64/stl.d: Likewise.
+ * gas/testsuite/gas/arc64/stl.s: Likewise.
+
+2023-09-25 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update binutils arc predicate for tests.
+ binutils/testsuite/binutils-all
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * binutils/testsuite/binutils-all/arc/objdump.exp: Update predicate.
+
+2023-09-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-22 Frederic Cambus <fred@statdns.com>
+
+ Update the NetBSD system call table to add memfd_create(2) and epoll(2).
+ Generated from sys/sys/syscall.h revision 1.324.
+
+2023-09-22 Enze Li <enze.li@hotmail.com>
+
+ fbsd-nat: Pacify gcc with no functional changes
+ I see these errors on FreeBSD/aarch64 when using gcc 12 without passing
+ --disable-werror.
+
+ =====================================================================
+ CXX fbsd-nat.o
+ fbsd-nat.c: In member function 'void fbsd_nat_target::resume_one_process(ptid_t, int, gdb_signal)':
+ fbsd-nat.c:1208:11: error: unused variable 'request' [-Werror=unused-variable]
+ 1208 | int request;
+ | ^~~~~~~
+ fbsd-nat.c: In member function 'virtual ptid_t fbsd_nat_target::wait(ptid_t, target_waitstatus*, target_wait_flags)':
+ fbsd-nat.c:1726:22: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
+ 1726 | for (inferior *inf : all_non_exited_inferiors (this))
+ | ^~~
+ fbsd-nat.c:1697:17: note: shadowed declaration is here
+ 1697 | inferior *inf = find_inferior_ptid (this, wptid);
+ | ^~~
+ fbsd-nat.c: In member function 'virtual void fbsd_nat_target::detach(inferior*, int)':
+ fbsd-nat.c:2044:18: error: variable 'wptid' set but not used [-Werror=unused-but-set-variable]
+ 2044 | ptid_t wptid = wait_1 (ptid, &ws, 0);
+ | ^~~~~
+ cc1plus: all warnings being treated as errors
+ =====================================================================
+
+ This patch includes the following non-functional changes,
+
+ 1. Remove unused variable "request".
+ 2. Rename inf to inf_p to avoid shadowed declaration warnings.
+ 3. Mark wptid as used when USE_SIGTRAP_SIGINFO is defined.
+
+ Tested on FreeBSD/aarch64 by rebuilding.
+
+ Approved-By: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-22 Tom Tromey <tromey@adacore.com>
+
+ Remove keywords from target debug printer names
+ I recently checked in a patch that removed the use of the "struct"
+ keyword in some spots. Doing this pointed out that the target
+ delegate code preserves this keyword -- but, with C++, it does not
+ really need to. This patch changes make-target-delegates.py to remove
+ these keywords, and updates target-debug.h to follow. This pointed
+ out that there was already one redudancy: both
+ target_debug_print_struct_inferior_p and target_debug_print_inferior_p
+ existed.
+
+ Tested by rebuilding.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30834 improve disassembly output for call and branch instructions
+ This patch makes the gprofng disassembler to emit, e.g.
+ call fprintf@plt [ 0x401060, .-0x49c]
+ instead of
+ call 0xfffffffffffffb64
+
+ I use bfd_get_synthetic_symtab() to get function names in the .plt section.
+ I have not yet modified Elf-reader in gprofng to remove parsing of .symtab or
+ .dynsym sections. But we plan to do it.
+
+ gprofng/ChangeLog
+ 2023-09-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30834
+ * src/Disasm.cc: Show the function name in the call instruction
+ and the relative address in the branch instruction. Remove unused code.
+ * src/Disasm.h (map_PC_to_func, get_funcname_in_plt): New functions.
+ * src/Elf.cc: Get function names for the .plt section.
+ * src/Elf.h (get_funcname_in_plt, get_bfd_symbols): New functions.
+ * src/Stabs.cc: Add pltSym to SymLst. Remove the conversion to uint32_t.
+
+2023-09-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-21 Thomas Weißschuh <thomas@t-8ch.de>
+
+ ld: write resolved path to included file to dependency-file
+ In ldfile_open_command_file_1() name written to the dependency files is
+ the name as specified passed to the "INCLUDE" directive.
+ This is before include-path processing so the tracked dependency
+ location is most likely wrong.
+
+ Instead track the opened file at the point where the resolved path is
+ actually available, in try_open().
+
+2023-09-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-21 Tom Tromey <tromey@adacore.com>
+
+ Remove stray trailing "," from DAP breakpoint.py
+ The buildbot pointed out that the last DAP series I checked in had an
+ issue. Looking into it, it seems there is a stray trailing "," in
+ breakpoint.py. This patch removes it.
+
+ This seems to point out a test suite deficiency. I will look into
+ fixing that.
+
+2023-09-20 Tom Tromey <tom@tromey.com>
+
+ Remove explanatory comments from includes
+ I noticed a comment by an include and remembered that I think these
+ don't really provide much value -- sometimes they are just editorial,
+ and sometimes they are obsolete. I think it's better to just remove
+ them. Tested by rebuilding.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-09-20 Gregory Anders <greg@gpanders.com>
+
+ gdb/dap: only include sourceReference if file path does not exist
+ According to the DAP specification if the "sourceReference" field is
+ included in a Source object, then the DAP client _must_ make a "source"
+ request to the debugger to retrieve file contents, even if the Source
+ object also includes path information.
+
+ If the Source's path field is a valid path that the DAP client is able
+ to read from the filesystem, having to make another request to the
+ debugger to get the file contents is wasteful and leads to incorrect
+ results (DAP clients will try to get the contents from the server and
+ display those contents as a file with the name in "source.path", but
+ this will conflict with the _acutal_ existing file at "source.path").
+
+ Instead, only set "sourceReference" if the source file path does not
+ exist.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-20 Gregory Anders <greg@gpanders.com>
+
+ gdb/dap: use breakpoint fullname to resolve source
+ If the breakpoint has a fullname, use that as the source path when
+ resolving the breakpoint source information. This is consistent with
+ other callers of make_source which also use "fullname" if it exists (see
+ e.g. DAPFrameDecorator which returns the symtab's fullname).
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-20 Gregory Anders <greg@gpanders.com>
+
+ gdb/dap: ignore unused keyword args in step_out
+ Some DAP clients may send additional parameters in the stepOut command
+ (e.g. "granularity") which are not used by GDB, but should nonetheless
+ be accepted without error.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-20 Gregory Anders <greg@gpanders.com>
+
+ gdb/dap: check for breakpoint source before unpacking
+ Not all breakpoints have a source location. For example, a breakpoint
+ set on a raw address will have only the "address" field populated, but
+ "source" will be None, which leads to a RuntimeError when attempting to
+ unpack the filename and line number.
+
+ Before attempting to unpack the filename and line number from the
+ breakpoint, ensure that the source information is not None. Also
+ populate the source and line information separately from the
+ "instructionReference" field, so that breakpoints that include only an
+ address are still included.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-20 Tom Tromey <tromey@adacore.com>
+
+ Run 'black' on printing.py
+ The buildbot pointed out that I neglected to re-run 'black' after
+ making some changes. This patch fixes the oversight.
+
+2023-09-20 Matthew "strager" Glazar <strager.nds@gmail.com>
+
+ gdb/tui: add 'set tui mouse-events off' to restore mouse selection
+ Rationale:
+ I use the mouse with my terminal to select and copy text. In gdb, I use
+ the mouse to select a function name to set a breakpoint, or a variable
+ name to print, for example.
+
+ When gdb is compiled with ncurses mouse support, gdb's TUI mode
+ intercepts mouse events. Left-clicking and dragging, which would
+ normally select text, seems to do nothing. This means I cannot select
+ text using my mouse anymore. This makes it harder to set breakpoints,
+ print variables, etc.
+
+ Solution:
+ I tried to fix this issue by editing the 'mousemask' call to only enable
+ buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
+ to not allow text to be selected. The only way I could make it work is
+ by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
+ entirely, which other people might want.
+
+ I therefore decided to make a setting in gdb called 'tui mouse-events'.
+ If enabled (the default), the behavior is as it is now: terminal mouse
+ events are given to gdb, disabling the terminal's default behavior.
+ If disabled (opt-in), the behavior is as it was before the year 2020:
+ terminal mouse events are not given to gdb, therefore the mouse can be
+ used to select and copy text.
+
+ Notes:
+ I am not attached to the setting name or its description. Feel free to
+ suggest better wording.
+
+ Testing:
+ I tested this change in gnome-terminal by performing the following steps
+ manually:
+
+ 1. Run: gdb --args ./myprogram
+ 2. Enable TUI: press ctrl-x ctrl-a
+ 3. Click and drag text with the mouse. Observe no selection.
+ 4. Input: set tui mouse-events off
+ 5. Click and drag text with the mouse. Observe that selection works now.
+ 6. Input: set tui mouse-events on.
+ 7. Click and drag text with the mouse. Observe no selection.
+
+2023-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Error out for .debug_types section in dwz file
+ There are two methods to factor out type information in a dwarf4 executable:
+ - use -fdebug-info-types to generate type units in a .debug_types section, and
+ - use dwz to create partial units.
+
+ The dwz method has an extra benefit: it also allows to factor out information
+ between executables into a newly created .dwz file, pointed to by a
+ .gnu_debugaltlink section.
+
+ There is nothing prohibiting a .gnu_debugaltlink file to contain a
+ .debug_types section.
+
+ It's just not generated by dwz or any other tool atm, and consequently gdb has
+ no support for it. Enhancement PR symtab/30838 is open about the lack of
+ support.
+
+ Make the current situation explicit by emitting a dwarf error:
+ ...
+ (gdb) file struct-with-sig-2^M
+ Reading symbols from struct-with-sig-2...^M
+ Dwarf Error: .debug_types section not supported in dwz file^M
+ ...
+ and add an assert in write_gdbindex:
+ ...
+ + /* See enhancement PR symtab/30838. */
+ + gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types));
+ ...
+ to clarify why we can use:
+ ...
+ data_buf &cu_list = (per_cu->is_debug_types
+ ? types_cu_list
+ : per_cu->is_dwz ? dwz_cu_list : objfile_cu_list);
+ ...
+
+ The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it
+ keeps the copyright years range.
+
+ Tested on x86_64-linux.
+
+ Tested-By: Guinevere Larsen <blarsen@redhat.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838
+
+2023-09-20 Song Mengzhi <song.mengzhi@zte.com.cn>
+
+ PR30870, VMS_DEBUG compilation error
+ Introduced by 8169954446.
+
+ PR 30870
+ * vms-alpha.c (image_write): Remove extraneous parenthesis.
+
+2023-09-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-19 Alan Modra <amodra@gmail.com>
+
+ readelf.c 'ext' may be used uninitialized
+ * readelf.c (display_lto_symtab): Init ext.
+
+2023-09-19 Alan Modra <amodra@gmail.com>
+
+ elf-attrs.c memory allocation fail
+ Report errors rather than segfaulting.
+
+ bfd/
+ * elf-attrs.c (elf_new_obj_attr): Return NULL on bfd_alloc fail.
+ (bfd_elf_add_obj_attr_int): Handle NULL return from the above,
+ and propagate return to callers.
+ (elf_add_obj_attr_string, elf_add_obj_attr_int_string): Likewise.
+ (bfd_elf_add_obj_attr_string): Similarly.
+ (_bfd_elf_copy_obj_attributes): Report error on alloc fails.
+ (_bfd_elf_parse_attributes): Likewise.
+ * elf-bfd.h (bfd_elf_add_obj_attr_int): Update prototype.
+ (bfd_elf_add_obj_attr_string): Likewise.
+ (bfd_elf_add_obj_attr_int_string): Likewise.
+ gas/
+ * config/obj-elf.c (obj_elf_vendor_attribute): Report fatal
+ error on out of memory from bfd attribute functions.
+ * config/tc-arc.c (arc_set_attribute_int): Likewise.
+ (arc_set_attribute_string, arc_set_public_attributes): Likewise.
+ * config/tc-arm.c (aeabi_set_attribute_int): Likewise.
+ (aeabi_set_attribute_string): Likewise.
+ * config/tc-mips.c (mips_md_finish): Likewise.
+ * config/tc-msp430.c (msp430_md_finish): Likewise.
+ * config/tc-riscv.c (riscv_write_out_attrs): Likewise.
+ * config/tc-sparc.c (sparc_md_finish): Likewise.
+ * config/tc-tic6x.c (tic6x_set_attribute_int): Likewise.
+ * config/tc-csky.c (md_begin): Likewise.
+ (set_csky_attribute): Return ok status.
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Handle pointers and references correctly in DAP
+ A user pointed out that the current DAP variable code does not let the
+ client deference a pointer. Oops!
+
+ Fixing this oversight is simple enough -- adding a new no-op
+ pretty-printer for pointers and references is quite simple.
+
+ However, doing this naive caused a regession in scopes.exp, which
+ expected there to be no children of a 'const char *' variable. This
+ problem was fixed by the preceding patches in the series, which ensure
+ that a C type of this kind is recognized as a string.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30821
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Give a language to a type
+ This changes main_type to hold a language, and updates the debug
+ readers to set this field. This is done by adding the language to the
+ type-allocator object.
+
+ Note that the non-DWARF readers are changed on a "best effort" basis.
+
+ This patch also reimplements type::is_array_like to use the type's
+ language, and it adds a new type::is_string_like as well. This in
+ turn lets us change the Python implementation of these methods to
+ simply defer to the type.
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Add is_array_like and to_array to language_defn
+ This adds new is_array_like and to_array methods to language_defn.
+ This will be used in a subsequent patch that generalizes the new
+ Python array- and string-handling code.
+
+ Regularize some DWARF type initialization
+ In one spot, it will be convenient for a subsequent patch if the CU is
+ passed to a type-creation helper function. In another spot, remove
+ the redundant 'objfile' parameter to another such function.
+
+ Pass a type allocator to init_fixed_point_type
+ init_fixed_point_type currently takes an objfile and creates its own
+ type allocator. However, for a later patch it is more convenient if
+ this function accepts a type allocator. This patch makes this change.
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::checked_static_cast for catchpoints
+ This replaces some casts to various kinds of catchpoint with
+ checked_static_cast.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::checked_static_cast for code_breakpoint
+ This replaces some casts to 'code_breakpoint *' with
+ checked_static_cast.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::checked_static_cast for tracepoints
+ This replaces some casts to 'tracepoint *' with checked_static_cast.
+ Some functions are changed to accept a 'tracepoint *' now, for better
+ type safety.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-19 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::checked_static_cast for watchpoints
+ This replaces some casts to 'watchpoint *' with checked_static_cast.
+ In one spot, an unnecessary block is also removed.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-19 Mohamed Bouhaouel <mohamed.bouhaouel@intel.com>
+
+ gdb, breakpoint: add a destructor to the watchpoint struct
+ Make sure to unlink the related breakpoint when the watchpoint instance
+ is deleted. This prevents having a wp-related breakpoint that is
+ linked to a NULL watchpoint (e.g. the watchpoint instance is being
+ deleted when the 'watch' command fails). With the below scenario,
+ having such a left out breakpoint will lead to a GDB hang, and this
+ is due to an infinite loop when deleting all inferior breakpoints.
+
+ Scenario:
+ (gdb) set can-use-hw-watchpoints 0
+ (gdb) awatch <SCOPE VAR>
+ Can't set read/access watchpoint when hardware watchpoints are disabled.
+ (gdb) rwatch <SCOPE VAR>
+ Can't set read/access watchpoint when hardware watchpoints are disabled.
+ (gdb) <continue the program until the end>
+ >> HANG <<
+
+ Reviewed-by: Bruno Larsen <blarsen@redhat.com>
+
+2023-09-19 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/cli: fixes to newly added "list ." command
+ After the series that added this command was pushed, Pedro mentioned
+ that the news description could easily be misinterpreted, as well as
+ some code and test improvements that should be made.
+
+ While fixing the test, I realized that code repetition wasn't
+ happening as it should, so I took care of that too.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-18 Tom Tromey <tom@tromey.com>
+
+ More type safety for symbol_search
+ This patch changes class symbol_search to store a block_enum rather
+ than an int.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-18 Tom Tromey <tromey@adacore.com>
+
+ Move val_prettyformat to valprint.h
+ I stumbled across an ancient FIXME comment that was easy to fix --
+ val_prettyformat does not need to be in defs.h, and is easily moved to
+ valprint.h, where (despite what the comment says) it belongs.
+
+ Tested by rebuilding.
+
+2023-09-18 Jacob Navia <jacob@jacob.remcomp.fr>
+
+ Fix: Use of uninitialized memory
+ * config/tc-riscv.c (riscv_ip_hardcode): Fully initialise the allocated riscv_opcode structure.
+
+2023-09-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused free_actions declaration
+ This appears to be a leftover from a past change.
+
+ Change-Id: I8e747edbf291400e4f417f5c6875049479a1669a
+
+2023-09-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix overly large gdb-index file check for 32-bit
+ Add a unit test which checks that write_gdb_index_1 will throw
+ an error when the size of the file would exceed the maximum value
+ capable of being represented by 'offset_type'.
+
+ The unit test fails on 32-bit systems due to wrapping overflow. Fix this by
+ changing the type of total_len in write_gdbindex_1 from size_t to uint64_t.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove -Werror annotations from MAINTAINERS file
+ I don't think these are useful nowadays, since we now expect all code to
+ be -Werror clean (it's the default in development branches).
+
+ Change-Id: I8c3b86c70d683bd41344d27add0ac2627a474d20
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/amdgpu: add precise-memory support
+ The amd-dbgapi library exposes a setting called "memory precision" for
+ AMD GPUs [1]. Here's a copy of the description of the setting:
+
+ The AMD GPU can overlap the execution of memory instructions with other
+ instructions. This can result in a wave stopping due to a memory violation
+ or hardware data watchpoint hit with a program counter beyond the
+ instruction that caused the wave to stop.
+
+ Some architectures allow the hardware to be configured to always wait for
+ memory operations to complete before continuing. This will result in the
+ wave stopping at the instruction immediately after the one that caused the
+ stop event. Enabling this mode can make execution of waves significantly
+ slower.
+
+ Expose this option through a new "amdgpu precise-memory" setting.
+
+ The precise memory setting is per inferior. The setting is transferred
+ from one inferior to another when using the clone-inferior command, or
+ when a new inferior is created following an exec or a fork.
+
+ It can be set before starting the inferior, in which case GDB will
+ attempt to apply what the user wants when attaching amd-dbgapi. If the
+ user has requested to enable precise memory, but it can't be enabled
+ (not all hardware supports it), GDB prints a warning.
+
+ If precise memory is disabled, GDB prints a warning when hitting a
+ memory exception (translated into GDB_SIGNAL_SEGV or GDB_SIGNAL_BUS),
+ saying that the stop location may not be precise.
+
+ Note that the precise memory setting also affects memory watchpoint
+ reporting, but the watchpoint support for AMD GPUs hasn't been
+ upstreamed to GDB yet. When we do upstream watchpoint support, GDB will
+ produce a similar warning message when stopping due to a watchpoint if
+ precise memory is disabled.
+
+ Add a handful of tests. Add a util proc
+ "hip_devices_support_precise_memory", which indicates if all devices
+ used for testing support that feature.
+
+ [1] https://github.com/ROCm-Developer-Tools/ROCdbgapi/blob/687374258a27b5aab1309a7e8ded719e2f1ed3b1/include/amd-dbgapi.h.in#L6300-L6317
+
+ Change-Id: Ife1a99c0e960513da375ced8f8afaf8e47a61b3f
+ Approved-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: add linux target check in allow_hipcc_tests
+ ROCm / HIP tests should only run on Linux for now, existing gdb.rocm
+ tests miss such a check. Add an "istarget linux" check in
+ allow_hipcc_tests.
+
+ Change-Id: I71f69e510a754f2fdadc32de53b923ebb9835ab5
+ Approved-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-09-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add inferior_cloned observable
+ The following patch makes the amdgpu port transfer a property from the
+ original inferior to the new inferior when using the clone-inferior
+ command. Add the inferior_cloned observable to help with this.
+
+ Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-15 Tom Tromey <tromey@adacore.com>
+
+ Fix build failure with GCC 4.8
+ A user pointed out that the build failed with GCC 4.8. The problem
+ was that the form used by the std::hash specialization of ptid_t was
+ not accepted. This patch rewrites this code into a form that is
+ acceptable to the older compiler.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-15 Laurent Morichetti <laurent.morichetti@amd.com>
+
+ gdb/amdgpu: Silence wave termination messages
+ After commit 9d7d58e7262, the amdgpu target started printing
+ "thread exited" messages when pruning waves that had terminated.
+
+ ...
+ [AMDGPU Wave ?:?:?:2045 (?,?,?)/? exited]
+ [AMDGPU Wave ?:?:?:2046 (?,?,?)/? exited]
+ [AMDGPU Wave ?:?:?:2047 (?,?,?)/? exited]
+ [AMDGPU Wave ?:?:?:2048 (?,?,?)/? exited]
+ ...
+
+ The issue was that before commit 9d7d58e7262, delete_thread was silent
+ by default due to a bug that the commit fixed.
+
+ Replaced the amdgpu target call to delete_thread with a call to
+ delete_thread_silent.
+
+ Change-Id: Ie5d5a4c5be851f092d2315b2afa6a36a30a05245
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add Lancelot Six as maintainer of the AMD GPU port
+ Lancelot has accepted to take the role of maintainer for the AMD GPU
+ port. The AMD GPU port (amdgpu as I've written in the MAINTAINERS file)
+ is an umbrella term for everything needed to make this work: the amdgcn
+ arch, the amd-dbgapi target, solib-rocm, etc.
+
+ Thanks for accepting the role, and congratulations!
+
+ Change-Id: I4c898042fda49b45dcb0d54ca94731bb57287f71
+
+2023-09-15 Tom Tromey <tromey@adacore.com>
+
+ Rename split_style::DOT
+ This renames split_style::DOT, to avoid name clashes when building gdb
+ with an old version of Bison (2.3, the version available on macOS).
+
+ In particular the error looks like:
+
+ ./split-name.h:34:3: error: expected identifier
+ DOT,
+ ^
+ m2-exp.c:163:13: note: expanded from macro 'DOT'
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286
+
+2023-09-15 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Fix alignment of the TLS Translation Control Block
+ The R_ARC_TLS_LE_32 is defined as S + A + TLS_TBSS - TLS_REL, where
+
+ - S is the base address of the symbol in the memory
+ - A is the symbol addendum
+ - TLS_TBSS is the TLS Translation Control Block size (aligned)
+ - TLS_REL is the base of the TLS section
+
+ Given the next code snip:
+
+ __thread int data_var = 12;
+ __attribute__((__aligned__(128))) __thread int data_var_128 = 128;
+ __thread int bss_var;
+ __attribute__((__aligned__(256))) __thread int bss_var_256;
+
+ int __start(void)
+ {
+ return data_var + data_var_128 + bss_var + bss_var_256;
+ }
+
+ The current code returns different TLS_TBSS values for .tdata and
+ .tbss. This patch fixes this by using the linker provided tls_sec.
+
+ bfd/
+
+ * elf32-arc.c (TLS_REL): Clean up.
+ (TLS_TBSS): Use tls_sec alignment.
+ (arc_do_relocation): Check if we have valid tls_sec.
+
+2023-09-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: small cleanup in symbol_file_add_with_addrs
+ While looking at how gdb::observers::new_objfile was used, I found
+ some code in symbol_file_add_with_addrs that I thought could be
+ improved.
+
+ Instead of:
+
+ if (condition)
+ {
+ ...
+ return;
+ }
+
+ ...
+ return;
+
+ Where some parts of '...' identical between the two branches. I think
+ it would be nicer if the duplication is removed, and we just use:
+
+ if (!condition)
+ ...
+
+ to guard the one statement that should only happen when the condition
+ is not true.
+
+ There is one change in this commit though that is (possibly)
+ significant, there is a call to bfd_cache_close_all() that was only
+ present in the second block. After this commit we now call that
+ function for both paths.
+
+ The call to bfd_cache_close_all was added in commit:
+
+ commit ce7d45220e4ed342d4a77fcd2f312e85e1100971
+ Date: Fri Jul 30 12:05:45 2004 +0000
+
+ with the purpose of ensuring that GDB doesn't hold the BFDs open
+ unnecessarily, thus preventing the files from being updated on some
+ hosts (e.g. Win32).
+
+ In the early exit case we previously didn't call bfd_cache_close_all,
+ with the result that GDB would continue to hold open some BFD objects
+ longer than needed.
+
+ After this commit, but calling bfd_cache_close_all for both paths this
+ problem is solved.
+
+ I'm not sure how this change could be tested, I don't believe there's
+ any GDB (maintenance) command that displays the BFD cache contents, so
+ we can't check the cache contents easily. Ideas are welcome though.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add some missing filename styling
+ Spotted a few places where we can add filename styling.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-15 Jinyang He <hejinyang@loongson.cn>
+
+ LoongArch: Enable gas sort relocs
+ The md_pre_output_hook creating fixup is asynchronous, causing relocs
+ may be out of order in .eh_frame. Define GAS_SORT_RELOCS so that reorder
+ relocs when write_relocs.
+
+ Reported-by: Rui Ueyama <rui314@gmail.com>
+
+2023-09-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold CpuLM and Cpu64
+ Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while
+ Cpu64 is solely used in insn templates, they no longer need to be
+ treated different from other "ordinary" flags; the only "unusual" one
+ left if CpuNo64. Fold both, leaving just Cpu64.
+
+2023-09-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't play with cpu_arch_flags.cpu{,no}64
+ A total four places exists where we set the two bits from flag_code, but
+ these values are never used. The two bits are evaluated only when coming
+ from insn templates.
+
+ Drop these assignments. Also make obvious that cpu_flags_check_cpu64()
+ is only ever used against insn templates.
+
+2023-09-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: make code size vs CPU arch checking consistent
+ While update_code_flag() checks for LM / i386, set_cpu_arch() so far
+ didn't, allowing e.g. 64-bit code to be emitted after ".arch generic32".
+
+ Oddly enough a few of our testcases actually exhibit bad behavior (and
+ hence need minor adjustments).
+
+2023-09-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-order update_code_flag()
+ Do checks before updating state, and bail upon failure of either of the
+ checks. While moving the code, eliminate some redundancy.
+
+2023-09-15 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: explicitly test for stderr in gdb.mi/mi-dprintf.exp
+ As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some
+ compilers such as clang don't add debug information about stderr by
+ default, leaving it to external debug packages.
+
+ This commit adds a way to check if GDB has access to stderr information
+ when in MI mode, and uses this new mechanism to skip the related section
+ of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a
+ test in that file.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-15 Kevin Buettner <kevinb@redhat.com>
+
+ Throw error when creating an overly large gdb-index file
+ The header in a .gdb_index section uses 32-bit unsigned offsets to
+ refer to other areas of the section. Thus, there is a size limit of
+ 2^32-1 which is currently unaccounted for by GDB's code for outputting
+ these sections.
+
+ At the moment, when GDB creates an overly large section, it will exit
+ abnormally due to an internal error, which is caused by a failed
+ assert in assert_file_size, which in turn is called from
+ write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c.
+
+ This is what happens when that assert fails:
+
+ $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
+ Reading symbols from ./libgraph_tool_inference.so...
+ No executable file now.
+ Discard symbol table from `libgraph_tool_inference.so'? (y or n) n
+ Not confirmed.
+ ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x55fddb4d78b0 gdb_internal_backtrace_1
+ ../../gdb/bt-utils.c:122
+ 0x55fddb4d78b0 _Z22gdb_internal_backtracev
+ ../../gdb/bt-utils.c:168
+ 0x55fddb98b5d4 internal_vproblem
+ ../../gdb/utils.c:396
+ 0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag
+ ../../gdb/utils.c:476
+ 0x55fddbb71654 _Z18internal_error_locPKciS0_z
+ ../../gdbsupport/errors.cc:58
+ 0x55fddb5a0f23 assert_file_size
+ ../../gdb/dwarf2/index-write.c:1069
+ 0x55fddb5a1ee0 assert_file_size
+ /usr/include/c++/13/bits/stl_iterator.h:1158
+ 0x55fddb5a1ee0 write_gdbindex_1
+ ../../gdb/dwarf2/index-write.c:1119
+ 0x55fddb5a51be write_gdbindex
+ ../../gdb/dwarf2/index-write.c:1273
+ [...]
+ ---------------------
+ ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
+
+ This problem was encountered while building the python-graph-tool
+ package on Fedora. The Fedora bugzilla bug can be found here:
+
+ https://bugzilla.redhat.com/show_bug.cgi?id=1773651
+
+ This commit prevents the internal error from occurring by calling error()
+ when the file size exceeds 2^32-1.
+
+ Using a gdb built with this commit, I now see this behavior instead:
+
+ $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
+ Reading symbols from ./libgraph_tool_inference.so...
+ No executable file now.
+ Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n
+ Not confirmed.
+ Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded
+ (gdb)
+
+ I wish I could provide a test case, but due to the sizes of both the
+ input and output files, I think that testing resources would be
+ strained or exceeded in many environments.
+
+ My testing on Fedora 38 shows no regressions.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-09-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix buffer overflow in DWARF reader
+ In this commit:
+
+ commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e
+ Date: Fri Nov 19 10:12:44 2021 -0700
+
+ Handle multiple addresses in call_site_target
+
+ a buffer overflow bug was introduced when the following code was
+ added:
+
+ CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
+ addresses.size ());
+ std::copy (addresses.begin (), addresses.end (), saved);
+
+ The definition of XOBNEWVAR is (from libiberty.h):
+
+ #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S)))
+
+ So 'saved' is going to point to addresses.size () bytes of memory,
+ however, the std::copy will write addresses.size () number of
+ CORE_ADDR sized entries to the address pointed to by 'saved', this is
+ going to result in memory corruption.
+
+ The mistake is that we should have used XOBNEWVEC, which allocates a
+ vector of entries, the definition of XOBNEWVEC is:
+
+ #define XOBNEWVEC(O, T, N) \
+ ((T *) obstack_alloc ((O), sizeof (T) * (N)))
+
+ Which means we will have set aside enough space to create a copy of
+ the contents of the addresses vector.
+
+ I'm not sure how to create a test for this problem, this issue cropped
+ up when debugging a particular i686 built binary, which just happened
+ to trigger a glibc assertion (likely due to random memory corruption),
+ debugging the same binary built for x86-64 appeared to work just fine.
+
+ Using valgrind on the failing GDB binary pointed straight to the cause
+ of the problem, and with this patch in place there are no longer
+ valgrind errors in this area.
+
+ If anyone has ideas for a test I'm happy to work on something.
+
+ Co-Authored-By: Keith Seitz <keiths@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/exp] Clean up asap in value_print_array_elements
+ I've been running the test-suite on an i686-linux laptop with 1GB of memory,
+ and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
+ not being able to spawn for a large number of test-cases afterwards.
+
+ So I investigated the memory usage, on my usual x86_64-linux development
+ platform.
+
+ The test-case is compiled with -DCRASH_GDB=2097152, so this:
+ ...
+ static int a[CRASH_GDB], b[CRASH_GDB];
+ ...
+ with sizeof (int) == 4 represents two arrays of 8MB each.
+
+ Say we add a loop around the "print a" command and print space usage
+ statistics:
+ ...
+ gdb_test "maint set per-command space on"
+ for {set i 0} {$i < 100} {incr i} {
+ gdb_test "print a"
+ }
+ ...
+
+ This gets us:
+ ...
+ (gdb) print a^M
+ $1 = {0 <repeats 2097152 times>}^M
+ Space used: 478248960 (+469356544 for this command)^M
+ (gdb) print a^M
+ $2 = {0 <repeats 2097152 times>}^M
+ Space used: 486629376 (+8380416 for this command)^M
+ (gdb) print a^M
+ $3 = {0 <repeats 2097152 times>}^M
+ Space used: 495009792 (+8380416 for this command)^M
+ ...
+ (gdb) print a^M
+ $100 = {0 <repeats 2097152 times>}^M
+ Space used: 1308721152 (+8380416 for this command)^M
+ ...
+
+ In other words, we start out at 8MB, and the first print costs us about 469MB,
+ and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
+ i686-linux laptop, the first print costs us 335MB. ]
+
+ The subsequent 8MBs are consistent with the values being saved into the value
+ history, but the usage for the initial print seems somewhat excessive.
+
+ There is a PR open about needing sparse representation of large arrays
+ (PR8819), but this memory usage points to an independent problem.
+
+ The function value_print_array_elements contains a scoped_value_mark to free
+ allocated values in the outer loop, but it doesn't prevent the inner loop from
+ allocating a lot of values.
+
+ Fix this by adding a scoped_value_mark in the inner loop, after which we have:
+ ...
+ (gdb) print a^M
+ $1 = {0 <repeats 2097152 times>}^M
+ Space used: 8892416 (+0 for this command)^M
+ (gdb) print a^M
+ $2 = {0 <repeats 2097152 times>}^M
+ Space used: 8892416 (+0 for this command)^M
+ (gdb) print a^M
+ $3 = {0 <repeats 2097152 times>}^M
+ Space used: 8892416 (+0 for this command)^M
+ ...
+ (gdb) print a^M
+ $100 = {0 <repeats 2097152 times>}^M
+ Space used: 8892416 (+0 for this command)^M
+ ...
+
+ Note that the +0 here just means that the mallocs did not trigger an sbrk.
+ This is dependent on malloc (which can use either mmap or sbrk or some
+ pre-allocated memory) and will likely vary between different tunings, versions
+ and implementations, so this does not give us a reliable way detect the
+ problem in a minimal way.
+
+ A more reliable way of detecting the problem is:
+ ...
+ void
+ value_free_to_mark (const struct value *mark)
+ {
+ + size_t before = all_values.size ();
+ auto iter = std::find (all_values.begin (), all_values.end (), mark);
+ if (iter == all_values.end ())
+ all_values.clear ();
+ else
+ all_values.erase (iter + 1, all_values.end ());
+ + size_t after = all_values.size ();
+ + if (before - after >= 1024)
+ + fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
+ ...
+ which without the fix tells us:
+ ...
+ +print a
+ value_free_to_mark freed 2097152 items
+ $1 = {0 <repeats 2097152 times>}
+ ...
+
+ Fix a similar problem for Fortran:
+ ...
+ +print array1
+ value_free_to_mark freed 4194303 items
+ $1 = (0, <repeats 2097152 times>)
+ ...
+ in fortran_array_printer_impl::process_element.
+
+ The problem also exists for Ada:
+ ...
+ +print Arr
+ value_free_to_mark freed 2097152 items
+ $1 = (0 <repeats 2097152 times>)
+ ...
+ but is fixed by the fix for C.
+
+ Add Fortran and Ada variants of the test-case. The *.exp files are similar
+ enough to the original to keep the copyright years range.
+
+ While writing the Fortran test-case, I ran into needing an additional print
+ setting to print the entire array in repeat form, filed as PR exp/30817.
+
+ I managed to apply the compilation loop for the Ada variant as well, but with
+ a cumbersome repetition style. I noticed no other test-case uses gnateD, so
+ perhaps there's a better way of implementing this.
+
+ The regression test included in the patch is formulated in its weakest
+ form, to avoid false positive FAILs, which also means that smaller regressions
+ may not get detected.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Modernize gdb.base/huge.exp
+ Rewrite test-case gdb.base/huge.exp:
+ - use build_executable rather than gdb_compile,
+ - use save_vars,
+ - factor out hardcoded loop limits min and max,
+ - handle compilation failure using require, and
+ - avoid using . in regexp to match $, {} and <>.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: Vxy naming correction
+ Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
+ operand purpose isn't properly reflected in Vxy's definition. Rename
+ "dst" to "src", thus bringing things in line with Exy.
+
+2023-09-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: support AVX10.1 vector size restrictions
+ Recognize "/<number>" suffixes on both -march=+avx10.1 and the
+ corresponding .arch directive, setting an upper bound on the vector size
+ that insns may use. Such a restriction can be reset by setting a new base
+ architecture, by using a suffix-less form, by disabling AVX10, or by
+ enabling any other VEX/EVEX-based vector extension.
+
+ While for most insns we can suppress their use with too wide operands
+ via registers becoming unavailable (or in Intel syntax memory operand
+ size specifiers not being recognized), mask register insns have to have
+ their minimum required vector size specified in a new attribute. (Of
+ course this new attribute could also be used on other insns.)
+
+ Note that .insn continues to be permitted to emit EVEX{512,256} (and
+ VEX256 ones) encodings regardless of vector size restrictions in place.
+ Of course these can't be expressed using zmm (or ymm) operands then,
+ but need using the EVEX.512.* forms (broadcast forms may be usable right
+ now, but this may go away so shouldn't be relied upon). This is why no
+ assertions should be added to build_{e,}vex_prefix().
+
+2023-09-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: support AVX10.1/512
+ Since this is merely a re-branding of certain AVX512* features, there's
+ little code to be added.
+
+ The main aspect here are new testcases. In order to be able to re-use
+ some of the existing testcases, several of them need their start symbols
+ adjusted. Note that 256- and 128-bit tests want adding here, as these
+ need to work right away. Subsequently they'll gain vector length
+ constraints.
+
+ Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
+ test.
+
+2023-09-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: make AES/PCMULQDQ respectively prereqs of VAES/VPCMULQDQ
+ These probably should have been put in place already anyway, but they're
+ very much wanted in order to then put AVX10.1 support on top. Note that
+ to avoid reverse dependencies towards SSE (just like we already do for
+ AVX and XOP), add_isa_dependencies() needs some further tweaking.
+
+ While there also address a related anomaly: Disabling AES but neither
+ AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
+ VEX-encoded forms available. Note that for this the VAES insns are moved
+ past the AVX+AES ones, to avoid the property-11 test suddenly failing.
+ The test really is wrong, but let's not also make things inconsistent:
+ Without the movement, YMM use would be correctly recorded for the
+ 128-bit forms simply because the first template already matches, as long
+ as VAES wasn't disabled. Yet it still wouldn't be if only AVX+AES were
+ enabled. Nor would behavior here then be the same as for VPCLMUL* insns.
+
+2023-09-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-13 Jacob Navia <jacob@jacob.remcomp.fr>
+
+ Fix: "Missing NULL check"
+ * elf.c (_bfd_elf_init_reloc_shdr): Don't segfault on alloc fail.
+
+2023-09-13 Alan Modra <amodra@gmail.com>
+
+ Fix: "Possible Memory leak in bed hash.c"
+ * elf-strtab.c (_bfd_elf_strtab_init): In the event of memory allocation failure, make sure that the hash table is freed.
+
+2023-09-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/mi: remove warning about mi1
+ Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI
+ version 1"). It is no longer possible to reach this warning, since
+ trying to use interpreter mi1 bails out before:
+
+ $ ./gdb -nx -q --data-directory=data-directory -i mi1
+ Interpreter `mi1' unrecognized
+
+ Change-Id: Ie43b21e01bca1407995150c729531a70ee662003
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-12 Tom Tromey <tromey@adacore.com>
+
+ Avoid spurious breakpoint-setting failure in DAP
+ A user pointed out that if a DAP setBreakpoints request has a 'source'
+ field in a SourceBreakpoint object, then the gdb DAP implementation
+ will throw an exception.
+
+ While SourceBreakpoint does not allow 'source' in the spec, it seems
+ better to me to accept it. I don't think we should fully go down the
+ "Postel's Law" path -- after all, we have the type-checker -- but at
+ the same time, if we do send errors, they should be intentional and
+ not artifacts of the implementation.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30820
+
+2023-09-12 Enze Li <enze.li@hotmail.com>
+
+ gdb: Fix -Wuninitialized issue
+ I see the following warning when building GDB on FreeBSD/amd64 with
+ Clang 14,
+
+ ======================================================================
+ CXX mdebugread.o
+ mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized]
+ f->set_loc_enumval (tsym.value);
+ ^
+ mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning
+ struct field *f;
+ ^
+ = nullptr
+ ======================================================================
+
+ after digging a little, I realized that we can not simply do what
+ Clang 14 says.
+
+ The root cause of this issue is that we lost the initialization of
+ the variable 'f' in this commit,
+
+ commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e
+ Date: Thu Aug 31 09:37:44 2023 +0200
+
+ [gdb/symtab] Factor out type::{alloc_fields,copy_fields}
+
+ we have made these modifications,
+
+ ---------------------------------------------------------------------
+ --- a/gdb/mdebugread.c
+ +++ b/gdb/mdebugread.c
+ @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,
+
+ t->set_code (type_code);
+ t->set_length (sh->value);
+ - t->set_num_fields (nfields);
+ - f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field)));
+ - t->set_fields (f);
+ + t->alloc_fields (nfields, false);
+ ---------------------------------------------------------------------
+
+ The problem is that the variable 'f' is used in the second half of
+ parse_symbol, that's why Clang complained.
+
+ To fix this issue we need to ensure that the varibale 'f' is
+ initialized. Calling the fields method is an obvious way to fix this
+ issue.
+
+ Tested on FreeBSD/amd64 by rebuilding.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-09-12 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/testsuite/rocm: fix rocm-multi-inferior-gpu.cpp
+ The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a
+ call to execl which does not have NULL as a last argument. This is
+ an invalid use of execl. This patch fixes this oversight.
+
+ Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-11 Tom Tromey <tromey@adacore.com>
+
+ Specialize std::hash for ptid_t
+ This changes hash_ptid to instead be a specialization of std::hash.
+ This makes it a little easier to use with standard containers.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-09-11 Tom Tromey <tromey@adacore.com>
+
+ Update Python signal-handling documentation
+ I noticed a typo in the "Basic Python" node, and when fixing it
+ realized that the paragraph could use a link to the block_signals
+ function. This patch is the result.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: use foreach_with_prefix in gdb.guile/scm-ports.exp
+ Simplify things a bit using foreach_with_prefix. The only expected
+ change is in the naming of tests.
+
+ Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-09-11 Ijaz, Abdul B <abdul.b.ijaz@intel.com>
+
+ testsuite, fortran: Fix regression due to fix for ifort's 'start' behavior
+ Got a regression email due to merge of commit in CI config
+ tcwg_gdb_check/master-aarch64 :
+ https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec
+
+ Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above
+ commit to start the test from running to line with tag "First Breakpoint"
+ instead of "fortran_runto_main". Reason of the regression is shared
+ libraries are still loaded after hitting the breakpoint as "nosharedlibrary"
+ is already called before hitting the breakpoint.
+
+ So now after this change test is updated accordingly to disable and unload
+ shared libraries symbols after hitting the first breakpoint.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-09-11 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb: c++ify btrace_target_info
+ Following the example of private_thread_info and private_inferior, turn
+ struct btrace_target_info into a small class hierarchy.
+
+ Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into
+ linux_btrace_target_info.
+
+ Fixes PR gdb/30751.
+
+2023-09-11 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, btrace: move xml parsing into remote.c
+ The code is only used in remote.c and all functions can be declared static.
+
+2023-09-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs
+ I see the following failure when running this test on an AMD machine:
+
+ p/x $fioff^M
+ $24 = 0x0^M
+ (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff
+
+ The register that GDB calls fioff normally contains the address of the
+ last instruction executed by the x87 unit. It is available through the
+ FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
+ area. You can read about it in the Intel manual [1] at section "10.5.1
+ FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
+ manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
+ State".
+
+ The test therefore expects that after executing the FLD1 instruction,
+ the fioff register contains the address of the FLD1 instruction.
+
+ However, the FXSAVE and XSAVE instructions (which the kernel uses to
+ dump x87 register state which it provides GDB through ptrace) behave
+ differently on AMD CPUs. In section "11.4.4.3 FXSAVE and FXRSTOR
+ Instructions" of the AMD manual, we read:
+
+ The FXSAVE and FXRSTOR instructions save and restore the entire
+ 128-bit media, 64-bit media, and x87 state. These instructions
+ usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
+ not normally save and restore the x87 exception pointers
+ (last-instruction pointer, last data-operand pointer, and last
+ opcode). The only case in which they do save the exception pointers
+ is the relatively rare case in which the exception-summary bit in
+ the x87 status word (FSW.ES) is set to 1, indicating that an
+ unmasked exception has occurred.
+
+ So, unless a floating point exception happened and that exception is
+ unmasked in the x87 FPU control register (which isn't by default on
+ Linux, from what I saw), the "last instruction address" register (or
+ fioff as GDB calls it) will always be 0 on an AMD CPU.
+
+ For this reason, I think it's fine to change the test to accept the
+ value 0 - that's just how the processor works.
+
+ I toyed with the idea of changing the test program to make it so the CPU
+ would generate a non-zero fioff. That is by unmasking an FPU exception
+ and executing an instruction to raise that kind exception. It worked,
+ but then I would have to change the test more extensively, and it didn't
+ seem to be worth it.
+
+ [1] https://cdrdv2.intel.com/v1/dl/getContent/671200
+ [2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf
+
+ Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-09-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-09 Jinyang He <hejinyang@loongson.cn>
+
+ Make sure DW_CFA_advance_loc4 is in the same frag
+ Do the same as commit b9d8f5601bcf in another place generating
+ DW_CFA_advance_loc4. The idea behind commit b9d8f5601bcf was that
+ when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
+ eh_frame_convert_frag we want to remove the opcode entirely, not just
+ convert to a nop. If the opcode was split over two frags then a size
+ adjustment would need to be done to the first frag, not just the
+ second as is correct for other cases with split frags. This would
+ complicate the eh relaxation. It's easier to ensure the frag is not
+ split.
+
+ * ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4
+ to be placed in a different frag to the rs_cfa.
+
+2023-09-08 Tom Tromey <tromey@adacore.com>
+
+ Run 'black' on recent test case
+ The auto-builders pointed out that I neglected to run 'black' after a
+ rest testcase change. This patch fixes the oversight.
+
+2023-09-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Set insn_type for branch instructions on aarch64
+ gprofng uses insn_type in print_address_func().
+ But insn_type is always zero on aarch64.
+
+ opcodes/ChangeLog:
+ 2023-09-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
+ branch instructions.
+
+2023-09-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/doc: describe x87 registers
+ While investigating this [1], I initially had no idea what register
+ "fioff" stood for, making it difficult to map it to something in the
+ Intel or AMD manuals. Similarly, I can imaging someone familiar with
+ x87 to want to print the "x87 last instruction address", and have no
+ clue that GDB makes it available as register "fioff". The names of the
+ x87 state fields don't seem to be standardized, they even change between
+ sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
+ descriptions).
+
+ Add some details to the doc to help one map GDB register names to x87
+ state fields.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u
+
+ Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-09-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/doc: rename "x86 Architecture-specific Issues" section to "x86"
+ I'm looking to add some x86-specific information to the doc, but I find
+ the naming of this section odd. It doesn't really talk about issues, it
+ just gives generally useful information. Also, the sections about other
+ architectures don't mention "issues", just the architecture name.
+
+ Also, at least in the HTML version of the doc, the name is inconsistent
+ between the main table of content, where it appears as "x86
+ Architecture-specific Issues", and the sub-table of contents of the
+ "Architectures" section, where it appears as "i386".
+
+ Rename the section to just "x86".
+
+ Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-08 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Remove unused function
+ set_expected_error is no longer used. It has been replaced by
+ more specific error messages.
+
+2023-09-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make gdb.dwarf2/dwzbuildid.exp more robust
+ I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
+ and noticed that compilation failure for one exec prohibited testing of all
+ execs.
+
+ Fix this by restructuring the test-case, such that we have:
+ ...
+ PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
+ PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
+ UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
+ UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
+ ...
+
+ Tested on x86_64-linux.
+
+2023-09-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add kfail in gdb.dwarf2/dwzbuildid.exp
+ When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
+ get:
+ ...
+ (gdb) file dwzbuildid-mismatch^M
+ Reading symbols from dwzbuildid-mismatch...^M
+ warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
+ could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
+ (gdb) delete breakpoints^M
+ (gdb) info breakpoints^M
+ No breakpoints or watchpoints.^M
+ (gdb) break -qualified main^M
+ No symbol table is loaded. Use the "file" command.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
+ ...
+
+ This is PR symtab/26797: when using readnow, a failure in reading the dwarf
+ results in the minimal symbols not being available.
+
+ Add a corresponding KFAIL.
+
+ Tested on x86_64-linux.
+
+2023-09-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add aranges in gdb.dwarf2/dwzbuildid.exp
+ While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
+ into a warning:
+ ...
+ $ readelf -w dwzbuildid-ok > READELF
+ readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
+ point to a CU header.
+ ...
+
+ AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.
+
+ While looking at the .debug_aranges section, I noticed that the entries for
+ the CUs generated by the dwarf assembler are missing.
+
+ Fix this by adding the missing .debug_aranges entries.
+
+ Tested on x86_64-linux.
+
+2023-09-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix build-ids in gdb.dwarf2/dwzbuildid.exp
+ When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
+ readelf, I run into:
+ ...
+ $ readelf -w dwzbuildid-ok > READELF
+ readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
+ readelf: Warning: Build-ID is too short (0x6 bytes)
+ ...
+
+ Fix this by ensuring the Build-IDs are the required 20 bytes.
+
+ Tested on x86_64-linux.
+
+2023-09-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.mi/mi-condbreak-throw.exp failure
+ In commit:
+
+ commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae
+ Date: Tue Aug 8 10:45:20 2023 +0100
+
+ gdb: MI stopped events when unwindonsignal is on
+
+ a new test, gdb.mi/mi-condbreak-throw.exp, was added. Unfortunately,
+ this test would fail when using the native-gdbserver board (and other
+ similar boards).
+
+ The problem was that one of the expected output patterns included some
+ output from the inferior. When using the native-gdbserver board, this
+ output is not printed to GDB's tty, but is instead printed to
+ gdbserver's tty, the result is that the expected output no longer
+ matches, and the test fails.
+
+ Additionally, as the output is actually from the C++ runtime, rather
+ than the test's source file, changes to the C++ runtime could cause
+ the output to change.
+
+ To solve both of these issues, in this commit, I'm removing the
+ reference to the inferior's output, and replacing it with '.*', which
+ will skip the output if it is present, but is equally happy if the
+ output is not present.
+
+ After this commit gdb.mi/mi-condbreak-throw.exp now passes on all
+ boards, including native-gdbserver.
+
+2023-09-08 Jan Beulich <jbeulich@suse.com>
+
+ x86: restrict prefix use with .insn VEX/XOP/EVEX
+ Avoid triggering the respective abort() in output_insn().
+
+2023-09-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove interp_supports_command_editing
+ It is a trivial wrapper around the supports_command_editing method,
+ remove it.
+
+ Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove interp_pre_command_loop
+ It is a trivial wrapper around the pre_command_loop method, remove it.
+
+ Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: make kfail gfortran specific
+ The modified test in function-calls.exp actually passes with ifort and
+ ifx. The particular fail seems to be specific to gfortran. When the
+ test was introduced it was only tested with gfortran (actually the
+ whole patch was written with gfortran and the GNU Fortran argument
+ passing convention in mind).
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: adapt tests for ifort's 'start' behavior
+ The modified tests array-slices-bad.exp and vla-type.exp both set a
+ breakpoint at the first real statement in the respective executables.
+
+ Normally, the expected behavior of fortran_runto_main for these would be
+ the stopping of the debugger at exactly the first statment in the code.
+
+ Strangely, neither gfortran nor ifx seem to do this for these tests.
+ Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB
+ stop at the 'program ...' line and gfortran stops at a variable
+ declaration line. E.g. for vla-type it stops at
+
+ 41 type(five) :: fivearr (2)
+
+ So, actually, ifort's behavior can be considered to be a bit more
+ 'correct' here. This patch remove the fortran_runto_main in the
+ two tests and instead uses runto to directly run to the first breakpoint
+ set at the first program statement. This works with both compiler
+ behaviors and makes the tests more robust.
+
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: Remove self assignment non-statements
+ There were a couple of places in the testsuite where instructions like
+
+ var = var
+
+ were written in the source code of tests. These were usually dummy
+ statements meant to generate a line table entry at that line on which
+ to break later on.
+
+ This worked fine for gfortran and ifx, but it seems that, when compiled
+ with ifort (2021.6.0) these statements do not actually create any
+ assmbler instructions and especially no line table entries. Consider
+ the program
+
+ program test
+ Integer var :: var = 1
+ var = var
+ end program
+
+ compiled with gfortran (13.0.0, -O0 -g). The linetable as emitted by
+ 'objdump --dwarf=decodedline ./a.out' looks like
+
+ test.f90:
+ File name Line number Starting address View Stmt
+ test.f90 1 0x401172 x
+ test.f90 3 0x401176 x
+ test.f90 4 0x401182 x
+ test.f90 4 0x401185 x
+ test.f90 4 0x401194 x
+ test.f90 - 0x4011c0
+
+ actually containing line table info for line 3. Running gdb, breaking
+ at 3 and checking the assembly we see
+
+ 0x0000000000401172 <+0>: push %rbp
+ 0x0000000000401173 <+1>: mov %rsp,%rbp
+ => 0x0000000000401176 <+4>: mov 0x2ebc(%rip),%eax # 0x404038 <var.1>
+ 0x000000000040117c <+10>: mov %eax,0x2eb6(%rip) # 0x404038 <var.1>
+ 0x0000000000401182 <+16>: nop
+ 0x0000000000401183 <+17>: pop %rbp
+ 0x0000000000401184 <+18>: ret
+
+ so two mov instructions are being issued for this assignment one copying
+ the value into a register and one writing it back to the same memory.
+ Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here
+ and also has no line table entry:
+
+ test.f90:
+ File name Line number Starting address View Stmt
+ test.f90 1 0x4040f8 x
+ test.f90 4 0x404109 x
+ test.f90 4 0x40410e x
+ test.f90 - 0x404110
+
+ As I do not think that this is really a bug (on either side, gfortran/ifx or
+ ifort), and as I don't think this behavior is covered in the Fortran
+ standard, I changed these lines to become actual value assignments.
+
+ This removes a few FAILs in the testsuite when ran with ifort.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-09-07 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: make mixed-lang-stack less compiler dependent
+ In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
+ bunch of nested function calls we issue and test a 'info args' command
+ for the mixed_func_1b function (when in that function's frame).
+
+ The signature of the function looks like
+
+ subroutine mixed_func_1b(a, b, c, d, e, g)
+ use type_module
+ implicit none
+
+ integer :: a
+ real(kind=4) :: b
+ real(kind=8) :: c
+ complex(kind=4) :: d
+ character(len=*) :: e
+ character(len=:), allocatable :: f
+ TYPE(MyType) :: g
+
+ and usually one would expect arguments a, b, c, d, e, and g to be
+ emitted here. However, due to some compiler dependent treatment of the
+ e array the actual output in the test (with gfortran/ifx) is
+
+ (gdb) info args
+ a = 1
+ b = 2
+ c = 3
+ d = (4,5)
+ e = 'abcdef'
+ g = ( a = 1.5, b = 2.5 )
+ _e = 6
+
+ where the compiler generated '_e' is emitted as the length of e. While
+ ifort also generates an additional length argument, the naming (which is
+ up to the compilers here I think, I could not find anything in the
+ Fortran standard about this) is different and we see
+
+ (gdb) info args
+ a = 1
+ b = 2
+ c = 3
+ d = (4,5)
+ e = 'abcdef'
+ g = ( a = 1.5, b = 2.5 )
+ .tmp.E.len_V$4a = 6
+
+ To make both outputs pass the test, I kept the additional argument for now and
+ made the regex for the emitted name of the last variable match any
+ arbitrary name.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-09-07 Ijaz, Abdul B <abdul.b.ijaz@intel.com>
+
+ gdb: add Abdul Basit Ijaz to gdb/MAINTAINERS
+
+2023-09-07 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: Add a testcase for bundles with KVXMAXBUNDLEWORDS syllables
+ * testsuite/gas/kvx/fat-bundles.s: New test.
+ * testsuite/gas/kvx/kv3-1-fat-bundles.d: New test.
+ * testsuite/gas/kvx/kv3-2-fat-bundles.d: New test.
+
+2023-09-07 Alan Modra <amodra@gmail.com>
+
+ PR30793, kvx_reassemble_bundle index 8 out of bounds
+ While the patch already committed for pr30793 prevents the asan error,
+ there is a problem: Now the last element of bundle_words never gets
+ written. That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
+ So this patch rearranges things a little to support writing of all of
+ bundle_words and does the parallel bit checking only when filling
+ bundle_words. In the normal case, kvx_reassemble_bundle will see
+ bundle_words[word_count-1] with the parallel bit clear and all other
+ words having it set. In the error case where all words in
+ bundle_words have the parallel bit set, kvx_reassemble_bundle will be
+ passed a wordcount of KVXMAXBUNDLEWORDS + 1. I've also made
+ kvx_reassemble_bundle return true for success rather than zero, and
+ removed the unnecessary check for zero wordcount.
+
+ PR 30793
+ * kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
+ Fail if wordcount is too large. Don't check for wordcount zero.
+ Don't check kvx_has_parallel_bit.
+ (print_insn_kvx): Rewrite code reading bundle_words as a for loop.
+ Don't stop reading at KVXMAXBUNDLEWORDS - 1.
+ (decode_prologue_epilogue_bundle): Similarly.
+
+2023-09-07 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in -var-evaluate-expression
+ This bug points out that if one uses -var-set-visualizer with "None"
+ -- to disable a pretty-printer for a varobj -- then
+ -var-evaluate-expression will still use pretty-printing.
+
+ This is a combination of bugs. First, setting the visualizer does not
+ update the display text; and second, computing the display text should
+ use "raw" when Python is available but no visualizer is desired.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-09-07 Tom Tromey <tromey@adacore.com>
+
+ Remove variable_default_display
+ variable_default_display has a single caller now, so remove it.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-09-07 Tom Tromey <tromey@adacore.com>
+
+ Remove dead code from varobj_set_display_format
+ varobj_set_display_format takes an enum and exhaustively switches on
+ the values -- but also has a default. This default case is dead code.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-09-07 Tom Tromey <tromey@adacore.com>
+
+ Allow pretty-printer 'children' method to return strings
+ A user noticed that, while a pretty-printer can return Python strings
+ from its "children" method, this does not really work for MI. I
+ tracked this down to my_value_of_variable calling into
+ c_value_of_variable, which specially handles arrays and structures --
+ not using the actual contents of the string.
+
+ Now, this part of MI seems bad to me, but rather than change that,
+ this applies the fix to only dynamic varobjs, which is the only
+ scenario where a string like this can really be returned.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix gdb-index writing for .debug_types
+ With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run
+ into:
+ ...
+ (gdb) print red^M
+ No definition of "red" in current context.^M
+ (gdb) FAIL: gdb.ada/same_enum.exp: print red
+ ...
+
+ [ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"),
+ so this is broken in gdb 12 and 13. ]
+
+ The easiest way to see what's going wrong is with readelf. We have in section
+ .gdb_index:
+ ...
+ [7194] pck__red:
+ 2 [static, variable]
+ 3 [static, variable]
+ ...
+ which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but
+ should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and
+ "T3").
+
+ Fix this by removing the counter / types_counter distinction in
+ write_gdbindex, such that we get the expected:
+ ...
+ [7194] pck__red:
+ T2 [static, variable]
+ T3 [static, variable]
+ ...
+
+ [ While reading write_gdbindex I noticed a few oddities related to dwz
+ handling, I've filed PR30829 about this. ]
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30827
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827
+
+2023-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Extend type equivalence test in ada_resolve_enum
+ When running test-case gdb.ada/local-enum.exp with target board debug-types, I
+ run into:
+ ...
+ (gdb) print v1(three)^M
+ No name 'three' in enumeration type 'local__e1'^M
+ (gdb) FAIL: gdb.ada/local-enum.exp: print v1 element
+ ...
+
+ The array V1 is of type A1 which is an array with index type E1, containing
+ "three" as enumerator:
+ ...
+ type E1 is (one, two, three);
+ type A1 is array (E1) of Integer;
+ V1 : A1 := (0, 1, 2);
+ ...
+
+ There's also a type E2 that contains three as enumerator:
+ ...
+ type E2 is (three, four, five);
+ ...
+
+ When doing "print v1(three)", it's the job of ada_resolve_enum to resolve
+ "three" to type E1 rather than type E2.
+
+ When using target board debug-types, the enums E1 and E2 are replicated in the
+ .debug_types section, and consequently in ada_resolve_enum the type
+ equivalence check using a pointer comparison fails:
+ ...
+ for (int i = 0; i < syms.size (); ++i)
+ {
+ /* We already know the name matches, so we're just looking for
+ an element of the correct enum type. */
+ if (ada_check_typedef (syms[i].symbol->type ()) == context_type)
+ return i;
+ }
+ ...
+
+ Fix this by also trying a structural comparison using
+ ada_identical_enum_types_p.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR ada/29335
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335
+
+2023-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Move identical enums handling later
+ When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
+ cc-with-dwz, I run into:
+ ...
+ (gdb) print enum_with_gaps'enum_rep(lit3)^M
+ 'Enum_Rep requires argument to have same type as enum^M
+ (gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
+ ...
+
+ With target_board unix, we have instead:
+ ...
+ (gdb) print enum_with_gaps'enum_rep(lit3)^M
+ $16 = 13^M
+ (gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
+ ...
+
+ Conversely, when I add this test to the test-case:
+ ...
+ gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
+ "enum_rep"
+ + gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
+ + "other enum_rep"
+ ...
+ the extra test passes with target board cc-with-dwz, but fails with target
+ board unix.
+
+ The problem is here in remove_extra_symbols:
+ ...
+ if (symbols_are_identical_enums (syms))
+ syms.resize (1);
+ ...
+ where one of the two identical enums is picked before the enum_rep handling
+ can resolve lit3 to one of the two.
+
+ Fix this by moving the code to ada_resolve_variable.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR ada/30726
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726
+
+2023-09-07 Tom Tromey <tom@tromey.com>
+
+ Simplify block_find_symbol
+ block_find_symbol takes a callback function, but only two callbacks
+ are ever passed to it -- and they are similar enough that it seems
+ cleaner to just have block_find_symbol do the work itself. Also,
+ block_find_symbol can take a lookup_name_info as an argument,
+ following the general idea of pushing the construction of these
+ objects as high in the call chain as feasible.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2023-09-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/mi: make current_token a field of mi_interp
+ Following the commit f818c32ba459 ("gdb/mi: fix ^running record with
+ multiple MI interpreters"), I thought it would make sense to make
+ current_token a field of mi_interp. This variable contains the token of
+ the currently handled MI command, like the 222 in:
+
+ 222-exec-continue
+
+ I didn't find any bug related to that, it's just a "that seems nicer"
+ cleanup, since the current token is a fundamentally per-interp thing.
+
+ mi_execute_command needs a check similar to what we already have in
+ mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current
+ interpreter is not an mi_interp. When using the Python gdb.execute_mi
+ function, there is no such concept of token, so we can just skip that.
+
+ There should be no user-visible change.
+
+ Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix indentation in mi/mi-parse.h
+ Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8
+
+2023-09-07 cailulu <cailulu@loongson.cn>
+
+ Add testcase for generation of 32/64_PCREL.
+
+2023-09-07 cailulu <cailulu@loongson.cn>
+
+ Use 32/64_PCREL to replace a pair of ADD32/64 and SUB32/64.
+ Subtraction for labels that require static relocation
+ usually generates ADD32/64 and SUB32/64.
+
+ If subsy of BFD_RELOC_32/64 and PC in same segment,
+ and disable relax or PC at start of subsy or enable
+ relax but not in SEC_CODE, we generate 32/64_PCREL
+ to replace a pair of ADD32/64 and SUB32/64.
+
+2023-09-07 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Clarify the naming rules of vendor operands.
+ The vendor operands should be named starting with `X', and preferably the
+ second letter (or multiple following letters) is enough to differentiate
+ them from other vendors.
+
+ Therefore, added letter `t' after `X' for t-head operands, to differentiate
+ from future different vendor's operands.
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
+ document link since it should already be recorded in the
+ gas/doc/c-riscv.texi.
+ gas/
+ * config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
+ t-head operands. Minor updates for indents and comments.
+ (riscv_ip): Likewise.
+ * doc/c-riscv.texi: Minor updates.
+ opcodes/
+ * riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
+ operands. Minor updates for indents and comments.
+ * riscv-opc.c (riscv_opcode): Likewise.
+
+2023-09-07 Roland McGrath <mcgrathr@google.com>
+
+ gold: Use char16_t, char32_t instead of uint16_t, uint32_t as character types
+ The std::basic_string template type is only specified for
+ instantiations using character types. Newer (LLVM) libc++
+ implementations no longer allow non-character integer types
+ to be used.
+
+ gold/
+ * output.cc: Include <uchar.h>.
+ (Output_section::add_merge_input_section): Use char16_t and
+ char32_t for 2- and 4-byte entry size, respectively.
+ * stringpool.cc: Include <uchar.h>.
+ (Stringpool_template): Explicitly instantiate for char16_t,
+ char32_t instead of uint16_t, uint32_t.
+ * merge.cc (Output_merge_string): Likewise.
+
+2023-09-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-07 Alan Modra <amodra@gmail.com>
+
+ PR30828, notes obstack memory corruption
+ Commit 3bab069c29b3 carelessly allowed "string" to be released from
+ the notes obstack twice, with the second call to obstack_free
+ releasing memory for a fixup that just happened to be the same size as
+ the original string. The fixup then of course was overwritten.
+ This patch fixes that problem, and another that could occur on an
+ error path.
+
+ PR 30828
+ * stabs.c (s_stab_generic): Don't free string twice. Don't
+ blow away entire notes obstack on a missing string.
+
+2023-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/same_enum.exp
+ Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
+ bit of code in remove_extra_symbols:
+ ...
+ if (symbols_are_identical_enums (syms))
+ syms.resize (1);
+ ...
+
+ The test-case does "print red" and expects one of these two choices to be
+ picked by remove_extra_symbols:
+ ...
+ type Color is (Black, Red, Green, Blue, White);
+ type RGB_Color is new Color range Red .. Blue;
+ ...
+ but because only the type Color is used:
+ ...
+ FC : Color := Red;
+ SC : Color := Green;
+ ...
+ the RGB_Color type is eliminated from the debug info, and consequently
+ remove_extra_symbols has no effect for the test-case.
+
+ In other words, we have:
+ ...
+ (gdb) ptype Color ^M
+ type = (black, red, green, blue, white)^M
+ (gdb) ptype RGB_Color^M
+ No definition of "rgb_color" in current context.^M
+ ...
+
+ Fix this by changing the type of SC to RGB_Color, and add prints of the two
+ types to check that they're both available.
+
+ With the test-case fixed, if we disable the bit of code in
+ remove_extra_symbols we get:
+ ...
+ (gdb) print red^M
+ Multiple matches for red^M
+ [0] cancel^M
+ [1] pck.color'(pck.red) (enumeral)^M
+ [2] pck.rgb_colorB'(pck.red) (enumeral)^M
+ > FAIL: gdb.ada/same_enum.exp: print red (timeout)
+ ...
+ in other words, the test-case now properly functions as a regression test.
+
+ Tested on x86_64-linux.
+
+2023-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix too many symbols in gdbpy_lookup_static_symbols
+ When running test-case gdb.python/py-symbol.exp with target board
+ cc-with-dwz-m, we run into:
+ ...
+ (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
+ 4^M
+ (gdb) FAIL: gdb.python/py-symbol.exp: \
+ print (len (gdb.lookup_static_symbols ('rr')))
+ ...
+ while with target board unix we have instead:
+ ...
+ (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
+ 2^M
+ (gdb) PASS: gdb.python/py-symbol.exp: \
+ print (len (gdb.lookup_static_symbols ('rr')))
+ ...
+
+ The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits
+ representing both CUs and PUs:
+ ...
+ for (compunit_symtab *cust : objfile->compunits ())
+ ...
+
+ When doing a lookup on a PU, the user link is followed until we end up at a CU,
+ and the lookup is done in that CU.
+
+ In other words, when doing a lookup in the loop for a PU we duplicate the
+ lookup for a CU that is already handled by the loop.
+
+ Fix this by skipping PUs in the loop in gdb.lookup_static_symbols.
+
+ Tested on x86_64-linux.
+
+ PR symtab/25261
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261
+
+2023-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle PU in iterate_over_some_symtabs
+ When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
+ run into:
+ ...
+ (gdb) info line 1^M
+ Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
+ Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
+ (gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
+ ...
+ while the expected output is:
+ ...
+ Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
+ ��setshow.c:1:0:beg:0x400527
+ ...
+
+ The second line of the expected output is missing due to the first line of the
+ expected output being repeated, so the problem is that the "Line 1" line is
+ printed twice.
+
+ This happens because the PU imported by the CU reuses the filetab of the CU,
+ and both the CU and PU are visited by iterate_over_some_symtabs.
+
+ Fix this by skipping PUs in iterate_over_some_symtabs.
+
+ Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30797
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797
+
+2023-09-06 Hans-Peter Nilsson <hp@axis.com>
+
+ src-release.sh (SIM_SUPPORT_DIRS): Add libsframe, libctf/swap.h and gnulib
+ Without this, a simulator build breaks when building from a tarball
+ made by "./src-release.sh -b sim", when building e.g. bfd and
+ libsframe. See also previous similar commits for GDB_SUPPORT_DIRS.
+
+ The libctf library does not needed to be built, but building
+ libsframe requires libctf/swap.h, with no dependencies on built or
+ configured contents. Do as for the single gdb files and include
+ explicitly only that file.
+
+2023-09-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Fix 30808 gprofng tests failed
+ In gprofng testing, we need a tempory gprofng installation to resolve run-time
+ dependencies on libraries (libgprofng, libopcodes, libbfd, etc).
+ We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and
+ configuration file. These variables must be set for all gprofng tests.
+
+ Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>.
+
+ gprofng/ChangeLog
+ 2023-08-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30808
+ * testsuite/config/default.exp: Make a temporary install dir.
+ Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR.
+ * testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and
+ GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp.
+
+2023-09-05 Sandra Loosemore <sandra@codesourcery.com>
+
+ gdb/testsuite: Make hook-stop.exp ignore termination message from GDB stub
+ When a GDB stub is run via "target remote |", it sometimes produces
+ extra output that ends up mixed with GDB's own output. For example,
+ QEMU's built-in GDB stub responds to the vKill packet by printing
+
+ nios2-elf-qemu-system: QEMU: Terminated via GDBstub
+
+ before exiting.
+
+ This patch fixes the regexp in gdb.base/hook-stop.exp to allow such
+ messages between GDB's "continuing" and "Inferior killed" messages.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-05 Sandra Loosemore <sandra@codesourcery.com>
+
+ gdb/testsuite: Disable some tests that are broken on remote Windows host
+ These testcases assume host==build or that the remote host has a Posix
+ shell to run commands in. Don't try to run them if that's not the case.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-05 Sandra Loosemore <sandra@codesourcery.com>
+
+ gdb/testsuite: Adjust some testcases to allow Windows pathnames
+ This patch fixes some testcases that formerly had patterns with
+ hardwired "/" pathname separators in them, which broke when testing on
+ (remote) Windows host.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-05 Sandra Loosemore <sandra@codesourcery.com>
+
+ gdb/testsuite: Fix style.exp failures on targets without argc/argv support
+ Some embedded targets don't have full support for argc/argv. argv
+ may print as "0x0" or as an address with a symbol name following.
+ This causes problems for the regexps in the style.exp line-wrapping
+ tests that assume it always prints as an ordinary address in backtrace
+ output.
+
+ This patch generalizes the regexps to handle these additional forms
+ and reworks some of the line-wrapping tests to account for the argv
+ address string being shorter or longer than a regular address.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Handle array- and string-like values in no-op pretty printers
+ This changes the no-op pretty printers -- used by DAP -- to handle
+ array- and string-like objects known by the gdb core. Two new tests
+ are added, one for Ada and one for Rust.
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Add new Python APIs to support DAP value display
+ gdb's language code may know how to display values specially. For
+ example, the Rust code understands that &str is a string-like type, or
+ Ada knows how to handle unconstrained arrays. This knowledge is
+ exposed via val-print, and via varobj -- but currently not via DAP.
+
+ This patch adds some support code to let DAP also handle these cases,
+ though in a somewhat more generic way.
+
+ Type.is_array_like and Value.to_array are added to make Python aware
+ of the cases where gdb knows that a structure type is really
+ "array-like".
+
+ Type.is_string_like is added to make Python aware of cases where gdb's
+ language code knows that a type is string-like.
+
+ Unlike Value.string, these cases are handled by the type's language,
+ rather than the current language.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Select frame when fetching a frame variable in DAP
+ Right now, if a program uses multiple languages, DAP value formatting
+ will always use the language of the innermost frame. However, it is
+ better to use the variable's defining frame instead. This patch does
+ this by selecting the frame first.
+
+ This also fixes a possibly latent bug in the "stepOut" command --
+ "finish" is sensitive to the selected frame, but the DAP code may
+ already select other frames when convenient. The DAP stepOut request
+ only works on the newest frame, so be sure to select it before
+ invoking "finish".
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Introduce type::is_array_like and value_to_array
+ This adds the type::is_array_like method and the value_to_array
+ function.
+
+ The former can be used to see whether a given type is known to be
+ "array-like". This is the currently the case for certain
+ compiler-generated structure types; in particular both the Ada and
+ Rust compilers do this.
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Use ada_value_subscript in valpy_getitem
+ Ada has a few complexities when it comes to array handling. Currently
+ these are all handled in Ada-specific code -- but unfortunately that
+ means they aren't really accessible to Python.
+
+ This patch changes the Python code to defer to Ada when given an Ada
+ array. In order to make this work, one spot in ada-lang.c had to be
+ updated to set the "GNAT-specific" flag on an array type.
+
+ The test case for this will come in a later patch.
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Introduce TYPE_SPECIFIC_RUST_STUFF
+ This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes
+ the DWARF reader to set this on Rust types. This will be used as a
+ flag in a later patch.
+
+ Note that the size of the type_specific_field bitfield had to be
+ increased. I checked that this did not impact the size of main_type.
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Refactor Rust code for slice-to-array operation
+ This patch exposes rust_slice_type_p and introduces
+ rust_slice_to_array, in preparation for subsequent patches that will
+ need these.
+
+ Move rust_language::lookup_symbol_nonlocal
+ This moves rust_language::lookup_symbol_nonlocal to rust-lang.c.
+ There's no need to have it in rust-lang.h and moving it lets us avoid
+ adding new includes in a later patch.
+
+2023-09-05 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ gdb/riscv: Fix oob memory access when printing info registers
+ If the length of a register name was greater than 15,
+ print_spaces was called with a negative number, which
+ prints random data from the heap instead of the requested
+ number of spaces.
+
+ This could happen if a target-description file was used
+ to specify additional long-named registers.
+
+ Fix is simple - don't ask for fewer than 1 space (since
+ we still want column separation).
+
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Read Ada main name from executable, not inferior
+ An upstream bug report points out this bug: if the user switches from
+ one Ada executable to another without "kill"ing the inferior, then the
+ "start" command will fail.
+
+ What happens here is that the Ada "main" name is found in a constant
+ string in the executable. But, if the inferior is running, then the
+ process_stratum target reads from the inferior memory.
+
+ This patch fixes the problem by changing the main name code to set
+ trust-readonly-sections, causing the target stack to read from the
+ executable instead.
+
+ I looked briefly at changing GNAT to emit DW_AT_main_subprogram
+ instead, but this looks to be pretty involved.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
+
+2023-09-05 Tom Tromey <tromey@adacore.com>
+
+ Avoid crash with Ada and -fdata-sections
+ A user noticed that gdb would crash when showing a backtrace.
+ Investigation showed this to be a crash in the DWARF reader when
+ handling a "pragma export" symbol. The bug here is that earlier code
+ decides to eliminate the symbol, but the export code tries to add it
+ anyway -- but to a NULL list.
+
+2023-09-05 Nick Clifton <nickc@redhat.com>
+
+ readelf: Add option to display the names of sections referenced by symbols.
+ PR 30684
+ * readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function. Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function.
+ * doc/binutils.texi: Document the new option.
+ * NEWS: Mention the new feature.
+
+2023-09-05 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: fold duplicate code in vector_macro()
+ There's no need to have almost identical code twice. Do away with
+ M_VMSGEU and instead simply use an unused (for these macros) field to
+ tell apart both variants.
+
+2023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add stub support for the 'Svadu' extension
+ This commit implements support for 'Svadu' extension. Because it does not
+ add any instructions or CSRs (but adds bits to existing CSRs), this commit
+ only adds extension name support and implication to the 'Zicsr' extension.
+
+ This is based on the "Hardware Updating of PTE A/D Bits (Svadu)"
+ specification, version 1.0-rc1 (Frozen):
+ <https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add implication from
+ 'Svadu' to 'Zicsr'. (riscv_supported_std_s_ext) Add 'Svadu'.
+
+2023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix typo in the testsuite
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded
+ by minstretcfg, not mcyclecfg.
+
+2023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Smcntrpmf' extension and its CSRs
+ This commit adds now stable and approved 'Smcntrpmf' extension defined by
+ the RISC-V Cycle and Instret Privilege Mode Filtering specification.
+
+ Note that, because mcyclecfg and minstretcfg CSRs conflict with the
+ privileged specification version 1.9.1, CSRs for this extension are only
+ enabled on the privileged specification version 1.10 or later.
+
+ By checking the base privileged specification, we no longer need to change
+ the design of base CSR handling.
+
+ This is based on the specification version v1.0_rc1 (Frozen):
+ <https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from
+ the new 'Smcntrpmf' extension. (riscv_supported_std_s_ext): Add
+ 'Smcntrpmf' to the supported S extension list.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes
+ CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32.
+ (riscv_csr_address): Add handling for new CSR classes.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. Move
+ "mscounteren" and "mhcounteren" CSRs and note that they are now
+ aliases.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change.
+ * testsuite/gas/riscv/csr.s: Add new CSRs. Move "mscounteren"
+ and "mhcounteren" CSRs and note that they are now reused for
+ the 'Smcntrpmf' extension.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of
+ csr.s.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: 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.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h: Add new CSRs noting that this extension is
+ incompatible with the privileged specification version 1.9.1.
+ Move "mscounteren" and "mhcounteren" CSRs, make them aliases and
+ reuse the CSR numbers from the 'Smcntrpmf' extension.
+ (CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and
+ "mhcounteren" are now aliases and new CSR macros are used instead.
+ (CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH):
+ New CSR macros.
+
+2023-09-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Prohibit combination of 'E' and 'H'
+ According to the ratified privileged specification (version 20211203),
+ it says:
+
+ > The hypervisor extension depends on an "I" base integer ISA with 32 x
+ > registers (RV32I or RV64I), not RV32E, which has only 16 x registers.
+
+ Also in the latest draft, it also prohibits RV64E with the 'H' extension.
+ This commit prohibits the combination of 'E' and 'H' extensions.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and
+ 'H' combinations.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to
+ make sure that RV32E + 'H' is prohibited.
+ * testsuite/gas/riscv/march-fail-rv32eh.l: Likewise.
+
+2023-09-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-04 Christophe Lyon <christophe.lyon@linaro.org>
+
+ arm: Make 'conflicting CPU architectures' error message more user-friendly
+ Error messages such as "conflicting CPU architectures 10/16" are not
+ very to understand, so this patch replaces the numbers with the
+ description they actually mean:
+ "conflicting CPU architectures ARM v7E-M vs Pre v4"
+
+ 2023-09-01 Christophe Lyon <christophe.lyon@linaro.org>
+
+ bfd/
+ * elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and
+ use it.
+ (elf32_arm_merge_eabi_attributes): Update call to
+ tag_cpu_arch_combine.
+
+ ld/
+ * testsuite/ld-arm/attr-merge-9.out: Update expected error
+ message.
+ * testsuite/ld-arm/attr-merge-arch-2.d: Likewise.
+
+2023-09-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix race in gdb.base/add-symbol-file-attach.exp
+ When running test-case gdb.base/add-symbol-file-attach.exp with target board
+ unix/-m32, we run into:
+ ...
+ (gdb) attach 3955^M
+ Attaching to process 3955^M
+ Load new symbol table from "add-symbol-file-attach"? (y or n) y^M
+ Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M
+ Reading symbols from /lib/libm.so.6...^M
+ Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M
+ Reading symbols from /lib/libc.so.6...^M
+ Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M
+ Reading symbols from /lib/ld-linux.so.2...^M
+ Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M
+ 0xf7f53549 in __kernel_vsyscall ()^M
+ (gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach
+ ...
+
+ The test fails because this regexp is used:
+ ...
+ -re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" {
+ ...
+
+ The regexp attempts to detect that the exec is somewhere in pause ():
+ ...
+ int
+ main (int argc, char **argv)
+ {
+ pause ();
+ return 0;
+ }
+ ...
+ but when the exec is blocked in pause, the backtrace is:
+ ...
+ (gdb) bt
+ #0 0xf7fd2549 in __kernel_vsyscall ()
+ #1 0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
+ #2 0x0804844c in main (argc=1, argv=0xffffce84)
+ at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26
+ ...
+
+ We could simply extend the regexp to also match __kernel_vsyscall, but the
+ more fundamental problem is that the test is racy.
+
+ The attach can happen before the exec is blocked in pause (), somewhere in the
+ dynamic linker resolving the call to pause, in main or even earlier.
+
+ Note that for the test-case to be effective, the exec is not required to be in
+ pause (). I added a "while (1);" loop at the start of main, reverted the
+ patch fixing the corresponding PR and reproduced the problem it's supposed to
+ detect.
+
+ Fix this by simply matching the "Reading symbols from" line, similar to what
+ an earlier test is doing.
+
+ While we're at it, rewrite the earlier test to also use the -wrap idiom.
+
+ Tested on x86_64-linux.
+
+2023-09-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver: i387_cache_to_xsave: fix copy dest of zmm registers
+ On a machine with AVX512 support (AMD EPYC 9634), I see these failures:
+
+ $ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+ ...
+ FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs
+ FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs
+ FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs
+ ...
+
+ The problem can be reduced to:
+
+ (gdb) print $zmm16.v8_int64
+ $1 = {0, 0, 0, 0, 0, 0, 0, 0}
+ (gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88}
+ $2 = {11, 22, 33, 44, 55, 66, 77, 88}
+ (gdb) print $zmm16.v8_int64
+ $3 = {11, 22, 33, 44, 55, 66, 77, 88}
+ (gdb) step
+ 5 ++x;
+ (gdb) print $zmm16.v8_int64
+ $4 = {11, 22, 77, 88, 0, 0, 0, 0}
+
+ Writing to the local regcache in GDB works fine, but the writeback to
+ gdbserver (which happens when resuming / stepping) doesn't work (the
+ code being stepped doesn't touch AVX registers, so we don't expect the
+ value of zmm16 to change when stepping).
+
+ The problem is on the gdbserver side, the zmmh and ymmh portions of the
+ zmm register are not memcpied at the right place in the xsave buffer. Fix
+ that. Note now how the two modified memcpy calls match the memcmp calls
+ just above them.
+
+ With this patch, gdb.arch/i386-avx512.exp passes completely for me.
+
+ Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818
+
+2023-09-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-01 Joseph Myers <joseph@codesourcery.com>
+
+ config: Fix host -rdynamic detection for build != host != target
+ [Merge from GCC commit 4d9bc81a5d8d884dee7a7781fa4c1577a6c9681a.]
+
+ The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic
+ is necessary and supported uses an appropriate objdump for $host
+ binaries (running on $build) in cases where $host is $build or
+ $target.
+
+ However, it is missing such logic in the case where $host is neither
+ $build nor $target, resulting in the compilers not being linked with
+ -rdynamic and plugins not being usable with such a compiler. In fact
+ $ac_cv_prog_OBJDUMP, as used when $build = $host, is always an objdump
+ for $host binaries that runs on $build; that is, it's appropriate to
+ use in this case as well.
+
+ Tested in such a configuration that it does result in cc1 being linked
+ with -rdynamic as expected. Also bootstrapped with no regressions for
+ x86_64-pc-linux-gnu.
+
+ config/
+ * gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Use
+ export_sym_check="$ac_cv_prog_OBJDUMP -T" also when host is not
+ build or target.
+
+2023-09-01 Tom Tromey <tromey@adacore.com>
+
+ Fix "usage" errors for some MI varobj commands
+ I noticed that the "usage" error for -var-set-frozen mentioned the
+ wrong command name. Then I looked through the whole file and found a
+ couple other spots that didn't mention the command name at all. This
+ patch fixes all of these.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-01 Jan Beulich <jbeulich@suse.com>
+
+ x86: unindent most of set_cpu_arch()
+ Inverting the initial if()'s condition allows to move out the bulk of
+ the function by a level, improving readability at least a bit. While
+ doing that also pull the push/pop handling up first, such that "else if"
+ after "return" isn't needed anymore; the order in which special cases
+ are checked doesn't really matter.
+
+ x86: rename CpuPCLMUL
+ The name we use internally isn't in line with the SDM, and also isn't in
+ line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave
+ alone user facing names.
+
+ x86: correct source used for two non-AVX512 VEXWIG tests
+ These shouldn't wrongly include the AVX512VL sources. Obviously the
+ expectations therefore also need to change.
+
+ x86: drop Size64 from VMOVQ
+ Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was
+ right in adding the attribute to MOVQ, but there was no need to add it
+ to VMOVQ. (See also the AVX512F form, which doesn't have the attribute
+ either.)
+
+2023-09-01 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: move various alias entries
+ For disassembly to only use spec-mandated aliases, respective non-alias
+ entries need to come ahead of their alias ones. Since identical
+ mnemonics need to stay together, whole groups are moved up where
+ necessary.
+
+ This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for
+ consistent alias handling"), but then also goes beyond a plain revert.
+
+ Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-09-01 Jerry Zhang Jian <jerry.zhangjian@sifive.com>
+
+ Fix ld Makefile variable naming: ELF_CLFAGS -> ELF_CFLAGS
+
+2023-09-01 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Fixed the wrong expansion for pseudo vmsge[u].vx instructions.
+ The original report was from Kiva Oyama <libkernelpanic@gmail.com>,
+ https://sourceware.org/pipermail/binutils/2023-August/129255.html
+
+ The vmsge[u].vx pseudo should be expanded to masked vmslt[u].vx only when
+ vd != v0. Otherwise, it should be expanded to unmasked one.
+
+ gas/
+ * config/tc-riscv.c (vector_macro): Fixed the wrong expansion for
+ pseudo vmsge[u].vx instructions.
+ * testsuite/gas/riscv/vector-insns-vmsgtvx.d: Updated.
+
+2023-09-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove uses of alloca in gdbtypes.c
+ Replace two uses of alloca with std::string.
+
+ Change-Id: I970ae3f450da407494d95668a57bba8796d6292b
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-09-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-09-01 Nicolas Boulenguez <nicolas@debian.org>
+
+ PR30806, CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfo
+ PR 30806
+ bfd/
+ * doc/local.mk (doc/chew.stamp): Add CPPFLAGS_FOR_BUILD.
+ * Makefile.in: Regenerate.
+ binutils/
+ * Makefile.am (syslex_wrap.@OBJEXT@): Add CPPFLAGS_FOR_BUILD.
+ (sysinfo.@OBJEXT@): Likewise.
+ * Makefile.in: Regenerate.
+
+2023-09-01 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Adjust PR ld/30791 tests
+ Adjust PR ld/30791 tests:
+
+ 1. Generic linker targets don't comply with all orhpan section merging
+ rules.
+ 2. z80 fails since a, b, c, d are registers for z80.
+ 3. hppa fails since .text sections aren't merged for relocatable link.
+
+ PR ld/30791
+ * testsuite/ld-elf/pr30791a.d: Xfail for generic and z80
+ targets.
+ * testsuite/ld-elf/pr30791b.d: Xfail for hppa and z80 targets.
+
+2023-08-31 Tom Tromey <tom@tromey.com>
+
+ Add symbol::matches method
+ This adds symbol::matches, a wrapper for symbol_matches_domain. Most
+ places calling symbol_matches_domain can call this method instead,
+ which is a bit less wordy and also (IMO) clearer.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_PACKED
+ Replace with a new equivalent "is_packed" method on struct field.
+
+ Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_BITSIZE
+ Replace with type::field + field::bitsize.
+
+ Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_BITSIZE
+ Replace with field::bitsize.
+
+ Change-Id: I400be235d6a1f446d0a4aafac01df5e850185d3a
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce field::bitsize / field::set_bitsize
+ Add these two methods, rename the field to m_bitsize to make it pseudo
+ private.
+
+ Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_ARTIFICIAL
+ Replace with type::field + field::is_artificial.
+
+ Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_ARTIFICIAL
+ Replace uses with field::is_artificial.
+
+ Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce field::is_artificial / field::set_is_artificial
+ Add these two methods, rename the field to m_artificial to make it
+ pseudo private.
+
+ Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Tom Tromey <tromey@adacore.com>
+
+ Remove eval_op_ternop
+ eval_op_ternop is only used by the implementation of
+ ternop_slice_operation. While working on another series, it was
+ convenient for me to merge this function into its only caller.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-08-31 Kevin Buettner <kevinb@redhat.com>
+
+ [symtab/27831] New test case: gdb.base/add-symbol-file-attach.exp
+ This commit adds a new test case for bug 27831. See the contents
+ of the .exp file for a description of what it's about.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Kevin Buettner <kevinb@redhat.com>
+
+ [symtab/27831] Fix OBJF_MAINLINE assert
+ This commit fixes a bug mentioned by Florian Weimer during the
+ libpthread/ld.so load order discussion from 2021. Florian provided
+ instructions for reproducing the bug here:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html
+
+ That particular test does some interesting things involving forks,
+ threads, and thread local storage. Fortunately, none of that is
+ needed to reproduce the problem.
+
+ I've made a new test case (which is now found in a separate commit)
+ contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The
+ .c file is fairly simple as is the recipe for reproducing the problem.
+
+ After separately starting the test case and noting the process id,
+ start gdb (w/ no arguments), and do the following to reproduce the
+ assertion failure - for this run, the process id of the separately
+ started add-symbol-file-attach process is 4103218:
+
+ (gdb) add-symbol-file add-symbol-file-attach
+ add symbol table from file "add-symbol-file-attach"
+ (y or n) y
+ Reading symbols from add-symbol-file-attach...
+ (gdb) attach 4103218
+ Attaching to process 4103218
+ Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
+ Reading symbols from /tmp/add-symbol-file-attach...
+ 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)
+ 0x00007f502130bf27 in pause () from /lib64/libc.so.6
+ (gdb) p foo
+ symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
+ const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
+ failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+
+ The add-symbol-file command causes the symbols to be loaded without
+ the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
+ set. This, in turn, causes the "maybe_copied" flag to be set for
+ the global symbol (named "foo" in the provided test case).
+
+ The attach command will cause another objfile to be created, but
+ it will reuse the symtabs from the objfile created by add-symbol-file,
+ leading to a situation in which the OBJFILE_MAINLINE flag will be set
+ for the new (attach-created) objfile, however the "maybe_copied"
+ flag will still be set for the global symbol. Had it been loaded
+ anew, this flag would not be set due to OBJFILE_MAINLINE being set
+ for the objfile.
+
+ At present, minimal_symbol::value_address looks like this:
+
+ CORE_ADDR
+ minimal_symbol::value_address (objfile *objfile) const
+ {
+ if (this->maybe_copied (objfile))
+ return get_msymbol_address (objfile, this);
+ else
+ return (CORE_ADDR (this->unrelocated_address ())
+ + objfile->section_offsets[this->section_index ()]);
+ }
+
+ So, we can now see the problem: When the "maybe_copied" flag is set,
+ get_msymbol_address() will be called. However, get_msymbol_address()
+ assumes that it won't be called with the OBF_MAINLINE flag set for
+ the objfile in question. It, in fact, contains an assert() which
+ makes sure that this is the case:
+
+ gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);
+
+ (If this assert is removed, then get_msymbol_address() recurses
+ infinitely for the case under consideration.)
+
+ So, the problem here is that the maybe_copied flag is set for the
+ symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted
+ earlier, this happens due to add-symbol-file being used; this causes
+ the maybe_copied flag to be set. Later, when the attach is performed,
+ OBJF_MAINLINE will be set for that objfile, leading to this
+ unfortunate situation.
+
+ My first cut at a solution involved adjusting the
+ MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
+ method noted above) to include a test of the OBJFILE_MAINLINE flag.
+ However, Simon Marchi, in his review of my patch, suggested a better
+ solution. Simon observed that the 'maybe_copied' flag is (was, after
+ this commit) being set/initialized in record_minimal_symbol() using
+ using the objfile in the context in which the symbol was created.
+
+ Simon further observed:
+
+ Today, a single copy is created, as symtabs are shared between
+ objfiles. This means that everything that we store into a symbol
+ must be independent of any objfile. However, the value of the
+ maybe_copied field is dependent on the objfile in the context of
+ which the symbol was created. Meaning that when the symbol is
+ re-used in the context of another objfile, the maybe_copied value is
+ not right in the context of that objfile.
+
+ So I think it means there isn't a single "is this symbol maybe
+ copied" value, but instead "is this symbol maybe copied, in the
+ context of this given objfile". And the answer is yes or no,
+ depending on whether the objfile is mainline. So maybe_copied
+ should become a method that takes an objfile and returns an answer
+ based on that.
+
+ Simon's full review can be found here:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html
+
+ Simon also provided a patch which implements this suggestion. The
+ current patch is mostly his work, though I did make some adjustments
+ during a rebase in addition to making some changes to account for a
+ concern from Tom Tromey.
+
+ During his review of the v3 series, Tom noted, "The old approach was
+ specific to ELF, while the new approach will be used by any object
+ format." Tom further observed, "...it seems like it could result in an
+ incorrect evaluation in some scenario." This seemed plausible to me,
+ so I introduced the flag 'object_format_has_copy_relocs' to struct
+ objfile. It is set at the end of elf_symfile_read() in elfread.c.
+ The minimal_symbol::maybe_copied method tests this new flag, forcing
+ this method to return false when the flag is not set. If we find that
+ other object file formats use the same copy reloc mechanism as ELF,
+ then 'object_format_has_copy_relocs' should be set for objfiles using
+ those formats.
+
+ Lastly, I'll note that this is a strange use case. It's far more
+ common to either let gdb figure out which file to load by itself when
+ attaching, i.e.
+
+ (gdb) attach 4104360
+ Attaching to process 4104360
+ Reading symbols from /tmp/add-symbol-file-attach...
+ 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)
+ 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
+ (gdb) p foo
+ $1 = 42
+
+ ...or to use the "file" command prior to the attach, like this:
+
+ (gdb) file add-symbol-file-attach
+ Reading symbols from add-symbol-file-attach...
+ (gdb) attach 4104360
+ Attaching to program: /tmp/add-symbol-file-attach, process 4104360
+ 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)
+ 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
+
+ Both of these more common scenarios work perfectly fine; using
+ "add-symbol-file" to load the program to which you will attach
+ isn't recommended as a normal use case. That said, it's bad for
+ gdb to assert, hence this fix.
+
+ Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
+ Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
+ Approved-by: Tom Tromey <tom@tromey.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
+
+2023-08-31 Tom Tromey <tom@tromey.com>
+
+ Unify DW_TAG_typedef case in new_symbol
+ This patch merges the DW_TAG_typedef case in new_symbol with some
+ other type-related cases. These all have identical code.
+
+ Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
+
+2023-08-31 Tom Tromey <tom@tromey.com>
+
+ Revert "Simplify @node use in BFD documentation"
+ This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8.
+
+ My earlier patch to simplifify the @node uses in the BFD manual didn't
+ take into account (1) that BFD doesn't use the ordinary texinfo
+ sectioning commands, and (2) that some users are stuck on very ancient
+ versions of makeinfo.
+
+ This patch reverts the change.
+
+ I went through the entire manual using the spacebar, trying to find
+ the original problem I reported in the change, but couldn't. I don't
+ know why. Anyway, all this means is that, with this reversion,
+ editing the node structure will be slightly less convenient.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30703
+
+ 2023-08-30 Tom Tromey <tom@tromey.com>
+
+ PR binutils/30703
+ * doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding
+ parameters back to @node.
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/contrib] Require minimal dwz version in cc-with-tweaks.sh
+ I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build
+ from current trunk, but the pathname to the build dir changed and I forgot to
+ update my test scripts, so the test scripts reverted to using system dwz,
+ version 0.12.
+
+ Consequently, I ran into:
+ ...
+ (gdb) p ZERO^M
+ No symbol "ZERO" in current context.^M
+ (gdb) FAIL: gdb.base/enumval.exp: p ZERO
+ ...
+ which is due to PR dwz/24468, which was fixed in version 0.13.
+
+ Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such
+ that this situation is detected and we get instead:
+ ...
+ gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \
+ 0.13 or higher required
+ ...
+
+ Tested on x86_64-linux, verified with shellcheck.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Alan Modra <amodra@gmail.com>
+
+ vms-alpha: Free memory on failure path
+ * vms-alpha.c (evax_bfd_print_eobj): Free rec on failure.
+
+2023-08-31 Alan Modra <amodra@gmail.com>
+
+ gas init_stab_section and get_stab_string_offset
+ get_stab_string_offset currently creates the stabstr section if not
+ already present, in the process keeping a reference to the malloc'd
+ section name string. Really, the name belongs in bfd_alloc'd memory
+ or some obstack so that it doesn't show as a memory leak on exit.
+ s_stab_generic at least does allocate the name for the stab section on
+ an obstack, but doesn't tidy that as well as it could. Return paths
+ after issuing a warning don't release the memory, nor the memory for
+ the "string" copy.
+
+ This patch fixes these problems. s_stab_generic is rearranged so that
+ creation of the sections occurs earlier, before any potential uses of
+ the note obstack during expression parsing. That makes it possible to
+ always free the section name strings unless used to create new
+ sections. I've also avoided get_absolute_expression_and_terminator
+ as I see that function might skip over end-of-line, and lack of a
+ --input_line_pointer might have caused the following source line to be
+ ignored. (Other uses of this function in gas are OK.)
+
+ * config/obj-coff.c (obj_coff_init_stab_section): Add stabstr
+ param. Pass to get_stab_string_offset rather than name of
+ section.
+ * config/obj-som.c (obj_som_init_stab_section): Likewise.
+ * config/obj-elf.c (obj_elf_init_stab_section): Likewise.
+ (elf_init_stab_section): Adjust.
+ * config/obj-coff.h (INIT_STAB_SECTION): Update.
+ (obj_coff_init_stab_section): Update prototype.
+ * config/obj-som.h: Similarly.
+ * config/obj-elf.h: Similarly.
+ * config/obj-multi.h (INIT_STAB_SECTION): Update.
+ * obj.h (struct format_ops <init_stab_section>): Update.
+ * read.h (get_stab_string_offset): Update prototype.
+ * stabs.c (cached_sec): Delete.
+ (stabs_begin): Adjust to suit.
+ (get_stab_string_offset): Add stabstr param, delete stabstr_name
+ and free_stabstr_secname params. Don't make stabstr section
+ here.
+ (eat_comma): New function.
+ (s_stab_generic): Replace stab_secname_obstack_end param with
+ bool freenames. Move creation of stab and stabstr sections
+ earlier, so the names can be freed earlier before possible use
+ of notes obstack during expression parsing. Tidy error paths
+ ensuring "string" is freed. Use get_absolute_expression in
+ place of get_absolute_expression_and_terminator.
+ (s_stab): Adjust.
+ (s_xstab): Use notes_concat to make stabstr section name.
+
+2023-08-31 Alan Modra <amodra@gmail.com>
+
+ gas OBJ_PROCESS_STAB
+ This macro and the supporting functions have an unused "seg" first
+ argument. Tidy that.
+
+ * config/obj-aout.c (obj_aout_process_stab): Delete first param.
+ * config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise.
+ * config/obj-elf.c (elf_process_stab): Likewise.
+ * config/obj-elf.h (OBJ_PROCESS_STAB): Likewise.
+ * config/obj-macho.h (OBJ_PROCESS_STAB): Likewise.
+ * config/obj-multi.h (OBJ_PROCESS_STAB): Likewise.
+ * ecoff.c (ecoff_stab): Likewise.
+ * ecoff.h (ecoff_stab): Likewise.
+ * obj.h (struct format_ops <process_stab>): Likewise.
+ * stabs.c (OBJ_PROCESS_STAB): Likewise.
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Replace TYPE_ALLOC with TYPE_ZALLOC where required
+ Handle the remaining uses of TYPE_ALLOC, either by:
+ - replacing with TYPE_ZALLOC, or
+ - adding a comment explaining why zero-initialization is not necessary.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Replace TYPE_ALLOC + B_CLRALL with TYPE_ZALLOC
+ I noticed some cases of TYPE_ALLOC followed by B_CLRALL.
+
+ Replace these with TYPE_ZALLOC.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Replace TYPE_ALLOC + memset with TYPE_ZALLOC
+ I noticed a case of TYPE_ALLOC followed by memset.
+
+ Replace this with TYPE_ZALLOC.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Do more zero-initialization of type::fields
+ Now that we've introduced type::{alloc_fields,copy_fields}, the places where
+ no zero-initialization of allocated fields is done are easy to spot:
+ ...
+ $ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
+ gdb/coffread.c: type->alloc_fields (nfields, false);
+ gdb/coffread.c: type->alloc_fields (nsyms, false);
+ gdb/stabsread.c: ftype->alloc_fields (nsemi, false);
+ gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false);
+ gdb/gdbtypes.c: alloc_fields (nfields, false);
+ gdb/gdbtypes.c: alloc_fields (nfields, false);
+ gdb/mdebugread.c: t->alloc_fields (nfields, false);
+ gdb/mdebugread.c: ftype->alloc_fields (nparams, false);
+ ...
+
+ All hits in gdbtypes.c are ok. There are two hits in the two variants of
+ copy_fields, and there's already a comment for the third.
+
+ AFAICT, the other ones are not ok, so fix those by dropping the "false"
+ argument.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Factor out type::{alloc_fields,copy_fields}
+ After finding this code in buildsym_compunit::finish_block_internal:
+ ...
+ ftype->set_fields
+ ((struct field *)
+ TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
+ ...
+ and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
+ locations that needed fixing.
+
+ I decided to make things easier to spot by factoring out a new function
+ alloc_fields:
+ ...
+ /* Allocate the fields array of this type, with NFIELDS elements. If INIT,
+ zero-initialize the allocated memory. */
+ void
+ type::alloc_fields (unsigned int nfields, bool init = true);
+ ...
+ where:
+ - a regular use would be "alloc_fields (nfields)", and
+ - an exceptional use that needed no initialization would be
+ "alloc_fields (nfields, false)".
+
+ Pretty soon I discovered that most of the latter cases are due to
+ initialization by memcpy, so I added two variants of copy_fields as well.
+
+ After this rewrite there are 8 uses of set_fields left:
+ ...
+ gdb/coffread.c: type->set_fields (nullptr);
+ gdb/coffread.c: type->set_fields (nullptr);
+ gdb/coffread.c: type->set_fields (nullptr);
+ gdb/eval.c: type->set_fields
+ gdb/gdbtypes.c: type->set_fields (args);
+ gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (),
+ gdb/dwarf2/read.c: type->set_fields (new_fields);
+ gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1);
+ ...
+
+ These fall into the following categories:
+ - set to nullptr (coffread.c),
+ - type not owned by objfile or gdbarch (eval.c), and
+ - modifying an existing fields array, like adding an element at the end or
+ dropping an element at the start (the rest).
+
+ Tested on x86_64-linux.
+
+2023-08-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix uninitialized memory in buildsym_compunit::finish_block_internal
+ When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs,
+ gdb either segfaults or asserts due to reading uninitialized memory, allocated
+ here in buildsym_compunit::finish_block_internal:
+ ...
+ ftype->set_fields
+ ((struct field *)
+ TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
+ ...
+
+ Fix this by using TYPE_ZALLOC instead.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30810
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810
+
+2023-08-31 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Update elfarcv2 script template
+ Update ARC's elfarcv2 script template with:
+
+ - The .ivt section (Interrupt Vector Table) is mapped at the begining
+ of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it
+ was pointing to 0x00.
+
+ - MEMORY_FILE is a new emulation paramter and sets the name for the
+ linker script file which holds the MEMORY commands required by
+ arcv2elfx emulation.
+
+ - Four new linker variables are introduced available when arcv2elf emulation is used:
+ * __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero.
+ * __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M.
+ * __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000.
+ * __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M.
+
+ ld/ChangeLog:
+
+ * scripttempl/elfarcv2.sc: Update script template.
+
+2023-08-31 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Don't merge sections with different SHF_LINK_ORDER
+ For relocatable link, don't merge 2 SHF_LINK_ORDER sections if output
+ sections of their linked to sections are different.
+
+ * ldelf.c (elf_orphan_compatible): Don't merge sections with
+ different SHF_LINK_ORDER.
+ * testsuite/ld-elf/pr30791a.d: New file.
+ * testsuite/ld-elf/pr30791a.s: Likewise.
+ * testsuite/ld-elf/pr30791b.d: Likewise.
+ * testsuite/ld-elf/pr30791b.s: Likewise.
+ * testsuite/ld-elf/pr30791c.s: Likewise.
+ * testsuite/ld-elf/pr30791d.s: Likewise.
+
+2023-08-31 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Check DT_SYMTAB only on non-IR object
+ Check DT_SYMTAB only on non-IR object of archive member to avoid crash
+ on LLVM IR object with NULL elf_tdata.
+
+ PR ld/30811
+ * elflink.c (elf_link_is_defined_archive_symbol): Check
+ DT_SYMTAB only on non-IR object.
+
+2023-08-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-31 Alan Modra <amodra@gmail.com>
+
+ libbfd.texi zero size
+ Pattern rules in doc/local.mk exist that specify how to make
+ libbfd.texi from libfd.h or libbfd.c. Since both files exist and the
+ libbfd.h rule is first, libbfd.h is used. libbfd.h doesn't contain
+ the documentation..
+
+ * doc/local.mk (doc/%stamp): Put rule making this from %.c
+ before %.h rule.
+ * Makefile.in: Regenerate.
+ * libbfd.c (Byte swapping routines): Don't omit description.
+
+2023-08-30 Alan Modra <amodra@gmail.com>
+
+ DEFAULT_BUFFERSIZE
+ There isn't any reason to think that a particular buffer size is
+ ideal in bfd, so let's just not define it.
+
+ * libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define.
+ * libbfd.h: Regenerate.
+ * archive.c (AR_WRITE_BUFFERSIZE): Substitute value.
+ * vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise.
+ * coff-rs6000.c (do_copy): Likewise, and use sizeof.
+
+2023-08-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/nullptr_t.exp with cc-with-dwz-m
+ When running test-case gdb.dwarf2/nullptr_t.exp with target board
+ cc-with-dwz-m, I run into:
+ ...
+ FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
+ ...
+
+ The problem is that were looking for "typedef void decltype\\(nullptr\\)"
+ using "maint print symbols -source $srcfile", but dwz has moved the typedef to
+ a PU, so it's shown by "maint print symbols -source <unknown>" instead.
+
+ Fix this by dropping the "-source $srcfile" bit.
+
+ Tested on x86_64-linux, with make-check-all.sh.
+
+2023-08-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: simplify vector construction in eval_op_rust_array
+ Replace the manual fill of the vector with the appropriate std::vector
+ constructor that makes N copies of the provided value.
+
+ Change-Id: I579570748c48f53d35024105269d83c716294746
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-30 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ Revert "Gold: Add targ_extra_little_endian to configure.ac"
+ This reverts commit cf8565fb2ea42579c50722cbaeafdf71c3d58c66. It was
+ applied unapproved.
+
+ Revert "Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian"
+ This reverts commit 39834263784567c306fbccb8230ddd1badca53fe. It was
+ applied unapproved.
+
+ Revert "Gold/MIPS: Drop mips*le/mips*el* triple pattern"
+ This reverts commit adb3ae2eba78b4b84d7b94342f6774b250190a98. It was
+ applied unapproved.
+
+ Revert "Gold/MIPS: Add targ_extra_size=64 for mips32 triples"
+ This reverts commit d6cdc0af2b880bb48dd16055f4cb3509c7a2da70. It was
+ applied unapproved.
+
+ Revert "Gold/MIPS: Add mips64*/mips64*el triple support"
+ This reverts commit 5c4cdba100b66e2924a25dad9b12d8e5b84d527f. It was
+ applied unapproved.
+
+ Revert "MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets"
+ This reverts commit 025e84f93566c8ced594ef48ddee1dec7e5b4cdd. It was
+ applied unapproved.
+
+2023-08-30 Willgerodt, Felix <felix.willgerodt@intel.com>
+
+ gdbserver, linux-low: add a couple of nullptr assertions.
+ This safeguards a couple of places that may theoretically return NULL but
+ must not in this specific context. These were found by a static analysis tool.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Make XVentanaCondOps RV64 only
+ Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual
+ only defines them only for RV64 (because all Ventana's processors implement
+ RV64).
+
+ This commit limits XVentanaCondOps instructions RV64-only to match the
+ behavior of the manual and LLVM.
+
+ Note that this commit alone will not make XVentanaCondOps extension with
+ RV32 invalid (it just makes XVentanaCondOps on RV32 empty).
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn"
+ to XLEN=64.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-ventana-condops-32.d: New failure test.
+ * testsuite/gas/riscv/x-ventana-condops-32.l: Likewise.
+
+2023-08-30 Alan Modra <amodra@gmail.com>
+
+ objdump: Free sorted_syms on error path
+ * objdump.c (disassemble_data): Free sorted_syms before returning.
+
+ binutils/dwarf.c abbrev list leak
+ * dwarf.c (process_debug_info): Call free_abrev_list on
+ return paths.
+
+ Re: readelf/objdump: Handle DWARF info with mixed types of range section
+ PR 30791
+ * dwarf.c (free_debug_information): Free range_versions.
+
+2023-08-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix C inclusion of nat/x86-cpuid.h
+ When running test-case gdb.arch/i386-avx512.exp, I run into:
+ ...
+ gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0:
+ src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count':
+ src/gdb/nat/x86-cpuid.h:63:16: error: \
+ 'nullptr' undeclared (first use in this function)
+ if (__eax == nullptr)
+ ^~~~~~~
+ src/gdb/nat/x86-cpuid.h:63:16: note: each \
+ undeclared identifier is reported only once for each function it appears in
+
+ === gdb Summary ===
+
+ # of untested testcases 1
+ ...
+
+ This is due to commit e85aad4ae76 ("nat/x86-cpuid.h: Add x86_cpuid_count
+ wrapper around __get_cpuid_count"), which introduced the nullptr check.
+
+ The header file gdb/nat/x86-cpuid.h is a file that is included in the build
+ and compiled as a C++ file, but also in the testsuite and compiled as a C
+ file.
+
+ Fix this by replacing nullptr with (void *)0.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ More renames in array_operation::evaluate
+ array_operation::evaluate has variables named "tem2" and "tem3". This
+ patch replaces one with a better name, and entirely removes the other.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Remove "highbound" parameter from value_array
+ value_array requires the passed-in bounds to match the length of the
+ array_view it is given. This patch removes the redundant "highbound"
+ parameter.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Remove another redundant variable from array_operation::evaluate
+ This removes yet another redundant variable from
+ array_operation::evaluate -- only one index is needed.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Remove redundant variable from array_operation::evaluate
+ In array_operation::evaluate, 'idx' and 'tem' are redundant in one
+ branch. This patch merges them, using the clearer name.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Hoist array bounds check in array_operation::evaluate
+ This hoists the array bounds check in array_operation::evaluate to
+ before the loop.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Declare 'tem' in loop header in array_operation::evaluate
+ This changes array_operation::evaluate to declare the 'tem' variable
+ in the loop header, rather than at the top of the function. This is
+ cleaner and easier to reason about. I also changed 'nargs' to be
+ 'const'.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::array_view for value_array
+ This changes value_array to accept an array view. I also replaced an
+ alloca with a std::vector in array_operation::evaluate. This function
+ can work on any size of array, so it seems bad to use alloca.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-29 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: recognize one more unsupported instruction in gdb.reverse/step-precsave.exp
+ When running this test on a processor that supports AVX512 (AMD EPYC
+ 9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:
+
+ continue^M
+ Continuing.^M
+ Process record does not support instruction bound.^M
+ Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
+ Process record: failed to record execution log.^M
+ ^M
+ Program stopped.^M
+ 0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
+ (gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
+
+ The instruction at this address is:
+
+ 0x00007ffff7f49b40: 62 e2 7d 48 7a c6 vpbroadcastb %esi,%zmm16
+
+ This seems like an AVX512 instruction (given the use of zmm16). Match
+ this byte value in order to produce a KFAIL.
+
+ Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require have_compile_flag -mavx512f in gdb.arch/i386-avx512.exp
+ When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
+ ...
+ Running gdb.arch/i386-avx512.exp ...
+ gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
+ ...
+
+ Fix this by requiring have_compile_flag -mavx512f.
+
+ Tested on x86_64-linux.
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require gcc >= 5 in gdb.linespec/cpls-abi-tag.exp
+ When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
+ into:
+ ...
+ cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
+ ABI3 test_abi_tag_struct s;
+ ^
+ ...
+
+ The test-case is supported starting gcc 5.
+
+ Fix this by requiring gcc >= 5, if a gcc compiler is used.
+
+ Tested on x86_64-linux.
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle some test-cases with older compiler
+ When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
+ into a compilation failure due to the test-case requiring c++11 and the
+ compiler defaulting to less than that.
+
+ Fix this by compiling with -std=c++11.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix false negative in have_host_locale
+ In test-case gdb.tui/pr30056.exp we check for:
+ ...
+ require {have_host_locale C.UTF-8}
+ ...
+
+ The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
+ find it in the list returned by host_locales.
+
+ On my development platform, "locale -a" lists C.utf8, which is normalized to
+ "c.utf8" by host_locales, so there's a match and have_host_locale returns true.
+
+ On another platform however, "locale -a" lists C.UTF-8, which is normalized to
+ "c.utf-8" by host_locales, so there's no match and have_host_locale returns false.
+
+ Fix this by also dropping the dash in host_locales.
+
+ Tested on x86_64-linux.
+
+2023-08-29 Nicolas Boulenguez <nicolas.boulenguez@free.fr>
+
+ readelf: typos in user messages
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Default getpkt 'forever' parameter to 'false'
+ This patch changes remote.c so that the getpkt 'forever' parameter now
+ defaults to 'false' and fixes up all the callers.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Unify getpkt and getpkt_or_notif_sane
+ getpkt and getpkt_or_notif_sane are just wrappers for
+ getpkt_or_notif_sane_1. This patch adds the is_notif parameter to
+ getpkt, with a suitable default, and removes the wrappers.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Use bool in getpkt
+ This changes getpkt and related functions to use bool rather than int.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Remove expecting_notif parameter from getpkt_or_notif_sane_1
+ For getpkt_or_notif_sane_1, expecting_notif is redundant, because it
+ always reflects whether the is_notif parameter is non-NULL. This
+ patch removes the redundant parameter.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-29 Tom Tromey <tromey@adacore.com>
+
+ Remove getpkt_sane
+ I noticed that getpkt is just a wrapper around getpk_sane, so this
+ patch unifies the two of them.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check for sys/random.h in gdb.reverse/getrandom.exp
+ When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
+ we run into:
+ ...
+ gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
+ sys/random.h: No such file or directory
+ #include <sys/random.h>
+ ^
+ compilation terminated.
+
+ === gdb Summary ===
+
+ # of untested testcases 1
+ ...
+ and:
+ ...
+ UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
+ ...
+
+ Fix this by testing for the presence of the header, such that we have instead:
+ ...
+ UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
+ have_system_header sys/random.h
+ ...
+
+ Tested on x86_64-linux and i686-linux.
+
+2023-08-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve xfail in gdb.cp/nsusing.exp
+ In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
+ mentioned:
+ ...
+ XFAIL: gdb.cp/nsusing.exp: print x, before using statement
+ XFAIL: gdb.cp/nsusing.exp: print x, only using M
+ ...
+
+ Add the missing PRMS, such that we have:
+ ...
+ XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
+ XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
+ ...
+ and limit the xfail to unfixed versions.
+
+ The PR is fixed starting gcc 13, but it has been backported to release
+ branches stretching back to gcc 10. For simplicity we just stick to testing
+ for the major version and ignore the backported fixes.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Fix style of struct declarations in i387-fp.cc
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Simplify handling of ZMM registers.
+ - Reuse num_xmm_registers directly for the count of ZMM0-15 registers
+ as is already done for the YMM registers for AVX rather than using
+ a new variable that is always the same.
+
+ - Replace 3 identical variables for the count of upper ZMM16-31
+ registers with a single variable. Make use of this to merge
+ various loops working on the ZMM XSAVE region so that all of the
+ handling for the various sub-registers in this region are always
+ handled in a single loop.
+
+ - While here, fix some bugs in i387_cache_to_xsave where if
+ X86_XSTATE_ZMM was set on i386 (e.g. a 32-bit process on a 64-bit
+ kernel), the -1 register nums would wrap around and store the value
+ of GPRs in the XSAVE area. This should be harmless, but is
+ definitely odd. Instead, check num_zmm_high_registers directly when
+ checking X86_XSTATE_ZMM and skip the ZMM region handling entirely if
+ the register count is 0.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ x86: Remove X86_XSTATE_SIZE and related constants.
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 Aleksandar Paunovic <aleksandar.paunovic@intel.com>
+ John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Use x86_xstate_layout to parse the XSAVE extended state area.
+ Replace the extended state area fields of i387_xsave with methods which
+ return an offset into the XSAVE buffer.
+
+ The two changed functions are called within all tests which runs
+ gdbserver.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 Aleksandar Paunovic <aleksandar.paunovic@intel.com>
+ John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Refactor the legacy region within the xsave struct
+ Legacy fields of the XSAVE area are already defined within fx_save
+ struct. Use class inheritance to remove code duplication.
+
+ The two changed functions are called within all tests which run
+ gdbserver.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Add a function to set the XSAVE mask and size.
+ Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
+ the value instead. Add a static global instance of x86_xsave_layout
+ and initialize it in the new function as well to be used in a future
+ commit to parse XSAVE extended state regions.
+
+ Update the Linux port to use this function rather than setting
+ x86_xcr0 directly. In the case that XML is not supported, don't
+ bother setting x86_xcr0 to the default value but just omit the call to
+ i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
+ non-XML.
+
+ In addition, use x86_xsave_length to determine the size of the XSAVE
+ register set via CPUID.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Use x86_xstate_layout to parse the XSAVE extended state area.
+ All of the tables describing the offsets of individual registers for
+ XSAVE state components now hold relative offsets rather than absolute
+ offsets. Some tables (those for MPX registers and ZMMH registers) had
+ to be split into separate tables as they held entries that spanned
+ multiple state components.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Support XSAVE layouts for the current host in the Linux x86 targets.
+ Note that this uses the CPUID instruction to determine the total size
+ of the XSAVE register set. If there is a way to fetch the register set
+ size using ptrace that would probably be better.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Update x86 Linux architectures to support XSAVE layouts.
+ Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding
+ x86_xsave_layout as well as xcr0 using the size of an existing
+ NT_X86_XSTATE core dump to determine the offsets via
+ i387_guess_xsave_layout. Use this to add an implementation of
+ gdbarch_core_xfer_x86_xsave_layout.
+
+ Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
+ set.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets.
+ Use the CPUID instruction to fetch the offsets of supported state
+ components.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Update x86 FreeBSD architectures to support XSAVE layouts.
+ Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding
+ x86_xsave_layout as well as xcr0 using the size of an existing
+ NT_X86_XSTATE core dump to determine the offsets via
+ i387_guess_xsave_layout. Use this to add an implementation of
+ gdbarch_core_xfer_x86_xsave_layout.
+
+ Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
+ set and only fetch/store the register set if this size is non-zero.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ x86 nat: Add helper functions to save the XSAVE layout for the host.
+ x86_xsave_length returns the total length of the XSAVE state area
+ standard format as queried from CPUID.
+
+ x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE
+ extended regions from the running host. The total length of the XSAVE
+ state area can either be supplied by the caller if known (e.g. from
+ FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host
+ using x86_xsave_length.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count.
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ core: Support fetching x86 XSAVE layout from architectures.
+ Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
+ structure from a core file.
+
+ Current OS's do not export the offsets of XSAVE state components in
+ core dumps, so provide an i387_guess_xsave_layout helper function to
+ set offsets based on known combinations of XCR0 masks and total state
+ sizes. Eventually when core dumps do contain this information this
+ function should only be used as a fall back for older core dumps.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: Store an x86_xsave_layout in i386_gdbarch_tdep.
+ This structure is fetched from the current target in i386_gdbarch_init
+ via a new "fetch_x86_xsave_layout" target method.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 John Baldwin <jhb@FreeBSD.org>
+ Aleksandar Paunovic <aleksandar.paunovic@intel.com>
+
+ x86: Add an x86_xsave_layout structure to handle variable XSAVE layouts.
+ The standard layout of the XSAVE extended state area consists of three
+ regions. The first 512 bytes (legacy region) match the layout of the
+ FXSAVE instruction including floating point registers, MMX registers,
+ and SSE registers. The next 64 bytes (XSAVE header) contains a header
+ with a fixed layout. The final region (extended region) contains zero
+ or more optional state components. Examples of these include the
+ upper 128 bits of YMM registers for AVX.
+
+ These optional state components generally have an
+ architecturally-fixed size, but they are not assigned architectural
+ offsets in the extended region. Instead, processors provide
+ additional CPUID leafs describing the size and offset of each
+ component in the "standard" layout for a given CPU. (There is also a
+ "compact" format which uses an alternate layout, but existing OS's
+ currently export the "standard" layout when exporting XSAVE data via
+ ptrace() and core dumps.)
+
+ To date, GDB has assumed the layout used on current Intel processors
+ for state components in the extended region and hardcoded those
+ offsets in the tables in i387-tdep.c and i387-fp.cc. However, this
+ fails on recent AMD processors which use a different layout.
+ Specifically, AMD Zen3 and later processors do not leave space for the
+ MPX register set in between the AVX and AVX512 register sets.
+
+ To rectify this, add an x86_xsave_layout structure which contains the
+ total size of the XSAVE extended state area as well as the offset of
+ each known optional state component.
+
+ Subsequent commits will modify XSAVE parsing in both gdb and gdbserver
+ to use x86_xsave_layout.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-08-28 Tom Tromey <tromey@adacore.com>
+
+ Use sect_offset_str in cooked_index::dump
+ Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
+ Andreas Schwab pointed out that gdb already has sect_offset_str. This
+ patch applies both these observations.
+
+2023-08-28 Mark Wielaard <mark@klomp.org>
+
+ Use hex_string in gdb/coffread.c instead of PRIxPTR
+ The getsymname function uses PRIxPTR to print and uintptr_t value in
+ an error message. Use hex_string instead.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle self-reference in inherit_abstract_dies
+ Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
+ self-referencing DIE:
+ ...
+ <2><91dace>: Abbrev Number: 405 (DW_TAG_label)
+ <91dad0> DW_AT_abstract_origin: <0x91dace>
+ ...
+
+ When encountering the self-reference DIE in inherit_abstract_dies we loop
+ following the abstract origin, effectively hanging gdb.
+
+ Fix this by handling self-referencing DIEs in the loop in
+ inherit_abstract_dies.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30799
+ https://sourceware.org/bugzilla/show_bug.cgi?id=30799
+
+2023-08-28 Alan Modra <amodra@gmail.com>
+
+ COFF swap_aux_in
+ A low level function like coff_swap_aux_in really has no business
+ concatenating multiple auxents for the old PE multi-aux scheme of
+ handling long file names. In doing so, it assumes multiple internal
+ auxent buffers are available, which they are not in most calls to
+ bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB. Buffer
+ overflow fun. Concatenating multiple auxents belongs at a higher
+ level.
+
+ This required some changes to coff_get_normalized_symtab, which now
+ uses the external auxents to access the concatenated file name.
+ (Internal auxents are larger than the x_fname array, so the pieces of
+ the file name are not adjacent as they are in the external auxents.)
+
+ * coffswap.h (coff_swap_aux_in): Do not write more than one
+ internal auxent.
+ * coffcode.h (coff_bigobj_swap_aux_in): Likewise.
+ * coffgen.c (coff_get_normalized_symtab): Normalize strings
+ after swapping in each symbol so that external auxents are
+ available. Use external auxents for multi-aux long file
+ names. Formatting. Wrap long lines. Remove excess parens
+ and unnecessary casts. Don't zalloc when only the string
+ terminator needs zeroing, and memcpy rather than strncpy.
+ Delete unnecessary sanity check with unsigned _n_offset.
+ Return with failure if debug section can't be read, to avoid
+ trying to read it multiple times. Correct sanity check
+ against debug section size.
+
+2023-08-28 Alan Modra <amodra@gmail.com>
+
+ Re: comdat_hash memory leaks
+ I missed another field that needs freeing. Also, oss-fuzz found a
+ case with a C_FILE sym using multiple auxents for a long file name
+ which overflowed the single auxent buffer. I'm going to fix that
+ problem in swap_aux_in too, but we may as well avoid it here too,
+ saving unnecessary work.
+
+ * coffcode.h (comdat_delf): Free comdat_name.
+ (fill_comdat_hash): Only look at symbols with one auxent.
+
+2023-08-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail in gdb.cp/subtypes.exp
+ When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into:
+ ...
+ FAIL: gdb.cp/subtypes.exp: ptype main::Foo
+ FAIL: gdb.cp/subtypes.exp: ptype main::Bar
+ FAIL: gdb.cp/subtypes.exp: ptype main::Baz
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar
+ FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz
+ ...
+
+ The problem is gcc PR debug/55541, which generates a superfluous
+ DW_TAG_lexical_block.
+
+ Add a corresponding xfail.
+
+ Tested on x86_64-linux.
+
+2023-08-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Refactor gdb.cp/subtypes.exp
+ Make test-case gdb.cp/subtypes.exp less repetitive by using foreach.
+
+ Tested on x86_64-linux.
+
+2023-08-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle gdb.cp/*.exp with older compiler
+ When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
+ failures due to the test-cases requiring c++11 and the compiler defaulting
+ to less than that.
+
+ Fix this by compiling with -std=c++11.
+
+ This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
+ gcc PR debug/16063, so xfail those.
+
+ Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
+ prevent compilation failure.
+
+ Tested on x86_64-linux.
+
+2023-08-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets
+ Following the arrangement in GCC select a 64-bit ABI by default, either
+ n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as
+ with the corresponding `mips64*-*-linux*' targets.
+
+ Gold/MIPS: Add mips64*/mips64*el triple support
+ Use targ_size=64 and targ_extra_size=32
+
+ Gold/MIPS: Add targ_extra_size=64 for mips32 triples
+ So we can enable 64bit ELF support for MIPS32 toolchain.
+
+ Gold/MIPS: Drop mips*le/mips*el* triple pattern
+ Only mips*el triples are supported by binutils. The mips*le
+ or mips*el* may cause some problem with other components of
+ binutils, since they will consider them as big endian.
+
+2023-08-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian
+ EM_MIPS_RS3_LE has been deprecated quite long ago, and in fact
+ most of current LE ELF files are using EM_MIPS.
+
+ This problem didn't make some trouble for us, is due to that
+ gold is a linker, and all of the inputs to it has right EM values.
+
+2023-08-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ Gold: Add targ_extra_little_endian to configure.ac
+ This option will be used by architectures which is big endian
+ by default, while little-endian support is also needed.
+
+ Mips(eb) ports are the examples.
+
+2023-08-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-27 Alan Modra <amodra@gmail.com>
+
+ PE dos_message
+ I was looking at dos_message and wondering why we have H_PUT_32
+ in _bfd_XXi_only_swap_filehdr_out but no H_GET_32 in pe_bfd_object_p.
+ On a big-endian machine this would result in scrambling the code and
+ strings constained in dos_message. Rather than fix the lack of
+ H_GET_32 in pe_bfd_object_p, I decided it doesn't make sense to store
+ dos_message internally as an array of ints.
+
+ include/
+ * coff/internal.h (struct internal_extra_pe_filehdr): Make
+ dos_message a char array.
+ * coff/msdos.h (struct external_DOS_hdr): Flatten dos_message.
+ * coff/pe.h (struct external_PEI_filehdr): Likewise.
+ bfd/
+ * libcoff-in.h (struct pe_tdata): Make dos_message a char array.
+ * libcoff.h: Regenerate.
+ * peXXigen.c (_bfd_XXi_only_swap_filehdr_out): memcpy dos_message
+ to output.
+ * peicode.h (pe_mkobject): Don't memset already zeroed pe_opthdr.
+ Tidy allocation of tdata.pe_obj_data. Set up dos_message from..
+ (default_dos_message): ..this. New static array.
+
+2023-08-27 Alan Modra <amodra@gmail.com>
+
+ comdat_hash memory leaks
+ Entries added to the hash table with bfd_malloc ought to be freed when
+ the hash table is deleted. This patch adds the necessary del_f to the
+ htab_create call, and delays creating the table until an
+ IMAGE_SCN_LNK_COMDAT symbol is read.
+
+ * peicode.h (pe_mkobject): Move comdat_hash creation..
+ (htab_hash_flags, htab_eq_flags): ..and these support functions..
+ * coffcode.h (handle_COMDAT): ..to here, renaming support to
+ (comdat_hashf, comdat_eqf): ..this and adding..
+ (comdat_delf): ..this new function.
+
+2023-08-27 Alan Modra <amodra@gmail.com>
+
+ Confusion in coff_object_cleanup
+ A bfd_cleanup function needs to run when only tdata is correct for the
+ bfd. The xvec may have changed during bfd_check_format and thus the
+ flavour may be incorrect. The format won't have changed but checking
+ is superfluous. (In contrast to _bfd_free_cached_info or
+ _close_and_cleanup where we do need to check things.)
+
+ Not getting this correct leaked comdat_hash.
+
+ Also, pe_ILF_cleanup ought to call coff_object_cleanup as do all PE
+ files.
+
+ * coffgen.c (coff_object_cleanup): Don't check bfd flavour or
+ format.
+ * peicode.h (pe_ILF_cleanup): Call coff_object_cleanup.
+
+2023-08-27 Alan Modra <amodra@gmail.com>
+
+ sanity check n_numaux
+ Sanity check aux entries used by PE to extend a C_FILE name. See
+ coffswap.h:coff_swap_aux_in. The existing check only catered for
+ n_numaux == 1.
+
+ * coffcode.h (fill_comdat_hash): Properly sanity check n_numaux.
+ Formatting.
+ (handle_COMDAT): Formatting.
+
+2023-08-27 Alan Modra <amodra@gmail.com>
+
+ Re: ld STRINGIFY
+ Oops there was a reference to the old name.
+
+ * emultempl/aix.em: Use stringify.sed.
+
+2023-08-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-26 Tom Tromey <tom@tromey.com>
+
+ Simplify definition of GUILE
+ This patch sets GUILE to just plain 'guile'.
+
+ In the distant ("devo") past, the top-level build did support building
+ Guile in-tree. However, I don't think this really works any more.
+ For one thing, there are no build dependencies on it, so there's no
+ guarantee it would actually be built before the uses.
+
+ This patch also removes the use of "-s" as an option to cgen scheme
+ scripts. With my latest patch upstream, this is no longer needed.
+
+ After the upstream changes, either Guile 2 or Guile 3 will work, with
+ or without the compiler enabled.
+
+ 2023-08-24 Tom Tromey <tom@tromey.com>
+
+ * cgen.sh: Don't pass "-s" to cgen.
+ * Makefile.in: Rebuild.
+ * Makefile.am (GUILE): Simplify.
+
+2023-08-26 Tom Tromey <tom@tromey.com>
+
+ Use get_frame_address_in_block in print_frame
+ The author of 'mold' pointed out that with a certain shared library,
+ gdb would fail to find the shared library's name in 'bt'.
+
+ The function in question appeared at the end of the .so's .text
+ segment and ended with a call to 'abort'.
+
+ This turned out to be a classic case of calling get_frame_pc when
+ get_frame_address_in_block is needed -- the former will be off-by-one
+ for purposes of finding the enclosing function or shared library.
+
+ The included test fails without the patch on my system. However, I
+ imagine it can't be assumed to reliably fail. Nevertheless it seemed
+ worth doing.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-08-26 Alan Modra <amodra@gmail.com>
+
+ opcodes i386 and ia64 gen file warnings
+ i386: warning: format ‘%u’ expects argument of type ‘unsigned int’,
+ but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
+ ia64: warning: ignoring return value of ‘fgets’
+
+ * i386-gen.c (process_i386_opcodes): Correct format string.
+ * ia64-gen.c (load_insn_classes, load_depfile): Don't ignore
+ fgets return value.
+
+2023-08-26 Alan Modra <amodra@gmail.com>
+
+ ld STRINGIFY
+ Delete support for old compilers that don't support string
+ concatentation.
+
+ * Makefile.am (stringify.sed): Delete rule.
+ (GEN_DEPENDS, DISTCLEANFILES): Adjust.
+ * configure.ac (STRINGIFY): Delete.
+ * emultempl/beos.em: Use stringify.sed from srcdir.
+ * emultempl/elf.em: Likewise.
+ * emultempl/generic.em: Likewise.
+ * emultempl/msp430.em: Likewise.
+ * emultempl/pdp11.em: Likewise.
+ * emultempl/pe.em: Likewise.
+ * emultempl/pep.em: Likewise.
+ * emultempl/stringify.sed: Renamed from..
+ * emultempl/astring.sed: ..this.
+ * emultempl/ostring.sed: Delete.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+2023-08-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-26 Alan Modra <amodra@gmail.com>
+
+ ld .deps/*.Pc files
+ This patch gets rid of the individual rules including the .Pc
+ dependency files made while generating e*.c files, replacing them with
+ a fancy GNU make pattern include. I've also moved creation of
+ ldscripts to the makefile since it is possible to run more than one
+ genscripts at once, resulting in "ldscripts: File exists" messages.
+
+ * Makefile.am: Replace individual include of *.Pc dependency
+ files with one pattern rule.
+ (.Pc): New dummy rule.
+ (ldscripts/stamp): New rule.
+ (GEN_DEPENDS): Add ldscripts/stamp.
+ (install-data-local): Exclude ldscripts/stamp from install.
+ * genscripts.sh: Don't make ldscripts dir.
+ * Makefile.in: Regenerate.
+
+2023-08-25 Mark Wielaard <mark@klomp.org>
+
+ Fix gdb/coffread.c build on 32bit architectures
+ The getsymname function tries to emit an error using %ld for an
+ uintptr_t argument. Use PRIxPTR instead. Which works on any architecture
+ for uintptr_t.
+
+2023-08-25 Keith Seitz <keiths@redhat.com>
+
+ Verify COFF symbol stringtab offset
+ This patch addresses an issue with malformed/fuzzed debug information that
+ was recently reported in gdb/30639. That bug specifically deals with
+ an ASAN issue, but the reproducer provided by the reporter causes a
+ another failure outside of ASAN:
+
+ $ ./gdb --data-directory data-directory -nx -q UAF_2
+ Reading symbols from /home/keiths/UAF_2...
+
+
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ 0x59a53a gdb_internal_backtrace_1
+ ../../src/gdb/bt-utils.c:122
+ 0x59a5dd _Z22gdb_internal_backtracev
+ ../../src/gdb/bt-utils.c:168
+ 0x786380 handle_fatal_signal
+ ../../src/gdb/event-top.c:889
+ 0x7864ec handle_sigsegv
+ ../../src/gdb/event-top.c:962
+ 0x7ff354c5fb6f ???
+ 0x611f9a process_coff_symbol
+ ../../src/gdb/coffread.c:1556
+ 0x611025 coff_symtab_read
+ ../../src/gdb/coffread.c:1172
+ 0x60f8ff coff_read_minsyms
+ ../../src/gdb/coffread.c:549
+ 0x60fe4b coff_symfile_read
+ ../../src/gdb/coffread.c:698
+ 0xbde0f6 read_symbols
+ ../../src/gdb/symfile.c:772
+ 0xbde7a3 syms_from_objfile_1
+ ../../src/gdb/symfile.c:966
+ 0xbde867 syms_from_objfile
+ ../../src/gdb/symfile.c:983
+ 0xbded42 symbol_file_add_with_addrs
+ ../../src/gdb/symfile.c:1086
+ 0xbdf083 _Z24symbol_file_add_from_bfdRKN3gdb7ref_ptrI3bfd18gdb_bfd_ref_policyEEPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaISC_EES8_I12objfile_flagEP7objfile
+ ../../src/gdb/symfile.c:1166
+ 0xbdf0d2 _Z15symbol_file_addPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaIS5_EES1_I12objfile_flagE
+ ../../src/gdb/symfile.c:1179
+ 0xbdf197 symbol_file_add_main_1
+ ../../src/gdb/symfile.c:1203
+ 0xbdf13e _Z20symbol_file_add_mainPKc10enum_flagsI16symfile_add_flagE
+ ../../src/gdb/symfile.c:1194
+ 0x90f97f symbol_file_add_main_adapter
+ ../../src/gdb/main.c:549
+ 0x90f895 catch_command_errors
+ ../../src/gdb/main.c:518
+ 0x9109b6 captured_main_1
+ ../../src/gdb/main.c:1203
+ 0x910fc8 captured_main
+ ../../src/gdb/main.c:1310
+ 0x911067 _Z8gdb_mainP18captured_main_args
+ ../../src/gdb/main.c:1339
+ 0x418c71 main
+ ../../src/gdb/gdb.c:39
+ ---------------------
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ Segmentation fault (core dumped)
+
+ The issue here is that the COFF offset for the fuzzed symbol's
+ name is outside the string table. That is, the offset is greater
+ than the actual string table size.
+
+ coffread.c:getsymname actually contains a FIXME about this, and that's
+ what I've chosen to address to fix this issue, following what is done
+ in the DWARF reader:
+
+ $ ./gdb --data-directory data-directory -nx -q UAF_2
+ Reading symbols from /home/keiths/UAF_2...
+ COFF Error: string table offset (256) outside string table (length 0)
+ (gdb)
+
+ Unfortunately, I haven't any idea how else to test this patch since
+ COFF is not very common anymore. GCC removed support for it five
+ years ago with GCC 8.
+
+2023-08-25 John Baldwin <jhb@FreeBSD.org>
+
+ Update FreeBSD system calls for the upcoming 14.0-RELEASE
+ This matches the current set of system calls at the start of the
+ stable/14 branch (commit 29a16ce065dbc28bc9e87c9bfadb08bb58b137e4).
+
+2023-08-25 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix for call feature having 9th function parameter and beyond corrupt values.
+ In AIX the first eight function parameters are stored from R3 to R10.
+ If there are more than eight parameters in a function then we store the 9th parameter onwards in the stack.
+ While doing so, in 64 bit mode the words were not zero extended and was coming like 32 bit mode.
+ This patch is a fix to the same.
+
+ Fix 64 bit red zone frame size in AIX
+
+2023-08-25 Jan Beulich <jbeulich@suse.com>
+
+ bfd: correct relocation handling for objcopy COFF -> ELF
+ While documented to not be reliable, it is still odd for objcopy to
+ silently produce bad output when converting COFF/PE object files to ELF
+ ones. The issue there is that relocation addends all are screwed up by
+ subtracting the symbol's section offset. In the COFF/PE world, to my
+ knowledge, section contents stores the addends alone, not the result of
+ symbol value plus addend. Hence the compensation talked about in a
+ comment ahead of the sole use site of CALC_ADDEND() may need to account
+ for the VMA (which is always zero for object files anyway), but not for
+ the symbol value.
+
+ The coff-sh.c adjustment is based upon guessing that behavior there is
+ the same. Note also how coff-aarch64.c short-circuits CALC_ADDEND()
+ altogether, which may suggest that a much simpler macro might do for the
+ COFF_WITH_PE case in the three arch-specific files touched here.
+
+ For (at least) Arm/WinCE this actually results in more appropriate
+ objdump output as well, as can be seen in the one testcase which has its
+ expectations adjusted (the generated binary doesn't change).
+
+2023-08-25 Jan Beulich <jbeulich@suse.com>
+
+ gas/ELF: widen use of $dump_opts in testsuite
+ Rather than special-casing rx-*-* for section30, force use of
+ conventional section names uniformly. By further passing $dump_opts to
+ a few more tests, a number of xfail-s (and one notarget) can be
+ eliminated (some of which had wrong justifications in associated
+ comments anyway). Note that section7 and section15 need to be left
+ alone: The harness fiddling with section names there didn't help before
+ and is getting in the way now. For section12b, section16b, and most of
+ the Dwarf tests nothing changes. Interestingly by passing $dump_opts
+ the need to xfail section11 for LoongArch and RISC-V also goes away.
+
+2023-08-25 Jan Beulich <jbeulich@suse.com>
+
+ gas/ELF: allow "inheriting" section attributes and type
+ While --sectname-subst is nice, it isn't enough to e.g. mimic
+ -f{function,data}-sections in assembly code, when such use is to be
+ optional (e.g. dependent upon some configuration setting).
+
+ Assign meaning to '+' and '-' as section attribute letters, allowing
+ to inherit the prior section's attributes (and possibly type) along
+ with adding or removing some. Note that documenting the interaction
+ with '?' as undefined is a precautionary measure.
+
+ While touching the function invocation, stop using |= on the result of
+ obj_elf_parse_section_letters(): "attr" is firmly zero ahead of the
+ call.
+
+2023-08-25 Alan Modra <amodra@gmail.com>
+
+ Use GNU make pattern rule in ld Makefile
+ Use the pattern rule in a comment from commit 77ac17b8453f.
+
+ * Makefile.am (run-genscripts): Delete. Use pattern rule
+ e%.c instead.
+ * Makefile.in: Regenerate.
+
+2023-08-25 Alan Modra <amodra@gmail.com>
+
+ som: buffer overflow writing strings
+ Code in som_write_symbol_strings neglected to allow for padding, which
+ can result in a buffer overflow. It also used xrealloc, which we're
+ not supposed to use in libbfd because libbfd isn't supposed to call
+ exit. Also a realloc is perhaps not a good idea when none of the
+ buffer contents are needed, so replace with free, bfd_malloc. There
+ were three copies of the string handling code, so rather than fix them
+ all I've extracted them to a function. This necessitated making one
+ of the fields in struct som_symbol unsigned.
+
+ * som.c (add_string): New function.
+ (som_write_space_strings, som_write_symbol_strings): Use it.
+ * som.h (som_symbol_type <stringtab_offset>): Make unsigned.
+
+2023-08-25 Alan Modra <amodra@gmail.com>
+
+ PR30794, PowerPC gold: internal error in add_output_section_to_load
+ Caused by commit 5a97377e5513, specifically this code added to
+ Target_powerpc::do_relax
+ + if (parameters->options().output_is_position_independent())
+ + this->rela_dyn_size_
+ + = this->rela_dyn_section(layout)->current_data_size();
+
+ The problem here is that if .rela.dyn isn't already created then the
+ call to rela_dyn_section creates it, and as this comment in
+ Target_powerpc::do_finalize_sections says:
+ // Annoyingly, we need to make these sections now whether or
+ // not we need them. If we delay until do_relax then we
+ // need to mess with the relaxation machinery checkpointing.
+ We can't be creating sections in do_relax.
+
+ PR 30794
+ * powerpc.cc (Target_powerpc::do_relax): Only set rela_dyn_size_
+ for size == 64, and assert that rela_dyn_ already exists.
+ Tidy code setting plt_thread_safe, which also only needs to be
+ set when size == 64 for ELFv1.
+
+2023-08-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-24 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/solib-rocm: Detect SO for unsupported AMDGPU device
+ It is possible to debug a process which uses unsupported AMDGPU devices.
+ In such scenario, we can still use librocm-dbgapi.so to attach to the
+ process and complete the runtime activation sequence.
+
+ However, when listing shared objects loaded on the AMDGPU devices, we
+ might list SOs loaded on the unsupported devices. If such SO is
+ seen, one of two things can happen.
+
+ First, if the arch of this device is unknown to BFD,
+ 'gdbarch_find_by_info (gdbarch_info info)' will return the gdbarch
+ matching default_bfd_arch. As a result,
+ rocm_solib_relocate_section_addresses will delegate the relocation
+ operation to svr4_so_ops.relocate_section_addresses, but this makes no
+ sense: this code object was not loaded by the system loader.
+
+ The second case is if BFD knows the micro-architecture of the device,
+ but dbgapi does not support it. In such case, gdbarch_info_fill will
+ successfully identify an amdgcn architecture (bfd_arch_amdgcn). From
+ there, gdbarch_find_by_info calls amdgpu_gdbarch_init which will fail to
+ query arch specific details from dbgapi and subsequently fail to
+ initialize the gdbarch object. As a result, gdbarch_find_by_info
+ returns nullptr, which will down the line cause some "gdb_assert
+ (gdbarch != nullptr)" assertion failures.
+
+ This patch proposes to add a check in rocm_solib_bfd_open to ensure that
+ the architecture associated with the code object to open is fully
+ supported by both BFD and amd-dbgapi, and error-out otherwise.
+
+ Change-Id: Ica97ab7cba45e4944b77d3080c54c1038aaeda54
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-08-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Return gdb::array_view in thread_info_to_thread_handle
+ In remote_target::thread_info_to_thread_handle we return a copy:
+ ...
+ gdb::byte_vector
+ remote_target::thread_info_to_thread_handle (struct thread_info *tp)
+ {
+ remote_thread_info *priv = get_remote_thread_info (tp);
+ return priv->thread_handle;
+ }
+ ...
+
+ Fix this by returning a gdb::array_view instead:
+ ...
+ gdb::array_view<const gdb_byte>
+ remote_target::thread_info_to_thread_handle (struct thread_info *tp)
+ ...
+
+ Tested on x86_64-linux.
+
+ This fixes the build when building with -std=c++20.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-08-24 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: fix kvx_reassemble_bundle index 8 out of bounds
+ opcodes/
+ * kvx-dis.c (print_insn_kvx): Change the loop condition so that
+ wordcount is always less than KVXMAXBUNDLEWORDS.
+ (decode_prologue_epilogue_bundle): Likewise.
+
+2023-08-24 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Multiple improvements for gdb.reverse/insn-reverse.exp
+ This commits tackles 2 problems in the test
+ gdb.reverse/insn-reverse.exp. They are, broadly: flawed logic when an
+ unexpected error occurs, and badly formed asm expressions.
+
+ For the first, what happens is that if the inferior stops progressing
+ for some reason, the test will emit an UNSUPPORTED and continue testing
+ by reversing from the current location and checking all registers for
+ every instruction. However, due to how the outputs are indexed in the
+ test, this early exit will cause most of the subsequent tests to be
+ de-synced and will emit many unrelated failures.
+
+ This commit changes the UNSUPPORTED for a FAIL, since the test has in
+ fact failed to record the execution of the whole function, and
+ decrements the recorded instruction count by one so that the indexes are
+ in sync once more.
+
+ At the time of committing, this reduces the amount of failures when
+ testing with clang-15 from around 150 to 2, and correctly identifies
+ where the issue lies.
+
+ The second problem is in how the asm statements in the *-x86.c file
+ are written. As an example, let's examine the following line:
+
+ __asm__ volatile ("rdrand %%ebp;" : "=r" (number));
+
+ This statement says that number is being used as the output variable,
+ but is not indicating which registers were clobbered so that the
+ compiler is able to properly output. GCC decides to just not save
+ anything, whereas clang assumes that the output is in %rax, and writes
+ it to the variable. This hid the problem that any compiler is not good
+ at dealing with asm statements that change the rbp register. It can be
+ seen more explicitly by informing gcc that rbp has been clobbered like
+ so:
+
+ __asm__ volatile ("rdrand %%ebp;" : "=r" (number) : : "%ebp");
+
+ This statement gets compiled into the following assembly:
+ rdrandl %ebp
+ movl %eax, -4(%rbp)
+
+ Which is clearly using the incorrect rbp to find the memory location of
+ the variable. Since the test only exercises GDB's ability to record the
+ register changes, this commit removes the output to memory.
+
+ Finally, correctly informing the compiler of clobbered registers
+ makes gcc throw an error that the rsp is no longer usable at the end of
+ the function. To avoid that, this commit compresses the 3 asm statements
+ that would save, change and reset registers into a single asm statement.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-24 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix testing gdb.reverse/step-reverse.exp with clang
+ When testing using reverse-stepi to fully step through a function, the
+ code checks for an infinite loop by seeing if we land on the line that
+ contains the return statement multiple times. This assumption only works
+ if there is only one instruction associated with that line, which is how
+ GCC handles line information, but other compilers may handle it differently.
+ Clang-15, for instance, associates 6. Because of this, the inferior used
+ to get seriously out of sync with the test expectations, and result in 13
+ spurious failures. The same issue occurs with gdb.reverse/step-precsave.exp.
+
+ This commit changes the test so that we check for PC instead of line
+ number. The test still only happens when the same line is detected, to
+ simplify the resulting log. With this change, no new failures are
+ emitted when using clang.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-24 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix gdb.reverse/solib-*.exp tests when using clang
+ The tests gdb.reverse/solib-precsave.exp and solib-reverse.exp have the
+ assumption that line tables will have an entry for the closing } in a
+ function. Not all compiles do this, one example being clang. To fix
+ this, this commit changes the function in shr2.c to have multiple lines,
+ and the test to accept either line as a correct step location.
+
+ To properly re-sync the inferiors, the function repeat_cmd_until had to
+ be slightly changed to work with empty "current locations", so that we
+ are able to step through multiple lines.
+
+ This also changes the annotations used to determine the breakpoint
+ locations in solib-reverse.c, adding a simple variable assignment right
+ before the return statement. This way GDB will not set a breakpoint in
+ the closing } line.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-24 Guinevere Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Fix many errors in gdb.reverse with clang
+ Clang does not add line information for lines that only contain a
+ closing } in functions. Many tests in the gdb.reverse folder set a
+ breakpoint in that line, but don't seem to use information available
+ after the return statement is executed, so this commit moves the
+ breakpoint to the previous line, where the return statement is.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-24 Alan Modra <amodra@gmail.com>
+
+ kvx: workaround gcc-4.5 bug
+ kvx-dis.c:1078:10: error: missing initializer
+ kvx-dis.c:1078:10: error: (near initialization for 'dec.nb_ops')
+
+ * kvx-dis.c (print_insn_kvx): Init dec with memset.
+ (decode_prologue_epilogue_bundle): Likewise.
+
+2023-08-24 Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
+
+ optimize handle_COMDAT
+
+2023-08-24 Alan Modra <amodra@gmail.com>
+
+ nds32, sh, kvx: DT_JMPREL/DT_PLTRELSZ
+ As commit fa4f2d46f9 did for x86, there a few other targets that
+ wrongly use the output section rather than the dynamic section for
+ DT_JMPREL and others.
+
+ * elfnn-kvx.c (elfNN_kvx_finish_dynamic_sections): Use input
+ section for DT_JMPREL.
+ * elf32-sh.c (sh_elf_finish_dynamic_sections): Use input
+ section for DT_JMPREL and DT_PLTRELSZ.
+ * elf32-nds32.c (nds32_elf_finish_dynamic_sections): Likewise,
+ and for DT_PLTGOT and when adjusting DT_RELA.
+
+2023-08-24 Stafford Horne <shorne@gmail.com>
+
+ sim: or1k: Eliminate dangerous RWX load segments
+ This fixes test failures caused by the new linker warning which report:
+
+ ./ld/ld-new: warning: load.S.x has a LOAD segment with RWX permissions
+
+ Fix this by splitting the linker MEMORY into ram and rom to avoid
+ generating RWX sections. This required tests to be adjusted to fix
+ issues with the move. Namely:
+
+ - fpu tests: were incorrectly using l.ori with ha(anchor) which now
+ that we pushed the anchor up in memory it exposes the bug. Update
+ to used the correct l.movhi instruction instead.
+ - adrp test: the test reports ram offset addresses, now that we have
+ moved memory layout around a bit I adjusted the test output. Some
+ padding is added before pi to show that the actual address of pi and
+ the adrp page offset are not the same.
+
+ Bug: https://sourceware.org/PR29957
+
+2023-08-24 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: bfd/config.bfd & ld/configure.tgt
+ bfd/
+ * config.bfd: Remove kvx_elf64_vec from targ_selvecs as it is
+ already in targ_defvec.
+ ld/
+ * configure.tgt: Split long line.
+
+2023-08-24 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: use {u,}int32_t and {u,}int64_t
+ gas/
+ * config/kvx-parse.c (promote_token): Use {u,}int32_t and
+ {u,}int64_t.
+ (get_token_class): Likewise.
+ * config/tc-kvx.c (insert_operand): Likewise.
+ * config/tc-kvx.h (struct token_s): Likewise.
+ (struct token_list): Likewise.
+
+ opcodes/
+ * kvx-dis.c (struct decoded_insn): Use {u,}int32_t and
+ {u,}int64_t.
+ (decode_insn): Likewise.
+ (print_insn_kvx): Likewise.
+ (decode_prologue_epilogue_bundle): Likewise.
+ * kvx-dis.h (struct kvx_prologue_epilogue_insn): Likewise.
+
+2023-08-24 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: fix handling of STB_GNU_UNIQUE symbols
+ When processing a STB_GNU_UNIQUE symbol we did not update has_gnu_osabi
+ correctly.
+
+ * config/tc-kvx.c (kvx_end): Do not write to e_ident.
+ (kvx_type): Properly handle STB_GNU_UNIQUE symbols.
+
+2023-08-24 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: remove kvx_elf64_linux_vec
+ * configure.ac: Remove kvx_elf64_linux_vec.
+ * configure: Regenerate.
+
+2023-08-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Run black on make-target-delegates.py
+ Run black on make-target-delegates.py to fix buildbot build breaker.
+
+ Tested on x86_64-linux.
+
+2023-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Support reference return type in make-target-delegates.py
+ When doing this in target.h:
+ ...
+ - virtual gdb::byte_vector thread_info_to_thread_handle (struct thread_info *)
+ + virtual gdb::byte_vector &thread_info_to_thread_handle (struct thread_info *)
+ ...
+ make-target-delegates.py drops the function.
+
+ By handling '&' in POINTER_PART we can prevent that the function is dropped,
+ but when recompiling target.o we get:
+ ...
+ gdb/target-delegates.c: In member function ‘virtual gdb::byte_vector& \
+ debug_target::thread_info_to_thread_handle(thread_info*)’:
+ gdb/target-delegates.c:1889:22: error: ‘result’ declared as reference but not \
+ initialized
+ gdb::byte_vector & result;
+ ^~~~~~
+ make: *** [Makefile:1923: target.o] Error 1
+ ...
+
+ Fix this by making sure result is initialized.
+
+ Regenerate target-delegates.c using this new style.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-08-23 Peter Edwards <peadar@arista.com>
+
+ x86: Fix DT_JMPREL/DT_PLTRELSZ when relocs share a section
+ If a linker script does not place the PLT relocations and "normal"
+ relocations in separate ELF sections, `ld` will currently output incorrect
+ values for DT_JMPREL and DT_PLTRELSZ - they cover the entire ELF section,
+ rather than just the PLT relocations
+
+ Don't ignore the extent of the BFD section - use the size of the srelplt
+ BFD section and its offset from the output_secttion
+
+ bfd/
+
+ PR ld/30787
+ * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use input
+ section for DT_JMPREL and DT_PLTRELSZ.
+
+ ld/
+
+ PR ld/30787
+ * testsuite/ld-i386/i386.exp: Run pr30787.
+ * testsuite/ld-x86-64/x86-64.exp: Likewise.
+ * testsuite/ld-i386/pr30787.d: New file.
+ * testsuite/ld-i386/pr30787.s: Likewise.
+ * testsuite/ld-i386/pr30787.t: Likewise.
+ * testsuite/ld-x86-64/pr30787.d: Likewise.
+ * testsuite/ld-x86-64/pr30787.s: Likewise.
+ * testsuite/ld-x86-64/pr30787.t: Likewise.
+
+2023-08-23 Lancelot Six <lancelot.six@amd.com>
+
+ gdb: fix build failure in amd-dbgapi-target.c
+ Since b080fe54fb3 "gdb: add inferior-specific breakpoints", the
+ breakpoint class has an "inferior" member used to handle
+ inferior-specific breakpoints. This creates a compilation error
+ in amd_dbgapi_target_breakpoint::check_status which declares a local
+ variable "inferior *inf".
+
+ Fix this by using "struct inferior *inf" instead.
+
+ Change-Id: Icc4dc1ba96c7d3ff9d33f9cb384ffcf64eba26fb
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-08-23 Pedro Alves <pedro@palves.net>
+
+ Fix Windows sharing_input_terminal hang
+ After running a number of programs under Windows gdb and detaching
+ them, I typed run in gdb, and got a hang, here:
+
+ (top-gdb) bt
+ #0 sharing_input_terminal (pid=4672) at /home/pedro/gdb/src/gdb/mingw-hdep.c:388
+ #1 0x00007ff71a2d8678 in sharing_input_terminal (inf=0x23bf23dafb0) at /home/pedro/gdb/src/gdb/inflow.c:269
+ #2 0x00007ff71a2d887b in child_terminal_save_inferior (self=0x23bf23de060) at /home/pedro/gdb/src/gdb/inflow.c:423
+ #3 0x00007ff71a2c80c0 in inf_child_target::terminal_save_inferior (this=0x23bf23de060) at /home/pedro/gdb/src/gdb/inf-child.c:111
+ #4 0x00007ff71a429c0f in target_terminal_is_ours_kind (desired_state=target_terminal_state::is_ours_for_output) at /home/pedro/gdb/src/gdb/target.c:1037
+ #5 0x00007ff71a429e02 in target_terminal::ours_for_output () at /home/pedro/gdb/src/gdb/target.c:1094
+ #6 0x00007ff71a2ccc8e in post_create_inferior (from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:245
+ #7 0x00007ff71a2cd431 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at /home/pedro/gdb/src/gdb/infcmd.c:502
+ #8 0x00007ff71a2cd58b in run_command (args=0x0, from_tty=0) at /home/pedro/gdb/src/gdb/infcmd.c:527
+
+ The problem is that the loop around GetConsoleProcessList looped
+ forever, because there were exactly 10 processes to return.
+ GetConsoleProcessList's documentation says:
+
+ If the buffer is too small to hold all the valid process identifiers,
+ the return value is the required number of array elements. The
+ function will have stored no identifiers in the buffer. In this
+ situation, use the return value to allocate a buffer that is large
+ enough to store the entire list and call the function again.
+
+ In this case, the buffer wasn't too small, it was exactly the right
+ size, so we should have broken out of the loop. We didn't due to a
+ "<" check that should have been "<=". That is fixed by this patch.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Change-Id: I14e4909f2ac2fa83d0d9b6e64418b5831ac4e4e3
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix up a few places where a char was treated as a bool
+ Spotted a few places where a char is being treated as a bool. The GDB
+ style is to use explicit comparisons, so fix things up.
+
+ There should be no user visible changes after this commit.
+
+2023-08-23 Nick Clifton <nickc@redhat.com>
+
+ Correct PR number in previous delta
+
+ readelf/objdump: Handle DWARF info with mixed types of range section.
+ PR 30791
+ * dwarf.h (debug_info): Add range_versions field.
+ * dwarf.c (read_and_display_attr_value): When recording a range arribute also ecord the dwarf version number.
+ (is_range_list_for_this_section): New function.
+ (display_debug_ranges): Only show debug ranges whose version is suitable for the secction being displayed.
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: MI stopped events when unwindonsignal is on
+ This recent commit:
+
+ commit b1c0ab20809a502b2d2224fecb0dca3ada2e9b22
+ Date: Wed Jul 12 21:56:50 2023 +0100
+
+ gdb: avoid double stop after failed breakpoint condition check
+
+ Addressed a problem where two MI stopped events would be reported if a
+ breakpoint condition failed due to a signal, this commit was a
+ replacement for this commit:
+
+ commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
+ Date: Fri Oct 14 14:53:15 2022 +0100
+
+ gdb: don't always print breakpoint location after failed condition check
+
+ which solved the two stop problem, but only for the CLI. Before both
+ of these commits, if a b/p condition failed due to a signal then the
+ user would see two stops reported, the first at the location where the
+ signal occurred, and the second at the location of the breakpoint.
+
+ By default GDB remains at the location where the signal occurred, so
+ the second reported stop can be confusing, this is the problem that
+ commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a
+ extended also address the issue for MI too.
+
+ However, while working on another patch I realised that there was a
+ problem with GDB after the above commits. Neither of the above
+ commits considered 'set unwindonsignal on'. With this setting on,
+ when an inferior function call fails with a signal GDB will unwind the
+ stack back to the location where the inferior function call started.
+ In the b/p case we're looking at, the stop should be reported at the
+ location of the breakpoint, not at the location where the signal
+ occurred, and this isn't what happens.
+
+ This commit fixes this by ensuring that when unwindonsignal is 'on',
+ GDB reports a single stop event at the location of the breakpoint,
+ this fixes things for both CLI and MI.
+
+ The function call_thread_fsm::should_notify_stop is called when the
+ inferior function call completes and GDB is figuring out if the user
+ should be notified about this stop event by calling normal_stop from
+ fetch_inferior_event in infrun.c. If normal_stop is called, then this
+ notification will be for the location where the inferior call stopped,
+ which will be the location at which the signal occurred.
+
+ Prior to this commit, the only time that normal_stop was not called,
+ was if the inferior function call completed successfully, this was
+ controlled by ::should_notify_stop, which only turns false when the
+ inferior function call has completed successfully.
+
+ In this commit I have extended the logic in ::should_notify_stop. Now
+ there are three cases in which ::should_notify_stop will return false,
+ and we will not announce the first stop (by calling normal_stop).
+ These three reasons are:
+
+ 1. If the inferior function call completes successfully, this is
+ unchanged behaviour,
+
+ 2. If the inferior function call stopped due to a signal and 'set
+ unwindonsignal on' is in effect, and
+
+ 3. If the inferior function call stopped due to an uncaught C++
+ exception, and 'set unwind-on-terminating-exception on' is in
+ effect.
+
+ However, if we don't call normal_stop then we need to call
+ async_enable_stdin in call_thread_fsm::should_stop. Prior to this
+ commit this was only done for the case where the inferior function
+ call completed successfully.
+
+ In this commit I now call ::should_notify_stop and use this to
+ determine if we need to call async_enable_stdin. With this done we
+ now call async_enable_stdin for each of the three cases listed above,
+ which means that GDB will exit wait_sync_command_done correctly (see
+ run_inferior_call in infcall.c).
+
+ With these two changes the problem is mostly resolved. However, the
+ solution isn't ideal, we've still lost some information.
+
+ Here is how GDB 13.1 behaves, this is before commits b1c0ab20809a and
+ 2e411b8c68eb:
+
+ $ gdb -q /tmp/mi-condbreak-fail \
+ -ex 'set unwindonsignal on' \
+ -ex 'break 30 if (cond_fail())' \
+ -ex 'run'
+ Reading symbols from /tmp/mi-condbreak-fail...
+ Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
+ Starting program: /tmp/mi-condbreak-fail
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
+ 24 return *p; /* Crash here. */
+ Error in testing breakpoint condition:
+ The program being debugged was signaled while in a function called from GDB.
+ GDB has restored the context to what it was before the call.
+ To change this behavior use "set unwindonsignal off".
+ Evaluation of the expression containing the function
+ (cond_fail) will be abandoned.
+
+ Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
+ 30 global_counter += 1; /* Set breakpoint here. */
+ (gdb)
+
+ In this state we see two stop notifications, the first is where the
+ signal occurred, while the second is where the breakpoint is located.
+ As GDB has unwound the stack (thanks to unwindonsignal) the second
+ stop notification reflects where the inferior is actually located.
+
+ Then after commits b1c0ab20809a and 2e411b8c68eb the behaviour changed
+ to this:
+
+ $ gdb -q /tmp/mi-condbreak-fail \
+ -ex 'set unwindonsignal on' \
+ -ex 'break 30 if (cond_fail())' \
+ -ex 'run'
+ Reading symbols from /tmp/mi-condbreak-fail...
+ Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
+ Starting program: /tmp/mi-condbreak-fail
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
+ 24 return *p; /* Crash here. */
+ Error in testing condition for breakpoint 1:
+ The program being debugged was signaled while in a function called from GDB.
+ GDB has restored the context to what it was before the call.
+ To change this behavior use "set unwindonsignal off".
+ Evaluation of the expression containing the function
+ (cond_fail) will be abandoned.
+ (gdb) bt 1
+ #0 foo () at /tmp/mi-condbreak-fail.c:30
+ (More stack frames follow...)
+ (gdb)
+
+ This is the broken state. GDB is reports the SIGSEGV location, but
+ not the unwound breakpoint location. The final 'bt 1' shows that the
+ inferior is not located in cond_fail, which is the only location GDB
+ reported, so this is clearly wrong.
+
+ After implementing the fixes described above we now get this
+ behaviour:
+
+ $ gdb -q /tmp/mi-condbreak-fail \
+ -ex 'set unwindonsignal on' \
+ -ex 'break 30 if (cond_fail())' \
+ -ex 'run'
+ Reading symbols from /tmp/mi-condbreak-fail...
+ Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
+ Starting program: /tmp/mi-condbreak-fail
+ Error in testing breakpoint condition for breakpoint 1:
+ The program being debugged was signaled while in a function called from GDB.
+ GDB has restored the context to what it was before the call.
+ To change this behavior use "set unwindonsignal off".
+ Evaluation of the expression containing the function
+ (cond_fail) will be abandoned.
+
+ Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
+ 30 global_counter += 1; /* Set breakpoint here. */
+ (gdb)
+
+ This is better. GDB now reports a single stop at the location of the
+ breakpoint, which is where the inferior is actually located. However,
+ by removing the first stop notification we have lost some potentially
+ useful information about which signal caused the inferior to stop.
+
+ To address this I've reworked the message that is printed to include
+ the signal information. GDB now reports this:
+
+ $ gdb -q /tmp/mi-condbreak-fail \
+ -ex 'set unwindonsignal on' \
+ -ex 'break 30 if (cond_fail())' \
+ -ex 'run'
+ Reading symbols from /tmp/mi-condbreak-fail...
+ Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
+ Starting program: /tmp/mi-condbreak-fail
+ Error in testing condition for breakpoint 1:
+ The program being debugged received signal SIGSEGV, Segmentation fault
+ while in a function called from GDB. GDB has restored the context
+ to what it was before the call. To change this behavior use
+ "set unwindonsignal off". Evaluation of the expression containing
+ the function (cond_fail) will be abandoned.
+
+ Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
+ 30 global_counter += 1; /* Set breakpoint here. */
+ (gdb)
+
+ This is better, the user now sees a single stop notification at the
+ correct location, and the error message describes which signal caused
+ the inferior function call to stop.
+
+ However, we have lost the information about where the signal
+ occurred. I did consider trying to include this information in the
+ error message, but, in the end, I opted not too. I wasn't sure it was
+ worth the effort. If the user has selected to unwind on signal, then
+ surely this implies they maybe aren't interested in debugging failed
+ inferior calls, so, hopefully, just knowing the signal name will be
+ enough. I figure we can always add this information in later if
+ there's a demand for it.
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add mi_info_frame helper proc (and use it)
+ New helper proc mi_info_frame which takes care of running the MI
+ -stack-info-frame command and matching its output.
+
+ Like the breakpoint helper procs, this new proc takes a name/value
+ argument list and uses this to build the expected result regexp. This
+ means that we can now write something like:
+
+ mi_info_frame "test name here" \
+ -level 0 -func name -line 123
+
+ Instead of the current equivalent:
+
+ mi_gdb_test "235-stack-info-frame" \
+ "235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"name\",file=\".*\",fullname=\".*\",line=\"123\",arch=\".*\"\}" \
+ "test name here"
+
+ There's also a helper proc mi_make_info_frame_regexp which is
+ responsible for building the 'frame={...}' part of the pattern.
+
+ I've update the two existing tests that use -stack-info-frame and
+ expect the command to succeed. There is another test that runs
+ -stack-info-frame and expects the command to fail -- the helper proc
+ doesn't help with this case, so that test is not changed.
+
+2023-08-23 Pedro Alves <pedro@palves.net>
+
+ gdb: centralize "[Thread ...exited]" notifications
+ Currently, each target backend is responsible for printing "[Thread
+ ...exited]" before deleting a thread. This leads to unnecessary
+ differences between targets, like e.g. with the remote target, we
+ never print such messages, even though we do print "[New Thread ...]".
+
+ E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
+ with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
+ currently see:
+
+ (gdb) c
+ Continuing.
+ ^C[New Thread 3850398.3887449]
+ [New Thread 3850398.3887500]
+ [New Thread 3850398.3887551]
+ [New Thread 3850398.3887602]
+ [New Thread 3850398.3887653]
+ ...
+
+ Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
+ 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
+ at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
+ 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
+ (gdb)
+
+ Above, we only see "New Thread" notifications, even though threads
+ were deleted.
+
+ After this patch, we'll see:
+
+ (gdb) c
+ Continuing.
+ ^C[Thread 3558643.3577053 exited]
+ [Thread 3558643.3577104 exited]
+ [Thread 3558643.3577155 exited]
+ [Thread 3558643.3579603 exited]
+ ...
+ [New Thread 3558643.3597415]
+ [New Thread 3558643.3600015]
+ [New Thread 3558643.3599965]
+ ...
+
+ Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
+ 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
+ at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
+ 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
+ (gdb) q
+
+ This commit fixes this by moving the thread exit printing to common
+ code instead, triggered from within delete_thread (or rather,
+ set_thread_exited).
+
+ There's one wrinkle, though. While most targest want to print:
+
+ [Thread ... exited]
+
+ the Windows target wants to print:
+
+ [Thread ... exited with code <exit_code>]
+
+ ... and sometimes wants to suppress the notification for the main
+ thread. To address that, this commits adds a delete_thread_with_code
+ function, only used by that target (so far).
+
+ This fix was originally posted as part of a larger series:
+
+ https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/
+
+ But didn't really need to be part of that series. In order to get
+ this fix merged sooner, I (Andrew Burgess) have rebased this commit
+ outside of the original series. Any bugs introduced while splitting
+ this patch out and rebasing, are entirely my own.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove the silent parameter from exit_inferior_1 and cleanup
+ After the previous commit, exit_inferior_1 no longer makes use of the
+ silent parameter. This commit removes this parameter and cleans up
+ the callers.
+
+ After doing this exit_inferior_1, exit_inferior, and
+ exit_inferior_silent are all equivalent, so rename exit_inferior_1 to
+ exit_inferior and delete exit_inferior_silent, update all the callers.
+
+ Also I spotted the declaration exit_inferior_num_silent in inferior.h,
+ but this function is not defined anywhere, so I deleted the
+ declaration.
+
+ There should be no user visible changes after this commit.
+
+2023-08-23 Pedro Alves <pedro@palves.net>
+
+ gdb: make inferior::clear_thread_list always silent
+ After this commit:
+
+ commit a78ef8757418105c35685c5d82b9fdf79459321b
+ Date: Wed Jun 22 18:10:00 2022 +0100
+
+ Always emit =thread-exited notifications, even if silent
+
+ The function mi_interp::on_thread_exited (or mi_thread_exit as the
+ function was called back then) no longer makes use of the "silent"
+ parameter.
+
+ As a result there is no difference between inferior::clear_thread_list
+ with silent true or false, because:
+
+ - None of the interpreter ::on_thread_exited functions rely on the
+ silent parameter, and
+
+ - None of GDB's thread_exit observers rely on the silent parameter
+ either.
+
+ This commit removes the silent parameter from
+ inferior::clear_thread_list, and makes the function always silent.
+
+ This commit was originally part of a larger series:
+
+ https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/
+
+ But didn't really need to be part of that series. I had an interest
+ in seeing this patch merged:
+
+ https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-31-pedro@palves.net/
+
+ Which also didn't really need to be part of the larger series, but
+ does depend, at least a little, on this commit. In order to get the
+ fix I'm interested in merged quicker, I (Andrew Burgess) have rebased
+ this commit outside of the original series. Any bugs introduced while
+ splitting this patch out and rebasing, are entirely my own.
+
+ There should be no user visible changes after this commit.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove mi_parse::make functions
+ Remove the static mi_parse::make functions, and instead use the
+ mi_parse constructor.
+
+ This is a partial revert of the commit:
+
+ commit fde3f93adb50c9937cd2e1c93561aea2fd167156
+ Date: Mon Mar 20 10:56:55 2023 -0600
+
+ Introduce "static constructor" for mi_parse
+
+ which introduced the mi_parse::make functions, though after discussion
+ on the list the reasons for seem to have been lost[1]. Given there
+ are no test regressions when moving back to using the constructors, I
+ propose we should do that for now.
+
+ There should be no user visible changes after this commit.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20230404-dap-loaded-sources-v2-5-93f229095e03@adacore.com/
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have mi_out_new return std::unique_ptr
+ Have the mi_out_new function return a std::unique_ptr instead of a raw
+ pointer. Update the two uses of mi_out_new.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add gdb::make_unique function
+ While GDB is still C++11, lets add a gdb::make_unique template
+ function that can be used to create std::unique_ptr objects, just like
+ the C++14 std::make_unique.
+
+ If GDB is being compiled with a C++14 compiler then the new
+ gdb::make_unique function will delegate to the std::make_unique. I
+ checked with gcc, and at -O1 and above gdb::make_unique will be
+ optimised away completely in this case.
+
+ If C++14 (or later) becomes our minimum, then it will be easy enough
+ to go through the code and replace gdb::make_unique with
+ std::make_unique later on.
+
+ I've make use of this function in all the places I think this can
+ easily be used, though I'm sure I've probably missed some.
+
+ Should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: improve MI support for inferior specific breakpoints
+ In this commit:
+
+ commit b080fe54fb3414b488b8ef323c6c50def061f918
+ Date: Tue Nov 8 12:32:51 2022 +0000
+
+ gdb: add inferior-specific breakpoints
+
+ limited support was added in lib/mi-support.exp to help with testing
+ of inferior specific breakpoints.
+
+ Though the changes that were added were not wrong, while working on a
+ later patch, I realised that I had added the support in the wrong
+ place -- I only added support to mi_make_breakpoint_multi, when really
+ I should have added the support to mi_make_breakpoint_1, which is used
+ by all of the MI procs that create breakpoints.
+
+ This commit moves the support to mi_make_breakpoint_1, and updates all
+ the procs that use mi_make_breakpoint_1 to accept, and then pass
+ through, and (optional) inferior argument. This will make it much
+ easier to write MI tests for inferior specific breakpoints.
+
+ There's no change in what is tested after this commit.
+
+2023-08-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add missing notify_breakpoint_modified call
+ The commit:
+
+ commit b080fe54fb3414b488b8ef323c6c50def061f918
+ Date: Tue Nov 8 12:32:51 2022 +0000
+
+ gdb: add inferior-specific breakpoints
+
+ introduced a bug in the function breakpoint_set_inferior. The above
+ commit includes this line:
+
+ gdb::observers::breakpoint_modified.notify (b);
+
+ when it should have instead used this line:
+
+ notify_breakpoint_modified (b);
+
+ The change to use notify_breakpoint_modified was introduced to GDB
+ after commit b080fe54fb34 was written, but before it was merged, and I
+ failed to update this part of the code during the rebase.
+
+ The consequence of this error is that the MI interpreter will not emit
+ breakpoint-modified notifications when breakpoint_set_inferior is
+ called.
+
+ In this commit I update the code to call notify_breakpoint_modified,
+ and add a test that checks the MI events are being emitted correctly
+ in this case.
+
+2023-08-23 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: fix 32-bit build
+ bfd/
+ * Makefile.am: Move elf32-kvx.lo from BFD32_BACKENDS to
+ BFD64_BACKENDS. Remove elfxx-kvx.lo from BFD32_BACKENDS.
+ Remove elfxx-kvx.c from BFD32_BACKENDS_CFILES.
+ * Makefile.in: Regenerate.
+ * config.bfd: Adjust targ_defvec and targ_selvecs and gate them
+ behind BFD64.
+ * configure.ac: Add target_size=64 to kvx_elf64_*vec.
+ * configure: Regenerate.
+ * elfnn-kvx.c (elfNN_kvx_stub_name): Cast rel->r_addend to
+ uint64_t to match format string.
+ (elfNN_kvx_relocate_section): Similarly for r_offset, and
+ use PRIx64 in format string.
+ * targets.c (_bfd_target_vector <kvx_elf32_vec>): Move inside
+ #ifdef BFD64.
+ ld/
+ * Makefile.am: Move eelf32kvx.c from ALL_EMULATION_SOURCES to
+ ALL_64_EMULATION_SOURCES.
+ * Makefile.in: Regenerate.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ kvx: O_pseudo_fixup
+ O_pseudo_fixup was defined as O_max+1, missing the fact that O_md1
+ through O_md32 enums are for use by target code. Worse, kvx-parse.c
+ used 64 rather than O_pseudo_fixup. Fix this, and wrap some overlong
+ lines.
+
+ * config/tc-kvx.h (O_pseudo_fixup): Define.
+ * config/tc-kvx.c (O_pseudo_fixup): Don't define here.
+ (insert_operand): Delete bogus comment and cast.
+ * config/kvx-parse.c (promote_token): Use O_pseudo_fixup
+ rather than hardcoded value. Wrap overlong lines.
+ (get_token_class): Likewise.
+ (parse_with_restarts): Wrap overlong line.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ kvx: ubsan: integer overflow
+ This fixes a few places where ubsan complains about signed integer
+ overflow when running the testsuite, and that clz(0) is undefined.
+ When fixing the clz problem, I also noticed that we'd get complaints
+ if pval is ever LLONG_MIN. Fix that by using unsigned arithmetic.
+
+ * config/kvx-parse.c (get_token_class): Avoid signed overflow.
+ Don't clz(0).
+ * config/tc-kvx.c (PARALLEL_BIT): Avoid signed overflow.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ kvx: asan: out-of-bounds read
+ kvx-parse.c:parse_with_restarts does
+ if (!tok.insn[tok.begin])
+ tok.class_id = -3;
+ then a little later
+ printf_debug (1, "\nEntering rule: %d (Trying to match: (%s)[%d])\n", jump_target,
+ TOKEN_NAME (CLASS_ID (tok)), CLASS_ID (tok));
+
+ This results in a buffer overrun in TOKEN_NAME. Fix that.
+
+ * config/tc-kvx.h (TOKEN_NAME): Check for tok <= 0, not just -1.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ kvx bfd signed calculations and _bfd_kvx_elf_resolve_relocation
+ It is generally a good idea to avoid signed arithmetic on values
+ extracted from object files, to avoid ubsan warnings on overflow.
+ This patch replaces some uses of bfd_signed_vma in the kvx backend
+ with bfd_vma, and removes _bfd_kvx_elf_resolve_relocation, a
+ do-nothing function. In the process of making this patch I noticed
+ some dead code in the GOT entry handling, setting value to
+ got_entry_addr but using "off" in the _bfd_final_link_relocate call.
+ Since kvx_calculate_got_entry_vma also returns the GOT offset, I
+ presume the code is correct, but I've left the dead code and comment
+ there.
+
+ * elfxx-kvx.h (_bfd_kvx_elf_resolve_relocation): Delete.
+ * elfxx-kvx.c (kvx_signed_overflow): Rewrite using unsigned
+ arithmetic.
+ (_bfd_kvx_elf_resolve_relocation): Delete.
+ * elfnn-kvx.c (kvx_relocate): Update for
+ _bfd_kvx_elf_resolve_relocation removal.
+ (elfNN_kvx_final_link_relocate): Likewise. Don't use a signed
+ addend.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ bfd kvx formatting fixes
+ Indentation, whitespace and comment fixes.
+
+ * elfnn-kvx.c: Formatting.
+ * elfxx-kvx.c: Formatting.
+ (elfNN_kvx_final_link_relocate): Correct GOT entry comment.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ gdb: bfd_get_symbol_leading_char vs. ""
+ Some places matching the first char of a string against
+ bfd_get_symbol_leading_char, which may be zero, didn't check for "".
+ This could lead to accesses past the end of the string and potential
+ buffer overruns. Fix that, and also get rid of a stupid optimisation
+ in dbxread when looking for "__DYNAMIC" that also might access past
+ the end of a string.
+
+2023-08-23 Alan Modra <amodra@gmail.com>
+
+ bfd_get_symbol_leading_char vs. ""
+ Some places matching the first char of a string against
+ bfd_get_symbol_leading_char, which may be zero, didn't check for the
+ string being "". This patch adds the check to stop accesses past the
+ end of the string and potential buffer overruns.
+ The dlltool one was found by oss-fuzz quite a while ago.
+
+ bfd/
+ * cofflink.c (_bfd_coff_link_input_bfd): Ensure a zero
+ bfd_get_symbol_leading_char doesn't lead to accessing past the
+ zero string terminator.
+ * linker.c (bfd_wrapped_link_hash_lookup): Likewise.
+ (unwrap_hash_lookup): Likewise.
+ binutils/
+ * dlltool.c (scan_filtered_symbols): Ensure a zero
+ bfd_get_symbol_leading_char doesn't lead to accessing past the
+ zero string terminator.
+
+2023-08-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Work around cgen odr violations
+ When building gdb with -flto -O2, I run into:
+ ...
+ opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
+ C++ One Definition Rule [-Wodr]
+ typedef enum cgen_operand_type {
+ ^
+ opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
+ defined in another translation unit
+ typedef enum cgen_operand_type {
+ ^
+ opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
+ Definition Rule [-Wodr]
+ typedef enum cgen_hw_type {
+ ^
+ opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
+ defined in another translation unit
+ typedef enum cgen_hw_type {
+ ^
+ ...
+
+ Fix this by making the conflicting type names unique, adding a target-specific
+ prefix using a define before the include:
+ ...
+ #define cgen_operand_type <target-name>_cgen_operand_type
+ #define cgen_hw_type <target-name>_cgen_hw_type
+ #include "opcodes/<target-name>-desc.h"
+ ...
+ and move those defines into a new file cgen-remap.h, similar to how that's
+ done for yacc in yy-remap.h.
+
+ Likewise for targets frv and lm32, the two other targets that include
+ opcodes/<target-name>-desc.h.
+
+ Likewise for more cgen symbols that I got the same warning for when using
+ -flto-partition=one.
+
+ A PR has been filed to take care of this in the opcodes dir instead (PR30758).
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/30757
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30757
+
+2023-08-22 Tom Tromey <tromey@adacore.com>
+
+ Remove value::copy call from gdbpy_get_varobj_pretty_printer
+ I noticed a call to value::copy in gdbpy_get_varobj_pretty_printer,
+ and I couldn't figure out why it was there. I think maybe it came
+ from the time when value_to_value_object would release values from the
+ value chain -- but that was removed in commit f3d3bbbc.
+
+ This patch removes this call. Regression tested on x86-64 Fedora 36.
+
+2023-08-22 Victor Do Nascimento <Victor.DoNascimento@arm.com>
+
+ aarch64: Improve naming conventions for A and R-profile architecture
+ Historically, flags and variables relating to architectural revisions
+ for the A-profile architecture omitted the trailing `A' such that, for
+ example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
+ flag in the assembler.
+
+ This leads to some ambiguity, since Binutils also targets the
+ R-profile Arm architecture. Therefore, it seems prudent to have
+ everything associated with the A-profile cores end in `A' and likewise
+ `R' for the R-profile. Referring back to the example above, the flag
+ set for `-march=armv8.4-a' is better characterized if labeled
+ `AARCH64_ARCH_V8_4A'.
+
+ The only exception to the rule of appending `A' to variables is found
+ in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
+ baseline from which ALL processors derive and should therefore be left
+ unchanged.
+
+ In reflecting the `ARM' architectural nomenclature choices, where we
+ have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
+ an underscore separating the numerical revision number and the
+ A/R-profile indicator suffix. This has meant that renaming of
+ R-profile related flags and variables was warranted, thus going from
+ `.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.
+
+ Finally, this is more in line with conventions within GCC and adds consistency
+ across the toolchain.
+
+ gas/ChangeLog:
+ * gas/config/tc-aarch64.c:
+ (aarch64_cpus): Reference to arch feature macros updated.
+ (aarch64_archs): Likewise.
+
+ include/ChangeLog:
+ * include/opcode/aarch64.h:
+ (AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A.
+ (AARCH64_FEATURE_V8_1A): A-suffix added.
+ (AARCH64_FEATURE_V8_2A): Likewise.
+ (AARCH64_FEATURE_V8_3A): Likewise.
+ (AARCH64_FEATURE_V8_4A): Likewise.
+ (AARCH64_FEATURE_V8_5A): Likewise.
+ (AARCH64_FEATURE_V8_6A): Likewise.
+ (AARCH64_FEATURE_V8_7A): Likewise.
+ (AARCH64_FEATURE_V8_8A):Likewise.
+ (AARCH64_FEATURE_V9A): Likewise.
+ (AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R.
+ (AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A.
+ (AARCH64_ARCH_V8_1A_FEATURES): A-suffix added.
+ (AARCH64_ARCH_V8_2A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_3A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_4A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_5A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_6A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_7A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8_8A_FEATURES): Likewise.
+ (AARCH64_ARCH_V9A_FEATURES): Likewise.
+ (AARCH64_ARCH_V9_1A_FEATURES): Likewise.
+ (AARCH64_ARCH_V9_2A_FEATURES): Likewise.
+ (AARCH64_ARCH_V9_3A_FEATURES): Likewise.
+ (AARCH64_ARCH_V8A): Updated name: V8_A -> V8A.
+ (AARCH64_ARCH_V8_1A): A-suffix added.
+ (AARCH64_ARCH_V8_2A): Likewise.
+ (AARCH64_ARCH_V8_3A): Likewise.
+ (AARCH64_ARCH_V8_4A): Likewise.
+ (AARCH64_ARCH_V8_5A): Likewise.
+ (AARCH64_ARCH_V8_6A): Likewise.
+ (AARCH64_ARCH_V8_7A): Likewise.
+ (AARCH64_ARCH_V8_8A): Likewise.
+ (AARCH64_ARCH_V9A): Likewise.
+ (AARCH64_ARCH_V9_1A): Likewise.
+ (AARCH64_ARCH_V9_2A): Likewise.
+ (AARCH64_ARCH_V9_3A): Likewise.
+ (AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R.
+
+ opcodes/ChangeLog:
+ * opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A.
+ (SR_V8_1A): A-suffix added.
+ (SR_V8_2A): Likewise.
+ (SR_V8_3A): Likewise.
+ (SR_V8_4A): Likewise.
+ (SR_V8_6A): Likewise.
+ (SR_V8_7A): Likewise.
+ (SR_V8_8A): Likewise.
+ (aarch64_sys_regs): Reference to arch feature macros updated.
+ (aarch64_pstatefields): Reference to arch feature macros updated.
+ (aarch64_sys_ins_reg_supported_p): Reference to arch feature macros
+ updated.
+ * opcodes/aarch64-tbl.h:
+ (aarch64_feature_v8_2a): a-suffix added.
+ (aarch64_feature_v8_3a): Likewise.
+ (aarch64_feature_fp_v8_3a): Likewise.
+ (aarch64_feature_v8_4a): Likewise.
+ (aarch64_feature_fp_16_v8_2a): Likewise.
+ (aarch64_feature_v8_5a): Likewise.
+ (aarch64_feature_v8_6a): Likewise.
+ (aarch64_feature_v8_7a): Likewise.
+ (aarch64_feature_v8r): Updated name: v8_r-> v8r.
+ (ARMV8R): Updated name: V8_R-> V8R.
+ (ARMV8_2A): A-suffix added.
+ (ARMV8_3A): Likewise.
+ (FP_V8_3A): Likewise.
+ (ARMV8_4A): Likewise.
+ (FP_F16_V8_2A): Likewise.
+ (ARMV8_5): Likewise.
+ (ARMV8_6A): Likewise.
+ (ARMV8_6A_SVE): Likewise.
+ (ARMV8_7A): Likewise.
+ (V8_2A_INSN): `A' added to macro symbol.
+ (V8_3A_INSN): Likewise.
+ (V8_4A_INSN): Likewise.
+ (FP16_V8_2A_INSN): Likewise.
+ (V8_5A_INSN): Likewise.
+ (V8_6A_INSN): Likewise.
+ (V8_7A_INSN): Likewise.
+ (V8R_INSN): Updated name: V8_R-> V8R.
+
+2023-08-22 Alan Modra <amodra@gmail.com>
+
+ objdump: file name table entry count check
+ Fuzzers have found that objdump -W takes a really long time if
+ the entry count uleb is ridiculously large, and format attributes
+ don't consume data (which doesn't make sense for a table of names).
+
+ * dwarf.c (display_formatted_table): Sanity check count of
+ table entries.
+
+2023-08-22 Alan Modra <amodra@gmail.com>
+
+ kvx_dis_init
+ kvx_dis_init currently always returns true, but error conditions do so
+ by "return -1" which converts to true. The return status is ignored
+ anyway, and it doesn't make much sense to error on unexpected arch or
+ mach: If print_insn_kvx is called then the atch is known to be kvx,
+ and it's better to choose some default for a user passing an unknown
+ mach value rather than segfaulting in decode_insn when env.opc_table
+ is NULL.
+
+ I've chosen the default mach to be bfd_mach_kv3_1, the default in
+ bfd/cpu-kvx.c, not that it matters very much. In normal objdump/gdb
+ usage, info->mach won't be an unexpected value.
+
+ * kvx-dis.c (kvx_dis_init): Return void. Don't error on
+ unexpected arch or mach. Default to bfd_mach_kv3_1 for
+ unknown mach. Don't clear info->disassembler_options.
+
+2023-08-22 Alan Modra <amodra@gmail.com>
+
+ kvx-linux config
+ A misplaced line, resulting in testsuite errors when attempting to use
+ as -m32.
+
+ * config.bfd (kvx-*-linux*): Add targ_selvecs.
+ (kvx-*-*): Remove targ_selvecs.
+
+2023-08-22 Alan Modra <amodra@gmail.com>
+
+ Re: kvx: New port.
+ Add files submitted on the mailing list but somehow not committed.
+
+2023-08-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-21 David Faust <david.faust@oracle.com>
+
+ sim: bpf: remove negi, neg32i insns
+ The BPF virtual machine does not support neg instructions operating on
+ immediates, and these erroneous instructions were recently removed from
+ gas. Remove them from the simulator as well.
+
+2023-08-21 David Faust <david.faust@oracle.com>
+
+ bpf: correct neg and neg32 instruction encoding
+ The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
+ source bit, despite operating on registers. If BPF_SRC_X (=1) is set,
+ the instructions are rejected by the kernel.
+
+ Because of this there are also no neg/neg32 instructions which operate
+ on immediates, so remove them.
+
+ bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old
+ CGEN-based port, but was not carried forward in the new port.
+
+ include/
+ * opcode/bpf.h (enum bpf_insn_id): Remove spurious entries
+ BPF_INSN_NEGI and BPF_INSN_NEG32I.
+
+ opcodes/
+ * bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I
+ instructions.
+
+ gas/
+ * doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and
+ neg32 instructions operating on immediates.
+ * testsuite/gas/bpf/alu.s: Adapt accordingly.
+ * testsuite/gas/bpf/alu.d: Likewise.
+ * testsuite/gas/bpf/alu-be.d: Likewise
+ * testsuite/gas/bpf/alu32.s: Likewise.
+ * testsuite/gas/bpf/alu32.d: Likewise.
+ * testsuite/gas/bpf/alu32-be.d: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
+
+2023-08-21 Luis Machado <luis.machado@arm.com>
+
+ aarch64/sme2: Teach binutils/BFD about the NT_ARM_ZT register set
+ The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that
+ the Linux Kernel handles through a new NT_ARM_ZT register set.
+
+ Teach binutils/BFD about it so that gdb can make use of it for reading
+ and writing core files. This also enables readelf/objdump to show the
+ correct identification for the NT_ARM_ZT register set.
+
+ Validated under Fast Models.
+
+2023-08-21 Ezra Sitorus <ezra.sitorus@arm.com>
+
+ aarch64/sme: Core file support
+ Add required code to support core file dumps with NT_ARM_ZA and NT_ARM_SSVE
+ register sets in them.
+
+ These new register sets are dumped when SME is supported.
+
+2023-08-21 Alan Modra <amodra@gmail.com>
+
+ bfd_close_all_done bug and bfd_last_cache
+ bfd_close ought to always call iovec->bclose so that cache_bclose is
+ called. If not, bfd_last_cache will be left pointing at freed memory.
+ This bug was found by oss-fuzz with the trigger being an old bug in
+ the ia64-vms support. Given a file of the "wrong" size,
+ elf64_vms_close_and_cleanup attempted to extend it, leading to an
+ error since the file was opened read-only by nm. nm bad_file bad_file
+ then hit the use-after-free when opening the second file.
+
+ commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and
+ bfd_close_all_done, but didn't go quite far enough.
+
+ * elf64-ia64-vms.c (elf64_vms_close_and_cleanup): Don't
+ attempt to extend read-only files.
+ * opncls.c (bfd_close_all_done): Always call _close_and_cleanup.
+
+ An old bug in the ia64-vms support can be used to tickle another bug
+ in bfd_close_all_done. If _close_and_cleanup returns an error,
+
+2023-08-21 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Fix make check-gas crash
+
+2023-08-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-19 Tom Tromey <tom@tromey.com>
+
+ Placate -Wmissing-declarations in sim/cris
+ I get a couple of -Wmissing-declarations errors when building the sim.
+ This happens because an earlier patch added the declarations to a
+ cgen-generated header, but the recent re-generation then removed them.
+
+ This patch fixes the build by adding declarations just before the
+ definition. This is normally not best practice, but in this
+ particular situation it at leat un-breaks the build.
+
+2023-08-19 Tom Tromey <tom@tromey.com>
+
+ Remove extraneous '%' from sim/cris/local.mk
+ I saw this warning from make:
+
+ Makefile:5043: *** mixed implicit and normal rules: deprecated syntax
+
+ I believe this snuck in by error with the recent cgen-related changes.
+
+ This patch removes the stray '%' and rebuilds the Makefile.in. I'm
+ checking this in.
+
+2023-08-19 Alan Modra <amodra@gmail.com>
+
+ sim regen
+ This regenerates sim files.
+
+ Tested with the following tools from a recent binutils build in
+ sim-site-config.exp, plus a few cross compilers.
+
+ set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc"
+ set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new"
+ set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new"
+ set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc"
+ set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new"
+ set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new"
+ set CC_FOR_TARGET_AVR ""
+ set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new"
+ set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new"
+ set CC_FOR_TARGET_BFIN ""
+ set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new"
+ set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new"
+ set CC_FOR_TARGET_BPF ""
+ set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new"
+ set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new"
+ set CC_FOR_TARGET_CR16 ""
+ set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new"
+ set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new"
+ set CC_FOR_TARGET_CRIS ""
+ set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new"
+ set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new"
+ set CC_FOR_TARGET_D10V ""
+ set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new"
+ set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new"
+ set CC_FOR_TARGET_FRV ""
+ set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new"
+ set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new"
+ set CC_FOR_TARGET_FT32 ""
+ set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new"
+ set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new"
+ set CC_FOR_TARGET_H8300 ""
+ set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new"
+ set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new"
+ set CC_FOR_TARGET_IQ2000 ""
+ set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_LM32 ""
+ set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new"
+ set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new"
+ set CC_FOR_TARGET_M32C ""
+ set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new"
+ set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new"
+ set CC_FOR_TARGET_M32R ""
+ set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new"
+ set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new"
+ set CC_FOR_TARGET_M68HC11 ""
+ set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new"
+ set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new"
+ set CC_FOR_TARGET_MCORE ""
+ set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc"
+ set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc"
+ set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new"
+ set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new"
+ set CC_FOR_TARGET_MN10300 ""
+ set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new"
+ set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new"
+ set CC_FOR_TARGET_MOXIE ""
+ set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new"
+ set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new"
+ set CC_FOR_TARGET_MSP430 ""
+ set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_OR1K ""
+ set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new"
+ set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new"
+ set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc"
+ set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new"
+ set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new"
+ set CC_FOR_TARGET_PRU ""
+ set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new"
+ set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new"
+ set CC_FOR_TARGET_RISCV ""
+ set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new"
+ set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new"
+ set CC_FOR_TARGET_RL78 ""
+ set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new"
+ set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new"
+ set CC_FOR_TARGET_RX ""
+ set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new"
+ set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new"
+ set CC_FOR_TARGET_SH ""
+ set AS_FOR_TARGET_ERC32 ""
+ set LD_FOR_TARGET_ERC32 ""
+ set CC_FOR_TARGET_ERC32 ""
+ set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new"
+ set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new"
+ set CC_FOR_TARGET_V850 ""
+
+ Results both before and after were:
+ FAIL: crisv10 mem1.ms (execution)
+ FAIL: crisv10 mem2.ms (execution)
+ FAIL: crisv32 mem1.ms (execution)
+ FAIL: crisv32 mem2.ms (execution)
+ FAIL: microblaze fail.s (execution)
+ FAIL: microblaze pass.s (execution)
+ expected passes 5288
+ unexpected failures 6
+ expected failures 3
+ untested testcases 373
+ unsupported tests 14
+
+2023-08-19 Alan Modra <amodra@gmail.com>
+
+ sim regen preparation
+ Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
+ generated file, so this patch move those declarations to
+ sim/lm32/sim-main.h.
+
+2023-08-19 Alan Modra <amodra@gmail.com>
+
+ sim --enable-cgen-maint
+ I had reason yesterday to want to regenerate configury files which I
+ do with --enable-maintainer-mode, and added --enable-cgen-maint
+ accidentally. The first problem I hit is that sim looks for cgen in a
+ different directory by default than opcodes, and I had my source
+ layout set up for opcodes rather than sim. Fix that by making both
+ use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The
+ next problem was that various sim local.mk files expected generated
+ sources in the build dir rather than the source dir. Fix that by
+ adding $(srcdir) to paths. Finally, the generated iq2000 files had a
+ compile error, fixed by the cpu/iq2000.cpu patch.
+
+ cpu/
+ * iq2000.cpu (syscall): Add pc arg.
+ opcodes/
+ * configure.ac (cgendir): Default to ../../cgen, but use ../cgen
+ if found there.
+ * configure: Regenerate.
+ sim/m4/
+ * sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
+ sim/
+ * cris/local.mk: Add $(srcdir) to paths for regenerated source.
+ * frv/local.mk: Likewise.
+ * iq2000/local.mk: Likewise.
+ * lm32/local.mk: Likewise.
+ * m32r/local.mk: Likewise.
+ * or1k/local.mk: Likewise.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+2023-08-19 Alan Modra <amodra@gmail.com>
+
+ sim prune_warnings
+ Remove some of the warnings generated by newer versions of ld.
+
+ * testsuite/lib/sim-defs.exp (prune_warnings_extra): New.
+ Arrange to run it from prune_warnings.
+
+2023-08-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-18 Tom Tromey <tromey@adacore.com>
+
+ Fix off-by-one in call to vector::reserve
+ While looking at a bug, I noticed what I think is an off-by-one
+ mistake in a call to vector::reserve. This code:
+
+ new_args.reserve (args.size ());
+ new_args.push_back
+ (value_from_pointer (lookup_pointer_type (values_type), struct_addr));
+ new_args.insert (new_args.end (), args.begin (), args.end ());
+
+ ... reserves 'size()' entries, but then proceeds to push one extra
+ one.
+
+ This shouldn't have any really bad effects, as insert will grow the
+ vector. Still, it seems better to use the correct size if we're going
+ to bother calling reserve.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-18 Tom Tromey <tromey@adacore.com>
+
+ Merge psympriv.h into psymtab.h
+ psympriv.h was intended for use by code that created partial symbols.
+ Now that no generic code needs psymtab.h any more, psympriv.h can be
+ merged into psymtab.h.
+
+ Remove most includes of psymtab.h
+ I found that most spots including psymtab.h do not need it. This
+ patch removes these includes, and also one unnecessary include of
+ psympriv.h.
+
+2023-08-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: remove indirection from bx[] and di_si[]
+ The longest register name is 3 characters (plus a nul one), so using a
+ 4- or 8-byte pointer to get at it is neither space nor time efficient.
+ Embed the names right into the array. For PIE this also slightly reduces
+ the number of base relocations in the final image.
+
+ gas: make S_IS_LOCAL() and S_IS_EXTERNAL() exclusive of one another
+ While they aren't opposites of each other, there also shouldn't be any
+ symbol for which both return true; both may return false. Therefore
+ use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check
+ which so far both did alike.
+
+2023-08-18 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Report "c or zca" for INSN_CLASS_C when error reporting.
+ bfd/
+ * elfxx-riscv.c (riscv_multi_subset_supports_ext): Return "c or zca"
+ rather than "c".
+
+2023-08-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-18 Tom Tromey <tom@tromey.com>
+
+ C++-ify minidebug.c
+ I noticed minidebug.c was still using explicit malloc and free, where
+ a vector would be more automatic.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Use execvp instead of execv
+ gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui)
+ can be installed in a different directory.
+ In this case, $PATH is used to look up gp-display-text.
+ execv() does not use $PATH to find the executable.
+
+ gprofng/ChangeLog
+ 2023-08-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/gp-display-text.cc (reexec): Use execvp instead of execv.
+
+2023-08-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add inferior-specific breakpoints
+ This commit extends the breakpoint mechanism to allow for inferior
+ specific breakpoints (but not watchpoints in this commit).
+
+ As GDB gains better support for multiple connections, and so for
+ running multiple (possibly unrelated) inferiors, then it is not hard
+ to imagine that a user might wish to create breakpoints that apply to
+ any thread in a single inferior. To achieve this currently, the user
+ would need to create a condition possibly making use of the $_inferior
+ convenience variable, which, though functional, isn't the most user
+ friendly.
+
+ This commit adds a new 'inferior' keyword that allows for the creation
+ of inferior specific breakpoints.
+
+ Inferior specific breakpoints are automatically deleted when the
+ associated inferior is removed from GDB, this is similar to how
+ thread-specific breakpoints are deleted when the associated thread is
+ deleted.
+
+ Watchpoints are already per-program-space, which in most cases mean
+ watchpoints are already inferior specific. There is a small window
+ where inferior-specific watchpoints might make sense, which is after a
+ vfork, when two processes are sharing the same address space.
+ However, I'm leaving that as an exercise for another day. For now,
+ attempting to use the inferior keyword with a watchpoint will give an
+ error, like this:
+
+ (gdb) watch a8 inferior 1
+ Cannot use 'inferior' keyword with watchpoints
+
+ A final note on the implementation: currently, inferior specific
+ breakpoints, like thread-specific breakpoints, are inserted into every
+ inferior, GDB then checks once the inferior stops if we are in the
+ correct thread or inferior, and resumes automatically if we stopped in
+ the wrong thread/inferior.
+
+ An obvious optimisation here is to only insert breakpoint locations
+ into the specific program space (which mostly means inferior) that
+ contains either the inferior or thread we are interested in. This
+ would reduce the number times GDB has to stop and then resume again in
+ a multi-inferior setup.
+
+ I have a series on the mailing list[1] that implements this
+ optimisation for thread-specific breakpoints. Once this series has
+ landed I'll update that series to also handle inferior specific
+ breakpoints in the same way. For now, inferior specific breakpoints
+ are just slightly less optimal, but this is no different to
+ thread-specific breakpoints in a multi-inferior debug session, so I
+ don't see this as a huge problem.
+
+ [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix yysymbol_kind_t odr violation
+ When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
+ run into:
+ ...
+ ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
+ Definition Rule [-Wodr]
+ c-exp.c.tmp:398: note: an enum with different value name is defined in \
+ another translation unit
+ ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
+ 'YYSYMBOL_COMPLEX_INT' defined in another translation unit
+ c-exp.c.tmp:405: note: mismatching definition
+ ...
+
+ Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
+ files.
+
+ Tested on x86_64-linux.
+
+ PR build/22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2023-08-17 Alan Modra <amodra@gmail.com>
+
+ generated bfd files, and kvx regen
+ The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are
+ different to the other similar generated files, and that reminded me
+ that we need to have $srcdir in the generated #line reference back to
+ the source for debugging, but don't want it for comments in bfd.pot
+ (because then bfd.pot will likely reference Nick's source tree).
+ This patch fixes that by making all the #line use $srcdir by virtue of
+ using $<, and edits bfd.pot.
+
+ I also uniq list of files to remove duplicated elfxx-x86.c, sort lists
+ of files and regen with our standard automake/autoconf.
+
+ * configure: Regenerate.
+ bfd/
+ * Makefile.am: Sort various lists of files. Use $< in #line
+ directive of generated C files.
+ (po/SRC-POTFILES.in): uniq SRC_POTFILES.
+ (po/BLD-POTFILES.in): uniq BFD_POTFILES.
+ * Makefile.in: Regenerate.
+ * po/Make-in (bfd.pot): Edit out source dir from comments.
+ * po/SRC-POTFILES.in: Regenerate.
+ gas/
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * po/POTFILES.in: Regenerate.
+ ld/
+ * Makefile.am (ALL_64_EMULATION_SOURCES): Sort.
+ * Makefile.in: Regenerate.
+
+2023-08-17 Alan Modra <amodra@gmail.com>
+
+ Re: sim frv: Add a missing return value for frvbf_check_acc_range.
+ Commit f00b50d057 went the wrong way. As the comment says this
+ function is only applicable to fr550. If not fr550 return 1,
+ meaning we don't have acc restrictions.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Handle deprecated std::allocator::construct
+ When building gdb with -std=c++20, I run into:
+ ...
+ gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \
+ declared in ‘class std::allocator<unsigned char>’
+ 52 | using A::construct;
+ | ^~~~~~~~~
+ ...
+
+ Indeed, std::allocator::construct has been deprecated in c++17 and removed in
+ c++20.
+
+ Fix this by using instead std::pmr::polymorphic_allocator for c++20.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Return const reference in target_read_auxv
+ In target_read_auxv we return a copy of an object:
+ ...
+ gdb::optional<gdb::byte_vector>
+ target_read_auxv ()
+ {
+ ...
+ return info->data;
+ }
+ ...
+
+ Return a const reference instead, saving a copy.
+
+ This is exposed by using std::pmr::polymorphic_allocator instead of
+ std::allocator in default_init_allocator.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Fix invalid conversion in test_symbols
+ When building gdb with -std=c++20, I run into:
+ ...
+ gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \
+ ‘const char*’ [-fpermissive]
+ 2709 | u8"u8função",
+ | ^~~~~~~~~~~~
+ | |
+ | const char8_t*
+ ...
+
+ Fix this by making the conversion explicit.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Fix deprecated implicit capture of this
+ When building gdb with -std=c++20 I run into:
+ ...
+ gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \
+ deprecated in C++20 [-Werror=deprecated]
+ 10713 | auto do_op = [=] (LONGEST x, LONGEST y)
+ | ^
+ gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture
+ ...
+
+ Fix this by using "[this]".
+
+ Likewise in two more spots.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Fix DISABLE_COPY_AND_ASSIGN use in ui_out_emit_type
+ When building gdb with -std=c++20, I run into:
+ ...
+ include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’
+ 342 | TYPE (const TYPE&) = delete; \
+ | ^~~~~
+ gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
+ 412 | DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>);
+ | ^~~~~~~~~~~~~~~~~~~~~~~
+ ...
+
+ Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)".
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Stop using deprecated is_pod
+ When building gdb with clang 15 and -std=c++20, I run into:
+ ...
+ gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \
+ is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations]
+ std::is_pod<T>>
+ ^
+ ...
+
+ Fix this by following the suggestion.
+
+ Likewise in gdb/unittests/ptid-selftests.c.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build, c++20] Fix Wdeprecated-enum-enum-conversion
+ When building gdb with clang 15 and -std=c++20, I run into:
+ ...
+ gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \
+ enumeration types ('const enum return_reason' and 'const enum errors') is \
+ deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
+ size_t result = exc.reason + exc.error;
+ ~~~~~~~~~~ ^ ~~~~~~~~~
+ ...
+
+ Fix this by using to_underlying.
+
+ Likewise in a few other places.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix copy-to-remote in gdb.base/vfork-follow-parent.exp
+ When running test-case gdb.base/vfork-follow-parent.exp, I run into:
+ ...
+ ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
+ ERROR: error copying "vforked-prog": 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 $binfile3"
+ ...
+
+ Fix this by:
+ - making the copy-to-remote conditional on is_remote target, and
+ - allowing gdb_remote_download to find $binfile3 by using
+ standard_output_file.
+
+ Also remove unused variable remote_exec_prog.
+
+ Tested on x86_64-linux.
+
+2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: tc-sparc.c: undo spurious change in 5be1b787276d2adbe85ae7febc709ca517b62f08
+
+2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas: consolidate handling of immediate overflows
+ This commit changes the BPF GAS port in order to handle immediate
+ overflows the same way than the clang BPF assembler:
+
+ - For an immediate field of N bits, any written number (positive or
+ negative) whose two's complement encoding fit in N its is accepted.
+ This means that -2 is the same than 0xffffffe. It is up to the
+ instructions to decide how to interpret the encoded value.
+
+ - Immediate fields in jump instructions are no longer relaxed.
+ Relaxing to jump instructions with wider range is only performed
+ when expressions are involved.
+
+ - The manual is updated to document this, and testsuite adapted
+ accordingly.
+
+ Tested in x86_64-linux-gnu host, bpf-unknown-none target.
+
+ gas/ChangeLog:
+
+ 2023-08-17 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-bpf.c (check_immediate_overflow): New function.
+ (encode_insn): Use check_immediate_overflow.
+ (md_assemble): Do not relax instructions with
+ constant disp16 fields.
+ * doc/c-bpf.texi (BPF Instructions): Add note about how numerical
+ literal values are interpreted for instruction immediate operands.
+ * testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly.
+ * testsuite/gas/bpf/jump-relax-jump.s: Likewise.
+ * testsuite/gas/bpf/jump-relax-jump.d: Likewise.
+ * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
+ * testsuite/gas/bpf/jump-relax-ja.s: Likewise.
+ * testsuite/gas/bpf/jump-relax-ja.d: Likewise.
+ * testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
+ * testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp16-overflow.l: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.l: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.l: Likewise.
+ * testsuite/gas/bpf/offset16-overflow.l: Likewise.
+
+2023-08-17 Sam James <sam@gentoo.org>
+
+ ld: ld-lib.exp: log failed dump.out contents for debugging
+ If we're using dump_prog in a test which fails, log the dump.out contents
+ to ld.log to aid debugging.
+
+ This avoids needing to ask reporters to manually run e.g. `objdump` commands
+ when making bug reports.
+
+ PR30722
+ * ld/testsuite/lib/ld-lib.exp: Log failed dump.out contents to aid
+ debugging.
+
+ Approved-by: Nick Clifton <nickc@redhat.com>
+
+2023-08-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle self-reference DIE
+ While working on a dwarf assembly test-case I accidentally created the
+ following pathological dwarf:
+ ...
+ <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
+ <bf> DW_AT_name : c1
+ <c2> DW_AT_specification: <0xbe>
+ ...
+ and noticed gdb segfaulting during cooked index creating due to running out of
+ stack. This is a regression from gdb-12, where gdb just hung.
+
+ Fix this by inhibiting the scan_attributes self-recursion for self-references.
+
+ The same test-case with -readnow makes gdb hang, so also fix this in
+ dwarf2_attr and follow_die_ref.
+
+ Note that this doesn't fix the same problems for the more complicated case of:
+ ...
+ <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
+ <bf> DW_AT_name : c1
+ <c2> DW_AT_specification: <0xc6>
+ <1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
+ <c7> DW_AT_name : c2
+ <ca> DW_AT_specification: <0xbe>
+ ...
+ but the approach for deciding whether to fix pathological dwarf cases is as
+ per PR27981 comment 3:
+ ...
+ yes if it is cheap/obvious, and no if it is something complicated or expensive.
+ ...
+ and at this point I'm not sure whether fixing this will fall in the first
+ category.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-16 Tom Tromey <tromey@adacore.com>
+
+ Avoid buffer overflow in ada_decode
+ A bug report pointed out a buffer overflow in ada_decode, which Keith
+ helpfully analyzed. ada_decode had a logic error when the input was
+ all digits. While this isn't valid -- and would probably only appear
+ in fuzzer tests -- it still should be handled properly.
+
+ This patch adds a missing bounds check. Tested with the self-tests in
+ an asan build.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-08-16 Tom Tromey <tromey@adacore.com>
+
+ Fix obvious bug in aggregate expression
+ I found an obvious bug in Ada aggregate expression handling:
+
+ if (vvo != nullptr)
+ error (_("Invalid record component association."));
+ name = vvo->get_symbol ()->natural_name ();
+
+ Here the code errors when vvo is not null -- and then proceeds to use
+ vvo.
+
+ This hasn't caused a crash because, I believe, there's currently no
+ way to reach this code in the null case. However, I'm not really
+ willing to assert this...
+
+ Fixing this shows another bug, which is that due to the way the parser
+ works, a field name in an aggregate expression might erroneously be
+ fully qualified if some global variable with the same base name
+ exists.
+
+ The included test case triggers both bugs. Note that the test
+ includes a confounding case for array aggregates as well, but as these
+ are harder to fix, I've left it as kfail.
+
+ As this is Ada-specific, and has already been tested internally at
+ AdaCore, I am checking it in.
+
+2023-08-16 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP module-removed event
+ DAP specifies an event that should be sent when a module is removed.
+ This patch implements this.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2023-08-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp
+ I ran into a test failure on gdb.python/py-thread-exited.c. The test
+ creates two threads and then catches the thread exits in Python. The
+ test expects the threads to exit in a specific order.
+
+ As the test is currently written, it is _likely_, but not guaranteed,
+ that the threads will exit in the same order they are created, which
+ is what the test expects.
+
+ When running on a loaded system I ran into a case where the threads
+ exited in the reverse creation order, which caused the test to fail.
+
+ I could fix this by having the .exp file not care about the thread
+ order, or by changing the C file to force the order. I chose the
+ later, and added a pthread_barrier_t to ensure the threads exit in the
+ correct order.
+
+ There should be no change in what is tested after this commit.
+
+2023-08-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix vfork regressions when target-non-stop is off
+ It was pointed out on the mailing list[1] that after this commit:
+
+ commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
+ Date: Wed Jun 21 14:18:54 2023 +0100
+
+ gdb: don't resume vfork parent while child is still running
+
+ the test gdb.base/vfork-follow-parent.exp now has some failures when
+ run with the native-gdbserver or native-extended-gdbserver boards:
+
+ FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
+ FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
+ FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
+ FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)
+
+ The reason that these failures don't show up when run on the standard
+ unix board is that the test is only run in the default operating mode,
+ so for Linux this will be all-stop on top of non-stop.
+
+ If we adjust the test script so that it runs in the default mode and
+ with target-non-stop turned off, then we see the same failures on the
+ unix board. This commit includes this change.
+
+ The way that the test is written means that it is not (currently)
+ possible to turn on non-stop mode and have the test still work, so
+ this commit does not do that.
+
+ I have also updated the test script so that the vfork child performs
+ an exec as well as the current exit. Exec and exit are the two ways
+ in which a vfork child can release the vfork parent, so testing both
+ of these cases is useful I think.
+
+ In this test the inferior performs a vfork and the vfork-child
+ immediately exits. The vfork-parent will wait for the vfork-child and
+ then blocks waiting for gdb. Once gdb has released the vfork-parent,
+ the vfork-parent also exits.
+
+ In the test that fails, GDB sets 'detach-on-fork off' and then runs to
+ the vfork. At this point the test tries to just "continue", but this
+ fails as the vfork-parent is still selected, and the parent can't
+ continue until the vfork-child completes. As the vfork-child is
+ stopped by GDB the parent will never stop once resumed, so GDB refuses
+ to resume it.
+
+ The test script then sets 'schedule-multiple on' and once again
+ continues. This time GDB, in theory, resumes both the parent and the
+ child, the parent will be held blocked by the kernel, but the child
+ will run until it exits, and which point GDB stops again, this time
+ with inferior 2, the newly exited vfork-child, selected.
+
+ What happens after this in the test script is irrelevant as far as
+ this failure is concerned.
+
+ To understand why the test started failing we should consider the
+ behaviour of four different cases:
+
+ 1. All-stop-on-non-stop before commit b1e0126ec56e,
+
+ 2. All-stop-on-non-stop after commit b1e0126ec56e,
+
+ 3. All-stop-on-all-stop before commit b1e0126ec56e, and
+
+ 4. All-stop-on-all-stop after commit b1e0126ec56e.
+
+ Only case #4 is failing after commit b1e0126ec56e, but I think the
+ other cases are interesting because, (a) they inform how we might fix
+ the regression, and (b) it turns out the behaviour of #2 changed too
+ with the commit, but the change was harmless.
+
+ For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
+ is:
+
+ 1. GDB calls proceed with the vfork-parent selected, as schedule
+ multiple is on user_visible_resume_ptid returns -1 (everything)
+ as the resume_ptid (see proceed function),
+
+ 2. As this is all-stop-on-non-stop, every thread is resumed
+ individually, so GDB tries to resume both the vfork-parent and the
+ vfork-child, both of which succeed,
+
+ 3. The vfork-parent is held stopped by the kernel,
+
+ 4. The vfork-child completes (exits) at which point the GDB sees the
+ EXITED event for the vfork-child and the VFORK_DONE event for the
+ vfork-parent,
+
+ 5. At this point we might take two paths depending on which event
+ GDB handles first, if GDB handles the VFORK_DONE first then:
+
+ (a) As GDB is controlling both parent and child the VFORK_DONE is
+ ignored (see handle_vfork_done), the vfork-parent will be
+ resumed,
+
+ (b) GDB processes the EXITED event, selects the (now defunct)
+ vfork-child, and stops, returning control to the user.
+
+ Alternatively, if GDB selects the EXITED event first then:
+
+ (c) GDB processes the EXITED event, selects the (now defunct)
+ vfork-child, and stops, returning control to the user.
+
+ (d) At some future time the user resumes the vfork-parent, at
+ which point the VFORK_DONE is reported to GDB, however, GDB
+ is ignoring the VFORK_DONE (see handle_vfork_done), so the
+ parent is resumed.
+
+ For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
+ important difference is in step (2) above, now, instead of resuming
+ both the vfork-parent and the vfork-child, only the vfork-child is
+ resumed. As such, when we get to step (5), only a single event, the
+ EXITED event is reported.
+
+ GDB handles the EXITED just as in (5)(c), then, later, when the user
+ resumes the vfork-parent, the VFORKED_DONE is immediately delivered
+ from the kernel, but this is ignored just as in (5)(d), and so,
+ though the pattern of when the vfork-parent is resumed changes, the
+ overall pattern of which events are reported and when, doesn't
+ actually change. In fact, by not resuming the vfork-parent, the order
+ of events (in this test) is now deterministic, which (maybe?) is a
+ good thing.
+
+ If we now consider case #3, all-stop-on-all-stop before commit
+ b1e0126ec56e, then what happens is:
+
+ 1. GDB calls proceed with the vfork-parent selected, as schedule
+ multiple is on user_visible_resume_ptid returns -1 (everything)
+ as the resume_ptid (see proceed function),
+
+ 2. As this is all-stop-on-all-stop, the resume is passed down to the
+ linux-nat target, the vfork-parent is the event thread, while the
+ vfork-child is a sibling of the event thread,
+
+ 3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
+ for all threads, this causes the vfork-child to be resumed. Then
+ in linux_nat_target::resume, the event thread, the vfork-parent,
+ is also resumed.
+
+ 4. The vfork-parent is held stopped by the kernel,
+
+ 5. The vfork-child completes (exits) at which point the GDB sees the
+ EXITED event for the vfork-child and the VFORK_DONE event for the
+ vfork-parent,
+
+ 6. We are now in a situation identical to step (5) as for
+ all-stop-on-non-stop above, GDB selects one of the events to
+ handle, and whichever we select the user sees the correct
+ behaviour.
+
+ And so, finally, we can consider #4, all-stop-on-all-stop after commit
+ b1e0126ec56e, this is the case that started failing.
+
+ We start out just like above, in proceed, the resume_ptid is
+ -1 (resume everything), due to schedule multiple being on. And just
+ like above, due to the target being all-stop, we call
+ proceed_resume_thread_checked just once, for the current thread,
+ which, remember, is the vfork-parent thread.
+
+ The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
+ thread, read the commit message for the justification for this change.
+
+ However, this means that GDB now rejects resuming the vfork-parent in
+ this case, which means that nothing gets resumed! Obviously, if
+ nothing resumes, then nothing will ever stop, and so GDB appears to
+ hang.
+
+ I considered a couple of solutions which, in the end, I didn't go
+ with, these were:
+
+ 1. Move the vfork-parent check out of proceed_resume_thread_checked,
+ and place it in proceed, but only on the all-stop-on-non-stop
+ path, this should still address the issue seen in b1e0126ec56e,
+ but would avoid the issue seen here. I rejected this just
+ because it didn't feel great to split the checks that exist in
+ proceed_resume_thread_checked like this,
+
+ 2. Extend the condition in proceed_resume_thread_checked by adding a
+ target_is_non_stop_p check. This would have the same effect as
+ idea 1, but leaves all the checks in the same place, which I
+ think would be better, but this still just didn't feel right to
+ me, and so,
+
+ What I noticed was that for the all-stop-on-non-stop, after commit
+ b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
+ The vfork-parent isn't going to run anyway (the kernel will hold it
+ back), so if feels like we there's no harm in just waiting for the
+ child to complete, and then resuming the parent.
+
+ So then I started looking at follow_fork, which is called from the top
+ of proceed. This function already has the task of switching between
+ the parent and child based on which the user wishes to follow. So, I
+ wondered, could we use this to switch to the vfork-child in the case
+ that we are attached to both?
+
+ Turns out this is pretty simple to do.
+
+ Having done that, now the process is for all-stop-on-all-stop after
+ commit b1e0126ec56e, and with this new fix is:
+
+ 1. GDB calls proceed with the vfork-parent selected, but,
+
+ 2. In follow_fork, and follow_fork_inferior, GDB switches the
+ selected thread to be that of the vfork-child,
+
+ 3. Back in proceed user_visible_resume_ptid returns -1 (everything)
+ as the resume_ptid still, but now,
+
+ 4. When GDB calls proceed_resume_thread_checked, the vfork-child is
+ the current selected thread, this is not a vfork-parent, and so
+ GDB allows the proceed to continue to the linux-nat target,
+
+ 5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
+ for all threads, this does not resume the vfork-parent (because
+ it is a vfork-parent), and then the vfork-child is resumed as
+ this is the event thread,
+
+ At this point we are back in the same situation as for
+ all-stop-on-non-stop after commit b1e0126ec56e, that is, the
+ vfork-child is resumed, while the vfork-parent is held stopped by
+ GDB.
+
+ Eventually the vfork-child will exit or exec, at which point the
+ vfork-parent will be resumed.
+
+ [1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/
+
+2023-08-16 Paul Iannetta <piannetta@kalrayinc.com>
+
+ kvx: New port.
+
+2023-08-16 Richard Ball <richard.ball@arm.com>
+
+ aarch64: Enable Cortex-A720 CPU
+ This patch adds support for the Cortex-A720 CPU to binutils.
+
+ bfd/ChangeLog:
+
+ * cpu-aarch64.c: Add Cortex-A720.
+
+ gas/ChangeLog:
+
+ * NEWS: Update docs.
+ * config/tc-aarch64.c: Add Cortex-A720.
+ * doc/c-aarch64.texi: Update docs.
+ * testsuite/gas/aarch64/cpu-cortex-a720.d: New test.
+
+2023-08-16 Puputti, Matti <matti.puputti@intel.com>
+
+ gdb, infcmd: support jump command in multi-inferior case
+ Fixes the issue where jump failed if multiple inferiors run the same
+ source.
+
+ See the below example
+
+ $ gdb -q ./simple
+ Reading symbols from ./simple...
+ (gdb) break 2
+ Breakpoint 1 at 0x114e: file simple.c, line 2.
+ (gdb) run
+ Starting program: /temp/simple
+
+ Breakpoint 1, main () at simple.c:2
+ 2 int a = 42;
+ (gdb) add-inferior
+ [New inferior 2]
+ Added inferior 2 on connection 1 (native)
+ (gdb) inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) info inferiors
+ Num Description Connection Executable
+ 1 process 6250 1 (native) /temp/simple
+ * 2 <null> 1 (native)
+ (gdb) file ./simple
+ Reading symbols from ./simple...
+ (gdb) run
+ Starting program: /temp/simple
+
+ Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
+ 2 int a = 42;
+ (gdb) info inferiors
+ Num Description Connection Executable
+ 1 process 6250 1 (native) /temp/simple
+ * 2 process 6705 1 (native) /temp/simple
+ (gdb) jump 3
+ Unreasonable jump request
+ (gdb)
+
+ In this example, jump fails because the debugger finds two different
+ locations, one for each inferior.
+
+ Solution is to limit the search to the current program space.
+
+ This is done by having the jump_command function use
+ decode_line_with_current_source rather than
+ decode_line_with_last_displayed, which makes sense,
+ the *_current_source function always looks up a location based on the
+ current thread's location -- if a user is asking the current thread to
+ jump, then surely their destination should be relative to where the
+ current thread is located.
+
+ Then, inside decode_line_with_current_source, the call to
+ decode_line_1 is updated to pass through the current program_space,
+ which will limit the returned locations to those in the current
+ program space.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-08-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-15 Tom Tromey <tromey@adacore.com>
+
+ Mention process_stratum in inferior::priv comment
+ From what I can tell, inferior::priv is reserved for the
+ process_stratum target. It seems to me that it has to be, because
+ currenlty only such targets use it, and if a target at another stratum
+ started using this field, then conflicts could occur. This patch
+ documents this.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-15 Nick Clifton <nickc@redhat.com>
+
+ Updated Russian translation for the bfd directory
+
+2023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Make T-Head testing pattern more generic
+ On some T-Head vendor extensions, we test against the constant
+ 18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
+ However, it heavily depends on the fact that the value used to print
+ immediate value is a 64-bit unsigned type and this constant is not (and
+ should not be) important (we just want to know that -1 is not valid).
+
+ This commit replaces all such occurrences of 18446744073709551615 with
+ a more generic regular expression.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/x-thead-ba-fail.l: Replace
+ 18446744073709551615 with generic regular expression.
+ * testsuite/gas/riscv/x-thead-bb-fail.l: Likewise.
+ * testsuite/gas/riscv/x-thead-bs-fail.l: Likewise.
+ * testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise.
+ * testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise.
+ * testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise.
+
+2023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa'
+ The documentation of the 'Zfa' extension states that "fli.h" is available
+ "if the Zfh or Zvfh extension is implemented" (both the latest and the
+ oldest editions are checked).
+
+ This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
+ 'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
+ This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
+ extensions are implemented.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add new
+ instruction class handling.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zfa-zvfh.s: New test.
+ * testsuite/gas/riscv/zfa-zvfh.d: Ditto.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class): Add new instruction
+ class.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
+ from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.
+
+2023-08-15 Tsukasa OI <research_trasio@irq.a4lg.com>
+ Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Add support for the 'Zihintntl' extension
+ This commit adds 'Zihintntl' extension and its hint instructions.
+
+ This is based on:
+ <https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
+ the first ISA Manual noting that the 'Zihintntl' extension is ratified.
+
+ Note that compressed 'Zihintntl' hints require either 'C' or
+ 'Zca' extension.
+
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
+ standard hint 'Z' extension.
+ (riscv_multi_subset_supports): Support new instruction classes.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
+ including auto-compression without C prefix and explicit C prefix.
+ * testsuite/gas/riscv/zihintntl.d: Likewise.
+ * testsuite/gas/riscv/zihintntl-na.d: Likewise.
+ * testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
+ between 'Zihintntl' and base 'I' or 'C' instructions.
+ * testsuite/gas/riscv/zihintntl-base.d: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class): Add new instruction
+ classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
+ (MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
+ MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
+ MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
+ MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
+ MATCH_C_NTL_ALL): New.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Add instructions from the
+ 'Zihintntl' extension.
+
+2023-08-15 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: remove indirection from register tables
+ The longest register name is 4 characters (plus a nul one), so using a
+ 4- or 8-byte pointer to get at it is neither space nor time efficient.
+ Embed the names right into the array. For PIE this also reduces the
+ number of base relocations in the final image.
+
+ To avoid old gcc, when generating 32-bit code, bogusly warning about
+ bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
+ an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
+ a 64-bit value, and it also doesn't need to - all operand fields to
+ date are far more narrow than 32 bits. This in turn allows dropping a
+ number of casts elsewhere.
+
+2023-08-15 Jan Beulich <jbeulich@suse.com>
+
+ PPC: remove indirection from struct pd_reg
+ The longest register name is 5 characters (plus a nul one), so using a
+ 4- or 8-byte pointer to get at it is neither space nor time efficient.
+ Embed the names right into the array. For PIE this also reduces the
+ number of base relocations in the final image.
+
+2023-08-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix YYSTYPE and yyalloc odr violation
+ When building gdb with -O2 -flto I run into:
+ ...
+ ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
+ Definition Rule [-Werror=odr]
+ ...
+
+ Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.
+
+ Likewise for yyalloc.
+
+ Tested on x86_64-linux. Also tested with byacc rather than bison on
+ suggestion of Tom Tromey.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Stop a process if it is running before killing it.
+ In addition, detach from any child processes implicitly attached to by
+ the kernel due to fork following that have not yet been processed by
+ GDB's core.
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Fix thread_alive against a running thread.
+ FreeBSD's ptrace fails requests with EBUSY against a running process.
+ Report that the thread is alive instead of dead if ptrace fails with
+ EBUSY.
+
+ This fixes an internal error in the gdb.threads/detach-step-over.exp
+ test where one process was detached while a thread in a second process
+ was being stepped. The core incorrectly assumed the stepping thread
+ had vanished and discarded the pending stepping state. When the
+ thread later reported a SIGTRAP from completing the step, this
+ triggered an assertion.
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Fix several issues with detaching.
+ - Detach from any child processes implicitly attached to by the kernel
+ due to fork following that have not yet been processed by GDB's
+ core.
+
+ - Delete breakpoints before detaching.
+
+ inf-ptrace::detach does not do this (somewhat surprisingly), so add
+ an override to remove breakpoints from a process before detaching
+ from it.
+
+ This also requires explicitly draining any pending SIGTRAP events
+ for software breakpoints before detaching. In particular, threads
+ may need their PC adjusted due to the software breakpoint before
+ being resumed after detach. On more modern systems using the si_code
+ from SIGTRAP to identify software breakpoint traps, the PC is adjusted
+ in ::wait_1 as a side effect of parsing the event. To support older
+ kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential
+ new PC matches an existing software breakpoint.
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Fix resuming and waiting with multiple processes.
+ I did not fully understand the requirements of multiple process
+ support when I enabled it previously and several parts were broken.
+ In particular, the resume method was only resuming a single process,
+ and wait was not stopping other processes when reporting an event.
+
+ To support multiple running inferiors, add a new per-inferior
+ structure which trackes the number of existing and running LWPs for
+ each process. The structure also stores a ptid_t describing the
+ set of LWPs currently resumed for each process.
+
+ For the resume method, iterate over all non-exited inferiors resuming
+ each process matching the passed in ptid rather than only resuming the
+ current inferior's process for a wildcard ptid. If a resumed process
+ has a pending event, don't actually resume the process, but other
+ matching processes without a pending event are still resumed in case
+ the later call to the wait method requests an event from one of the
+ processes without a pending event.
+
+ For the wait method, stop other running processes before returning an
+ event to the core. When stopping a process, first check to see if an
+ event is already pending. If it is, queue the event to be reported
+ later. If not, send a SIGSTOP to the process and wait for it to stop.
+ If the event reported by the wait is not for the SIGSTOP, queue the
+ event and remember to ignore a future SIGSTOP event for the process.
+
+ Note that, unlike the Linux native target, entire processes are
+ stopped rather than individual LWPs. In FreeBSD one can only wait on
+ processes (via pid), not for an event from a specific thread.
+
+ Other changes in this commit handle bookkeeping for the per-inferior
+ data such as migrating the data to the new inferior in the follow_exec
+ method. The per-inferior data is created in the attach,
+ create_inferior, and follow_fork methods.
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Defer any ineligible events reported by wait.
+ If wait_1 finds an event for a thread or process that does not match
+ the set of threads and processes previously resumed, defer the event.
+ If the event is for a specific thread, suspend the thread and continue
+ the associated process before waiting for another event.
+
+ One specific example of such an event is if a thread is created while
+ another thread in the same process hits a breakpoint. If the second
+ thread's event is reported first, the target resume method does not
+ yet "know" about the new thread and will not suspend it via
+ PT_SUSPEND. When wait is called, it will probably return the event
+ from the first thread before the result of the step from second
+ thread. This is the case reported in PR 21497.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21497
+
+2023-08-14 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Add a list of pending events.
+ The m_pending_events list stores a queue of deferred events that might
+ be reported by the next call to the target's wait method. The set of
+ events that are eligible is filtered by the ptid passed to resume.
+
+ For now this just replaces the list of vfork_done events. A
+ subsequent commit will reuse this to store other events.
+
+2023-08-14 Tom Tromey <tom@tromey.com>
+
+ Remove alloca from osabi.c
+ I noticed that the call to alloca in osabi.c can be replaced with a
+ statically-sized buffer, because some code just before the declaration
+ ensures that the length is bounded.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix struct token odr violation
+ When building gdb with -O2 -flto I run into:
+ ...
+ /data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
+ violates the C++ One Definition Rule [-Wodr]
+ struct token
+ ^
+ /data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
+ another translation unit
+ struct token
+ ^
+ ...
+
+ Fix this by renaming to c_token and d_token.
+
+ Likewise in:
+ - fortran-exp.y, renaming to f_token,
+ - go-exp.y, renaming to go_token, and
+ - p-exp.y, renaming to p_token.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix struct token_and_value odr violation
+ When build gdb with -O2 -flto I run into:
+ ...
+ gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
+ One Definition Rule [-Wodr]
+ struct token_and_value
+ ^
+ gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
+ unit
+ struct token_and_value
+ ^
+ ...
+
+ Fix this by renaming to c_token_and_value and d_token_and_value.
+
+ Likewise in gdb/go-exp.y, renaming to go_token_and_value.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix enum param_types odr violation
+ When building gdb with -O2 -flto, I run into:
+ ...
+ gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
+ One Definition Rule [-Wodr]
+ enum param_types
+ ^
+ gdb/python/py-param.c:33:6: note: an enum with different value name is \
+ defined in another translation unit
+ enum param_types
+ ^
+ ...
+
+ Fix this by renaming to enum scm_param_types and py_param_types.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c
+ In gdb/python/py-param.c we have:
+ ...
+ enum param_types
+ {
+ ...
+ }
+ param_types;
+ ...
+ which declares both an enum param_types, and an unused variable param_types.
+
+ Fix this by removing the variable.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix maint print symbols/psymbols help text
+ Consider the help text of "maint print symbols":
+ ...
+ (gdb) help maint print symbols
+ Print dump of current symbol definitions.
+ Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
+ mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
+ Entries in the full symbol table are dumped to file OUTFILE,
+ or the terminal if OUTFILE is unspecified.
+ If ADDRESS is provided, dump only the file for that address.
+ If SOURCE is provided, dump only that file's symbols.
+ If OBJFILE is provided, dump only that file's minimal symbols.
+ ...
+ and "maint print psymbols":
+ ...
+ (gdb) help maint print psymbols
+ Print dump of current partial symbol definitions.
+ Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
+ mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
+ Entries in the partial symbol table are dumped to file OUTFILE,
+ or the terminal if OUTFILE is unspecified.
+ If ADDRESS is provided, dump only the file for that address.
+ If SOURCE is provided, dump only that file's symbols.
+ If OBJFILE is provided, dump only that file's minimal symbols.
+ ...
+
+ The OBJFILE lines mistakingly mention minimal symbols.
+
+ Fix this by reformulating as "dump only that object file's symbols".
+
+ Also make the ADDRESS lines more clear by using the formulation: "dump only
+ the symbols for the file with code at that address".
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
+
+ PR gdb/30742
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742
+
+2023-08-14 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Build libpr23169a.so with -z lazy
+ pr23169b test only works with lazy binding. To work with linker which
+ disables lazy binding by default, build pr23169b binaries with -z lazy.
+
+ PR ld/30698
+ * ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy.
+
+2023-08-14 Alan Modra <amodra@gmail.com>
+
+ Remove fall-back prune_warnings
+ No one should be using versions of dejagnu without prune_warnings,
+ which was available in 1996 (dejagnu-1.3).
+
+ binutils/
+ * testsuite/lib/binutils-common.exp: Remove fallback prune_warnings.
+ gas/
+ * testsuite/lib/gas-defs.exp: Remove fallback prune_warnings.
+
+2023-08-14 Alan Modra <amodra@gmail.com>
+
+ Re: PR30715, VAX: md_create_long_jump
+ Tidy comment formatting.
+
+2023-08-14 Sam James <sam@gentoo.org>
+
+ ld: fix relocatable, retain7a target pattens for HPPA
+ Fix issue reported by Dave and Alan.
+
+ Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
+ Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
+ before.
+
+ ld/
+ PR 30733
+ PR 30734
+ * ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
+ but include hppa1.1, hppa2.0.
+ * ld/testsuite/ld-elf/retain7a.d: Ditto.
+
+ Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49
+ Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5
+
+2023-08-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Don't deduplicate variables in gdb-index
+ When running test-case gdb.python/py-symbol.exp with target board
+ cc-with-gdb-index, we run into:
+ ...
+ (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
+ 1^M
+ (gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
+ ...
+
+ [ Note that the test-case contains rr in both py-symtab.c:
+ ...
+ static int __attribute__ ((used)) rr = 42; /* line of rr */
+ ...
+ and py-symtab-2.c:
+ ...
+ static int __attribute__ ((used)) rr = 99; /* line of other rr */
+ ... ]
+
+ This passes with gdb-12-branch, and fails with gdb-13-branch.
+
+ AFAIU the current code in symtab_index_entry::minimize makes the assumption
+ that it's fine to store only one copy of rr in the gdb-index, because
+ "print rr" will only ever print one, and always the same.
+
+ But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
+ returns a list of variables rather than the first one.
+
+ In other words, the current approach breaks feature parity between cooked
+ index and gdb-index.
+
+ Note btw that also debug-names has both instances:
+ ...
+ [ 5] #00597969 rr:
+ <4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
+ <4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
+ ...
+
+ Fix this in symtab_index_entry::minimize, by not deduplicating variables.
+
+ Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+ PR symtab/30720
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720
+
+2023-08-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: pass gprofng location to gp-display-gui
+ gprofng GUI can be installed to the other directory.
+ In this case, $PATH is used to find gp-display-gui from gprofng
+ and option --gprofngdir is passed to gp-display-gui.
+
+ gprofng/ChangeLog
+ 2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir.
+
+2023-08-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix typos in get_realpath() and check_executable()
+ gprofng/ChangeLog
+ 2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Application.cc (Application::get_realpath): Fix typo.
+ * src/checks.cc (collect::check_executable): Likewise.
+
+2023-08-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-13 Alan Modra <amodra@gmail.com>
+
+ Re: gdb: warn unused result for bfd IO functions
+ Add a missing return statement.
+
+2023-08-12 Kalvis Duckmanton <kalvisd@gmail.com>
+
+ PR30715, VAX: md_create_long_jump
+ PR 30715
+ * config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
+ * testsuite/gas/vax/broken_word.d,
+ * testsuite/gas/vax/broken_word.s: New test.
+ * testsuite/gas/vax/vax.exp: Run it.
+
+2023-08-12 Kevin Buettner <kevinb@redhat.com>
+
+ gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps
+ At the moment, while performing a software single-step, gdbserver fails
+ to reinsert software single-step breakpoints for a LWP when
+ interrupted by a signal in another thread. This commit fixes this
+ problem by reinstalling software single-step breakpoints in
+ linux_process_target::resume_stopped_resumed_lwps in
+ gdbserver/linux-low.cc.
+
+ This bug was discovered due to a failing assert in maybe_hw_step()
+ in gdbserver/linux-low.cc. Looking at the backtrace revealed
+ that the caller was linux_process_target::resume_stopped_resumed_lwps.
+ I was uncertain whether the assert should still be valid when called
+ from that method, so I tried hoisting the assert from maybe_hw_step
+ to all callers except resume_stopped_resumed_lwps. But running the
+ new test case, described below, showed that merely eliminating the
+ assert for this case was NOT a good fix - a study of the log file for
+ the test showed that the single-step operation failed to occur.
+ Instead GDB (via gdbserver) stopped at the next breakpoint that was
+ hit.
+
+ Zhiyong Yan had proposed a fix which resinserted software single-step
+ breakpoints, albeit at a different location in linux-low.cc. Testing
+ revealed that, while running gdb.threads/pending-fork-event-detach,
+ the executable associated with that test would die due to a SIGTRAP
+ after the test program was detached. Examination of the core file(s)
+ showed that a breakpoint instruction had been left in program memory.
+ Test results were otherwise very good, so Zhiyong was definitely on
+ the right track!
+
+ This commit causes software single-step breakpoint(s) to be inserted
+ before the call to maybe_hw_step in resume_stopped_resumed_lwps. This
+ will cause 'has_single_step_breakpoints (thread)' to be true, so that
+ the assert in maybe_hw_step...
+
+ /* GDBserver must insert single-step breakpoint for software
+ single step. */
+ gdb_assert (has_single_step_breakpoints (thread));
+
+ ...will no longer fail. And better still, the single-step breakpoints
+ are reinstalled, so that stepping will actually work, even when
+ interrupted.
+
+ The C code for the test case was loosely adapted from the reproducer
+ provided in Zhiyong's bug report for this problem. The .exp file was
+ copied from next-fork-other-thread.exp and then tweaked slightly. As
+ noted in a comment in next-fork-exec-other-thread.exp, I had to remove
+ "on" from the loop for non-stop as it was failing on all architectures
+ (including x86-64) that I tested. I have a feeling that it ought to
+ work, but this can be investigated separately and (re)enabled once it
+ works. I also increased the number of iterations for the loop running
+ the "next" commands. I've had some test runs which don't show the bug
+ until the loop counter exceeded 100 iterations. The C file for the
+ new test uses shorter delays than next-fork-other-thread.c though, so
+ it doesn't take overly long (IMO) to run this new test.
+
+ Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
+ userland using a gdbserver build without the fix in this commit shows
+ the following results:
+
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here
+
+ === gdb Summary ===
+
+ # of unexpected core files 12
+ # of expected passes 3011
+ # of unexpected failures 14
+
+ Each of the 12 core files were caused by the failed assertion in
+ maybe_hw_step in linux-low.c. These correspond to 12 of the
+ unexpected failures.
+
+ When the tests are run using a gdbserver build which includes the fix
+ in this commit, the results are significantly better, but not perfect:
+
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
+ FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line
+
+ === gdb Summary ===
+
+ # of expected passes 10178
+ # of unexpected failures 2
+
+ I think that the two remaining failures are due to some different
+ problem. They are also racy - I've seen runs with no failures or only
+ one failure, but never more than two. Also, those runs were conducted
+ with the loop count in next-fork-exec-other-thread.exp set to 200.
+ During his testing of this fix and the new test case, Luis Machado
+ found that this test was taking a long time and asked about ways to
+ speed it up. I then conducted additional tests in which I gradually
+ reduced the loop count, timing each one, also noting the number of
+ failures. With the loop count set to 30, I found that I could still
+ reliably reproduce the failures that Zhiyong reported (in which, with
+ the proper settings, core files are created). But, with the loop
+ count set to 30, the other failures noted above were much less likely
+ to show up. Anyone wishing to investigate those other failures should
+ set the loop count back up to 200.
+
+ Running the new test on x86-64 and aarch64, both native and
+ native-gdbserver shows no failures.
+
+ Also, I see no regressions when running the entire test suite for
+ armv7l-unknown-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit
+ kernel+userland) with --target_board=native-gdbserver. Additionally,
+ using --target_board=native-gdbserver, I also see no regressions for
+ the entire test suite for x86-64 and aarch64 running Fedora 38.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
+ Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
+ Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2023-08-12 Alan Modra <amodra@gmail.com>
+
+ regen config
+ This regenerates config files changed by the previous 44 commits.
+ Note that subject lines in these commits mostly match the gcc git
+ originating commit.
+
+2023-08-12 Arsen Arsenović <arsen@aarsen.me>
+
+ toplevel: Substitute GDCFLAGS instead of using CFLAGS
+ r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
+ implemented this change, but only on the generated file rather than in
+ the template it is generated from.
+
+ * Makefile.tpl: Substitute @GDCFLAGS@ instead of using
+ $(CFLAGS).
+
+2023-08-12 Andreas Schwab <schwab@suse.de>
+
+ Use substituted GDCFLAGS
+ Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
+ that the subdir configure scripts use the configured value.
+
+ * configure.ac (GDCFLAGS): Set default from ${CFLAGS}.
+
+2023-08-12 Philip Herron <philip.herron@embecosm.com>
+
+ gccrs: Add gcc-check-target check-rust
+ This allows us to invoke the rust testsuite.
+
+ * Makefile.def: Add Rust language.
+
+2023-08-12 Roger Sayle <roger@nextmovesoftware.com>
+
+ PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def
+ This patch fixes PR bootstrap/106472 by adding a missing dependency
+ to Makefile.def to allow make bootstrap when configured using
+ "--enable-languages=go" (and not using make with multiple threads).
+
+ 2022-07-31 Roger Sayle <roger@nextmovesoftware.com>
+
+ PR bootstrap/106472
+ * Makefile.def (dependencies): Make configure-target-libgo depend
+ upon all-target-libbacktrace.
+
+2023-08-12 Thomas Schwinge <thomas@codesourcery.com>
+
+ Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]
+
+2023-08-12 Eugene Rozenfeld <erozen@microsoft.com>
+
+ Disable warnings as errors for STAGEautofeedback.
+ Compilation during STAGEautofeedback produces additional warnings
+ since inlining decisions with -fauto-profile are different from
+ other builds.
+
+ This patches disables warnings as errors for STAGEautofeedback.
+
+ Tested on x86_64-pc-linux-gnu.
+
+ * Makefile.tpl: Disable warnings as errors for STAGEautofeedback
+
+2023-08-12 Eugene Rozenfeld <erozen@microsoft.com>
+
+ Fix autoprofiledbootstrap build
+ * Makefile.tpl: Define PROFILE_MERGER
+
+2023-08-12 Eugene Rozenfeld <erozen@microsoft.com>
+
+ Fix collection and processing of autoprofile data for target libs
+ cc1, cc1plus, and lto built during STAGEautoprofile need to be built with
+ debug info since they are used to build target libs. -gtoggle was
+ turning off debug info for this stage.
+
+ create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto
+ instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when
+ processing profile data collected while building target libraries.
+
+ Tested on x86_64-pc-linux-gnu.
+
+ * Makefile.tpl: Remove -gtoggle for STAGEautoprofile
+
+2023-08-12 Eugene Rozenfeld <erozen@microsoft.com>
+
+ Collect both user and kernel events for autofdo tests and autoprofiledbootstrap
+ When we collect just user events for autofdo with lbr we get some events where branch
+ sources are kernel addresses and branch targets are user addresses. Without kernel MMAP
+ events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if
+ it can't map at least 95% of events. We sometimes get below this threshold with just
+ user events. The change is to collect both user events and kernel events.
+
+ Tested on x86_64-pc-linux-gnu.
+
+ * Makefile.tpl: Collect both kernel and user events for autofdo
+
+2023-08-12 Iain Buclaw <ibuclaw@gdcproject.org>
+
+ d: Import dmd b8384668f, druntime e6caaab9, phobos 5ab9ad256 (v2.098.0-beta.1)
+ The D front-end is now itself written in D, in order to build GDC, you
+ will need a working GDC compiler (GCC version 9.1 or later).
+
+ GCC changes:
+
+ - Add support for bootstrapping the D front-end.
+
+ These add the required components in order to have a D front-end written
+ in D itself. Because the compiler front-end only depends on the core
+ runtime modules, only libdruntime is built for the bootstrap stages.
+
+ D front-end changes:
+
+ - Import dmd v2.098.0-beta.1.
+
+ Druntime changes:
+
+ - Import druntime v2.098.0-beta.1.
+
+ Phobos changes:
+
+ - Import phobos v2.098.0-beta.1.
+
+ The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of
+ development on the D programming language and run-time libraries.
+
+ * Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
+ libatomic.
+ * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
+ (STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
+ target-libphobos-bootstrap.
+ (STAGE2_CONFIGURE_FLAGS): Likewise.
+
+2023-08-12 Sergei Trofimovich <siarheit@google.com>
+
+ Makefile.def: drop remnants of unused libelf
+ Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR
+ lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0.
+
+ This change removes unused references to libelf from top-level configure
+ and Makefile.
+
+ * Makefile.def: Drop libelf module and gcc-configure dependency
+ on it.
+ * Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and
+ LIBELFINC.
+
+2023-08-12 Martin Liska <mliska@suse.cz>
+
+ Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin.
+ PR gcov-profile/94570
+ * ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
+ for CYGWIN.
+
+ Co-Authored-By: Jonathan Yong <10walls@gmail.com>
+
+2023-08-12 Christophe Lyon <christophe.lyon@st.com>
+
+ FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
+ In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
+ libraries support is required, as uclinux does not guarantee that.
+
+ * libtool.m4: Handle uclinuxfdpiceabi.
+
+2023-08-12 Bernhard M. Wiedemann <bwiedemann@suse.de>
+
+ libtool.m4: Sort output of 'find' to enable deterministic builds.
+ * libtool.m4: Sort output of 'find' to enable deterministic builds.
+ * ltmain.sh: Likewise.
+
+2023-08-12 John David Anglin <danglin@gcc.gnu.org>
+
+ Fix hppa64-hpux11 build to remove source paths from embedded path.
+ This change adds the +nodefaultrpath ld option to remove all library
+ paths that were specified with the -L option from the embedded path.
+
+ * libtool.m4 (archive_cmds): Add +nodefaultrpath ld option on
+ hppa64-*-hpux11*.
+
+2023-08-12 Olivier Hainque <hainque@adacore.com>
+
+ Generic configury support for shared libs on VxWorks
+ This change adds the configury bits to activate the build of
+ shared libs on VxWorks ports configured with --enable-shared,
+ for libraries variants where this is generally supported (rtp,
+ code model !large - currently not compatible with -fPIC).
+
+ Set lt_cv_deplibs_check_method in libtool.m4, so the build of
+ libraries know how to establish dependencies. This is useful in
+ configurations such as aarch64 where proper support of LSE relies
+ on accurate dependency information between libstdc++ and libgcc_s
+ to begin with.
+
+ * libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker
+ and friends for rtp !large. Assume the linker has the required
+ abilities and set lt_cv_deplibs_check_method.
+
+2023-08-12 Arsen Arsenović <arsen@aarsen.me>
+
+ toplevel: reconcile few divergences with GCC
+ * configure.ac: Reorder include.
+ <is_elf calculation>: Re-add haiku to ELF target list.
+
+2023-08-12 Max Filippov <jcmvbkbc@gmail.com>
+
+ gcc: xtensa: add data alignment properties to dynconfig
+ include/
+ * xtensa-dynconfig.h (xtensa_config_v4): New struct.
+ (XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION)
+ (XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW)
+ (XCHAL_UNALIGNED_STORE_HW, XTENSA_CONFIG_V4_ENTRY_LIST): New
+ definitions.
+ (XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v4 instance.
+ (XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V4_ENTRY_LIST.
+
+ gcc: xtensa: add XCHAL_HAVE_{CLAMPS, DEPBITS, EXCLUSIVE, XEA3} to dynconfig
+ include/
+ * xtensa-dynconfig.h (xtensa_config_v3): New struct.
+ (xtensa_get_config_v3): New declaration.
+ (XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS, XCHAL_HAVE_EXCLUSIVE)
+ (XCHAL_HAVE_XEA3, XTENSA_CONFIG_V3_ENTRY_LIST): New definitions.
+ (XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v3 instance.
+ (XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V3_ENTRY_LIST.
+
+2023-08-12 Jozef Lawrynowicz <jozefl@gcc.gnu.org>
+
+ MSP430: Add -fno-exceptions multilib
+ * config-ml.in (msp430-*-*): Support --disable-no-exceptions configure
+ flag.
+
+2023-08-12 Iain Buclaw <ibuclaw@gcc.gnu.org>
+
+ Add D front-end, libphobos library, and D2 testsuite.
+ * config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag
+ environment variables.
+
+ Cherry picked from GCC commit b4c522fabd0df7be08882d2207df8b2765026110
+
+2023-08-12 Jonathan Wakely <jwakely@redhat.com>
+
+ config-ml.in: Suppress output from multi-do recipes
+ The FIXME comments saying "Leave out until this is tested a bit more"
+ are from 1997. I think they've been sufficiently tested.
+
+ * config-ml.in (multi-do, multi-clean): Add @ to silence recipes.
+ Remove FIXME comments.
+
+2023-08-12 Sergei Trofimovich <siarheit@google.com>
+
+ mh-mingw: drop unused BOOT_CXXFLAGS variable
+ gcc's build system has BOOT_CFLAGS and various STAGE<N>_C{,XX}FLAGS
+ variables. BOOT_CXXFLAGS is not handled anywhere.
+
+ config/
+ * mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable.
+
+2023-08-12 Martin Storsjö <martin@martin.st>
+
+ mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables
+ This is similar to what was done in
+ eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
+ STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
+ BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
+ BOOT_CFLAGS).
+
+ 2021-04-09 Martin Storsjö <martin@martin.st>
+
+ config/
+ * mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
+ variables
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ configure: Allow host fragments to react to --enable-host-shared.
+ This makes the host_shared value available to host makefile
+ fragments.
+
+ It uses this to adjust Darwin's mdynamic-no-pic in the case that
+ shared host resources are required.
+
+
+ config/
+ * mh-darwin: Require a non-shared host configuration to
+ enable mdynamic-no-pic where that is supported.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ Darwin, config: Revise host config fragment.
+ There were two uses for the Darwin host config fragment:
+
+ The first is to arrange for targets that support mdynamic-no-pic
+ to be built with that enabled (since it makes a significant
+ difference to the compiler performance). We can be more specific
+ in the application of this, since it only applies to 32b hosts
+ plus powerpc64-darwin9.
+
+ The second was to work around a tool bug where -fno-PIE was not
+ propagated to the link stage. This second use is redundant,
+ since the buggy toolchain cannot bootstrap current GCC sources
+ anyway.
+
+ This makes the host fragment more specific and reduces the number
+ of toolchains for which it is included which reduces clutter in
+ configure lines.
+
+
+ config/
+ * mh-darwin: Make this specific to handling the
+ mdynamic-no-pic case.
+
+2023-08-12 LIU Hao <lh_mouse@126.com>
+
+ gcc: Add 'mcf' thread model support from mcfgthread
+ This patch adds the new thread model `mcf`, which implements mutexes
+ and condition variables with the mcfgthread library.
+
+ Source code for mcfgthread is available at <https://github.com/lhmouse/mcfgthread>.
+
+ config/
+ * gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
+ model
+
+2023-08-12 Andrew Pinski <apinski@marvell.com>
+
+ Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken
+ So the problem here is that now the lto-plugin requires NM that works
+ with LTO to work so we need to pass down NM just like we do for ranlib
+ and ar.
+
+ config/
+ * bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR.
+ * bootstrap-lto.mk: Likewise.
+
+2023-08-12 Martin Liska <mliska@suse.cz>
+
+ 32-bit PA-RISC with HP-UX: remove deprecated ports
+ * configure.ac: Drop GCC configury for hpux10
+ * configure: Likewise.
+ config/
+ * mh-pa-hpux10: Drop.
+
+2023-08-12 Gaius Mulley <gaiusmod2@gmail.com>
+
+ Merge modula-2 front end onto gcc.
+ This commit merges the devel/modula2 into master.
+ The libraries reside in libgm2, the compiler in gcc/m2
+ and the testsuite in gcc/testsuite/gm2.
+
+ * configure.ac (target_libraries): Add target-libgm2.
+ Add NCN_STRICT_CHECK_TARGET_TOOLS entry for gm2.
+ Add GCC_TARGET_TOOL entry for gm2. (compare_exclusions)
+ add gcc/m2/gm2-compiler/M2Version,
+ gcc/m2/gm2-compiler-boot/SYSTEM and gcc/m2/gm2version.
+ * Makefile.def (target_modules): Add libgm2. (flags_to_pass)
+ Add GM2_FOR_TARGET, GM2FLAGS_FOR_TARGET. (dependencies) Add
+ all-target-libgm2 and on=all-target-libatomic. (languages)
+ Add entry for language=m2 with gcc-check-target=check-m2
+ and lib-check-target=check-target-libgm2.
+ * Makefile.tpl (BUILD_EXPORTS): Add definition for GM2
+ and GM2FLAGS. (HOST_EXPORTS) Add definition for GM2.
+ (BASE_TARGET_EXPORTS) Add definition for GM2.
+ (GM2_FOR_BUILD) Defined. (GM2FLAGS) Defined.
+ (GM2_FOR_TARGET) Defined. (GM2FLAGS_FOR_TARGET) Defined.
+ (EXTRA_HOST_FLAGS) Defined. (POSTSTAGE1_FLAGS_TO_PASS)
+ Add GM2 and GM2_FOR_BUILD. (EXTRA_TARGET_FLAGS) Add
+ GM2 and GM2FLAGS. (EXTRA_GCC_FLAGS) Add GM2_FOR_TARGET.
+
+2023-08-12 Alexandre Oliva <oliva@adacore.com>
+
+ Add TFLAGS to gcc's GCC_FOR_TARGET
+ When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for
+ dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios. This
+ patch arranges for TFLAGS to be passed from the top level down to gcc
+ in GCC_FOR_TARGET in this case.
+
+ * Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET.
+ (EXTRA_GCC_FLAGS): Likewise.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ configure: Account CXXFLAGS in gcc-plugin.m4.
+ We now use a C++ compiler so that we need to process
+ CXXFLAGS as well as CFLAGS in the gcc-plugin config
+ fragment.
+
+
+ config/
+ * gcc-plugin.m4: Save and process CXXFLAGS.
+
+2023-08-12 David Seifert <soap@gentoo.org>
+
+ configure: use OBJDUMP determined by libtool [PR95648]
+ $ac_cv_prog_OBJDUMP contains the --host OBJDUMP that
+ libtool has inferred. Current config/gcc-plugin.m4 does
+ not respect the user's choice for OBJDUMP.
+
+ config/
+ * gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP.
+
+2023-08-12 Thomas Schwinge <thomas@codesourcery.com>
+
+ Remove support for Intel MIC offloading
+ ... after its deprecation in GCC 12.
+
+ * Makefile.def: Remove module 'liboffloadmic'.
+ * configure.ac: Remove 'liboffloadmic' handling.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ configure, Darwin: Ensure overrides to host-pie are passed to gcc configure.
+ The latest versions of Darwin on the Aarch64 platform mandate PIE executables.
+ On x86_64 it remains optional, but produces tool warnings after Darwin20, so
+ we default to PIE executables there too.
+
+ All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force
+ host_shared on (we issue a diagnostic if the user tries to configure them
+ non-shared).
+
+ However, this also means we cannot test the host_shared setting independently
+ of the host_pie setting so that the logic for setting PICFLAG must be amended
+ for Darwin.
+
+ For Darwin versions required to have PIE executables, in the event that the
+ user tries to configure these as --disable-host-pie, we issue a warning and
+ override the setting. These versions must also switch host_pie on even if it
+ is not given in the configure line. To cater for this we pass the current
+ value of host_pie, as determined by top-level configure, to the GCC configure.
+
+
+ * Makefile.def: Pass the enable-host-pie value to GCC configure.
+ * configure.ac: Adjust the logic for shared and PIE host flags to
+ ensure that PIE is passed for hosts that require it.
+
+2023-08-12 Peter Foley <pefoley2@pefoley.com>
+
+ configure: Only create serdep.tmp if needed
+ There's no reason to create this file if none of the serial configure
+ options are passed.
+
+ * configure.ac: Only create serdep.tmp if needed
+
+2023-08-12 Marek Polacek <polacek@redhat.com>
+
+ configure: Implement --enable-host-pie
+ This patch implements the --enable-host-pie configure option which
+ makes the compiler executables PIE. This can be used to enhance
+ protection against ROP attacks, and can be viewed as part of a wider
+ trend to harden binaries.
+
+ Co-Authored by: Iain Sandoe <iain@sandoe.co.uk>
+
+ * configure.ac (--enable-host-pie): New check. Set PICFLAG after this
+ check.
+
+ intl/
+ * configure.ac (--enable-host-shared): Don't set PICFLAG here.
+ (--enable-host-pie): New check. Set PICFLAG after this check.
+
+ libdecnumber/
+ * configure.ac (--enable-host-shared): Don't set PICFLAG here.
+ (--enable-host-pie): New check. Set PICFLAG after this check.
+
+ zlib/
+ * configure.ac (--enable-host-shared): Don't set PICFLAG here.
+ (--enable-host-pie): New check. Set PICFLAG after this check.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ configure: When host-shared, pass --with-pic to in-tree lib configs.
+ If we are building PIC/PIE host executables, and we are building dependent
+ libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code.
+
+
+ * Makefile.def: Pass host_libs_picflag to host dependent library
+ configures.
+ * configure.ac (host_libs_picflag): New configure variable set to
+ '--with-pic' when building 'host_shared'.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ configure: Do not build the ununsed libffi shared library.
+ We do not use the shared libffi libraray, nor do we install it.
+ However, on at least Darwin, the shared version will be picked
+ up for testing, so it is preferrable not to build it.
+
+
+ * Makefile.def: Do not build shared libffi.
+
+2023-08-12 Iain Sandoe <iain@sandoe.co.uk>
+
+ Darwin : Update libtool and dependencies for Darwin20 [PR97865]
+ The change in major version (and the increment from Darwin19 to 20)
+ caused libtool tests to fail which resulted in incorrect build settings
+ for shared libraries.
+
+ PR target/97865
+ * libtool.m4: Update handling of Darwin platform link flags
+ for Darwin20.
+
+2023-08-12 Xi Ruoyao <xry111@xry111.site>
+
+ LoongArch: implement count_{leading,trailing}_zeros
+ LoongArch always support clz and ctz instructions, so we can always use
+ __builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves
+ the code of libgcc, and also benefits Glibc once we merge longlong.h
+ there.
+
+ Bootstrapped and regtested on loongarch64-linux-gnu.
+
+ include/
+ * longlong.h [__loongarch__] (count_leading_zeros): Define.
+ [__loongarch__] (count_trailing_zeros): Likewise.
+ [__loongarch__] (COUNT_LEADING_ZEROS_0): Likewise.
+
+2023-08-12 Meghan Denny <hello@nektro.net>
+
+ Updated constants from <https://dwarfstd.org/Languages.php>
+ include/
+ * dwarf2.h: Update with additional languages from dwarf
+ standard.
+
+2023-08-12 Jason Merrill <jason@redhat.com>
+
+ c++: source position of lambda captures [PR84471]
+ include/
+ * ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __.
+
+2023-08-12 Lulu Cheng <chenglulu@loongson.cn>
+
+ Libvtv: Add loongarch support.
+ The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB,
+ but only 16KiB pages are supported for now.
+
+ Co-Authored-By: qijingwen <qijingwen@loongson.cn>
+
+ include/
+ * vtv-change-permission.h (defined): Determines whether the macro
+ __loongarch_lp64 is defined
+ (VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.
+
+2023-08-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-11 Carl Love <cel@us.ibm.com>
+
+ gdb.ada/mi_var_access.exp
+ The NUMCHILD value for the "A_String_Access" test differs for X86 and
+ PowerPC. The patch substitutes $decimal instead of "1" to match the value
+ of NUMCHILD.
+
+ The test "-var-update A_String_Access" generates different output depending
+ on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true,
+ the strings "new_type" and "new_num_children" are printed along with their
+ values.
+
+ The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
+ produces the output:
+
+ Expecting: ^(-var-update A_String_Access[
+ ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
+ ]+[(]gdb[)]
+ [ ]*)
+ -var-update A_String_Access
+ ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
+ (gdb)
+ FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)
+
+ The patch adds a second possible result string for the test
+ $re_varobj_update_result_type to match the case when type_changed is true.
+
+ Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
+ is true on PowerPC and false on X86-64.
+
+ Fixes 2 failures on PowerPC.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-11 Tom Tromey <tromey@adacore.com>
+
+ Fix Python documentation for range type fields
+ GDB's Python documentation claims that range types have two fields,
+ but this is not true, and attempts to access them hit this error:
+
+ "Type is not a structure, union, enum, or function type."
+
+ This patch fixes the documentation.
+
+2023-08-11 Tom Tromey <tromey@adacore.com>
+
+ Test GNAT encodings in arr_acc_idx_w_gap.exp
+ While working on a GNAT bug, I wanted to also test
+ arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is
+ ready, I plan to add a new case here.
+
+ Tested on x86-64 Fedora 36. I am checking this in.
+
+2023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Reflect actual range of vlen for hashing
+ Before actual vlen handling, fix the riscv_gdbarch_features hashing
+ function based on the actual valid range of vlen. In bytes, vlen is 0,
+ or 4 <= xlen <= 8192.
+
+ RISC-V: Add reference to Zve32*
+ Before actual vlen handling, this commit fixes its description to allow vlen
+ less than 16 (but 4 or greater), to support vector subset extensions for
+ embedded environment ('Zve32*').
+
+2023-08-11 Alan Modra <amodra@gmail.com>
+
+ gdb: warn unused result for bfd IO functions
+ This fixes the compilation warnings introduced by my bfdio.c patch.
+
+ The removed bfd_seeks in coff_symfile_read date back to 1994, commit
+ 7f4c859520, prior to which the file used stdio rather than bfd to read
+ symbols. Since it now uses bfd to read the file there should be no
+ need to synchronise to bfd's idea of the file position. I also fixed
+ a potential uninitialised memory access.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-08-11 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix AIX build break.
+ In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same.
+
+ This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result.
+
+2023-08-11 Jan Beulich <jbeulich@suse.com>
+
+ gas: purge md_elf_section_word()
+ It's not documented anyway, and having it makes no sense anymore with
+ obj_elf_section_word() now being TC_SPARC-only. In any event the x86
+ backing function was dead code.
+
+2023-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: pack CPU flags in opcode table
+ The table constantly growing in two dimensions (number of table entries
+ times number of ISA extension flags) doesn't scale very well. Use a more
+ compact representation: Only identifiers which need to combine with
+ other identifiers retain individual flag bits. All others are combined
+ into an enum, with a new helper added to transform the table entries
+ into the original i386_cpu_flags layout. This way the table in the final
+ binary shrinks by almost a third (the generated source code shrinks by
+ about half), and isn't likely to grow again in that dimension any time
+ soon.
+
+ While moving the 3DNow! fields, drop the stray inner 'a' from their
+ names.
+
+2023-08-11 Alan Modra <amodra@gmail.com>
+
+ warn unused result for bfd IO functions
+ This patch fixes all the warnings I found in bfd, binutils and ld,
+ plus some bitrotted COFF_GO32 code that tried to allocate -168ul
+ bytes. When the malloc fail was reported these testsuite fails
+ resulted:
+
+ i386-go32 +FAIL: go32 stub
+ i386-go32 +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp.
+ i386-go32 +ERROR: couldn't open "tmpdir/go32stub": no such file or directory
+ i386-go32 +FAIL: ld-scripts/sane1
+ i386-go32 +FAIL: ld-scripts/assign-loc
+ i386-go32 +FAIL: ld-scripts/pr18963
+
+ This does result in some warnings in gdb which are fixed in a followup
+ patch.
+
+ bfd/
+ * bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT.
+ (bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise.
+ * bfd-in2.h: Regenerate.
+ * coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write
+ return value.
+ (xcoff_generate_rtinit): Likewise. Also free data_buffer and
+ string_table before returning.
+ * coff64-rs6000.c (xcoff64_generate_rtinit): Likewise.
+ * coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek
+ return value.
+ * coffcode.h (coff_apply_checksum): Don't ignore bfd_write return.
+ (coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc.
+ Fix bitrotted code to look for first section with non-zero filepos.
+ * elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore
+ bfd_seek or bfd_write return values.
+ * pef.c (bfd_pef_scan_section): Likewise.
+ (bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise.
+ * vms-misc.c (_bfd_vms_output_end): Likewise. Return status.
+ * vms.h (_bfd_vms_output_end): Update prototype.
+ * vms-alpha.c: Pass _bfd_vms_output_end status up call chains.
+ * wasm-module.c (wasm_compute_custom_section_file_position): Don't
+ ignore bfd_seek or bfd_write return values.
+ (wasm_compute_section_file_positions): Likewise.
+ * xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value.
+ (bfd_sym_read_name_table): Likewise.
+ binutils/
+ * ar.c (print_contents, extract_file): Don't ignore bfd_seek
+ return value.
+ ld/
+ * pdb.c (create_section_contrib_substream): Don't ignore bfd_seek
+ return value.
+ (create_section_header_stream): Likewise.
+ * pe-dll.c (pe_get16, pe_get32): Add fail param to return results
+ from bfd_seek and bfd_read.
+ (pe_implied_import_dll): Handle these fails, and other bfd_seek
+ and bfd_read return values.
+
+2023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix opcode entries of "vmsge{,u}.vx"
+ Their check_func should be "match_never", not "match_opcode". The reasons
+ this error did not cause any disassembler errors are:
+
+ 1. The problem will not reproduce if "no-aliases" is specified
+ (because macro instructions are handled as aliases).
+ 2. If not, all affected compressed instructions or their aliases
+ precede before "vmsge{,u}.vx" macro instructions.
+
+ However, it'll easily break if we reorder opcode entries. This commit
+ fixes this issue before the *accident* occurs.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Make sure that we never match to
+ vmsge{,u}.vx instructions unless specified in the assembler.
+
+2023-08-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove support for non-existing 'Zve32d'
+ Since this "extension" does not exist (on the other hand, 'Zve64d' exists)
+ and it's not useful if we keep it (as other code portions just ignore
+ "zve32d"), this commit just removes it.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d'
+ extension from the list.
+
+2023-08-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix off-by-one error in cooked_indexer::recurse
+ Test-case gdb.dwarf2/pr13961.exp contains:
+ ...
+ <1><25>: Abbrev Number: 8 (DW_TAG_class_type)
+ <26> DW_AT_specification: <0x2a>
+ <1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
+ <2b> DW_AT_name : foo
+ <2f> DW_AT_byte_size : 4
+ <30> DW_AT_decl_file : 1
+ <31> DW_AT_decl_line : 1
+ <32> DW_AT_sibling : <0x44>
+ ...
+
+ The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
+ DIE indexing in the cooked_index, by adding it to m_deferred_entries.
+
+ The resulting cooked index entries are:
+ ...
+ [25] ((cooked_index_entry *) 0x333b5d0)
+ name: foo
+ canonical: foo
+ qualified: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x2a
+ parent: ((cooked_index_entry *) 0)
+
+ [26] ((cooked_index_entry *) 0x333b630)
+ name: foo
+ canonical: foo
+ qualified: foo::foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x25
+ parent: ((cooked_index_entry *) 0x333b5d0) [foo]
+ ...
+
+ Notice that 0x2a is the parent of 0x25, and that this is why the qualified
+ name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".
+
+ The parent is set here in cooked_indexer::make_index:
+ ...
+ for (const auto &entry : m_deferred_entries)
+ {
+ void *obj = m_die_range_map.find (entry.spec_offset);
+ cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
+ m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
+ entry.name, parent, m_per_cu);
+ }
+ ...
+ and AFAICT, we store in m_die_range_map the parent of the respective
+ spec_offset DIE (though that's not clear from the comment describing it).
+
+ So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
+ m_die_range_map.find (0x2a) == 0x2a.
+
+ This is an off-by-one error, fixed in cooked_indexer::recurse by:
+ ...
+ - CORE_ADDR start = form_addr (parent_entry->die_offset,
+ + CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
+ ...
+ which gives us:
+ ...
+ [12] ((cooked_index_entry *) 0x41e21f0)
+ name: foo
+ canonical: foo
+ qualified: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x25
+ parent: ((cooked_index_entry *) 0)
+
+ [13] ((cooked_index_entry *) 0x41e2190)
+ name: foo
+ canonical: foo
+ qualified: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x2a
+ parent: ((cooked_index_entry *) 0)
+ ...
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30739
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739
+
+2023-08-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Dump qualified name of cooked_index_entry
+ When doing "maint print objfiles" for the exec of test-case
+ gdb.dwarf2/pr13961.exp, we get:
+ ...
+ [25] ((cooked_index_entry *) 0x37b25d0)
+ name: foo
+ canonical: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x2a
+ parent: ((cooked_index_entry *) 0)
+
+ [26] ((cooked_index_entry *) 0x37b2630)
+ name: foo
+ canonical: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x25
+ parent: ((cooked_index_entry *) 0x37b25d0) [foo]
+ ...
+
+ By following the parent links in the text, we can conclude that the qualified
+ name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).
+
+ But it's not evident, and also hard to verify in a test-case.
+
+ Add dumping of the qualified name, such that we have:
+ ...
+ [25] ((cooked_index_entry *) 0x333b5d0)
+ name: foo
+ canonical: foo
+ qualified: foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x2a
+ parent: ((cooked_index_entry *) 0)
+
+ [26] ((cooked_index_entry *) 0x333b630)
+ name: foo
+ canonical: foo
+ qualified: foo::foo
+ DWARF tag: DW_TAG_class_type
+ flags: 0x0 []
+ DIE offset: 0x25
+ parent: ((cooked_index_entry *) 0x333b5d0) [foo]
+ ...
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-10 Carl Love <cel@us.ibm.com>
+
+ Fix gdb.ada/O2_float_param.exp for PowerPC
+ The frame command on Power pc prints the address in hex between the
+ #0 and in calle.increment. For example
+
+ (gdb) frame
+ #0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
+ at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
+ 19 procedure Increment (Val : in out Float; Msg: String) is
+
+ The printing of the address for the frame is done by function
+ print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame,
+ function frame_show_address returns true and print_frame prints the
+ address. Currently, SAL.IS is false on PowerPC and true on X86-64.
+
+ Update the set re string to accept the hex address if it exits.
+
+ Fixes two failures on PowerPC.
+
+ Patch tested on Power10 with no new regressions.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-10 Tom Tromey <tromey@adacore.com>
+
+ Change py-thread-exited.exp to work with gdbserver
+ gdbserver does not notify gdb of new threads when they are created.
+ I'm not sure if this is documented anywhere, but it is mentioned on
+ this page:
+
+ https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
+
+ Search for "Finding new threads in the inferior".
+
+ This behavior is a bit unfortunate -- I would think that it would be
+ better to arrange for such notification if something on the gdb side
+ is interested.
+
+ Meanwhile, this patch fixes py-thread-exited.exp to work around this
+ problem.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677
+
+2023-08-10 Tom Tromey <tom@tromey.com>
+
+ Pass unique_ptr to add_thread_with_info
+ This changes add_thread_with_info to accept a unique_ptr, making it
+ clear that it takes ownership of the passed-in pointer.
+
+ I can't test the AIX or Darwin changes, but I think they are
+ relatively obvious.
+
+2023-08-10 Richard Ball <richard.ball@arm.com>
+
+ aarch64: Enable Cortex-A520 CPU
+ This patch adds support for the Cortex-A520 CPU to gas.
+
+ No regressions on aarch64-none-elf.
+
+ gas/ChangeLog:
+
+ * NEWS: Update docs.
+ * config/tc-aarch64.c: Add Cortex-A520.
+ * doc/c-aarch64.texi: Update docs.
+
+2023-08-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with cc-with-gnu-debuglink
+ When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
+ cc-with-gnu-debuglink, I run into:
+ ...
+ (gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
+ maint print symbols -objfile enqueued-cu-base-addr^M
+ (gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
+ ...
+
+ The problem is that the CU we're trying to print is in objfile
+ enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.
+
+ Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".
+
+ Tested on x86_64-linux.
+
+2023-08-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp
+ I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
+ cc-with-debug-names, and ran into:
+ ...
+ FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
+ FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
+ ...
+
+ The first FAIL is a known issue, PR symtab/29572.
+
+ The following FAIL is a consequence of the first FAIL, so require for the
+ second test that the first test passes.
+
+ Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
+
+2023-08-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix assertion in write_debug_names
+ When running test-case gdb.dwarf2/pr13961.exp with target-board
+ cc-with-debug-names, I run into:
+ ...
+ Running gdb.dwarf2/pr13961.exp ...
+ gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \
+ write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed.
+ ...
+
+ This is a regression since commit 542a33e348a ("Only use the per-BFD object to
+ write a DWARF index"), which did:
+ ...
+ - gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ());
+ + gdb_assert (counter == per_bfd->all_units.size ());
+ ...
+
+ Fix this by reverting to using all_comp_units:
+ ...
+ gdb_assert (counter == per_bfd->all_comp_units.size ());
+ ...
+
+ Tested on x86_64-linux, using target boards unix and cc-with-debug-names.
+
+ PR symtab/30741
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30741
+
+2023-08-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-09 David Faust <david.faust@oracle.com>
+
+ bpf: use w regs in 32-bit non-fetch atomic pseudo-c
+ The 32-bit non-fetching atomic instructions treat the source register as
+ 32-bits, which means in the pseudo-c syntax the "w" registers should be
+ used rather than the "r" registers.
+
+ opcodes/
+
+ * bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32
+ and AXOR32 pseudo-c dialect asm templates.
+
+ gas/
+
+ * testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg
+ in non-fetching 32-bit atomic instructions.
+ * testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
+
+2023-08-09 Mihails Strasuns <mihails.strasuns@intel.com>
+
+ gdb, breakpoint: add breakpoint location debugging logs
+ Add new commands:
+
+ set debug breakpoint on|off
+ show debug breakpoint
+
+ This patch introduces new debugging information that prints
+ breakpoint location insertion and removal flow.
+
+ The debug output looks like:
+ ~~~
+ (gdb) set debug breakpoint on
+ (gdb) disassemble main
+ Dump of assembler code for function main:
+ 0x0000555555555129 <+0>: endbr64
+ 0x000055555555512d <+4>: push %rbp
+ 0x000055555555512e <+5>: mov %rsp,%rbp
+ => 0x0000555555555131 <+8>: mov $0x0,%eax
+ 0x0000555555555136 <+13>: pop %rbp
+ 0x0000555555555137 <+14>: ret
+ End of assembler dump.
+ (gdb) break *0x0000555555555137
+ Breakpoint 2 at 0x555555555137: file main.c, line 4.
+ [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
+ (gdb) c
+ Continuing.
+ [breakpoint] update_global_location_list: insert_mode = UGLL_INSERT
+ [breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4
+ [breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5
+ [breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e
+ [breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4
+ [breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove
+ [breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove
+ [breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove
+ [breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove
+
+ Breakpoint 2, 0x0000555555555137 in main () at main.c:4
+ 4 }
+ ~~~
+
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-08-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-09 Alan Modra <amodra@gmail.com>
+
+ Rename bfd_bread and bfd_bwrite
+ These were renamed from bfd_read and bfd_write back in 2001 when they
+ lost an unnecessary parameter. Rename them back, and get rid of a few
+ casts that are only needed without prototyped functions (K&R C).
+
+ Add ld makefile dependencies
+ * Makefile.am (EXTRA_ld_new_SOURCES): Add pep-dll-aarch64.c
+ and pep-dll-x86_64.c.
+ * Makefile.in: Regenerate.
+
+2023-08-09 Alan Modra <amodra@gmail.com>
+
+ PR30724, cygwin ld performance regression since 014a602b86
+ According to the reporter of this bug the newlib fseek implementation
+ is likely slowed down by locking and fflush, only attempting to
+ optimise seeks when the file is opened read-only. Thus when writing
+ the output we get a dramatic slowdown due to commit 014a602b86.
+
+ PR 30724
+ * bfd.c (enum bfd_last_io): New.
+ (struct bfd): Add last_io field.
+ * bfd-in2.h: Regenerate.
+ * bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is
+ opposite direction.
+ (bfd_seek): Reinstate optimisation for seek to same position.
+
+2023-08-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Use move capture in gdb_demangle
+ Use move capture in gdb_demangle when compiling for c++14 or higher, to save a
+ std::string copy.
+
+ Tested on x86_64-linux.
+
+ Reported-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-08 Sam James <sam@gentoo.org>
+
+ ld: Fix retain7a.d XFAIL/notarget entry for hppa
+ PR 30733
+ * ld/testsuite/ld-elf/retain7a.d: Fix XFAIL entry for hppa to match
+ hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.
+
+ ld: Fix relocatable.d XFAIL/notarget entry for hppa
+ PR 30734
+ * ld/testsuite/ld-elf/relocatable.d: Fix notarget entry for hppa to match
+ hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.
+
+2023-08-08 Guinevere Larsen <blarsen@redhat.com>
+
+ Update my name in maintainers file
+
+2023-08-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Guard against killing unrelated processes in amd64-disp-step.exp
+ When testing current gdb trunk on Solaris/amd64, the whole session was
+ reliably terminated by make check. I could trace this to the following
+ entry in gdb.arch/amd64-disp-step/gdb.log:
+
+ FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get
+ inferior pid
+ Executing on target: kill -ALRM -1 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -ALRM -1
+
+ If $inferior_pid doesn't refer to a single process for some reason, this
+ kill would terminate either a process group or the whole session.
+
+ This patch avoids this by ensuring that the pid arg is positive.
+
+ Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build breaker with -std=c++11
+ When building with -std=c++11 I run into:
+ ...
+ gdb/dwarf2/cooked-index.c: In member function \
+ ‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’:
+ gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \
+ available with -std=c++14 or -std=gnu++14 [-Werror]
+ ctx = std::move (ctx)] ()
+ ^~~
+ ...
+
+ Fix this by capturing a copy instead when using -std=c++11:
+ ...
+ = gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] ()
+ ...
+
+ Tested by building with and without -stdc=++11 on x86_64-linux.
+
+ Reported-By: Tom Tromey <tom@tromey.com>
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-08 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Update ratified 'Ztso' extension version
+ Because the 'Ztso' extension is now ratified, it has a version number of 1.0
+ (not 0.1). This commit updates the number.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
+ number of the 'Ztso' extension since it's ratified.
+
+2023-08-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30700 tmpdir/gp-collect-app_F test fails
+ gprofng/ChangeLog
+ 2023-08-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30700
+ * testsuite/gprofng.display/gp-collect-app_F.exp: Fix -name argument
+ for sub-experiment filtering.
+
+2023-08-07 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: move comment describing rules for riscv_opcodes[]
+ It makes little sense to have this comment meanwhile over a hundred
+ lines ahead of the array. In fact until spotting the comment, I was
+ wondering why those pretty important aspects aren't spelled out
+ anywhere.
+
+2023-08-07 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb/fortran: Align intrinsic/variable precedence
+ Fortran allows variables and function to be named after language defined
+ intrinsics as they are not reserved keywords. For example, the abs maths
+ intrinsic can be hidden by a user declaring a variable called abs.
+
+ The behavior before this patch was to favour the intrinsic, which meant
+ that any variables named, for example "allocated", could not be
+ inspected by GDB.
+
+ This patch inverts this priority to bring GDB's behaviour closer to the
+ Fortran language, where the user defined symbol can hide the intrinsic.
+
+ Special care was need to prevent any C symbols from overriding either
+ Fortran intrinsics or user defined variables. This was observed to be
+ the case when GDB has access to symbols for abs from libm. This was
+ solved by only allowing symbols not marked with language_fortran to be
+ overridden.
+
+ In total this brings the order of precedence to the following (highest
+ first):
+
+ 1. User defined Fortran variable or function.
+ 2. Fortran intrinsic.
+ 3. Symbols from languages other than Fortran.
+
+ The sizeof intrinsic is now case insensitive. This is closer to the
+ Fortran language. I believe this change is safe enough as it increases
+ the acceptance of the grammar, rather than restricts it. I.e. it should
+ not break any existing scripts which rely on it. Unless of course they
+ rely on SIZEOF being rejected.
+
+ GDB built with GCC 13.
+
+ No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
+ LLVM, NVHPC; Platforms: x86_64, aarch64.
+
+ Existing tests in gdb.fortran cover the invocation of intrinsics
+ including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Find main language without symtab expansion
+ When loading an executable using "file a.out", the language is set according
+ to a.out, which can involve looking up the language of symbol "main", which
+ will cause the symtab expansion for the containing CU.
+
+ Expansion of lto debug info can be slow, so in commit d3214198119 ("[gdb] Use
+ partial symbol table to find language for main") a feature was added to avoid
+ the symtab expansion.
+
+ This feature stopped working after commit 7f4307436fd ("Fix "start" for D,
+ Rust, etc").
+
+ [ The commit addresses problems related to command start, which requires finding
+ the main function:
+ - for language D, "main" was found instead of "D main", and
+ - for Rust, the correct function was found, but attributed the wrong name
+ (not fully qualified). ]
+
+ Reimplement the feature by adding
+ cooked_index_functions::lookup_global_symbol_language.
+
+ Tested on x86_64-linux.
+
+ PR symtab/30661
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661
+
+2023-08-05 David Carew <david@dcarew.com>
+
+ as: Fix typo in manual
+ The -D flag should enable "debugging"
+
+2023-08-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-04 Tom Tromey <tromey@adacore.com>
+
+ Reindent recursive_dump_type
+ I noticed that a 'switch' in recursive_dump_type was incorrect
+ indented. This patch fixes the problem. Tested by rebuilding.
+
+2023-08-04 Tom Tromey <tom@tromey.com>
+
+ Consolidate calls to bfd_set_cacheable
+ I noticed that some spots in gdb call bfd_set_cacheable after opening
+ a BFD.
+
+ The BFD file cache is a bit odd. BFDs that are opened locally are
+ unconditionally registered with the cache, and their underlying file
+ descriptor will always be closed when bfd_cache_close_all is called.
+ However, only "cacheable" BFDs will be eligible for reopening when
+ needed -- and by default BFD decides that if a file descriptor is
+ passed in, then it should not be cacheable. If a non-cacheable BFD's
+ file descriptor is closed, there is no offical way to reopen it.
+
+ gdb needs to call bfd_cache_close_all, because some systems cannot
+ start an executable when it has an open file descriptor referencing
+ it.
+
+ However, gdb also will sometimes passes an open file descriptor to the
+ various BFD open functions. And, due to lazy DWARF reading, gdb may
+ also need to reopen these BFDs.
+
+ Rather than having all the callers figure out when exactly to set the
+ cacheable flag, I think it makes sense to consolidate this logic into
+ the gdb_bfd.c wrapper functions. It is ok to do this because gdb
+ always passes a filename to these open functions, so reopening should
+ work ok.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-04 Tom Tromey <tromey@adacore.com>
+
+ Remove extra '.' from error message
+ A local gdb test failed with this error message:
+
+ Remote communication error. Target disconnected.: Arg list too long.
+
+ The ".:" seemed weird to me. This patch removes the ".".
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-08-04 Tom Tromey <tromey@adacore.com>
+
+ Fix incorrect class name in free_objfile documentation
+ The documentation for the Python free_objfile event registry uses the
+ wrong class name. This patch fixes it. I'm checking this in as
+ obvious.
+
+2023-08-04 Nick Clifton <nickc@redhat.com>
+
+ Fix potential infinite loop in bfd_cache_close_all.
+ PR 15545 * cache.c (bfd_cache_close_all): Extend description to note that all files will be closed, even those that are not cacheable. Add code to prevent a possible infinite loop.
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Extend gdb.base/index-cache.exp further
+ Add lookup of a non-existing symbol to test-case gdb.base/index-cache.exp.
+
+ This serves as regression test for PR symtab/30718.
+
+ PR symtab/30718
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Move "maint wait-for-index-cache" ALAP in gdb.base/index-cache.exp
+ In test-case gdb.base/index-cache.exp proc run_test_with_flags contains:
+ ...
+ clean_restart ${testfile}
+
+ # The tests generally want to check the cache, so make sure it
+ # has completed its work.
+ gdb_test_no_output "maintenance wait-for-index-cache"
+ ...
+
+ This however hides data races between:
+ - index-cache writing (due to file $exec), and
+ - symbol lookups (due to subsequent ptype commands).
+
+ Fix this by:
+ - moving the "maintenance wait-for-index-cache" to proc check_cache_stats, and
+ - moving all calls to proc check_cache_stats ALAP.
+
+ Tested on x86_64-linux.
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on dwarf2_per_cu_data::{files_read,is_debug_types}
+ With gdb build with -fsanitize=thread, and the exec from test-case
+ gdb.base/index-cache.exp, I run into:
+ ...
+ $ rm -f ~/.cache/gdb/*; \
+ gdb -q -batch -iex "set index-cache enabled on" index-cache \
+ -ex "print foobar"
+ ...
+ WARNING: ThreadSanitizer: data race (pid=25018)
+ Write of size 1 at 0x7b200000410d by main thread:
+ #0 dw2_get_file_names_reader gdb/dwarf2/read.c:2033 (gdb+0x7ab023)
+ #1 dw2_get_file_names gdb/dwarf2/read.c:2130 (gdb+0x7ab023)
+ #2 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3105 (gdb+0x7ac6e9)
+ #3 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d040f)
+ #4 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5b6e)
+ #5 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc441d)
+ #6 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc4522)
+ #7 classify_name gdb/c-exp.y:3083 (gdb+0x61afec)
+ #8 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13)
+ #9 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e)
+ #10 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864)
+ #11 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x977245)
+ #12 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10b1b)
+ #13 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb1112e)
+ #14 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf8c)
+ #15 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4caaa)
+ #16 print_command gdb/printcmd.c:1468 (gdb+0xb4cdda)
+ #17 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078)
+ #18 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53)
+ #19 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a7ea)
+ #20 catch_command_errors gdb/main.c:518 (gdb+0xa183fd)
+ #21 execute_cmdargs gdb/main.c:617 (gdb+0xa185bf)
+ #22 captured_main_1 gdb/main.c:1289 (gdb+0xa1aad8)
+ #23 captured_main gdb/main.c:1310 (gdb+0xa1b9da)
+ #24 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b9da)
+ #25 main gdb/gdb.c:39 (gdb+0x42506a)
+
+ Previous read of size 1 at 0x7b200000410d by thread T2:
+ #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30)
+ #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803)
+ #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36)
+ #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d)
+ #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d)
+ #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d)
+ #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c)
+ #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db)
+ #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db)
+ #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db)
+ #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db)
+ #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db)
+ #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954)
+ #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954)
+ #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a)
+ #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a)
+ #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a)
+ #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a)
+ #19 pthread_once <null> (libtsan.so.0+0x4457c)
+ #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b)
+ #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b)
+ #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174570d)
+ #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174570d)
+ #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174570d)
+ #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174570d)
+ #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x17480c0)
+ #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x17480c0)
+ #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x17480c0)
+ #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x17480c0)
+ #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x17480c0)
+ #31 <null> <null> (libstdc++.so.6+0xdcac2)
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:2033 in dw2_get_file_names_reader
+ ...
+
+ The race happens when issuing the "file $exec" command.
+
+ The race is between:
+ - a worker thread writing the index cache, and in the process reading
+ dwarf2_per_cu_data::is_debug_type, and
+ - the main thread writing to dwarf2_per_cu_data::files_read.
+
+ The two bitfields dwarf2_per_cu_data::files_read and
+ dwarf2_per_cu_data::is_debug_type share the same bitfield container.
+
+ Fix this by making dwarf2_per_cu_data::files_read a packed<bool, 1>.
+
+ Tested on x86_64-linux.
+
+ PR symtab/30718
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on dwarf2_per_cu_data::{mark,is_debug_types}
+ With gdb build with -fsanitize=thread, and the exec from test-case
+ gdb.base/index-cache.exp, I run into:
+ ...
+ $ rm -f ~/.cache/gdb/*; \
+ gdb -q -batch -iex "set index-cache enabled on" index-cache \
+ -ex "print foobar"
+ ...
+ WARNING: ThreadSanitizer: data race (pid=23970)
+ Write of size 1 at 0x7b200000410d by main thread:
+ #0 dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) gdb/dwarf2/read.c:3077 (gdb+0x7ac54e)
+ #1 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16812 (gdb+0x7d039f)
+ #2 objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) gdb/symfile-debug.c:219 (gdb+0xda5aee)
+ #3 iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) gdb/symtab.c:648 (gdb+0xdc439d)
+ #4 lookup_symtab(char const*) gdb/symtab.c:662 (gdb+0xdc44a2)
+ #5 classify_name gdb/c-exp.y:3083 (gdb+0x61afec)
+ #6 c_yylex gdb/c-exp.y:3251 (gdb+0x61dd13)
+ #7 c_yyparse() build/gdb/c-exp.c.tmp:1988 (gdb+0x61f07e)
+ #8 c_parse(parser_state*) gdb/c-exp.y:3417 (gdb+0x62d864)
+ #9 language_defn::parser(parser_state*) const gdb/language.c:598 (gdb+0x9771c5)
+ #10 parse_exp_in_context gdb/parse.c:414 (gdb+0xb10a9b)
+ #11 parse_expression(char const*, innermost_block_tracker*, enum_flags<parser_flag>) gdb/parse.c:462 (gdb+0xb110ae)
+ #12 process_print_command_args gdb/printcmd.c:1321 (gdb+0xb4bf0c)
+ #13 print_command_1 gdb/printcmd.c:1335 (gdb+0xb4ca2a)
+ #14 print_command gdb/printcmd.c:1468 (gdb+0xb4cd5a)
+ #15 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x65b078)
+ #16 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x65ed53)
+ #17 execute_command(char const*, int) gdb/top.c:575 (gdb+0xe3a76a)
+ #18 catch_command_errors gdb/main.c:518 (gdb+0xa1837d)
+ #19 execute_cmdargs gdb/main.c:617 (gdb+0xa1853f)
+ #20 captured_main_1 gdb/main.c:1289 (gdb+0xa1aa58)
+ #21 captured_main gdb/main.c:1310 (gdb+0xa1b95a)
+ #22 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xa1b95a)
+ #23 main gdb/gdb.c:39 (gdb+0x42506a)
+
+ Previous read of size 1 at 0x7b200000410d by thread T1:
+ #0 write_gdbindex gdb/dwarf2/index-write.c:1214 (gdb+0x75bb30)
+ #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1469 (gdb+0x75f803)
+ #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x755a36)
+ #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:642 (gdb+0x71c96d)
+ #4 operator() gdb/dwarf2/cooked-index.c:471 (gdb+0x71c96d)
+ #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x71c96d)
+ #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x72a57c)
+ #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x72a5db)
+ #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72a5db)
+ #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x72a5db)
+ #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x72a5db)
+ #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x72a5db)
+ #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x724954)
+ #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x724954)
+ #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x72434a)
+ #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x72434a)
+ #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x72434a)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x72434a)
+ #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x72434a)
+ #19 pthread_once <null> (libtsan.so.0+0x4457c)
+ #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72532b)
+ #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x72532b)
+ #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x174568d)
+ #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x174568d)
+ #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x174568d)
+ #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x174568d)
+ #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1748040)
+ #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1748040)
+ #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1748040)
+ #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1748040)
+ #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1748040)
+ #31 <null> <null> (libstdc++.so.6+0xdcac2)
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:3077 in dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>)
+ ...
+
+ The race happens when issuing the "file $exec" command.
+
+ The race is between:
+ - a worker thread writing the index cache, and in the process reading
+ dwarf2_per_cu_data::is_debug_type, and
+ - the main thread writing to dwarf2_per_cu_data::mark.
+
+ The two bitfields dwarf2_per_cu_data::mark and
+ dwarf2_per_cu_data::is_debug_type share the same bitfield container.
+
+ Fix this by making dwarf2_per_cu_data::mark a packed<unsigned int, 1>.
+
+ Tested on x86_64-linux.
+
+ PR symtab/30718
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Extend gdb.base/index-cache.exp
+ The test-case gdb.base/index-cache.exp uses only one source file, which
+ contains main.
+
+ While doing "file $exec", in set_initial_language a symbol lookup of "main" is
+ done, causing the symtab containing main to be expanded.
+
+ Handling of main is special, and a future optimization may skip the lookup and
+ expansion.
+
+ Reliably exercise:
+ - the lookup of main, expanding the symtab containing main, by doing
+ "ptype main", and
+ - the lookup of another symbol, expanding a symtab not containing main, by:
+ - adding another source file containing function foo, and
+ - doing "ptype foo".
+
+ This triggered a segfault with target board native-extended-gdbserver, filed
+ as PR symtab/30712, but that seems to be fixed by a previous commit in this
+ series.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30712
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in,is_debug_type}
+ With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp
+ and target board debug-types, I run into:
+ ...
+ (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
+ Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
+ ==================
+ WARNING: ThreadSanitizer: data race (pid=9654)
+ Write of size 1 at 0x7b200000420d by main thread:
+ #0 dwarf2_per_cu_data::get_header() const gdb/dwarf2/read.c:21513 (gdb+0x8d1eee)
+ #1 dwarf2_per_cu_data::addr_size() const gdb/dwarf2/read.c:21524 (gdb+0x8d1f4e)
+ #2 dwarf2_cu::addr_type() const gdb/dwarf2/cu.c:112 (gdb+0x806327)
+ #3 set_die_type gdb/dwarf2/read.c:21932 (gdb+0x8d3870)
+ #4 read_base_type gdb/dwarf2/read.c:15448 (gdb+0x8bcacb)
+ #5 read_type_die_1 gdb/dwarf2/read.c:19832 (gdb+0x8cc0a5)
+ #6 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d)
+ #7 lookup_die_type gdb/dwarf2/read.c:19739 (gdb+0x8cbdc7)
+ #8 die_type gdb/dwarf2/read.c:19593 (gdb+0x8cb68a)
+ #9 read_subroutine_type gdb/dwarf2/read.c:14648 (gdb+0x8b998e)
+ #10 read_type_die_1 gdb/dwarf2/read.c:19792 (gdb+0x8cbf2f)
+ #11 read_type_die gdb/dwarf2/read.c:19767 (gdb+0x8cbe6d)
+ #12 read_func_scope gdb/dwarf2/read.c:10154 (gdb+0x8a4f36)
+ #13 process_die gdb/dwarf2/read.c:6667 (gdb+0x898daa)
+ #14 read_file_scope gdb/dwarf2/read.c:7682 (gdb+0x89bad8)
+ #15 process_die gdb/dwarf2/read.c:6654 (gdb+0x898ced)
+ #16 process_full_comp_unit gdb/dwarf2/read.c:6418 (gdb+0x8981de)
+ #17 process_queue gdb/dwarf2/read.c:5690 (gdb+0x894433)
+ #18 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1770 (gdb+0x88623a)
+ #19 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x886300)
+ #20 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88b1f1)
+ #21 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16917 (gdb+0x8c228e)
+ #22 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf39055)
+ #23 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66ab7)
+ #24 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf6711b)
+ #25 operator() gdb/symtab.c:2562 (gdb+0xf67272)
+ #26 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf776b1)
+ #27 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77708)
+ #28 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3fc97)
+ #29 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xecae47)
+ #30 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
+ #31 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf674fb)
+ #32 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf67780)
+ #33 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf66d6e)
+ #34 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf65cb3)
+ #35 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf64dab)
+ #36 set_initial_language() gdb/symfile.c:1708 (gdb+0xf43074)
+ #37 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf41608)
+ #38 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf42faf)
+ #39 file_command gdb/exec.c:554 (gdb+0x94ff29)
+ #40 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
+ #41 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
+ #42 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff379c)
+ #43 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94b5bc)
+ #44 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94bc79)
+ #45 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x1034efc)
+ #46 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94ab61)
+ #47 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11be4ef)
+ #48 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a960)
+ #49 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94aa21)
+ #50 stdin_event_handler gdb/ui.c:155 (gdb+0x10751a0)
+ #51 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d95bac)
+ #52 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d962e4)
+ #53 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d946d0)
+ #54 start_event_loop gdb/main.c:412 (gdb+0xb5ab52)
+ #55 captured_command_loop gdb/main.c:476 (gdb+0xb5ad41)
+ #56 captured_main gdb/main.c:1320 (gdb+0xb5cec1)
+ #57 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5cf70)
+ #58 main gdb/gdb.c:32 (gdb+0x416776)
+
+ Previous read of size 1 at 0x7b200000420d by thread T11:
+ #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x831630)
+ #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x832897)
+ #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/index-cache.c:173 (gdb+0x82db8d)
+ #3 cooked_index::maybe_write_index(dwarf2_per_bfd*, index_cache_store_context const&) gdb/dwarf2/cooked-index.c:645 (gdb+0x7f1d49)
+ #4 operator() gdb/dwarf2/cooked-index.c:474 (gdb+0x7f0f31)
+ #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2a13)
+ #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
+ #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
+ #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
+ #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
+ #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
+ #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
+ #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
+ #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
+ #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
+ #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
+ #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
+ #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
+ #19 pthread_once <null> (libtsan.so.0+0x4457c)
+ #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
+ #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
+ #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
+ #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
+ #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dad25a)
+ #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dacb7c)
+ #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dadc2b)
+ #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dad05c)
+ #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1db038e)
+ #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1db0319)
+ #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1db02ce)
+ #31 <null> <null> (libstdc++.so.6+0xdcac2)
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:21513 in dwarf2_per_cu_data::get_header() const
+ ...
+
+ The race happens when issuing the "file $exec" command.
+
+ The race is between:
+ - a worker thread writing the index cache, and in the process reading
+ dwarf2_per_cu_data::is_debug_type, and
+ - the main thread writing to dwarf2_per_cu_data::m_header_read_in.
+
+ The two bitfields dwarf2_per_cu_data::m_header_read_in and
+ dwarf2_per_cu_data::is_debug_type share the same bitfield container.
+
+ Fix this by making dwarf2_per_cu_data::m_header_read_in a packed<bool, 1>.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30392
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix race on dwarf2_per_cu_data::{queued,is_debug_type}
+ With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
+ run into:
+ ...
+ (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
+ Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
+ ==================
+ WARNING: ThreadSanitizer: data race (pid=24296)
+ Write of size 1 at 0x7b200000420d by main thread:
+ #0 queue_comp_unit gdb/dwarf2/read.c:5564 (gdb+0x8939ce)
+ #1 dw2_do_instantiate_symtab gdb/dwarf2/read.c:1754 (gdb+0x885b96)
+ #2 dw2_instantiate_symtab gdb/dwarf2/read.c:1792 (gdb+0x885d86)
+ #3 dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) gdb/dwarf2/read.c:3042 (gdb+0x88ac77)
+ #4 cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) gdb/dwarf2/read.c:16915 (gdb+0x8c1c8a)
+ #5 objfile::lookup_symbol(block_enum, char const*, domain_enum) gdb/symfile-debug.c:288 (gdb+0xf389a1)
+ #6 lookup_symbol_via_quick_fns gdb/symtab.c:2385 (gdb+0xf66403)
+ #7 lookup_symbol_in_objfile gdb/symtab.c:2516 (gdb+0xf66a67)
+ #8 operator() gdb/symtab.c:2562 (gdb+0xf66bbe)
+ #9 operator() gdb/../gdbsupport/function-view.h:305 (gdb+0xf76ffd)
+ #10 _FUN gdb/../gdbsupport/function-view.h:299 (gdb+0xf77054)
+ #11 gdb::function_view<bool (objfile*)>::operator()(objfile*) const gdb/../gdbsupport/function-view.h:289 (gdb+0xc3f5e3)
+ #12 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3455 (gdb+0xeca793)
+ #13 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
+ #14 lookup_global_or_static_symbol gdb/symtab.c:2559 (gdb+0xf66e47)
+ #15 lookup_global_symbol(char const*, block const*, domain_enum) gdb/symtab.c:2615 (gdb+0xf670cc)
+ #16 language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const gdb/symtab.c:2447 (gdb+0xf666ba)
+ #17 lookup_symbol_aux gdb/symtab.c:2123 (gdb+0xf655ff)
+ #18 lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) gdb/symtab.c:1931 (gdb+0xf646f7)
+ #19 set_initial_language() gdb/symfile.c:1708 (gdb+0xf429c0)
+ #20 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40f54)
+ #21 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf428fb)
+ #22 file_command gdb/exec.c:554 (gdb+0x94f875)
+ #23 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
+ #24 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
+ #25 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff3166)
+ #26 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94af08)
+ #27 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b5c5)
+ #28 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x10348c6)
+ #29 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a4ad)
+ #30 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdf87)
+ #31 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a2ac)
+ #32 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a36d)
+ #33 stdin_event_handler gdb/ui.c:155 (gdb+0x1074b6a)
+ #34 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d9502c)
+ #35 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d95764)
+ #36 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93b50)
+ #37 start_event_loop gdb/main.c:412 (gdb+0xb5a49e)
+ #38 captured_command_loop gdb/main.c:476 (gdb+0xb5a68d)
+ #39 captured_main gdb/main.c:1320 (gdb+0xb5c80d)
+ #40 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c8bc)
+ #41 main gdb/gdb.c:32 (gdb+0x416776)
+
+ Previous read of size 1 at 0x7b200000420d by thread T12:
+ #0 write_gdbindex gdb/dwarf2/index-write.c:1229 (gdb+0x8310c8)
+ #1 write_dwarf_index(dwarf2_per_bfd*, char const*, char const*, char const*, dw_index_kind) gdb/dwarf2/index-write.c:1484 (gdb+0x83232f)
+ #2 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:177 (gdb+0x82d62b)
+ #3 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf7)
+ #4 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40)
+ #5 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f2909)
+ #6 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
+ #7 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
+ #8 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
+ #9 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
+ #10 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
+ #11 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
+ #12 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
+ #13 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
+ #14 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
+ #15 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
+ #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
+ #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
+ #19 pthread_once <null> (libtsan.so.0+0x4457c)
+ #20 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
+ #21 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
+ #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
+ #23 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
+ #24 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac6da)
+ #25 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabffc)
+ #26 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dad0ab)
+ #27 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac4dc)
+ #28 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf80e)
+ #29 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf799)
+ #30 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf74e)
+ #31 <null> <null> (libstdc++.so.6+0xdcac2)
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:5564 in queue_comp_unit
+ ...
+
+ The race happens when issuing the "file $exec" command.
+
+ The race is between:
+ - a worker thread writing the index cache, and in the process reading
+ dwarf2_per_cu_data::is_debug_type, and
+ - the main thread expanding the CU containing main, and in the process setting
+ dwarf2_per_cu_data::queued.
+
+ The two bitfields dwarf2_per_cu_data::queue and
+ dwarf2_per_cu_data::is_debug_type share the same bitfield container.
+
+ Fix this by making dwarf2_per_cu_data::queued a packed<bool, 1>.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30392
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on bfd::{cacheable,format}
+ With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
+ run into:
+ ...
+ (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
+ Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
+ ==================
+ WARNING: ThreadSanitizer: data race (pid=12261)
+ Write of size 4 at 0x7b4400097d08 by main thread:
+ #0 bfd_open_file bfd/cache.c:584 (gdb+0x148bb92)
+ #1 bfd_cache_lookup_worker bfd/cache.c:261 (gdb+0x148b12a)
+ #2 cache_bseek bfd/cache.c:289 (gdb+0x148b324)
+ #3 bfd_seek bfd/bfdio.c:459 (gdb+0x1489c31)
+ #4 _bfd_generic_get_section_contents bfd/libbfd.c:1069 (gdb+0x14977a4)
+ #5 bfd_get_section_contents bfd/section.c:1606 (gdb+0x149cc7c)
+ #6 gdb_bfd_scan_elf_dyntag(int, bfd*, unsigned long*, unsigned long*) gdb/solib.c:1601 (gdb+0xed8eca)
+ #7 elf_locate_base gdb/solib-svr4.c:705 (gdb+0xec28ac)
+ #8 svr4_iterate_over_objfiles_in_search_order gdb/solib-svr4.c:3430 (gdb+0xeca55d)
+ #9 gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) gdb/gdbarch.c:5041 (gdb+0x537cad)
+ #10 find_main_name gdb/symtab.c:6270 (gdb+0xf743a5)
+ #11 main_language() gdb/symtab.c:6313 (gdb+0xf74499)
+ #12 set_initial_language() gdb/symfile.c:1700 (gdb+0xf4285c)
+ #13 symbol_file_add_main_1 gdb/symfile.c:1212 (gdb+0xf40e2a)
+ #14 symbol_file_command(char const*, int) gdb/symfile.c:1681 (gdb+0xf427d1)
+ #15 file_command gdb/exec.c:554 (gdb+0x94f74b)
+ #16 do_simple_func gdb/cli/cli-decode.c:95 (gdb+0x6d9528)
+ #17 cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 (gdb+0x6e0f69)
+ #18 execute_command(char const*, int) gdb/top.c:575 (gdb+0xff303c)
+ #19 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94adde)
+ #20 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b49b)
+ #21 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103479c)
+ #22 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a383)
+ #23 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bde5d)
+ #24 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a182)
+ #25 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a243)
+ #26 stdin_event_handler gdb/ui.c:155 (gdb+0x1074a40)
+ #27 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94f02)
+ #28 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9563a)
+ #29 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93a26)
+ #30 start_event_loop gdb/main.c:412 (gdb+0xb5a374)
+ #31 captured_command_loop gdb/main.c:476 (gdb+0xb5a563)
+ #32 captured_main gdb/main.c:1320 (gdb+0xb5c6e3)
+ #33 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c792)
+ #34 main gdb/gdb.c:32 (gdb+0x416776)
+
+ Previous read of size 1 at 0x7b4400097d08 by thread T12:
+ #0 bfd_check_format_matches bfd/format.c:323 (gdb+0x1492db4)
+ #1 bfd_check_format bfd/format.c:94 (gdb+0x1492104)
+ #2 build_id_bfd_get(bfd*) gdb/build-id.c:42 (gdb+0x6648f7)
+ #3 index_cache::store(dwarf2_per_bfd*, index_cache_store_context*) gdb/dwarf2/index-cache.c:110 (gdb+0x82d205)
+ #4 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:640 (gdb+0x7f1bf1)
+ #5 operator() gdb/dwarf2/cooked-index.c:470 (gdb+0x7f0f40)
+ #6 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f28f7)
+ #7 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
+ #8 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
+ #9 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
+ #10 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
+ #11 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
+ #12 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
+ #13 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
+ #14 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
+ #15 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
+ #16 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
+ #18 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
+ #19 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
+ #20 pthread_once <null> (libtsan.so.0+0x4457c)
+ #21 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
+ #22 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
+ #23 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
+ #24 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
+ #25 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac5b0)
+ #26 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabed2)
+ #27 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dacf81)
+ #28 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac3b2)
+ #29 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf6e4)
+ #30 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf66f)
+ #31 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf624)
+ #32 <null> <null> (libstdc++.so.6+0xdcac2)
+ ...
+ SUMMARY: ThreadSanitizer: data race bfd/cache.c:584 in bfd_open_file
+ ...
+
+ The race happens when issuing the "file $exec" command.
+
+ The race is between:
+ - a worker thread getting the build id while writing the index cache, and in
+ the process reading bfd::format, and
+ - the main thread calling find_main_name, and in the process setting
+ bfd::cacheable.
+
+ The two bitfields bfd::cacheable and bfd::format share the same bitfield
+ container.
+
+ Fix this by capturing the build id in the main thread, and using the captured
+ value in the worker thread.
+
+ Likewise for the dwz build id, which likely suffers from the same issue.
+
+ While we're at it, also move the creation of the cache directory to
+ the index_cache_store_context constructor, to:
+ - make sure there's no race between subsequent file commands, and
+ - issue any related warning or error messages during the file command.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30392
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
+
+2023-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on index_cache::m_enabled
+ With gdb build with -fsanitize=thread and test-case gdb.base/index-cache.exp I
+ run into:
+ ...
+ (gdb) file build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
+ Reading symbols from build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...
+ (gdb) show index-cache enabled
+ The index cache is off.
+ (gdb) PASS: gdb.base/index-cache.exp: test_basic_stuff: index-cache is disabled by default
+ set index-cache enabled on
+ ==================
+ WARNING: ThreadSanitizer: data race (pid=32248)
+ Write of size 1 at 0x00000321f540 by main thread:
+ #0 index_cache::enable() gdb/dwarf2/index-cache.c:76 (gdb+0x82cfdd)
+ #1 set_index_cache_enabled_command gdb/dwarf2/index-cache.c:270 (gdb+0x82d9af)
+ #2 bool setting::set<bool>(bool const&) gdb/command.h:353 (gdb+0x6fe5f2)
+ #3 do_set_command(char const*, int, cmd_list_element*) gdb/cli/cli-setshow.c:414 (gdb+0x6fcd21)
+ #4 execute_command(char const*, int) gdb/top.c:567 (gdb+0xff2e64)
+ #5 command_handler(char const*) gdb/event-top.c:552 (gdb+0x94acc0)
+ #6 command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:788 (gdb+0x94b37d)
+ #7 tui_command_line_handler gdb/tui/tui-interp.c:104 (gdb+0x103467e)
+ #8 gdb_rl_callback_handler gdb/event-top.c:259 (gdb+0x94a265)
+ #9 rl_callback_read_char readline/readline/callback.c:290 (gdb+0x11bdd3f)
+ #10 gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 (gdb+0x94a064)
+ #11 gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 (gdb+0x94a125)
+ #12 stdin_event_handler gdb/ui.c:155 (gdb+0x1074922)
+ #13 handle_file_event gdbsupport/event-loop.cc:573 (gdb+0x1d94de4)
+ #14 gdb_wait_for_event gdbsupport/event-loop.cc:694 (gdb+0x1d9551c)
+ #15 gdb_do_one_event(int) gdbsupport/event-loop.cc:264 (gdb+0x1d93908)
+ #16 start_event_loop gdb/main.c:412 (gdb+0xb5a256)
+ #17 captured_command_loop gdb/main.c:476 (gdb+0xb5a445)
+ #18 captured_main gdb/main.c:1320 (gdb+0xb5c5c5)
+ #19 gdb_main(captured_main_args*) gdb/main.c:1339 (gdb+0xb5c674)
+ #20 main gdb/gdb.c:32 (gdb+0x416776)
+
+ Previous read of size 1 at 0x00000321f540 by thread T12:
+ #0 index_cache::enabled() const gdb/dwarf2/index-cache.h:48 (gdb+0x82e1a6)
+ #1 index_cache::store(dwarf2_per_bfd*) gdb/dwarf2/index-cache.c:94 (gdb+0x82d0bc)
+ #2 cooked_index::maybe_write_index(dwarf2_per_bfd*) gdb/dwarf2/cooked-index.c:638 (gdb+0x7f1b97)
+ #3 operator() gdb/dwarf2/cooked-index.c:468 (gdb+0x7f0f24)
+ #4 _M_invoke /usr/include/c++/7/bits/std_function.h:316 (gdb+0x7f285b)
+ #5 std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x700952)
+ #6 void std::__invoke_impl<void, std::function<void ()>&>(std::__invoke_other, std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:60 (gdb+0x7381a0)
+ #7 std::__invoke_result<std::function<void ()>&>::type std::__invoke<std::function<void ()>&>(std::function<void ()>&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x737e91)
+ #8 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}::operator()() const /usr/include/c++/7/future:1421 (gdb+0x737b59)
+ #9 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void>::operator()() const /usr/include/c++/7/future:1362 (gdb+0x738660)
+ #10 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::{lambda()#1}, void> >::_M_invoke(std::_Any_data const&) /usr/include/c++/7/bits/std_function.h:302 (gdb+0x73825c)
+ #11 std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706 (gdb+0x733623)
+ #12 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) /usr/include/c++/7/future:561 (gdb+0x732bdf)
+ #13 void std::__invoke_impl<void, void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::__invoke_memfun_deref, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x734c4f)
+ #14 std::__invoke_result<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>::type std::__invoke<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x733bc5)
+ #15 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#1}::operator()() const /usr/include/c++/7/mutex:672 (gdb+0x73300d)
+ #16 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::operator()() const /usr/include/c++/7/mutex:677 (gdb+0x7330b2)
+ #17 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&)::{lambda()#2}::_FUN() /usr/include/c++/7/mutex:677 (gdb+0x7330f2)
+ #18 pthread_once <null> (libtsan.so.0+0x4457c)
+ #19 __gthread_once /usr/include/c++/7/x86_64-suse-linux/bits/gthr-default.h:699 (gdb+0x72f5dd)
+ #20 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) /usr/include/c++/7/mutex:684 (gdb+0x733224)
+ #21 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) /usr/include/c++/7/future:401 (gdb+0x732852)
+ #22 std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run() /usr/include/c++/7/future:1423 (gdb+0x737bef)
+ #23 std::packaged_task<void ()>::operator()() /usr/include/c++/7/future:1556 (gdb+0x1dac492)
+ #24 gdb::thread_pool::thread_function() gdbsupport/thread-pool.cc:242 (gdb+0x1dabdb4)
+ #25 void std::__invoke_impl<void, void (gdb::thread_pool::*)(), gdb::thread_pool*>(std::__invoke_memfun_deref, void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:73 (gdb+0x1dace63)
+ #26 std::__invoke_result<void (gdb::thread_pool::*)(), gdb::thread_pool*>::type std::__invoke<void (gdb::thread_pool::*)(), gdb::thread_pool*>(void (gdb::thread_pool::*&&)(), gdb::thread_pool*&&) /usr/include/c++/7/bits/invoke.h:95 (gdb+0x1dac294)
+ #27 decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/7/thread:234 (gdb+0x1daf5c6)
+ #28 std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> >::operator()() /usr/include/c++/7/thread:243 (gdb+0x1daf551)
+ #29 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (gdb::thread_pool::*)(), gdb::thread_pool*> > >::_M_run() /usr/include/c++/7/thread:186 (gdb+0x1daf506)
+ #30 <null> <null> (libstdc++.so.6+0xdcac2)
+
+ Location is global 'global_index_cache' of size 48 at 0x00000321f520 (gdb+0x00000321f540)
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/dwarf2/index-cache.c:76 in index_cache::enable()
+ ...
+
+ The race happens when issuing a "file $exec" command followed by a
+ "set index-cache enabled on" command.
+
+ The race is between:
+ - a worker thread reading index_cache::m_enabled to determine whether an
+ index-cache entry for $exec needs to be written
+ (due to command "file $exec"), and
+ - the main thread setting index_cache::m_enabled
+ (due to command "set index-cache enabled on").
+
+ Fix this by capturing the value of index_cache::m_enabled in the main thread,
+ and using the captured value in the worker thread.
+
+ Tested on x86_64-linux.
+
+ PR symtab/30392
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
+
+2023-08-04 Alan Modra <amodra@gmail.com>
+
+ ppc: sanity check writing relocs
+ Check for output buffer overruns.
+
+ * elf32-ppc.c (swap_reloc_out, count_and_swap_reloc_out): New
+ functions. Use throughout file.
+ * elf64-ppc.c (swap_reloc_out, count_and_swap_reloc_out): Likewise.
+
+2023-08-04 Alan Modra <amodra@gmail.com>
+
+ PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
+ This fixes miscounting of dynamic relocations on GOT entries when
+ a) there are both local-dynamic and global-dynamic tls accesss for a
+ given symbol, and
+ b) the symbol is global with non-default visibility, and
+ c) the __tls_get_addr calls aren't optimised away.
+
+ PR 30697
+ bfd/
+ * elf32-ppc.c (allocate_dynrelocs): Correct local-dynamic
+ reloc count.
+ ld/
+ * testsuite/ld-powerpc/tls32ldgd.d,
+ * testsuite/ld-powerpc/tls32ldgd.s: New test.
+ * testsuite/ld-powerpc/powerpc.exp: Run it.
+
+2023-08-04 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Disable gdb.compile when testing with clang
+ Attempting to test the gdb.compile with clang as the compiler results in
+ over 300 unexpected errors, due to a segmentation fault and several
+ handshake failures. Since the whole feature is designed around a gcc
+ plugin, and even the gcc testing is shaky at best, this commit restricts
+ those tests to only running under gcc. If that gets fixed, this commit
+ can be reverted.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Remove superfluous handling of Ada main in write_cooked_index
+ I filed PR29179 about the following FAIL in test-case
+ gdb.ada/O2_float_param.exp with target board cc-with-gdb-index:
+ ...
+ (gdb) break increment^M
+ Function "increment" not defined.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: gdb_breakpoint: \
+ set breakpoint at increment
+ ...
+
+ The FAIL was a regression since commit 2cf349be0e3 ("Do not put linkage names
+ into .gdb_index").
+
+ Before that commit we had:
+ ...
+ $ readelf -w foo > READELF
+ $ grep callee.*increment READELF
+ [1568] callee__increment: 5 [global, function]
+ [3115] callee.increment: 5 [global, function]
+ ...
+ but after only:
+ ...
+ $ grep callee.*increment READELF
+ [3115] callee.increment: 5 [global, function]
+ ...
+
+ The regression was fixed by commit 67e83a0deef ("Fix regression in
+ c-linkage-name.exp with gdb index"), which got us again:
+ ...
+ $ grep callee.*increment READELF
+ [1568] callee__increment: 5 [global, function]
+ [3115] callee.increment: 5 [global, function]
+ ...
+
+ The commit however did not claim that particular PR. A subsequent commit,
+ commit 5fea9794325 ("Improve Ada support in .gdb_index") did claim to fix it,
+ together with commit dd05fc7071a ("Change .gdb_index de-duplication
+ implementation").
+
+ The commit 5fea9794325 contained the following addition in write_cooked_index:
+ ...
+ + if (entry->per_cu->lang () == language_ada)
+ + {
+ + /* We want to ensure that the Ada main function's name
+ + appears verbatim in the index. However, this name will
+ + be of the form "_ada_mumble", and will be rewritten by
+ + ada_decode. So, recognize it specially here and add it
+ + to the index by hand. */
+ + if (entry->tag == DW_TAG_subprogram
+ + && strcmp (main_for_ada, name) == 0)
+ + {
+ + /* Leave it alone. */
+ + }
+ + else
+ + {
+ + /* In order for the index to work when read back into
+ + gdb, it has to use the encoded name, with any
+ + suffixes stripped. */
+ + std::string encoded = ada_encode (name, false);
+ + name = obstack_strdup (&symtab->m_string_obstack,
+ + encoded.c_str ());
+ + }
+ + }
+ ...
+
+ The code contains some special handling related to the Ada main function, so
+ let's look at that one: foo. Before commit 67e83a0deef we have:
+ ...
+ $ grep foo.*function READELF
+ [3733] foo: 7 [global, function]
+ ...
+ and after:
+ ...
+ $ grep foo.*function READELF
+ [2738] _ada_foo: 7 [global, function]
+ [3733] foo: 7 [global, function]
+ ...
+ so that looks identical to the callee.increment case.
+
+ At commit 5fea9794325, we have slightly different index numbers:
+ ...
+ $ grep foo.*function READELF
+ [1658] foo: 7 [global, function]
+ [2738] _ada_foo: 7 [global, function]
+ ...
+ but otherwise the same result.
+
+ If we disable the special handling of the Ada main function like so:
+ ...
+ - if (entry->tag == DW_TAG_subprogram
+ + if (false && entry->tag == DW_TAG_subprogram
+ ...
+ we still have the exact same result because:
+ ...
+ (gdb) p main_for_ada
+ $1 = 0x352e6a0 "_ada_foo"
+ ...
+ and ada_encode ("_ada_foo", false) == "_ada_foo".
+
+ The comment seems to be copied from debug_names::insert, which does indeed use
+ ada_decode, while the code in write_cooked_index uses ada_encode instead.
+
+ Remove the superfluous special handling of Ada main in write_cooked_index.
+
+ Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-03 Tom Tromey <tromey@adacore.com>
+
+ Remove f-string from DAP
+ One more f-string snuck into the DAP code, in breakpoint.py. Most of
+ them were removed here:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-June/200023.html
+
+ but I think this one landed after that patch.
+
+ While DAP only supports Python 3.5 and later, f-strings were added in
+ 3.6, so remove this.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708
+
+2023-08-03 Tom Tromey <tromey@adacore.com>
+
+ Use frame.name() in FrameDecorator
+ A co-worker pointed out that gdb's DAP implementation might return an
+ integer for the name of a stack frame, like:
+
+ {"id": 1, "name": 93824992310799, ...}
+
+ This can be seen currently in the logs of the bt-nodebug.exp test
+ case.
+
+ What is happening is that FrameDecorator falls back on returning the
+ PC when the frame's function symbol cannot be found, relying on the
+ gdb core to look up the minsym and print its name.
+
+ This can actually yield the wrong answer sometimes, because it falls
+ into the get_frame_pc / get_frame_address_in_block problem -- if the
+ frame is at a call to a noreturn function, the PC in this case might
+ appear to be in the next function in memory. For more on this, see:
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=8416
+
+ and related bugs.
+
+ However, there's a different approach we can take: the code here can
+ simply use Frame.name. This handles the PC problem correctly, and
+ gets us the information we need.
+
+2023-08-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: avoid double stop after failed breakpoint condition check
+ This commit replaces this earlier commit:
+
+ commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
+ Date: Fri Oct 14 14:53:15 2022 +0100
+
+ gdb: don't always print breakpoint location after failed condition check
+
+ and is a result of feedback received here[1].
+
+ The original commit addressed a problem where, if a breakpoint
+ condition included an inferior function call, and if the inferior
+ function call failed, then GDB would announce the stop twice. Here's
+ an example of GDB's output before the above commit that shows the
+ problem being addressed:
+
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing condition for breakpoint 1:
+ The program being debugged stopped while in a function called from GDB.
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+
+ Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ (gdb)
+
+ The original commit addressed this issue in breakpoint.c, by spotting
+ that the $pc had changed while evaluating the breakpoint condition,
+ and inferring from this that GDB must have stopped elsewhere.
+
+ However, the way in which the original commit suppressed the second
+ stop announcement was to set bpstat::print to true -- this tells GDB
+ not to print the frame during the stop announcement, and for the CLI
+ this is fine, however, it was pointed out that for the MI this still
+ isn't really enough. Below is an example from an MI session after the
+ above commit was applied, this shows the problem with the above
+ commit:
+
+ -break-insert -c "cond_fail()" foo
+ ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"}
+ (gdb)
+ -exec-run
+ =thread-group-started,id="i1",pid="2636270"
+ =thread-created,id="1",group-id="i1"
+ =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}]
+ ^running
+ *running,thread-id="all"
+ (gdb)
+ =library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}]
+ =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}]
+ ~"\nProgram"
+ ~" received signal SIGSEGV, Segmentation fault.\n"
+ ~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n"
+ ~"24\t return *p;\t\t\t/* Crash here. */\n"
+ *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9"
+ &"Error in testing condition for breakpoint 1:\n"
+ &"The program being debugged was signaled while in a function called from GDB.\n"
+ &"GDB remains in the frame where the signal was received.\n"
+ &"To change this behavior use \"set unwindonsignal on\".\n"
+ &"Evaluation of the expression containing the function\n"
+ &"(cond_fail) will be abandoned.\n"
+ &"When the function is done executing, GDB will silently stop.\n"
+ =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"}
+ *stopped
+ (gdb)
+
+ Notice that we still see two '*stopped' lines, the first includes the
+ full frame information, while the second has no frame information,
+ this is a result of bpstat::print having been set. Ideally, the
+ second '*stopped' line should not be present.
+
+ By setting bpstat::print I was addressing the problem too late, this
+ flag really only changes how interp::on_normal_stop prints the stop
+ event, and interp::on_normal_stop is called (indirectly) from the
+ normal_stop function in infrun.c. A better solution is to avoid
+ calling normal_stop at all for the stops which should not be reported
+ to the user, and this is what I do in this commit.
+
+ This commit has 3 parts:
+
+ 1. In breakpoint.c, revert the above commit,
+
+ 2. In fetch_inferior_event (infrun.c), capture the stop-id before
+ calling handle_inferior_event. If, after calling
+ handle_inferior_event, the stop-id has changed, then this indicates
+ that somewhere within handle_inferior_event, a stop was announced to
+ the user. If this is the case then GDB should not call normal_stop,
+ and we should rely on whoever announced the stop to ensure that we
+ are in a PROMPT_NEEDED state, which means the prompt will be
+ displayed once fetch_inferior_event returns. And,
+
+ 3. In infcall.c, do two things:
+
+ (a) In run_inferior_call, after making the inferior call, ensure
+ that either async_disable_stdin or async_enable_stdin is called
+ to put the prompt state, and stdin handling into the correct
+ state based on whether the inferior call completed successfully
+ or not, and
+
+ (b) In call_thread_fsm::should_stop, call async_enable_stdin
+ rather than changing the prompt state directly. This isn't
+ strictly necessary, but helped me understand this code more.
+ This async_enable_stdin call is only reached if normal_stop is
+ not going to be called, and replaces the async_enable_stdin call
+ that exists in normal_stop. Though we could just adjust the
+ prompt state if felt (to me) much easier to understand when I
+ could see this call and the corresponding call in normal_stop.
+
+ With these changes in place now, when the inferior call (from the
+ breakpoint condition) fails, infcall.c leaves the prompt state as
+ PROMPT_NEEDED, and leaves stdin registered with the event loop.
+
+ Back in fetch_inferior_event GDB notices that the stop-id has changed
+ and so avoids calling normal_stop.
+
+ And on return from fetch_inferior_event GDB will display the prompt
+ and handle input from stdin.
+
+ As normal_stop is not called the MI problem is solved, and the test
+ added in the earlier mentioned commit still passes just fine, so the
+ CLI has not regressed.
+
+ [1] https://inbox.sourceware.org/gdb-patches/6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net/
+
+2023-08-03 Tom Tromey <tom@tromey.com>
+
+ Remove PEI_HEADERS define
+ I noticed a few files double-included libcoff.h, and digging deeper I
+ found that the PEI_HEADERS define is a sort of external include guard.
+
+ This patch adds include guards to the few files in include/coff that
+ were missing one, and then removes the PEI_HEADERS workaround and the
+ redundant includes.
+
+ I didn't see anything in these files that indicated that
+ double-inclusion would be useful, so it seems to me that this approach
+ is ok.
+
+ Tested by rebuilding with --enable-targets=all.
+
+ 2023-08-02 Tom Tromey <tromey@adacore.com>
+
+ * pei-x86_64.c (PEI_HEADERS): Do not define.
+ * pei-loongarch64.c (PEI_HEADERS): Do not define.
+ * pei-aarch64.c (PEI_HEADERS): Do not define.
+ * pe-x86_64.c (PEI_HEADERS): Do not define.
+ * pe-aarch64.c (PEI_HEADERS): Do not define.
+ * libpei.h (_LIBPEI_H): Add include guard.
+ * coff-x86_64.c (PEI_HEADERS): Do not check.
+ * coff-loongarch64.c (PEI_HEADERS): Do not check.
+ * coff-aarch64.c (PEI_HEADERS): Do not check.
+
+ include/ChangeLog
+ 2023-08-02 Tom Tromey <tromey@adacore.com>
+
+ * coff/x86_64.h (COFF_X86_64_H): Add include guard.
+ * coff/loongarch64.h (COFF_LOONGARCH64_H): Add include guard.
+ * coff/aarch64.h (COFF_AARCH64_H): Add include guard.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ readelf sprintf optimisation
+ This replaces sprintf and strcat calls with stpcpy, and makes use of
+ sprintf return value rather than using strlen, for get_machine_flags.
+
+ decode_NDS32_machine_flags made use of snprintf, which is arguably the
+ "correct" way to do things if there can be a buffer overflow. In this
+ case I don't think there can be, the buffer is 1k in size which is at
+ least 5 times more than needed. What's more, snprintf returns the
+ count of chars that would be output given no buffer limit, which means
+ code like
+ r += snprintf (buf + r, size - r, ...);
+ r += snprintf (buf + r, size - r, ...);
+ is just wrong. There needs to be a check on the return value in order
+ to prevent buf + r being out of bounds for the second snprintf call.
+
+ BTW, if you look closely you'll see the return value of the decode
+ functions is unused. I admit to getting a little carried away with
+ writing "out = stpcpy (out, ...):" in each of the decode functions and
+ didn't notice that until get_machine_flags was trimmed down to a much
+ smaller size. When I did notice, I decided it's not such a bad thing.
+
+ * readelf.c (decode_ARC_machine_flags, decode_ARM_machine_flags),
+ (decode_AVR_machine_flags, decode_NDS32_machine_flags),
+ (decode_AMDGPU_machine_flags): Use stpcpy and sprintf return
+ value. Return end of string.
+ (decode_BLACKFIN_machine_flags, decode_FRV_machine_flags),
+ (decode_IA64_machine_flags, decode_LOONGARCH_machine_flags),
+ (decode_M68K_machine_flags, decode_MeP_machine_flags),
+ (decode_MIPS_machine_flags, decode_MSP430_machine_flags),
+ (decode_PARISC_machine_flags, decode_RISCV_machine_flags),
+ (decode_RL78_machine_flags, decode_RX_machine_flags),
+ (decode_SH_machine_flags, decode_SPARC_machine_flags),
+ (decode_V800_machine_flags, decode_V850_machine_flags),
+ (decode_Z80_machine_flags): New functions, split out from..
+ (get_machine_flags): ..here. Similarly use stpcpy.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ binutils sprintf optimisation
+ Avoid the use of sprintf with a "%s" format string, replacing with
+ strcpy or stpcpy. Use sprintf return value rather than a later
+ strlen. Don't use strcat where we can keep track of the end of a
+ string output buffer.
+
+ * dlltool.c (look_for_prog): memcpy prefix and strcpy prog_name.
+ * dllwrap.c (look_for_prog): Likewise.
+ * resrc.c (look_for_default): Likewise. Add quotes with memmove
+ rather than allocating another buffer.
+ * size.c (size_number): Use sprintf return value.
+ * stabs.c (parse_stab_argtypes): Likewise.
+ * windmc.c (write_bin): Likewes, and use stpcpy.
+ * wrstabs.c: Similarly throughout.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ cris: sprintf optimisation
+ Since I was poking at cris-dis.c to avoid the sanitizer warning,
+ I figure I might as well make use of stpcpy and sprintf return value
+ in other places in this file.
+
+ * cris-dis.c (format_hex): Use sprintf return value.
+ (format_reg): Use stpcpy and sprintf return, avoiding strlen.
+ (format_sup_reg): Likewise.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ arm: sanitizer stringop-overflow
+ In function 'memset',
+ inlined from 'create_unwind_entry' at /home/alan/src/binutils-gdb/gas/config/tc-arm.c:27881:3:
+ /usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' specified size between 2147483652 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
+ 59 | return __builtin___memset_chk (__dest, __ch, __len,
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 60 | __glibc_objsize0 (__dest));
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * config/tc-arm.c (create_unwind_entry): Return after bad size,
+ and bad opcode count.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ xtensa: sprintf sanitizer null destination pointer
+ * config/tc-xtensa.c (xtensa_add_config_info): Use auto buffer
+ rather than malloc. Use sprintf return value.
+
+ ld: sprintf sanitizer null destination pointer
+ * configure.ac (stpcpy): AC_CHECK_DECLS.
+ * sysdep.h (stpcpy): Add fallback declaraion.
+ * config.in: Regenerate.
+ * configure: Regenerate.
+ * emultempl/pe.em (open_dynamic_archive): Use
+ stpcpy rather than sprintf plus strlen.
+ * emultempl/pep.em (open_dynamic_archive): Likewise.
+ * emultempl/xtensaelf.em (elf_xtensa_before_allocation): Use
+ auto rather than malloc'd buffer. Use sprintf count.
+ * ldelf.c (ldelf_search_needed): Use memcpy in place of sprintf.
+ * pe-dll.c (pe_process_import_defs): Use string already formed
+ for alias match rather than recreating.
+
+ gprof: sprintf sanitizer null destination pointer
+ * basic_blocks.c (annotate_with_count): Use output of sprintf
+ rather than strlen.
+
+ resrc: sprintf sanitizer null destination pointer
+ * resrc.c (read_rc_file): Use stpcpy rather than sprintf
+ followed by strlen. Tidy.
+
+ dlltool: sprintf sanitizer null destination pointer
+ * dlltool.c (gen_lib_file): Avoid bogus sanitizer error.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ wrstabs: sprintf sanitizer null destination pointer
+ gcc-2.12 seems to be ignoring __attribute__((__returns_nonnull__))
+ on xmalloc.
+
+ * wrstabs.c (stab_method_type): Use stpcpy rather than sprintf
+ or strcat.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ cris: sprintf sanitizer null destination pointer
+ Simplify the sprintf calls, and use sprintf return value. Older code
+ in binutils avoided using the sprintf return count of chars printed,
+ because with some older C libraries it wasn't reliable. Nowadays it
+ should be OK to use (and we already use the return value elsewhere).
+ sprintf can't return an error status of -1 here.
+
+ * cris-dis.c (format_dec): Avoid sanitizer warning. Use sprintf
+ return value rather than calling strlen.
+
+2023-08-03 Alan Modra <amodra@gmail.com>
+
+ objdump, nm: sprintf sanitizer null destination pointer
+ Seen on Ubuntu 23.04 x86_64-linux using gcc-12.2 and gcc-12.3 with
+ CFLAGS="-m32 -g -O2 -fsanitize=address,undefined".
+
+ CC objdump.o
+ In file included from /usr/include/stdio.h:906,
+ from /home/alan/src/binutils-gdb/binutils/sysdep.h:24,
+ from /home/alan/src/binutils-gdb/binutils/objdump.c:51:
+ In function 'sprintf',
+ inlined from 'display_utf8' at /home/alan/src/binutils-gdb/binutils/objdump.c:621:14,
+ inlined from 'sanitize_string.part.0' at /home/alan/src/binutils-gdb/binutils/objdump.c:742:11:
+ /usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
+ 30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 31 | __glibc_objsize (__s), __fmt,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 32 | __va_arg_pack ());
+ | ~~~~~~~~~~~~~~~~~
+ cc1: all warnings being treated as errors
+
+ The warning is bogus of course. xmalloc is guaranteed to return
+ non-NULL, but apparently this isn't seen in display_utf6. The same
+ doesn't happen with -m64, maybe due to inlining differences, I haven't
+ investigated fully. Easily avoided as we hardly need to use sprintf
+ for a single char, or a two char string.
+
+ * objdump.c (display_utf8): Avoid bogus sprintf sanitizer warning.
+ Use hex ESC to switch back to default colour.
+ (sanitize_string): Comment. Bump buffer size by one. Fix overlong
+ line.
+ * nm.c (display_utf8, sanitize_string): As above.
+
+2023-08-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix possible nullptr dereference in a remote_debug_printf call
+ While working on another patch I triggered a segfault from within the
+ function remote_target::discard_pending_stop_replies. Turns out this
+ was caused by a cut&paste error introduced in this commit:
+
+ commit df5ad102009c41ab4dfadbb8cfb8c8b2a02a4f78
+ Date: Wed Dec 1 09:40:03 2021 -0500
+
+ gdb, gdbserver: detach fork child when detaching from fork parent
+
+ This commit adds a remote_debug_printf call that was copied from
+ earlier in the function, however, the new call wasn't updated to use
+ the appropriate local variable. The local variable that it is using
+ might be nullptr, in which case we trigger undefined behaviour, and
+ could crash, which is what I was seeing.
+
+ Fixed by updating to use the correct local variable.
+
+2023-08-03 Tom de Vries <tdevries@suse.de>
+
+ Fix Wlto-type-mismatch in opcodes/ft32-dis.c
+
+2023-08-03 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add support for 'Zvfh' and 'Zvfhmin'
+ This commit adds support for recently ratified vector FP16 extensions:
+ 'Zvfh' and 'Zvfhmin'.
+
+ This is based on:
+ <https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point>
+ <https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfh-vector-extension-for-half-precision-floating-point>
+
+ Despite not having any new instructions, it will be necessary since those
+ extensions are already implemented in GCC.
+
+ Note that however, in this commit, following dependencies are implemented.
+
+ 1. 'Zvfhmin' -> 'Zve32f'
+ 2. 'Zvfh' -> 'Zvfhmin' (not 'Zvfh' -> 'Zve32f' as in the documentation)
+ 3. 'Zvfh' -> 'Zfhmin'
+
+ This is because the instructions and configurations supported by the
+ 'Zvfh' extension is a strict superset of the 'Zvfhmin' extension and
+ 'Zvfh' -> 'Zve32f' dependency is indirectly derived from that fact.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add implications
+ related to 'Zvfh' and 'Zvfhmin' extensions.
+ (riscv_supported_std_z_ext) Add 'Zvfh' and 'Zvfhmin' to the list.
+
+2023-08-03 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Imply 'Zicsr' from 'Zve32x'
+ Further clarification is made so that 'Zve32x' implies 'Zicsr' (the same
+ implication is already implemented in LLVM).
+
+ See related issue (the author raised) on the vector specification:
+ <https://github.com/riscv/riscv-v-spec/issues/908>
+ and its resolution:
+ <https://github.com/riscv/riscv-v-spec/issues/909>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zve32x' -> 'Zicsr'.
+
+2023-08-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Initialize main_thread_id earlier
+ I wrote a patch using is_main_thread (), and found it returning false in the
+ main thread due to main_thread_id not being initialized yet.
+
+ Initialization currently takes place in _initialize_run_on_main_thread, but
+ that's too late for earlier uses.
+
+ Fix this by initializing, either:
+ - when entering main, or
+ - on an earlier first use.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/dap] Disable DAP for python <= 3.5
+ DAP requires python module typing, which is supported starting python 3.5.
+
+ Make this formal by:
+ - disabling the dap interpreter for python version < 3.5
+ - returning 0 in allow_dap_tests for python version < 3.5
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR dap/30708
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708
+
+2023-08-02 Tom Tromey <tromey@adacore.com>
+
+ Avoid failures in fixed_points.exp with older GCC
+ Tom de Vries pointed out that my recent change to fixed_points.exp
+ failed with older versions of GCC. This patch fixes the problem by
+ skipping the new test in this situation.
+
+2023-08-02 Sam James <sam@gentoo.org>
+
+ Revert "2.41 Release sources"
+ This reverts commit 675b9d612cc59446e84e2c6d89b45500cb603a8d.
+
+ See https://sourceware.org/pipermail/binutils/2023-August/128761.html.
+
+2023-08-02 Nick Clifton <nickc@redhat.com>
+
+ 2.41 Release sources
+
+2023-08-02 Khem Raj <raj.khem@gmail.com>
+
+ gprofng: Fix build with 64bit file offset on 32bit machines
+ gprofng/ChangeLog
+ 2023-07-31 Khem Raj <raj.khem@gmail.com>
+
+ * libcollector/iotrace.c: Define open64, fgetpos64, and fsetpos64
+ only when __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not
+ defined.
+
+2023-08-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-08-01 Alan Modra <amodra@gmail.com>
+
+ Don't declare xmalloc and others in ldmisc.h
+ * ldmisc.h (xmalloc, xrealloc, xexit, yyerror): Don't declare.
+ * emultempl/pdp11.em: Include libiberty.h.
+ * emultempl/ticoff.em: Likewise.
+ * emultempl/vms.em: Likewise.
+ * ldctor.c: Likewise.
+ * ldelfgen.c: Likewise.
+ * ldgram.y: Likewise.
+ (yyerror): Prototype and make static.
+
+2023-08-01 Alan Modra <amodra@gmail.com>
+
+ Don't declare xmalloc or xrealloc in bucomm.h
+ It's better to include the proper header, which has declarations with
+ various attributes. Commit 096aefc040 in 1994 introduced this wart.
+
+ * bucomm.h (xmalloc, xrealloc): Delete declaration.
+ * od-macho.c: Include libiberty.h.
+ * od-xcoff.c: Include libiberty.h.
+
+2023-08-01 Alan Modra <amodra@gmail.com>
+
+ Regen ld/configure
+ For commit 3d05c80b5dc4.
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP "source" request
+ This implements the DAP "source" request. I renamed the
+ "loadedSources" function from "sources" to "loaded_sources" to avoid
+ any confusion. I also moved the loadedSources test to the new
+ sources.exp.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30691
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Handle Source in DAP breakpointLocations
+ This changes the DAP breakpointLocations request to accept a Source
+ and to decode it properly.
+
+ Introduce sourceReference handling in DAP
+ This changes the gdb DAP implementation to emit a real
+ sourceReference, rather than emitting 0. Sources are tracked in some
+ maps in sources.py, and a new helper function is introduced to compute
+ the "Source" object that can be sent to the client.
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Don't supply DAP 'path' for non-file shared libraries
+ The DAP 'module' event may include a 'path' component. I noticed that
+ this is supplied even when the module in question does not come from a
+ file.
+
+ This patch only emits this field when the objfile corresponds to a
+ real file.
+
+ No test case, because I wasn't sure how to write a portable one.
+ However, it's clear from gdb.log on Linux:
+
+ {"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21}
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Implement ValueFormat for DAP
+ This patch implements ValueFormat for DAP. Currently this only means
+ supporting "hex".
+
+ Note that StackFrameFormat is defined to have many more options, but
+ none are currently recognized. It isn't entirely clear how these
+ should be handled. I'll file a new gdb bug for this, and perhaps an
+ upstream DAP bug as well.
+
+ New in v2:
+ - I realized that the "hover" context was broken, and furthermore
+ that we only had tests for "hover" failing, not for it succeeding.
+ This version fixes the oversight and adds a test.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30469
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Respect supportsMemoryReferences in DAP
+ I noticed that the support for memoryReference in the "variables"
+ output is gated on the client "supportsMemoryReferences" capability.
+
+ This patch implements this and makes some other changes to the DAP
+ memory reference code:
+
+ * Remove the memoryReference special case from _SetResult.
+ Upstream DAP fixed this oversight in response to
+ https://github.com/microsoft/debug-adapter-protocol/issues/414
+
+ * Don't use the address of a variable as its memoryReference -- only
+ emit this for pointer types. There's no spec support for the
+ previous approach.
+
+ * Use strip_typedefs to handle typedefs of pointers.
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Add DAP support for C++ exceptions
+ This adds DAP support for the various C++ exception-catching
+ operations.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP 'terminated' event
+ This implements the DAP 'terminated' event. Vladimir Makaev noticed
+ that VSCode will not report the debug session as over unless this is
+ sent.
+
+ It's not completely clear when exactly this event ought to be sent.
+ Here I've done it when the inferior exits.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30681
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Do not send "new breakpoint" event when breakpoint is set
+ When the DAP client sets a breakpoint, gdb currently sends a "new
+ breakpoint" event. However, Vladimir Makaev discovered that this
+ causes VSCode to think there are two breakpoints.
+
+ This patch changes gdb to suppress the event in this case.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Move DAP breakpoint event code to breakpoint.py
+ A subsequent patch will add the ability to suppress breakpoint events
+ to DAP. My first attempt at this ended up with recurse imports,
+ causing Python failures. So, this patch moves all the DAP breakpoint
+ event code to breakpoint.py in preparation for the change.
+
+ I've renamed breakpoint_descriptor here as well, because it can now be
+ private to breakpoint.py.
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Full paths in DAP stackTrace responses
+ Vladimir Makaev noticed that, in some cases, a DAP stackTrace response
+ would include a relative path name for the "path" component.
+
+ This patch changes the frame decorator code to add a new DAP-specific
+ decorator, and changes the DAP entry point to frame filters to use it.
+ This decorator prefers the symtab's full name, and does not fall back
+ to the solib's name.
+
+ I'm not entirely happy with this patch, because if a user frame filter
+ uses FrameDecorator, it may still do the wrong thing. It would be
+ better to have frame filters return symtab-like objects instead, or to
+ have a separate method to return the full path to the source file.
+
+ I also tend to think that the solib fallback behavior of
+ FrameDecorator is a mistake. If this is ever needed, it seems to me
+ that it should be a separate method.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Add "cwd" parameter to DAP launch request
+ This adds the "cwd" parameter to the DAP launch request.
+
+ This came up here:
+ https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90
+ ... and seemed like a good idea.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-08-01 Tom Tromey <tromey@adacore.com>
+
+ Refactor dap_launch
+ This patch refactors dap_launch to make it more extensible and also
+ easier to use.
+
+ Rename private member of FrameDecorator
+ In Python, a member name starting with "__" is specially handled to
+ make it "more private" to the class -- it isn't truly private, but it
+ is renamed to make it less likely to be reused by mistake. This patch
+ ensures that this is done for the private method of FrameDecorator.
+
+2023-08-01 Simon Farre <simon.farre.cx@gmail.com>
+
+ Add thread exited event
+ Reports a thread exit according to the DAP spec:
+ https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread
+
+ This patch requires the ThreadExitedEvent to be checked in,
+ in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html
+
+ Formatted correctly using black
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30474
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-08-01 Nick Clifton <nickc@redhat.com>
+
+ Fix "--only-keep-debug for ELF relocatables" binutils test for compilers which add .debug_macro sections to object files.
+ PR 30699
+ * binutils/testsuite/binutils-all/objcopy.exp (keep_debug_symbols_for_elf_relocatable): Do not add sections containing the string "debug_" to the list of non-debug sections.
+
+2023-08-01 Jan Beulich <jbeulich@suse.com>
+
+ gas: rework timestamp preservation on doc/asconfig.texi
+ PR 28909
+
+ Sadly "cp -p", doing more than just preserving the time stamp, can fail
+ e.g. upon trying to preserve ownership (which we don't care about), as
+ can be observed on e.g. Cygwin. Replace the use of -p by a use of touch,
+ this way also only preserving modification time.
+
+2023-08-01 Nick Clifton <nickc@redhat.com>
+
+ Add note to check that all changes have been pushed before creating the source tarballs
+
+2023-08-01 Sam James <sam@gentoo.org>
+
+ ld: Fix test failures with --enable-textrel-check=error
+
+2023-08-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: create a list of available views
+ In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
+ the output of gp-display-text to display the data.
+ gp-display-text did not report available views.
+
+ gprofng/ChangeLog
+ 2023-07-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Command.cc: Add commands for gprofng GUI.
+ * src/gprofng.rc: Set defaults for gprofng GUI.
+
+2023-08-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Set TSAN_OPTIONS by default to history_size=7
+ I build gdb with -fsanitize=thread and ran the testsuite, and ran into the
+ case that a race is detected, but we see the full stack trace only for one of
+ the two accesses, and the other one is showing "failed to restore the stack".
+
+ Try to prevent this by setting ThreadSanitizer flag history_size [1] to the
+ maximum (7) by default, as suggested here [2].
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ [1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags
+ [2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE
+
+2023-07-31 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in fixed-point handling
+ Alexandre Oliva found a bug in gdb's handling of fixed-point -- a
+ certain Ada fixed-point type would be misintepreted. The bug was that
+ the DW_AT_small looked like:
+
+ <1><13cd>: Abbrev Number: 16 (DW_TAG_constant)
+ <13ce> DW_AT_GNU_numerator: 1
+ <13cf> DW_AT_GNU_denominator: 0x8000000000000000
+
+ ... but gdb interpreted the denominator as a negative value.
+
+2023-07-31 Sam James <sam@gentoo.org>
+
+ ld: fix typo in --enable-warn-rwx-segments help
+
+2023-07-31 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/amdgpu: Fix debugging multiple inferiors using the ROCm runtime
+ When debugging a multi-process application where a parent spawns
+ multiple child processes using the ROCm runtime, I see the following
+ assertion failure:
+
+ ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x556e9a318540 gdb_internal_backtrace_1
+ ../../gdb/bt-utils.c:122
+ 0x556e9a318540 _Z22gdb_internal_backtracev
+ ../../gdb/bt-utils.c:168
+ 0x556e9a730224 internal_vproblem
+ ../../gdb/utils.c:396
+ 0x556e9a7304e0 _Z15internal_verrorPKciS0_P13__va_list_tag
+ ../../gdb/utils.c:476
+ 0x556e9a87aeb4 _Z18internal_error_locPKciS0_z
+ ../../gdbsupport/errors.cc:58
+ 0x556e9a29f446 process_one_event
+ ../../gdb/amd-dbgapi-target.c:1071
+ 0x556e9a29f446 process_event_queue
+ ../../gdb/amd-dbgapi-target.c:1156
+ 0x556e9a29faf2 _ZN17amd_dbgapi_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
+ ../../gdb/amd-dbgapi-target.c:1262
+ 0x556e9a6b0965 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
+ ../../gdb/target.c:2586
+ 0x556e9a4c221f do_target_wait_1
+ ../../gdb/infrun.c:3876
+ 0x556e9a4d8489 operator()
+ ../../gdb/infrun.c:3935
+ 0x556e9a4d8489 do_target_wait
+ ../../gdb/infrun.c:3964
+ 0x556e9a4d8489 _Z20fetch_inferior_eventv
+ ../../gdb/infrun.c:4365
+ 0x556e9a87b915 gdb_wait_for_event
+ ../../gdbsupport/event-loop.cc:694
+ 0x556e9a87c3a9 gdb_wait_for_event
+ ../../gdbsupport/event-loop.cc:593
+ 0x556e9a87c3a9 _Z16gdb_do_one_eventi
+ ../../gdbsupport/event-loop.cc:217
+ 0x556e9a521689 start_event_loop
+ ../../gdb/main.c:412
+ 0x556e9a521689 captured_command_loop
+ ../../gdb/main.c:476
+ 0x556e9a523c04 captured_main
+ ../../gdb/main.c:1320
+ 0x556e9a523c04 _Z8gdb_mainP18captured_main_args
+ ../../gdb/main.c:1339
+ 0x556e9a24b1bf main
+ ../../gdb/gdb.c:32
+ ---------------------
+ ../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
+ A problem internal to GDB has been detected,
+
+ Before diving into why this error appears, let's explore how things are
+ expected to work in normal circumstances. When a process being debugged
+ starts using the ROCm runtime, the following happens:
+
+ - The runtime registers itself to the driver.
+ - The driver creates a "runtime loaded" event and notifies the debugger
+ that a new event is available by writing to a file descriptor which is
+ registered in GDB's main event loop.
+ - GDB core calls the callback associated with this file descriptor
+ (dbgapi_notifier_handler). Because the amd-dbgapi-target is not
+ pushed at this point, the handler pulls the "runtime loaded" event
+ from the driver (this is the only event which can be available at this
+ point) and eventually pushes the amd-dbgapi-target on the inferior's
+ target stack.
+
+ In a nutshell, this is the expected AMDGPU runtime activation process.
+
+ From there, when new events are available regarding the GPU threads, the
+ same file descriptor is written to. The callback sees that the
+ amd-dbgapi-target is pushed so marks the amd_dbgapi_async_event_handler.
+ This will later cause amd_dbgapi_target::wait to be called. The wait
+ method pulls all the available events from the driver and handles them.
+ The wait method returns the information conveyed by the first event, the
+ other events are cached for later calls of the wait method.
+
+ Note that because we are under the wait method, we know that the
+ amd-dbgapi-target is pushed on the inferior target stack. This implies
+ that the runtime activation event has been seen already. As a
+ consequence, we cannot receive another event indicating that the runtime
+ gets activated. This is what the failing assertion checks.
+
+ In the case when we have multiple inferiors however, there is a flaw in
+ what have been described above. If one inferior (let's call it inferior
+ 1) already has the amd-dbgapi-target pushed to its target stack and
+ another inferior (inferior 2) activates the ROCm runtime, here is what
+ can happen:
+
+ - The driver creates the runtime activation for inferior 2 and writes to
+ the associated file descriptor.
+ - GDB has inferior 1 selected and calls target_wait for some reason.
+ - This prompts amd_dbgapi_target::wait to be called. The method pulls
+ all events from the driver, including the runtime activation event for
+ inferior 2, leading to the assertion failure.
+
+ The fix for this problem is simple. To avoid such problem, we need to
+ make sure that amd_dbgapi_target::wait only pulls events for the current
+ inferior from the driver. This is what this patch implements.
+
+ This patch also includes a testcase which could fail before this patch.
+
+ This patch has been tested on a system with multiple GPUs which had more
+ chances to reproduce the original bug. It has also been tested on top
+ of the downstream ROCgdb port which has more AMDGPU related tests. The
+ testcase has been tested with `make check check-read1 check-readmore`.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-31 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/testsuite/rocm: Add the hip_devices_support_debug_multi_process proc
+ It is not possible to debug multiple processes simultaneously on all
+ generations of AMDGPU devices. As some tests will need to debug
+ multiple inferiors using AMDGPU devices, we need to ensure that all
+ devices available have the required capability. Failing to do so would
+ result in GDB not being able to debug all inferiors properly.
+
+ Add the hip_devices_support_debug_multi_process helper function used to
+ ensure that all devices available can debug multiple processes.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-31 Tom Tromey <tromey@adacore.com>
+
+ Set PYTHONMALLOC in the test suite
+ Setting PYTHONMALLOC helped me locate an earlier bug. It seems to me
+ that there aren't big downsides to always setting this during testing,
+ and it might help find other bugs in the future.
+
+2023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: opcodes: fix regression in BPF disassembler
+ This patch fixes a regression recently introduced in the BPF
+ disassembler, that was assuming an abfd was always available in
+ info->section->owner. Apparently this is not so in GDB, and therefore
+ https://sourceware.org/bugzilla/show_bug.cgi?id=30705.
+
+ Tested in bpf-unkonwn-none.
+
+ opcodes/ChangeLog:
+
+ 2023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ PR 30705
+ * bpf-dis.c (print_insn_bpf): Check that info->section->owner is
+ actually available before using it.
+
+2023-07-31 Nick Clifton <nickc@redhat.com>
+
+ Updated Spanish translation for the gprof directory
+
+2023-07-31 Tom Tromey <tromey@adacore.com>
+
+ Restore previous sigmask in gdb.block_signals
+ Tom de Vries found a bug where, sometimes, a SIGCHLD would be
+ delivered to a non-main thread, wreaking havoc.
+
+ The problem is that gdb.block_signals after first blocking a set of
+ signals, then unblocked the same set rather than restoring the initial
+ situation. This function being called from the DAP thread lead to
+ SIGCHLD being unblocked there.
+
+ This patch fixes the problem by restoring the previous set of signals
+ instead.
+
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Reviewed-By: Tom de Vries <tdevries@suse.de>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30680
+
+2023-07-31 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix typo in the test case name
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/rouding-fail.s: Moved to...
+ * testsuite/gas/riscv/rounding-fail.s: ...here.
+ * testsuite/gas/riscv/rouding-fail.d: Moved to...
+ * testsuite/gas/riscv/rounding-fail.d: ...here.
+ * testsuite/gas/riscv/rouding-fail.l: Moved to...
+ * testsuite/gas/riscv/rounding-fail.l: ...here.
+
+2023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: sim: do not overflow instruction immediates in tests
+ This patch fixes some instructions in the BPF tests that overflow the
+ signed immediates. Note that this happened to work before by chance,
+ as GAS would silently truncate.
+
+ Tested in bpf-unknown-none.
+
+2023-07-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-31 Joel Brobecker <brobecker@adacore.com>
+
+ GDB Global Maintainer update (3 maintainers stepping down)
+ Doug Evans, Yao Qi and myself are stepping down as GDB Global
+ Maintainers. This commit therefore moves our entries to the
+ "Past Maintainers" section.
+
+ I've also removed myself as Ada maintainer, as well as MIPS
+ authorized committer.
+
+2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: include, bfd, opcodes: add EF_BPF_CPUVER ELF header flags
+ This patch adds support for EF_BPF_CPUVER bits in the ELF
+ machine-dependent header flags. These bits encode the BPF CPU
+ version for which the object file has been compiled for.
+
+ The BPF assembler is updated so it annotates the object files it
+ generates with these bits.
+
+ The BPF disassembler is updated so it honors EF_BPF_CPUVER to use the
+ appropriate ISA version if the user didn't specify an explicit ISA
+ version in the command line. Note that a value of zero in
+ EF_BPF_CPUVER is interpreted by the disassembler as "use the later
+ supported version" (the BPF CPU versions start with v1.)
+
+ The readelf utility is updated to pretty print EF_BPF_CPUVER when it
+ prints out the ELF header:
+
+ $ readelf -h a.out
+ ELF Header:
+ ...
+ Flags: 0x4, CPU Version: 4
+
+ Tested in bpf-unknown-none.
+
+ include/ChangeLog:
+
+ 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * elf/bpf.h (EF_BPF_CPUVER): Define.
+ * opcode/bpf.h (BPF_XBPF): Change from 0xf to 0xff so it fits in
+ EF_BPF_CPUVER.
+
+ binutils/ChangeLog:
+
+ 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * readelf.c (get_machine_flags): Recognize and pretty print BPF
+ machine flags.
+
+ opcodes/ChangeLog:
+
+ 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-dis.c: Initialize asm_bpf_version to -1.
+ (print_insn_bpf): Set BPF ISA version from the cpu version ELF
+ header flags if no explicit version set in the command line.
+ * disassemble.c (disassemble_init_for_target): Remove unused code.
+
+ gas/ChangeLog:
+
+ 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-bpf.h (elf_tc_final_processing): Define.
+ * config/tc-bpf.c (bpf_elf_final_processing): New function.
+
+2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas: add field overflow checking to the BPF assembler
+ This patch makes the BPF assembler to throughfully check for overflow
+ in immediates. This includes relaxed instructions.
+
+ Tested in bpf-unknown-none.
+
+ gas/ChangeLog:
+
+ 2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-bpf.c (signed_overflow): Copy function from
+ tc-aarch64.c.
+ (encode_insn): Check for overflow in constant immediates.
+ (add_relaxed_insn): Pass relax argument to encode_insn.
+ (add_fixed_insn): Likewise.
+ * testsuite/gas/bpf/disp16-overflow.d: New file.
+ * testsuite/gas/bpf/disp16-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp16-overflow.l: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.d: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.s: Likewise.
+ * testsuite/gas/bpf/disp32-overflow.l: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.d: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.s: Likewise.
+ * testsuite/gas/bpf/imm32-overflow.l: Likewise.
+ * testsuite/gas/bpf/offset16-overflow.d: Likewise.
+ * testsuite/gas/bpf/offset16-overflow.s: Likewise.
+ * testsuite/gas/bpf/offset16-overflow.l: Likewise.
+ * testsuite/gas/bpf/disp16-overflow-relax.d: Likewise.
+ * testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
+ * testsuite/gas/bpf/disp16-overflow-relax.s: Likewise.
+ * testsuite/gas/bpf/jump-relax-jump-be.d: New file.
+ * testsuite/gas/bpf/bpf.exp: Run new tests.
+
+2023-07-30 Nick Clifton <nickc@redhat.com>
+
+ Update how to make a release document after the 2.41 release
+
+2023-07-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: remove spurious comment from tc-bpf.c
+
+2023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas: support relaxation of V4 jump instructions
+ The BPF jump-always instruction (JA), like all other jump instructions
+ in the ISA, get a signed 16-bit displacement target argument denoted
+ in number of 64-bit words minus one. This can sometimes be overflown.
+
+ The BPF V4 ISA thus introduced support for a jump-always
+ instruction (JAL) that gets a signed 32-bit displacement instead.
+
+ This patch makes the BPF assembler to perform the following
+ relaxations when the disp16 field gets overflown, unless the option
+ -mno-relax is specified:
+
+ JA disp16 -> JAL disp32
+ Jxx disp16 -> Jxx +1; JA +1; JAL disp32
+
+ Documentation and tests added.
+ Tested in bpf-unknown-none.
+
+ gas/ChangeLog:
+
+ 2023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ PR gas/30690
+ * config/tc-bpf.c (struct bpf_insn): Add fields is_relaxable and
+ relaxed_exp.
+ (enum options): Add OPTION_NO_RELAX.
+ (md_longopts): Likewise for -mno-relax.
+ (do_relax): New global.
+ (md_parse_option): Handle OPTION_NO_RELAX.
+ (RELAX_BRANCH_ENCODE): Define.
+ (RELAX_BRANCH_P): Likewise.
+ (RELAX_BRANCH_LENGTH): Likewise.
+ (RELAX_BRANCH_CONST): Likewise.
+ (RELAX_BRANCH_UNCOND): Likewise.
+ (relaxed_branch_length): New function.
+ (md_estimate_size_before_relax): Likewise.
+ (read_insn_word): Likewise.
+ (encode_int16): Likewise.
+ (encode_int32): Likewise.
+ (write_insn_bytes): Likewise.
+ (md_convert_frag): Likewise.
+ (encode_insn): Likewise.
+ (install_insn_fixups): Likewise.
+ (add_fixed_insn): Likewise.
+ (add_relaxed_insn): Likewise.
+ (md_assemble): Move instruction encoding logic to the above
+ new functions.
+ * testsuite/gas/bpf/jump-relax-ja.d: New test.
+ * testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
+ * testsuite/gas/bpf/jump-relax-ja.s: And corresponding source.
+ * testsuite/gas/bpf/jump-relax-jump.d: New test.
+ * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
+ * testsuite/gas/bpf/jump-relax-jump.s: And corresponding source.
+ * testsuite/gas/bpf/bpf.exp: Run new tests.
+ * doc/c-bpf.texi (BPF Options): Document -mno-relax.
+
+2023-07-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Rename variable main_thread to main_thread_id
+ I noticed that the variable main_thread:
+ ...
+ /* The main thread. */
+
+ static std::thread::id main_thread;
+ ...
+ has a confusing name and corresponding comment, because it doesn't contain the
+ main thread, but rather the main thread's std::thread::id.
+
+ Fix this by renaming to main_thread_id.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-28 Tom Tromey <tromey@adacore.com>
+
+ Re-acquire GIL earlier in gdbpy_parse_and_eval
+ Tom de Vries filed a bug about an intermittent gdb DAP failure -- and
+ coincidentally, at the same time, Alexandra Hájková sent email about a
+ somewhat similar failure.
+
+ After looking into this for a while (with no results) using ASan and
+ valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug
+ instantly.
+
+ The problem is that gdbpy_parse_and_eval releases the GIL while
+ calling parse_and_eval, but fails to re-acquire it before calling
+ value_to_value_object. This is easily fixed by introducing a new
+ scope.
+
+ I wonder whether the test suite should unconditionally set
+ PYTHONMALLOC=malloc_debug.
+
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Reviewed-By: Tom de Vries <tdevries@suse.de>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686
+
+2023-07-28 Jan Beulich <jbeulich@suse.com>
+
+ gas: amend X_unsigned uses
+ PR gas/30688
+
+ X_unsigned being clear does not indicate a negative number; it merely
+ indicates a signed one (whose sign may still be clear). Amend two uses
+ by an actual value check.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: Support `-gnuabi64' target triplet suffix for 64-bit Linux targets
+ Make the n64 ABI the default for 64-bit Linux targets specified with
+ `-gnuabi64' suffix included in the target triplet, for configurations
+ such as the Debian mips64el and mips64r6el ports. Adjust testsuite
+ configuration accordingly.
+
+ There are the following regressions with the new target triplet:
+
+ mips64-linux-gnuabi64 +FAIL: readelf -S bintest
+ mips64-linux-gnuabi64 +FAIL: MIPS reloc estimation 1
+ mips64el-linux-gnuabi64 +FAIL: readelf -S bintest
+ mips64el-linux-gnuabi64 +FAIL: MIPS reloc estimation 1
+
+ The `readelf' issue comes from a difference in section headers produced
+ that the `binutils/testsuite/binutils-all/readelf.s-64' pattern template
+ does not match. While there has been a precedent it does not appear to
+ me that there is a clear advantage from adding more and more variations
+ to the template rather than forking the existing template into multiple
+ ones for a more exact match. So this is best deferred to a separate
+ discussion.
+
+ The MIPS reloc estimation issue is an actual bug in `objdump', which
+ discards a number of trailing entries from output here for n64 composed
+ relocations:
+
+ DYNAMIC RELOCATION RECORDS
+ OFFSET TYPE VALUE
+ 0000000000000000 R_MIPS_NONE *ABS*
+ 0000000000000000 R_MIPS_NONE *ABS*
+
+ and consequently `ld/testsuite/ld-mips-elf/reloc-estimate-1.d' does not
+ match even though ELF output produced is correct according to `readelf':
+
+ Relocation section '.rel.dyn' at offset 0x10400 contains 2 entries:
+ Offset Info Type Sym. Value Sym. Name
+ 000000000000 000000000000 R_MIPS_NONE
+ Type2: R_MIPS_NONE
+ Type3: R_MIPS_NONE
+ 000000010000 000300001203 R_MIPS_REL32 0000000000010010 foo@@V2
+ Type2: R_MIPS_64
+ Type3: R_MIPS_NONE
+
+ As a genuine bug this has to be handled separately.
+
+ Co-Authored by: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ bfd/
+ * config.bfd: Add `mips64*el-*-linux*-gnuabi64' and
+ `mips64*-*-linux*-gnuabi64' targets.
+
+ binutils/
+ * testsuite/binutils-all/mips/mips.exp: Handle `*-*-*-gnuabi64'
+ targets.
+ * testsuite/binutils-all/objcopy.exp: Handle
+ `mips64*-*-*-gnuabi64' targets.
+ * testsuite/binutils-all/remove-relocs-01.d: Likewise.
+ * testsuite/binutils-all/remove-relocs-04.d: Likewise.
+ * testsuite/binutils-all/remove-relocs-05.d: Likewise.
+ * testsuite/binutils-all/remove-relocs-06.d: Likewise.
+
+ gas/
+ * configure.ac: Handle `mips64*-linux-gnuabi64' targets.
+ * configure: Regenerate.
+ * testsuite/gas/mips/compact-eh-eb-7.d: Handle
+ `mips64*-*-*-gnuabi64' targets.
+ * testsuite/gas/mips/compact-eh-el-7.d: Likewise.
+
+ ld/
+ * configure.tgt: Add `mips64*el-*-linux-gnuabi64' and
+ `mips64*-*-linux-gnuabi64' targets.
+ * testsuite/ld-undefined/undefined.exp: Handle
+ `mips64*-*-*-gnuabi64' targets.
+ * testsuite/ld-mips-elf/attr-gnu-4-10.d: Likewise.
+ * testsuite/ld-mips-elf/compact-eh6.d: Likewise.
+ * testsuite/ld-mips-elf/mips-elf.exp: Handle `*-*-*-gnuabi64'
+ targets.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/GAS/testsuite: Fix n64 compact EH failures
+ Expect a `.MIPS.options' section alternatively to `.reginfo' and ignore
+ contents of either as irrelevant for all the affected compact EH tests,
+ removing these regressions:
+
+ mips64-openbsd -FAIL: Compact EH EB #1 with personality ID and FDE data
+ mips64-openbsd -FAIL: Compact EH EB #2 with personality routine and FDE data
+ mips64-openbsd -FAIL: Compact EH EB #3 with personality id and large FDE data
+ mips64-openbsd -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA
+ mips64-openbsd -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA
+ mips64-openbsd -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data
+ mips64-openbsd -FAIL: Compact EH EL #1 with personality ID and FDE data
+ mips64-openbsd -FAIL: Compact EH EL #2 with personality routine and FDE data
+ mips64-openbsd -FAIL: Compact EH EL #3 with personality id and large FDE data
+ mips64-openbsd -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA
+ mips64-openbsd -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA
+ mips64-openbsd -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data
+ mips64el-openbsd -FAIL: Compact EH EB #1 with personality ID and FDE data
+ mips64el-openbsd -FAIL: Compact EH EB #2 with personality routine and FDE data
+ mips64el-openbsd -FAIL: Compact EH EB #3 with personality id and large FDE data
+ mips64el-openbsd -FAIL: Compact EH EB #4 with personality id, FDE data and LSDA
+ mips64el-openbsd -FAIL: Compact EH EB #5 with personality routine, FDE data and LSDA
+ mips64el-openbsd -FAIL: Compact EH EB #6 with personality id, LSDA and large FDE data
+ mips64el-openbsd -FAIL: Compact EH EL #1 with personality ID and FDE data
+ mips64el-openbsd -FAIL: Compact EH EL #2 with personality routine and FDE data
+ mips64el-openbsd -FAIL: Compact EH EL #3 with personality id and large FDE data
+ mips64el-openbsd -FAIL: Compact EH EL #4 with personality id, FDE data and LSDA
+ mips64el-openbsd -FAIL: Compact EH EL #5 with personality routine, FDE data and LSDA
+ mips64el-openbsd -FAIL: Compact EH EL #6 with personality id, LSDA and large FDE data
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ gas/
+ * testsuite/gas/mips/compact-eh-eb-1.d: Accept `.MIPS.options'
+ section as an alternative to `.reginfo' and ignore contents of
+ either.
+ * testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-1.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-6.d: Likewise.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ testsuite: Handle composed R_MIPS_NONE relocations
+ MIPS n64 ABI has a peculiarity where all relocations are composed of
+ three, with subsequent relocation types set to R_MIPS_NONE if further
+ calculation is not required. Example output produced by `readelf' and
+ `objdump' for such relocations is:
+
+ Offset Info Type Sym. Value Sym. Name + Addend
+ 000000000000 000800000002 R_MIPS_32 0000000000000000 foo + 0
+ Type2: R_MIPS_NONE
+ Type3: R_MIPS_NONE
+
+ and:
+
+ OFFSET TYPE VALUE
+ 0000000000000000 R_MIPS_32 foo
+ 0000000000000000 R_MIPS_NONE *ABS*
+ 0000000000000000 R_MIPS_NONE *ABS*
+
+ respectively. The presence of these extra R_MIPS_NONE entries is not
+ relevant for generic or even some MIPS tests, so optionally match them
+ with the respective dump patterns, also discarding `xfail' annotation
+ for MIPS/OpenBSD targets from gas/elf/missing-build-notes.d, removing
+ these regressions:
+
+ mips64-openbsd -FAIL: readelf -r bintest
+ mips64-openbsd -FAIL: forward expression
+ mips64-openbsd -FAIL: assignment tests
+ mips64-openbsd -FAIL: gas/all/none
+ mips64-openbsd -XFAIL: gas/elf/missing-build-notes
+ mips64-openbsd -FAIL: macro test 2
+ mips64-openbsd -FAIL: macro irp
+ mips64-openbsd -FAIL: macro rept
+ mips64-openbsd -FAIL: nested irp/irpc/rept
+ mips64-openbsd -FAIL: macro vararg
+ mips64-openbsd -FAIL: mips jalx
+ mips64-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
+ mips64el-openbsd -FAIL: readelf -r bintest
+ mips64el-openbsd -FAIL: forward expression
+ mips64el-openbsd -FAIL: assignment tests
+ mips64el-openbsd -FAIL: gas/all/none
+ mips64el-openbsd -XFAIL: gas/elf/missing-build-notes
+ mips64el-openbsd -FAIL: macro test 2
+ mips64el-openbsd -FAIL: macro irp
+ mips64el-openbsd -FAIL: macro rept
+ mips64el-openbsd -FAIL: nested irp/irpc/rept
+ mips64el-openbsd -FAIL: macro vararg
+ mips64el-openbsd -FAIL: mips jalx
+ mips64el-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ binutils/
+ * testsuite/binutils-all/readelf.r-64: Optionally match extra
+ R_MIPS_NONE pairs.
+
+ gas/
+ * testsuite/gas/all/assign.d: Optionally match extra
+ R_MIPS_NONE pairs.
+ * testsuite/gas/all/fwdexp.d: Likewise.
+ * testsuite/gas/all/none.d: Likewise.
+ * testsuite/gas/macros/irp.d: Likewise.
+ * testsuite/gas/macros/repeat.d: Likewise.
+ * testsuite/gas/macros/rept.d: Likewise.
+ * testsuite/gas/macros/test2.d: Likewise.
+ * testsuite/gas/macros/vararg.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-1.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-1.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-6.d: Likewise.
+ * testsuite/gas/mips/loongson-2f-3.d: Likewise.
+ * testsuite/gas/mips/mips-jalx.d: Likewise.
+ * testsuite/gas/elf/missing-build-notes.d: Likewise. Remove
+ the `xfail' tag.
+
+ ld/
+ * testsuite/ld-mips-elf/reloc-estimate-1.d: Optionally match
+ extra R_MIPS_NONE pairs.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/testsuite: Handle 64-bit addresses
+ Several MIPS test cases are suitable for the n64 ABI if not for the
+ extra leading zeros or spaces in addresses not handled by dump patterns.
+ Match the characters then, removing these regressions:
+
+ mips64-openbsd -FAIL: .set arch=FOO
+ mips64-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue
+ mips64-openbsd -FAIL: MIPS DSP ASE for MIPS64
+ mips64-openbsd -FAIL: gas/mips/align2
+ mips64-openbsd -FAIL: gas/mips/align2-el
+ mips64-openbsd -FAIL: Locally-resolvable PC-relative code references
+ mips64-openbsd -FAIL: MIPS jalx-1
+ mips64-openbsd -FAIL: JAL overflow 2
+ mips64el-openbsd -FAIL: .set arch=FOO
+ mips64el-openbsd -FAIL: ST Microelectronics Loongson-2F workarounds of nop issue
+ mips64el-openbsd -FAIL: MIPS DSP ASE for MIPS64
+ mips64el-openbsd -FAIL: gas/mips/align2
+ mips64el-openbsd -FAIL: gas/mips/align2-el
+ mips64el-openbsd -FAIL: Locally-resolvable PC-relative code references
+ mips64el-openbsd -FAIL: MIPS jalx-1
+ mips64el-openbsd -FAIL: JAL overflow 2
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ gas/
+ * testsuite/gas/mips/align2-el.d: Match extra leading zeros
+ with addresses.
+ * testsuite/gas/mips/align2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-1.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-eb-6.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-1.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-2.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-3.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-4.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-5.d: Likewise.
+ * testsuite/gas/mips/compact-eh-el-6.d: Likewise.
+ * testsuite/gas/mips/loongson-2f-2.d: Likewise.
+ * testsuite/gas/mips/loongson-2f-3.d: Likewise.
+ * testsuite/gas/mips/mips-jalx.d: Likewise.
+ * testsuite/gas/mips/mips64-dsp.d: Likewise.
+ * testsuite/gas/mips/pcrel-1.d: Likewise.
+ * testsuite/gas/mips/set-arch.d: Likewise.
+
+ ld/
+ * testsuite/ld-mips-elf/jaloverflow-2.d: Match extra leading
+ zeros and spaces with addresses as appropriate.
+ * testsuite/ld-mips-elf/jalx-1.d: Likewise.
+ * testsuite/ld-mips-elf/reloc-estimate-1.d: Likewise.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ testsuite: Also discard the `.MIPS.options' section
+ Also discard the `.MIPS.options' section, used with n64 MIPS binaries,
+ along with similar other MIPS sections (`.reginfo', `.MIPS.abiflags')
+ not relevant for the test cases concerned, fixing these regressions:
+
+ mips64-openbsd -FAIL: ld-elf/group3a
+ mips64-openbsd -FAIL: ld-elf/group3b
+ mips64-openbsd -FAIL: Place orphan sections (map file check)
+ mips64-openbsd -FAIL: ld-elf/orphan-region
+ mips64-openbsd -FAIL: ld-elf/orphan
+ mips64-openbsd -FAIL: overlay size (map file check)
+ mips64-openbsd -FAIL: overlay size
+ mips64el-openbsd -FAIL: ld-elf/group3a
+ mips64el-openbsd -FAIL: ld-elf/group3b
+ mips64el-openbsd -FAIL: Place orphan sections (map file check)
+ mips64el-openbsd -FAIL: ld-elf/orphan-region
+ mips64el-openbsd -FAIL: ld-elf/orphan
+ mips64el-openbsd -FAIL: overlay size (map file check)
+ mips64el-openbsd -FAIL: overlay size
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ binutils/
+ * testsuite/binutils-all/strip-3.d: Add `-R .MIPS.options' to
+ the `strip' tag.
+
+ ld/
+ * testsuite/ld-elf/group.ld: Also discard `.MIPS.options'.
+ * testsuite/ld-elf/orphan-region.ld: Likewise.
+ * testsuite/ld-elf/orphan.ld: Likewise.
+ * testsuite/ld-mips-elf/got-page-1.ld: Likewise.
+ * testsuite/ld-scripts/overlay-size.t: Likewise.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Fix MIPS16 interlinking test IRIX 6 regressions
+ IRIX 6 does not have MIPS16 stub section support in its n32 linker
+ scripts, causing such input sections to be propagated to the respective
+ output sections rather than `.text', causing dump pattern mismatches.
+
+ Expect IRIX 6 to fail with n32 testing then, removing this regression:
+
+ mips-sgi-irix6 -FAIL: MIPS16 interlinking for local functions 1 (n32)
+
+ We may choose to update IRIX 6 n32 linker scripts sometime, as it seems
+ a harmless change.
+
+ ld/
+ * testsuite/ld-mips-elf/mips-elf.exp: Expect IRIX 6 to fail with
+ n32 `mips16-local-stubs-1' testing.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/LD/testsuite: Fix MIPS16 interlinking test n64 regressions
+ The MIPS16 interlinking test for local functions expects to be assembled
+ with 32-bit addressing, otherwise causing assembly warnings:
+
+ .../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s: Assembler messages:
+ .../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s:16: Warning: la used to load 64-bit address; recommend using dla instead
+
+ Use the per-ABI framework then to run the test explicitly for o32 and
+ n32 ABIs only, replacing the `-mips4' option from the `as' tag with
+ `.module mips4' pseudo-op within the source itself so as to avoid
+ assembly errors:
+
+ Assembler messages:
+ Error: -mips4 conflicts with the other architecture options, which imply -mips3
+
+ with n32 testing for some targets, and ultimately removing these
+ regressions:
+
+ mips64-openbsd -FAIL: MIPS16 interlinking for local functions 1
+ mips64el-openbsd -FAIL: MIPS16 interlinking for local functions 1
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ ld/
+ * testsuite/ld-mips-elf/mips16-local-stubs-1.d: Remove `-mips4'
+ from the `as' tag.
+ * testsuite/ld-mips-elf/mips16-local-stubs-1.s: Add `.module
+ mips4'.
+ * testsuite/ld-mips-elf/mips-elf.exp: Run `mips16-local-stubs-1'
+ for o32 and n32 ABIs only.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/GAS/testsuite: Force o32 for tests expecting 32-bit addressing
+ A few GAS tests expect to be assembled with 32-bit addressing, otherwise
+ causing an assembly warning:
+
+ .../gas/testsuite/gas/mips/fix-rm7000-2.s:11: Warning: la used to load 64-bit address; recommend using dla instead
+
+ or pattern dump mismatches against 32-bit address calculations, however
+ these tests do not enforce their expectation in any. For none of them
+ the specific ABI used is of any relevance however, so select the o32 ABI
+ unconditionally, removing these failures with OpenBSD targets:
+
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (micromips)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips3)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips4)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips5)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r2)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r3)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r5)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon2)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon3)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeonp)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (r4000)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (sb1)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (vr5400)
+ mips64-openbsd -FAIL: MIPS RM7000 workarounds test 2 (xlr)
+ mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2)
+ mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3)
+ mips64-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp)
+ mips64-openbsd -FAIL: Full MIPS R5900
+ mips64-openbsd -FAIL: MIPS R5900 VU0
+ mips64-openbsd -FAIL: Paired LL/SC for mips64r6 (mips64r6)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (micromips)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips3)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips4)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips5)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r2)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r3)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (mips64r5)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon2)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeon3)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (octeonp)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (r4000)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (sb1)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (vr5400)
+ mips64el-openbsd -FAIL: MIPS RM7000 workarounds test 2 (xlr)
+ mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon2)
+ mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeon3)
+ mips64el-openbsd -FAIL: MIPS-OCTEON octeon_saa_saad (octeonp)
+ mips64el-openbsd -FAIL: Full MIPS R5900
+ mips64el-openbsd -FAIL: MIPS R5900 VU0
+ mips64el-openbsd -FAIL: Paired LL/SC for mips64r6 (mips64r6)
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ gas/
+ * testsuite/gas/mips/fix-rm7000-2.d: Add `-32' to the `as' tag.
+ * testsuite/gas/mips/micromips@fix-rm7000-2.d: Likewise.
+ * testsuite/gas/mips/r5900-full.d: Likewise.
+ * testsuite/gas/mips/r5900-vu0.d: Likewise.
+ * testsuite/gas/mips/llpscp-64.d: Add `as' tag with `-32'.
+ * testsuite/gas/mips/octeon-saa-saad.d: Likewise.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Run `got-dump-1' for o32/n32 ABIs
+ The `got-dump-1' test case uses 32-bit addressing, so it makes no sense
+ to run it with the n64 ABI. And there is a corresponding `got-dump-2'
+ test already for the n64 ABI.
+
+ Use the per-ABI framework then to run the `got-dump-1' test explicitly
+ for o32 and n32 ABIs only.
+
+ ld/
+ * testsuite/ld-mips-elf/mips-elf.exp: Run `got-dump-1' for o32
+ and n32 ABIs only.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with OpenBSD targets
+ OpenBSD targets produce ELF64 files while the pattern dump expects ELF32
+ output and specific header sizes. Disable it for `mips64*-*-openbsd*'
+ for these targets then, removing these failures:
+
+ mips64-openbsd -FAIL: ld-mips-elf/attr-gnu-4-10
+ mips64el-openbsd -FAIL: ld-mips-elf/attr-gnu-4-10
+
+ ld/
+ * testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `notarget' tag with
+ `mips64*-*-openbsd*'.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Fix `attr-gnu-4-10' failures with IRIX targets
+ IRIX targets do not enable the production of a `.pdr' section in GAS by
+ default, which causes a failure with the `attr-gnu-4-10' test case due
+ to a difference resulting in the number and indices of sections produced
+ in linker output.
+
+ As the presence or absence of this section is not relevant to this test
+ case, just enable it unconditionally, fixing these regressions:
+
+ mips-sgi-irix5 -FAIL: ld-mips-elf/attr-gnu-4-10
+ mips-sgi-irix6 -FAIL: ld-mips-elf/attr-gnu-4-10
+
+ ld/
+ * testsuite/ld-mips-elf/attr-gnu-4-10.d: Add `as' tag with
+ `-mpdr'.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Fix JALR relaxation test failure with IRIX 6
+ The `mips-sgi-irix6' target only supports IRIX linker emulations, but
+ most JALR relaxation tests request the relevant traditional emulation
+ instead, causing a link failure:
+
+ ./ld-new: unrecognised emulation mode: elf32btsmipn32
+ Supported emulations: elf32bmipn32 elf32bsmip elf64bmip
+
+ This is clearly an omission from the conversion to use the per-ABI
+ framework made with commit 78da84f99405 ("MIPS/LD/testsuite: Correct
+ mips-elf.exp test ABI/emul/endian arrangement"). These tests are also
+ endianness agnostic, which was missed in the conversion as well.
+
+ Remove the unnecessary explicit ABI and endianness options then and rely
+ on the per-ABI framework to get things right, removing this regression:
+
+ mips-sgi-irix6 -FAIL: MIPS relax-jalr-shared n32
+
+ ld/
+ * testsuite/ld-mips-elf/relax-jalr-n32-shared.d: Remove flags
+ related to ABI and endianness selection from the `as' and `ld'
+ tags.
+ * testsuite/ld-mips-elf/relax-jalr-n64.d: Likewise.
+ * testsuite/ld-mips-elf/relax-jalr-n64-shared.d: Likewise.
+ * testsuite/ld-mips-elf/mips-elf.exp: Remove `as' and `ld' tag
+ additions from the invocation of JALR relaxation tests.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/LD/testsuite: Fix unaligned JALX failures with OpenBSD targets
+ There are only n64 linker emulations included with `mips64*-*-openbsd*'
+ targets, however the unaligned JALX tests insist on running across all
+ targets and force the n32 ABI, causing link errors with the targets
+ concerned, e.g.:
+
+ ./ld-new: tmpdir/unaligned-jalx-0.o: ABI is incompatible with that of the selected emulation
+ ./ld-new: failed to merge target specific data of file tmpdir/unaligned-jalx-0.o
+ ./ld-new: tmpdir/unaligned-insn.o: ABI is incompatible with that of the selected emulation
+ ./ld-new: failed to merge target specific data of file tmpdir/unaligned-insn.o
+
+ Convert the tests then to use the per-ABI framework and run them for the
+ o32 and n32 ABIs, removing these regressions:
+
+ mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 0
+ mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 1
+ mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 2
+ mips64-openbsd -FAIL: MIPS JALX to unaligned symbol 3
+ mips64-openbsd -FAIL: MIPS16 JALX to unaligned symbol 0
+ mips64-openbsd -FAIL: MIPS16 JALX to unaligned symbol 1
+ mips64-openbsd -FAIL: microMIPS JALX to unaligned symbol 0
+ mips64-openbsd -FAIL: microMIPS JALX to unaligned symbol 1
+ mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 0
+ mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 1
+ mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 2
+ mips64el-openbsd -FAIL: MIPS JALX to unaligned symbol 3
+ mips64el-openbsd -FAIL: MIPS16 JALX to unaligned symbol 0
+ mips64el-openbsd -FAIL: MIPS16 JALX to unaligned symbol 1
+ mips64el-openbsd -FAIL: microMIPS JALX to unaligned symbol 0
+ mips64el-openbsd -FAIL: microMIPS JALX to unaligned symbol 1
+
+ Similar tests for the n64 ABI can be added separately, using suitable
+ dump patterns.
+
+ ld/
+ * testsuite/ld-mips-elf/unaligned-jalx-0.d: Remove `-32' from
+ the `as' tag.
+ * testsuite/ld-mips-elf/unaligned-jalx-1.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-2.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-3.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-mips16-0.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-mips16-1.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-micromips-0.d: Likewise.
+ * testsuite/ld-mips-elf/unaligned-jalx-micromips-1.d: Likewise.
+ * testsuite/ld-mips-elf/mips-elf.exp: Run unaligned JALX tests
+ with `run_dump_test_o32' and `run_dump_test_n32' rather than
+ `run_dump_test'.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/GAS/testsuite: Disable compact EH #7 tests with OpenBSD targets
+ Compact EH #7 tests use output templates that are not suitable for the
+ n64 ABI, which `mips64*-*-openbsd*' targets use by default, because the
+ contents of the sections examined are expected to be differnt. Disable
+ the tests then, removing these regressions:
+
+ mips64-openbsd -FAIL: Compact EH EB #7 with personality id and fallback FDE
+ mips64-openbsd -FAIL: Compact EH EL #7 with personality id and fallback FDE
+ mips64el-openbsd -FAIL: Compact EH EB #7 with personality id and fallback FDE
+ mips64el-openbsd -FAIL: Compact EH EL #7 with personality id and fallback FDE
+
+ Suitable corresponding tests for the n64 ABI can be added separately.
+
+ gas/
+ * testsuite/gas/mips/compact-eh-eb-7.d: Exclude for
+ `mips64*-*-openbsd*'.
+ * testsuite/gas/mips/compact-eh-el-7.d: Likewise.
+
+2023-07-28 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS/LD: Include n64 `.interp' with INITIAL_READONLY_SECTIONS
+ In ld/emulparams/elf64bmip-defs.sh there is no explicit handling of the
+ `.interp' section, which causes it to be positioned in output at an odd
+ place.
+
+ Let's include it with INITIAL_READONLY_SECTIONS, just like o32/n32 do,
+ fixing a regression from commit 5a8e7be242f3 ("INITIAL_READONLY_SECTIONS
+ in elf.sc"), where the handling of n64 was missed due to an unfortunate
+ sequence of events where ld/emulparams/elf64bmip-defs.sh was only added
+ with commit 94bb04b3c611 ("Use .reginfo rather than .MIPS.options in n32
+ linker scripts") the day before.
+
+ Add test cases covering section ordering across the three ABIs. This
+ change also fixes ld/pr23658-2:
+
+ FAIL: Build pr23658-2
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+ ld/ChangeLog:
+ * emulparams/elf64bmip-defs.sh: Include `.interp' with
+ INITIAL_READONLY_SECTIONS.
+ * testsuite/ld-mips-elf/pie-n64.d: Adjust addresses.
+ * testsuite/ld-mips-elf/sections-1-o32.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-o32t.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-n32.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-n32t.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-n32p.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-n64.rd: New test.
+ * testsuite/ld-mips-elf/sections-1-n64t.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-o32.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-o32t.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-n32.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-n32t.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-n32p.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-n64.rd: New test.
+ * testsuite/ld-mips-elf/sections-2-n64t.rd: New test.
+ * testsuite/ld-mips-elf/sections.s: New test source.
+ * testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
+
+2023-07-28 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ Revert "MIPS: support mips*64 as CPU and gnuabi64 as ABI"
+ This reverts commit 32f1c80375ebe8ad25d9805ee5889f0006c51e59. It had
+ two unrelated changes lumped together, one of which changed the meaning
+ of the `mipsisa64*-*-linux*' target triplets, which was not properly
+ evaluated.
+
+2023-07-28 Alan Modra <amodra@gmail.com>
+
+ ldscripts/empty-address vs. xcoff
+ The empty-address tests check that if a section is removed by ld due
+ to being empty then properties of that section don't affect following
+ addresses. The xcoff backend doesn't remove the empty .data section
+ created by empty-address-2* and empty-address-3* for some reason, and
+ therefore fails the test.
+
+ * testsuite/ld-scripts/empty-address-1.d: Accept more symbols.
+ * testsuite/ld-scripts/empty-address-2a.d: xfail for xcoff.
+ * testsuite/ld-scripts/empty-address-2b.d: Likewise.
+ * testsuite/ld-scripts/empty-address-3a.d: Likewise.
+ * testsuite/ld-scripts/empty-address-3b.d: Likewise.
+
+2023-07-28 Alan Modra <amodra@gmail.com>
+
+ Fix recent x86 pe/coff testsuite regressions
+ * testsuite/gas/i386/sha512-intel.d: Accept section nop padding.
+ * testsuite/gas/i386/sha512.d: Likewise.
+ * testsuite/gas/i386/sm3-intel.d: Likewise.
+ * testsuite/gas/i386/sm3.d: Likewise.
+ * testsuite/gas/i386/x86-64-pbndkb-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-pbndkb.d: Likewise.
+ * testsuite/gas/i386/x86-64-sha512-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-sha512.d: Likewise.
+ * testsuite/gas/i386/x86-64-sm3-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-sm3.d: Likewise.
+
+2023-07-28 Alan Modra <amodra@gmail.com>
+
+ coff/pe/xcoff and --extract-symbols
+ This fixes failure of the "extract symbols" test for rs6000, where
+ --extract-symbols generates a non-zero sized .text. By the look of
+ coffcode.h the same problem might occur for coff/pe too, but doesn't
+ happen to trigger a test failure.
+
+ bfd/
+ * coffcode.h (coff_compute_section_file_positions): Don't
+ adjust size of !SEC_LOAD sections.
+ binutils/
+ * objcopy.c (setup_section): Clear SEC_LOAD for --extract-symbol.
+
+2023-07-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add actual 'Zvkt' extension support
+ The 'Zvkt' extension is listed on the added extensions in the GNU Binutils
+ version 2.41 (see binutils/NEWS). However, the support of this extension
+ was actually missing.
+
+ This commit adds actual support of this extension and adds implications
+ from 'Zvkn' and 'Zvks' superset extensions.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets) Add implications from
+ 'Zvkn' and 'Zvks'. (riscv_supported_std_z_ext): Add 'Zvkt' to
+ the supported extension list.
+
+2023-07-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ Fix typo in riscv-dis.c comment
+ Don't go "past" the start of the section.
+
+2023-07-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove trailing empty line in target-delegates.c
+ In a review [1], I pointed out that applying the patch, git would say:
+
+ .git/rebase-apply/patch:147: new blank line at EOF.
+
+ However, since the empty line is in target-delegates.c (a generated
+ file), there's nothing the author can do about it. To avoid this
+ comment coming up again in the future, change make-target-delegates.py
+ to avoid the trailing empty line. Do this by making it output empty
+ lines before each entity, not after.
+
+ Since this needs removing a newline output in gdbcopyright, adjust
+ ada-unicode.py and gdbarch.py to avoid changes in the files they
+ generate.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20230427210113.45380-1-jhb@FreeBSD.org/T/#m083598405bef19157f67c9d97846d3dd90dc7d1c
+
+ Change-Id: Ic4c648f06443b432168cb76603402c918aa6e5d2
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-27 Tom Tromey <tromey@adacore.com>
+
+ Report supportsBreakpointLocationsRequest
+ While looking at the DAP spec, I noticed that the breakpointLocations
+ request is gated behind a capability. This patch changes gdb to
+ report this capability.
+
+ I've also added a comment to explain the fact that arguments to
+ breakpointLocations are not optional, even though the spec says they
+ are.
+
+2023-07-27 Alan Modra <amodra@gmail.com>
+
+ /DISCARD/ in ld testsuite
+ The canonical form to discard all sections not mentioned earlier in
+ the script is
+ /DISCARD/ : { *(*) }
+ not
+ /DISCARD/ : { *(.*) }
+ ".*" happens to work with the usual section names starting with a dot,
+ but let's not promote something not quite right.
+
+2023-07-27 Alan Modra <amodra@gmail.com>
+
+ sh: uninitialised sh_operand_info.type in get_specific
+ Seen when running gas/testsuite/gas/sh/err-at.s
+
+ * config/tc-sh.c (get_operands): Always init operand type.
+ * testsuite/gas/sh/err-at.s: Expect unnecessary extra errors.
+
+2023-07-27 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support Intel PBNDKB
+ gas/ChangeLog:
+
+ * NEWS: Support Intel PBNDKB.
+ * config/tc-i386.c: Add pbndkb.
+ * doc/c-i386.texi: Document .pbndkb.
+ * testsuite/gas/i386/i386.exp: Add PBNDKB tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/pbndkb-inval.l: New test.
+ * testsuite/gas/i386/pbndkb-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-pbndkb-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-pbndkb.d: Ditto.
+ * testsuite/gas/i386/x86-64-pbndkb.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_7): New.
+ (X86_64_0F01_REG_0_MOD_3_RM_7_P_0): Ditto.
+ (prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_7.
+ (x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_7_P_0.
+ (rm_table): New entry for pbndkb.
+ * i386-gen.c (cpu_flag): Add PBNDKB.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (CpuPBNDKB): New.
+ (i386_cpu_flags): Add cpupbndkb.
+ * i386-opc.tbl: Add PBNDKB instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-07-27 Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel SM4
+ gas/ChangeLog:
+
+ * NEWS: Support Intel SM4.
+ * config/tc-i386.c: Add sm4.
+ * doc/c-i386.texi: Document .sm4.
+ * testsuite/gas/i386/i386.exp: Run SM4 tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/sm4-intel.d: Add SM4 tests.
+ * testsuite/gas/i386/sm4.d: Ditto.
+ * testsuite/gas/i386/sm4.s: Ditto.
+ * testsuite/gas/i386/x86-64-sm4-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-sm4.d: Ditto.
+ * testsuite/gas/i386/x86-64-sm4.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (prefix_table): Add SM4 instructions.
+ * i386-gen.c (isa_dependencies): Add SM4.
+ (cpu_flags): Ditto.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (CpuSM4): New.
+ (i386_cpu_flags): Add cpusm4.
+ * i386-opc.tbl: Add SM4 instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-07-27 Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel SM3
+ gas/ChangeLog:
+
+ * NEWS: Support Intel SM3.
+ * config/tc-i386.c: Add sm3.
+ * doc/c-i386.texi: Document .sm3.
+ * testsuite/gas/i386/i386.exp: Run sm3 tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/sm3-intel.d: New test.
+ * testsuite/gas/i386/sm3.d: Ditto.
+ * testsuite/gas/i386/sm3.s: Ditto.
+ * testsuite/gas/i386/x86-64-sm3-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-sm3.d: Ditto.
+ * testsuite/gas/i386/x86-64-sm3.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (PREFIX_VEX_0F38DA_W_0): New.
+ (VEX_LEN_0F38DA_W_0_P_0): Ditto.
+ (VEX_LEN_0F38DA_W_0_P_2): Ditto.
+ (VEX_LEN_0F3ADE_W_0): Ditto.
+ (VEX_W_0F38DA): Ditto.
+ (VEX_W_0F3ADE): Ditto.
+ (prefix_table): Add PREFIX_VEX_0F38DA_W_0.
+ (vex_len_table): Add VEX_LEN_0F38DA_W_0_P_0,
+ VEX_LEN_0F38DA_W_0_P_2, VEX_LEN_0F3ADE_W_0.
+ (vex_w_table): Add VEX_W_0F38DA, VEX_W_0F3ADE.
+ * i386-gen.c (isa_dependencies): Add SM3.
+ (cpu_flags): Ditto.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (CpuSM3): New.
+ (i386_cpu_flags): Add cpusm3.
+ * i386-opc.tbl: Add SM3 instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-07-27 Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel SHA512
+ gas/ChangeLog:
+
+ * NEWS: Support Intel SHA512.
+ * config/tc-i386.c: Add sha512.
+ * doc/c-i386.texi: Document .sha512.
+ * testsuite/gas/i386/disassem.d: Add SHA512 tests.
+ * testsuite/gas/i386/disassem.s: Ditto.
+ * testsuite/gas/i386/i386.exp: Run SHA512 tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/sha512-intel.d: New test.
+ * testsuite/gas/i386/sha512-inval.l: Ditto.
+ * testsuite/gas/i386/sha512-inval.s: Ditto.
+ * testsuite/gas/i386/sha512.d: Ditto.
+ * testsuite/gas/i386/sha512.s: Ditto.
+ * testsuite/gas/i386/x86-64-sha512-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-sha512-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-sha512-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-sha512.d: Ditto.
+ * testsuite/gas/i386/x86-64-sha512.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (Rxmmq): New.
+ (Rymm): Ditto.
+ (PREFIX_VEX_0F38CB): Ditto.
+ (PREFIX_VEX_0F38CC): Ditto.
+ (PREFIX_VEX_0F38CD): Ditto.
+ (VEX_LEN_0F38CB_P_3_W_0): Ditto.
+ (VEX_LEN_0F38CC_P_3_W_0): Ditto.
+ (VEX_LEN_0F38CD_P_3_W_0): Ditto.
+ (VEX_W_0F38CB_P_3): Ditto.
+ (VEX_W_0F38CC_P_3): Ditto.
+ (VEX_W_0F38CD_P_3): Ditto.
+ (prefix_table): Add PREFIX_VEX_0F38CB, PREFIX_VEX_0F38CC,
+ PREFIX_VEX_0F38CD.
+ (vex_len_table): Add VEX_LEN_0F38CB_P_3_W_0,
+ VEX_LEN_0F38CC_P_3_W_0, VEX_LEN_0F38CD_P_3_W_0.
+ (vex_w_table): Add VEX_W_0F38CB_P_3, VEX_W_0F38CC_P_3, VEX_W_0F38CD_P_3.
+ * i386-gen.c (isa_dependencies): Add SHA512.
+ (cpu_flags): Ditto.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (CpuSHA512): New.
+ (i386_cpu_flags): Add cpusha512.
+ * i386-opc.tbl: Add SHA512 instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-07-27 konglin1 <lingling.kong@intel.com>
+
+ Support Intel AVX-VNNI-INT16
+ gas/ChangeLog:
+
+ * NEWS: Support Intel AVX-VNNI-INT16.
+ * config/tc-i386.c: Add avx_vnni_int16.
+ * doc/c-i386.texi: Document avx_vnni_int16.
+ * testsuite/gas/i386/i386.exp: Run AVX VNNI INT16 tests.
+ * testsuite/gas/i386/x86-64.exp: Ditto.
+ * testsuite/gas/i386/avx-vnni-int16-intel.d: New test.
+ * testsuite/gas/i386/avx-vnni-int16.d: New test.
+ * testsuite/gas/i386/avx-vnni-int16.s: New test.
+ * testsuite/gas/i386/x86-64-avx-vnni-int16-intel.d: New test.
+ * testsuite/gas/i386/x86-64-avx-vnni-int16.d: New test.
+ * testsuite/gas/i386/x86-64-avx-vnni-int16.s: New test.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (PREFIX_VEX_0F38D2_W_0): New.
+ (PREFIX_VEX_0F38D3_W_0): Ditto.
+ (VEX_W_0F38D2_P_0): Ditto.
+ (VEX_W_0F38D2_P_1): Ditto.
+ (VEX_W_0F38D2_P_2): Ditto.
+ (VEX_W_0F38D3_P_0): Ditto.
+ (VEX_W_0F38D3_P_1): Ditto.
+ (VEX_W_0F38D3_P_2): Ditto.
+ (prefix_table): Add PREFIX_VEX_0F38D2_W_0 and
+ PREFIX_VEX_0F38D3_W_0.
+ (vex_table): Add VEX_W_0F38D2 and VEX_W_0F38D3.
+ (vex_w_table): Ditto.
+ * i386-gen.c (isa_dependencies): Add AVX_VNNI_INT16.
+ (cpu_flag): Ditto.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h: (CpuAVX_VNNI_INT16): New.
+ * i386-opc.tbl: Add Intel AVX_VNNI_INT16 instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-07-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-thread-exited.exp
+ Two fixes in gdb.python/py-thread-exited.exp:
+ - fix the copyright notice validity range (PR testsuite/30687):
+ 2022-202 -> 2022-2023, and
+ - add missing "require allow_python_tests".
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30687
+
+2023-07-26 David Faust <david.faust@oracle.com>
+
+ bpf: accept # as an inline comment char
+ This little patch makes the BPF assembler accept '#' as an inline
+ comment character, which clang -S seems to use.
+
+ gas/
+ * config/tc-bpf.c (comment_chars): Add '#'.
+ * doc/c-bpf.texi (BPF Special Characters): Add note that '#' may
+ be used for inline comments.
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix Wstringop-truncation in coff_getfilename
+ When building gdb with -O2 -fsanitize-threads, I ran into
+ a Werror=stringop-truncation.
+
+ The problem is here in coff_getfilename in coffread.c:
+ ...
+ strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
+ buffer[FILNMLEN] = '\0';
+ ...
+
+ The constant FILNMLEN is expected to designate the size of
+ aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit
+ 60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW
+ targets.").
+
+ Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead.
+
+ Likewise in xcoffread.c.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ PR build/30669
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669
+
+2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas: add negi and neg32i tests
+ gas/ChangeLog:
+
+ 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/alu.s: Add test for NEGI and NEG32I.
+ * testsuite/gas/bpf/alu32.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu.d: Add expected results.
+ * testsuite/gas/bpf/alu-be.d: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32.d: Likewise.
+ * testsuite/gas/bpf/alu32-be.d: Likewise.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Drop -nostdlib in gdb.dwarf2/typeddwarf.exp
+ As reported in PR testsuite/30633, when running test-case
+ gdb.dwarf2/typeddwarf.exp with target board native-gdbserver on Ubuntu
+ 22.04.2, we run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Program received signal SIGSEGV, Segmentation fault.^M
+ 0x0000000000000001 in ?? ()^M
+ (gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
+ ...
+
+ We run into the FAIL as follows:
+ - due to using gdbserver, we attach at the point of the first instruction, in
+ _start
+ - we then set a breakpoint at main
+ - the test-case is a .s file, that has main renamed to _start in the assembly,
+ but not in the debuginfo
+ - setting a breakpoint at main sets the breakpoint at the same instruction
+ we're currently stopped at
+ - continue doesn't hit the breakpoint, and we return out of _start, which
+ causes a sigsegv
+
+ Note that this is for the amd64 case (using gdb.dwarf2/typeddwarf-amd64.S).
+ For the i386 case (using gdb.dwarf2/typeddwarf.S), setting a breakpoint in
+ main sets it one insn after function entry, and consequently the problem does
+ not occur.
+
+ The FAIL is a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie
+ in a few test-cases").
+
+ Without nopie the executable is PIE, with nopie it's static instead.
+
+ In the PIE case, we attach at the point of _start in the dynamic linker, and
+ consequently we do not skip the breakpoint in main, and also don't run into
+ the FAIL.
+
+ Fix this by:
+ - removing the -nostdlib setting, and
+ - renaming _start to main in both .S files.
+
+ The change to use -nostdlib and rename main to _start was originally added
+ in commit 6edba76fe8b (submitted here:
+ https://sourceware.org/pipermail/gdb-patches/2011-May/082657.html ) , I assume
+ to fix the problem now fixed by using nopie.
+
+ Tested on x86_64-linux.
+
+ Reported-By: Simon Marchi <simon.marchi@efficios.com>
+ Tested-By: Simon Marchi <simon.marchi@efficios.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30633
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix secondary prompt
+ With CLI, a session defining a command looks like:
+ ...
+ (gdb) define foo
+ Type commands for definition of "foo".
+ End with a line saying just "end".
+ >bar
+ >end
+ (gdb)
+ ...
+
+ With TUI however, we get the same secondary prompts, and type the same, but
+ are left with:
+ ...
+ (gdb) define foo
+ Type commands for definition of "foo".
+ End with a line saying just "end".
+ (gdb)
+ ...
+
+ Fix this by calling tui_inject_newline_into_command_window in
+ gdb_readline_wrapper_line, as is done in tui_command_line_handler.
+
+ Tested on x86_64-linux.
+
+ PR tui/30636
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30636
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0 some more
+ With a gdb build with -O2 -flto=auto and gcc 7.5.0 and test-case
+ gdb.gdb/python-helper.exp I run into:
+ ...
+ (outer-gdb) continue^M
+ Continuing.^M
+ print 1^M
+ ^M
+ Thread 1 "xgdb" hit Breakpoint 2, \
+ _Z11value_printP5valueP7ui_filePK19value_print_options (val=0x22e2590, \
+ stream=0x1f65480, options=0x7fffffffcdc0) at gdb/valprint.c:1193^M
+ 1193 {^M
+ (outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
+ ...
+
+ This is the "value_print" variant of the problem with "c_print_type" I fixed
+ in commit 0d332f11122 ("[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2
+ -flto=auto and gcc 7.5.0").
+
+ Fix this likewise.
+
+ Tested on x86_64-linux.
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix assert in ~gdbpy_tui_window_maker
+ In gdb/tui/tui-layout.c, we have:
+ ...
+ static window_types_map known_window_types;
+ ...
+ and in gdb/python/py-tui.c:
+ ...
+ /* A global list of all gdbpy_tui_window_maker objects. */
+ static intrusive_list<gdbpy_tui_window_maker> m_window_maker_list;
+ };
+
+ /* See comment in class declaration above. */
+
+ intrusive_list<gdbpy_tui_window_maker>
+ gdbpy_tui_window_maker::m_window_maker_list;
+ ...
+
+ With a gdb build with -O0 or -O2, the static destructor calling order seems to be:
+ - first gdb/tui/tui-layout.c,
+ - then gdb/python/py-tui.c.
+
+ So when running test-case gdb.python/tui-window-factory.exp, we see the
+ following order of events:
+ - the destructor for known_window_types is called, which triggers calling the
+ destructor for the only element E of m_window_maker_list. The destructor
+ destroys E, and also removes E from m_window_maker_list, leaving it empty.
+ - the destructor for m_window_maker_list is called. It's empty, so it's a nop.
+
+ However, when building gdb with -O2 -flto=auto, the static destructor calling
+ order seems to be reversed.
+
+ Instead, we have these events:
+ - the destructor for m_window_maker_list is called. This doesn't destroy it's
+ only element E, but it does make m_window_maker_list empty.
+ - the destructor for known_window_types is called, which triggers calling the
+ destructor for E. An attempt is done to remove E from m_window_maker_list,
+ but we run into an assertion failure, because the list is empty.
+
+ Fix this by checking is_linked () before attempting to remove from
+ m_window_maker_list, similar to how things were addressed in commit 995a34b1772
+ ("Guard against frame.c destructors running before frame-info.c's").
+
+ Tested on x86_64-linux.
+
+ PR tui/30646
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30646
+
+2023-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix regexps in gdb.base/step-over-syscall.exp
+ When running test-case gdb.base/step-over-syscall.exp without glibc debuginfo
+ installed, I get:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, 0x00007ffff7d4405e in vfork () from /lib64/libc.so.6^M
+ (gdb) PASS: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
+ continue to vfork (1st time)
+ ...
+ but with glibc debuginfo installed I get instead:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, 0x00007ffff7d4405e in __libc_vfork () at \
+ ../sysdeps/unix/sysv/linux/x86_64/vfork.S:44^M
+ 44 ENTRY (__vfork)^M
+ (gdb) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
+ continue to vfork (1st time)
+ ...
+
+ The FAIL is due to a mismatch with regexp:
+ ...
+ "Breakpoint \[0-9\]+, (.* in |__libc_|)$syscall \\(\\).*"
+ ...
+ because it cannot match both ".* in " and the __libc_ prefix.
+
+ Fix this by using instead the regexp:
+ ...
+ "Breakpoint \[0-9\]+, (.* in )?(__libc_)?$syscall \\(\\).*"
+ ...
+
+ Tested on x86_64-linux.
+
+2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: fix neg and neg32 BPF instructions in simulator
+ This patch fixes the semantics of the neg and neg32 BPF instructions
+ in the simulator, and also updates the corresponding tests
+ accordingly.
+
+ Tested in target bpf-unknown-none.
+
+2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: fix register NEG[32] instructions
+ This patch fixes the BPF_INSN_NEGR and BPF_INSN_NEG32R BPF
+ instructions to not use their source registers.
+
+ Tested in bpf-unknown-none.
+
+ opcodes/ChangeLog:
+
+ 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Fix BPF_INSN_NEGR to not use a src
+ register.
+
+ gas/ChangeLog:
+
+ 2023-07-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/alu.s: The register neg instruction gets only
+ one argument.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-be.d: Likewise.
+ * testsuite/gas/bpf/alu.d: Likewise.
+ * testsuite/gas/bpf/alu32-be.d: Likewise.
+ * testsuite/gas/bpf/alu32.d: Likewise.
+ * testsuite/gas/bpf/alu32.s: Likewise.
+ * doc/c-bpf.texi (BPF Instructions): Update accordingly.
+
+2023-07-26 Alan Modra <amodra@gmail.com>
+
+ PR30657, gprof heap buffer overflow
+ PR 30657
+ * cg_arcs.c (cg_assemble): Sanity check find_call addresses.
+ * i386.c (i386_find_call): Don't access past end of core_text_space.
+ * aarch64.c (aarch64_find_call): Round up lowpc, round down highpc.
+ * alpha.c (alpha_find_call): Likewise.
+ * mips.c (mips_find_call): Likewise.
+ * sparc.c (sparc_find_call): Likewise.
+ * vax.c (vax_find_call): Sanity check core_text_space accesses.
+
+2023-07-26 Alan Modra <amodra@gmail.com>
+
+ [GOLD] reporting local symbol names
+ get_symbol_name currently returns "" for the usual STT_SECTION symbols
+ generated by gas. That's not very helpful, return the section name.
+ Demangle local symbols too, fixing an inconsistency in
+ issue_discarded_error where global symbols are demangled.
+
+ * object.cc (Sized_relobj_file::get_symbol_name): Return a
+ std::string. Return section name for STT_SECTION symbols with
+ zero st_name. Sanity check st_name, and don't run off the end
+ of an improperly terminated .strtab. Demangle sym names.
+ * object.h (Sized_relobj_file::get_symbol_name): Update decl.
+ * target-reloc.h (issue_discarded_error): Adjust.
+ * powerpc.cc (Target_powerpc::Relocate::relocate): Report reloc
+ type and symbol for relocation overflows.
+
+2023-07-26 Alan Modra <amodra@gmail.com>
+
+ Don't warn on .attach_to_group to same group
+ * config/obj-elf.c (obj_elf_attach_to_group): Don't warn if
+ group name matches current group for section.
+
+ bpf: format not a string literal
+ * config/tc-bpf.c (md_assemble): Correct as_bad call.
+
+ Regen bpf opcodes POTFILE
+
+2023-07-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-25 David Faust <david.faust@oracle.com>
+
+ bpf: Add atomic compare-and-exchange instructions
+ This patch adds the two remaining BPF v3 atomic instructions:
+ - BPF_INSN_ACMP{,32}: atomic compare-and-swap
+ - BPF_INSN_AXCHG{,32}: atomic (non-conditional) exchange
+
+ Tests and documentation are also updated.
+
+ gas/
+ * doc/c-bpf.texi (BPF Instructions): Document atomic exchange and
+ atomic compare-and-swap instructions.
+ * testsuite/gas/bpf/atomic.s: Test ACMP, ACMP32, AXCHG, AXCGH32
+ instructions.
+ * testsuite/gas/bpf/atomic.d: Likewise.
+ * testsuite/gas/bpf/atomic-be.d: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise.
+
+ include/
+ * opcode/bpf.h (BPF_IMM32_ACMP): Fix typo.
+ (enum bpf_insn_id): New entries for BPF_INSN_ACMP{,32} and
+ BPF_INSN_AXCHG{,32}.
+
+ opcodes/
+ * bpf-opc.c (bpf_opcodes): Add entries for ACMP{,32} and
+ AXCHG{,32} instructions.
+
+2023-07-25 David Faust <david.faust@oracle.com>
+
+ bpf: Update atomic instruction pseudo-C syntax
+ This patch updates the pseudo-C dialect templates for the BPF v3 atomic
+ instructions. The templates match the strings emitted by clang -S for
+ these instructions.
+
+ The tests and documentation are updated accordingly.
+
+ gas/
+ * doc/c-bpf.texi (BPF Instructions): Update entries for atomic
+ and 32-bit atomic instructions.
+ * testsuite/gas/bpf/atomic.s: Test AAND, AAND32, AOR, AOR32,
+ AXOR, AXOR32, AFADD, AFADD32, AFAND, AFAND32, AFOR, AFOR32,
+ AFXOR and AFXOR32 instructions.
+ * testsuite/gas/bpf/atomic.d: Likewise.
+ * testsuite/gas/bpf/atomic-be.d: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/atomic-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/atomic-v1.s: New test.
+ * testsuite/gas/bpf/atomic-v1.d: Likewise.
+ * testuiste/gas/bpf/atomic-v1-be.d: Likewise.
+ * testuiste/gas/bpf/bpf.exp: Run new tests.
+
+ opcodes/
+ * bpf-opc.c (bpf_opcodes): Update pseudo-C dialect templates for:
+ BPF_INSN_AADD, BPF_INSN_AOR, BPF_INSN_AAND, BPF_INSN_AXOR,
+ BPF_INSN_AFADD, BPF_INSN_AFOR, BPF_INSN_AFAND, BPF_INSN_AFXOR,
+ BPF_INSN_AADD32, BPF_INSN_AOR32, BPF_INSN_AAND32,
+ BPF_INSN_AXOR32, BPF_INSN_AFADD32, BPF_INSN_AFOR32,
+ BPF_INSN_AFAND32, and BPF_INSN_AFXOR32 instructions.
+
+2023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Enable RVC on ".option arch, +zca" etc.
+ Since the 'Zca' extension is the new base of the compressed instructions,
+ this commit enables RVC *also* when the 'Zca' extension is enabled
+ via ".option arch" directive.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (s_riscv_option): Enable RVC also when the
+ 'Zca' extension is enabled after an ".option arch" directive.
+
+2023-07-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Implications from 'Zc[fd]' extensions
+ The version 1.0.4-1 of the code size reduction specification clarifies
+ that 'Zcf' implies 'F' and 'Zcd' implies 'D'.
+
+ cf:
+ <https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1>
+
+ This commit adds those implications.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add two implications,
+ 'Zcf' -> 'F' and 'Zcd' -> 'D'.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-imply-zcd.d: New test.
+ * testsuite/gas/riscv/march-imply-zcf.d: New test.
+
+2023-07-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Prohibit the 'Zcf' extension on RV64
+ As per:
+ <https://github.com/riscv/riscv-code-size-reduction/issues/221>,
+ the 'Zcf' extension does not exist on RV64. This is reflected on the
+ version 1.0.4-1 of the code size reduction specification:
+ <https://github.com/riscv/riscv-code-size-reduction/releases/tag/v1.0.4-1>.
+
+ This commit prohibits the combination: RV64 (or any ISA with XLEN > 32)
+ and the 'Zcf' extension.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit
+ combination of RV64 and 'Zcf'.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-fail-rv64i_zcf.d: New test.
+ * testsuite/gas/riscv/march-fail-rv64i_zcf.l: Likewise.
+
+2023-07-24 Johannes Schauer Marin Rodrigues <josch@debian.org>
+
+ objcopy embeds the current time and ignores SOURCE_DATE_EPOCH making the output unreproducible.
+ bfd
+ * peXXigen.c (_bfd_XXi_only_swap_filehdr_out): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined.
+ binutils
+ * doc/binutils.texi (objcopy): Document change in behaviour of objcopy's --preserve-dates command line option.
+ ld
+ * pe-dll.c (fill_edata): If inserting a timestamp, use the value held in the SOURCE_DATE_EPOCH environment variable, if it is defined.
+ * ld.texi (--insert-timestamp): Document change in behaviour.
+
+2023-07-24 Nick Clifton <nickc@redhat.com>
+
+ Updated translations for bfd, gold and opcodes
+
+2023-07-24 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: ld: Simplify inserting IRELATIVE relocations to .rela.dyn
+ In LoongArch, the R_LARCH_IRELATIVE relocations for local ifunc symbols are
+ in .rela.dyn. Before, this is done by loongarch_elf_finish_dynamic_sections.
+ But this function is called after elf_link_sort_relocs, it need to find a
+ null slot to insert IRELATIVE relocation.
+
+ Now, it is processed by elf_loongarch_output_arch_local_syms before
+ elf_link_sort_relocs, just need to call loongarch_elf_append_rela to
+ insert IRELATIVE relocation.
+
+ bfd/ChangeLog:
+
+ * elfnn-loongarch.c (elfNN_allocate_local_ifunc_dynrelocs): Return
+ type change to int.
+ (loongarch_elf_size_dynamic_sections): Delete (void *).
+ (loongarch_elf_finish_dynamic_symbol): Use loongarch_elf_append_rela
+ insert IRELATIVE relocation to .rela.dyn.
+ (elfNN_loongarch_finish_local_dynamic_symbol): Return type change to
+ int.
+ (loongarch_elf_finish_dynamic_sections): Delete process of local
+ ifunc symbols.
+ (elf_backend_output_arch_local_syms): New.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-loongarch-elf/local-ifunc-reloc.d: Regenerated.
+
+2023-07-24 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix immediate overflow check bug
+ For B16/B21/B26/PCREL20_S2 relocations, if immediate overflow check after
+ rightshift, and the mask need to include sign bit.
+
+ Now, the immediate overflow check before rightshift for easier understand.
+
+ bfd/ChangeLog:
+
+ * elfxx-loongarch.c (reloc_bits_pcrel20_s2): Delete.
+ (reloc_bits_b16): Delete.
+ (reloc_bits_b21): Delete.
+ (reloc_bits_b26): Delete.
+ (reloc_sign_bits): New.
+
+2023-07-24 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix instruction immediate bug caused by sign-extend
+ For extreme code mode, the instruction sequences is
+ pcalau12i $t0, hi20
+ addi.d $t1, $zero, lo12
+ lu32i.d $t1, lo20
+ lu52i.d $t1, hi12
+ add.d $t1, $t0, $t1
+
+ If lo12 > 0x7ff, hi20 need to add 0x1, lo20 need to sub 0x1.
+ If hi20 > 0x7ffff, lo20 need to add 0x1.
+
+ bfd/ChangeLog:
+
+ * elfnn-loongarch.c (RELOCATE_CALC_PC32_HI20): Redefined.
+ (RELOCATE_CALC_PC64_HI32): Redefined.
+
+2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas,include,opcode: add suppor for instructions BSWAP{16,32,64}
+ This patch adds support for the BPF V4 ISA byte swap instructions to
+ opcodes, assembler and disassembler.
+
+ Tested in bpf-unknown-none.
+
+ include/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * opcode/bpf.h (BPF_IMM32_BSWAP16): Define.
+ (BPF_IMM32_BSWAP32): Likewise.
+ (BPF_IMM32_BSWAP64): Likewise.
+ (enum bpf_insn_id): New entries BPF_INSN_BSWAP{16,32,64}.
+
+ opcodes/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Add entries for the BSWAP*
+ instructions.
+
+ gas/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * doc/c-bpf.texi (BPF Instructions): Document BSWAP* instructions.
+ * testsuite/gas/bpf/alu.s: Test BSWAP{16,32,64} instructions.
+ * testsuite/gas/bpf/alu.d: Likewise.
+ * testsuite/gas/bpf/alu-be.d: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+
+2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas: fix in manual that MOVS* pseudoc syntax uses = instead of s=
+ gas/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * doc/c-bpf.texi (BPF Instructions): The pseudoc syntax for MOVS*
+ doesn't use `s=' but `='.
+
+2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: gas,opcodes: fix pseudoc syntax for MOVS* and LDXS* insns
+ This patch fixes the pseudoc syntax of the V4 instructions MOVS* and
+ LDXS* in order to reflect https://reviews.llvm.org/D144829.
+
+ opcodes/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Fix pseudo-c syntax for MOVS* and LDXS*
+ instructions.
+
+ gas/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * doc/c-bpf.texi (BPF Instructions): Fix pseudoc syntax for MOVS*
+ and LDXS* instructions.
+ * testsuite/gas/bpf/mem-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/mem-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
+
+2023-07-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: add support for jal/gotol jump instruction with 32-bit target
+ This patch adds support for the V4 BPF instruction jal/gotol, which is
+ like ja/goto but it supports a signed 32-bit PC-relative (in number of
+ 64-bit words minus one) target operand instead of the 16-bit signed
+ operand of the other instruction. This greatly increases the jump
+ range in BPF programs.
+
+ Tested in bpf-unkown-none.
+
+ bfd/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * reloc.c: New reloc BFD_RELOC_BPF_DISPCALL32.
+ * elf64-bpf.c (bpf_reloc_type_lookup): Handle the new reloc.
+ * libbfd.h (bfd_reloc_code_real_names): Regenerate.
+
+ gas/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * config/tc-bpf.c (struct bpf_insn): New field `id'.
+ (md_assemble): Save the ids of successfully parsed instructions
+ and use the new BFD_RELOC_BPF_DISPCALL32 whenever appropriate.
+ (md_apply_fix): Adapt to the new BFD reloc.
+ * testsuite/gas/bpf/jump.s: Test JAL.
+ * testsuite/gas/bpf/jump.d: Likewise.
+ * testsuite/gas/bpf/jump-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/jump-be.d: Likewise.
+ * testsuite/gas/bpf/jump-be-pseudoc.d: Likewise.
+ * doc/c-bpf.texi (BPF Instructions): Document new instruction
+ jal/gotol.
+ Document new operand type disp32.
+
+ include/ChangeLog:
+
+ 2023-07-24 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * opcode/bpf.h (enum bpf_insn_id): Add entry BPF_INSN_JAL.
+ (enum bpf_insn_id): Remove spurious entry BPF_INSN_CALLI.
+
+ opcodes/ChangeLog:
+
+ 2023-07-23 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Add entry for jal.
+
+2023-07-23 Tom Tromey <tom@tromey.com>
+
+ Use 'name' in DAP start_thread function
+ The DAP start_thread helper function has a 'name' parameter that is
+ unused. Apparently I forgot to hook it up to the thread constructor.
+ This patch fixes the oversight.
+
+2023-07-23 Tom Tromey <tom@tromey.com>
+
+ Export gdb.block_signals and create gdb.Thread
+ While working on an experiment, I realized that I needed the DAP
+ block_signals function. I figured other developers may need it as
+ well, so this patch moves it from DAP to the gdb module and exports
+ it.
+
+ I also added a new subclass of threading.Thread that ensures that
+ signals are blocked in the new thread.
+
+ Finally, this patch slightly rearranges the documentation so that
+ gdb-side threading issues and functions are all discussed in a single
+ node.
+
+2023-07-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: two changes to linux_nat_debug_printf calls in linux-nat.c
+ This commit adjusts some of the debug output in linux-nat.c, but makes
+ no other functional changes to GDB.
+
+ In resume_lwp I've added the word "sibling" to one of the debug
+ messages. All the other debug messages in this function talk about
+ operating on the sibling thread, so I think it makes sense, for
+ consistency, if the message I've updated also talks about the sibling
+ thread.
+
+ In resume_stopped_resumed_lwps I've reordered the condition checks so
+ that the vfork-parent check now happens after the checks for whether
+ the thread is already resumed or not. This makes no functional
+ difference to GDB, but does, I think, mean we see more helpful debug
+ messages first.
+
+ Consider the situation where a vfork-parent thread is already resumed,
+ and resume_stopped_resumed_lwps is called. Previously the message
+ saying that the thread was not being resumed due to being a
+ vfork-parent, was printed. This might give the impression that the
+ thread is left in a not resumed state, which is misleading.
+
+ After this change we now get a message saying that the thread is not
+ being resumed due to it not being stopped (i.e. is already resumed).
+ With this message the already resumed nature of the thread is much
+ clearer.
+
+ I found this change helpful when debugging some vfork related issues.
+
+2023-07-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: replace $testfile with $binfile in one case
+ For *reasons* I was hacking on gdb.base/foll-vfork.exp and wanted to
+ change the name of the binary that was created. Should be easy, I
+ adjusted the global $binfile variable .... but that didn't work.
+
+ In one place the script uses $testfile instead of $binfile.
+
+ Fixed this to use $binfile, now I can easily change the name of the
+ generated binary, and the test still works.
+
+ There's no change in what is tested after this commit.
+
+2023-07-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve gdb.arch/arm-pthread_cond_timedwait-bt.exp
+ I noticed in test-case gdb.arch/arm-pthread_cond_timedwait-bt.exp that
+ prepare_for_testing is used, followed by a clean_restart.
+
+ This calls clean_restart twice in a row.
+
+ Fix this by using build_executable instead.
+
+ Also, I noticed that the test-case requires an SVC instruction, so add a
+ require to limit the test-case to supported architectures.
+
+ While we're at it, run M-x indent-region in emacs to fix indentation.
+
+ Tested on x86_64-linux.
+
+2023-07-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use proc readnow in two test-cases
+ Use "require !readnow" in two test-cases, instead of the written-out variant.
+
+ Tested on x86_64-linux, with target boards unix and readnow.
+
+2023-07-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-21 Tom Tromey <tom@tromey.com>
+
+ Fix crash with DW_FORM_implicit_const
+ Jakub pointed out that using DW_FORM_implicit_const with
+ DW_AT_bit_size would cause gdb to crash. This happened because
+ DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned
+ to assert. This patch fixes the problem.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-07-21 David Faust <david.faust@oracle.com>
+
+ bpf: disasemble offsets of value 0 as "+0"
+ This tiny patch makes the BPF disassembler to emit, e.g.
+
+ ldxdw %r1, [%r0+0]
+
+ instead of
+
+ ldxdw %r1, [%r00]
+
+ when the offset is 0, to avoid confusion.
+
+ opcodes/
+
+ * bpf-dis.c (print_insn_bpf): Print offsets with value 0 as "+0".
+
+ gas/
+
+ * testsuite/gas/bpf/mem.s: Add tests with offset 0.
+ * testsuite/gas/bpf/mem-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/mem.d: Update accordingly.
+ * testsuite/gas/bpf/mem-be.d: Likewise.
+ * testsuite/gas/bpf/mem-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP modules request
+ This implements the DAP "modules" request, and also arranges to add
+ the module ID to stack frames.
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Add Progspace.objfile_for_address
+ This adds a new objfile_for_address method to gdb.Progspace. This
+ makes it easy to find the objfile for a given address.
+
+ There's a related PR; and while this change would have been sufficient
+ for my original need, it's not clear to me whether I should close the
+ bug. Nevertheless I think it makes sense to at least mention it here.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Remove unused imports
+ I noticed an unused import in dap/evaluate.py; and also I found out
+ that my recent changes to use frame filters from DAP left some unused
+ imports in dap/bt.py.
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Document array indexing for Python gdb.Value
+ I noticed that the documentation for gdb.Value doesn't mention array
+ indexing.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: opcodes, gas: support for signed load V4 instructions
+ This commit adds the signed load to register (ldxs*) instructions
+ introduced in the BPF ISA version 4, including opcodes and assembler
+ tests.
+
+ Tested in bpf-unknown-none.
+
+ include/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * opcode/bpf.h (enum bpf_insn_id): Add entries for signed load
+ instructions.
+ (BPF_MODE_SMEM): Define.
+
+ opcodes/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Add entries for LDXS{B,W,H,DW}
+ instructions.
+
+ gas/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/mem.s: Add signed load instructions.
+ * testsuite/gas/bpf/mem-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/mem.d: Likewise.
+ * testsuite/gas/bpf/mem-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/mem-be.d: Likewise.
+ * doc/c-bpf.texi (BPF Instructions): Document the signed load
+ instructions.
+
+2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: opcodes, gas: support for signed register move V4 instructions
+ This commit adds the signed register move (movs) instructions
+ introduced in the BPF ISA version 4, including opcodes and assembler
+ tests.
+
+ Tested in bpf-unknown-none.
+
+ include/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * opcode/bpf.h (BPF_OFFSET16_MOVS8): Define.
+ (BPF_OFFSET16_MOVS16): Likewise.
+ (BPF_OFFSET16_MOVS32): Likewise.
+ (enum bpf_insn_id): Add entries for MOVS{8,16,32}R and
+ MOVS32{8,16,32}R.
+
+ opcodes/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * bpf-opc.c (bpf_opcodes): Add entries for MOVS{8,16,32}R and
+ MOVS32{8,16,32}R instructions. and MOVS32I instructions.
+
+ gas/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/alu.s: Test movs instructions.
+ * testsuite/gas/bpf/alu-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu32.s: Likewise for movs32 instruction.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu.d: Add expected results.
+ * testsuite/gas/bpf/alu32.d: Likewise.
+ * testsuite/gas/bpf/alu-be.d: Likewise.
+ * testsuite/gas/bpf/alu32-be.d: Likewise.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Remove redundant @findex from python.texi
+ In a review, Eli pointed out that @findex is redundant when used with
+ @defun. This patch removes all such uses from python.texi, plus a
+ couple uses before @defvar that are also unnecessary.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Fix typo in py-type.c docstring
+ I noticed that a doc string py-type.c says "an signed".
+ This patch corrects it to "a signed".
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Implement Ada target name symbol
+ Ada 2022 adds the "target name symbol", which can be used on the right
+ hand side of an assignment to refer to the left hand side. This
+ allows for convenient updates. This patch implements this for gdb's
+ Ada expression parser.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Add instruction bytes to DAP disassembly response
+ The DAP disassemble command lets the client return the underlying
+ bytes of the instruction in an implementation-defined format. This
+ patch updates gdb to return this, and simply uses a hex string of the
+ bytes as the format.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-21 Tom Tromey <tromey@adacore.com>
+
+ Remove ancient Ada workaround
+ I ran across this very old code in gdb's Ada support. After a bit of
+ archaeology, we couldn't determine what bug this might have been
+ working around. It is no longer needed, so this patch removes it.
+
+ As this is entirely Ada-specific and was reviewed and tested at
+ AdaCore, I'm checking it in.
+
+2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ bpf: add missing bpf-dis.c to opcodes/Makefile.am
+ This was breaking --enable-targets=all builds.
+
+ opcodes/ChangeLog:
+
+ 2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * Makefile.am (TARGET64_LIBOPCODES_CFILES): Add missing bpf-dis.c
+ * Makefile.in: Regenerate.
+
+2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ sim/bpf: desCGENization of the BPF simulator
+ The BPF port in binutils has been rewritten (commit
+ d218e7fedc74d67837d2134120917f4ac877454c) in order to not be longer
+ based on CGEN. Please see that commit log for more information.
+
+ This patch updates the BPF simulator accordingly. The new
+ implementation is much simpler and it is based on the new BPF opcodes.
+
+ Tested with target bpf-unknown-none with both 64-bit little-endian
+ host and 32-bit little-endian host.
+
+ Note that I have not tested in a big-endian host yet. I will do so
+ once this lands upstream so I can use the GCC compiler farm.
+
+2023-07-21 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ DesCGENization of the BPF binutils port
+ CGEN is cool, but the BPF architecture is simply too bizarre for it.
+
+ The weird way of BPF to handle endianness in instruction encoding, the
+ weird C-like alternative assembly syntax, the weird abuse of
+ multi-byte (or infra-byte) instruction fields as opcodes, the unusual
+ presence of opcodes beyond the first 32-bits of some instructions, are
+ all examples of what makes it a PITA to continue using CGEN for this
+ port. The bpf.cpu file is becoming so complex and so nested with
+ p-macros that it is very difficult to read, and quite challenging to
+ update. Also, every time we are forced to change something in CGEN to
+ accommodate BPF requirements (which is often) we have to do extensive
+ testing to make sure we do not break any other target using CGEN.
+
+ This is getting un-maintenable.
+
+ So I have decided to bite the bullet and revamp/rewrite the port so it
+ no longer uses CGEN. Overall, this involved:
+
+ * To remove the cpu/bpf.{cpu,opc} descriptions.
+
+ * To remove the CGEN generated files.
+
+ * To replace the CGEN generated opcodes table with a new hand-written
+ opcodes table for BPF.
+
+ * To replace the CGEN generated disassembler wih a new disassembler
+ that uses the new opcodes.
+
+ * To replace the CGEN generated assembler with a new assembler that uses the
+ new opcodes.
+
+ * To replace the CGEN generated simulator with a new simulator that uses the
+ new opcodes. [This is pushed in GDB in another patch.]
+
+ * To adapt the build systems to the new situation.
+
+ Additionally, this patch introduces some extensions and improvements:
+
+ * A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF
+ relocation R_BPF_GNU_64_16 are added to the BPF BFD port. These
+ relocations are used for section-relative 16-bit offsets used in
+ load/store instructions.
+
+ * The disassembler now has support for the "pseudo-c" assembly syntax of
+ BPF. What dialect to use when disassembling is controlled by a command
+ line option.
+
+ * The disassembler now has support for dumping instruction immediates in
+ either octal, hexadecimal or decimal. The used output base is controlled
+ by a new command-line option.
+
+ * The GAS BPF test suite has been re-structured and expanded in order to
+ test the disassembler pseudoc syntax support. Minor bugs have been also
+ fixed there. The assembler generic tests that were disabled for bpf-*-*
+ targets due to the previous implementation of pseudoc syntax are now
+ re-enabled. Additional tests have been added to test the new features of
+ the assembler. .dump files are no longer used.
+
+ * The linker BPF test suite has been adapted to the command line options
+ used by the new disassembler.
+
+ The result is very satisfactory. This patchs adds 3448 lines of code
+ and removes 10542 lines of code.
+
+ Tested in:
+
+ * Target bpf-unknown-none with 64-bit little-endian host and 32-bit
+ little-endian host.
+
+ * Target x86-64-linux-gnu with --enable-targets=all
+
+ Note that I have not tested in a big-endian host yet. I will do so
+ once this lands upstream so I can use the GCC compiler farm.
+
+ I have not included ChangeLog entries in this patch: these would be
+ massive and not very useful, considering this is pretty much a rewrite
+ of the port. I beg the indulgence of the global maintainers.
+
+2023-07-21 Lancelot Six <lancelot.six@amd.com>
+
+ gdb/solib-rocm: limit the number of opened file descriptors
+ ROCm programs can load a high number of compute kernels on GPU devices,
+ especially if lazy code-object loading have been disabled. Each code
+ object containing such program is loaded once for each device available,
+ and each instance is reported by GDB as an individual shared library.
+
+ We came across situations where the number of shared libraries opened by
+ GDB gets higher than the allowed number of opened files for the process.
+ Increasing the opened files limit works around the problem, but there is a
+ better way this patch proposes to follow.
+
+ Under the hood, the GPU code objects are embedded inside the host
+ application binary and shared library binaries. GDB currently opens the
+ underlying file once for each shared library it sees. That means that
+ the same file is re-opened every time a code object is loaded on a GPU.
+
+ This patch proposes to only open each underlying file once. This is
+ done by implementing a reference counting mechanism so the underlying
+ file is opened when the underlying file first needs to be opened, and
+ closed when the last BFD using the underlying file is closed.
+
+ On a program where GDB used to open about 1500 files to load all shared
+ libraries, this patch makes it so only 54 opened file descriptors are
+ needed.
+
+ I have tested this patch on downstream ROCgdb's full testsuite and
+ upstream GDB testsuite with no regression.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: adjust disassembly of insns operating on selector values
+ Bring disassembly back in line with what the assembler accepts, thus
+ also making it self-consistent (with, in particular selector load/store
+ insns). While there further add D to all affected insns except ARPL
+ (where S is used, matching LAR/LSL), to also behave correctly in suffix-
+ always mode.
+
+ While there also hook up the Intel variant of the LKGS test.
+
+2023-07-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: simplify disassembly of LAR/LSL
+ For whatever reason in c9f5b96bdab0 ("x86: correct handling of LAR and
+ LSL") I didn't realize that we can easily use Sv instead of going
+ through mod_table[]. Redo this aspect of that change.
+
+2023-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add optimized out static var to cooked index
+ Consider the test-case:
+ ...
+ $ cat main.c
+ int main (void) { return 0; }
+ $ cat static-optimized-out.c
+ static int aaa;
+ ...
+ compiled like this:
+ ...
+ $ gcc-12 static-optimized-out.c main.c -g -O2 -flto
+ ...
+
+ There's a difference in behaviour depending on symtab expansion state:
+ ...
+ $ gdb -q -batch a.out -ex "print aaa"
+ No symbol "aaa" in current context.
+ $ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa"
+ $1 = <optimized out>
+ ...
+
+ The reason for the difference is that the optimized out variable aaa:
+ ...
+ <1><104>: Abbrev Number: 2 (DW_TAG_variable)
+ <105> DW_AT_name : aaa
+ <109> DW_AT_decl_file : 1
+ <10a> DW_AT_decl_line : 18
+ <10b> DW_AT_decl_column : 12
+ <10c> DW_AT_type : <0x110>
+ ...
+ is not added to the cooked index because of this clause in abbrev_table::read:
+ ...
+ else if (!has_location && !has_specification_or_origin && !has_external
+ && cur_abbrev->tag == DW_TAG_variable)
+ cur_abbrev->interesting = false;
+ ...
+
+ Fix this inconsistency by making sure that the optimized out variable is added
+ to the cooked index.
+
+ Regression tested on x86_64-linux.
+
+ Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf
+ assembly test-case gdb.dwarf2/static-optimized-out.exp.
+
+ Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now
+ consistently get:
+ ...
+ (gdb) print aaa^M
+ $1 = <optimized out>^M
+ ...
+ and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get:
+ ...
+ (gdb) print aaa^M
+ No symbol "aaa" in current context.^M
+ ...
+ due to missing debug info for the variable.
+
+ PR symtab/30656
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix superfluous newline for long prompt
+ In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size
+ as the terminal width, we get a superfluous newline at line 19:
+ ...
+ 16 (gdb) set prompt 123456789A123456789B123
+ 17 456789C123456789>
+ 18 123456789A123456789B123456789C123456789>
+ 19
+ 20 123456789A123456789B123456789C123456789>
+ 21 set prompt (gdb)
+ 22 (gdb)
+ ...
+ as well as a superfluous repetition of the prompt at line 20 once we type the
+ 's' starting "set prompt".
+
+ I traced the superfluous newline back to readline's readline_internal_setup,
+ that does:
+ ...
+ /* If we're not echoing, we still want to at least print a prompt, because
+ rl_redisplay will not do it for us. If the calling application has a
+ custom redisplay function, though, let that function handle it. */
+ if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay)
+ ...
+ else
+ {
+ if (rl_prompt && rl_already_prompted)
+ rl_on_new_line_with_prompt ();
+ else
+ rl_on_new_line ();
+ (*rl_redisplay_function) ();
+ ...
+ and then we hit the case that calls rl_on_new_line_with_prompt, which does:
+ ...
+ /* If the prompt length is a multiple of real_screenwidth, we don't know
+ whether the cursor is at the end of the last line, or already at the
+ beginning of the next line. Output a newline just to be safe. */
+ if (l > 0 && (l % real_screenwidth) == 0)
+ _rl_output_some_chars ("\n", 1);
+ ...
+
+ This doesn't look like a readline bug, because the behaviour matches the
+ comment.
+
+ [ And the fact that the output of the newline doesn't happen in the scope of
+ tui_redisplay_readline means it doesn't get the prompt wrap detection
+ treatment, causing start_line to be incorrect, which causes the superfluous
+ repetition of the prompt. ]
+
+ I looked at ways to work around this, and managed by switching off
+ rl_already_prompted, which we set to 1 in tui_rl_startup_hook:
+ ...
+ /* Readline hook to redisplay ourself the gdb prompt.
+ In the SingleKey mode, the prompt is not printed so that
+ the command window is cleaner. It will be displayed if
+ we temporarily leave the SingleKey mode. */
+ static int
+ tui_rl_startup_hook (void)
+ {
+ rl_already_prompted = 1;
+ if (tui_current_key_mode != TUI_COMMAND_MODE
+ && !gdb_in_secondary_prompt_p (current_ui))
+ tui_set_key_mode (TUI_SINGLE_KEY_MODE);
+ tui_redisplay_readline ();
+ return 0;
+ }
+ ...
+
+ Then I started looking at why rl_already_prompted is set to 1.
+
+ The use case for rl_already_prompted seems to be:
+ - app (application, the readline user) outputs prompt,
+ - app sets rl_already_prompted to 1, and
+ - app calls readline, which calls rl_on_new_line_with_prompt, which figures
+ out how long the prompt is, and sets a few readline variables accordingly,
+ which can be used in the following call to rl_redisplay_function.
+
+ AFAICT, TUI does not fit this pattern. It does not output an initial prompt,
+ rather it writes the prompt in every rl_redisplay_function. It doesn't use
+ the variables set by rl_on_new_line_with_prompt, instead it figures stuff out
+ by itself.
+
+ Fix this by removing the rl_already_prompted setting.
+
+ Also remove the call to tui_redisplay_readline, it's not necessary, the
+ function is called anyway.
+
+ Tested on x86_64-linux, no regressions.
+
+2023-07-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-20 Alan Modra <amodra@gmail.com>
+
+ MIPS: Don't move __gnu_lto_slim to .scommon
+ * elfxx-mips.c (_bfd_mips_elf_symbol_processing): Don't treat
+ __gnu_lto_slim as SHN_MIPS_SCOMMON.
+ (_bfd_mips_elf_add_symbol_hook): Likewise.
+
+2023-07-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-19 Hui Li <lihui@loongson.cn>
+
+ gdb: LoongArch: Update status of the entire regset in regcache
+ In the current code, when a register is fetched, the entire regset
+ are fetched via ptrace, but only this register status is updated in
+ regcache, it needs to fetch the same regset through ptrace again if
+ another register in this regset is fetched later, this is obviously
+ unnecessary. It is proper to update the status of the entire regset
+ in regcache when fetching a register via ptrace.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-07-19 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.Inferior.read_memory without execution (PR dap/30644)
+ Andrew reported that the previous change to gdb.Inferior.read_memory &
+ friends introducing scoped_restore_current_inferior_for_memory broke
+ gdb.dap/stop-at-main.exp. This is also reported as PR dap/30644.
+
+ The root of the problem is that all the methods that now use
+ scoped_restore_current_inferior_for_memory cause GDB to crash with a
+ failed assert if they are run on an inferior that is not yet started.
+
+ E.g.:
+
+ (gdb) python i = gdb.selected_inferior ()
+ (gdb) python i.read_memory (4,4)
+ gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed.
+
+ This patch fixes the problem by removing
+ scoped_restore_current_inferior_for_memory's ctor ptid parameter and
+ the any_thread_of_inferior calls completely, and making
+ scoped_restore_current_inferior_for_memory switch inferior_ptid to a
+ pid ptid.
+
+ I was a little worried that some port might be assuming inferior_ptid
+ points at a thread in the xfer_partial memory access routines. We
+ know that anything that supports forks must not assume that, due to
+ how detach_breakpoints works. I looked at a number of xfer_partial
+ implementations, and didn't see anything that is looking at
+ inferior_ptid in a way that would misbehave. I'm thinking that we
+ could go forward with this and just fix ports if they break.
+
+ While on some ports like on AMD GPU we have thread-specific address
+ spaces, and so when accessing memory for those address spaces, we must
+ have the right thread context (via inferior_ptid) selected, in
+ Inferior.read_memory, we only have the inferior to work with, so this
+ API as is can't be used to access thread-specific address spaces.
+ IOW, it can only be used to access the global address space that is
+ visible to both the CPU and the GPUs.
+
+ In proc-service.c:ps_xfer_memory, the other spot using
+ scoped_restore_current_inferior_for_memory, we're always accessing
+ per-inferior memory.
+
+ If we end up using scoped_restore_current_inferior_for_memory later to
+ set up the context to read memory from a specific thread, then we can
+ add an alternative ctor that takes a thread_info pointer, and make
+ inferior_ptid point to the thread, for example.
+
+ New test added to gdb.python/py-inferior.exp, exercising
+ Inferior.read_memory without execution.
+
+ No regressions on native and extended-gdbserver x86_64 GNU/Linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644
+ Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19
+
+2023-07-19 Nick Clifton <nickc@redhat.com>
+
+ Updated Romainian translation for the opcodes directory
+
+2023-07-19 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/amd-dbgapi-target: Use inf param in detach
+ Current implementation of amd_dbgapi_target::detach (inferior *, int)
+ does the following:
+
+ remove_breakpoints_inf (current_inferior ());
+ detach_amd_dbgapi (inf);
+ beneath ()->detach (inf, from_tty);
+
+ I find that using a mix of `current_inferior ()` and `inf` disturbing.
+ At this point, we know that both are the same (target_detach does assert
+ that `inf == current_inferior ()` before calling target_ops::detach).
+
+ To improve consistency, this patch replaces `current_inferior ()` with
+ `inf` in amd_dbgapi_target::detach.
+
+ Change-Id: I01b7ba2e661c25839438354b509d7abbddb7c5ed
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto=auto and gcc 7.5.0
+ With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into:
+ ...
+ (gdb) ptype global_c^M
+ ^M
+ Thread 1 "xgdb" hit Breakpoint 3, \
+ _Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \
+ gdb/c-typeprint.c:175^M
+ 175 {^M
+ (outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
+ ...
+
+ This is a problem with the debug info, which marks the CU containing the
+ function declaration as C rather than C++. This is fixed in gcc 8 and later.
+
+ Work around this compiler problem by allowing the mangled name.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30648
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648
+
+2023-07-19 Alan Modra <amodra@gmail.com>
+
+ [GOLD, PowerPC64] Debug info relocation overflow
+ It is possible to build huge binaries on powerpc64, where 32-bit
+ addresses in debug info are insufficient to descibe locations in the
+ binary. Help out the user, and only warn about debug overflows.
+
+ * powerpc.cc (Target_powerpc::Relocate::relocate): Warn on
+ relocation overflows in debug info.
+
+2023-07-19 Alan Modra <amodra@gmail.com>
+
+ Tidy binutils configure
+ Separate out some of the defines from the block handling windows
+ support, so they don't get lost. Delete an unused variable.
+
+2023-07-19 Alan Modra <amodra@gmail.com>
+
+ Build all the objdump extensions with --enable-targets=all
+ Only the xcoff and pe extensions were enabled. Build the lot, and fix
+ some more printf format problems when the host is 32-bit.
+
+ * configure.ac (od_vectors): Set up for --enable-targets=all.
+ * configure: Regenerate.
+ * od-elf32_avr.c (elf32_avr_dump_mem_usage): Correct format
+ specifier vs. arg mismatch.
+ (elf32_avr_dump_avr_prop): Likewise.
+
+2023-07-19 Alan Modra <amodra@gmail.com>
+
+ gas 32-bit host compile warnings
+ * config/tc-d10v.c (find_opcode): Correct format specifier vs.
+ arg mismatch.
+ * config/tc-m68hc11.c (fixup8, fixup16, fixup24, fixup8_xg): Likewise.
+ * config/tc-vax.c (md_assemble): Likewise.
+ * config/tc-xtensa.c (dump_litpools): Likewise.
+ * config/tc-z80.c (emit_data_val, emit_byte): Likewise.
+
+2023-07-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-18 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the binutils subdirectory
+
+2023-07-18 Pter Chubb <peter.chubb@unsw.edu.au>
+
+ PR 30632 - ld segfaults if linker script includes a STARTUP line.
+
+2023-07-18 Jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Supports Zcb extension.
+ This patch support Zcb extension, contains new compressed instructions,
+ some instructions depend on other existed extension, like 'zba', 'zbb'
+ and 'zmmul'. Zcb also imply Zca extension to enable the compressing
+ features.
+
+ Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
+ Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
+ Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
+ Co-Authored by: Simon Cook <simon.cook@embecosm.com>
+ Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
+ Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): New extension.
+ (riscv_multi_subset_supports_ext): Ditto.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): New operators.
+ (riscv_ip): Ditto.
+ * testsuite/gas/riscv/zcb.d: New test.
+ * testsuite/gas/riscv/zcb.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_C_LBU): New opcode.
+ (MASK_C_LBU): New mask.
+ (MATCH_C_LHU): New opcode.
+ (MASK_C_LHU): New mask.
+ (MATCH_C_LH): New opcode.
+ (MASK_C_LH): New mask.
+ (MATCH_C_SB): New opcode.
+ (MASK_C_SB): New mask.
+ (MATCH_C_SH): New opcode.
+ (MASK_C_SH): New mask.
+ (MATCH_C_ZEXT_B): New opcode.
+ (MASK_C_ZEXT_B): New mask.
+ (MATCH_C_SEXT_B): New opcode.
+ (MASK_C_SEXT_B): New mask.
+ (MATCH_C_ZEXT_H): New opcode.
+ (MASK_C_ZEXT_H): New mask.
+ (MATCH_C_SEXT_H): New opcode.
+ (MASK_C_SEXT_H): New mask.
+ (MATCH_C_ZEXT_W): New opcode.
+ (MASK_C_ZEXT_W): New mask.
+ (MATCH_C_NOT): New opcode.
+ (MASK_C_NOT): New mask.
+ (MATCH_C_MUL): New opcode.
+ (MASK_C_MUL): New mask.
+ (DECLARE_INSN): New opcode.
+ * opcode/riscv.h (EXTRACT_ZCB_BYTE_UIMM): New inline func.
+ (EXTRACT_ZCB_HALFWORD_UIMM): Ditto.
+ (ENCODE_ZCB_BYTE_UIMM): Ditto.
+ (ENCODE_ZCB_HALFWORD_UIMM): Ditto.
+ (VALID_ZCB_BYTE_UIMM): Ditto.
+ (VALID_ZCB_HALFWORD_UIMM): Ditto.
+ (enum riscv_insn_class): New extension class.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): New operators.
+ * riscv-opc.c: New instructions.
+
+2023-07-18 Jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Support Zca/f/d extensions.
+ This patch add Zca/f/d extensions support, since all ZC*
+ extensions will imply Zca extension, just enabled compress
+ feature when Zca extension is available.
+
+ Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
+ Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
+ Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
+ Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
+ Co-Authored by: Simon Cook <simon.cook@embecosm.com>
+ Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
+ Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
+ (riscv_multi_subset_supports_ext): Ditto.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_set_arch): Extend compress check.
+ * testsuite/gas/riscv/zca.d: New test.
+ * testsuite/gas/riscv/zca.s: New test.
+ * testsuite/gas/riscv/zcd.d: New test.
+ * testsuite/gas/riscv/zcd.s: New test.
+ * testsuite/gas/riscv/zcf.d: New test.
+ * testsuite/gas/riscv/zcf.s: New test.
+
+2023-07-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-17 Tom Tromey <tromey@adacore.com>
+
+ Remove unused declaration of child_terminal_init_with_pgrp
+ child_terminal_init_with_pgrp is declared but not defined. This patch
+ removes the declaration. Tested by grep and rebuilding.
+
+2023-07-17 Michael Matz <matz@suse.de>
+
+ Also support '^=' in linker script expressions
+ this requires also changes in ldgram.y and ldexp.c, unlike
+ accepting '^' only. But let's do this anyway, if only for
+ symmetry.
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: additional debug output in infrun.c and linux-nat.c
+ While working on some of the recent patches relating to vfork handling
+ I found this debug output very helpful, I'd like to propose adding
+ this into GDB.
+
+ With debug turned off there should be no user visible changes after
+ this commit.
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp
+ While working on gdb.base/foll-vfork.exp I noticed that there are
+ several random 'sleep' calls throughout the test.
+
+ The comment suggests these are to allow for output from a vforked
+ child to arrive, but in each case the test is about to close and
+ restart GDB, so I don't see how random output from a child process
+ could impact testing.
+
+ I removed the sleep calls and couldn't reproduce any failures from
+ this test, I left the test running for a couple of hours, and tried
+ loading my machine, and the test seems fine with these removed.
+
+ I've left this as a separate commit so that if, in the future, someone
+ can show that these are required, it will be easy to revert this one
+ patch and bring them back.
+
+ There should be no change in what is tested after this commit.
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: expand gdb.base/foll-vfork.exp
+ This commit provides tests for all of the bugs fixed in the previous
+ four commits, this is achieved by expanding gdb.base/foll-vfork.exp to
+ run with different configurations:
+
+ * target-non-stop on/off
+ * non-stop on/off
+ * schedule-multiple on/off
+
+ We don't test with schedule-multiple on if we are using a remote
+ target, this is due to bug gdb/30574. I've added a link to that bug
+ in this commit, but all this commit does is expose that bug, there's
+ no fixes here.
+
+ Some of the bugs fixed in the previous commits are very timing
+ dependent, as such, they don't always show up. I've had more success
+ when running this test on a very loaded machine -- I usually run ~8
+ copies of the test in parallel, then the bugs would normally show up
+ pretty quickly.
+
+ Other than running the test in more configurations, I've not made any
+ changes to what is actually being tested, other than in one place
+ where, when testing with non-stop mode, GDB stops in a different
+ inferior, as such I had to add a new 'inferior 2' call, this can be
+ found in vfork_relations_in_info_inferiors.
+
+ I have cleaned things up a little, for example, making use of
+ proc_with_prefix to remove some with_test_prefix calls.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30574
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't resume vfork parent while child is still running
+ Like the last few commit, this fixes yet another vfork related issue.
+ Like the commit titled:
+
+ gdb: don't restart vfork parent while waiting for child to finish
+
+ which addressed a case in linux-nat where we would try to resume a
+ vfork parent, this commit addresses a very similar case, but this time
+ occurring in infrun.c. Just like with that previous commit, this bug
+ results in the assert:
+
+ x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
+
+ In this case the issue occurs when target-non-stop is on, but non-stop
+ is off, and again, schedule-multiple is on. As with the previous
+ commit, GDB is in follow-fork-mode child. If you have not done so, it
+ is worth reading the earlier commit as many of the problems leading to
+ the failure are the same, they just appear in a different part of GDB.
+
+ Here are the steps leading to the assertion failure:
+
+ 1. The user performs a 'next' over a vfork, GDB stop in the vfork
+ child,
+
+ 2. As we are planning to follow the child GDB sets the vfork_parent
+ and vfork_child member variables in the two inferiors, the
+ thread_waiting_for_vfork_done member is left as nullptr, that member
+ is only used when GDB is planning to follow the parent inferior,
+
+ 3. The user does 'continue', our expectation is that the vfork child
+ should resume, and once that process has exited or execd, GDB should
+ detach from the vfork parent. As a result of the 'continue' GDB
+ eventually enters the proceed function,
+
+ 4. In proceed we selected a ptid_t to resume, because
+ schedule-multiple is on we select minus_one_ptid (see
+ user_visible_resume_ptid),
+
+ 5. As GDB is running in all-stop on top of non-stop mode, in the
+ proceed function we iterate over all threads that match the resume
+ ptid, which turns out to be all threads, and call
+ proceed_resume_thread_checked. One of the threads we iterate over
+ is the vfork parent thread,
+
+ 6. As the thread passed to proceed_resume_thread_checked doesn't
+ match any of the early return conditions, GDB will set the thread
+ resumed,
+
+ 7. As we are resuming one thread at a time, this thread is seen by
+ the lower layers (e.g. linux-nat) as the "event thread", which means
+ we don't apply any of the checks, e.g. is this thread a
+ vfork parent, instead we assume that GDB core knows what it's doing,
+ and linux-nat will resume the thread, we have now incorrectly set
+ running the vfork parent thread when this thread should be waiting
+ for the vfork child to complete,
+
+ 8. Back in the proceed function GDB continues to iterate over all
+ threads, and now (correctly) resumes the vfork child thread,
+
+ 8. As the vfork child is still alive the kernel holds the vfork
+ parent stopped,
+
+ 9. Eventually the child performs its exec and GDB is sent and EXECD
+ event. However, because the parent is resumed, as soon as the child
+ performs its exec the vfork parent also sends a VFORK_DONE event to
+ GDB,
+
+ 10. Depending on timing both of these events might seem to arrive in
+ GDB at the same time. Normally GDB expects to see the EXECD or
+ EXITED/SIGNALED event from the vfork child before getting the
+ VFORK_DONE in the parent. We know this because it is as a result of
+ the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
+ handle_vfork_child_exec_or_exit for details). Further the comment
+ in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
+ when we remain attached to the child (not the parent) we should not
+ expect to see a VFORK_DONE,
+
+ 11. If both events arrive at the same time then GDB will randomly
+ choose one event to handle first, in some cases this will be the
+ VFORK_DONE. As described above, upon seeing a VFORK_DONE GDB
+ expects that (a) the vfork child has finished, however, in this case
+ this is not completely true, the child has finished, but GDB has not
+ processed the event associated with the completion yet, and (b) upon
+ seeing a VFORK_DONE GDB assumes we are remaining attached to the
+ parent, and so resumes the parent process,
+
+ 12. GDB now handles the EXECD event. In our case we are detaching
+ from the parent, so GDB calls target_detach (see
+ handle_vfork_child_exec_or_exit),
+
+ 13. While this has been going on the vfork parent is executing, and
+ might even exit,
+
+ 14. In linux_nat_target::detach the first thing we do is stop all
+ threads in the process we're detaching from, the result of the stop
+ request will be cached on the lwp_info object,
+
+ 15. In our case the vfork parent has exited though, so when GDB
+ waits for the thread, instead of a stop due to signal, we instead
+ get a thread exited status,
+
+ 16. Later in the detach process we try to resume the threads just
+ prior to making the ptrace call to actually detach (see
+ detach_one_lwp), as part of the process to resume a thread we try to
+ touch some registers within the thread, and before doing this GDB
+ asserts that the thread is stopped,
+
+ 17. An exited thread is not classified as stopped, and so the assert
+ triggers!
+
+ Just like with the earlier commit, the fix is to spot the vfork parent
+ status of the thread, and not resume such threads. Where the earlier
+ commit fixed this in linux-nat, in this case I think the fix should
+ live in infrun.c, in proceed_resume_thread_checked. This function
+ already has a similar check to not resume the vfork parent in the case
+ where we are planning to follow the vfork parent, I propose adding a
+ similar case that checks for the vfork parent when we plan to follow
+ the vfork child.
+
+ This new check will mean that at step #6 above GDB doesn't try to
+ resume the vfork parent thread, which prevents the VFORK_DONE from
+ ever arriving. Once GDB sees the EXECD/EXITED/SIGNALLED event from
+ the vfork child GDB will detach from the parent.
+
+ There's no test included in this commit. In a subsequent commit I
+ will expand gdb.base/foll-vfork.exp which is when this bug would be
+ exposed.
+
+ If you do want to reproduce this failure then you will for certainly
+ need to run the gdb.base/foll-vfork.exp test in a loop as the failures
+ are all very timing sensitive. I've found that running multiple
+ copies in parallel makes the failure more likely to appear, I usually
+ run ~6 copies in parallel and expect to see a failure after within
+ 10mins.
+
+2023-07-17 Mihails Strasuns <mihails.strasuns@intel.com>
+
+ gdb, infrun: refactor part of `proceed` into separate function
+ Split the thread resuming code from proceed into new function
+ proceed_resume_thread_checked.
+
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix an issue with vfork in non-stop mode
+ This commit fixes a bug introduced by this commit:
+
+ commit d8bbae6ea080249c05ca90b1f8640fde48a18301
+ Date: Fri Jan 14 15:40:59 2022 -0500
+
+ gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on)
+
+ The problem can be seen in this GDB session:
+
+ $ gdb -q
+ (gdb) set non-stop on
+ (gdb) file ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork
+ Reading symbols from ./gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork...
+ (gdb) tcatch vfork
+ Catchpoint 1 (vfork)
+ (gdb) run
+ Starting program: /tmp/gdb/testsuite/outputs/gdb.base/foll-vfork/foll-vfork
+
+ Temporary catchpoint 1 (vforked process 1375914), 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
+ (gdb) bt
+ #0 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
+ #1 0x00000000004011af in main (argc=1, argv=0x7fffffffad88) at .../gdb/testsuite/gdb.base/foll-vfork.c:32
+ (gdb) finish
+ Run till exit from #0 0x00007ffff7d5043c in vfork () from /lib64/libc.so.6
+ [Detaching after vfork from child process 1375914]
+ No unwaited-for children left.
+ (gdb)
+
+ Notice the "No unwaited-for children left." error. This is incorrect,
+ given where we are stopped there's no reason why we shouldn't be able
+ to use "finish" to return to the main frame.
+
+ When the inferior is stopped as a result of the 'tcatch vfork', the
+ inferior is in the process of performing the vfork, that is, GDB has
+ seen the VFORKED event, but has not yet attached to the new child
+ process, nor has the child process been resumed.
+
+ However, GDB has seen the VFORKED, and, as we are going to follow the
+ parent process, the inferior for the vfork parent will have its
+ thread_waiting_for_vfork_done member variable set, this will point to
+ the one and only thread that makes up the vfork parent process.
+
+ When the "finish" command is used GDB eventually ends up in the
+ proceed function (in infrun.c), in here we pass through all the
+ function until we eventually encounter this 'else if' condition:
+
+ else if (!cur_thr->resumed ()
+ && !thread_is_in_step_over_chain (cur_thr)
+ /* In non-stop, forbid resuming a thread if some other thread of
+ that inferior is waiting for a vfork-done event (this means
+ breakpoints are out for this inferior). */
+ && !(non_stop
+ && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))
+ {
+
+ The first two of these conditions will both be true, the thread is not
+ already resumed, and is not in the step-over chain, however, the third
+ condition, this one:
+
+ && !(non_stop
+ && cur_thr->inf->thread_waiting_for_vfork_done != nullptr))
+
+ is false, and this prevents the thread we are trying to finish from
+ being resumed. This condition is false because (a) non_stop is true,
+ and (b) cur_thr->inf->thread_waiting_for_vfork_done is not
+ nullptr (see above for why).
+
+ Now, if we check the comment embedded within the condition it says:
+
+ /* In non-stop, forbid resuming a thread if some other thread of
+ that inferior is waiting for a vfork-done event (this means
+ breakpoints are out for this inferior). */
+
+ And this makes sense, if we have a vfork parent with two thread, and
+ one thread has performed a vfork, then we shouldn't try to resume the
+ second thread.
+
+ However, if we are trying to resume the thread that actually performed
+ a vfork, then this is fine. If we never resume the vfork parent then
+ we'll never get a VFORK_DONE event, and so the vfork will never
+ complete.
+
+ Thus, the condition should actually be:
+
+ && !(non_stop
+ && cur_thr->inf->thread_waiting_for_vfork_done != nullptr
+ && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr))
+
+ This extra check will allow the vfork parent thread to resume, but
+ prevent any other thread in the vfork parent process from resuming.
+ This is the same condition that already exists in the all-stop on a
+ non-stop-target block earlier in the proceed function.
+
+ My actual fix is slightly different to the above, first, I've chosen
+ to use a nested 'if' check instead of extending the original 'else if'
+ check, this makes it easier to write a longer comment explaining
+ what's going on, and second, instead of checking 'non_stop' I've
+ switched to checking 'target_is_non_stop_p'. In this context this is
+ effectively the same thing, a previous 'else if' block in proceed
+ already handles '!non_stop && target_is_non_stop_p ()', so by the time
+ we get here, if 'target_is_non_stop_p ()' then we must be running in
+ non_stop mode.
+
+ Both of these tweaks will make the next patch easier, which is a
+ refactor to merge two parts of the proceed function, so this nested
+ 'if' block is not going to exist for long.
+
+ For testing, there is no test included with this commit. The test was
+ exposed when using a modified version of the gdb.base/foll-vfork.exp
+ test script, however, there are other bugs that are exposed when using
+ the modified test script. These bugs will be addressed in subsequent
+ commits, and then I'll add the updated gdb.base/foll-vfork.exp.
+
+ If you wish to reproduce this failure then grab the updates to
+ gdb.base/foll-vfork.exp from the later commit and run this test, the
+ failure is always reproducible.
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't restart vfork parent while waiting for child to finish
+ While working on a later patch, which changes gdb.base/foll-vfork.exp,
+ I noticed that sometimes I would hit this assert:
+
+ x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
+
+ I eventually tracked it down to a combination of schedule-multiple
+ mode being on, target-non-stop being off, follow-fork-mode being set
+ to child, and some bad timing. The failing case is pretty simple, a
+ single threaded application performs a vfork, the child process then
+ execs some other application while the parent process (once the vfork
+ child has completed its exec) just exits. As best I understand
+ things, here's what happens when things go wrong:
+
+ 1. The parent process performs a vfork, GDB sees the VFORKED event
+ and creates an inferior and thread for the vfork child,
+
+ 2. GDB resumes the vfork child process. As schedule-multiple is on
+ and target-non-stop is off, this is translated into a request to
+ start all processes (see user_visible_resume_ptid),
+
+ 3. In the linux-nat layer we spot that one of the threads we are
+ about to start is a vfork parent, and so don't start that
+ thread (see resume_lwp), the vfork child thread is resumed,
+
+ 4. GDB waits for the next event, eventually entering
+ linux_nat_target::wait, which in turn calls linux_nat_wait_1,
+
+ 5. In linux_nat_wait_1 we eventually call
+ resume_stopped_resumed_lwps, this should restart threads that have
+ stopped but don't actually have anything interesting to report.
+
+ 6. Unfortunately, resume_stopped_resumed_lwps doesn't check for
+ vfork parents like resume_lwp does, so at this point the vfork
+ parent is resumed. This feels like the start of the bug, and this
+ is where I'm proposing to fix things, but, resuming the vfork parent
+ isn't the worst thing in the world because....
+
+ 7. As the vfork child is still alive the kernel holds the vfork
+ parent stopped,
+
+ 8. Eventually the child performs its exec and GDB is sent and EXECD
+ event. However, because the parent is resumed, as soon as the child
+ performs its exec the vfork parent also sends a VFORK_DONE event to
+ GDB,
+
+ 9. Depending on timing both of these events might seem to arrive in
+ GDB at the same time. Normally GDB expects to see the EXECD or
+ EXITED/SIGNALED event from the vfork child before getting the
+ VFORK_DONE in the parent. We know this because it is as a result of
+ the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see
+ handle_vfork_child_exec_or_exit for details). Further the comment
+ in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that
+ when we remain attached to the child (not the parent) we should not
+ expect to see a VFORK_DONE,
+
+ 10. If both events arrive at the same time then GDB will randomly
+ choose one event to handle first, in some cases this will be the
+ VFORK_DONE. As described above, upon seeing a VFORK_DONE GDB
+ expects that (a) the vfork child has finished, however, in this case
+ this is not completely true, the child has finished, but GDB has not
+ processed the event associated with the completion yet, and (b) upon
+ seeing a VFORK_DONE GDB assumes we are remaining attached to the
+ parent, and so resumes the parent process,
+
+ 11. GDB now handles the EXECD event. In our case we are detaching
+ from the parent, so GDB calls target_detach (see
+ handle_vfork_child_exec_or_exit),
+
+ 12. While this has been going on the vfork parent is executing, and
+ might even exit,
+
+ 13. In linux_nat_target::detach the first thing we do is stop all
+ threads in the process we're detaching from, the result of the stop
+ request will be cached on the lwp_info object,
+
+ 14. In our case the vfork parent has exited though, so when GDB
+ waits for the thread, instead of a stop due to signal, we instead
+ get a thread exited status,
+
+ 15. Later in the detach process we try to resume the threads just
+ prior to making the ptrace call to actually detach (see
+ detach_one_lwp), as part of the process to resume a thread we try to
+ touch some registers within the thread, and before doing this GDB
+ asserts that the thread is stopped,
+
+ 16. An exited thread is not classified as stopped, and so the assert
+ triggers!
+
+ So there's two bugs I see here. The first, and most critical one here
+ is in step #6. I think that resume_stopped_resumed_lwps should not
+ resume a vfork parent, just like resume_lwp doesn't resume a vfork
+ parent.
+
+ With this change in place the vfork parent will remain stopped in step
+ instead GDB will only see the EXECD/EXITED/SIGNALLED event. The
+ problems in #9 and #10 are therefore skipped and we arrive at #11,
+ handling the EXECD event. As the parent is still stopped #12 doesn't
+ apply, and in #13 when we try to stop the process we will see that it
+ is already stopped, there's no risk of the vfork parent exiting before
+ we get to this point. And finally, in #15 we are safe to poke the
+ process registers because it will not have exited by this point.
+
+ However, I did mention two bugs.
+
+ The second bug I've not yet managed to actually trigger, but I'm
+ convinced it must exist: if we forget vforks for a moment, in step #13
+ above, when linux_nat_target::detach is called, we first try to stop
+ all threads in the process GDB is detaching from. If we imagine a
+ multi-threaded inferior with many threads, and GDB running in non-stop
+ mode, then, if the user tries to detach there is a chance that thread
+ could exit just as linux_nat_target::detach is entered, in which case
+ we should be able to trigger the same assert.
+
+ But, like I said, I've not (yet) managed to trigger this second bug,
+ and even if I could, the fix would not belong in this commit, so I'm
+ pointing this out just for completeness.
+
+ There's no test included in this commit. In a couple of commits time
+ I will expand gdb.base/foll-vfork.exp which is when this bug would be
+ exposed. Unfortunately there are at least two other bugs (separate
+ from the ones discussed above) that need fixing first, these will be
+ fixed in the next commits before the gdb.base/foll-vfork.exp test is
+ expanded.
+
+ If you do want to reproduce this failure then you will for certainly
+ need to run the gdb.base/foll-vfork.exp test in a loop as the failures
+ are all very timing sensitive. I've found that running multiple
+ copies in parallel makes the failure more likely to appear, I usually
+ run ~6 copies in parallel and expect to see a failure after within
+ 10mins.
+
+2023-07-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: catch more errors in gdb.base/foll-vfork.exp
+ For *reasons* I was looking at gdb.base/foll-vfork.exp. This test
+ script has a proc 'setup_gdb' that could (potentially) fail. The
+ setup_gdb proc is called from many places and I, initially, didn't
+ think that we were checking if setup_gdb had failed or not.
+
+ My confusion was because I didn't understand what this tcl construct
+ did:
+
+ return -code return
+
+ this will actually act as a return in the context of a proc's caller,
+ effectively returning two levels of the call stack. Neat (I guess).
+
+ So it turns out my worries were misplaced, everywhere setup_gdb is
+ called, if setup_gdb fails then we will (magically) return.
+
+ However, I did spot one place where we managed to confuse ourselves
+ with our cleverness.
+
+ In check_vfork_catchpoints, this proc is called to check that GDB is
+ able to catch vforks or not. This proc is called early in the test
+ script, and the intention is that, should this proc fail, we'll mark
+ the whole test script as unsupported and then move onto the next test
+ script.
+
+ However, check_vfork_catchpoints also uses setup_gdb, and so, if that
+ call to setup_gdb fails we'll end up returning immediately from
+ check_vfork_catchpoints, and then continue with the test of _this_
+ test script, which is not correct.
+
+ To fix this I see two choices, one is remove the use of 'return -code
+ return' from setup_gdb, however, this would require every use of
+ setup_gdb to then be placed inside:
+
+ if { ![setup_gdb] } {
+ return
+ }
+
+ Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints
+ and check its return code.
+
+ I chose the second option as this is the smaller code change.
+
+ There should be no change in what is tested after this commit.
+
+2023-07-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-16 Alan Modra <amodra@gmail.com>
+
+ PR10957, Missing option to really print section+offset
+ Many of the reloc error messages have already been converted from
+ using %C to using %H in ld.bfd, to print section+offset as well as
+ file/line/function. This catches a few remaining, and changes gold to
+ do the same.
+
+ PR 10957
+ bfd/
+ * elf32-sh.c (sh_elf_relocate_section): Use %H in error messages.
+ gold/
+ * object.cc (Relocate_info::location): Always report section+offset.
+ * testsuite/debug_msg.sh: Adjust to suit.
+ * testsuite/x32_overflow_pc32.sh: Likewise.
+ * testsuite/x86_64_overflow_pc32.sh: Likewise.
+ ld/
+ * emultempl/pe.em (read_addend): Use %H in error message.
+ * emultempl/pep.em (read_addend): Likewise.
+ * ldcref.c (check_reloc_refs): Likewise.
+ * ldmain.c (warning_find_reloc, undefined_symbol): Likewise.
+ * pe-dll.c (pe_create_import_fixup): Likewise.
+ * testsuite/ld-cris/undef2.d: Adjust expected output to suit.
+ * testsuite/ld-cris/undef3.d: Likewise.
+ * testsuite/ld-elf/shared.exp: Likewise.
+ * testsuite/ld-i386/compressed1.d: Likewise.
+ * testsuite/ld-ia64/line.exp: Likewise.
+ * testsuite/ld-plugin/lto.exp: Likewise.
+ * testsuite/ld-undefined/undefined.exp: Likewise.
+ * testsuite/ld-x86-64/compressed1.d: Likewise.
+ * testsuite/ld-x86-64/line.exp: Likewise.
+ * testsuite/ld-x86-64/pr27587.err: Likewise.
+
+2023-07-16 Alan Modra <amodra@gmail.com>
+
+ Support NEXT_SECTION in ALIGNOF and SIZEOF
+ This patch is aimed at making __bss_start properly aligned with the
+ first of any bss-style sections following. Most of the work here
+ involves keeping track of the last output section seen when processing
+ the linker script.
+
+ You can almost align __bss_start properly by using
+ ${RELOCATING+. = ALIGN(${DATA_SDATA-${NO_SMALL_DATA-ALIGNOF(.${SBSS_NAME}) != 0 ? ALIGNOF(.${SBSS_NAME}) : }}${BSS_PLT+ALIGNOF(.plt) != 0 ? ALIGNOF(.plt) : }ALIGNOF(.${BSS_NAME}));}
+ and changing every place that defines NO_SMALL_DATA to use " ", but
+ having two .plt sections (marked SPECIAL) on some backends foils that
+ idea. The problem is that you only want to pick up the following
+ .plt, not the one preceeding __bss_start in the data segment if the
+ backend decides that is the proper .plt section.
+
+ Perhaps that could be fixed too, but I decided instead to extend the
+ linker script a little. THIS_SECTION and PREV_SECTION could easily be
+ added too.
+
+ * ld.texi (ALIGNOF, SIZEOF): Update and mention NEXT_SECTION.
+ * ldexp.c (output_section_find): New function.
+ (fold_name <ALIGNOF, SIZEOF>): Use output_section_find.
+ (exp_fold_tree): Add os parameter. Adjust all calls.
+ (exp_fold_tree_no_dot, exp_get_vma, exp_get_power): Likewise.
+ * ldexp.h (struct ldexp_control): Add last_os.
+ (exp_fold_tree, exp_fold_tree_no_dot): Update prototypes.
+ (exp_get_vma, exp_get_power): Likewise.
+ * ldlang.c: Pass last output section to expression folder
+ calls throughout file.
+ (open_input_bfds): Add os parameter to track last os seen.
+ (lang_size_sections_1): Rename output_section_statement param
+ to current_os. Track last os.
+ (lang_do_assignments_1): Track last os.
+ * scripttempl/arclinux.sc: Align to ALIGNOF NEXT_SECTION
+ before defining __bss_start.
+ * scripttempl/elf.sc: Likewise.
+ * scripttempl/elf64bpf.sc: Likewise.
+ * scripttempl/elf64hppa.sc: Likewise.
+ * scripttempl/elf_chaos.sc: Likewise.
+ * scripttempl/elfarc.sc: Likewise.
+ * scripttempl/elfd10v.sc: Likewise.
+ * scripttempl/elfxtensa.sc: Likewise.
+ * scripttempl/epiphany_4x4.sc: Likewise.
+ * scripttempl/iq2000.sc: Likewise.
+ * scripttempl/mep.sc: Likewise.
+ * scripttempl/nds32elf.sc: Likewise.
+ * scripttempl/xstormy16.sc: Likewise.
+ * testsuite/ld-x86-64/pe-x86-64-5.od: Update expected __bss_start.
+ * testsuite/ld-x86-64/pe-x86-64-5.rd: Likewise.
+
+2023-07-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle has_native_target in gdb.testsuite/gdb-caching-proc-consistency.exp
+ With test-case gdb.testsuite/gdb-caching-proc-consistency.exp we run into:
+ ...
+ ERROR: no fileid for xerxes
+ Couldn't send help target native to GDB.
+ UNRESOLVED: <exp>: have_native_target: initial: help target native
+ ...
+
+ Fix this by handling have_native_target in
+ gdb.testsuite/gdb-caching-proc-consistency.exp.
+
+ Tested on x86_64-linux.
+
+2023-07-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: make tui_win_info::title private
+ This commit builds on this earlier work:
+
+ commit 9fe01a376b2fb096e4836e985ba316ce9dc02399
+ Date: Thu Jun 29 11:26:55 2023 -0600
+
+ Update TUI window title when changed
+
+ and makes tui_win_info::title private, renaming to m_title at the same
+ time. There's a new tui_win_info::title() member function to provide
+ read-only access to the title.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: style filenames in separate debug file warnings
+ After the commit:
+
+ commit 6647f05df023b63bbe056e9167e9e234172fa2ca
+ Date: Tue Jan 24 18:13:38 2023 +0100
+
+ gdb: defer warnings when loading separate debug files
+
+ It was pointed out[1] that the warnings being deferred and then later
+ emitted lacked styling. The warnings lacked styling before the above
+ commit, but it was suggested that the filenames in these warnings
+ should be styled, and this commit does this.
+
+ There were a couple of previous attempts[2][3][4] to solve this
+ problem, but these all tried to extend the mechanism introduced in the
+ above commit, the deferred warnings were placed directly into a
+ std::vector, but now we tried to, when appropriate, style these
+ warnings. The review feedback that this approach looked too complex.
+
+ So instead, this revision adds a new helper class 'deferred_warnings'
+ which can be used to collect a set of deferred warnings, and then emit
+ these deferred warnings later, if needed. This helper class hides the
+ complexity, so at the point the deferred warning is created no extra
+ logic is required.
+
+ The deferred_warnings class will style the deferred warnings only if
+ gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr,
+ so this should ensure we only style when expected.
+
+ There was also review feedback[5] that all of the warnings should be
+ bundled into a single string_file, this has not been done. I feel
+ pretty strongly that separate warnings should be emitted using
+ separate "warning" calls. If we do end up with multiple warnings in
+ this case they aren't really related, one will be about looking up
+ debug via .gnu_debuglink, while the other will be about build-id based
+ lookup. So I'd really rather keep the warnings separate.
+
+ [1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
+ [2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
+ [3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
+ [4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
+ [5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/
+
+ Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-07-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/forward-spec.exp with read1
+ When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run
+ into:
+ ...
+ parent: ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent
+ 7fdc1c002ed0) [ns]^M
+ ...
+
+ The problem is using regexps containing '.' to avoid escaping, which makes
+ them too generic.
+
+ Fix this by eliminating the '.' from the regexps.
+
+ Tested on x86_64-linux.
+
+2023-07-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Use correct inferior in Inferior.read_memory et al
+ A user noticed that Inferior.read_memory and a few other Python APIs
+ will always use the currently selected inferior, not the one passed to
+ the call.
+
+ This patch fixes the bug by arranging to switch to the inferior. I
+ found this same issue in several APIs, so this fixes them all.
+
+ I also added a few missing calls to INFPY_REQUIRE_VALID to these
+ methods.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30615
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Introduce scoped_restore_current_inferior_for_memory
+ This introduces a new class,
+ scoped_restore_current_inferior_for_memory, and arranges to use it in
+ a few places. This class is intended to handle setting up and
+ restoring the various globals that are needed to read or write memory
+ -- but without invalidating the frame cache.
+
+ I wasn't able to test the change to aix-thread.c.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Remove obsolete comment from gdbthread.h
+ A comment in gdbthread.h refers to a global that no longer exists.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Rename Python variable in py-inferior.exp
+ py-inferior.exp creates a Python variable named 'str'. This clashes
+ with the built-in type of the same name and can be confusing when
+ trying to evaluate Python code when debugging the test case. This
+ patch renames it.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Refactor py-inferior.exp
+ This changes py-inferior.exp to make it a bit more robust when adding
+ new inferiors during the course of the test.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Minor cleanups in py-inferior.exp
+ While working on this series, I noticed a some oddities in
+ py-inferior.exp. One is an obviously incorrect comment, and the
+ others are confusing test names. This patch fixes these.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-14 Tom Tromey <tromey@adacore.com>
+
+ Revert "Simplify auto_load_expand_dir_vars and remove substitute_path_component"
+ This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489.
+
+ This commit was a refactoring to remove an xrealloc and simplify
+ utils.[ch]. However, it has a flaw -- it mishandles a substitution
+ like "$datadir/subdir".
+
+ I am backing out the patch in the interests of fixing the regression
+ before GDB 14. It can be reinstated (with modifications) later if we
+ like.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-07-14 John Baldwin <jhb@FreeBSD.org>
+
+ Test that native targets can read a tdesc without a process attached.
+ This ensures that 'unset tdesc filename' does not generate any output
+ on a "bare" native target inferior without an attached process.
+
+ Add a have_native_target helper function for use with require.
+ Move logic from auto-connect-native-target.exp into this helper.
+
+2023-07-14 John Baldwin <jhb@FreeBSD.org>
+
+ *-linux-nat: Handle null inferior in read_description.
+ Don't invoke ptrace in the target read_description method if there is
+ not an active inferior to query via ptrace. Instead, use the default
+ register set for the architecture.
+
+ Previously the native target could report an error from a failed
+ ptrace operation when fetching a tdesc without an attached process.
+ For example on Linux x86-64:
+
+ (gdb) target native
+ Done. Use the "run" command to start a process.
+ (gdb) unset tdesc filename
+ Couldn't get CS register: No such process.
+
+2023-07-14 John Baldwin <jhb@FreeBSD.org>
+
+ *-fbsd-nat: Handle null inferior in read_description.
+ Don't invoke ptrace in the target read_description method if there is
+ not an active inferior to query via ptrace. Instead, use the default
+ register set for the architecture.
+
+ Previously the native target could report an error from a failed
+ ptrace operation when fetching a tdesc without an attached process.
+ For example on FreeBSD/amd64:
+
+ (gdb) target native
+ Done. Use the "run" command to start a process.
+ (gdb) unset tdesc filename
+ Couldn't get registers: Operation not permitted.
+
+2023-07-14 Tobias Burnus <tobias@codesourcery.com>
+
+ Re: Let '^' through the lexer
+ Fix "make pdf".
+
+2023-07-14 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/doc: document '+' argument for 'list' command
+ The command 'list' has accepted the argument '+' for many years already,
+ but this option wasn't documented either in the texinfo docs or in the
+ help text for the command. This commit documents it.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-14 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/cli: Improve UX when using list with no args
+ When using "list" with no arguments, GDB will first print the lines
+ around where the inferior is stopped, then print the next N lines until
+ reaching the end of file, at which point it warns the user "Line X out
+ of range, file Y only has X-1 lines.". This is usually desirable, but
+ if the user can no longer see the original line, they may have forgotten
+ the current line or that a list command was used at all, making GDB's
+ error message look cryptic. It was reported in bugzilla as PR cli/30497.
+
+ This commit improves the user experience by changing the behavior of
+ "list" slightly when a user passes no arguments. It now prints that the
+ end of the file has been reached and recommends that the user use the
+ command "list ." instead.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-14 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/cli: add '.' as an argument for 'list' command
+ Currently, after the user has used the list command once, there is no
+ self-contained way to ask GDB to print the location where the inferior is
+ stopped. The current best options require either using a separate
+ command to scope out where the inferior is stopped, or using "list *$pc"
+ requiring knowledge of GDB standard registers. This commit adds a way
+ to do that using '.' as a new argument for the 'list' command. If the
+ inferior isn't running, the command prints around the main function.
+
+ Because this necessitated having the inferior running and the test was
+ (seemingly unnecessarily) using printf in a non-essential way and it
+ would make the resulting log harder to read for no benefit, it was
+ replaced by a different statement.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-14 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/cli: Factor out code to list lines around a given line
+ A future patch will add more situations that calculates "lines around a
+ certain point" to be printed using print_source_lines, and the logic
+ could be re-used. As a preparation for those commits, this one factors
+ out that part of the logic of the list command into its own function.
+ No functional changes are expected
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30602 [2.41] gprofng test hangs on i686-linux-gnu
+ There were several problems in the gprofng testing:
+ - we did not catch a timeout for each test.
+ - we used exit() to stop a failed test. But this stops all other tests.
+ - we used a time_t (long) type in smalltest.c instead of a long long type.
+
+ PR gprofng/30602
+ * configure.ac: Launch only native testing.
+ * configure: Rebuild.
+ * testsuite/config/default.exp: Set TEST_TIMEOUT.
+ * testsuite/gprofng.display/setpath_map.exp: Use return instead of exit.
+ * testsuite/gprofng.display/gp-archive.exp: Likewise.
+ * testsuite/gprofng.display/gp-collect-app_F.exp: Likewise.
+ * testsuite/gprofng.display/display.exp: Delete an unnecessary test
+ for native testing.
+ * testsuite/lib/display-lib.exp (run_native_host_cmd): Add timeout.
+ * testsuite/lib/smalltest.c: Use a long long type instead of time_t.
+
+2023-07-14 Alan Modra <amodra@gmail.com>
+
+ Make the default gas symbol hash table larger
+ We may as well start with the symbol table a little larger, saving
+ time resizing. Even a simple C hello world compiled with -O2 -g will
+ exceed 16 symbols (by well over 3 times with gcc-11).
+
+ * symbols.c (symbol_begin): Create sy_hash with more entries.
+
+2023-07-14 Alan Modra <amodra@gmail.com>
+
+ Fix loongarch build with gcc-4.5
+ * loongarch-opc.c (loongarch_alias_opcodes): Don't trigger
+ gcc-4.5 bug in handling of struct initialisation.
+
+2023-07-14 Alan Modra <amodra@gmail.com>
+
+ More tidies to objcopy archive handling
+ This makes sure copy_archive exits with ibfd and obfd closed. Error
+ paths didn't do that, leading to memory leaks. None of this matters
+ very much.
+
+ * objcopy.c (copy_archive): bfd_close ibfd and obfd on error
+ return paths. Remove braces around "list" free.
+ (copy_file): Don't close invalid file descriptor.
+
+2023-07-14 Alan Modra <amodra@gmail.com>
+
+ AIX_WEAK_SUPPORT
+ Making target code depend on a host define like _AIX52 is never
+ correct, so out it goes. Also, sort some config.bfd entries a little
+ to make it more obvious there is a config difference between aix5.1
+ and aix5.2. These two changes should make no difference to anything
+ in binutils. The gas define of AIX_WEAK_SUPPORT on the other hand was
+ wrong, so fix that. Finally, fix some testsuite fails on aix < 5.2 by
+ simply not running the tests.
+
+ include/
+ * coff/internal.h (C_WEAKEXT): Don't depend on _AIX52.
+ bfd/
+ * coffcode.h (coff_slurp_symbol_table): Don't depend on _AIX52.
+ (coff_classify_symbol): Likewise.
+ * config.bfd: Sort some entries.
+ gas/
+ * configure.ac (AIX_WEAK_SUPPORT): Don't set for aix5.[01].
+ * configure: Regenerate.
+ * testsuite/gas/ppc/aix.exp (xcoff-visibility-1*) Don't run
+ for aix < 5.2.
+
+2023-07-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-13 Tom Tromey <tromey@adacore.com>
+
+ Implement 'Enum_Val and 'Enum_Rep
+ This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-07-13 Tom Tromey <tromey@adacore.com>
+
+ Remove ada_attribute_name
+ ada_attribute_name uses an array that must be kept in sync with an
+ enum -- but the comment here refers to an enum that no longer exists.
+ Looking at the sole caller, I see this can only be called for two
+ opcodes. So, remove this entirely and inline it.
+
+2023-07-13 Michael Matz <matz@suse.de>
+
+ Let '^' through the lexer
+ so that the (existing) code in parser and expression evaluator
+ actually get to see it and handle it as XOR. Also adjust docu
+ to match what's there.
+
+2023-07-13 Alan Modra <amodra@gmail.com>
+
+ elf_object_p load of dynamic symbols
+ This fixes an uninitialised memory access on a fuzzed file:
+ 0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2
+ 1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13
+ 2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9
+
+ Hopefully it will also stop any attempt to load dynamic symbols from
+ eu-strip debug files.
+
+ * elfcode.h (elf_object_p): Do not attempt to load dynamic
+ symbols for a file with no section headers until all the
+ program headers are swapped in. Do not fail on eu-strip debug
+ files.
+
+2023-07-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Assume HAVE_WBORDER
+ The tui border-kind setting allows values acs, ascii and space.
+
+ The values ascii and space however don't work well with !HAVE_WBORDER.
+
+ Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
+ support, which is now obsolete.
+
+ Tested on x86_64-linux.
+
+ PR tui/30580
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Make translate return entry->value instead of entry
+ The only use of "entry = translate (...)" is entry->value.
+
+ Simplify using the function by returning entry->value instead.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Merge tui border-kind corner translation tables
+ The tables:
+ - tui_border_kind_translate_ulcorner
+ - tui_border_kind_translate_urcorner
+ - tui_border_kind_translate_llcorner
+ - tui_border_kind_translate_lrcorner
+ are identical.
+
+ Merge and rename to tui_border_kind_translate_corner.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Introduce translate_acs
+ In function tui_update_variables we have the somewhat inconvenient:
+ ...
+ entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
+ int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
+ ...
+
+ Add a new function translate_acs, that allows us to do the more straighforward:
+ ...
+ int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner,
+ ACS_LRCORNER);
+ ...
+
+ By special-casing "acs" in translate_acs, we can now remove the acs entries
+ from the translation tables.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Remove default entries in TUI translation tables
+ The TUI translation tables contain default entries at the end:
+ ...
+ static struct tui_translate tui_border_kind_translate_hline[] = {
+ { "space", ' ' },
+ { "ascii", '-' },
+ { "acs", -1 },
+ { 0, 0 },
+ { "ascii", '-' }
+ };
+ ...
+
+ A simpler way of implementing this would be to to declare the first (or last)
+ entry the default, but in fact these default entries are not used.
+
+ Make this explicit by removing the default entries, and asserting in translate
+ that an entry will always be found.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-12 Alan Modra <amodra@gmail.com>
+
+ .noinit and .persistent for msp430
+ Similar to the previous patch, but also tidy a few more sections.
+
+ * scripttempl/elf32msp430.sc (.text, .rodata, .data, .bss, .noinit),
+ (.persistent): Align the section rather than aligning inside.
+
+2023-07-12 Alan Modra <amodra@gmail.com>
+
+ .noinit and .persistent alignment
+ It's more elegant to make the section match up with its "_start"
+ symbol. We could align by setting the address of the section (by
+ using ALIGN before the colon), but this way we also set sh_addralign
+ to at least $ALIGNMENT.
+
+ * scripttempl/elf.sc (.noinit, .persistent): Align the output
+ section rather than using ". = ALIGN();" at the beginning.
+ Set address to zero when not a final link.
+
+2023-07-12 Alan Modra <amodra@gmail.com>
+
+ Re: Align linkerscript symbols according to ABI
+ Align dot before symbols defined outside of output sections. Before _end
+ is already aligned.
+
+ * scripttempl/elf.sc (def_symbol): Tidy excess space.
+ (_edata): Align before emitting symbol when SYMBOL_ABI_ALIGNMENT.
+
+2023-07-12 Alan Modra <amodra@gmail.com>
+
+ Re: Keeping track of rs6000-coff archive element pointers
+ bfd/
+ * coff-rs6000.c (add_range): Revise comment, noting possible fail.
+ (_bfd_xcoff_openr_next_archived_file): Start with clean ranges.
+ binutils/
+ * bfdtest1.c: Enhance to catch errors on second scan.
+
+2023-07-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-11 Tom Tromey <tromey@adacore.com>
+
+ Remove some TODOs from gdb.cp tests
+ This patch removes many TODOs from the gdb.cp tests.
+ Going through the patch:
+
+ * bs15503.exp - these have been commented out forever and rely on
+ libstdc++ debuginfo. It's better to just remove these.
+
+ * classes.exp - the test is wrong, I think, according to the C++ ABI
+ that gdb understands; and the test can be fixed and comments removed
+ with a simple change to the code.
+
+ * ctti.exp - there's no need to bail out any more, as the test works.
+
+ * exception.exp - the code relying on the line numbers can't work,
+ because gdb never prints that message anyway.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: simplify table-referencing macros
+ First of all it is entirely unclear why THREE_BYTE_TABLE_PREFIX() was
+ introduced by bf890a93a7c4. Nothing uses the .prefix_requirement values
+ from the two relevant entries.
+
+ And then having VEX_Cn_TABLE() and friends take arguments is misleading.
+ These aren't used (or pointlessly used in the case of VEX_C5_TABLE); the
+ respective table index is decoded from the insn (or implied in the case
+ of VEX_C5_TABLE).
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: convert 0FXOP to just XOP in enumerator names
+ There's nothing 0f-ish in XOP encodings.
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: misc further register-only insns don't need to go through mod_table[]
+ Several already use OP_R(), which rejects the memory forms of insns, and
+ a few others can easily be converted to do so as well. Note that for it
+ to be able to use BadOp() without forward declaration, OP_Skip_MODRM() is
+ moved down.
+
+ While there add the previously missing PREFIX_OPCODE to legacy opcode
+ 0FD7.
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: various operations on mask registers can avoid going through mod_table[]
+ Now that we have OP_R(), use it here as well, while wiring memory-only
+ operands to OP_M() at the same time. To keep the number of consumed
+ opcode bytes similar to before, make BadOp() also account for VEX/XOP/
+ EVEX prefix bytes. To keep that change simple, convert need_vex to an
+ actual count of prefix bytes (keeping intact all prior boolean uses of
+ the field).
+
+ Note how this improves disassembly of such bad encodings, by at least
+ leaving a hint towards what a "nearby" instruction is. (For KSHIFT*
+ change the immediates test testcases use, such that disassembly remains
+ sufficiently in sync.)
+
+ While there also use Ux for VPMOV{B,W,D,Q}2M, where decoding through
+ mod_table[] was missing in the earlier scheme.
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: slightly rework handling of some register-only insns
+ Fold OP_MS() and OP_XS() into OP_R(), paralleling OP_M(). Use operand
+ names (largely) matching those in the SDM. For 128-bit-only forms use
+ Uxmm though, marking 256-bit forms as bad. This then allows no longer
+ going through vex_len_table[] for two of the insns.
+
+ Specifically _do not_ continue to mis-use v_mode.
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: SIMD shift-by-immediate don't need to go through mod_table[]
+ OP_MS() and OP_XS() reject memory forms of insns quite fine. This then
+ also eliminates mis-named enumerators (we use M_1 for register forms).
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: misc further memory-only insns don't need to go through mod_table[]
+ Several already use OP_M(), which rejects the register forms of insns,
+ and a few others can easily be converted to do so as well. (Note that
+ FXSAVE_Fixup() wires through to OP_M(). Note further that OP_IndirE(),
+ which wasn't placed very well anyway, is moved down to avoid the need to
+ forward-declare BadOp().)
+
+ Also adjust formatting of and drop PREFIX_OPCODE from a few adjacent
+ entries.
+
+2023-07-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: {,V}MOVNT* don't need to go through mod_table[]
+ Most of them use Mx already for the memory operand, which rejects the
+ register form of the insn. Use that operand type also for the two EVEX
+ forms which so far have used EXEvexXNoBcst (and thus failed to reject
+ the register forms), compensating by flagging broadcast as bad for all
+ Mx. This way several other insns which don't permit embedded broadcast
+ either are also covered at the same time.
+
+ x86: fold legacy/VEX {,V}MOV{H,L}* entries
+ By changing decode order to do ModR/M.mod last (rather than VEX.L), the
+ VEX entries (which are already reused by EVEX decoding) can be folded
+ with their legacy counterparts as well. Note how this change of decode
+ order also allows removing two auxiliary #define-s, which were
+ introduced during earlier folding (because of that unhelpful order of
+ steps).
+
+ x86: fold certain legacy/VEX table entries
+ Introduce macro V to expand to 'v' in the VEX/EVEX case, and replace a
+ couple of abort()s where legacy code can now legitimately make it. While
+ there for {,V}LDDQU drop hoing through mod_table[] - OP_M() rejects
+ register operands quite fine.
+
+ ld/PDB: fix off-by-1 in add_globals_ref()
+ Copying one too many bytes can corrupt memory, detected/reported by
+ glibc on a 32-bit distro.
+
+2023-07-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Remove target_close
+ I noticed that target_close is only called in two places:
+ solib-svr4.c, and target_ops_ref_policy::decref.
+
+ This patch fixes the former by changing target_bfd_reopen to return a
+ target_ops_up and then fixing the sole caller. Then it removes
+ target_close by inlining its body into the decref method.
+
+ The advantage of this approach is that targets are now automatically
+ managed.
+
+ Regression tested on x86-64 Fedora 38.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Update TUI window title when changed
+ I wrote a TUI window in Python, and I noticed that setting its title
+ did not result in a refresh, so the new title did not appear. This
+ patch corrects this problem.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Add Ada scope test for DAP
+ This adds a DAP test for fetching scopes and variables with an Ada
+ program. This test is the reason that the FrameVars code does not
+ check is_constant on the symbols it returns.
+
+ Note that this test also shows that string-printing is incorrect in
+ Ada. This is a known bug but I'm still considering how to fix it.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Handle typedefs in no-op pretty printers
+ The no-ops pretty-printers that were introduced for DAP have a classic
+ gdb bug: they neglect to call check_typedef. This will cause some
+ strange behavior; for example not showing the children of a variable
+ whose type is a typedef of a structure type. This patch fixes the
+ oversight.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Reimplement DAP stack traces using frame filters
+ This reimplements DAP stack traces using frame filters. This slightly
+ simplifies the code, because frame filters and DAP were already doing
+ some similar work. This also renames RegisterReference and
+ ScopeReference to make it clear that these are private (and so changes
+ don't have to worry about other files).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30468
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Simplify FrameVars
+ FrameVars implements its own variant of Symbol.is_variable. This
+ patch replaces this code.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Fix oversights in frame decorator code
+ The frame decorator "FrameVars" code misses a couple of cases,
+ discovered when working on related DAP changes.
+
+ First, fetch_frame_locals does not stop when reaching a function
+ boundary. This means it would return locals from any enclosing
+ functions.
+
+ Second, fetch_frame_args assumes that all arguments are at the
+ outermost scope, but this doesn't seem to be required by gdb.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Add new interface to frame filter iteration
+ This patch adds a new function, frame_iterator, that wraps the
+ existing code to find and execute the frame filters. However, unlike
+ execute_frame_filters, it will always return an iterator -- whereas
+ execute_frame_filters will return None if no frame filters apply.
+
+ Nothing uses this new function yet, but it will used by a subsequent
+ DAP patch.
+
+2023-07-10 Tom Tromey <tromey@adacore.com>
+
+ Fix execute_frame_filters doc string
+ When reading the doc string for execute_frame_filters, I wasn't sure
+ if the ranges were inclusive or exclusive. This patch updates the doc
+ string to reflect my findings, and also fixes an existing typo.
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Change 'handle_id' to be a local variable
+ The global variable 'handle_id' in tracectf.c is only used in a single
+ function, so change it to be a local variable.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Move definition of ctf_target type
+ This moves the definition of the ctf_target type into the
+ HAVE_LIBBABELTRACE block. This type is only used in this block, so it
+ makes sense to only define it there.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Constify tfile_interp_line
+ This adds 'const' to tfile_interp_line.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Use function_view in traceframe_walk_blocks
+ This change traceframe_walk_blocks to take a function_view. This
+ simplifies the code somewhat and lets us entirely remove one helper
+ function.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Use unique_ptr for trace_dirname
+ This changes trace_dirname to use unique_ptr, removing some manual
+ memory management.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Use unique_ptr for trace_filename
+ This changes trace_filename to use unique_ptr, removing some manual
+ memory management.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Replace use of xfree with byte_vector
+ This replaces a use of xfree with a byte_vector.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Remove a use of xfree
+ This removes a use of xfree from tracefile-tfile.c, replacing it with
+ a unique_xmalloc_ptr.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-07-10 Tom Tromey <tom@tromey.com>
+
+ Avoid crash with absolute symbol
+ A user supplied an executable and a remote logfile that could be used
+ to crash gdb. The problem is that the BFD section for a particular
+ symbol was null, because the section was not marked "allocated".
+ Digging deeper, the problem was that elfread.c dropped the section for
+ absolute symbols. This patch fixes the crash.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431
+
+2023-07-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: handle all eval_result_type values in tracepoint.cc
+ It was pointed out[1] that after this commit:
+
+ commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab
+ Date: Thu Oct 20 11:14:33 2022 +0100
+
+ gdbserver: allow agent expressions to fail with invalid memory access
+
+ Now that agent expressions might fail with the error
+ expr_eval_invalid_memory_access, we might overflow the
+ eval_result_names array in tracepoint.cc. This is because the
+ eval_result_names array does not include a string for either
+ expr_eval_invalid_goto or expr_eval_invalid_memory_access.
+
+ I don't know if having expr_eval_invalid_goto missing is also a
+ problem, but it feels like eval_result_names should just include a
+ string for every possible error.
+
+ I could just add two more strings into the array, but I figure that a
+ more robust solution will be to move all of the error types, and their
+ associated strings, into a new ax-result-types.def file, and to then
+ include this file in both ax.h and tracepoint.cc in order to build
+ the enum eval_result_type and the eval_result_names string array.
+ Doing this means it is impossible to have a missing error string in
+ the future.
+
+ [1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: avoid stack addresses in test names
+ When comparing the test results for two different runs of GDB I
+ noticed a difference in the results for gdb.base/frame-view.exp.
+
+ The difference was caused by one of the tests including a stack
+ address in the test name:
+
+ PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b
+
+ and
+
+ PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b
+
+ If for whatever reason the stack address changes between test runs
+ then it becomes harder to compare results.
+
+ Fix this by giving the test a descriptive name that doesn't include a
+ stack address:
+
+ PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1
+
+ and
+
+ PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1
+
+ There's no change to what is actually tested after this commit.
+
+2023-07-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: return after reporting a test unsupported
+ In this commit:
+
+ commit 8bcead69665af3a9f9867cd34c3a1daf22120027
+ Date: Tue May 23 11:25:01 2023 +0100
+
+ gdb/testsuite: add test for core file with a 0 pid
+
+ a new test gdb.arch/core-file-pid0.exp was added. This test includes
+ a pre-generated core file for x86-64 and for other architectures the
+ test reports 'unsupported'.
+
+ However, after reporting 'unsupported' the test failed to perform an
+ early return, so the test would then carry on and try to actually
+ perform the test, which resulted in some TCL errors.
+
+ Fix this by returning after reporting the test unsupported.
+
+2023-07-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: include location number in breakpoint error message
+ This commit improves the output of this previous commit:
+
+ commit 2dc3457a454a35d0617dc1f9cc1db77468471f95
+ Date: Fri Oct 14 13:22:55 2022 +0100
+
+ gdb: include breakpoint number in testing condition error message
+
+ The earlier commit extended the error message:
+
+ Error in testing breakpoint condition:
+
+ to include the breakpoint number, e.g.:
+
+ Error in testing breakpoint condition 3:
+
+ This commit extends takes this further, and includes the location
+ number if the breakpoint has multiple locations, so we might now see:
+
+ Error in testing breakpoint condition 3.2:
+
+ Just as with how GDB reports a normal breakpoint stop, if a breakpoint
+ only has a single location then the location number is not included,
+ this keeps things nice and consistent.
+
+ I've extended one of the tests to cover the new functionality.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-07-10 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb/testsuite: Testing with the nvfortran compiler
+ Currently, the Fortran test suite does not run with NVIDIA's Fortran
+ compiler (nvfortran).
+
+ The goal here is to get the tests running and preventing further
+ regressions during future work. This change does not do anything to fix
+ existing failures.
+
+ Teach the compiler detection about nvfortran. There is no underlying
+ information about whether this compiler is related to flang classic or
+ flang, so we cannot reuse the main and type definitions. Therefore, we
+ explicitly record the main method and type information observed when
+ using nvfortran.
+
+ The main name was extracted by trying to set breakpoints on both MAIN_
+ and MAIN__.
+
+ The following mapping of test to type names was used to extract how
+ nvfortran reports types.
+
+ info-types.exp: fortran_int4, fortran_int8, fortran_real4,
+ fortran_logical4
+
+ common-block.exp: fortran_real8
+
+ complex.exp: fortran_complex4 fortran_complex8
+
+ logical.exp: fortran_character1. Ran ptype on "c".
+
+ Types defined as fortran_complex16 do not compile with nvfortran, so it
+ was left unset.
+
+ gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
+ No regressions detected.
+
+ The gdb.fortran test results with nvfortran 23.3 are as follows.
+
+ Before:
+
+ # of expected passes 523
+ # of unexpected failures 107
+ # of known failures 2
+ # of unresolved testcases 1
+ # of untested testcases 7
+ # of duplicate test names 2
+
+ After:
+
+ # of expected passes 5696
+ # of unexpected failures 271
+ # of known failures 12
+ # of untested testcases 9
+ # of unsupported tests 5
+
+ As can be seen from the above, there are now considerably more passing
+ assertions.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-09 Fangrui Song <maskray@google.com>
+
+ PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE
+ For example, objcopy --set-section-flags .data=alloc,large will add
+ SHF_X86_64_LARGE to the .data section. Omitting "large" will drop the
+ SHF_X86_64_LARGE flag.
+
+ The bfd_section flag is named generically, SEC_ELF_LARGE, in case other
+ processors want to follow SHF_X86_64_LARGE. SEC_ELF_LARGE has the same
+ value as SEC_TIC54X_BLOCK used by coff.
+
+ bfd/
+ * section.c: Define SEC_ELF_LARGE.
+ * bfd-in2.h: Regenerate.
+ * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections,
+ elf_x86_64_copy_private_section_data): New.
+
+ binutils/
+ * NEWS: Mention the new feature for objcopy.
+ * doc/binutils.texi: Mention "large".
+ * objcopy.c (parse_flags): Parse "large".
+ (check_new_section_flags): Error if "large" is used with a
+ non-x86-64 ELF target.
+ * testsuite/binutils-all/x86-64/large-sections.d: New.
+ * testsuite/binutils-all/x86-64/large-sections.s: New.
+ * testsuite/binutils-all/x86-64/large-sections-i386.d: New.
+ * testsuite/binutils-all/x86-64/large-sections-2.d: New.
+ * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.
+
+2023-07-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-08 Aaron Merey <amerey@redhat.com>
+
+ gdb/cp-namespace.c: Fix assert failure caused by malformed user input
+ When debugging C++ programs, it is possible to trigger a spurious assert
+ failure when attempting to set a breakpoint on a malformed symbol name.
+ Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
+ cp_lookup_bare_symbol:
+
+ $ gdb gdb
+ [...]
+ (gdb) br test>::assert
+ Function "test>::assert" not defined.
+ Make breakpoint pending on future shared library load? (y or [n]) y
+ Breakpoint 1 (test>::assert) pending.
+ (gdb) start
+ [...]
+ cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x5217e2 gdb_internal_backtrace_1
+ /home/amerey/binutils-gdb/gdb/bt-utils.c:122
+ 0x521885 _Z22gdb_internal_backtracev
+ /home/amerey/binutils-gdb/gdb/bt-utils.c:168
+ 0xaf8303 internal_vproblem
+ /home/amerey/binutils-gdb/gdb/utils.c:396
+ 0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
+ /home/amerey/binutils-gdb/gdb/utils.c:476
+ 0xccdb3f _Z18internal_error_locPKciS0_z
+ /home/amerey/binutils-gdb/gdbsupport/errors.cc:58
+ 0x5dded9 cp_lookup_bare_symbol
+ /home/amerey/binutils-gdb/gdb/cp-namespace.c:181
+ 0x5de39d cp_lookup_symbol_in_namespace
+ /home/amerey/binutils-gdb/gdb/cp-namespace.c:328
+ [...]
+
+ Currently this assert is skipped if the symbol name contains '<' or '('.
+ Fix this spurious failure by also skipping the assert when the symbol
+ name contains '>' or ')'.
+
+ Regression tested on F38 x86_64.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-07-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-07 Tom Tromey <tromey@adacore.com>
+
+ Fix result of DAP setExpression
+ A co-worker, Andry, noticed that the DAP setExpression implementation
+ returned the wrong fields -- it used "result" rather than "value", and
+ included "memoryReference", which isn't in the spec (an odd oversight,
+ IMO).
+
+ This patch fixes the problems.
+
+2023-07-07 Tom Tromey <tromey@adacore.com>
+
+ Remove unchecked casts to mi_interp
+ Simon noticed a crash that could be caused via new Python
+ gdb.execute_mi function. Looking into this, I found a few unchecked
+ casts to mi_interp, like:
+
+ - struct mi_interp *mi = (struct mi_interp *) command_interp ();
+
+ This patch replaces all such casts with safer variants.
+
+ For -gdb-exit and mi_load_progress, I chose to have the functions
+ simply not generate any output. It didn't seem useful to do so.
+
+ Some casts I eliminated by adding a parameter to a function. Then, in
+ mi_execute_command, I changed the code to use
+ gdb::checked_static_cast. This is appropriate because this particular
+ overload can only be called by the MI interpreter.
+
+ There does not seem to be a very good way to test -gdb-exit.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-07-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: check max-value-size when reading strings for printf
+ I noticed that the printf code for strings, printf_c_string and
+ printf_wide_c_string, don't take max-value-size into account, but do
+ load a complete string from the inferior into a GDB buffer.
+
+ As such it would be possible for an badly behaved inferior to cause
+ GDB to try and allocate an excessively large buffer, potentially
+ crashing GDB, or at least causing GDB to swap lots, which isn't
+ great.
+
+ We already have a setting to protect against this sort of thing, the
+ 'max-value-size'. So this commit updates the two function mentioned
+ above to check the max-value-size and give an error if the
+ max-value-size is exceeded.
+
+ If the max-value-size is exceeded, I chose to continue reading
+ inferior memory to figure out how long the string actually is, we just
+ don't store the results. The benefit of this is that when we give the
+ user an error we can tell the user how big the string actually is,
+ which would allow them to correctly adjust max-value-size, if that's
+ what they choose to do.
+
+ The default for max-value-size is 64k so there should be no user
+ visible changes after this commit, unless the user was previously
+ printing very large strings. If that is the case then the user will
+ now need to increase max-value-size.
+
+2023-07-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove last alloca call from printcmd.c
+ This commit removes the last alloca call from printcmd.c. This is
+ similar to the patches I originally posted here:
+
+ https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/
+
+ However, this change was not included in that original series.
+
+ The original series received push back because it was thought that
+ replacing alloca with a C++ container type would introduce unnecessary
+ malloc/free overhead.
+
+ However, in this case we are building a string, and (at least for
+ GCC), the std::string type has a small string optimisation, where
+ small strings are stored on the stack.
+
+ And in this case we are building what will usually be a very small
+ string, we're just constructing a printf format specifier for a hex
+ value, so it'll be something like '%#x' -- though it could also have a
+ width in there too -- but still, it should normally fit within GCCs
+ small string buffer.
+
+ So, in this commit, I propose replacing the use of alloca with a
+ std::string. This shouldn't result (normally) in any additional
+ malloc or free calls, so should be similar in performance to the
+ original approach.
+
+ There should be no user visible differences after this commit.
+
+2023-07-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove two uses of alloca from printcmd.c
+ Remove a couple of uses of alloca from printcmd.c, and replace them
+ with gdb::byte_vector.
+
+ An earlier variant of this patch was proposed in this thread:
+
+ https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/
+
+ however, there was push back on that thread due to it adding extra
+ dynamic allocation, i.e. moving the memory buffers off the stack on to
+ the heap.
+
+ However, of all the patches originally proposed, I think in these two
+ cases moving off the stack is the correct thing to do. Unlike all the
+ other patches in the original series, where the data being read
+ was (mostly) small in size, a register, or a couple of registers, in
+ this case we are reading an arbitrary string from the inferior. This
+ could be any size, and so should not be placed on the stack.
+
+ So in this commit I replace the use of alloca with std::byte_vector
+ and simplify the logic a little (I think) to take advantage of the
+ ability of std::byte_vector to dynamically grow in size.
+
+ Of course, really, we should probably be checking the max-value-size
+ setting as we load the string to stop GDB crashing if a corrupted
+ inferior causes GDB to try read a stupidly large amount of
+ memory... but I'm leaving that for a follow on patch.
+
+ There should be no user visible changes after this commit.
+
+2023-07-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix printf of wchar_t early in a gdb session
+ Given this test program:
+
+ #include <wchar.h>
+
+ const wchar_t wide_str[] = L"wide string";
+
+ int
+ main (void)
+ {
+ return 0;
+ }
+
+ I observed this GDB behaviour:
+
+ $ gdb -q /tmp/printf-wchar_t
+ Reading symbols from /tmp/printf-wchar_t...
+ (gdb) start
+ Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
+ Starting program: /tmp/printf-wchar_t
+
+ Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
+ 25 return 0;
+ (gdb) printf "%ls\n", wide_str
+
+ (gdb)
+
+ Notice that the printf results in a blank line rather than the
+ expected 'wide string' output.
+
+ I tracked the problem down to printf_wide_c_string (in printcmd.c), in
+ this function we do this:
+
+ struct type *wctype = lookup_typename (current_language,
+ "wchar_t", NULL, 0);
+ int wcwidth = wctype->length ();
+
+ the problem here is that 'wchar_t' is a typedef. If we look at the
+ comment on type::length() we see this:
+
+ /* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
+ But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
+ so you only have to call check_typedef once. Since value::allocate
+ calls check_typedef, X->type ()->length () is safe. */
+
+ What this means is that after calling lookup_typename we should call
+ check_typedef in order to ensure that the length of the typedef has
+ been setup correctly. We are not doing this in printf_wide_c_string,
+ and so wcwidth is incorrectly calculated as 0. This is what leads GDB
+ to print an empty string.
+
+ We can see in c_string_operation::evaluate (in c-lang.c) an example of
+ calling check_typedef specifically to fix this exact issue.
+
+ Initially I did fix this problem by adding a check_typedef call into
+ printf_wide_c_string, but then I figured why not move the
+ check_typedef call up into lookup_typename itself, that feels like it
+ should be harmless when looking up a non-typedef type, but will avoid
+ bugs like this when looking up a typedef. So that's what I did.
+
+ I can then remove the extra check_typedef call from c-lang.c, I don't
+ see any other places where we had extra check_typedef calls. This
+ doesn't mean we definitely had bugs -- so long as we never checked the
+ length, or, if we knew that check_typedef had already been called,
+ then we would be fine.
+
+ I don't see any test regressions after this change, and my new test
+ case is now passing.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-07-07 Jan Beulich <jbeulich@suse.com>
+
+ ld: fix build with old glibc / gcc
+ "rename" conflicts with a function of that name, which gcc from that
+ same timeframe then complains about. Use a name matching that of
+ struct input_remap's respective field.
+
+2023-07-07 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update/Add ARCv3 support.
+ The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA
+ that implements a full range of 32-bit and 64-bit instructions. These
+ processors feature a high-speed 10-stage, dual-issue pipeline that
+ offers increased utilization of functional units with a limited
+ increase in power and area. The HS5x processors feature a 32-bit
+ pipeline that can execute all ARCv3 32-bit instructions, while the
+ HS6x processors feature a full 64-bit pipeline and register file that
+ can execute both 32-bit and 64-bit instructions. In addition, the ARC
+ HS6x supports 64-bit virtual and 52-bit physical address spaces to
+ enable direct addressing of current and future large memories, as well
+ as 128-bit loads and stores for efficient data movement.
+
+ This readelf patch updates/adds Synopsys ARCv3 machine name fileds and
+ supported relocations.
+
+2023-07-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix license on recently added file
+ The license header on a file I recently contributed was incorrect.
+ The file was added in commit:
+
+ commit 087969169836f802a09b1cd0502d2f22d7a8f7dc
+ Date: Tue May 23 11:25:21 2023 +0100
+
+ gdb: handle core files with .reg/0 section names
+
+ The problems were:
+
+ - GPLv2 instead of GPLv3,
+ - Use the FSF postal address rather than their URL.
+
+ Nobody else has touched the file since I merged it, so I don't believe
+ there are any problems with me changing the license, this commit does
+ just that.
+
+2023-07-07 Nick Clifton <nickc@redhat.com>
+
+ Udated Freach and Romainian translations for various sub-directories
+
+ Minor updates to release readme
+
+2023-07-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-06 Pedro Alves <pedro@palves.net>
+
+ Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525)
+ Since commit 05c06f318fd9 ("Linux: Access memory even if threads are
+ running"), GDB prefers pread64/pwrite64 to access inferior memory
+ instead of ptrace. That change broke reading shared libraries on
+ SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared
+ libraries on SPARC64").
+
+ On SPARC64 Linux, surprisingly (to me), userspace shared libraries are
+ mapped at high 64-bit addresses:
+
+ (gdb) info sharedlibrary
+ Cannot access memory at address 0xfff80001002011e0
+ Cannot access memory at address 0xfff80001002011d8
+ Cannot access memory at address 0xfff80001002011d8
+ From To Syms Read Shared Object Library
+ 0xfff80001000010a0 0xfff8000100021f80 Yes (*) /lib64/ld-linux.so.2
+ (*): Shared library is missing debugging information.
+
+ Those addresses are 64-bit addresses with the high bits set. When
+ interpreted as signed, they're negative.
+
+ The Linux kernel rejects pread64/pwrite64 if the offset argument of
+ type off_t (a signed type) is negative, which happens if the memory
+ address we're accessing has its high bit set. See
+ linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux.
+
+ Thankfully, lseek does not fail in that situation. So the fix is to
+ use the 'lseek + read|write' path if the offset would be negative.
+
+ Fix this in both native GDB and GDBserver.
+
+ Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525
+ Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5
+
+2023-07-06 Branislav Brzak <branislav.brzak@syrmia.com>
+
+ riscv: Ensure LE instruction fetching
+ Currently riscv gdb code looks at arch byte order
+ when fetching instructions. This works when the
+ target is LE, but on BE arch it will byte swap the
+ instruction, while the riscv spec defines all
+ instructions are LE encoded regardless of
+ system memory endianess.
+
+2023-07-06 Pedro Alves <pedro@palves.net>
+
+ Fix Solaris regression (PR tdep/30252)
+ PR tdep/30252 reports that using GDB on Solaris fails an assertion in
+ target_resume:
+
+ target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n)
+
+ The backtrace, after running it through c++filt, looks like:
+
+ ----- Backtrace -----
+ 0xa18914 gdb_internal_backtrace_1
+ /root/binutils-gdb/gdb/bt-utils.c:122
+ 0xa18914 gdb_internal_backtrace()
+ /root/binutils-gdb/gdb/bt-utils.c:168
+ 0xdec834 internal_vproblem
+ /root/binutils-gdb/gdb/utils.c:401
+ 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*)
+ /root/binutils-gdb/gdb/utils.c:481
+ 0xf3638c internal_error_loc(char const*, int, char const*, ...)
+ /root/binutils-gdb/gdbsupport/errors.cc:58
+ 0xd70580 target_resume(ptid_t, int, gdb_signal)
+ /root/binutils-gdb/gdb/target.c:2648
+ 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
+ /root/binutils-gdb/gdb/procfs.c:2187
+ 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
+ /root/binutils-gdb/gdb/sol-thread.c:442
+ 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
+ /root/binutils-gdb/gdb/target.c:2586
+ ...
+
+ The problem is that the procfs backend, while inside target_wait,
+ called target_resume without switching to the leader thread of that
+ resumption.
+
+ The target_resume interface is:
+
+ /* Resume execution (or prepare for execution) of the current thread
+ (INFERIOR_PTID), while optionally letting other threads of the
+ current process or all processes run free.
+ ...
+
+ Thus calling target_resume with inferior_ptid == null_ptid is bogus.
+
+ target_wait (which leads to procfs_target::wait on Solaris) is called
+ with inferior_ptid == null_ptid on entry exactly to help catch such
+ bogus uses.
+
+ From the backtrace, it seems that the relevant line in question is
+ procfs.c:2187:
+
+ 2186 /* How to keep going without returning to wfi: */
+ 2187 target_continue_no_signal (ptid);
+ 2188 goto wait_again;
+
+ target_continue_no_signal is a small wrapper around target_resume,
+ which would make sense.
+
+ The fix is to not call target_resume or go via the target stack at
+ all. Instead, factor out a new proc_resume function out of
+ procfs_target::resume, and call that. The new function does not rely
+ on inferior_ptid.
+
+ I've not been able to test it myself, but Petr confirmed it fixes the
+ assertion failure with his test case, and Marcel Telka also confirmed
+ it solves the problem.
+
+ Tested-By: Petr Šumbera <petr.sumbera@oracle.com>
+ Tested-By: Marcel Telka <marcel@telka.sk>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252
+ Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3
+
+2023-07-06 YunQiang Su <yunqiang.su@cipunited.com>
+
+ ld: fix plugin tests for MIPS PIC
+ On MIPS, for PIC objects, symbols may reference 2 times:
+ once from the caller, and once from GOT.
+ Thus ld may complains 2 times about "undefined reference".
+
+ So we add a new "#?" line to every effected testsuite.
+
+2023-07-06 Alan Modra <amodra@gmail.com>
+
+ Use run_host_cmd to run $CC and other no-section-header test fixes
+ We should be using run_host_cmd everywhere we invoke a compiler in the
+ ld testsuite, if we want to use ld/ld-new just built. run_host_cmd
+ properly inserts $gcc_B_opt in cases where a user wants to test
+ binutils with a newly built compiler, ie. when $CC specifies -B itself.
+
+ Also, it is not good practice to exclude tests when non-native except
+ of course those tests that run a target binary. Compiling and linking
+ often shows up problems.
+
+ * testsuite/ld-elf/no-section-header.exp (binutils_run_test):
+ Use run_host_cmd to invoke $CC_FOR_TARGET. Run all tests
+ non-native too, except for attempting to run the binaries.
+ Run tests for ELF in general, not just linux.
+ * testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry
+ symbol decoration, and support either sorting of symbols.
+ * testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms.
+ * testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept
+ mips-sgi-irix symbol output.
+ * testsuite/ld-elf/start-shared-noheader.nd: Likewise.
+
+2023-07-06 Alan Modra <amodra@gmail.com>
+
+ Re: Stop the linker's --dependency-file option from including temporary lto files.
+ PR 30568
+ * ldfile.c (ldfile_try_open_bfd): Fix build failure when
+ !BFD_SUPPORTS_PLUGINS.
+
+2023-07-06 YunQiang Su <yunqiang.su@cipunited.com>
+
+ ld: Use run_host_cmd_yesno in indirect.exp instead of catch exec
+ Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build,
+ and in fact run_host_cmd_yesno is a better choice for it.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno
+ instead of handwrite catch exec $CC_FOR_TARGET.
+
+2023-07-06 YunQiang Su <yunqiang.su@cipunited.com>
+
+ ld: Use [list ] syntax to define run_tests in indirect.exp
+ Currently, the var run_tests is defined by syntax {{}},
+ while in this case, variables cannot be used.
+ Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names
+ instead of values:
+ gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o
+
+ Let's use [list [list ]] syntax instead.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/indirect.exp(run_tests): use [list [list]]
+ syntax instead of {{}}.
+
+2023-07-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-05 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ Align linkerscript symbols according to ABI
+ Apply ABI specific alignment to symbols generated in the default
+ linker script.
+
+2023-07-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ
+ The alternative is 1 byte shorter when the source is %xmm0-7, as a
+ 2-byte VEX prefix can then be used.
+
+ x86: optimize pre-AVX512 {,V}PCMPGT* with identical sources
+ These are better expressed by the zeroing idiom {,V}PXOR. In some cases
+ this also results in a shorter encoding.
+
+ x86: optimize pre-AVX512 {,V}PCMPEQQ with identical sources
+ The {,V}PCMPEQD alternative is 1 byte shorter in many cases.
+
+2023-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: flag bad EVEX masking for miscellaneous insns
+ Masking is not permitted for certain further insns, not falling in any
+ of the earlier categories. Introduce the Y macro (not expanding to any
+ output) to flag such cases.
+
+ Note that in a few cases entries already covered otherwise are converted
+ as well, to continue to allow sharing of the string literals.
+
+2023-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: flag EVEX masking when destination is GPR(-like)
+ Masking is not permitted in this case. See the code comment for how this
+ is being dealt with.
+
+ To avoid excess special casing of modes, have OP_M() call OP_E_memory()
+ directly.
+
+2023-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: flag EVEX.z set when destination is memory
+ Zeroing-masking is not permitted in this case. See the code comment for
+ how this is being dealt with.
+
+ x86: flag EVEX.z set when destination is a mask register
+ While only zeroing-masking is possible in this case, this still requires
+ EVEX.z to be clear. Introduce a "global" flag right here, to be re-used
+ by checks which need to live in specific operand handlers.
+
+ x86: re-work EVEX-z-without-masking check
+ Rather than corrupting disassmbly altogether, flag EVEX.z set as bad
+ when masking isn't in effect in the first place at the time the
+ destination operand is actually processed.
+
+2023-07-04 Matheus Branco Borella <dark.ryu.550@gmail.com>
+
+ gdb: add __repr__() implementation to a few Python types
+ Only a few types in the Python API currently have __repr__()
+ implementations. This patch adds a few more of them. specifically: it
+ adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
+ gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.
+
+ This makes it easier to play around the GDB Python API in the Python
+ interpreter session invoked with the 'pi' command in GDB, giving more
+ easily accessible tipe information to users.
+
+ An example of how this would look like:
+
+ (gdb) pi
+ >> gdb.lookup_type("char")
+ <gdb.Type code=TYPE_CODE_INT name=char>
+ >> gdb.lookup_global_symbol("main")
+ <gdb.Symbol print_name=main>
+
+ The gdb.Block.__repr__() method shows the first 5 symbols from the
+ block, and then a message to show how many more were elided (if any).
+
+2023-07-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have mdict_size always return a symbol count
+ In the next commit we would like to have mdict_size return the number
+ of symbols in the dictionary, currently mdict_size is just a
+ heuristic, sometimes it returns the number of symbols, and sometimes
+ the number of buckets in a hashing dictionary (see size_hashed in
+ dictionary.c).
+
+ Currently this vague notion of size is good enough, the only place
+ mdict_size is used is in a maintenance command in order to print a
+ message containing the size of the dictionary ... so we don't really
+ care that the value isn't correct.
+
+ However, in the next commit we do want the size returned to be the
+ number of symbols in the dictionary, so this commit makes mdict_size
+ return the symbol count in all cases.
+
+ The new use is still not on a hot path -- it's going to be a Python
+ __repr__ method, so all I do in this commit is have size_hashed walk
+ the dictionary and count the entries, obviously this could be slow if
+ we have a large number of symbols, but for now I'm not worrying about
+ that case. We could always store the symbol count if we wanted, but
+ that would increase the size of every dictionary for a use case that
+ isn't going to be hit that often.
+
+ I've updated the text in 'maint print symbols' so that we don't talk
+ about the size being 'syms/buckets', but just 'symbols' now.
+
+2023-07-04 Nick Clifton <nickc@redhat.com>
+
+ Updated Ukranian, Romanian and German translations for various sub-directories
+
+2023-07-04 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Update default target CPU to match GCC defaults
+
+ arc: Update neg<.f> 0,b encoding
+ Wrong encoding for null destination NEG instruction. Fix it.
+
+2023-07-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-03 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM Z: Fix pcrel relocs for symA-symB expressions
+ The code in md_apply_fix which tries to deduce from the operand type
+ which reloc to apply currently does the wrong thing for absolute
+ relocs which have been re-written by fixup_segment as pc-relative to
+ implement a subtraction of a local and an external symbol.
+
+ In all these cases we wrongly emit an absolute reloc because we ignore
+ the fx_pcrel flag in md_apply_fix. However, only for the last one we
+ actually support a pc relative relocation of the proper size and can
+ implement it accordingly. For the other 3 we have to issue an error.
+
+ foo:
+ cli 0(%r2),undef-foo
+ la %r2,undef-foo(%r2)
+ lay %r2,undef-foo(%r2)
+ lhi %r2,undef-foo
+
+2023-07-03 Tom Tromey <tromey@adacore.com>
+
+ Fix two Python calls that don't check for errors
+ PyModule_AddObject steals a reference on success, but not on error,
+ which is why we have gdb_pymodule_addobject. I found one spot still
+ calling the former, which could in theory leak memory on failure.
+ This patch fixes this.
+
+ In the same function I found an unchecked call to
+ PyDict_SetItemString. This patch fixes this as well.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-07-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle core files with .reg/0 section names
+ The previous commit added the test gdb.arch/core-file-pid0.exp which
+ tests GDB's ability to load a core file containing threads with an
+ lwpid of 0, which is something we GDB can encounter when loading a
+ vmcore file -- a core file generated by the Linux kernel. The threads
+ with an lwpid of 0 represents idle cores.
+
+ While the previous commit added the test, which confirms GDB doesn't
+ crash when confronted with such a core file, there are still some
+ problems with GDB's handling of these core files. These problems all
+ originate from the fact that the core file (once opened by bfd)
+ contains multiple sections called .reg/0, these sections all
+ represents different threads (cpu cores in the original vmcore dump),
+ but GDB gets confused and thinks all of these .reg/0 sections are all
+ referencing the same thread.
+
+ Here is a GDB session on an x86-64 machine which loads the core file
+ from the gdb.arch/core-file-pid0.exp, this core file contains two
+ threads, both of which have a pid of 0:
+
+ $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
+ (gdb) core-file /tmp/x86_64-pid0-core.core
+ [New process 1]
+ [New process 1]
+ Failed to read a valid object file image from memory.
+ Core was generated by `./segv-mt'.
+ Program terminated with signal SIGSEGV, Segmentation fault.
+ The current thread has terminated
+ (gdb) info threads
+ Id Target Id Frame
+ 2 process 1 0x00000000004017c2 in ?? ()
+
+ The current thread <Thread ID 1> has terminated. See `help thread'.
+ (gdb) maintenance info sections
+ Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
+ [0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
+ [1] 0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
+ [2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
+ [3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
+ [4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
+ [5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
+ [6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
+ [7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
+ [8] 0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
+ [9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
+ [10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
+ [11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
+ [12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
+ [13] 0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
+ [14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
+ [15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
+ [16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
+ [17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
+ [18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
+ [19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
+ [20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
+ [21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
+ [22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
+ [23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
+ [24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
+ [25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
+ [26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
+ (gdb)
+
+ Notice when the core file is first loaded we see two lines like:
+
+ [New process 1]
+
+ And GDB reports:
+
+ The current thread has terminated
+
+ Which isn't what we'd expect from a core file -- the core file should
+ only contain threads that are live at the point of the crash, one of
+ which should be the current thread. The above message is reported
+ because GDB has deleted what we think is the current thread!
+
+ And in the 'info threads' output we are only seeing a single thread,
+ again, this is because GDB has deleted one of the threads.
+
+ Finally, the 'maintenance info sections' output shows the cause of all
+ our problems, two sections named .reg/0. When GDB sees the first of
+ these it creates a new thread. But, when we see the second .reg/0 GDB
+ tries to create another new thread, but this thread has the same
+ ptid_t as the first thread, so GDB deletes the first thread and
+ creates the second thread in its place.
+
+ Because both these threads are created with an lwpid of 0 GDB reports
+ these are 'New process NN' rather than 'New LWP NN' which is what we
+ would normally expect.
+
+ The previous commit includes a little more of the history of GDB
+ support in this area, but these problems were discussed on the mailing
+ list a while ago in this thread:
+
+ https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
+
+ In this commit I propose a solution to these problems.
+
+ What I propose is that GDB should spot when we have .reg/0 sections
+ and, when these are found, should rename these sections using some
+ unique non-zero lwpid.
+
+ Note in the above output we also have sections like .reg2/0 and
+ .reg-xstate/0, these are additional register sets, this commit also
+ renumbers these sections inline with their .reg section.
+
+ The user is warned that some section renumbering has been performed.
+
+ GDB takes care to ensure that the new numbers assigned are unique and
+ don't clash with any of the pid's that might already be in use --
+ remember, in a real vmcore file, 0 is used to indicate an idle core,
+ non-idle cores will have the pid of whichever process was running on
+ that core, so we don't want GDB to assign an lwpid that clashes with
+ an actual pid that is in use in the core file.
+
+ After this commit here's the updated GDB session output:
+
+ $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
+ (gdb) core-file /tmp/x86_64-pid0-core.core
+ warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
+ [New LWP 1]
+ [New LWP 2]
+ Failed to read a valid object file image from memory.
+ Core was generated by `./segv-mt'.
+ Program terminated with signal SIGSEGV, Segmentation fault.
+ #0 0x00000000004017c2 in ?? ()
+ [Current thread is 1 (LWP 1)]
+ (gdb) info threads
+ Id Target Id Frame
+ * 1 LWP 1 0x00000000004017c2 in ?? ()
+ 2 LWP 2 0x000000000040dda5 in ?? ()
+ (gdb) maintenance info sections
+ Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
+ [0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
+ [1] 0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
+ [2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
+ [3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
+ [4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
+ [5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
+ [6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
+ [7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
+ [8] 0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
+ [9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
+ [10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
+ [11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
+ [12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
+ [13] 0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
+ [14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
+ [15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
+ [16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
+ [17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
+ [18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
+ [19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
+ [20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
+ [21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
+ [22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
+ [23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
+ [24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
+ [25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
+ [26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
+ (gdb)
+
+ Notice the new warning which is issued when the core file is being
+ loaded. The threads are announced as '[New LWP NN]', and we see two
+ threads in the 'info threads' output. The 'maintenance info sections'
+ output shows the result of the section renaming.
+
+ The gdb.arch/core-file-pid0.exp test has been update to check for the
+ improved GDB output.
+
+ Reviewed-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-07-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add test for core file with a 0 pid
+ This patch contains a test for this commit:
+
+ commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
+ Date: Fri Aug 6 19:45:58 2010 +0000
+
+ * thread.c (add_thread_silent): Use null_ptid instead of
+ minus_one_ptid while getting rid of stale inferior_ptid.
+
+ This is another test that has been carried in the Fedora GDB tree for
+ some time, and I thought that it would be worth merging to master. I
+ don't believe there is any test like this currently in the testsuite.
+
+ The original issue was reported in this thread:
+
+ https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
+
+ The problem was that when GDB was used to open a vmcore (core file)
+ image generated by the Linux kernel GDB would (sometimes) crash with
+ an assertion failure:
+
+ thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
+
+ To understand what's going on we need some background; a vmcore file
+ represents each processor core in the same way that a standard
+ application core file represents threads. Thus, we might say, a
+ vmcore file represents cores as threads.
+
+ When writing a vmcore file, the kernel will store the pid of the
+ process currently running on that core as the thread's lwpid.
+
+ However, if a core is idle, with no process currently running on it,
+ then the lwpid for that thread is stored as 0 in the vmcore file. If
+ multiple cores are idle then multiple threads will have a lwpid of 0.
+
+ Back in 2010, the original issue reported tried to change the kernel's
+ behaviour in this thread:
+
+ https://lkml.org/lkml/2010/8/3/75
+
+ This change was rejected by the kernel team, the current
+ behaviour (lwpid of 0) was considered correct. I've checked the
+ source of a recent kernel. The code mentioned in the lkml.org posting
+ has moved, it's now in the function crash_save_cpu in the file
+ kernel/kexec_core.c, but the general behaviour is unchanged, an idle
+ core will have an lwpid of 0, so I think GDB still needs to be able to
+ handle this case.
+
+ When GDB loads a vmcore file (which is handled just like any other
+ core file) the sections are processed in core_open to generate the
+ threads for the core file. The processing is done by calling
+ add_to_thread_list, a function which looks for sections named .reg/NN
+ where NN is the lwpid of the thread, GDB then builds a ptid_t for the
+ new thread and calls add_thread.
+
+ Remember, in our case the lwpid is 0. Now for the first thread this
+ is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
+ OK, GDB creates a thread with lwpid of 0 and carries on.
+
+ When we find the next thread (core) with lwpid of 0, we attempt to
+ create another thread with an lwpid of 0. This of course clashes with
+ the previously created thread, they have the same ptid_t, so GDB tries
+ to delete the first thread.
+
+ And it was within this thread delete code that we triggered a bug
+ which would then cause GDB to assert -- when deleting we tried to
+ switch to a thread with minus_one_ptid, this resulted in a call to
+ find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
+ find_inferior_pid call fails and returns NULL, which then triggered an
+ assert in switch_to_thread.
+
+ The actual details of the why the assert triggered are really not
+ important. What's important (I think) is that a vmcore file might
+ have this interesting lwpid of 0 characteristic, which isn't something
+ we see in "normal" application core files, and it is this that I think
+ we should be testing.
+
+ Now, you might be thinking: isn't deleting the first thread the wrong
+ thing to do? If the vmcore file has two threads that represent two
+ cores, and both have an lwpid of 0 (indicating both cores are idle),
+ then surely GDB should still represent this as two threads? You're
+ not wrong. This was mentioned by Pedro in the original GDB mailing
+ list thread here:
+
+ https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/
+
+ This is indeed a problem, and this problem is still present in GDB
+ today. I plan to try and address this in a later commit, however,
+ this first commit is about getting a test in place to confirm that GDB
+ at a minimum doesn't crash when loading such a vmcore file.
+
+ And so, finally, what's in this commit?
+
+ This commit contains a new test. The test doesn't actually contain a
+ vmcore file. Instead I've created a standard application core file
+ that contains two threads, and then manually edited the core file to
+ set the lwpid of each thread to 0.
+
+ To further reduce the size of the core file (as it will be stored in
+ git), I've zeroed all of the LOAD-able segments in the core file.
+ This test really doesn't care about that part of the core file, we
+ only really care about loading the register's, this is enough to
+ confirm that the GDB doesn't crash.
+
+ Obviously as the core file is pre-generated, this test is architecture
+ specific. There are already a few tests in gdb.arch/ that include
+ pre-generate core files. Just as those existing tests do, I've
+ compressed the core file with bzip2, which reduces it to just 750
+ bytes. I have structured the test so that if/when this patch is
+ merged I can add some additional core files for other architectures,
+ however, these are not included in this commit.
+
+ The test simply expands the core file, and then loads it into GDB.
+ One interesting thing to note is that GDB reports the core file
+ loading like this:
+
+ (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
+ [New process 1]
+ [New process 1]
+ Failed to read a valid object file image from memory.
+ Core was generated by `./segv-mt'.
+ Program terminated with signal SIGSEGV, Segmentation fault.
+ The current thread has terminated
+ (gdb)
+
+ There's two interesting things here: first, the repeated "New process
+ 1" message. This is caused because linux_core_pid_to_str reports
+ anything with an lwpid of 0 as a process, rather than an LWP. And
+ second, the "The current thread has terminated" message. This is
+ because the first thread in the core file is the current thread, but
+ when GDB loads the second thread (which also has lwpid 0) this causes
+ the first thread to be deleted, as a result GDB thinks that the
+ current (first) thread has terminated.
+
+ As I said previously, both of these problems are a result of the lwpid
+ 0 aliasing, which is not being fixed in this commit -- this commit is
+ just confirming that GDB doesn't crash when loading this core file.
+
+ Reviewed-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-07-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: split inferior and thread setup when opening a core file
+ I noticed that in corelow.c, when a core file is opened, both the
+ thread and inferior setup is done in add_to_thread_list. In this
+ patch I propose hoisting the inferior setup out of add_to_thread_list
+ into core_target_open.
+
+ The only thing about this change that gave me cause for concern is
+ that in add_to_thread_list, we only setup the inferior after finding
+ the first section with a name like ".reg/NN". If we find no such
+ section then the inferior will never be setup.
+
+ Is this important?
+
+ Well, I don't think so. Back in core_target_open, if there is no
+ current thread (which there will not be if no ".reg/NN" section was
+ found), then we look for a thread in the current inferior. If there
+ are no threads (which there will not be if no ".reg/NN" is found),
+ then we once again setup the current inferior.
+
+ What I think this means, is that, in all cases, the current inferior
+ will end up being setup. By moving the inferior setup code earlier in
+ core_target_open and making it non-conditional, we can remove the
+ later code that sets up the inferior, we now know this will always
+ have been done.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-07-03 Nick Clifton <nickc@redhat.com>
+
+ Update after creating 2.41 branch
+
+ Change version number to 2.41.50 and regenerate files
+
+2023-07-03 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Zvkh[a,b]: Remove individual instruction class
+ Currently we have three instruction classes defined for Zvkh[a,b]:
+ - INSN_CLASS_ZVKNHA
+ - INSN_CLASS_ZVKNHB
+ - INSN_CLASS_ZVKNHA_OR_ZVKNHB
+
+ The encodings of all instructions in Zvknh[a,b] are identical.
+ Therefore, we don't need the individual instruction classes
+ and can remove them.
+
+ This patch also adds the missing support of the combined instruction
+ class in riscv_multi_subset_supports_ext().
+
+ Fixes: 62edb233ef5 ("RISC-V: Add support for the Zvknh[a,b] ISA extensions")
+ Reported-By: Nelson Chu <nelson@rivosinc.com>
+
+2023-07-03 Nick Clifton <nickc@redhat.com>
+
+ Add markers for the 2.41 branch
+
+2023-07-03 WANG Xuerui <git@xen0n.name>
+
+ gas: NEWS: Announce LoongArch changes in the 2.41 cycle
+ gas/ChangeLog:
+
+ * NEWS: Mention LoongArch changes for 2.41.
+
+2023-07-03 WANG Xuerui <git@xen0n.name>
+
+ binutils: NEWS: Announce LoongArch changes in the 2.41 cycle
+ binutils/ChangeLog:
+
+ * NEWS: Mention LoongArch changes for 2.41.
+
+2023-07-03 WANG Xuerui <git@xen0n.name>
+
+ LoongArch: gas: Fix shared builds
+ Formerly an include of libbfd.h was added in commit 56576f4a722
+ ("LoongArch: gas: Add support for linker relaxation."), in order to
+ allow calling _bfd_read_unsigned_leb128 from gas, but doing so broke
+ shared builds. Commit d2fddb6d783 fixed this reference but did not
+ remove the now unnecessary inclusion of libbfd.h. The gas_assert macro
+ expands into a conditional call to abort(), but "abort" is re-defined to
+ _bfd_abort in libbfd.h, so the extra include breaks any gas_assert
+ usage, and should be removed.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c: Don't include libbfd.h.
+
+ Fixes: d2fddb6d783 ("LoongArch: Fix ld "undefined reference" error with --enable-shared")
+
+2023-07-03 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: Mark address offset operands of LVZ/LBT insns as such
+ opcodes/ChangeLog:
+
+ * loongarch-opc.c: Mark the offset operands as "so" for
+ {,x}v{ld,st}, {,x}v{ldrepl,stelm}.[bhwd], and {ld,st}[lr].[wd].
+
+2023-07-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-07-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix data race
+ In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
+ the output of gprofng to display the data. Sometimes this data is corrupted.
+
+ gprofng/ChangeLog
+ 2023-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/ipc.cc (ipc_doWork): Fix data race.
+ * src/ipcio.cc (IPCresponse::print): Fix data race.
+ Remove unused variables and functions.
+ * src/ipcio.h: Declare two variables.
+ * src/StringBuilder.cc (StringBuilder::write): New function.
+ * src/StringBuilder.h: Likewise.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ binutils: NEWS: Announce new RISC-V vector crypto extensions
+ This commit adds the recently added support of the RISC-V vector crypto
+ extensions to the NEWS file.
+
+ binutils/ChangeLog:
+
+ * NEWS: Announce new RISC-V vector crypto extensions.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Add support for the Zvksc ISA extension
+ Zvksc is part of the vector crypto extensions.
+
+ Zvksc is shorthand for the following set of extensions:
+ - Zvks
+ - Zvbc
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvksc extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvksc.d: New test.
+ * testsuite/gas/riscv/zvksc.s: New test.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Add support for the Zvknc ISA extension
+ Zvknc is part of the vector crypto extensions.
+
+ Zvknc is shorthand for the following set of extensxions:
+ - Zvkn
+ - Zvbc
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvknc extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvknc.d: New test.
+ * testsuite/gas/riscv/zvknc.s: New test.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Add support for the Zvksg ISA extension
+ Zvksg is part of the vector crypto extensions.
+
+ Zvksg is shorthand for the following set of extensions:
+ - Zvks
+ - Zvkg
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvksg extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvksg.d: New test.
+ * testsuite/gas/riscv/zvksg.s: New test.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvks ISA extension
+ Zvks is part of the vector crypto extensions.
+
+ Zvks is shorthand for the following set of extensions:
+ - Zvksed
+ - Zvksh
+ - Zvbb
+ - Zvkt
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvks extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvks.d: New test.
+ * testsuite/gas/riscv/zvks.s: New test.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Add support for the Zvkng ISA extension
+ Zvkng is part of the vector crypto extensions.
+
+ Zvkng is shorthand for the following set of extensions:
+ - Zvkn
+ - Zvkg
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvkng extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvkng.d: New test.
+ * testsuite/gas/riscv/zvkng.s: New test.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Allow nested implications for extensions
+ Certain extensions require two levels of implications. For example,
+ zvkng implies zvkn and zvkn implies zvkned. Enabling zvkng should also
+ enable zvkned.
+
+ This patch fixes this behavior.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_add_implicit_subsets): Allow nested
+ implications for extensions.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvkn ISA extension
+ Zvkn is part of the vector crypto extensions.
+
+ Zvkn is shorthand for the following set of extensions:
+ - Zvkned
+ - Zvknhb
+ - Zvbb
+ - Zvkt
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Define Zvkn extension.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvkn.d: New test.
+ * testsuite/gas/riscv/zvkn.s: New test.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvksh ISA extension
+ Zvksh is part of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vsm3me.vv
+ - vsm3c.vi
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvksh.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvksh.d: New test.
+ * testsuite/gas/riscv/zvksh.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VSM3C_VI): New.
+ (MASK_VSM3C_VI): New.
+ (MATCH_VSM3ME_VV): New.
+ (MASK_VSM3ME_VV): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvksh.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvksh instructions.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvksed ISA extension
+ Zvksed is part of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vsm4k.vi
+ - vsm4r.[vv,vs]
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvksed.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvksed.d: New test.
+ * testsuite/gas/riscv/zvksed.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VSM4K_VI): New.
+ (MASK_VSM4K_VI): New.
+ (MATCH_VSM4R_VS): New.
+ (MASK_VSM4R_VS): New.
+ (MATCH_VSM4R_VV): New.
+ (MASK_VSM4R_VV): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvksed.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvksed instructions.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvknh[a,b] ISA extensions
+ Zvknh[a,b] are parts of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vsha2ms.vv
+ - vsha2c[hl].vv
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvknh[a,b].
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvknha.d: New test.
+ * testsuite/gas/riscv/zvknha_zvknhb.s: New test.
+ * testsuite/gas/riscv/zvknhb.d: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VSHA2CH_VV): New.
+ (MASK_VSHA2CH_VV): New.
+ (MATCH_VSHA2CL_VV): New.
+ (MASK_VSHA2CL_VV): New.
+ (MATCH_VSHA2MS_VV): New.
+ (MASK_VSHA2MS_VV): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvknh[a,b].
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvknh[a,b] instructions.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvkned ISA extension
+ Zvkned is part of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vaesef.[vv,vs]
+ - vaesem.[vv,vs]
+ - vaesdf.[vv,vs]
+ - vaesdm.[vv,vs]
+ - vaeskf1.vi
+ - vaeskf2.vi
+ - vaesz.vs
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvkned.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvkned.d: New test.
+ * testsuite/gas/riscv/zvkned.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VAESDF_VS): New.
+ (MASK_VAESDF_VS): New.
+ (MATCH_VAESDF_VV): New.
+ (MASK_VAESDF_VV): New.
+ (MATCH_VAESDM_VS): New.
+ (MASK_VAESDM_VS): New.
+ (MATCH_VAESDM_VV): New.
+ (MASK_VAESDM_VV): New.
+ (MATCH_VAESEF_VS): New.
+ (MASK_VAESEF_VS): New.
+ (MATCH_VAESEF_VV): New.
+ (MASK_VAESEF_VV): New.
+ (MATCH_VAESEM_VS): New.
+ (MASK_VAESEM_VS): New.
+ (MATCH_VAESEM_VV): New.
+ (MASK_VAESEM_VV): New.
+ (MATCH_VAESKF1_VI): New.
+ (MASK_VAESKF1_VI): New.
+ (MATCH_VAESKF2_VI): New.
+ (MASK_VAESKF2_VI): New.
+ (MATCH_VAESZ_VS): New.
+ (MASK_VAESZ_VS): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvkned.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvkned instructions.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvkg ISA extension
+ Zvkg is part of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vghsh.vv
+ - vgmul.vv
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvkg.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvkg.d: New test.
+ * testsuite/gas/riscv/zvkg.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VGHSH_VV): New.
+ (MASK_VGHSH_VV): New.
+ (MATCH_VGMUL_VV): New.
+ (MASK_VGMUL_VV): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvkg.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvkg instructions.
+
+2023-07-01 Nathan Huckleberry <nhuck@google.com>
+
+ RISC-V: Add support for the Zvbc extension
+ Zvbc is part of the crypto vector extensions.
+
+ This extension adds the following instructions:
+ - vclmul.[vv,vx]
+ - vclmulh.[vv,vx]
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvbc.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zvbc.d: New test.
+ * testsuite/gas/riscv/zvbc.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VCLMUL_VV): New.
+ (MASK_VCLMUL_VV): New.
+ (MATCH_VCLMUL_VX): New.
+ (MASK_VCLMUL_VX): New.
+ (MATCH_VCLMULH_VV): New.
+ (MASK_VCLMULH_VV): New.
+ (MATCH_VCLMULH_VX): New.
+ (MASK_VCLMULH_VX): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction class
+ support for Zvbc.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add Zvbc instruction.
+
+2023-07-01 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zvbb ISA extension
+ Zvbb is part of the vector crypto extensions.
+
+ This extension adds the following instructions:
+ - vandn.[vv,vx]
+ - vbrev.v
+ - vbrev8.v
+ - vrev8.v
+ - vclz.v
+ - vctz.v
+ - vcpop.v
+ - vrol.[vv,vx]
+ - vror.[vv,vx,vi]
+ - vwsll.[vv,vx,vi]
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for Zvbb.
+ (riscv_multi_subset_supports_ext): Likewise.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Add 'l' as new format
+ string directive.
+ (riscv_ip): Likewise.
+ * testsuite/gas/riscv/zvbb.d: New test.
+ * testsuite/gas/riscv/zvbb.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_VANDN_VV): New.
+ (MASK_VANDN_VV): New.
+ (MATCH_VANDN_VX): New.
+ (MASK_VANDN_VX): New.
+ (MATCH_VBREV8_V): New.
+ (MASK_VBREV8_V): New.
+ (MATCH_VBREV_V): New.
+ (MASK_VBREV_V): New.
+ (MATCH_VCLZ_V): New.
+ (MASK_VCLZ_V): New.
+ (MATCH_VCPOP_V): New.
+ (MASK_VCPOP_V): New.
+ (MATCH_VCTZ_V): New.
+ (MASK_VCTZ_V): New.
+ (MATCH_VREV8_V): New.
+ (MASK_VREV8_V): New.
+ (MATCH_VROL_VV): New.
+ (MASK_VROL_VV): New.
+ (MATCH_VROL_VX): New.
+ (MASK_VROL_VX): New.
+ (MATCH_VROR_VI): New.
+ (MASK_VROR_VI): New.
+ (MATCH_VROR_VV): New.
+ (MASK_VROR_VV): New.
+ (MATCH_VROR_VX): New.
+ (MASK_VROR_VX): New.
+ (MATCH_VWSLL_VI): New.
+ (MASK_VWSLL_VI): New.
+ (MATCH_VWSLL_VV): New.
+ (MASK_VWSLL_VV): New.
+ (MATCH_VWSLL_VX): New.
+ (MASK_VWSLL_VX): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (EXTRACT_RVV_VI_UIMM6): New.
+ (ENCODE_RVV_VI_UIMM6): New.
+ (enum riscv_insn_class): Add instruction class for Zvbb.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Add 'l' as new format string
+ directive.
+ * riscv-opc.c: Add Zvbb instructions.
+
+2023-07-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-30 Tom Tromey <tom@tromey.com>
+
+ Fix regressions caused by agent expression C++-ification
+ Simon pointed out that my agent expression C++-ification patches
+ caused a regression with the native-gdbserver target board. The bug
+ is that append_const is supposed to write in big-endian order, but I
+ switched this by mistake.
+
+2023-06-30 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ binutils: NEWS: announce new RISC-V extensions
+ We picked up support for a few new extensions over the last weeks
+ (this may need further updating prior to the next release), list them
+ in the NEWS file.
+
+ binutils/ChangeLog:
+
+ * binutils/NEWS: announce suuport for the new RISC-V
+ extensions (Zicond, Zfa, XVentanaCondOps).
+
+2023-06-30 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for the Zfa extension
+ This patch adds support for the RISC-V Zfa extension,
+ which introduces additional floating-point instructions:
+ * fli (load-immediate) with pre-defined immediates
+ * fminm/fmaxm (like fmin/fmax but with different NaN behaviour)
+ * fround/froundmx (round to integer)
+ * fcvtmod.w.d (Modular Convert-to-Integer)
+ * fmv* to access high bits of FP registers in case XLEN < FLEN
+ * fleq/fltq (quiet comparison instructions)
+
+ Zfa defines its instructions in combination with the following
+ extensions:
+ * single-precision floating-point (F)
+ * double-precision floating-point (D)
+ * quad-precision floating-point (Q)
+ * half-precision floating-point (Zfh)
+
+ This patch is based on an earlier version from Tsukasa OI:
+ https://sourceware.org/pipermail/binutils/2022-September/122939.html
+ Most significant change to that commit is the switch from the rs1-field
+ value to the actual floating-point value in the last operand of the fli*
+ instructions. Everything that strtof() can parse is accepted and
+ the '%a' printf specifier is used to output hex floating-point literals
+ in the disassembly.
+
+ The Zfa specification is frozen (and has passed public review). It is
+ available as a chapter in "The RISC-V Instruction Set Manual: Volume 1":
+ https://github.com/riscv/riscv-isa-manual/releases
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
+ class support for 'Zfa' extension.
+ (riscv_multi_subset_supports_ext): Likewise.
+ (riscv_implicit_subsets): Add 'Zfa' -> 'F' dependency.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (flt_lookup): New helper to lookup a float value
+ in an array.
+ (validate_riscv_insn): Add 'Wfv' as new format string directive.
+ (riscv_ip): Likewise.
+ * doc/c-riscv.texi: Add floating-point chapter and describe
+ limiations of the Zfa FP literal parsing.
+ * testsuite/gas/riscv/zfa-32.d: New test.
+ * testsuite/gas/riscv/zfa-32.s: New test.
+ * testsuite/gas/riscv/zfa-64.d: New test.
+ * testsuite/gas/riscv/zfa-64.s: New test.
+ * testsuite/gas/riscv/zfa-fail.d: New test.
+ * testsuite/gas/riscv/zfa-fail.l: New test.
+ * testsuite/gas/riscv/zfa-fail.s: New test.
+ * testsuite/gas/riscv/zfa.d: New test.
+ * testsuite/gas/riscv/zfa.s: New test.
+ * testsuite/gas/riscv/zfa.s: New test.
+
+ * opcode/riscv-opc.h (MATCH_FLI_H): New.
+ (MASK_FLI_H): New.
+ (MATCH_FMINM_H): New.
+ (MASK_FMINM_H): New.
+ (MATCH_FMAXM_H): New.
+ (MASK_FMAXM_H): New.
+ (MATCH_FROUND_H): New.
+ (MASK_FROUND_H): New.
+ (MATCH_FROUNDNX_H): New.
+ (MASK_FROUNDNX_H): New.
+ (MATCH_FLTQ_H): New.
+ (MASK_FLTQ_H): New.
+ (MATCH_FLEQ_H): New.
+ (MASK_FLEQ_H): New.
+ (MATCH_FLI_S): New.
+ (MASK_FLI_S): New.
+ (MATCH_FMINM_S): New.
+ (MASK_FMINM_S): New.
+ (MATCH_FMAXM_S): New.
+ (MASK_FMAXM_S): New.
+ (MATCH_FROUND_S): New.
+ (MASK_FROUND_S): New.
+ (MATCH_FROUNDNX_S): New.
+ (MASK_FROUNDNX_S): New.
+ (MATCH_FLTQ_S): New.
+ (MASK_FLTQ_S): New.
+ (MATCH_FLEQ_S): New.
+ (MASK_FLEQ_S): New.
+ (MATCH_FLI_D): New.
+ (MASK_FLI_D): New.
+ (MATCH_FMINM_D): New.
+ (MASK_FMINM_D): New.
+ (MATCH_FMAXM_D): New.
+ (MASK_FMAXM_D): New.
+ (MATCH_FROUND_D): New.
+ (MASK_FROUND_D): New.
+ (MATCH_FROUNDNX_D): New.
+ (MASK_FROUNDNX_D): New.
+ (MATCH_FLTQ_D): New.
+ (MASK_FLTQ_D): New.
+ (MATCH_FLEQ_D): New.
+ (MASK_FLEQ_D): New.
+ (MATCH_FLI_Q): New.
+ (MASK_FLI_Q): New.
+ (MATCH_FMINM_Q): New.
+ (MASK_FMINM_Q): New.
+ (MATCH_FMAXM_Q): New.
+ (MASK_FMAXM_Q): New.
+ (MATCH_FROUND_Q): New.
+ (MASK_FROUND_Q): New.
+ (MATCH_FROUNDNX_Q): New.
+ (MASK_FROUNDNX_Q): New.
+ (MATCH_FLTQ_Q): New.
+ (MASK_FLTQ_Q): New.
+ (MATCH_FLEQ_Q): New.
+ (MASK_FLEQ_Q): New.
+ (MATCH_FCVTMOD_W_D): New.
+ (MASK_FCVTMOD_W_D): New.
+ (MATCH_FMVH_X_D): New.
+ (MASK_FMVH_X_D): New.
+ (MATCH_FMVH_X_Q): New.
+ (MASK_FMVH_X_Q): New.
+ (MATCH_FMVP_D_X): New.
+ (MASK_FMVP_D_X): New.
+ (MATCH_FMVP_Q_X): New.
+ (MASK_FMVP_Q_X): New.
+ (DECLARE_INSN): New.
+ * opcode/riscv.h (enum riscv_insn_class): Add instruction
+ classes for the Zfa extension.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Add support for
+ new format string directive 'Wfv'.
+ * riscv-opc.c: Add Zfa instructions.
+
+ Co-Developed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
+ Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
+ Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-06-30 Nick Clifton <nickc@redhat.com>
+
+ strings: Improve code to detect excessively large minimum string lengths.
+ PR 30598
+ * strings.c (set_string_min): New function. (main): Use it. (print_unicode_stream): Calculate buffer size using a size_t.
+
+ Prevent an illegal memory access when running the strings program with an excessively lerge minimum string length.
+ PR 30595
+ * strings.c (main): Check for an excessively large minimum string length.
+
+ Fix used-before-initialized warnings when compiling elf.c with Clang-16.
+
+2023-06-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Fix code style issues
+ Blocks of 8 spaces be replaced with tabs.
+ Fix alignment issues.
+
+2023-06-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Add LVZ and LBT instructions support
+ gas/ChangeLog:
+ * config/tc-loongarch.c (md_parse_option): Add LARCH_opts.ase_lvz and
+ LARCH_opts.ase_lbt.
+ * testsuite/gas/loongarch/uleb128.d: Regenerated.
+ * testsuite/gas/loongarch/lvz-lbt.d: New test.
+ * testsuite/gas/loongarch/lvz-lbt.s: New test.
+
+ include/ChangeLog:
+ * opcode/loongarch.h (ase_lvz): New.
+ (ase_lbt): New.
+
+ opcodes/ChangeLog:
+ * loongarch-dis.c (set_default_loongarch_dis_options): Add
+ LARCH_opts.ase_lvz and LARCH_opts.ase_lbt.
+ * loongarch-opc.c (struct loongarch_ase): Add LVZ and LBT instructions.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ LoongArch: Deprecate $v[01], $fv[01] and $x names per spec
+ As outlined in the LoongArch ELF psABI spec [1], it is actually already
+ 2 versions after the initial LoongArch support, and the $v[01] and
+ $fv[01] names should really get sunset by now.
+
+ In addition, the "$x" name for $r21 was never included in any released
+ version of the ABI spec, and such usages are all fixed to say just $r21
+ for every project I could think of that accepted a LoongArch port.
+
+ Plus, the upcoming LSX/LASX support makes use of registers named
+ "$vrNN" and "$xrNN", so having "$vN" and "$x" alongside would almost
+ certainly create confusion for developers.
+
+ Issue warnings for such usages per the deprecation procedure detailed
+ in the spec, so we can finally remove support in the next release cycle
+ after this.
+
+ [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c: Init canonical register ABI name
+ mappings and deprecated register names.
+ (loongarch_args_parser_can_match_arg_helper): Warn in case of
+ deprecated register name usage.
+ * testsuite/gas/loongarch/deprecated_reg_aliases.d: New test.
+ * testsuite/gas/loongarch/deprecated_reg_aliases.l: Likewise.
+ * testsuite/gas/loongarch/deprecated_reg_aliases.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/loongarch.h: Rename global variables.
+
+ opcodes/ChangeLog:
+
+ * loongarch-opc.c: Rename the alternate/deprecated register name
+ mappings, and move $x to the deprecated name map.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: print unrecognized insn words with the .word directive
+ For better round-trip fidelity and readability in general.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/loongarch/uleb128.d: Update test case.
+ * testsuite/gas/loongarch/raw-insn.d: New test.
+ * testsuite/gas/loongarch/raw-insn.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * loongarch-dis.c (disassemble_one): Print ".word" if !opc.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: do not print hex notation for signed immediates
+ The additional hex notation was minimally useful when one had to
+ inspect code with heavy bit manipulation, or of unclear signedness, but
+ it clutters the output, and the style is not regular assembly language
+ syntax either.
+
+ Precisely how one approaches the original use case is not taken care of
+ in this patch (maybe we want a disassembler option forcing a certain
+ style for immediates, like for example printing every immediate in
+ decimal or hexadecimal notation), but at least let's stop the current
+ practice.
+
+ ChangeLog:
+
+ * testsuite/gas/loongarch/imm_ins.d: Update test case.
+ * testsuite/gas/loongarch/imm_ins_32.d: Likewise.
+ * testsuite/gas/loongarch/imm_op.d: Likewise.
+ * testsuite/gas/loongarch/jmp_op.d: Likewise.
+ * testsuite/gas/loongarch/load_store_op.d: Likewise.
+ * testsuite/gas/loongarch/macro_op.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_32.d: Likewise.
+ * testsuite/gas/loongarch/privilege_op.d: Likewise.
+ * testsuite/gas/loongarch/uleb128.d: Likewise.
+ * testsuite/gas/loongarch/vector.d: Likewise.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
+ * testsuite/ld-loongarch-elf/macro_op.d: Likewise.
+ * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
+
+ opcodes/ChangeLog:
+
+ * loongarch-dis.c (dis_one_arg): Remove the "(0x%x)" part from
+ disassembly output of signed immediate operands.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: style disassembled address offsets as such
+ Add a modifier char 'o' telling the disassembler to print the immediate
+ using the address offset style, and mark the memory access instructions'
+ offset operands as such.
+
+ opcodes/ChangeLog:
+
+ * loongarch-dis.c (dis_one_arg): Style disassembled address
+ offsets as such when the operand has a modifier char 'o'.
+ * loongarch-opc.c: Add 'o' to operands that represent address
+ offsets.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: implement style support in the disassembler
+ Update the LoongArch disassembler to supply style information to the
+ disassembler output. The output formatting remains unchanged.
+
+ opcodes/ChangeLog:
+
+ * disassemble.c: Mark LoongArch as created_styled_output=true.
+ * loongarch-dis.c (dis_one_arg): Use fprintf_styled_func
+ throughout with proper styles.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ opcodes/loongarch: remove unused code
+ Remove some unused declarations and code.
+
+ include/ChangeLog:
+
+ * opcode/loongarch.h: Remove unused declarations.
+
+ opcodes/ChangeLog:
+
+ * loongarch-dis.c (loongarch_parse_dis_options): Remove.
+ (my_print_address_func): Likewise.
+ (loongarch_disassemble_one): Likewise.
+
+2023-06-30 WANG Xuerui <git@xen0n.name>
+
+ LoongArch: support disassembling certain pseudo-instructions
+ Add a flag in the pinfo field for being able to mark certain specialized
+ matchers as disassembler-only, so some degree of isolation between
+ assembler-side and disassembler-side can be achieved.
+
+ This isolation is necessary, firstly because some pseudo-instructions
+ cannot be fully described in the opcode table, like `li.[wd]`, so the
+ corresponding opcode entry cannot have meaningful match/mask values.
+ Secondly, some of these pseudo-instructions can be realized in more than
+ one plausible ways; e.g. `li.w rd, <something between 0 and 0x7ff>` can
+ be realized on LA64 with any of `addi.w`, `addi.d` or `ori`. If we tie
+ disassembly of such aliases with the corresponding GAS support, only one
+ canonical form among the above would be recognized as `li.w`, and it
+ would mildly impact the readability of disassembly output.
+ People wanting the exact disassembly can always set `-M no-aliases` to
+ get the original behavior back.
+
+ In addition, in certain cases, information is irreversibly lost after
+ assembling, so perfect round-trip would not be possible in such cases.
+ For example, `li.w` and `li.d` of immediates within int32_t range
+ produce the same code; in this patch, `addi.d rd, $zero, imm` is treated
+ as `li.d`, while `addi.w` and `ori` immediate loads are shown as `li.w`,
+ due to the expressible value range well within 32 bits.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c (get_loongarch_opcode): Ignore
+ disassembler-only aliases.
+ * testsuite/gas/loongarch/64_pcrel.d: Update test case.
+ * testsuite/gas/loongarch/imm_ins.d: Likewise.
+ * testsuite/gas/loongarch/imm_ins_32.d: Likewise.
+ * testsuite/gas/loongarch/jmp_op.d: Likewise.
+ * testsuite/gas/loongarch/li.d: Likewise.
+ * testsuite/gas/loongarch/macro_op.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_32.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_large_abs.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_large_pc.d: Likewise.
+ * testsuite/gas/loongarch/nop.d: Likewise.
+ * testsuite/gas/loongarch/relax_align.d: Likewise.
+ * testsuite/gas/loongarch/reloc.d: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/loongarch.h (INSN_DIS_ALIAS): Add.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
+ * testsuite/ld-loongarch-elf/macro_op.d: Likewise.
+ * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
+ * testsuite/ld-loongarch-elf/relax-align.dd: Likewise.
+
+ opcodes/ChangeLog:
+
+ * loongarch-dis.c: Move register name map declarations to top.
+ (get_loongarch_opcode_by_binfmt): Consider aliases when
+ disassembling without the no-aliases option.
+ (parse_loongarch_dis_option): Support the no-aliases option.
+ * loongarch-opc.c: Collect pseudo instructions into a new
+ dedicated table.
+
+2023-06-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-30 Indu Bhagat <indu.bhagat@oracle.com>
+
+ binutils/NEWS: announce SFrame version 2 as the new default
+
+2023-06-30 Indu Bhagat <indu.bhagat@oracle.com>
+
+ doc: sframe: update specification for SFRAME_VERSION_2
+ Add details for the changes made from Version 1 to Version 2 of the format.
+
+ Also add details about alignment in the SFrame format. A portion of the
+ SFrame stack trace format has an unaligned on-disk representation. Add
+ description at relevant points in the specificatin to clarify the
+ alignment related details.
+
+2023-06-30 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: bfd: gas: ld: format bump to SFrame version 2
+ SFrame version 2 encodes the size of repetitive insn block explicitly
+ in the format. Add information in the SFrame FDE to convey the size
+ of the block of repeating instructions. This information is used only
+ for SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.
+
+ Introduce two extra bytes for padding: this ensures that the memory
+ accesses to the members of the SFrame Frame Descriptor Entry (FDE) are
+ naturally aligned.
+
+ gas generates SFrame section with version SFRAME_VERSION_2 by default.
+
+ libsframe provides two new APIs to:
+ - get an SFrame FDE data from the decoder context, and
+ - add an SFrame FDE to the encoder context.
+ The additional argument (for rep_block_size) is useful for SFrame FDEs
+ where FDE type is SFRAME_FDE_TYPE_PCMASK.
+
+ The linker will generate the output SFrame sections in the
+ SFRAME_VERSION_2 format. If the input sections offered to the linker
+ are not all in the SFRAME_VERSION_2 format, the linker issues an error
+ to the user.
+
+ objdump/readelf will show the following message to the user if .sframe
+ section in SFRAME_VERSION_1 format is seen:
+
+ "No further information can be displayed. SFrame version not
+ supported."
+
+ In other words, like the rest of the binutils, only the current SFrame
+ format version, i.e., SFRAME_VERSION_2 is supported by the textual dump
+ facilities.
+
+ bfd/
+ * elf-sframe.c (_bfd_elf_merge_section_sframe): Generate an
+ output SFrame section with version SFRAME_VERSION_2. Also,
+ error out if the SFrame sections do not all have
+ SFRAME_VERSION_2.
+ * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Generate SFrame
+ section for plt entries with version SFRAME_VERSION_2.
+ gas/
+ * gen-sframe.c (sframe_set_version): Update to SFRAME_VERSION_2.
+ (output_sframe): Likewise.
+ gas/testsuite/
+ * gas/cfi-sframe/cfi-sframe-aarch64-1.d: Use SFRAME_VERSION_2.
+ * gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise.
+ * gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Likewise.
+ * gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
+ * 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: Likewise.
+ * gas/cfi-sframe/common-empty-1.d: Likewise.
+ * gas/cfi-sframe/common-empty-2.d: Likewise.
+ * gas/cfi-sframe/common-empty-3.d: Likewise.
+ ld/testsuite/
+ * ld-aarch64/sframe-simple-1.d: Adjust for SFRAME_VERSION_2.
+ * ld-x86-64/sframe-plt-1.d: Likewise.
+ * ld-x86-64/sframe-simple-1.d: Likewise.
+ libsframe/
+ * libsframe.ver: Add the new APIs.
+ * sframe.c (sframe_decoder_get_funcdesc_v2): New definition.
+ (sframe_encoder_add_funcdesc_v2): Likewise.
+ (sframe_header_sanity_check_p): Include SFRAME_VERSION_2.
+ (sframe_fre_check_range_p): Get rep_block_size info from SFrame
+ FDE.
+ * sframe-dump.c (dump_sframe_header): Add support for
+ SFRAME_VERSION_2.
+ (dump_sframe): Inform user if SFrame section in SFRAME_VERSION_1
+ format is seen.
+ libsframe/testsuite/
+ * libsframe.decode/DATA-BE: Regenerated data file.
+ * libsframe.decode/DATA1: Likewise.
+ * libsframe.decode/DATA2: Likewise.
+ * libsframe.find/plt-findfre-1.c: Use new API in the testcase.
+ include/
+ * sframe.h: Add member to encode size of the code block of
+ repeating instructions. Add 2 bytes of padding.
+ * sframe-api.h (sframe_decoder_get_funcdesc_v2): New
+ declaration.
+ (sframe_encoder_add_funcdesc_v2): Likewise.
+
+2023-06-30 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: add new APIs to get SFrame version
+ While the SFrame preamble is guaranteed to not change between versions,
+ providing these access APIs from the SFrame decoder and encoder APIs is
+ for convenience only. The linker may want to use these APIs as the
+ format evolves.
+
+ include/
+ * sframe-api.h (sframe_decoder_get_version): New declaration.
+ (sframe_encoder_get_version): Likewise.
+
+ libsframe/
+ * libsframe/libsframe.ver: Add new APIs.
+ * libsframe/sframe.c (sframe_decoder_get_version): New
+ definition.
+ (sframe_encoder_get_version): Likewise.
+
+2023-06-29 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: fix sframe_find_fre for pltN entries
+ For a toy application on x86_64, for example, following is the SFrame
+ stack trace information for the 3 pltN entries of 16 bytes each:
+
+ func idx [1]: pc = 0x401030, size = 48 bytes
+ STARTPC[m] CFA FP RA
+ 0000000000000000 sp+8 u u
+ 000000000000000b sp+16 u u
+
+ The data in first column is the start_ip_offset. Also note that the FDE
+ is of type SFRAME_FDE_TYPE_PCMASK (denoted by the [m] on LHS).
+
+ Where each pltN (note: excluding plt0 entry) entry looks like:
+
+ 401030: jmp *0x2fca(%rip)
+ 401036: push $0x0
+ 40103b: jmp 401020<_init+0x20>
+
+ 401040: jmp *0x2fc2(%rip)
+ 401046: push $0x1
+ 40104b: jmp 401020<_init+0x20>
+
+ 401050: jmp *0x2fba(%rip)
+ 401056: push $0x2
+ 40105b: jmp 401020<_init+0x20>
+
+ Now, to find SFrame stack trace information from an FDE of type
+ SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
+ like,
+ (start_ip_offset & 0xf) >= (pc & 0xf)
+
+ This works for pltN entry of size, say, less than 16 bytes. But if the
+ pltN entries or similar code stubs (for which SFrame FDE of type
+ SFRAME_FDE_TYPE_PCMASK may be used), evolve to be of size > 16 bytes,
+ this will cease to work.
+
+ To match the range covered by the SFrame FRE, one should instead perform
+ a modulo operation. The constant for the modulo operation must be the
+ size of the pltN entry. Further, this constant should ideally be
+ encoded in the format, as it may be different for each ABI.
+
+ In SFrame Version 2 of the format, we will move towards encoding it
+ explicitly in the SFrame FDE. For now, fix up the logic to at least
+ move towards modulo operation.
+
+ libsframe/
+ * sframe.c (sframe_fre_check_range_p): New definition.
+ (sframe_find_fre): Refactor a bit and use the new definition
+ above.
+ include/
+ * sframe.h (SFRAME_FDE_TYPE_PCMASK): Update comment.
+ libsframe/doc/
+ * sframe-spec.texi: Fix the text for SFRAME_FDE_TYPE_PCMASK FDE
+ type.
+
+2023-06-29 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add -z nosectionheader test to bootstrap.exp
+ PR ld/25617
+ * testsuite/ld-bootstrap/bootstrap.exp: Add -z nosectionheader
+ test.
+
+2023-06-29 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add tests for -z nosectionheader and --strip-section-headers
+ Add tests to verify that the linker option, -z nosectionheader and
+ objcopy and strip option, --strip-section-headers, work correctly as well
+ as linker issues an error when dynamic symbol table from PT_DYNAMIC
+ segment is used.
+
+ PR ld/25617
+ * testsuite/ld-elf/hash-2.d: New file.
+ * testsuite/ld-elf/no-section-header.exp: Likewise.
+ * testsuite/ld-elf/pr25617-1-no-sec-hdr.nd: Likewise.
+ * testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1-static-no-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Likewise.
+ * testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
+ * testsuite/ld-elf/pr25617-1a.c: Likewise.
+ * testsuite/ld-elf/pr25617-1b.c: Likewise.
+ * testsuite/ld-elf/start-noheader.rd: Likewise.
+ * testsuite/ld-elf/start-shared-noheader-gnu.rd: Likewise.
+ * testsuite/ld-elf/start-shared-noheader-sysv.rd: Likewise.
+ * testsuite/ld-elf/start-shared-noheader.nd: Likewise.
+
+2023-06-29 H.J. Lu <hjl.tools@gmail.com>
+
+ binutils: Add a --strip-section-headers test
+ PR ld/25617
+ * testsuite/binutils-all/objcopy.exp: Run strip-section-headers-1.
+ * testsuite/binutils-all/strip-section-headers-1.d: New file.
+
+2023-06-29 Kaylee Blake <klkblake@gmail.com>
+
+ ld: Add simple tests for -z nosectionheader
+ 2020-06-06 Kaylee Blake <klkblake@gmail.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+
+ PR ld/25617
+ * testsuite/ld-elf/nosectionheader-1.d: New file.
+ * testsuite/ld-elf/nosectionheader-2.d: Likewise.
+
+2023-06-29 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Improve nm and objdump without section header
+ When there is no section header in an executable or shared library, we
+ reconstruct dynamic symbol table from the PT_DYNAMIC segment, which
+ contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, DT_STRTAB, DT_SYMTAB,
+ DT_STRSZ, and DT_SYMENT entries, to improve nm and objdump. For DT_HASH,
+ the number of dynamic symbol table entries equals the number of chains.
+ For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols with non-STB_LOCAL
+ indings are in hash table. Since DT_GNU_HASH/DT_MIPS_XHASH place all
+ symbols with STB_LOCAL binding before symbols with other bindings and
+ all undefined symbols defined ones in dynamic symbol table, the highest
+ symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest dynamic symbol
+ table index. We can also get symbol version from DT_VERSYM, DT_VERDEF
+ and DT_VERNEED entries.
+
+ dt_symtab, dt_versym, dt_verdef, dt_verneed, dt_symtab_count,
+ dt_verdef_count, dt_verneed_count and dt_strtab are added to
+ elf_obj_tdata to store dynamic symbol table information.
+
+ PR ld/25617
+ * elf-bfd.h (elf_obj_tdata): Add dt_symtab, dt_verdef, dt_verneed,
+ dt_symtab_count, dt_verdef_count, dt_verneed_count and dt_strtab.
+ (elf_use_dt_symtab_p): New.
+ (_bfd_elf_get_dynamic_symbols): Likewise.
+ (_bfd_elf_get_section_from_dynamic_symbol): Likewise.
+ * elf.c (bfd_elf_get_elf_syms): Use dynamic symbol table if
+ neeeded.
+ (_bfd_elf_get_dynamic_symtab_upper_bound): Likewise.
+ (_bfd_elf_slurp_version_tables): Likewise.
+ (offset_from_vma): New function.
+ (get_hash_table_data): Likewise.
+ (_bfd_elf_get_dynamic_symbols): Likewise.
+ (_bfd_elf_get_section_from_dynamic_symbol): Likewise.
+ (_bfd_elf_get_symbol_version_name): Likewise.
+ * elfcode.h (elf_object_p): Call _bfd_elf_get_dynamic_symbols
+ to reconstruct dynamic symbol table from PT_DYNAMIC segment if
+ there is no section header.
+ (elf_slurp_symbol_table): Use dynamic symbol table if neeeded.
+ Don't free isymbuf when dynamic symbol table is used.
+ * elflink.c (elf_link_is_defined_archive_symbol): Return wrong
+ format error when dynamic symbol table is used.
+ (elf_link_add_object_symbols): Likewise.
+
+2023-06-29 H.J. Lu <hjl.tools@gmail.com>
+
+ ELF: Discard non-alloc sections without section header
+ Discard non-alloc sections when section headers are stripped.
+
+ bfd/
+
+ PR ld/25617
+ * elf.c (_bfd_elf_assign_file_positions_for_non_load): Skip
+ non-load sections without section header.
+ (_bfd_elf_write_object_contents): Don't set the sh_name field
+ without section header. Write out the .shstrtab section only
+ if its sh_offset field isn't -1.
+
+ binutils/
+
+ PR ld/25617
+ * objcopy.c (is_strip_section_1): Remove non-alloc sections for
+ --strip-section-headers.
+
+ ld/
+
+ PR ld/25617
+ * ldlang.c (lang_discard_section_p): Discard non-alloc sections
+ if we are stripping section headers.
+
+2023-06-29 Kaylee Blake <klkblake@gmail.com>
+
+ ELF: Strip section header in ELF objects
+ Section header isn't mandatory on ELF executable nor shared library.
+ This patch adds a new linker option, -z nosectionheader, to omit ELF
+ section header, a new objcopy and strip option, --strip-section-headers,
+ to remove ELF section headers.
+
+ bfd/
+
+ 2023-06-06 H.J. Lu <hongjiu.lu@intel.com>
+ Kaylee Blake <klkblake@gmail.com>
+
+ PR ld/25617
+ * bfd.c (BFD_NO_SECTION_HEADER): New.
+ (BFD_FLAGS_SAVED): Add BFD_NO_SECTION_HEADER.
+ (BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.
+ * elfcode.h (elf_swap_ehdr_out): Omit section header with
+ BFD_NO_SECTION_HEADER.
+ (elf_write_shdrs_and_ehdr): Likewise.
+ * elfxx-target.h (TARGET_BIG_SYM): Add BFD_NO_SECTION_HEADER
+ to object_flags.
+ (TARGET_LITTLE_SYM): Likewise.
+ * bfd-in2.h: Regenerated.
+
+ binutils/
+
+ 2023-06-06 H.J. Lu <hongjiu.lu@intel.com>
+
+ PR ld/25617
+ * NEWS: Mention --strip-section-headers for objcopy and strip.
+ * objcopy.c (strip_section_headers): New.
+ (command_line_switch): Add OPTION_STRIP_SECTION_HEADERS.
+ (strip_options): Add --strip-section-headers.
+ (copy_options): Likewise.
+ (copy_usage): Add --strip-section-headers.
+ (strip_usage): Likewise.
+ (copy_object): Handle --strip-section-headers for ELF files.
+ (strip_main): Handle OPTION_STRIP_SECTION_HEADERS.
+ (copy_main): Likewise.
+ * doc/binutils.texi: Document --strip-section-headers for objcopy
+ and strip.
+
+ ld/
+
+ 2023-06-06 H.J. Lu <hongjiu.lu@intel.com>
+ Kaylee Blake <klkblake@gmail.com>
+
+ PR ld/25617
+ * NEWS: Mention -z nosectionheader.
+ * emultempl/elf.em: Support -z sectionheader and
+ -z nosectionheader.
+ * ld.h (ld_config_type): Add no_section_header.
+ * ld.texi: Document -z sectionheader and -z nosectionheader.
+ * ldlang.c (ldlang_open_output): Handle
+ config.no_section_header.
+ * lexsup.c (parse_args): Enable --strip-all with
+ -z nosectionheader. Disallow -r with -z nosectionheader.
+ (elf_static_list_options): Add -z sectionheader and
+ -z nosectionheader.
+
+2023-06-29 Matthias Klose <doko@debian.org>
+
+ Ignore --prefix-file-map compiler option whist running testsuite.
+
+ ignore lto-wrapper warnings for lto builds.
+ I see these warnings from time to time, when configuring a build with --enable-pgo-build=lto, I haven't yet found out why I see these sometime, and why not. E.g. https://gcc.gnu.org/PR109241. Just ignore these when they appear in test cases. lto-wrapper: warning: using serial compilation of N LTRANS jobs
+
+2023-06-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Add new tests
+ gprofng/ChangeLog
+ 2023-06-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * Makefile.am: Pass CLOCK_GETTIME_LINK to the testsuite
+ * Makefile.in: Rebuild.
+ * testsuite/gprofng.display/gp-archive.exp: New file.
+ * testsuite/gprofng.display/gp-collect-app_F.exp: New file.
+ * testsuite/gprofng.display/setpath_map.exp: New file.
+ * testsuite/lib/smalltest.c: New file.
+
+2023-06-28 Andrew Carlotti <andrew.carlotti@arm.com>
+
+ aarch64: Remove version dependencies from features
+ Many instructions were enabled only when both a feature flag and a minimum
+ architecture version are specified. This behaviour differs from GCC, which (in
+ most cases) allows features to be enabled at any architecture version.
+
+ There is no need for the toolchain to restrict combinations of unrelated
+ features in this way, so this patch removes the unnecessary dependencies.
+
+2023-06-28 Tom Tromey <tromey@adacore.com>
+
+ Remove Python 2 from gdb documentation
+ GDB can't be built using Python 2 any more, so remove the remaining
+ vestiges of this from the documentation.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-06-28 Michael Matz <matz@suse.de>
+
+ section-match: Check parent archive name as well
+ rewriting the section matching routines lost a special case
+ of matching: section statements of the form
+
+ NAME(section-glob)
+
+ normally match against NAME being an object file, but like in
+ the exclude list we happened to accept archive names as NAME
+ (undocumented). The documented way to specify (all) archive members
+ is by using e.g.
+
+ lib.a:(section-glob)
+
+ (that does work also with the prefix tree matcher).
+
+ But I intended to not actually change behaviour with the prefix
+ tree implementation. So, let's also implement checking against
+ archive names with a similar FIXME comment we already have in
+ walk_wild_file_in_exclude_list.
+
+ PR 30590
+
+ ld/
+ * ldlang.c (walk_wild_section_match): Also look at archive
+ parents for a name match.
+
+2023-06-28 Tom Tromey <tromey@adacore.com>
+
+ Fix handling of DW_TAG_unspecified_type for Ada
+ Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type
+ DIE") changed the handling of DW_TAG_unspecified_type. Before this
+ change, such types were not entered into the symbol table.
+
+ It turns out that, when such a type is in the symtab, it can cause
+ failures in Ada. In particular, a private type in another package may
+ be seen locally as "void".
+
+ Now, it would probably be better to fix this via check_typedef.
+ However, that is somewhat difficult given the state of the DWARF
+ reader -- in particular with gdb_index, this would require expanding
+ potentially many CUs to find the correct type.
+
+ Instead, this patch changes gdb to not enter a symbol for an
+ unspecified type -- but only for Ada.
+
+2023-06-28 Tom Tromey <tromey@adacore.com>
+
+ Remove some Python 2 code
+ I found some Python 2 compatibility code in gdb's Python library.
+ There's no need for this any more, so this removes it. There is still
+ a bit more of this remaining in __init__.py, but I haven't tried
+ removing that yet.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-06-28 Nick Clifton <nickc@redhat.com>
+
+ Stop the linker's --dependency-file option from including temporary lto files.
+ PR 30568
+ * ldfile.c (ldfile_try_open_bfd): Do not track lto generated temporary files.
+
+ Updated French translation for the gold sub-directory
+
+2023-06-28 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Add LSX and LASX instructions test
+ gas/ChangeLog:
+
+ * testsuite/gas/loongarch/vector.d: New test.
+ * testsuite/gas/loongarch/vector.s: New test.
+
+2023-06-28 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Add lsx and lasx instructions support
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c (md_parse_option): Add lsx and lasx option.
+ (loongarch_after_parse_args): Add lsx and lasx option.
+
+ opcodes/ChangeLog:
+
+ * loongarch-opc.c (struct loongarch_ase): Add lsx and lasx
+ instructions.
+
+2023-06-28 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Add R_LARCH_64_PCREL relocation support
+ Gas defaults to emit R_LARCH_ADD64/R_LARCH_SUB64 unless explcitly declared
+ to emit R_LARCH_64_PCREL.
+
+ The LoongArch ABI at here:
+ https://github.com/loongson/la-abi-specs/blob/release/la-abi.adoc
+
+ bfd/ChangeLog:
+
+ * bfd-in2.h (not): Add R_LARCH_64_PCREL
+ * elfnn-loongarch.c (perform_relocation): Likewise.
+ * elfxx-loongarch.c: Likewise.
+ * libbfd.h: Likewise.
+ * reloc.c: Likewise.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
+ (md_apply_fix): Add R_LARCH_64_PCREL.
+ * testsuite/gas/loongarch/64_pcrel.d: New test.
+ * testsuite/gas/loongarch/64_pcrel.s: New test.
+
+ include/ChangeLog:
+
+ * elf/loongarch.h (RELOC_NUMBER): Add R_LARCH_64_PCREL.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test.
+ * testsuite/ld-loongarch-elf/64_pcrel.d: New test.
+ * testsuite/ld-loongarch-elf/64_pcrel.s: New test.
+
+2023-06-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ binutils/NEWS: add note about upcoming libsframe changes
+ Some of these changes update the ABI in an incompatible way.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: bfd: use uint32_t for return type of get_num_fidx APIs
+ Keep the data types usage in libsframe look consistent.
+
+ bfd/
+ * elf-sframe.c (_bfd_elf_merge_section_sframe): Use uint32_t
+ type alias.
+ * libsframe/sframe.c (sframe_decoder_get_funcdesc_at_index):
+ Likewise.
+ (sframe_decoder_get_num_fidx): Likewise.
+ (sframe_encoder_get_num_fidx): Likewise.
+ include/
+ * sframe-api.h (sframe_decoder_get_num_fidx): Likewise.
+ (sframe_encoder_get_num_fidx): Likewise.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use appropriate data types for args of sframe_encode
+ include/
+ * sframe-api.h (sframe_encode): Use of uint8_t is more
+ appropriate.
+ libsframe/
+ * sframe.c (sframe_encode): Likewise.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use uint8_t for return type of sframe_fre_get_base_reg_id
+ Use a more appropriate data type.
+
+ include/
+ * sframe-api.h (sframe_fre_get_base_reg_id): Use uint8_t as
+ return type.
+ libsframe/
+ * sframe-dump.c (dump_sframe_func_with_fres): Use uint8_t type
+ for base reg id.
+ * sframe.c (sframe_fre_get_base_reg_id): Use uin8_t as return
+ type.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use uint8_t instead of unsigned char for abi_arch
+ Use uint8_t consistently for identifying ABI/arch in SFrame format.
+
+ bfd/
+ * elf-sframe.c (_bfd_elf_merge_section_sframe):
+ libsframe/
+ * sframe-dump.c (is_sframe_abi_arch_aarch64): Use uint8_t for
+ local variable.
+ * sframe.c (sframe_decoder_get_abi_arch): Update return type to
+ uint8_t.
+ (sframe_encoder_get_abi_arch): Likewise.
+ include/
+ * sframe-api.h (sframe_decoder_get_abi_arch): Likewise.
+ (sframe_encoder_get_abi_arch): Likewise.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: bfd: use uint32_t for return type of sframe_calc_fre_type
+ Use uint32_t type alias consistently for all APIs in libsframe.
+
+ bfd/
+ * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for the
+ changed return type.
+ libsframe/
+ * sframe.c (sframe_calc_fre_type): Use uint32_t for return type.
+ include/
+ * sframe-api.h (sframe_calc_fre_type): Likewise.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use uint32_t for fre_type and fde_type function args
+ The API sframe_fde_create_func_info is provided by libsframe. Current
+ users are the bfd linker. Adjust the argument type for the variables
+ carrying the SFrame FRE type and SFrame FDE type to consistenly use
+ uint32_t type alias.
+
+ include/
+ * sframe-api.h (sframe_fde_create_func_info): Use uint32_t
+ instead of unsigned int.
+ libsframe/
+ * sframe.c (sframe_get_fre_type): Likewise.
+ (sframe_get_fde_type): Likewise.
+ (flip_fre_start_address): Likewise.
+ (sframe_fre_start_addr_size): Likewise.
+ (sframe_fre_entry_size): Likewise.
+ (flip_fre): Likewise.
+ (flip_sframe): Likewise.
+ (sframe_fde_create_func_info): Likewise.
+ (sframe_calc_fre_type): Likewise.
+ (sframe_decode_fre_start_address): Likewise.
+ (sframe_decode_fre): Likewise.
+ (sframe_find_fre): Likewise.
+ (sframe_decoder_get_fre): Likewise.
+ (sframe_encoder_add_fre): Likewise.
+ (sframe_encoder_write_fre_start_addr): Likewise.
+ (sframe_encoder_write_fre): Likewise.
+ (sframe_encoder_write_sframe): Likewise.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: update the semantics of sframe_fre_get_fp_offset
+ Until now, sframe_fre_get_fp_offset () would return
+ SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed FP offset. A stack
+ tracer, then, would call an explicit sframe_decoder_get_fixed_fp_offset ()
+ to get the FP offset.
+
+ On second look, it appears to make sense to hide these details of
+ whether the FP offset is fixed or not in an ABI from the consumer. Now,
+ with the changed semantics, the call to sframe_fre_get_fp_offset () will
+ fetch the fixed FP offset if applicable, or get the FP offset from FRE
+ when there is no fixed FP offset.
+
+ This patch changes the behavior of sframe_fre_get_fp_offset (): it turns
+ an error into non-error. This change will be included with the next
+ release of libsframe, where all the exposed symbols will be versioned
+ with version node LIBSFRAME_1.0 for the first time.
+
+ libsframe/
+ * sframe.c (sframe_fre_get_fp_offset): Return the fixed offset, if
+ applicable. Else return the FP offset from the FRE.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: update the semantics of sframe_fre_get_ra_offset
+ Until now, sframe_fre_get_ra_offset () would return
+ SFRAME_ERR_FREOFFSET_NOPRESENT if the ABI uses fixed RA offset (e.g.,
+ AMD64). A stack tracer, then, will call an explicit
+ sframe_decoder_get_fixed_ra_offset () to get the RA offset.
+
+ On second look, it appears to make sense to hide these details of
+ whether the RA offset is fixed or not from the consumer. Now, with the
+ changed semantics, the call to sframe_fre_get_ra_offset () will fetch
+ the fixed RA offset if applicable, or get the RA offset from FRE when
+ there is no fixed RA offset.
+
+ Adjustments need to be made to ensure the textual dump remains the same
+ as preivous. Currently, e.g., if RA is not being tracked per FRE,
+ following is seen with objdump --sframe:
+
+ STARTPC CFA FP RA
+ 000000000000NNNN sp+X u u
+
+ This patch changes the behavior of sframe_fre_get_ra_offset: it turns an
+ error into non-error. This change will be included with the next
+ release of libsframe, where all exposed symbols will be versioned for
+ the first time.
+
+ libsframe/
+ * sframe.c (sframe_fre_get_ra_offset): Return the fixed offset,
+ if applicable. Else return the RA offset from the FRE.
+ * sframe-dump.c (dump_sframe_func_with_fres): Make adjustments
+ to keep the textual dump same as previous.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: add symbol versioning
+ Define an empty base version LIBSFRAME_0.0 and add all symbols to
+ version LIBSFRAME_1.0.
+
+ The previous release of libsframe (libsframe.so.0) did not have
+ versioned symbols. Adding a libsframe.ver file so that future releases
+ of the library (and its consumers) can manage the changes better.
+
+ For Solaris ld, use -M mapfile command line option. libsframe does not
+ restrict the set of exported symbols, so at this time there is no need
+ to fall back on the libtool's -export-symbols option for platforms where
+ some other linker (with a different command line option for symbol
+ versioning) may be used.
+
+ libsframe/
+ * Makefile.am: Use symbol versioning for libsframe.
+ * Makefile.in: Regenerated.
+ * configure: Check for Solaris ld.
+ * configure.ac: Regenerated.
+ * libsframe.ver: New file.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: remove sframe_get_funcdesc_with_addr API
+ This is an incompatible ABI change in libsframe.
+
+ The interface provided by this function is not a healthy abstraction to
+ expose: the return type sframe_func_desc_entry, which is defined in
+ include/sframe.h (the SFrame binary format definition). This ties up
+ the library in a undesirable way. Most importantly, this function
+ should technically not be directly necessary for a stack tracer. A
+ stack tracer will likely only need to do a sframe_find_fre ().
+
+ Rename the API to continue to use the functionality internally in the
+ library. bfd/linker does not use this function.
+
+ Change the return type of the previous definition and make a note about
+ its planned deprecation.
+
+ include/
+ * sframe-api.h: Change return type of sframe_get_funcdesc_with_addr.
+ Add comment for intention to deprecate.
+ libsframe/
+ *sframe.c (sframe_get_funcdesc_with_addr): Change return type
+ and set error code. This API is deprecated.
+ (sframe_get_funcdesc_with_addr_internal): New definition for
+ internal use.
+ (sframe_find_fre): Use sframe_get_funcdesc_with_addr_internal
+ instead.
+
+2023-06-27 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: add library versioning
+ lisbframe was first released with Bintuils 2.40. As the library
+ evolves, some changes will break the ABI. Add library versioning for
+ users to manage these changes.
+
+ For the next release of the library (libsframe.so.1), incompatible ABI
+ changes are planned. These will include:
+ - Deprecation of some APIs, like sframe_get_funcdesc_with_addr (), and
+ - Change in the contract of some APIs (e.g., return type, behavior).
+
+ In libtool-version, set the current to 1 to prepare for the upcoming
+ release. Reset revision and age to 0.
+
+ Add libtool-version file to EXTRA_DIST.
+
+ libsframe/
+ * Makefile.am: Use libtool versioning.
+ * Makefile.in: Regenerated.
+ * libtool-version: New file.
+
+2023-06-27 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Support Zicond extension
+ This implements the Zicond (conditional integer operations) extension,
+ as of version 1.0-rc2.
+
+ The Zicond extension acts as a building block for branchless sequences
+ including conditional-arithmetic, conditional-logic and
+ conditional-select/move.
+ The following instructions constitute Zicond:
+ - czero.eqz rd, rs1, rs2 => rd = (rs2 == 0) ? 0 : rs1
+ - czero.nez rd, rs1, rs2 => rd = (rs2 != 0) ? 0 : rs1
+
+ See
+ https://github.com/riscv/riscv-zicond/releases/download/v1.0-rc2/riscv-zicond-v1.0-rc2.pdf
+ for the proposed specification and usage details.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Recognize
+ INSN_CLASS_ZICOND.
+ (riscv_multi_subset_supports_ext): Recognize INSN_CLASS_ZICOND.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zicond.d: New test.
+ * testsuite/gas/riscv/zicond.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_CZERO_EQZ): Define.
+ (MASK_CZERO_EQZ): Define.
+ (MATCH_CZERO_NEZ): Define,
+ (MASK_CZERO_NEZ): Define.
+ (DECLARE_INSN): Add czero.eqz and czero.nez.
+ * opcode/riscv.h (enum riscv_insn_class): Add
+ INSN_CLASS_ZICOND.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add czero.eqz and czero.nez.
+
+ Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+2023-06-27 Nick Clifton <nickc@redhat.com>
+
+ Add note about adding ChangeLog.git to src-release.sh
+
+2023-06-27 Cui, Lili <lili.cui@intel.com>
+
+ gprofng: Update intel url
+ Since the old software.intel.com has been removed, update a new one.
+
+ gprofng/ChangeLog
+ 2023-06-27 Lili Cui <lili.cui@intel.com>
+
+ * gp-display-html/gp-display-html.in: Update intel url.
+
+2023-06-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-26 Nick Clifton <nickc@redhat.com>
+
+ Fix gas tests for aarch64-pe
+
+ Synchromize libiberty sources with master version in gcc repository
+
+ Sync config.guess and config.sub with upstream master versions.
+
+ Updated French translation for the gprof sub-directory
+
+2023-06-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-25 Feiyang Chen <chenfeiyang@loongson.cn>
+
+ LoongArch: Support referring to FCSRs as $fcsrX
+ Previously, FCSRs were referred to as $rX, which seemed strange.
+ We refer to FCSRs as $fcsrX, which ensures compatibility with LLVM
+ IAS as well.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c:
+ (loongarch_fc_normal_name): New definition.
+ (loongarch_fc_numeric_name): New definition.
+ (loongarch_single_float_opcodes): Modify `movgr2fcsr` and
+ `movfcsr2gr`.
+ testsuite/gas/loongarch/float_op.d: Likewise.
+ testsuite/gas/loongarch/float_op.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/loongarch.h:
+ (loongarch_fc_normal_name): New extern.
+ (loongarch_fc_numeric_name): New extern.
+
+ opcodes/ChangeLog:
+
+ * opcodes/loongarch-dis.c (loongarch_after_parse_args): Support
+ referring to FCSRs as $fcsrX.
+ * opcodes/loongarch-opc.c (loongarch_args_parser_can_match_arg_helper):
+ Likewise.
+
+2023-06-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-23 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb/testsuite: Avoid infinite loop in gdb.reverse/step-reverse.exp
+ This testcase sometimes gets stuck in a loop for hours when running in our
+ CI. The problem is that due to an issue unrelated to reverse debugging the
+ inferior exits early, and because of the overly generic ".*" pattern the
+ testcase keeps sending the "next" command without noticing that the
+ inferior is gone.
+
+ gdb_test_multiple has a pattern to detect that "The program is not being
+ run.", but since it is placed after the patterns from the caller it won't
+ be triggered. It also has a timeout pattern but because it is triggered
+ between successful matches, each time the test matches the '-re -wrap ".*"'
+ this counts as a successful match and the timeout is reset.
+
+ Since the test binary is compiled with debug information, fix by changing
+ one of the generic patterns to match entering the main function and the
+ other one to match the source code line number that is shown by GDB right
+ after the "step" command.
+
+ Also, as a precaution add a maximum number of times the "next" command will
+ be sent.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-06-23 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64 huge branch dynamic relocs
+ PowerPC64 gold and ld.bfd implement an indirect branch trampoline,
+ used when the destination of a branch exceeds a bounce through another
+ "b" instruction. When generating PIEs or shared libraries, the
+ addresses need dynamic relocations. This was implemented in gold
+ using a dedicated relocation section, but this means the relative
+ relocations for these addresses are not sorted properly with other
+ dynamic relative relocations: gold doesn't support merging relocation
+ sections, then sorting. Instead we need to use a single .rela.dyn
+ section.
+
+ This is done by increasing the size of rela_dyn_ during do_relax to
+ account for needed dynamic relocations, delaying adding the actual
+ relocations until the end of relaxation once the layout has
+ stabilised.
+
+ * powerpc.cc (Target_powerpc): Add rela_dyn_size_;
+ (update_current_size): New function.
+ (Target_powerpc::do_relax): Capture the size of rela_dyn_ at
+ the start of relaxation. Artifically increase its size during
+ relaxation to account for needed indirect branches, and add
+ those relocations at the end.
+ (Output_data_brlt_powerpc::rel_, reset_brlt_sizes),
+ (finalize_brlt_sizes, add_reloc, set_current_size): Delete.
+ (Target_powerpc::make_brlt_section): Don't make reloc section.
+
+2023-06-23 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Support setting DT_RELACOUNT late
+ PowerPC gold adds relative dynamic relocs in do_relax. These aren't
+ accounted for in the value set in add_target_dynamic_tags, which is
+ called before do_relax. Provide a way of setting DT_RELCOUNT and
+ DT_RELACOUNT at the point where .dynamic is written.
+
+ * layout.cc (Layout::add_target_dynamic_tags): Add custom_relcount
+ parameter. Emit DT_RELCOUNT/RELACOUNT as a custom target handled
+ dynamic tag if set.
+ * layout.h(Layout::add_target_dynamic_tags): Update prototype.
+ * aarch64.cc (Target_aarch64::do_finalize_sections): Adjust
+ add_target_dynamic_tags call.
+ * arm.cc (Target_arm::do_finalize_sections): Likewise.
+ * i386.cc (Target_i386::do_finalize_sections): Likewise.
+ * mips.cc (Target_mips::do_finalize_sections): Likewise.
+ * s390.cc (Target_s390::do_finalize_sections): Likewise.
+ * sparc.cc (Target_sparc::do_finalize_sections): Likewise.
+ * tilegx.cc (Target_tilegx::do_finalize_sections): Likewise.
+ * x86_64.cc (Target_x86_64::do_finalize_sections): Likewise.
+ * powerpc.cc (Target_powerpc::do_finalize_sections): Likewise.
+ (Target_powerpc::do_dynamic_tag_custom_value): New function.
+
+2023-06-23 Alan Modra <amodra@gmail.com>
+
+ [GOLD] powerpc DT_RELACOUNT
+ DT_RELACOUNT was calculated incorrectly, and relative relocs not
+ sorted as they should be to the start of .rela.dyn, due to adding one
+ particular class of dynamic reloc using the wrong "add" method.
+
+ * powerpc.cc (Target_powerpc::Scan::global): Add relative
+ dyn relocs for ADDR64 and similar using add_global_relative.
+
+2023-06-23 Alan Modra <amodra@gmail.com>
+
+ lto test fails with -fno-inline in CFLAGS
+ Putting -fno-inline in CFLAGS results in these failures.
+ FAIL: Build liblto-17b.so 1
+ FAIL: PR ld/12365
+ FAIL: PR ld/13183
+
+ * ld-plugin/lto.exp: Add -finline to compiler flags in some tests.
+
+2023-06-23 Tom Tromey <tom@tromey.com>
+
+ Fix off-by-one error
+ Simon pointed out that commit a2bbca9fa5e ("Use std::vector<bool> for
+ agent_expr::reg_mask") caused a regression in libstdc++ debug mode.
+ This was due to an off-by-one error in a vector resize. This patch
+ fixes the problem.
+
+2023-06-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-22 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ gdb/testsuite: fix gdb.python/py-unwind.exp with python >= 3.11
+ Python 3.11 changed the AttributeError message - see commit
+ 0cb765b2cec9 ("bpo-46730: Add more info to @property AttributeError
+ messages (GH-31311)"). Add the new message to the expectations.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Link: https://sourceware.org/pipermail/gdb-patches/2023-June/200433.html
+
+2023-06-22 H.J. Lu <hjl.tools@gmail.com>
+
+ Revert "x86: Don't check if AVX512 template requires AVX512VL"
+ This reverts commit c7face14225296a2f5d3ebeb8ace88c166d80c3e.
+
+2023-06-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Clean or check standard_output_file dir in gdb_init
+ In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
+ gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
+ files at the start of the test-case:
+ ...
+ remote_file host delete [standard_output_file prog.o]
+ remote_file host delete [standard_output_file prog.ali]
+ ...
+
+ Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in
+ gdb_init") I tried to do this more structurally, by cleaning up the entire
+ standard_output_file directory, for all test-cases.
+
+ This caused a regression when using "make check -j 2", due to the cleanup
+ removing the active gdb.log, so I reverted the commit.
+
+ Try again, this time handling the two cases separately.
+
+ If the standard_output_file directory contains an active gdb.log, check that
+ the directory contains no files other than gdb.log and gdb.sum. This puts
+ the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in
+ which use --outdir.
+
+ If the standard_output_file directory doesn't contain an active gdb.log, clean
+ it by removing the entire directory.
+
+ An exception is made for performance tests, where cleaning up the
+ standard_output_file dir is the wrong thing to do, because an invocation with
+ GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an
+ earlier invocation with GDB_PERFTEST_MODE == compile.
+
+ Tested on x86_64-linux.
+
+ Suggested-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+
+2023-06-22 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP "hover" context
+ A DAP client can request that an expression be evaluated in "hover"
+ context, meaning that it should not cause side effects. In gdb, this
+ can be implemented by temporarily setting a few "may-" parameters to
+ "off".
+
+ In order to make this work, I had to also change "may-write-registers"
+ so that it can be changed while the program is running. I don't think
+ there was any reason for this prohibition in the first place.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30476
+
+2023-06-22 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP logging breakpoints
+ DAP allows a source breakpoint to specify a log message. When this is
+ done, the breakpoint acts more like gdb's dprintf: it logs a message
+ but does not cause a stop.
+
+ I looked into implement this using dprintf with the new %V printf
+ format. However, my initial attempt at this did not work, because
+ when the inferior is continued, the dprintf output is captured by the
+ gdb.execute call. Maybe this could be fixed by having all
+ inferior-continuation commands use the "&" form; the main benefit of
+ this would be that expressions are only parsed a single time.
+
+2023-06-22 Tom Tromey <tromey@adacore.com>
+
+ Handle supportsVariablePaging in DAP
+ A bug report about the supportsVariablePaging capability in DAP
+ resulted in a clarification: when this capability is not present, DAP
+ implementations should ignore the paging parameters to the "variables"
+ request. This patch implements this clarification.
+
+ Implement type checking for DAP breakpoint requests
+ I realized that with a small refactoring, it is possible to type-check
+ the parameters to the various DAP breakpoint requests. This would
+ have caught the earlier bug involving hitCondition.
+
+ Handle exceptions when creating DAP breakpoints
+ When creating a DAP breakpoint, a failure should be returned by
+ setting "verified" to False. gdb didn't properly implement this, and
+ there was a FIXME comment to this effect. This patch fixes the
+ problem.
+
+ Reuse breakpoints more frequently in DAP
+ The DAP breakpoint code tries to reuse a breakpoint when possible.
+ Currently it uses the condition and the hit condition (aka ignore
+ count) when making this determination. However, these attributes are
+ just going to be reset anyway, so this patch changes the code to
+ exclude these from the reuse decision.
+
+ Fix type of DAP hitCondition
+ DAP specifies a breakpoint's hitCondition as a string, meaning it is
+ an expression to be evaluated. However, gdb implemented this as if it
+ were an integer instead. This patch fixes this oversight.
+
+2023-06-22 Simon Farre <simon.farre.cx@gmail.com>
+
+ gdb/DAP Few bug fixes & Evaluate Array Watch vars
+ v2.
+
+ EvaluateResult does not need a name, just as what Tom pointed out in
+ previous review. It's only the *children* that need to be made sure that
+ their names are valid. An identifier for a variable, can't ever have an
+ integer as a name, anyhow (not as far as I am aware, no programming
+ languages allow for that).
+
+ Removed the f-strings and use str() instead as pointed out that
+ f-strings might not be supported fully.
+
+ v1.
+
+ This patch fixes a few bugs.
+
+ First of all, name of VariableReferences must always be of string type.
+ This patch makes sure that this is the case by formatting the name. If
+ (when) the name is an integer, this will cause clients to fail or throw
+ errors.
+
+ Fixes a bug in NoOpArrayPrinter that calculated children to be N, but
+ only ever retrieves N-1 children, which makes Python at some time later
+ (during fetch_children -> fetch_one_child(N) ) raise an exception (out
+ of list index) which makes the entire request go bad.
+
+ The result[self.result_name] also f-strings the printer.to_string()
+ value, because this can potentially be a LazyString (which is a Python
+ object, not a string) and is not serializable by json.dumps.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-06-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-21 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Free the symbol buffer and the relocation buffer after use
+ When --no-keep-memory is used, the symbol buffer and the relocation
+ buffer aren't cached. When packing relative relocations, we may
+ allocate a new symbol buffer and a new relocation buffer for each
+ eligible section in an object file. If there are many sections,
+ memory may be exhausted. In this case, we should free the symbol
+ buffer and the relocation buffer after use. If symbol buffer entries
+ are used to track relative relocations against local symbols for later
+ use, the symbol buffer should be cached.
+
+ PR ld/30566
+ * elfxx-x86.c (elf_x86_relative_reloc_record_add): Add an
+ argument to inform caller if the symbol buffer should be kept.
+ (_bfd_x86_elf_link_relax_section): Call
+ _bfd_elf_link_info_read_relocs instead of
+ _bfd_elf_link_read_relocs. Free the symbol buffer and the
+ relocation buffer after use. Cache the symbol buffer if it
+ is used.
+
+2023-06-21 Tom Tromey <tromey@adacore.com>
+
+ Add missing backslash to update-gnulib.sh
+ A user on irc noticed a missing backslash on one line in
+ update-gnulib.sh. This patch adds it.
+
+ Re-running update-gnulib.sh causes a few copyright notices to change.
+ Presumably these are from upstream gnulib and shouldn't be touched by
+ our yearly update. I've updated the script to account for this, but I
+ did not want to try testing it...
+
+2023-06-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add have_host_locale
+ With test-case gdb.tui/pr30056.exp, I run into:
+ ...
+ sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M
+ ...
+ and then subsequently into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ FAIL: gdb.tui/pr30056.exp: Control-C
+ ...
+
+ This is on a CentOS 7 distro for powerpc64le.
+
+ Either it has no C.UTF-8 support, or it's not installed:
+ ...
+ $ locale -a | grep ^C
+ C
+ $
+ ...
+
+ Fix this by:
+ - adding a new proc have_host_locale, and
+ - using it in all test-cases using setenv LC_ALL.
+
+ Tested on powerpc64le-linux and x86_64-linux.
+
+2023-06-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/wrap-line.exp
+ PR testsuite/30458 reports the following FAIL:
+ ...
+ PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap
+ ^CQuit
+ (gdb) WARNING: timeout in accept_gdb_output
+ Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3):
+ 0 Quit
+ 1 (gdb) 7890123456789012345678901234567890123456789
+ 2 W^CQuit
+ 3 (gdb)
+ ...
+ FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap
+ ...
+
+ The problem is that the regexp doesn't account for the ^C:
+ ...
+ gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
+ ...
+
+ The ^C occurs occasionally. This is something we'd like to fix. It's
+ reported as a readline problem here (
+ https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html ).
+
+ For now, fix this by updating the regexp, and likewise in another place in the
+ test-case where we use ^C.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458
+
+2023-06-21 Alan Modra <amodra@gmail.com>
+
+ PR30536, ppc64el gold linker produces unusable clang-16 binary
+ In commit 0961e631575b, the fix for PR30217, make_lplt_section and
+ make_brlt_section were changed to use rela_dyn_ rather than their own
+ separate dynamic reloc sections. This fails miserably whenever brlt_
+ is needed for long branches, due to needing to iterate sizing and thus
+ reset brlt_ sizes.
+
+ PR 30536
+ PR 30217
+ * powerpc.cc (Target_powerpc::make_brlt_section): Don't use
+ rela_dyn_.
+
+2023-06-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Reimplement Term::command_no_prompt_prefix
+ Say we run test-case gdb.tui/basic.exp. It calls Term::enter_tui, which does:
+ ...
+ command_no_prompt_prefix "tui enable"
+ ...
+
+ The proc command_no_prompt_prefix is documented as:
+ ...
+ # As proc command, but don't wait for an initial prompt. This is used for
+ # initial terminal commands, where there's no prompt yet.
+ ...
+
+ Indeed, before the "tui enable" command, the tuiterm is empty, so there is no
+ prompt and just before switching to TUI we have in the tuiterm:
+ ...
+ tui enable
+ ...
+
+ The reason that there is no prompt, is that:
+ - in order for tuiterm to show something, its input processing procs need to
+ be called, and
+ - the initial gdb prompt, and subsequent prompts generated by gdb_test-style
+ procs, are all consumed by those procs instead.
+
+ This is in principle not a problem, but the absence of a prompt makes a
+ tuiterm session look less like a session on an actual xterm.
+
+ Add a new proc gen_prompt, that:
+ - generates a prompt using echo
+ - consumes the response before the prompt using gdb_expect
+ - consumes the prompt using Term::wait_for "".
+
+ This allows us to reimplement Term::command_no_prompt_prefix using
+ Term::command, and just before switching to TUI we have in the tuiterm:
+ ...
+ (gdb) tui enable
+ ...
+
+ Tested on x86_64-linux.
+
+2023-06-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make Term::wait_for "" match only a prompt
+ The semantics of Term::wait_for is:
+ ...
+ # Accept some output from gdb and update the screen. WAIT_FOR is
+ # a regexp matching the line to wait for. Return 0 on timeout, 1
+ # on success.
+ proc wait_for {wait_for} {
+ ...
+
+ Note that besides the regexp, also a subsequent gdb prompt is matched.
+
+ I recently used wait_for "" in a few test-cases, thinking that this would
+ match just a prompt, but in fact that's not the case.
+
+ Fix this in wait_for, and add a corresponding test in gdb.tui/tuiterm-2.exp.
+
+ Tested on x86_64-linux.
+
+2023-06-21 Nick Clifton <nickc@redhat.com>
+
+ Prune linker warnings about an executable stack being created with the -z execstack option.
+ * testsuite/lib/binutils-common.exp (prune_warnings_extra): Prune warnings about -z execstack creating an executable stack.
+
+ For test for PR 29072 when the linker is configured with --enable-default-execstack=no.
+ PR 29072
+ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Always return false for linkers configured with the --enable-default-execstack=no option.
+
+2023-06-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbserver: use target_waitstatus::to_string in 'prepare_resume_reply'
+ Use the to_string method of target_waitstatus in
+ 'prepare_resume_reply' for a more readable log message.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-06-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: fix expansion of %XV
+ Only %LV should continue on to S handling; avoid emitting a stray 'l'
+ (typically) in suffix-always mode.
+
+2023-06-21 Alan Modra <amodra@gmail.com>
+
+ elf32_arm_get_synthetic_symtab memory leak
+ ARM get_synthetic_symtab reads .plt and caches that data. Caching the
+ data doesn't make a lot of sense since get_synthetic_symtab is only
+ called once per bfd, and the memory might be put to better use. It
+ also leaks on closing the bfd.
+
+ * elf32-arm.c (elf32_arm_get_synthetic_symtab): Don't cache
+ plt contents. Free plt data before returning.
+
+2023-06-21 Alan Modra <amodra@gmail.com>
+
+ macho-o.c don't leak strtab
+ * mach-o.c (bfd_mach_o_write_symtab_content): Free strtab on
+ success path.
+
+2023-06-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use ARRAY_SIZE in ax-general.c
+ This changes a couple of spots in ax-general.c to use ARRAY_SIZE.
+ While making this change, I noticed that one of the bounds checks was
+ incorrect.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Remove aop_last
+ aop_last is only used for an assertion. However, due to the '.def'
+ construct in the sources, this assert could never plausibly trigger
+ (the assert predates the use of a .def file here). This patch removes
+ the constant and the assert.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Make aop_map 'static'
+ This changes aop_map to be 'static'.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use bool for agent_expr::tracing
+ This changese agent_expr::tracing to have type bool, allowing inline
+ initialization and cleaning up the code a little.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Simplify agent_expr constructor
+ This simplifies the agent_expr constructor a bit, and removes the
+ destructor entirely.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use std::vector<bool> for agent_expr::reg_mask
+ agent_expr::reg_mask implements its own packed boolean vector. This
+ patch replaces it with a std::vector<bool>, simplifying the code.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use gdb::byte_vector in agent_expr
+ This changes agent_expr to use gdb::byte_vector rather than manually
+ reimplementing a vector.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Remove mem2hex
+ tracepoint.c has a 'mem2hex' function that is functionally equivalent
+ to bin2hex. This patch removes the redundancy.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Don't check if AVX512 template requires AVX512VL
+ If the ZMM operand in an AVX12 template also allows XMM or ZMM, this
+ template must require AVX512VL. Drop the AVX512VL requirement check
+ on such AVX512 templates.
+
+ * config/tc-i386.c (check_VecOperands): Don't check if AVX512
+ template requires AVX512VL.
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use std::string in do_set_command
+ do_set_command manually updates a string, only to copy it to a
+ std::string and free the working copy. This patch changes this code
+ to use std::string for everything, simplifying the code and removing a
+ copy.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use byte_vector in remote.c:readahead_cache
+ This patch changes the remote.c readahead_cache to use
+ gdb::byte_vector. This simplifies the code by removing manual memory
+ management.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tom@tromey.com>
+
+ Use std::string in linux-osdata.c
+ I found some code in linux-osdata that manually managed a string.
+ Replacing this with std::string simplifies it.
+
+ Reviewed-by: John Baldwin <jhb@FreeBSD.org>
+
+2023-06-20 Tom Tromey <tromey@adacore.com>
+
+ Use unique_xmalloc_ptr for mi_parse::command
+ This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up
+ all the uses. This avoids some manual memory management. std::string
+ is not used here due to how the Python API works -- this approach
+ avoids an extra copy there.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-06-20 Tom Tromey <tromey@adacore.com>
+
+ Use std::string for MI token
+ This changes the MI "token" to be a std::string, removing some manual
+ memory management. It also makes current_token 'const' in order to
+ support this change.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-06-20 Alan Modra <amodra@gmail.com>
+
+ Don't segfault in mips reloc special_functions
+ A symbol defined in a section from a shared library will have a NULL
+ section->output_section during linking.
+
+ * elf32-mips.c (gprel32_with_gp): Don't segfault on NULL
+ symbol->section->output_section.
+ * elf64-mips.c (mips_elf64_gprel32_reloc): Likewise.
+ * elfn32-mips.c (mips_elf_gprel16_reloc): Likewise.
+ (mips_elf_literal_reloc, mips_elf_gprel32_reloc): Likewise.
+ (gprel32_with_gp, mips16_gprel_reloc): Likewise.
+ * elfxx-mips.c (_bfd_mips_elf_gprel16_with_gp): Likewise.
+ (_bfd_mips_elf_generic_reloc): Likewise.
+
+2023-06-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-19 Tom de Vries <tdevries@suse.de>
+
+ Revert "[gdb/testsuite] Clean standard_output_file dir in gdb_init"
+ This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
+
+2023-06-19 Simon Farre <simon.farre.cx@gmail.com>
+
+ Fixes 28ab59607ef40b9571c0702ffba8f6aa6fb1b033
+ Python formatting errors fixed, introduced by this commit.
+
+ Fixes f1a614dc8f015743e9fe7fe5f3f019303f8db718
+ Fixes failure reported by buildbot regarding ill-formatted Python code.
+
+2023-06-19 Simon Farre <simon.farre.cx@gmail.com>
+
+ gdb/Python: Added ThreadExitedEvent
+ v6:
+ Fix comments.
+ Fix copyright
+ Remove unnecessary test suite stuff. save_var had to stay, as it mutates
+ some test suite state that otherwise fails.
+
+ v5:
+ Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/
+
+ v4:
+ Doc formatting fixed.
+
+ v3:
+ Eli:
+ Updated docs & NEWS to reflect new changes. Added
+ a reference from the .ptid attribute of the ThreadExitedEvent
+ to the ptid attribute of InferiorThread. To do this,
+ I've added an anchor to that attribute.
+
+ Tom:
+ Tom requested that I should probably just emit the thread object;
+ I ran into two issues for this, which I could not resolve in this patch;
+
+ 1 - The Thread Object (the python type) checks it's own validity
+ by doing a comparison of it's `thread_info* thread` to nullptr. This
+ means that any access of it's attributes may (probably, since we are
+ in "async" land) throw Python exceptions because the thread has been
+ removed from the thread object. Therefore I've decided in v3 of this
+ patch to just emit most of the same fields that gdb.InferiorThread has, namely
+ global_num, name, num and ptid (the 3-attribute tuple provided by
+ gdb.InferiorThread.ptid).
+
+ 2 - A python user can hold a global reference to an exiting thread. Thus
+ in order to have a ThreadExit event that can provide attribute access
+ reliably (both as a global reference, but also inside the thread exit
+ handler, as we can never guarantee that it's executed _before_ the
+ thread_info pointer is removed from the gdbpy thread object),
+ the `thread_info *` thread pointer must not be null. However, this
+ comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
+ that if a user holds takes a global reference to that
+ exiting event thread object, they can some time later do `t.switch()` at which
+ point GDB will 'explode' so to speak.
+
+ v2:
+ Fixed white space issues and NULL/nullptr stuff,
+ as requested by Tom Tromey.
+
+ v1:
+ Currently no event is emitted for a thread exit.
+
+ This adds this functionality by emitting a new gdb.ThreadExitedEvent.
+
+ It currently provides four attributes:
+ - global_num: The GDB assigned global thread number
+ - num: the per-inferior thread number
+ - name: name of the thread or none if not set
+ - ptid: the PTID of the thread, a 3-attribute tuple, identical to
+ InferiorThread.ptid attribute
+
+ Added info to docs & the NEWS file as well.
+
+ Added test to test suite.
+
+ Fixed formatting.
+
+ Feedback wanted and appreciated.
+
+2023-06-19 Simon Farre <simon.farre.cx@gmail.com>
+
+ gdb/dap - Getting thread names
+ Renamed thread_name according to convention (_ first)
+
+ When testing firefox tests, it is apparent that
+ _get_threads returns threads with name field = None.
+
+ I had initially thought that this was due to Firefox setting the names
+ using /proc/pid/task/tid/comm, by writing directly to the proc fs the
+ names, but apparently GDB seems to catch this, because I re-wrote
+ the basic-dap.exp/c to do this specifically and it saw the changes.
+
+ So I couldn't determine right now, what operation of name change that
+ GDB does not pick up, but with this patch, GDB will pick up the thread
+ names for an applications that set the name of a thread in ways that
+ aren't obvious.
+
+2023-06-19 Nick Clifton <nickc@redhat.com>
+
+ Fix illegal memory access implementing relocs in a fuzzed x86_64 object file.
+ PR 30560
+ * elf64-x86-64.c (elf_x86_64_relocate_section): Add more checks for a valid relocation offset.
+
+2023-06-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add shared_gnat_runtime_has_debug_info
+ Test-case gdb.ada/catch_ex_std.exp passes for me with package
+ libada7-debuginfo installed, but after removing it I get:
+ ...
+ (gdb) catch exception some_kind_of_error^M
+ Your Ada runtime appears to be missing some debugging information.^M
+ Cannot insert Ada exception catchpoint in this configuration.^M
+ (gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error
+ ...
+
+ The test-case contains a require gnat_runtime_has_debug_info to deal with
+ this, but the problem is that this checks the static gnat runtime, while this
+ test-case uses the shared one.
+
+ Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that
+ one instead.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30094
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094
+
+2023-06-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Simplify tui_update_variables
+ Simplify tui_update_variables by using template function
+ assign_return_if_changed.
+
+ Tested on x86_64-linux.
+
+2023-06-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add template functions assign_return/set_if_changed
+ Add template functions assign_return_if_changed and assign_set_if_changed in
+ gdb/utils.h:
+ ...
+ template<typename T> void assign_set_if_changed (T &lval, const T &val, bool &changed)
+ { ... }
+ template<typename T> bool assign_return_if_changed (T &lval, const T &val)
+ { ... }
+ ...
+
+ This allows us to rewrite code like this:
+ ...
+ if (tui_border_attrs != entry->value)
+ {
+ tui_border_attrs = entry->value;
+ need_redraw = true;
+ }
+ ...
+ into this:
+ ...
+ need_redraw |= assign_return_if_changed<int> (tui_border_attrs, entry->value);
+ ...
+ or:
+ ...
+ assign_set_if_changed<int> (tui_border_attrs, entry->value, need_redraw);
+ ...
+
+ The names are a composition of the functionality. The functions:
+ - assign VAL to LVAL, and either
+ - return true if the assignment changed LVAL, or
+ - set CHANGED to true if the assignment changed LVAL.
+
+ Tested on x86_64-linux.
+
+2023-06-19 Andreas Schwab <schwab@suse.de>
+
+ riscv: Use run-time endianess for floating point literals
+ gas/
+ PR binutils/30551
+ * config/tc-riscv.c (md_atof): Use target_big_endian instead of
+ TARGET_BYTES_BIG_ENDIAN.
+ * testsuite/gas/riscv/float-be.d: New file.
+ * testsuite/gas/riscv/float-le.d: New file.
+ * testsuite/gas/riscv/float.s: New file.
+
+2023-06-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Clean standard_output_file dir in gdb_init
+ In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
+ gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
+ files at the start of the test-case:
+ ...
+ remote_file host delete [standard_output_file prog.o]
+ remote_file host delete [standard_output_file prog.ali]
+ ...
+
+ Replace this with cleaning up the entire directory instead, for all
+ test-cases.
+
+ Tested on x86_64-linux.
+
+ Suggested-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove f-string in gdb.python/py-unwind.py
+ on openSUSE Leap 42.3, with python 3.4, I run into a
+ "SyntaxError: invalid syntax" due to usage of an f-string in test-case
+ gdb.python/py-unwind.py.
+
+ Fix this by using string concatenation using '+' instead.
+
+ Tested on x86_64-linux.
+
+2023-06-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add nopie in a few test-cases
+ When running test-case gdb.arch/i386-disp-step.exp with target board
+ unix/-m32/-fPIE/-pie we run into:
+ ...
+ gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
+ ld: warning: creating DT_TEXTREL in a PIE
+ ...
+
+ Fix this by adding nopie in the compilation flags.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2023-06-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use require in gdb.dwarf2/implptr.exp
+ In test-case gdb.dwarf2/implptr.exp I noticed:
+ ...
+ } elseif {![is_x86_like_target]} {
+ # This test can only be run on x86 targets.
+ unsupported "needs x86-like target"
+ return 0
+ }
+ ...
+
+ Use instead "require is_x86_like_target".
+
+ Tested on x86_64-linux.
+
+2023-06-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp
+ Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
+ fine, but if we run it again with target board unix-m32, we run into:
+ ...
+ gnatlink prog.ali -m32 -g -o prog^M
+ ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
+ i386 output^M
+ ...
+
+ This is due to compiling with no-force.
+
+ The test-case:
+ - first compiles pck.adb into pck.o (without debug info), and
+ - then compiles prog.adb and pck.o into prog (with debug info).
+
+ Using no-force in the second compilation make sure that pck.adb is not
+ compiled again, with debug info.
+
+ But it also means it will pick up intermediate files related to prog.adb from
+ a previous compilation.
+
+ Fix this by removing prog.o and prog.ali before compilation.
+
+ Tested on x86_64-linux.
+
+2023-06-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use %progbits in gdb.arch/thumb*.S
+ In commit 0f2cd53cf4f ("[gdb/testsuite] Handle missing .note.GNU-stack") I
+ updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits,
+ but failed to do so for gdb.arch/thumb*.S. Fix this oversight.
+
+ Tested on arm-linux-gnueabihf.
+
+2023-06-16 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix ld "undefined reference" error with --enable-shared
+ Because _bfd_read_unsigned_leb128 is hidden visibility, so it can't
+ be referenced out of shared object.
+
+ The new function loongarch_get_uleb128_length just used to call
+ _bfd_read_unsigned_leb128.
+
+ bfd/ChangeLog:
+
+ * elfxx-loongarch.c (loongarch_get_uleb128_length): New function.
+ * elfxx-loongarch.h (loongarch_get_uleb128_length): New function.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c (md_apply_fix): Use
+ loongarch_get_uleb128_length.
+
+2023-06-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: update IRC reference from Freenode to Libera.Chat
+ It's been some time since the switch from Freenode to Libera.Chat,
+ however, there's still a reference to Freenode in the 'gdb --help'
+ output. Lets update that.
+
+2023-06-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: shrink Masking insn attribute to a single bit (boolean)
+ The logic can actually be expressed with less code that way, utilizing
+ that there are common patterns of when which form of masking is
+ permitted. This then also eliminates the large set of open-codings of
+ BOTH_MASKING in the opcode table.
+
+2023-06-16 Alan Modra <amodra@gmail.com>
+
+ Correct ld-elf/eh5 test for hppa64
+ Commit 3c0afdb78988 regressed this test for hppa64, because the test
+ had been enabled for hppa64 in the time between the mips changes and
+ their reversion. This patch isn't just a simple reapply, I recreated
+ the testsuite change by hand for hppa64: Two lines in eh5.d might need
+ further changes for mips.
+
+2023-06-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-15 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ binutils/NEWS: Mention Sony Allegrex MIPS CPU support
+ Mention the addition of Sony Allegrex processor support to the MIPS port.
+
+ binutils/
+ * NEWS: Mention Sony Allegrex MIPS CPU support.
+
+2023-06-15 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/GAS/testsuite: Fix `-modd-spreg'/`-mno-odd-spreg' test invocations
+ Reformat `-modd-spreg'/`-mno-odd-spreg' test invocations in mips.exp to
+ fit in 79 columns
+
+ gas/
+ * testsuite/gas/mips/mips.exp: Reformat
+ `-modd-spreg'/`-mno-odd-spreg' test invocations.
+
+2023-06-15 David Guillen Fandos <david@davidgf.net>
+
+ Add additional missing Allegrex CPU instructions
+ Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with
+ some encoding differences) such as bit manipulation (ins/ext) and MLA
+ (madd/msub). It also features some new instructions like wsbw and
+ min/max or device-specific ones such as mfic.
+
+ Add rotation instructions to MIPS Allegrex CPU
+ The Allegrex CPU supports bit rotation instructions as described in the
+ MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU).
+
+ Add MIPS Allegrex CPU as a MIPS2-based CPU
+ The Allegrex CPU was created by Sony Interactive Entertainment to power
+ their portable console, the PlayStation Portable.
+ The pspdev organization maintains all sorts of tools to create software
+ for said device including documentation.
+
+2023-06-15 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ GAS/doc: Correct Tag_GNU_MIPS_ABI_MSA attribute description
+ Rewrite the paragraph to match the style of Tag_GNU_MIPS_ABI_FP text
+ immediately above, correcting grammar and formatting at the same time.
+
+ gas/
+ * doc/as.texi (MIPS Attributes): Correct Tag_GNU_MIPS_ABI_MSA
+ attribute description.
+
+2023-06-15 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ Revert "MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit"
+ This reverts commit 094025a30bb2da19df3990e0c0ff8167af823aa1. It was
+ applied unapproved.
+
+ Revert "MIPS: default r6 if vendor is img"
+ This reverts commit be0d391f22fe6009c3be907753975a984cbbcc23. It was
+ applied unapproved.
+
+ Revert "MIPS: fix r6 testsuites"
+ This reverts commit ffc528aed56b9e2c171137da28690a9bb6861b0b. It was
+ applied unapproved.
+
+ Revert "MIPS: fix -gnuabi64 testsuite"
+ This reverts commit cb81e84c72933a7fad10b75b7e270d92d8d65251. It was
+ applied unapproved.
+
+ Revert "MIPS: fix some ld testcases with compiler"
+ This reverts commit a0631c1501c113c04891c9a24a9ff5276257f28d. It was
+ applied unapproved.
+
+ Revert "MIPS: add MT ASE support for micromips32"
+ This reverts commit acce83dacff0ce43677410c67aaae32817afe991. It was
+ applied unapproved.
+
+ Revert "MIPS: sync oprand char usage between mips and micromips"
+ This reverts commit 5b207b919483f67311a73dfc1de8897ecfd8e776. It was
+ applied unapproved.
+
+2023-06-15 Alan Modra <amodra@gmail.com>
+
+ Re: Add some expected failures for bfin linker tests
+ After commit 7ade0f1582c4 I was seeing bfin-elf +XPASS: weak symbols,
+ and on looking into the bfin targets a little, discovered we have two
+ bfin-linux targets. One, bfin-uclinux, is like bfin-elf in that
+ ld -m elf32bfin is the default, and the other, bfin-linux-uclibc where
+ ld -m elf32bfinfd is the default. So putting bfin-*-*linux* in test
+ xfails or elsewhere is wrong. We want bfin-*-linux* instead to just
+ select the fdpic bfin target.
+
+ This patch corrects wrong bfin target triples in the ld testsuite,
+ not just the recent change but others I'd added to xfails too.
+ It also fixes the bfin-linux-uclibc ld-elf/64ksec fail
+
+2023-06-15 Alan Modra <amodra@gmail.com>
+
+ vms write_archive memory leaks
+ This fixes two memory leaks in the vms archive handling.
+
+ * vms-lib.c (_bfd_vms_lib_build_map): Free input symbols.
+ (_bfd_vms_lib_write_archive_contents): Free archive map symbols.
+
+2023-06-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/step-over-exit.exp with glibc debuginfo
+ In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
+ continue, expecting to hit the breakpoint.
+
+ Without glibc debug info installed, we have with target board unix/-m64:
+ ...
+ Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
+ _exit () from /lib64/libc.so.6^M
+ (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
+ ...
+ and with target board unix/-m32:
+ ...
+ Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
+ /lib/libc.so.6^M
+ (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
+ ...
+
+ However after installing debug info (packages glibc-debuginfo and
+ glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
+ ...
+ Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
+ __GI__exit (status=<optimized out>) at \
+ ../sysdeps/unix/sysv/linux/_exit.c:27^M
+ 27 {^M
+ (gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
+ ...
+ and -m32 (note: _Exit instead of _exit):
+ ...
+ Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
+ ../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
+ 24 ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
+ (gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
+ ...
+
+ The gdb_test allows for both _exit and __GI__exit, but not _Exit:
+ ...
+ gdb_test "continue" \
+ "Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
+ "continue to exit"
+ ...
+
+ Fix this by allowing _Exit as well.
+
+ Tested on x86_64-linux.
+
+2023-06-14 Nick Clifton <nickc@redhat.com>
+
+ Add some expected failures for bfin linker tests
+
+ Add --remap-inputs option to the BFD linker.
+ PR 30374
+ * ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions.
+ * ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps.
+ * ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define.
+ * lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options.
+ * NEWS: Mention the new feature.
+ * ld.texi: Document the new options.
+ * testsuite/ld-misc/input-remap.exp: New test driver.
+ * testsuite/ld-misc/remaps.r: New file: Expected linker output.
+ * testsuite/ld-misc/remaps.txt: New file. Input remaps file.
+
+2023-06-14 Alan Modra <amodra@gmail.com>
+
+ asprintf memory leaks
+ A number of backends want to return bfd_reloc_dangerous messaqes from
+ relocation special_function, and construct the message using asprintf.
+ Such messages are not freed anywhere, leading to small memory leaks
+ inside libbfd. To limit the leaks, I'd implemented a static buffer in
+ the ppc backends that was freed before use in asprintf output. This
+ patch extends that scheme to other backends using a shared static
+ buffer and goes further in freeing the buffer on any bfd_close.
+
+ The patch also fixes a few other cases where asprintf output was not
+ freed after use.
+
+ bfd/
+ * bfd.c (_input_error_msg): Make global and rename to..
+ (_bfd_error_buf): ..this.
+ (bfd_asprintf): New function.
+ (bfd_errmsg): Use bfd_asprintf.
+ * opncls.c (bfd_close_all_done): Free _buf_error_buf.
+ * elf32-arm.c (find_thumb_glue, find_arm_glue): Use bfd_asprintf.
+ * elf32-nios2.c (nios2_elf32_relocate_section): Likewise.
+ * elf32-ppc.c (ppc_elf_unhandled_reloc): Likewise.
+ * elf64-ppc.c (ppc64_elf_unhandled_reloc): Likewise.
+ * elfnn-riscv.c (riscv_resolve_pcrel_lo_relocs): Likewise.
+ (riscv_elf_relocate_section): Likewise.
+ * libbfd.h: Regenerate.
+ gas/
+ * read.c (read_end): Free current_name and current_label.
+ (do_s_func): Likewise on error path. strdup label.
+ ld/
+ * pe-dll.c (make_head, make_tail, make_one),
+ (make_singleton_name_thunk, make_import_fixup_entry),
+ (make_runtime_pseudo_reloc),
+ (pe_create_runtime_relocator_reference: Free oname after use.
+
+2023-06-14 Alan Modra <amodra@gmail.com>
+
+ Re: bfd/elf.c strtab memory leak
+ There are other places that leak the strtab.
+
+ * elf.c (_bfd_elf_compute_section_file_positions): Free strtab
+ on error paths.
+
+2023-06-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/long-prompt.exp with read1
+ When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
+ ...
+ (gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
+ end of screen: at last line
+ ...
+
+ The problem is in these commands:
+ ...
+ Term::command "echo \\n"
+ Term::command "echo \\n"
+ Term::command "echo \\n"
+ Term::command "echo \\n"
+ ...
+
+ The last one makes the terminal scroll, and the scrolling makes the expected
+ output match on a different line.
+
+ Fix this by replacing the sequence with a single command:
+ ...
+ Term::command "echo \\n\\n\\n\\n\\n\\n"
+ ...
+ which avoids scrolling.
+
+ Tested on x86_64-linux.
+
+2023-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix and add prompt anchoring in tuiterm
+ There is a test-case that contains a unit test for tuiterm:
+ gdb.tui/tuiterm.exp.
+
+ However, this only excercises the tuiterm itself, and not the functions that
+ interact with it, like Term::command.
+
+ Add a new test-case gdb.tui/tuiterm-2.exp that:
+ - overrides proc accept_gdb_output (to be able simulate incorrect responses
+ while avoiding the timeout),
+ - overrides proc send_gdb (to be able to call Term::command without a gdb
+ instance, such that all tuiterm input is generated by the test-case).
+ - issues Term::command calls, and
+ - checks whether they behave correctly.
+
+ This exposes a problem in Term::command. The "prompt before command" regexp
+ starts with a bit that is supposed to anchor the prompt to the border:
+ ...
+ set str "(^|\|)$gdb_prompt $str"
+ ...
+ but that doesn't work due to insufficient escaping. Fix this by adding the
+ missing escape:
+ ...
+ set str "(^|\\|)$gdb_prompt $str"
+ ...
+
+ Futhermore, the "prompt after command" regexp in Term::wait_for has no
+ anchoring at all:
+ ...
+ set prompt_wait_for "$gdb_prompt \$"
+ ...
+ so add that as well.
+
+ Tested on x86_64-linux.
+
+2023-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow procs with default value args in with_override
+ Currently proc with_override does not work with procs with default value args.
+
+ Fix this, and add a test-case excercising this scenario.
+
+ Tested on x86_64-linux.
+
+2023-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dap/type_check.exp with older python
+ On openSUSE Leap 15.4 with system python 3.6, I run into:
+ ...
+ (gdb) python check_everything()^M
+ (gdb) FAIL: gdb.dap/type_check.exp: type checker
+ ...
+
+ In check_everything, the hasattr test fails silently:
+ ...
+ def check_everything():
+ # Older versions of Python can't really implement this.
+ if hasattr(typing, "get_origin"):
+ ...
+ and that makes the gdb_test in the test-case fail.
+
+ Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
+ this in the test-case.
+
+ Tested on x86_64-linux.
+
+2023-06-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: use proper int size for gdb.dwarf2/symbol_needs_eval*.exp
+ We recently realized that symbol_needs_eval_fail.exp and
+ symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
+ x86_64) by reading 8 bytes (the size of a pointer).
+
+ Here how it goes:
+
+ In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
+ defined:
+
+ int exec_mask = 1;
+
+ and later both tests build some DWARF using the assembler doing:
+
+ set exec_mask_var [gdb_target_symbol exec_mask]
+ ...
+ DW_TAG_variable {
+ {DW_AT_name a}
+ {DW_AT_type :$int_type_label}
+ {DW_AT_location {
+ DW_OP_addr $exec_mask_var
+ DW_OP_deref
+ ...
+ }
+ }
+
+ The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
+ says that "The size of the data retrieved from the dereferenced address
+ is the size of an address on the target machine."
+
+ On x86_64, the size of an int is 4 while the size of an address is 8.
+ The result is that when evaluating this expression, the debugger reads
+ outside of the `a` variable.
+
+ Fix this by using `DW_OP_deref_size $int_size` instead. To achieve
+ this, this patch adds the necessary steps so we can figure out what
+ `sizeof(int)` evaluates to for the current target.
+
+ While at it, also change the definition of the int type in the assembled
+ DWARF information so we use the actual target's size for an int instead
+ of the literal 4.
+
+ Tested on x86_64 Linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-06-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-13 Kevin Buettner <kevinb@redhat.com>
+
+ Simplify case DW_OP_GNU_uninit in dwarf_expr_context::execute_stack_op
+ Tom Tromey pointed out that the test and call to error() for the
+ DW_OP_GNU_uninit case in dwarf_expr_context::execute_stack_op (in
+ gdb/dwarf2/expr.c)...
+
+ if (op_ptr != op_end && *op_ptr != DW_OP_piece
+ && *op_ptr != DW_OP_bit_piece)
+ error (_("DWARF-2 expression error: DW_OP_GNU_uninit must always "
+ "be the very last op in a DWARF expression or "
+ "DW_OP_piece/DW_OP_bit_piece piece."));
+
+ ...could be replaced by a call to dwarf_expr_require_composition which
+ performs a similar check and outputs a suitable error message.
+
+2023-06-12 Simon Farre <simon.farre.cx@gmail.com>
+
+ Added self to W.A.A. maintainers
+
+2023-06-12 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb/testsuite: Testing with the armflang compiler
+ Currently the Fortran test suite does not run with armflang because the
+ compiler detection fails. This in turn means fortran_runto_main does not
+ know which main method to use to start a test case.
+
+ Fortran compiler detection was added in 44d469c5f85; however, the commit
+ message notes that it was not tested with armflang.
+
+ This commit tests and fixes up a minor issue to get the detection
+ working.
+
+ The goal here is to get the tests running and preventing further
+ regressions during future work. This change does not do anything to fix
+ existing failures.
+
+ >From what I can understand, the auto detection leverages the
+ preprocessor to extract the Fortran compiler identity from the defines.
+ This preprocessor output is then evaluated by the test suite to import
+ these defines.
+
+ In the case of armflang, this evaluation step is disrupted by the
+ presence of the following warning:
+
+ $ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
+ $ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
+
+ The evaluation logic is already set up to filter this warning, but the
+ prefix differs.
+
+ This commit fixes the issue by updating the filter to exclude the
+ armflang flavour of warning.
+
+ gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
+ regressions detected.
+
+ The gdb.fortran test results with ACfL 23.04.1 are as follows.
+
+ Before:
+
+ # of expected passes 560
+ # of unexpected failures 113
+ # of unresolved testcases 2
+ # of untested testcases 5
+ # of duplicate test names 2
+
+ After:
+
+ # of expected passes 5388
+ # of unexpected failures 628
+ # of known failures 10
+ # of untested testcases 8
+ # of unsupported tests 5
+ # of duplicate test names 5
+
+ As can be seen from the above, there are now considerably more passing
+ assertions.
+
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Remove f-strings from DAP
+ Kévin pointed out that gdb claims a minimum Python version of 3.2, but
+ the DAP code uses f-strings, which were added in 3.6.
+
+ This patch removes the uses of f-strings from the DAP code. I can't
+ test an older version of Python, but I did confirm that this still
+ works with the version I have.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP conditional breakpoints
+ I realized that I had only implemented DAP breakpoint conditions for
+ exception breakpoints, and not other kinds of breakpoints. This patch
+ corrects the oversight.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Do not report totalFrames from DAP stackTrace request
+ Currently, gdb will unwind the entire stack in response to the
+ stackTrace request. I had erroneously thought that the totalFrames
+ attribute was required in the response. However, the spec says:
+
+ If omitted or if `totalFrames` is larger than the available
+ frames, a client is expected to request frames until a request
+ returns less frames than requested (which indicates the end of the
+ stack).
+
+ This patch removes this from the response in order to improve
+ performance when the stack trace is very long.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP breakpointLocations request
+ This implements the DAP breakpointLocations request.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Add "stop at main" extension to DAP launch request
+ Co-workers who work on a program that uses DAP asked for the ability
+ to have gdb stop at the main subprogram when launching. This patch
+ implements this extension.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Add "target" parameter to DAP attach request
+ This adds a new "target" to the DAP attach request. This is passed to
+ "target remote". I thought "attach" made the most sense for this,
+ because in some sense gdb is attaching to a running process. It's
+ worth noting that all DAP "attach" parameters are defined by the
+ implementation.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Handle DAP supportsVariableType capability
+ A DAP client can report the supportsVariableType capability in the
+ initialize request. In this case, gdb can include the type of a
+ variable or expression in various results.
+
+ Implement DAP setExpression request
+ This implements the DAP setExpression request.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.Value.assign method
+ This adds an 'assign' method to gdb.Value. This allows for assignment
+ without requiring the use of parse_and_eval.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Add type-checking to DAP requests
+ It occurred to me recently that gdb's DAP implementation should
+ probably check the types of objects coming from the client. This
+ patch implements this idea by reusing Python's existing type
+ annotations, and supplying a decorator that verifies these at runtime.
+
+ Python doesn't make it very easy to do runtime type-checking, so the
+ core of the checker is written by hand. I haven't tried to make a
+ fully generic runtime type checker. Instead, this only checks the
+ subset that is needed by DAP. For example, only keyword-only
+ functions are handled.
+
+ Furthermore, in a few spots, it wasn't convenient to spell out the
+ type that is accepted. I've added a couple of comments to this effect
+ in breakpoint.py.
+
+ I've tried to make this code compatible with older versions of Python,
+ but I've only been able to try it with 3.9 and 3.10.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Use tuples for default arguments in DAP
+ My co-worker Kévin taught me that using a mutable object as a default
+ argument in Python is somewhat dangerous, because the object is
+ created a single time (when the function is defined), and so if it is
+ mutated in the body of the function, the changes will stick around.
+
+ This patch changes the cases like this in DAP to use () rather than []
+ as the default. This patch is merely preventative, as no bugs like
+ this are in the code.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Fix a latent bug in DAP request decorator
+ The 'request' decorator is intended to also ensure that the request
+ function runs in the DAP thread. However, the unwrapped function is
+ installed in the global request map, so the wrapped version is never
+ called. This patch fixes the bug.
+
+ Add test for DAP pause request
+ I neglected to write a test for the DAP "pause" request. This patch
+ adds one.
+
+ Rename one DAP function
+ When I first started implementing DAP, I had some vague plan of having
+ the implementation functions use the same name as the request. I
+ abandoned this idea, but one vestige remained. This patch renames the
+ one remaining function to be gdb-ish.
+
+ Add singleThread support to some DAP requests
+ A few DAP requests support a "singleThread" parameter, which is
+ somewhat similar to scheduler-locking. This patch implements support
+ for this.
+
+ Implement DAP stepOut request
+ This implements the DAP "stepOut" request.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP attach request
+ This implements the DAP "attach" request.
+
+ Note that the copyright dates on the new test source file are not
+ incorrect -- this was copied verbatim from another directory.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP setExceptionBreakpoints request
+ This implements the DAP setExceptionBreakpoints request for Ada. This
+ is a somewhat minimal implementation, in that "exceptionOptions" are
+ not implemented (or advertised) -- I wasn't completely sure how this
+ feature is supposed to work.
+
+ I haven't added C++ exception handling here, but it's easy to do if
+ needed.
+
+ This patch relies on the new MI command execution support to do its
+ work.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Don't require inferior execution for Ada catchpoints
+ Currently, Ada catchpoints require that the inferior be running.
+ However, there's no deep reason for this -- for example, C++ exception
+ catchpoints do not have this requirement. Instead, those work like
+ ordinary breakpoints: they are pending until the needed runtime
+ locations are seen.
+
+ This patch changes Ada catchpoints to work the same way.
+
+2023-06-12 Tom Tromey <tromey@adacore.com>
+
+ Mark members of ada_catchpoint "private"
+ This changes the members of ada_catchpoint to be private.
+
+ Turn should_stop_exception into a method of ada_catchpoint
+ This turns the should_stop_exception function in ada-lang.c into a
+ method of ada_catchpoint.
+
+ Combine create_excep_cond_exprs and ada_catchpoint::re_set
+ This patch merges create_excep_cond_exprs into ada_catchpoint::re_set.
+ This is less verbose and is also a step toward making ada_catchpoint
+ work more like the other code_breakpoint-based exception catchpoints.
+
+ Transfer ownership of exception string to ada_catchpoint
+ This changes the ada_catchpoint to require an rvalue ref, so that
+ ownership of the exception string can be transferred to the catchpoint
+ object.
+
+ Pass tempflag to ada_catchpoint constructor
+ This is a minor cleanup to pass tempflag to the ada_catchpoint
+ constructor.
+
+ Use gnat_runtime_has_debug_info in Ada catchpoint tests
+ This changes the Ada catchpoint tests to use
+ gnat_runtime_has_debug_info. This simplifies the code.
+
+ Stop gdb in gnat_runtime_has_debug_info
+ gnat_runtime_has_debug_info starts a new gdb to do its work. However,
+ it also leaves this gdb running, which can potentially confuse the
+ calling test -- I encountered this when writing a new DAP test. This
+ patch changes the proc to shut down gdb.
+
+2023-06-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Relax breakpoint count check in gdb.python/py-rbreak.exp
+ With a gdb 13.2 based package on SLE-15 aarch64, I run into:
+ ...
+ (gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary
+ py sl = gdb.rbreak("^[^_]",minsyms=False)^M
+ Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M
+ ...
+ (gdb) py print(len(sl))^M
+ 12^M
+ (gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
+ ...
+
+ The FAIL is due to:
+ - the glibc object crti.o containing debug information for function
+ call_weak_fn, and
+ - the test-case not expecting this.
+
+ The debug information is there due to compiling glibc using a binutils which
+ contains commit 591cc9fbbfd ("gas/Dwarf: record functions").
+
+ I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite]
+ Fix regexp in py-rbreak.exp").
+
+ The fix I applied there was to use a regexp "^[^_]" to filter out
+ __libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn.
+
+ Fix this by:
+ - reverting the regexp to "", and
+ - rewriting the check to require at least 11 functions, rather than a precise
+ match.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30538
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30538
+
+2023-06-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix breakpoint regexp in gdb.ada/out_of_line_in_inlined.exp
+ With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
+ ...
+ (gdb) run ^M
+ Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib/libthread_db.so.1".^M
+ ^M
+ Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
+ 26 for C of S loop^M
+ (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
+ run to foo_o224_021.child1.child2
+ ...
+
+ I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
+ instead of optimize=-O2.
+
+ Fix this by using $bkptno_num_re.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30539
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539
+
+2023-06-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Replace macro HELP_ATTRIBUTE_MODE with std::string
+ Replace macro HELP_ATTRIBUTE_MODE with a std::string.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-12 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Relocations simplification when -mno-relax
+ Gas does not emit ADD/SUB relocation pairs for label differences
+ when -mno-relax.
+
+2023-06-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-11 Kevin Buettner <kevinb@redhat.com>
+
+ Permit DW_OP_GNU_uninit to be used with DW_OP_piece
+ This commit implements a fix for a bug reported against GDB on
+ Fedora bugzilla...
+
+ https://bugzilla.redhat.com/show_bug.cgi?id=2166796
+
+ The test case in that bug report involved running gdb against the 'jq'
+ program (which is a command-line JSON processor) on Fedora 37. Since
+ the debug info is compiler (and compile-time option) dependent, it
+ won't necessarily show up in other distributions or even past or
+ future versions of Fedora. (E.g. when trying the example shown below
+ on Fedora 38, GDB says that the value of 'value' has been optimized
+ out. I.e. it does not demonstrate the same DWARF error that can be
+ see when using Fedora 37.)
+
+ That said, on Fedora 37, the bug could be reproduced as follows:
+
+ [kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null'
+ Reading symbols from jq...
+
+ This GDB supports auto-downloading debuginfo from the following URLs:
+ <https://debuginfod.fedoraproject.org/>
+ Enable debuginfod for this session? (y or [n]) y
+ Debuginfod has been enabled.
+ To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
+ Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
+ No source file named src/util.c.
+ Make breakpoint pending on future shared library load? (y or [n]) y
+ Breakpoint 1 (src/util.c:415) pending.
+ Starting program: /usr/bin/jq </dev/null
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib64/libthread_db.so.1".
+
+ Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
+ 416 if (state->parser == NULL) {
+ (gdb) p value
+ DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.
+
+ This is undesirable - rather than output an error about the DWARF
+ info, we'd prefer to see a value, even if it is uninitialized.
+
+ Examination of the debuginfo showed the following:
+
+ <1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
+ <468f2> DW_AT_external : 1
+ <468f2> DW_AT_name : (indirect string, offset: 0x4781): jq_util_input_next_input
+ <468f6> DW_AT_decl_file : 10
+ <468f6> DW_AT_decl_line : 411
+ <468f8> DW_AT_decl_column : 4
+ <468f9> DW_AT_prototyped : 1
+ <468f9> DW_AT_type : <0x3f2>
+ <468fd> DW_AT_sibling : <0x4692e>
+ ...
+ <2><46921>: Abbrev Number: 102 (DW_TAG_variable)
+ <46922> DW_AT_name : (indirect string, offset: 0x8cb): value
+ <46926> DW_AT_decl_file : 10
+ <46926> DW_AT_decl_line : 414
+ <46928> DW_AT_decl_column : 6
+ <46929> DW_AT_type : <0x3f2>
+
+ Note that there's no DW_AT_location, so I looked for an abstract origin entry:
+
+ <2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
+ <2dfa1> DW_AT_abstract_origin: <0x46921>
+ <2dfa5> DW_AT_location : 0x27cf1 (location list)
+ <2dfa9> DW_AT_GNU_locviews: 0x27ce1
+
+ (Note that the DW_AT_abstract_origin attribute's value is 0x46921 which
+ is the DIE for the local variable "value".)
+
+ Looking at the location list, I see:
+
+ 00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
+ 000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)
+
+ While DW_OP_GNU_uninit is not the very last op, it is the last op
+ prior to DW_OP_piece. The fix involved changing the DW_OP_GNU_uninit
+ case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
+ that DW_OP_GNU_uninit may appear just before DW_OP_piece.
+
+ With the fix in place, attempting to print 'value' now looks like
+ this:
+
+ (gdb) p value
+ $1 = [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
+ size = 0, u = {ptr = 0x0, number = 0}}
+
+ Note that "[uninitialized]" is part of the output. (But also note
+ that there's an extra space character.)
+
+ I've made a new test case,
+ gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
+ existing one, gdb.dwarf2/opt-out-not-implptr.exp. Since it uses the
+ DWARF assembler, the test case does not depend on a specific compiler
+ version or compiler options.
+
+ Tested on Fedora 37 and Fedora 38.
+
+2023-06-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: testsuite: add sframe_find_fre tests for pltN entries
+ Add a new test plt-findfre-1 to ensure lookup of SFrame stack trace
+ information for pltN entries is correct.
+
+ In this test, a dummy SFrame FDE of type SFRAME_FDE_TYPE_PCMASK is
+ created. The size of the 'function code block' covered by the SFrame
+ FDE is equivalent to 5 pltN entries of 16 bytes each.
+
+ The test first looks up SFrame FREs for some addresses in the first pltN
+ entry, followed by lookups for some addresses in the fourth pltN entry.
+
+ libsframe/
+ * Makefile.in: Regenerated.
+ * testsuite/libsframe.find/find.exp: Add new test.
+ * testsuite/libsframe.find/local.mk: Likewise.
+ * testsuite/libsframe.find/plt-findfre-1.c: New test.
+
+2023-06-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: fix sframe_find_fre for pltN entries
+ To find SFrame stack trace information from an FDE of type
+ SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
+ like,
+ (start_ip_offset & 0xff) >= (pc & 0xff), etc.
+
+ This is buggy and needs correction. The mask 0xff should be 0xf (to
+ work for a pltN entry of size say, 16 bytes).
+
+ At this time, the size of the pltN entry is implicitly assumed to be 16
+ bytes by libsframe. In next version of the SFrame format, we can encode
+ this information explicitly in the SFrame FDE.
+
+ For now, we should fix the code to at least behave correctly for the
+ generated code and the generated SFrame stack trace information for the
+ pltN entries on x86_64.
+
+ libsframe/
+ * sframe.c (sframe_find_fre): Correct the bitmask used for
+ SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.
+
+2023-06-09 Luis Machado <luis.machado@arm.com>
+
+ [AArch64,arm] Fix some formatting issues in the aarch64/arm codebase
+ As noted by Tom Tromey, there are some formatting issues with the ternary
+ operator in the aarch64/arm codebase. This patch fixes those.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Simplify tui_puts_internal
+ Simplify tui_puts_internal by using continue, as per this [1] coding standard
+ rule, making the function more readable and easier to understand.
+
+ No functional changes.
+
+ Tested on x86_64-linux.
+
+ [1] https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Delete line buffer when switching to singlekey
+ Say we're in TUI mode, and type "sun":
+ ...
+ (gdb) sun
+ ...
+
+ After switching to SingleKey mode using C-x s, we have just:
+ ...
+ sun
+ ...
+
+ After typing "d", we get:
+ ...
+ sun
+ Undefined command: "sundown". Try "help".
+ ...
+
+ The SingleKey "d" is supposed run the "down" command.
+
+ Fix this by clearing the readline line buffer when switching to SingleKey
+ mode.
+
+ Tested on x86_64-linux.
+
+ PR tui/30522
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add test-case gdb.tui/single-key.exp
+ I noticed that there's no test-case excercising SingleKey mode, so add a test-case.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/debuginfod: cleanup debuginfod earlier
+ A GDB crash was discovered on Fedora GDB that was tracked back to an
+ issue with the way that debuginfod is cleaned up.
+
+ The bug was reported on Fedora 37, 38, and 39. Here are the steps to
+ reproduce:
+
+ 1. The file /etc/ssl/openssl.cnf contains the following lines:
+
+ [provider_sect]
+ default = default_sect
+ ##legacy = legacy_sect
+ ##
+ [default_sect]
+ activate = 1
+
+ ##[legacy_sect]
+ ##activate = 1
+
+ The bug will occur when the '##' characters are removed so that the
+ lines in question look like this:
+
+ [provider_sect]
+ default = default_sect
+ legacy = legacy_sect
+
+ [default_sect]
+ activate = 1
+
+ [legacy_sect]
+ activate = 1
+
+ 2. Clean up any existing debuginfod cache data:
+
+ > rm -rf $HOME/.cache/debuginfod_client
+
+ 3. Run GDB:
+
+ > gdb -nx -q -iex 'set trace-commands on' \
+ -iex 'set debuginfod enabled on' \
+ -iex 'set confirm off' \
+ -ex 'start' -ex 'quit' /bin/ls
+ +set debuginfod enabled on
+ +set confirm off
+ Reading symbols from /bin/ls...
+ Downloading separate debug info for /usr/bin/ls
+ ... snip ...
+ Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde38) at ../src/ls.c:1646
+ 1646 {
+ +quit
+
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ ... snip ...
+
+ So GDB ends up crashing during exit.
+
+ What's happening is that when debuginfod is initialised
+ debuginfod_begin is called (this is in the debuginfod library), this
+ in turn sets up libcurl, which makes use of openssl. Somewhere during
+ this setup process an at_exit function is registered to cleanup some
+ state.
+
+ Back in GDB the debuginfod_client object is managed using this code:
+
+ /* Deleter for a debuginfod_client. */
+
+ struct debuginfod_client_deleter
+ {
+ void operator() (debuginfod_client *c)
+ {
+ debuginfod_end (c);
+ }
+ };
+
+ using debuginfod_client_up
+ = std::unique_ptr<debuginfod_client, debuginfod_client_deleter>;
+
+ And then a global debuginfod_client_up is created to hold a pointer to
+ the debuginfod_client object. As a global this will be cleaned up
+ using the standard C++ global object destructor mechanism, which is
+ run after the at_exit handlers.
+
+ However, it is expected that when debuginfod_end is called the
+ debuginfod_client object will still be in a usable state, that is, we
+ don't expect the at_exit handlers to have run and started cleaning up
+ the library state.
+
+ To fix this issue we need to ensure that debuginfod_end is called
+ before the at_exit handlers have a chance to run.
+
+ This commit removes the debuginfod_client_up type, and instead has GDB
+ hold a raw pointer to the debuginfod_client object. We then make use
+ of GDB's make_final_cleanup to register a function that will call
+ debuginfod_end.
+
+ As GDB's final cleanups are called before exit is called, this means
+ that debuginfod_end will be called before the at_exit handlers are
+ called, and the crash identified above is resolved.
+
+ It's not obvious how this issue can easily be tested for. The bug does
+ not appear to manifest when using a local debuginfod server, so we'd
+ need to setup something more involved. For now I'm proposing this
+ patch without any associated tests.
+
+ Co-Authored-By: Mark Wielaard <mark@klomp.org>
+ Co-Authored-By: Simon Marchi <simark@simark.ca>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Aaron Merey <amerey@redhat.com>
+
+2023-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix ASan failure after recent string changes
+ After this commit:
+
+ commit baab375361c365afee2577c94cbbd3fdd443d6da
+ Date: Tue Jul 13 14:44:27 2021 -0400
+
+ gdb: building inferior strings from within GDB
+
+ It was pointed out that a new ASan failure had been introduced which
+ was triggered by gdb.base/internal-string-values.exp:
+
+ (gdb) PASS: gdb.base/internal-string-values.exp: test_setting: all langs: lang=ada: ptype "foo"
+ print $_gdb_maint_setting("test-settings string")
+ =================================================================
+ ==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba682 bp 0x7ffd20644620 sp 0x7ffd20644610
+ READ of size 1 at 0x603000068034 thread T0
+ #0 0x564785cba681 in find_command_name_length(char const*) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2129
+ #1 0x564785cbacb2 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2186
+ #2 0x564785cbb539 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2248
+ #3 0x564785cbbcf3 in lookup_cmd(char const**, cmd_list_element*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2339
+ #4 0x564785c82df2 in setting_cmd /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2219
+ #5 0x564785c84274 in gdb_maint_setting_internal_fn /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2348
+ #6 0x564788167b3b in call_internal_function(gdbarch*, language_defn const*, value*, int, value**) /tmp/src/binutils-gdb/gdb/value.c:2321
+ #7 0x5647854b6ebd in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11254
+ #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
+ #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
+ #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
+ #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
+ #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
+ #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
+ #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
+ #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
+ #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
+ #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
+ #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
+ #20 0x564786683dea in gdb_rl_callback_read_char_wrapper_noexcept /tmp/src/binutils-gdb/gdb/event-top.c:192
+ #21 0x564786684042 in gdb_rl_callback_read_char_wrapper /tmp/src/binutils-gdb/gdb/event-top.c:225
+ #22 0x564787f1b119 in stdin_event_handler /tmp/src/binutils-gdb/gdb/ui.c:155
+ #23 0x56478862438d in handle_file_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:573
+ #24 0x564788624d23 in gdb_wait_for_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:694
+ #25 0x56478862297c in gdb_do_one_event(int) /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:264
+ #26 0x564786df99f0 in start_event_loop /tmp/src/binutils-gdb/gdb/main.c:412
+ #27 0x564786dfa069 in captured_command_loop /tmp/src/binutils-gdb/gdb/main.c:476
+ #28 0x564786dff61f in captured_main /tmp/src/binutils-gdb/gdb/main.c:1320
+ #29 0x564786dff75c in gdb_main(captured_main_args*) /tmp/src/binutils-gdb/gdb/main.c:1339
+ #30 0x564785381b6d in main /tmp/src/binutils-gdb/gdb/gdb.c:32
+ #31 0x7f4efbc3984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
+ #32 0x7f4efbc39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
+ #33 0x564785381934 in _start (/tmp/build/binutils-gdb/gdb/gdb+0xabc5934) (BuildId: 90de353ac158646e7dab501b76a18a76628fca33)
+
+ 0x603000068034 is located 0 bytes after 20-byte region [0x603000068020,0x603000068034) allocated by thread T0 here:
+ #0 0x7f4efcee0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
+ #1 0x5647856265d8 in xcalloc /tmp/src/binutils-gdb/gdb/alloc.c:97
+ #2 0x564788610c6b in xzalloc(unsigned long) /tmp/src/binutils-gdb/gdbsupport/common-utils.cc:29
+ #3 0x56478815721a in value::allocate_contents(bool) /tmp/src/binutils-gdb/gdb/value.c:929
+ #4 0x564788157285 in value::allocate(type*, bool) /tmp/src/binutils-gdb/gdb/value.c:941
+ #5 0x56478815733a in value::allocate(type*) /tmp/src/binutils-gdb/gdb/value.c:951
+ #6 0x5647854ae81c in expr::ada_string_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:10675
+ #7 0x5647854b63b8 in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11184
+ #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
+ #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
+ #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
+ #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
+ #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
+ #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
+ #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
+ #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
+ #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
+ #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
+ #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
+
+ The problem is in cli/cli-cmds.c, in the function setting_cmd, where
+ we do this:
+
+ const char *a0 = (const char *) argv[0]->contents ().data ();
+
+ Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or
+ a TYPE_CODE_STRING. The problem is that the above line is casting the
+ value contents directly to a C-string, i.e. one that is assumed to
+ have a null-terminator at the end.
+
+ After the above commit this can no longer be assumed to be true. A
+ string value will be represented just as it would be in the current
+ language, so for Ada and Fortran the string will be an array of
+ characters with no null-terminator at the end.
+
+ My proposed solution is to copy the string contents into a std::string
+ object, and then use the std::string::c_str() value, this will ensure
+ that a null-terminator has been added.
+
+ I had a check through GDB at places TYPE_CODE_STRING was used and
+ couldn't see any other obvious places where this type of assumption
+ was being made, so hopefully this is the only offender.
+
+ Running the above test with ASan compiled in no longer gives an error.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-09 Tom Tromey <tromey@adacore.com>
+
+ Use scoped_value_mark in two more places
+ I found a couple of spots that could use scoped_value_mark. One of
+ them is a spot that didn't consider the possibility that value_mark
+ can return NULL. I tend to doubt this can be seen in this context,
+ but nevertheless this is safer.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-06-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix typos
+ Fix typos:
+ - reponse -> response
+ - inital -> initial
+ - a -> an
+
+2023-06-09 Alan Modra <amodra@gmail.com>
+
+ readelf/objdump remember_state memory leaks
+ * dwarf.c (display_debug_frames <DW_CFA_restore_state>): Do free
+ invalid remember_state.
+
+2023-06-09 Alan Modra <amodra@gmail.com>
+
+ ecoff find_nearest_line and final link leaks
+ Freeing ecoff_debug_info "pointers to the unswapped symbolic info"
+ isn't a simple matter, due to differing allocation strategies. In
+ _bfd_ecoff_slurp_symbolic_info the pointers are to objalloc memory.
+ In the ecoff linker they are to separately malloc'd memory. In gas we
+ have most (obj-elf) or all (obj-ecoff) into a single malloc'd buffer.
+
+ This patch fixes the leaks for binutils and ld, leaving the gas leaks
+ for another day. The mips elf backend already had this covered, and
+ the ecoff backend had a pointer, raw_syments used as a flag, so most
+ of the patch is moving these around a little so they are accessible
+ for both ecoff and elf.
+
+ include/
+ * coff/ecoff.h (struct ecoff_debug_info): Add alloc_syments.
+ bfd/
+ * libecoff.h (struct ecoff_tdata): Delete raw_syments.
+ * elfxx-mips.c (free_ecoff_debug): Delete. Replace uses with
+ _bfd_ecoff_free_ecoff_debug_info.
+ (_bfd_mips_elf_final_link): Init debug.alloc_syments.
+ * ecofflink.c (_bfd_ecoff_free_ecoff_debug_info): New function.
+ * ecoff.c (_bfd_ecoff_bfd_free_cached_info): Call
+ _bfd_ecoff_free_ecoff_debug_info.
+ (_bfd_ecoff_slurp_symbolic_info): Replace uses of raw_syments
+ with alloc_syments.
+ (ecoff_final_link_debug_accumulate): Likewise. Use
+ _bfd_ecoff_free_ecoff_debug_info.
+ (_bfd_ecoff_bfd_copy_private_bfd_data): Set alloc_syments for
+ copied output.
+ * elf64-alpha.c (elf64_alpha_read_ecoff_info): Use
+ _bfd_ecoff_free_ecoff_debug_info.
+ * libbfd-in.h (_bfd_ecoff_free_ecoff_debug_info): Declare.
+ * libbfd.h: Regenerate.
+ gas/
+ * config/obj-ecoff.c (ecoff_frob_file): Set alloc_syments.
+ * config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
+
+2023-06-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add test-case gdb.tui/long-prompt.exp
+ I noticed that the test-suite doesn't excercise the case in
+ tui_redisplay_readline that height (initially 1) is changed by this call:
+ ...
+ tui_puts_internal (w, prompt, &height);
+ ...
+
+ Add a test-case that excercises this.
+
+ Tested on x86_64-linux.
+
+2023-06-08 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/corelow.c: do not try to reopen a file if open failed once
+ In the current implementation, core_target::build_file_mappings will try
+ to locate and open files which were mapped in the process for which the
+ core dump was produced. If the file cannot be found or cannot be
+ opened, GDB will re-try to open it once for each time it was mapped in
+ the process's address space.
+
+ This patch makes it so GDB recognizes that it has already failed to open
+ a given file once and does not re-try the process for each mapping.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-06-08 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/corelow.c: avoid repeated warnings in build_file_mappings
+ When GDB opens a coredump it tries to locate and then open all files
+ which were mapped in the process.
+
+ If a file is found but cannot be opened with BFD (bfd_open /
+ bfd_check_format fails), then a warning is printed to the user. If the
+ same file was mapped multiple times in the process's address space, the
+ warning is printed once for each time the file was mapped. I find this
+ un-necessarily noisy.
+
+ This patch makes it so the warning message is printed only once per
+ file.
+
+ There was a comment in the code assuming that if the file was found on
+ the system, opening it (bfd_open + bfd_check_format) should always
+ succeed. A recent change in BFD (014a602b86f "Don't optimise bfd_seek
+ to same position") showed that this assumption is not valid. For
+ example, it is possible to have a core dump of a process which had
+ mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In
+ such case the core dump does contain the information that portions of
+ this special file were mapped in the host process, but trying to seek to
+ position 0 will fail, making bfd_check_format fail. This patch removes
+ this comment.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-06-08 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/corelow.c: fix use-after-free in build_file_mappings
+ In core_target::build_file_mappings, GDB tries to open files referenced
+ in the core dump.
+
+ The process goes like this:
+
+ struct bfd *bfd = bfd_map[filename];
+ if (bfd == nullptr)
+ {
+ bfd = bfd_map[filename]
+ = bfd_openr (expanded_fname.get (), "binary");
+ if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
+ {
+ if (bfd != nullptr)
+ bfd_close (bfd);
+ return;
+ }
+ }
+ asection *sec = bfd_make_section_anyway (bfd, "load");
+ ...
+
+ The problem is that if bfd_check_format fails, we close the bfd but keep
+ a reference to it in the bfd_map.
+
+ If the same filename appears another time in the NT_FILE note, we enter
+ this code again. The second time, bfd_map[filename] is not nullptr and
+ we try to call bfd_make_section_anyway on an already closed BFD, which
+ is a use-after-free error.
+
+ This patch makes sure that the bfd is only saved in the bfd_map if it
+ got opened successfully.
+
+ This error got exposed by a recent change in BFD (014a602b86f "Don't
+ optimise bfd_seek to same position"). Since this change, opening a
+ coredump which contains mapping to some special files such as a DRI
+ render node (/dev/dri/renderD$NUM) exposes the issue. This happens for
+ example for processes using AMDGPU devices to offload compute tasks.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-06-08 Alan Modra <amodra@gmail.com>
+
+ Re: _bfd_free_cached_info
+ Oops, another leak caused by not defining the correct macro.
+
+ * elf32-mips.c: Define bfd_elf32_bfd_free_cached_info.
+ * elfn32-mips.c: Likewise.
+ * elf64-mips.c: Define bfd_elf64_bfd_free_cached_info.
+
+2023-06-08 Alan Modra <amodra@gmail.com>
+
+ Re: _bfd_free_cached_info
+ ELF targets with target-specific free_cache_info functions need to
+ call _bfd_elf_free_cached_info, not _bfd_generic_bfd_free_cached_info.
+
+ * elf64-ppc.c (ppc64_elf_free_cached_info): Call
+ _bfd_elf_free_cached_info.
+ * elfnn-aarch64.c (elfNN_aarch64_bfd_free_cached_info): Likewise.
+
+2023-06-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-07 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: reuse static function sframe_decoder_get_funcdesc_at_index
+ sframe_decoder_get_funcdesc_at_index () is the function to access SFrame
+ FDEs in the SFrame decoder context. Use it consistently.
+
+ Avoid unnecessary type cast and include minor enhancements as the code
+ is moved around.
+
+ libsframe/
+ * sframe.c (sframe_decoder_get_funcdesc_at_index): Move some
+ checks here. Move the static function definition before the new
+ use.
+ (sframe_decoder_get_funcdesc): Use
+ sframe_decoder_get_funcdesc_at_index instead.
+
+2023-06-07 Tom Tromey <tromey@adacore.com>
+
+ Simplify ada_lookup_struct_elt_type
+ This patch simplifies ada_lookup_struct_elt_type by changing it to
+ call find_struct_field. The two functions were substantially similar,
+ even to the point of having identical comments.
+
+ I tested this using both the gdb test suite and the internal AdaCore
+ test suite. Given this and the fact that it is Ada-specific, I am
+ checking it in.
+
+2023-06-07 Nick Clifton <nickc@redhat.com>
+
+ Add extra linker warning message about discrepancies between normal and common symbols.
+ PR 30499
+ bfd * elflink.c (elf_link_add_object_symbols): Add a message indicating that alignment and size discrepancies between the definition of common symbols and normal symbols are serious and should be investigated.
+ ld * testsuite/ld-elfcomm/elfcomm.exp: Update regexps to match new output from the linker.
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Factor out border-mode help text
+ I noticed that the help texts for tui border-mode and tui active-border-mode
+ are similar.
+
+ Factor out the common part into macro HELP_ATTRIBUTE_MODE.
+
+ Tested on x86_64-linux.
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Handle pending ^C after rl_callback_read_char for readline 7
+ In commit faf01aee1d0 ("[gdb] Handle pending ^C after rl_callback_read_char")
+ we handled a problem (described in detail in that commit) for readline >= 8
+ using public readline functions rl_pending_signal and rl_check_signals.
+
+ For readline 7 (note that we require at least readline 7 so there's no need to
+ worry about readline 6), there was no fix though, because rl_check_signals was
+ not available.
+
+ Fix this by instead using the private readline function _rl_signal_handler.
+
+ There is precedent for using private readline variables and functions, but
+ it's something we want to get rid of (PR build/10723). Nevertheless, I think
+ we can allow this specific instance because it's not used when building
+ against readline >= 8.
+
+ [ In the meanwhile, a fix was committed in the devel branch of the readline
+ repo, contained in commit 8d0c439 ("rollup of changes since readline-8.2"),
+ first proposed here (
+ https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00008.html ). ]
+
+ Tested on x86_64-linux, against system readline 7.0 on openSUSE Leap 15.4.
+
+ PR cli/27813
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ Fix PR30369 regression on aarch64/arm (PR30506)
+ The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
+ Arm.
+
+ As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
+ there are issues with both the prologue skipper for AArch64 and Arm and an
+ incorrect assumption by the testcase.
+
+ This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
+ the end of a function. It also incorporates a fix to the testcase so it
+ doesn't assume the prologue skipper will stop at the first instruction of the
+ functions/labels.
+
+ Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
+ x86_64-linux Ubuntu 20.04.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30506
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+ Co-Authored-By: Luis Machado <luis.machado@arm.com>
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing wait in gdb.python/tui-window-disabled.exp
+ While working on PR tui/30526, I noticed a bug in test-case
+ gdb.python/tui-window-disabled.exp.
+
+ Here we send "tui enable" to gdb, but don't wait for it to arrive before
+ checking for a window box:
+ ...
+ send_gdb "tui enable\n"
+ Term::check_box "check for python window" 0 0 80 16
+ ...
+
+ Fix this by waiting for the prompt to be issued in TUI before doing the check.
+
+ Tested on x86_64-linux.
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix two typos in gdb.python/tui-window-disabled.exp
+ Fix two typos in test-case gdb.python/tui-window-disabled.exp.
+
+2023-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle output after prompt in gdb.threads/step-N-all-progress.exp
+ Using "taskset -c 0" I run into this timeout:
+ ...
+ (gdb) PASS: gdb.threads/step-N-all-progress.exp: non-stop=on: \
+ target-non-stop=on: continue to breakpoint: break here
+ next 3^M
+ [New Thread 0x7ffff7dbd6c0 (LWP 10202)]^M
+ 50 return 0;^M
+ (gdb) [Thread 0x7ffff7dbd6c0 (LWP 10202) exited]^M
+ FAIL: gdb.threads/step-N-all-progress.exp: non-stop=on: target-non-stop=on: \
+ next 3 (timeout)
+ ...
+
+ The problem is that this test:
+ ...
+ gdb_test "next 3" "return 0;"
+ ...
+ expects no output after the prompt.
+
+ Fix this by using -no-prompt-anchor.
+
+ Tested on x86_64-linux.
+
+2023-06-07 Alan Modra <amodra@gmail.com>
+
+ ld-elf/eh5 remove xfail hppa64
+ Commit cb81e84c72 resulted in an xpass for hppa64-hp-hpux11, but the
+ test still fails on hpp64-linux. Let's make it pass for hppa64-linux
+ too, by accepting pcrel sdata8 encoding in the augmentation data.
+
+2023-06-07 Luis Machado <luis.machado@arm.com>
+
+ Fix gdb.base/memtag.exp failure
+ While running this test on an emulator, I noticed we're failing to match the
+ output message when "memory-tag check" is issued with no arguments. That's
+ because I coded the message using "error" and missed a period at the end. Other
+ similar messages are issued with error_no_arg.
+
+ This patch changes that call to use error_no_arg.
+
+ Tested on aarch64-linux Ubuntu 20.04/22.04.
+
+2023-06-07 Alan Modra <amodra@gmail.com>
+
+ _bfd_free_cached_info
+ doc/bfdint.texi and comments in the aout and som code about this
+ function are just wrong, and its name is not very apt. Better would
+ be _bfd_mostly_destroy, and we certainly should not be saying anything
+ about the possibility of later recreating anything lost by this
+ function. What's more, if _bfd_free_cached_info is called when
+ creating an archive map to reduce memory usage by throwing away
+ symbols, the target _close_and_cleanup function won't have access to
+ tdata or section bfd_user_data to tidy memory. This means most of the
+ target _close_and_cleanup function won't do anything, and therefore
+ sometimes will result in memory leaks.
+
+ This patch fixes the documentation problems and moves most of the
+ target _close_and_cleanup code to target _bfd_free_cached_info.
+ Another notable change is that bfd_generic_bfd_free_cached_info is now
+ defined as _bfd_free_cached_info rather than _bfd_bool_bfd_true,
+ ie. the default now frees objalloc memory.
+
+2023-06-07 Alan Modra <amodra@gmail.com>
+
+ Memory leaks in bfd/vms-lib.c
+ * vms-lib.c (vms_lib_read_index): Free malloc'd memory on error
+ return paths.
+ (vms_write_index, _bfd_vms_lib_write_archive_contents): Likewise.
+
+ bfd/elf.c strtab memory leak
+ * elf.c (_bfd_elf_compute_section_file_positions): Free strtab
+ on set_group_contents failure return path.
+
+2023-06-07 Alan Modra <amodra@gmail.com>
+
+ objcopy memory leaks after errors
+ These aren't important at all, but tidy them in case they obscure
+ other more important leaks.
+
+ * objcopy (copy_file): Close input bfd after errors.
+
+2023-06-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: fix cosmetic issues and typos
+ include/
+ * sframe-api.h (sframe_decoder_get_num_fidx): Use extern.
+ libsframe/
+ * sframe-dump.c (dump_sframe_func_with_fres): Fix line length.
+ * sframe.c (sframe_frame_row_entry_copy): Likewise.
+ (sframe_decode_fre_start_address): Use the intended type uint32_t.
+
+2023-06-06 Alan Modra <amodra@gmail.com>
+
+ Re: loongarch readelf support
+ Commit 89c70cd358b8 apparently results in a bogus "value may be used
+ uninitialized" warning with some combination of compiler and
+ optimisation options.
+
+ * readelf.c (target_specific_reloc_handling): Init value.
+
+2023-06-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-05 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: avoid unnecessary type casts
+ Change the data type of some of the members of the sframe_decoder_ctx
+ and sframe_encoder_ctx data structures to use the applicable data types
+ explicitly. Current implementation in libsframe does type casts, which
+ seem unnecessary.
+
+ libsframe/
+ * libsframe/sframe-impl.h (struct sframe_decoder_ctx): Use
+ applicable data type explicitly.
+ (struct sframe_encoder_ctx): Likewise. Use same style of
+ comments consistently.
+ * libsframe/sframe.c (struct sf_fde_tbl): Define without
+ typedef.
+ (struct sf_fre_tbl): Likewise.
+ (sframe_decode): Remove unnecessary type casts.
+ (sframe_encoder_get_funcdesc_at_index): Likewise.
+ (sframe_encoder_add_fre): Likewise.
+ (sframe_encoder_add_funcdesc): Likewise.
+ (sframe_sort_funcdesc): Likewise.
+ (sframe_encoder_write_sframe): Likewise.
+
+2023-06-05 H.J. Lu <hjl.tools@gmail.com>
+
+ ELF: Add "#pass" to ld-elf/pr30508.d
+ Add "#pass" to ld-elf/pr30508.d to allow extra segments.
+
+ PR binutils/30508
+ * testsuite/ld-elf/pr30508.d: Add "#pass".
+
+2023-06-05 Tom Tromey <tromey@adacore.com>
+
+ Use unrelocated_addr in dwarf2_fde
+ This changes dwarf2_fde to use the unrelocated_addr type. This
+ pointed out a latent bug in dwarf2_frame_cache, where a relocated
+ address is compared to an unrelocated address.
+
+2023-06-05 Tom Tromey <tromey@adacore.com>
+
+ Use local "text offset" variable in dwarf2_frame_cache
+ A few spots in dwarf2_frame_cache use:
+
+ cache->per_objfile->objfile->text_section_offset ()
+
+ ... and a subsequent patch will add more, so move this into a local
+ variable.
+
+2023-06-05 Tom Tromey <tromey@adacore.com>
+
+ Constify dwarf2_cie::augmentation
+ I noticed that dwarf2_cie::augmentation could be 'const'.
+
+ Use "unrelocated" terminology in linetable_entry
+ I forgot to convert struct linetable_entry to use the "unrelocated"
+ (as opposed to "raw") terminology. This patch corrects the oversight.
+
+ Fix comment in address_class
+ enum address_class has a stale comment referring to
+ MSYMBOL_VALUE_RAW_ADDRESS, which no longer exists. This patch updates
+ the comment.
+
+ Use unrelocated_addr in dwarf_decode_lines
+ This changes dwarf_decode_lines to accept an unrelocated_addr and
+ fixes up the fallout.
+
+ Use unrelocated_addr in the DWARF reader
+ This changes various spots in the DWARF reader to use
+ unrelocated_addr.
+
+ Move unrelocated_addr to common-types.h
+ unrelocated_addr is currently defined in symtab.h, but in order to
+ avoid having to include that in more places, I wanted to move the type
+ elsewhere. I considered defs.h, but it seemed reasonable to have it
+ next to CORE_ADDR, which is what this patch does.
+
+ Minor cleanup in loclist_describe_location
+ loclist_describe_location already has a per_objfile local variable, so
+ use it consistently.
+
+ Remove baseaddr parameter from dwarf2_record_block_ranges
+ dwarf2_record_block_ranges is only ever called with the text section
+ offset, so this patch removes the parameter entirely. This makes a
+ subsequent patch a little simpler.
+
+2023-06-05 H.J. Lu <hjl.tools@gmail.com>
+
+ ELF: Don't warn an empty PT_LOAD with the program headers
+ When rewriting the program headers, don't warn an empty PT_LOAD with the
+ program headers.
+
+ bfd/
+
+ PR binutils/30508
+ * elf.c (rewrite_elf_program_header): Don't warn if an empty
+ PT_LOAD contains the program headers.
+
+ ld/
+
+ PR binutils/30508
+ * testsuite/ld-elf/pr30508.d: New file.
+ * testsuite/ld-elf/pr30508.s: Likewise.
+
+2023-06-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: building inferior strings from within GDB
+ History Of This Patch
+ =====================
+
+ This commit aims to address PR gdb/21699. There have now been a
+ couple of attempts to fix this issue. Simon originally posted two
+ patches back in 2021:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html
+
+ Before Pedro then posted a version of his own:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html
+
+ After this the conversation halted. Then in 2023 I (Andrew) also took
+ a look at this bug and posted two versions:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html
+ https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html
+
+ The approach taken in my first patch was pretty similar to what Simon
+ originally posted back in 2021. My second attempt was only a slight
+ variation on the first.
+
+ Pedro then pointed out his older patch, and so we arrive at this
+ patch. The GDB changes here are mostly Pedro's work, but updated by
+ me (Andrew), any mistakes are mine.
+
+ The tests here are a combinations of everyone's work, and the commit
+ message is new, but copies bits from everyone's earlier work.
+
+ Problem Description
+ ===================
+
+ Bug PR gdb/21699 makes the observation that using $_as_string with
+ GDB's printf can cause GDB to print unexpected data from the
+ inferior. The reproducer is pretty simple:
+
+ #include <stddef.h>
+ static char arena[100];
+
+ /* Override malloc() so value_coerce_to_target() gets a known
+ pointer, and we know we"ll see an error if $_as_string() gives
+ a string that isn't null terminated. */
+ void
+ *malloc (size_t size)
+ {
+ memset (arena, 'x', sizeof (arena));
+ if (size > sizeof (arena))
+ return NULL;
+ return arena;
+ }
+
+ int
+ main ()
+ {
+ return 0;
+ }
+
+ And then in a GDB session:
+
+ $ gdb -q test
+ Reading symbols from /tmp/test...
+ (gdb) start
+ Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
+ Starting program: /tmp/test
+
+ Temporary breakpoint 1, main () at test.c:17
+ 17 return 0;
+ (gdb) printf "%s\n", $_as_string("hello")
+ "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+ (gdb) quit
+
+ The problem above is caused by how value_cstring is used within
+ py-value.c, but once we understand the issue then it turns out that
+ value_cstring is used in an unexpected way in many places within GDB.
+
+ Within py-value.c we have a null-terminated C-style string. We then
+ pass a pointer to this string, along with the length of this
+ string (so not including the null-character) to value_cstring.
+
+ In value_cstring GDB allocates an array value of the given character
+ type, and copies in requested number of characters. However
+ value_cstring does not add a null-character of its own. This means
+ that the value created by calling value_cstring is only
+ null-terminated if the null-character is included in the passed in
+ length. In py-value.c this is not the case, and indeed, in most uses
+ of value_cstring, this is not the case.
+
+ When GDB tries to print one of these strings the value contents are
+ pushed to the inferior, and then read back as a C-style string, that
+ is, GDB reads inferior memory until it finds a null-terminator. For
+ the py-value.c case, no null-terminator is pushed into the inferior,
+ so GDB will continue reading inferior memory until a null-terminator
+ is found, with unpredictable results.
+
+ Patch Description
+ =================
+
+ The first thing this patch does is better define what the arguments
+ for the two function value_cstring and value_string should represent.
+ The comments in the header file are updated to describe whether the
+ length argument should, or should not, include a null-character.
+ Also, the data argument is changed to type gdb_byte. The functions as
+ they currently exist will handle wide-characters, in which case more
+ than one 'char' would be needed for each character. As such using
+ gdb_byte seems to make more sense.
+
+ To avoid adding casts throughout GDB, I've also added an overload that
+ still takes a 'char *', but asserts that the character type being used
+ is of size '1'.
+
+ The value_cstring function is now responsible for adding a null
+ character at the end of the string value it creates.
+
+ However, once we start looking at how value_cstring is used, we
+ realise there's another, related, problem. Not every language's
+ strings are null terminated. Fortran and Ada strings, for example,
+ are just an array of characters, GDB already has the function
+ value_string which can be used to create such values.
+
+ Consider this example using current GDB:
+
+ (gdb) set language ada
+ (gdb) p $_gdb_setting("arch")
+ $1 = (97, 117, 116, 111)
+ (gdb) ptype $
+ type = array (1 .. 4) of char
+ (gdb) p $_gdb_maint_setting("test-settings string")
+ $2 = (0)
+ (gdb) ptype $
+ type = array (1 .. 1) of char
+
+ This shows two problems, first, the $_gdb_setting and
+ $_gdb_maint_setting functions are calling value_cstring using the
+ builtin_char character, rather than a language appropriate type. In
+ the first call, the 'arch' case, the value_cstring call doesn't
+ include the null character, so the returned array only contains the
+ expected characters. But, in the $_gdb_maint_setting example we do
+ end up including the null-character, even though this is not expected
+ for Ada strings.
+
+ This commit adds a new language method language_defn::value_string,
+ this function takes a pointer and length and creates a language
+ appropriate value that represents the string. For C, C++, etc this
+ will be a null-terminated string (by calling value_cstring), and for
+ Fortran and Ada this can be a bounded array of characters with no null
+ terminator. Additionally, this new language_defn::value_string
+ function is responsible for selecting a language appropriate character
+ type.
+
+ After this commit the only calls to value_cstring are from the C
+ expression evaluator and from the default language_defn::value_string.
+
+ And the only calls to value_string are from Fortan, Ada, and ObjectC
+ related code.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-06-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix grammar in comments and docs
+ Fix grammar in some comments and docs:
+ - machines that doesn't -> machines that don't
+ - its a -> it's a
+ - its the -> it's the
+ - if does its not -> if it does it's not
+ - one more instructions if doesn't match ->
+ one more instruction if it doesn't match
+ - it's own -> its own
+ - it's first -> its first
+ - it's pointer -> its pointer
+
+ I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
+ domain notice, I've left that alone.
+
+ Tested on x86_64-linux.
+
+2023-06-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix more typos
+ Fix some more typos:
+ - distinquish -> distinguish
+ - actualy -> actually
+ - singe -> single
+ - frash -> frame
+ - chid -> child
+ - dissassembler -> disassembler
+ - uninitalized -> uninitialized
+ - precontidion -> precondition
+ - regsiters -> registers
+ - marge -> merge
+ - sate -> state
+ - garanteed -> guaranteed
+ - explictly -> explicitly
+ - prefices (nonstandard plural) -> prefixes
+ - bondary -> boundary
+ - formated -> formatted
+ - ithe -> the
+ - arrav -> array
+ - coresponding -> corresponding
+ - owend -> owned
+ - fials -> fails
+ - diasm -> disasm
+ - ture -> true
+ - tpye -> type
+
+ There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to
+ SIG_CODE_BOUNDARY_FAULT.
+
+ Tested on x86_64-linux.
+
+2023-06-05 Alan Modra <amodra@gmail.com>
+
+ bfd_error_on_input messages
+ bfd_errmsg uses asprintf for bfd_error_on_input, which means we
+ currently leak memory. Keep a static pointer to the message and free
+ it in various places to minimise the leaks.
+ bfd_set_input_error (NULL, bfd_error_no_error) is a way to free up the
+ last string if that matters.
+
+ * bfd.c (input_error_msg): New static var.
+ (bfd_set_input_error): Free it here..
+ (bfd_init): ..and here..
+ (bfd_errmsg): ..and here. Use it for asprintf output.
+
+2023-06-05 Alan Modra <amodra@gmail.com>
+
+ Yet another ecoff fuzzed object fix
+ * ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check fdr_ptr
+ csym against remaining space for symbols. Error on out of bounds
+ fdr_ptr fields.
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: sync oprand char usage between mips and micromips
+ We should try our best to make mips32 using the same
+ oprand char with micromips. So for mips32, we use:
+
+ ^ is added for 5bit sa oprand for some new DSPr2 instructions:
+ APPEND, PREPEND, PRECR_SRA[_R].PH.W
+ the LSB bit is 11, like RD.
+ +t is removed for coprocessor 0 destination register.
+ 'E' does the samething.
+ +t is now used for RX oprand for MFTR/MTTR (MT ASE)
+ ? is added for sel oprand for MFTR/MTTR (MT ASE)
+ For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc,
+ while for micromips, they are different.
+
+ We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2:
+ concatenating rs with rx as the index of control or data.
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: add MT ASE support for micromips32
+ These instructions are descripted in MD00768.
+
+ MIPS® Architecture for Programmers
+ Volume IV-f: The MIPS® MT Module for
+ the microMIPS32™ Architecture
+
+ Document Number: MD00768
+ Revision 1.12
+ July 16, 2013
+
+ https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ Revert "MIPS: add MT ASE support for micromips32"
+ This reverts commit 783a5f46b0583e9ed3a63acd3361009f46de5c17.
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: add MT ASE support for micromips32
+ These instructions are descripted in MD00768.
+
+ MIPS® Architecture for Programmers
+ Volume IV-f: The MIPS® MT Module for
+ the microMIPS32™ Architecture
+
+ Document Number: MD00768
+ Revision 1.12
+ July 16, 2013
+
+ https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: fix some ld testcases with compiler
+ 1. config/default.exp:
+ use -mabi=32 not for -gnuabi64
+ xfail_from_runlist: remove an element and mark it xfail.
+ 2. ld-elf/indirect.exp: xfail
+ indirect5a indirect5b indirect6a indirect6b
+ indirect5c indirect5d indirect6c indirect6d
+ 3. ld-elf/pr23658-2: mips output is not common
+ 4. ld-elf/shared.exp: non-run on mips: Build libpr16496b.so
+ 5. ld-elfvers/vers.exp:
+ xfail vers4, vers4b
+ no-run on mips: vers24a, vers24b, vers24c
+ 6. ld-gc/gc.exp: add -KPIC into asflags for pr13683, pr14265, pr19161
+ 7. ld-mips-elf/mips-elf.exp:
+ use noarch for mips16-local-stubs-1, since it use -mips4
+ 8. ld-plugin/lto.exp:
+ no-run on mips/linux: PR ld/12982
+ add -KPIC into asflags for lto-3r, lto-5r, PR ld/19317 (2)
+ xfail PR ld/15323 (4), PR ld/19317 (3)
+ 9. ld-plugin/plugin.exp: xfail
+ plugin claimfile lost symbol
+ plugin claimfile replace symbol
+ plugin claimfile replace symbol
+ plugin claimfile lost symbol with source
+ plugin claimfile replace symbol with source
+ plugin claimfile resolve symbol with source
+ plugin 2 with source lib
+ load plugin 2 with source
+ plugin 3 with source lib
+ load plugin 3 with source
+ 11. ld-selective/selective.exp: add -fno-PIC, which is needed for -mno-abicalls
+ 12. ld-shared/shared.exp: xfail shared (non PIC), shared (PIC main, non PIC so)
+
+ MIPS: fix -gnuabi64 testsuite
+ Test on:
+ mips64-linux-gnuabi64
+ mips64el-linux-gnuabi64
+ mipsisa64-linux-gnuabi64
+ mipsisa64el-linux-gnuabi64
+ mipsisa64r2-linux-gnuabi64
+ mipsisa64r2el-linux-gnuabi64
+ mipsisa64r6-linux-gnuabi64
+ mipsisa64r6el-linux-gnuabi64
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: fix r6 testsuites
+ Introduce
+ run_dump_test_o32l
+ run_dump_test_n32l
+ run_dump_test_n64l
+ Which use `-march=from-abi` for pre-R6 testcases,
+ like micromips/mips16e etc.
+
+ For cases doesn't use run_dump_test_*, we use
+ -mips32r2 for micromips32
+ -mips1 for mips16-32
+ -march=from-abi for testcases to o32/n32/n64 both/all.
+
+ Replace `addi` with `addiu` for some cases for both r6 and pre-R6.
+
+ Introduce some new testcases for r6 with FPXX/FP64.
+ Introduce new testcase: comdat-reloc-r6.
+
+ Skip `default` in mips_arch_list_matching if triple is mipsisa*, due to:
+ 1)it will cannot match mipsr6@*.d: since mips32rN/mips64rN
+ will always be used, it won't be a problem.
+ 2)some test think -march=mips64rN will alway true for mipsisa64rN,
+ which is not true now.
+
+ This patch fix testsuite for all r6-default gnu triples:
+ mipsisa32r6-linux-gnu
+ mipsisa32r6el-linux-gnu
+ mips-img-linux-gnu
+ mipsel-img-linux-gnu
+ mipsisa64r6-linux-gnu
+ mipsisa64r6el-linux-gnu
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: default r6 if vendor is img
+ This behavior is used by downstream toolchain since 2014.
+ We also set the default ABI for mips*-img-elf to O32.
+ The previous value is NO_ABI, which is not good default ABI.
+
+ We don't support mips64*-img* due to GCC doesn't support it,
+ and We believe that the multilib should be used for this case.
+
+2023-06-05 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit
+ When configure with triples mipsisa[32,64]rN[el,], the march value
+ is pinned to a fix value if not given explicitly. for example
+ 1) mipsisa32r6-linux-gnu -n32 xx.s will complains that:
+ -march=mips32r6 is not compatible with the selected ABI
+ 2) mipsisa64r2el-linux-gnu -o32 generates objects with 64bit CPU:
+ ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
+ They are not good default behaviors: Let's alter the CPU info
+
+ Since we are using these triples as a regular linux distributions,
+ let's alter march according to ABI.
+
+2023-06-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix typos
+ Fix a few typos:
+ - implemention -> implementation
+ - convertion(s) -> conversion(s)
+ - backlashes -> backslashes
+ - signoring -> ignoring
+ - (un)ambigious -> (un)ambiguous
+ - occured -> occurred
+ - hidding -> hiding
+ - temporarilly -> temporarily
+ - immediatelly -> immediately
+ - sillyness -> silliness
+ - similiar -> similar
+ - porkuser -> pokeuser
+ - thats -> that
+ - alway -> always
+ - supercede -> supersede
+ - accomodate -> accommodate
+ - aquire -> acquire
+ - priveleged -> privileged
+ - priviliged -> privileged
+ - priviledges -> privileges
+ - privilige -> privilege
+ - recieve -> receive
+ - (p)refered -> (p)referred
+ - succesfully -> successfully
+ - successfuly -> successfully
+ - responsability -> responsibility
+ - wether -> whether
+ - wich -> which
+ - disasbleable -> disableable
+ - descriminant -> discriminant
+ - construcstor -> constructor
+ - underlaying -> underlying
+ - underyling -> underlying
+ - structureal -> structural
+ - appearences -> appearances
+ - terciarily -> tertiarily
+ - resgisters -> registers
+ - reacheable -> reachable
+ - likelyhood -> likelihood
+ - intepreter -> interpreter
+ - disassemly -> disassembly
+ - covnersion -> conversion
+ - conviently -> conveniently
+ - atttribute -> attribute
+ - struction -> struct
+ - resonable -> reasonable
+ - popupated -> populated
+ - namespaxe -> namespace
+ - intialize -> initialize
+ - identifer(s) -> identifier(s)
+ - expection -> exception
+ - exectuted -> executed
+ - dungerous -> dangerous
+ - dissapear -> disappear
+ - completly -> completely
+ - (inter)changable -> (inter)changeable
+ - beakpoint -> breakpoint
+ - automativ -> automatic
+ - alocating -> allocating
+ - agressive -> aggressive
+ - writting -> writing
+ - reguires -> requires
+ - registed -> registered
+ - recuding -> reducing
+ - opeartor -> operator
+ - ommitted -> omitted
+ - modifing -> modifying
+ - intances -> instances
+ - imbedded -> embedded
+ - gdbaarch -> gdbarch
+ - exection -> execution
+ - direcive -> directive
+ - demanged -> demangled
+ - decidely -> decidedly
+ - argments -> arguments
+ - agrument -> argument
+ - amespace -> namespace
+ - targtet -> target
+ - supress(ed) -> suppress(ed)
+ - startum -> stratum
+ - squence -> sequence
+ - prompty -> prompt
+ - overlow -> overflow
+ - memember -> member
+ - languge -> language
+ - geneate -> generate
+ - funcion -> function
+ - exising -> existing
+ - dinking -> syncing
+ - destroh -> destroy
+ - clenaed -> cleaned
+ - changep -> changedp (name of variable)
+ - arround -> around
+ - aproach -> approach
+ - whould -> would
+ - symobl -> symbol
+ - recuse -> recurse
+ - outter -> outer
+ - freeds -> frees
+ - contex -> context
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix typo in debug message
+ In microblaze_analyze_prologue in gdb/microblaze-tdep.c I came across:
+ ...
+ microblaze_debug ("got addi r1,r1,%d; contnuing\n", imm);
+ ...
+
+ Fix this by using "continuing".
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Fix doc string of valpy_const_value
+ In gdb/python/py-value.c, in the value_object_methods array I noticed:
+ ...
+ { "const_value", valpy_const_value, METH_NOARGS,
+ "Return a 'const' qualied version of the same value." },
+ ...
+
+ Fix the qualied -> qualified typo.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/guile] Fix doc string for value-optimized-out?
+ In gdb/guile/scm-value.c, I noticed in the value_functions array initializer:
+ ...
+ { "value-optimized-out?", 1, 0, 0,
+ as_a_scm_t_subr (gdbscm_value_optimized_out_p),
+ "\
+ Return #t if the value has been optimizd out." },
+ ...
+ There's a typo in the doc string.
+
+ Fix this by using "optimized".
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix help text of show tui tab-width
+ I noticed:
+ ...
+ (gdb) help show tui tab-width
+ Show the tab witdh, in characters, for the TUI.
+ This variable controls how many spaces are used to display a tab character.
+ ...
+ a typo: "witdh".
+
+ Fix this by using "width" instead.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Fix help text of maint info target-sections
+ I noticed a typo:
+ ...
+ (gdb) help maint info target-sections
+ List GDB's internal section table.
+
+ Print the current targets section list. This is a sub-set of all
+ sections, from all objects currently loaded. Usually the ALLOC
+ sectoins.
+ ...
+
+ Fix this by using "sections".
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Fix help text of maint set ignore-prologue-end-flag
+ I noticed here:
+ ...
+ (gdb) help maint set ignore-prologue-end-flag
+ Set if the PROLOGUE-END flag is ignored.
+ The PROLOGUE-END flag from the line-table entries is used to place \
+ breakpoints past the prologue of functions. Disabeling its use use forces \
+ the use of prologue scanners.
+ ...
+ a typo in "Disabeling" and accidental word repetition "use use".
+
+ Fix by replacing with "Disabling" and "use".
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/compile] Fix typo in debug message
+ In compile_object_load in gdb/compile/compile-object-load.c I came across:
+ ...
+ "Connectiong ELF symbol \"%s\" to the .toc section (%s)\n",
+ ...
+
+ Fix this typo by using "Connecting" instead.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdbserver] Fix typo in debug message
+ I noticed in emit_ops_insns in gdbserver/linux-aarch64-low.cc:
+ ...
+ threads_debug_printf ("Adding %d instrucions at %s",
+ ...
+
+ Fix the typo by using "instructions" instead.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Fix argument name misspelling
+ Two functions use the argument name bounds_prefered_p.
+
+ This misspells "preferred".
+
+ Fix this by using bounds_preferred_p instead.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-06-03 Alan Modra <amodra@gmail.com>
+
+ Re: loongarch readelf support
+ Another segfault.
+
+ * readelf.c (target_specific_reloc_handling): Sanity check
+ loongarch reloc r_offset.
+
+2023-06-03 Alan Modra <amodra@gmail.com>
+
+ Re: More ecoff sanity checks
+ Yet another fuzzer fix.
+
+ * ecoff.c (ecoff_slurp_symbolic_header <FIX>): Zero counts when
+ associated pointer is zero.
+ (_bfd_ecoff_slurp_symbolic_info): Remove now unnecessary check.
+
+2023-06-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-02 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Fix architecture debug version constant thinkos
+ Caught this during emulator testing.
+
+ Fix the constants. They should be 0xa and 0xb as opposed to 0x10 and
+ 0x11. There was a thinko while defining them.
+
+ Obvious enough.
+
+ Tested on aarch64-linux Ubuntu 20.04/22.04.
+
+2023-06-02 Alan Modra <amodra@gmail.com>
+
+ Re: bfd_close and target free_cached_memory
+ _bfd_delete_bfd can be called early, before the target xvec is set up.
+
+ * opncls.c (_bfd_delete_bfd): Don't segfault on NULL xvec.
+
+2023-06-02 Alan Modra <amodra@gmail.com>
+
+ Re: More ecoff sanity checks
+ Another fix for fuzzed object files, exhibiting as a segfault in
+ nm.c filter_symbols when accessing a symbol name.
+
+ * ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check
+ fdr_ptr->issBase, and tighten sym.iss check.
+
+2023-06-02 Alan Modra <amodra@gmail.com>
+
+ loongarch readelf support
+ This fixes two buffer overflows found by fuzzers.
+
+ * readelf.c (target_specific_reloc_handling): Sanity check
+ loongarch reloc symbol index. Don't apply reloc after errors.
+ Reduce translation work of "invalid symbol index" error message.
+
+2023-06-02 Alan Modra <amodra@gmail.com>
+
+ Minor objcopy optimisation for copy_relocations_in_section
+ * objcopy (copy_relocations_in_section): Don't read the relocs
+ for STRIP_ALL if keep_specific_htab is empty.
+
+2023-06-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-06-01 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: avoid using magic number
+ Define a new constant for the maximum number of stack offsets handled in
+ libsframe, and use it. Note that the SFrame format does not define such
+ a constant (limit). This is an implmentation-defined constant in
+ libsframe.
+
+ include/
+ * sframe-api.h (MAX_NUM_STACK_OFFSETS): New definition.
+ libsframe/
+ * sframe.c (sframe_fre_sanity_check_p): Use it.
+
+2023-06-01 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: minor fixups in flip_fre related functions
+ libsframe/
+ * sframe.c (flip_fre_start_address): Remove unnecessary type
+ cast. Use uint16_t instead of unsigned short.
+ (flip_fre_stack_offsets): Likewise.
+
+2023-06-01 Jim Wilson <jimw@sifive.com>
+
+ RISC-V: PR30449, Add lga assembler macro support.
+ Originally discussion, https://github.com/riscv/riscv-isa-manual/pull/539
+
+ Added new load address pseudo instruction which is always expanded to GOT
+ access, no matter the .option rvc is set or not.
+
+ gas/
+ PR 30449
+ * config/tc-riscv.c (macro): Add M_LGA support.
+ * testsuite/gas/riscv/la-variants.d: New.
+ * testsuite/gas/riscv/la-variants.s: New.
+ include/
+ PR 30449
+ * opcode/riscv.h (M_LGA): New.
+ opcodes/
+ PR 30449
+ * riscv-opc.c (riscv_opcodes): Add lga support.
+
+2023-06-01 Nelson Chu <nelson@rivosinc.com>
+
+ [PR ld/22263][PR ld/24676] RISC-V: Avoid spurious R_RISCV_NONE for TLS GD/IE.
+ For TLS GD/IE, add the same condition with the relocate_section in the
+ allocate_dynrelocs, to make sure we won't reserve redundant spaces
+ for dynamic relocations since the conservative estimatation.
+
+ After applying this patch, ld seems no longer generate the spurious
+ R_RISCV_NONE for pr22263-1 test, and the test in pr24676.
+
+ bfd/
+ PR ld/22263
+ PR ld/24676
+ * elfnn-riscv.c (RISCV_TLS_GD_IE_NEED_DYN_RELOC): New defined.
+ Set NEED_RELOC to true if TLS GD/IE needs dynamic relocations,
+ and INDX will be the dynamic index.
+ (allocate_dynrelocs): Don't reserve extra spaces in the rela.got
+ if RISCV_TLS_GD_IE_NEED_DYN_RELOC set need_reloc to false. This
+ condition needs to be same as relocate_section.
+ (relocate_section): Likewise, use the same condition as
+ allocate_dynrelocs.
+
+2023-06-01 Alan Modra <amodra@gmail.com>
+
+ Harden PowerPC64 OPD handling against fuzzers
+ PowerPC64 ELFv1 object files should have at most one .opd section, and
+ OPD handling in elf64-ppc.c makes use of this fact by caching some
+ .opd section info in the per-object bfd.tdata. This was done to avoid
+ another word in the target specific section data. Of course, fuzzers
+ don't respect the ABI, and even non-malicious users can accidentally
+ create multiple .opd sections. So it is better to avoid possible
+ buffer overflows and other confusion when OPD handling for a second
+ .opd section references data for the first .opd section, by keeping
+ the data per-section.
+
+ The patch also fixes a memory leak, and a corner case where I think we
+ could hit an assertion in opd_entry_value or read out of bounds in
+ ppc64_elf_branch_reloc doing a final link producing non-ppc64 output.
+ (It's a really rare corner case because not only would you need to be
+ linking ppc64 objects to non-ppc64 output, you'd also need a branch
+ reloc symbol to be defined in a .opd section of a non-ppc64 input.)
+
+ * elf64-ppc.c (is_ppc64_elf): Move earlier in file.
+ (ppc64_elf_branch_reloc): Check symbol bfd before accessing
+ ppc64 elf specific data structures.
+ (struct ppc64_elf_obj_tdata): Move opd union..
+ (struct _ppc64_elf_section_data): ..to here.
+ (ppc64_elf_before_check_relocs): Allow for opd sec_type
+ already set to sec_opd.
+ (ppc64_elf_check_relocs): Only set sec_type to sec_toc when
+ unset. Error for unexpected toc relocs.
+ (opd_entry_value): Return -1 when non-ppc64 rather than
+ asserting. Check and set sec_type too. Adjust for changed
+ location of contents and relocs.
+ (ppc64_elf_relocate_section): Adjust for changed location of
+ cached .opd relocs.
+ (ppc64_elf_free_cached_info): New function.
+ (bfd_elf64_bfd_free_cached_info): Define.
+
+2023-06-01 Alan Modra <amodra@gmail.com>
+
+ bfd_close and target free_cached_memory
+ bfd_free_cached_info is used in just one place in archive.c, which
+ means most times we reach bfd_close the function isn't called. On the
+ other hand, if bfd_free_cached_info is called we can't do much on the
+ bfd since it loses all its obj_alloc memory. This restricts what can
+ be done in a target _close_and_cleanup. In particular you can't look
+ at sections, which leads to duplication of code in target
+ close_and_cleanup and free_cached_info, eg. elfnn-aarch64.c.
+
+ * opncls.c (_bfd_delete_bfd): Call bfd_free_cached_info.
+ * elfnn-aarch64.c (elfNN_aarch64_close_and_cleanup): Delete.
+ (bfd_elfNN_close_and_cleanup): Don't define.
+ * som.c (som_bfd_free_cached_info): Don't call
+ _bfd_generic_close_and_cleanup here.
+ (som_close_and_cleanup): Define as _bfd_generic_close_and_cleanup.
+
+2023-06-01 Alan Modra <amodra@gmail.com>
+
+ section_by_target_index memory leak
+ The rs6000 backend can call coff_section_from_bfd_index from its
+ object_p function via coff_set_alignment_hook. If the object doesn't
+ match, or another target matches too, then the hash table needs to be
+ freed via a cleanup.
+
+ * coffgen.c (coff_object_cleanup): New function.
+ (coff_real_object_p): Return coff_object_cleanup, and call on
+ failure path. Move declaration to..
+ * libcoff-in.h: ..here.
+ (coff_object_cleanup): Declare.
+ * coff-stgo32.c (go32exe_cleanup): Call coff_object_cleanup.
+ (go32exe_check_format): Adjust assertion.
+ * libcoff.h: Regenerate.
+
+2023-06-01 Alan Modra <amodra@gmail.com>
+
+ Remove BFD_FAIL in cpu-sh.c
+ The assertions in cpu-sh.c can be triggered by passing bogus values
+ in disassemble_info.mach. This doesn't cause any bfd misbehaviour.
+
+ * cpu-sh.c (sh_get_arch_from_bfd_mach): Remove BFD_FAIL.
+ (sh_get_arch_up_from_bfd_mach): Likewise.
+
+2023-06-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Fix -Wsign-compare warning
+ gprofng/ChangeLog
+ 2023-05-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30490
+ * src/LoadObject.cc: Fix -Wsign-compare warning.
+
+2023-05-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 29470 The test suite should be made more flexible
+ I add two new targets (check-extra, check-install) for gprofng testing:
+ `make check` runs sanity testing for gprofng and takes ~30 secunds.
+ `make check-extra` runs all gprofng tests and takes ~20 minutus.
+ `make check-install` runs all gprofng tests and uses gprofng installation.
+
+ On aarch64, there are unwind problems in libgp-collector.so.
+ I set ACCT_FILTER to temporarily ignore problematic functions.
+
+ gprofng/ChangeLog
+ 2023-05-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29470
+ * Makefile.am: Add check-extra, check-install.
+ * Makefile.in: Rebuild
+ * testsuite/config/default.exp: Set the GPROFNG variable.
+ * testsuite/gprofng.display/display.exp: Updated the test list.
+ * testsuite/gprofng.display/jsynprog/Intface.java: Correct copyright.
+ * testsuite/gprofng.display/jsynprog/Launcher.java: Likewise.
+ * testsuite/gprofng.display/jsynprog/Makefile: Likewise.
+ * testsuite/gprofng.display/jsynprog/Routine.java: Likewise.
+ * testsuite/gprofng.display/jsynprog/Sub_Routine.java: Likewise.
+ * testsuite/gprofng.display/jsynprog/cloop.cc: Likewise.
+ * testsuite/gprofng.display/jsynprog/jsynprog.h: Likewise.
+ * testsuite/gprofng.display/jsynprog/jsynprog.java: Correct copyright.
+ Add the -j option to run the selected functions.
+ * testsuite/gprofng.display/synprog/check_results.pl:
+ Remove unused environment variable.
+ * testsuite/gprofng.display/synprog/synprog.c: Updated DEFAULT_COMMAND.
+ * testsuite/lib/Makefile.skel: Apply $(ACCT_FILTER).
+ * testsuite/lib/acct.pm: Ignore errors when $(ACCT_FILTER) is set.
+ * testsuite/lib/display-lib.exp: Add TARGET_FLAGS in make_args.
+
+2023-05-31 Tom Tromey <tromey@adacore.com>
+
+ Improve MI -dprintf-insert documentation
+ I found the documentation for -dprintf-insert a bit unclear. It
+ didn't mention the possibility of multiple arguments, and I also
+ noticed that it implied that the format parameter is optional, which
+ it is not.
+
+ While looking into this I also noticed a few comments in the
+ implementation that could also be improved.
+
+ Then, I noticed a repeated call to strlen in a loop condition, so I
+ fixed this up as well.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-31 Tom Tromey <tromey@adacore.com>
+
+ Pass correct name to @value in gdb.texinfo
+ I noticed a couple instance of this warning when rebuilding the gdb
+ info files:
+
+ warning: undefined flag: GDB
+
+ The problem is that the wrong argument was passed to @value. This
+ patch fixes the problem.
+
+2023-05-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/wrap-line.exp with --disable-tui
+ When running the test-case gdb.tui/wrap-line.exp with a build configured with
+ --disable-tui, we run into:
+ ...
+ (gdb) PASS: gdb.tui/wrap-line.exp: width-hard-coded: set width 50
+ tui new-layout command-layout cmd 1^M
+ Undefined command: "tui". Try "help".^M
+ (gdb) ERROR: Undefined command "tui new-layout command-layout cmd 1".
+ ...
+
+ Fix this by guarding the command with allow_tui_tests.
+
+ Tested on x86_64-linux.
+
+2023-05-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/pr30056.exp for native-extended-gdbserver
+ When running test-case gdb.tui/pr30056.exp with target board
+ native-extended-gdbserver, I run into:
+ ...
+ Quit^[[K^M^[[B(gdb) PASS: gdb.tui/pr30056.exp: Control-C
+ Remote debugging from host ::1, port 38810^M
+ ^M(failed reverse-i-search)`xyz': ^M(gdb) target extended-remote \
+ localhost:2346^[[7GWARNING: Timed out waiting for EOF in server after \
+ monitor exit
+ ...
+
+ This is due to the fact that ^C doesn't abort the reverse-i-search. This
+ appears to be due to a readline problem. A PR is open about this: PR
+ cli/30498.
+
+ Add a KFAIL for the PR, and ensure that the isearch is aborted by using ^G,
+ such that we have a responsive prompt to handle the "monitor exit" command
+ that native-extended-gdbserver issues.
+
+ Tested on x86_64-linux.
+
+2023-05-31 Tristan Gingold <tgingold@free.fr>
+
+ pe/coff - add support for base64 encoded long section names
+ PR 30444
+ * coffcode.h (coff_write_object_contents): Handle base64 encoding on PE. Also check for too large string table.
+ * coffgen.c (extract_long_section_name): New function extracted from ... (make_a_section_from_file): ... here. Add support for base64 long section names. (decode_base64): New function.
+
+2023-05-31 Nick Clifton <nickc@redhat.com>
+
+ Fix printf formating issues in elfxx-loongarch64.c
+
+2023-05-31 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ python, btrace: Fix some small formatting issues.
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix fingerprint for cmd-only layout
+ I added a cmd-only layout:
+ ...
+ (gdb) tui new-layout cmd cmd 1
+ ...
+ and set it:
+ ...
+ (gdb) layout cmd
+ ...
+ which gave me the expect result: only the cmd window in the screen.
+
+ However, after going back to layout src:
+ ...
+ (gdb) layout src
+ ...
+ I got a source window with only one line in it, and the cmd window taking most
+ of the screen.
+
+ I traced this back to tui_set_layout, where for both the old and the new
+ layout the fingerprint of the cmd window in the layout is taken. If the
+ fingerprint is the same, an effort will be done to preserve the command
+ window size.
+
+ The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which
+ explains the behaviour.
+
+ I think this is essentially a bug in the finger print calculation, and it
+ should be "C" for the cmd layout.
+
+ Fix this by not adding a V or H in the fingerprint if the list size is one.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add support for %V to printf command
+ This commit adds a new format for the printf and dprintf commands:
+ '%V'. This new format takes any GDB expression and formats it as a
+ string, just as GDB would for a 'print' command, e.g.:
+
+ (gdb) print a1
+ $a = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
+ (gdb) printf "%V\n", a1
+ {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
+ (gdb)
+
+ It is also possible to pass the same options to %V as you might pass
+ to the print command, e.g.:
+
+ (gdb) print -elements 3 -- a1
+ $4 = {2, 4, 6...}
+ (gdb) printf "%V[-elements 3]\n", a1
+ {2, 4, 6...}
+ (gdb)
+
+ This new feature would effectively replace an existing feature of GDB,
+ the $_as_string builtin convenience function. However, the
+ $_as_string function has a few problems which this new feature solves:
+
+ 1. $_as_string doesn't currently work when the inferior is not
+ running, e.g:
+
+ (gdb) printf "%s", $_as_string(a1)
+ You can't do that without a process to debug.
+ (gdb)
+
+ The reason for this is that $_as_string returns a value object with
+ string type. When we try to print this we call value_as_address,
+ which ends up trying to push the string into the inferior's address
+ space.
+
+ Clearly we could solve this problem, the string data exists in GDB, so
+ there's no reason why we have to push it into the inferior, but this
+ is an existing problem that would need solving.
+
+ 2. $_as_string suffers from the fact that C degrades arrays to
+ pointers, e.g.:
+
+ (gdb) printf "%s\n", $_as_string(a1)
+ 0x404260 <a1>
+ (gdb)
+
+ The implementation of $_as_string is passed a gdb.Value object that is
+ a pointer, it doesn't understand that it's actually an array. Solving
+ this would be harder than issue #1 I think. The whole array to
+ pointer transformation is part of our expression evaluation. And in
+ most cases this is exactly what we want. It's not clear to me how
+ we'd (easily) tell GDB that we didn't want this reduction in _some_
+ cases. But I'm sure this is solvable if we really wanted to.
+
+ 3. $_as_string is a gdb.Function sub-class, and as such is passed
+ gdb.Value objects. There's no super convenient way to pass formatting
+ options to $_as_string. By this I mean that the new %V feature
+ supports print formatting options. Ideally, we might want to add this
+ feature to $_as_string, we might imagine it working something like:
+
+ (gdb) printf "%s\n", $_as_string(a1,
+ elements = 3,
+ array_indexes = True)
+
+ where the first item is the value to print, while the remaining
+ options are the print formatting options. However, this relies on
+ Python calling syntax, which isn't something that convenience
+ functions handle. We could possibly rely on strictly positional
+ arguments, like:
+
+ (gdb) printf "%s\n", $_as_string(a1, 3, 1)
+
+ But that's clearly terrible as there's far more print formatting
+ options, and if you needed to set the 9th option you'd need to fill in
+ all the previous options.
+
+ And right now, the only way to pass these options to a gdb.Function is
+ to have GDB first convert them all into gdb.Value objects, which is
+ really overkill for what we want.
+
+ The new %V format solves all these problems: the string is computed
+ and printed entirely on the GDB side, we are able to print arrays as
+ actual arrays rather than pointers, and we can pass named format
+ arguments.
+
+ Finally, the $_as_string is sold in the manual as allowing users to
+ print the string representation of flag enums, so given:
+
+ enum flags
+ {
+ FLAG_A = (1 << 0),
+ FLAG_B = (1 << 1),
+ FLAG_C = (1 << 1)
+ };
+
+ enum flags ff = FLAG_B;
+
+ We can:
+
+ (gdb) printf "%s\n", $_as_string(ff)
+ FLAG_B
+
+ This works just fine with %V too:
+
+ (gdb) printf "%V\n", ff
+ FLAG_B
+
+ So all functionality of $_as_string is replaced by %V. I'm not
+ proposing to remove $_as_string, there might be users currently
+ depending on it, but I am proposing that we don't push $_as_string in
+ the documentation.
+
+ As %V is a feature of printf, GDB's dprintf breakpoints naturally gain
+ access to this feature too. dprintf breakpoints can be operated in
+ three different styles 'gdb' (use GDB's printf), 'call' (call a
+ function in the inferior), or 'agent' (perform the dprintf on the
+ remote).
+
+ The use of '%V' will work just fine when dprintf-style is 'gdb'.
+
+ When dprintf-style is 'call' the format string and arguments are
+ passed to an inferior function (printf by default). In this case GDB
+ doesn't prevent use of '%V', but the documentation makes it clear that
+ support for '%V' will depend on the inferior function being called.
+
+ I chose this approach because the current implementation doesn't place
+ any restrictions on the format string when operating in 'call' style.
+ That is, the user might already be calling a function that supports
+ custom print format specifiers (maybe including '%V') so, I claim, it
+ would be wrong to block use of '%V' in this case. The documentation
+ does make it clear that users shouldn't expect this to "just work"
+ though.
+
+ When dprintf-style is 'agent' then GDB does no support the use of
+ '%V' (right now). This is handled at the point when GDB tries to
+ process the format string and send the dprintf command to the remote,
+ here's an example:
+
+ Reading symbols from /tmp/hello.x...
+ (gdb) dprintf call_me, "%V", a1
+ Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
+ (gdb) set sysroot /
+ (gdb) target remote | gdbserver --once - /tmp/hello.x
+ Remote debugging using | gdbserver --once - /tmp/hello.x
+ stdin/stdout redirected
+ Process /tmp/hello.x created; pid = 3088822
+ Remote debugging using stdio
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) set dprintf-style agent
+ (gdb) c
+ Continuing.
+ Unrecognized format specifier 'V' in printf
+ Command aborted.
+ (gdb)
+
+ This is exactly how GDB would handle any other invalid format
+ specifier, for example:
+
+ Reading symbols from /tmp/hello.x...
+ (gdb) dprintf call_me, "%Q", a1
+ Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
+ (gdb) set sysroot /
+ (gdb) target remote | gdbserver --once - /tmp/hello.x
+ Remote debugging using | gdbserver --once - /tmp/hello.x
+ stdin/stdout redirected
+ Process /tmp/hello.x created; pid = 3089193
+ Remote debugging using stdio
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) set dprintf-style agent
+ (gdb) c
+ Continuing.
+ Unrecognized format specifier 'Q' in printf
+ Command aborted.
+ (gdb)
+
+ The error message isn't the greatest, but improving that can be put
+ off for another day I hope.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_memory_changed method
+ Same idea as previous patches, but for memory_changed.
+
+ Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_param_changed method
+ Same idea as previous patches, but for command_param_changed.
+
+ Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_breakpoint_modified method
+ Same idea as previous patches, but for breakpoint_modified.
+
+ Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_breakpoint_deleted method
+ Same idea as previous patches, but for breakpoint_deleted.
+
+ Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_breakpoint_created method
+ Same idea as previous patches, but for breakpoint_created.
+
+ Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_tsv_modified method
+ Same idea as previous patches, but for tsv_modified.
+
+ Change-Id: I55454a2386d5450040b3a353909b26f389a43682
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_tsv_deleted method
+ Same idea as previous patches, but for tsv_deleted.
+
+ Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_tsv_created method
+ Same idea as previous patches, but for tsv_created.
+
+ Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_traceframe_changed method
+ Same idea as previous patches, but for traceframe_changed.
+
+ Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_about_to_proceed method
+ Same idea as previous patches, but for about_to_proceed. We only need
+ (and want, as far as the mi_interp implementation is concerned) to
+ notify the interpreter that caused the proceed.
+
+ Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_solib_unloaded method
+ Same idea as previous patches, but for solib_unloaded.
+
+ Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_solib_loaded method
+ Same idea as previous patches, but for solib_loaded
+
+ Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_target_resumed method
+ Same idea as previous patches, but for target_resumed.
+
+ Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_record_changed method
+ Same idea as previous patches, but for record_changed
+
+ Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_inferior_removed method
+ Same idea as previous patches, but for inferior_removed.
+
+ Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_inferior_disappeared method
+ Same idea as previous patches, but for inferior_disappeared.
+
+ For symmetry with on_inferior_appeared, I named this one
+ on_inferior_disappeared, despite the observer being called
+ inferior_exit. This is called when detaching an inferior, so I think
+ that calling it "disappeared" is a bit less misleading (the observer
+ should probably be renamed later).
+
+ Change-Id: I372101586bc9454997953c1e540a2a6685f53ef6
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_inferior_appeared method
+ Same idea as previous patches, but for inferior_appeared.
+
+ Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_inferior_added method
+ Same idea as previous patches, but for inferior_added.
+
+ mi_interp::init avoided using mi_inferior_added, since, as the comment
+ used to say, it would notify all MI interpreters. Now, it's easy to
+ only notify the new interpreter, so it's possible to just call the
+ on_inferior_added method in mi_interp::init.
+
+ Change-Id: I0eddbd5367217d1c982516982089913019ef309f
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_thread_exited method
+ Same idea as previous patches, but for thread_exited.
+
+ Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_new_thread method
+ Same idea as previous patches, but for new_thread.
+
+ Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_user_selected_context_changed method
+ Same as previous patches, but for user_selected_context_changed.
+
+ Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_command_error method
+ Same idea as the previous patches, but for command_error.
+
+ Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_sync_execution_done method
+ Same as previous patches, but for sync_execution_done. Except that
+ here, we only want to notify the interpreter that is executing the
+ command, not all interpreters.
+
+ Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_no_history method
+ Same as previous patches, but for no_history.
+
+ Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_exited method
+ Same as previous patch, but for exited. Remove the exited observable,
+ since nothing uses it anymore, and we don't have anything coming that
+ will use it.
+
+ Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_signal_exited method
+ Same as previous patch, but for signal_exited. Remove the signal_exited
+ observable, since nothing uses it anymore, and we don't have anything
+ coming that will use it.
+
+ Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_normal_stop method
+ Same idea as the previous patch, but for the normal_stop event.
+
+ Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863
+
+2023-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add interp::on_signal_received method
+ Instead of having the interpreter code registering observers for the
+ signal_received observable, add a "signal_received" virtual method to
+ struct interp. Add a interps_notify_signal_received function that loops
+ over all UIs and calls the signal_received method on the interpreter.
+ Finally, add a notify_signal_received function that calls
+ interps_notify_signal_received and then notifies the observers. Replace
+ all existing notifications to the signal_received observers with calls
+ to notify_signal_received.
+
+ Before this patch, the CLI and MI code both register a signal_received
+ observer. These observer go over all UIs, and, for those that have a
+ interpreter of the right kind, print the stop notifiation.
+
+ After this patch, we have just one "loop over all UIs", inside
+ interps_notify_signal_received. Since the interp::on_signal_received
+ method gets called once for each interpreter, the implementations only
+ need to deal with the current interpreter (the "this" pointer).
+
+ The motivation for this patch comes from a future patch, that makes the
+ amdgpu code register an observer to print a warning after the CLI's
+ signal stop message. Since the amdgpu and the CLI code both use
+ observers, the order of the two messages is not stable, unless we define
+ the priority using the observer dependency system. However, the
+ approach of using virtual methods on the interpreters seems like a good
+ change anyway, I think it's more straightforward and simple to
+ understand than the current solution that uses observers. We are sure
+ that the amdgpu message gets printed after the CLI message, since
+ observers are notified after interpreters.
+
+ Keep the signal_received, even if nothing uses if, because we will be
+ using it in the upcoming amdgpu patch implementing the warning described
+ above.
+
+ Change-Id: I4d8614bb8f6e0717f4bfc2a59abded3702f23ac4
+
+2023-05-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Mention --with/without-system-readline for --configuration
+ Simon reported that the new test-case gdb.tui/pr30056.exp fails with system
+ readline.
+
+ This is because the test-case requires a fix in readline that's present in our
+ in-repo copy of readline, but most likely not in any system readline yet.
+
+ Fix this by:
+ - mentioning --with-system-readline or --without-system-readline in the
+ configuration string.
+ - adding a new proc with_system_readline that makes this information available
+ in the testsuite.
+ - using this in test-case gdb.tui/pr30056.exp to declare it unsupported for
+ --with-system-readline.
+
+ Tested on x86_64-linux.
+
+ Reported-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-05-30 Nick Clifton <nickc@redhat.com>
+
+ Slight wording improvement for the -Ur documentation
+
+ Improve header information displayed with objdump -P for PE binaries.
+ * od-pe.c (targ_info): New array.
+ (get_target_specific_info): New function.
+ (decode_machine_number): Retire. Use get_target_specific_info instead.
+ (is_pe_object_magic): Likewise.
+ (dump_pe_file_header): Display more information.
+ Rework layout to be similar to that from 'objdump -p'.
+ Add code to handle larger than normnal AOUT headers.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: ld: Add support for linker relaxation.
+ Add ld relax support and testsuits.
+
+ ld/ChangeLog:
+
+ * emultempl/loongarchelf.em: Regenerated.
+ * testsuite/ld-elf/compressed1d.d: Xfail loongarch*-*.
+ * testsuite/ld-elf/pr26936.d: Likewise.
+ * testsuite/ld-loongarch-elf/disas-jirl.d: Regenerated.
+ * testsuite/ld-loongarch-elf/disas-jirl-32.d: Regenerated.
+ * testsuite/ld-loongarch-elf/jmp_op.d: Likewise.
+ * testsuite/ld-loongarch-elf/macro_op.d: Likewise.
+ * testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
+ * testsuite/ld-loongarch-elf/relax-align.dd: New test.
+ * testsuite/ld-loongarch-elf/relax-align.s: New test.
+ * testsuite/ld-loongarch-elf/relax.exp: New test.
+ * testsuite/ld-loongarch-elf/relax.s: New test.
+ * testsuite/ld-loongarch-elf/uleb128.dd: New test.
+ * testsuite/ld-loongarch-elf/uleb128.s: New test.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: gas: Add support for linker relaxation.
+ Add gas -mrelax and -mno-relax option.
+ Add R_LARCH_RELAX reloc for instrction if it can be relaxed.
+ ADD R_LARCH_ALIGN reloc for align pseudo instruction because relax.
+ Add ADD/SUB reloc pair for debug and exception data to calculate symbol
+ substraction because relax.
+
+ gas/ChangeLog:
+
+ * config/tc-loongarch.c:
+ (struct loongarch_cl_insn): New macro_id member.
+ (enum options): New OPTION_RELAX and OPTION_NO_RELAX.
+ (struct option): New mrelax and mno-relax.
+ (md_parse_option): Likewise.
+ (get_internal_label):
+ (loongarch_args_parser_can_match_arg_helper): Generate relax reloc.
+ (move_insn): Set fx_frag and fx_where if exist.
+ (append_fixp_and_insn): Call frag_wane and frag_new for linker relax
+ relocs.
+ (loongarch_assemble_INSNs): New loongarch_cl_insn pointer parameter.
+ (md_assemble): Fix function call.
+ (fix_reloc_insn): Likewise.
+ (md_apply_fix): Generate ADD/SUB reloc pair for debug and exception
+ data.
+ (loongarch_fix_adjustable): Delete.
+ (md_convert_frag): Generate new fix.
+ (loongarch_pre_output_hook): New function.
+ (loongarch_make_nops): Likewise.
+ (loongarch_frag_align_code): Likewise.
+ (loongarch_insert_uleb128_fixes): Likewise.
+ (loongarch_md_finish): Likewise.
+ * config/tc-loongarch.h
+ (md_allow_local_subtract): New macro define.
+ (loongarch_frag_align_code): New declare.
+ (md_do_align): Likewise.
+ (loongarch_fix_adjustable): Delete.
+ (tc_fix_adjustable): New macro define.
+ (TC_FORCE_RELOCATION_SUB_SAME): Likewise.
+ (TC_LINKRELAX_FIXUP): Likewise.
+ (TC_FORCE_RELOCATION_LOCAL): Likewise.
+ (DWARF2_USE_FIXED_ADVANCE_PC): Likewise.
+ (MD_APPLY_SYM_VALUE): Likewise.
+ (tc_symbol_new_hook): New extern.
+ (NOP_OPCODE): Delete.
+ (loongarch_pre_output_hook): New macro define.
+ (md_pre_output_hook): Likewise.
+ (md_finish): Likewise.
+ (loongarch_md_finish): New extern.
+ * testsuite/gas/all/align.d: Mark as unsupported on LoongArch.
+ * testsuite/gas/all/gas.exp: Xfail loongarch*-*.
+ * testsuite/gas/all/relax.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-irp.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-loc0.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-macro-include.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-macro.d: Likewise.
+ * testsuite/gas/elf/dwarf2-11.d: Likewise.
+ * testsuite/gas/elf/dwarf2-15.d: Likewise.
+ * testsuite/gas/elf/dwarf2-16.d: Likewise.
+ * testsuite/gas/elf/dwarf2-17.d: Likewise.
+ * testsuite/gas/elf/dwarf2-18.d: Likewise.
+ * testsuite/gas/elf/dwarf2-19.d: Likewise.
+ * testsuite/gas/elf/dwarf2-5.d: Likewise.
+ * testsuite/gas/elf/ehopt0.d: Likewise.
+ * testsuite/gas/elf/elf.exp: Likewise.
+ * testsuite/gas/elf/section11.d: Likewise.
+ * testsuite/gas/lns/lns.exp: Likewise.
+ * testsuite/gas/loongarch/jmp_op.d: Regenerated.
+ * testsuite/gas/loongarch/li.d: Likewise.
+ * testsuite/gas/loongarch/macro_op.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_32.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_large_abs.d: Likewise.
+ * testsuite/gas/loongarch/macro_op_large_pc.d: Likewise.
+ * testsuite/gas/loongarch/relax_align.d: New test.
+ * testsuite/gas/loongarch/relax_align.s: New test.
+ * testsuite/gas/loongarch/uleb128.d: New test.
+ * testsuite/gas/loongarch/uleb128.s: New test.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: binutils: Add support for linker relaxation.
+ Add support for relocs related to relax to readelf.
+
+ binutils/ChangeLog:
+
+ * readelf.c (target_specific_reloc_handling): Handle ULEB128 reloc.
+ (is_32bit_inplace_add_reloc): Handle new reloc.
+ (is_32bit_inplace_sub_reloc): Likewise.
+ (is_64bit_inplace_add_reloc): Likewise.
+ (is_64bit_inplace_sub_reloc): Likewise.
+ (is_16bit_inplace_add_reloc): Likewise.
+ (is_16bit_inplace_sub_reloc): Likewise.
+ (is_8bit_inplace_add_reloc): Likewise.
+ (is_8bit_inplace_sub_reloc): Likewise.
+ (is_6bit_inplace_sub_reloc): Likewise.
+ (is_6bit_inplace_add_reloc): New function.
+ (apply_relocations): Handle new reloc.
+ * testsuite/binutils-all/readelf.exp: Add -mno-relax option
+ for LoongArch.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: opcodes: Add support for linker relaxation.
+ Set gas default to enable relax.
+
+ opcodes/ChangeLog:
+
+ * loongarch-opc.c (struct loongarch_ASEs_option): New member relax
+ with the default value 1.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: bfd: Add support for linker relaxation.
+ Add relax support and related relocs in bfd.
+
+ bfd/ChangeLog:
+
+ * bfd-in2.h: Add relocs related to relax.
+ * elfnn-loongarch.c (struct loongarch_elf_link_hash_table): New integer
+ pointer (data_segment_phase) to monitor the data segment phase.
+ (loongarch_elf_check_relocs): Swap B21/B26 reloc sequence.
+ (loongarch_elf_adjust_dynamic_symbol): Fix code format.
+ (loongarch_reloc_rewrite_imm_insn): Fix function call.
+ (perform_relocation): Handle new relocs related to relax.
+ (RELOCATE_CALC_PC32_HI20): Fix code format.
+ (RELOCATE_CALC_PC64_HI32): Likewise.
+ (loongarch_elf_relocate_section): Handle new relocs related to relax.
+ (loongarch_relax_delete_bytes): New function.
+ (loongarch_relax_pcala_addi): Likewise.
+ (loongarch_relax_pcala_ld): Likewise.
+ (bfd_elfNN_loongarch_set_data_segment_info): Likewise.
+ (loongarch_relax_align): Likewise.
+ (loongarch_elf_relax_section): Likewise.
+ (bfd_elfNN_bfd_relax_section): New macro define.
+ * elfxx-loongarch.c (reloc_bits): New bfd point parameter.
+ (reloc_bits_b16): Likewise.
+ (reloc_bits_b21): Likewise.
+ (reloc_bits_b26): Likewise.
+ (loongarch_adjust_reloc_bitsfield): Likewise.
+ (reloc_bits_pcrel20_s2): New function.
+ (loongarch_elf_add_sub_reloc): Likewise.
+ (loongarch_elf_add_sub_reloc_uleb128): Likewise.
+ (loongarch_write_unsigned_leb128): New function.
+ * elfxx-loongarch.h (loongarch_adjust_reloc_bitsfield): New bfd point
+ parameter.
+ (bfd_elf32_loongarch_set_data_segment_info): New declare.
+ (bfd_elf64_loongarch_set_data_segment_info): Likewise.
+ (loongarch_write_unsigned_leb128): Likewise.
+ * libbfd.h: Add relocs related to relax.
+ * reloc.c: Add relocs related to relax.
+
+2023-05-30 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: include: Add support for linker relaxation.
+ Add relocs and gas LARCH_opts.relax option.
+
+ include/ChangeLog:
+
+ * elf/loongarch.h: Add relocs.
+ * opcode/loongarch.h: Add LARCH_opts.relax and macro LARCH_NOP.
+
+2023-05-30 Nick Clifton <nickc@redhat.com>
+
+ Add support for an ARMMAGIC value of 0xa00 to the PE dumper.
+
+2023-05-30 Alan Modra <amodra@gmail.com>
+
+ arm-pe objdump -P
+ arm-pe looks to be a very old PE implementation, incompatible with
+ current arm-wince-pe. arm-pe has different relocations and uses
+ ARMMAGIC which has this comment: "I just made this up". Well, OK, I
+ don't know the history but it was probably before Microsoft "just made
+ up" their constants for ARM windows CE.
+
+ This patch supports objdump -P for arm-pe, and another magic constant
+ that may appear in object files. (I don't think binutils generates
+ files using ARMV7PEMAGIC aka IMAGE_FILE_MACHINE_ARMNT.)
+
+ * od-pe.c (is_pe_object_magic): Handle IMAGE_FILE_MACHINE_ARMNT
+ and ARMMAGIC.
+
+2023-05-30 Alan Modra <amodra@gmail.com>
+
+ Define IMAGE_FILE_MACHINE_ARMNT
+ Same value as ARMV7PEMAGIC.
+ https://learn.microsoft.com/en-us/windows/win32/sysinfo/image-file-machine-constants
+
+ * coff/pe.h (IMAGE_FILE_MACHINE_ARMNT): Define.
+
+2023-05-30 Alan Modra <amodra@gmail.com>
+
+ Don't define COFF_MAGIC
+ This macro was unused apart from aout/encap.h, which has been deleted.
+
+ * config/tc-arm.h (COFF_MAGIC): Don't define.
+ * config/tc-sh.h (COFF_MAGIC): Don't define.
+ * config/tc-z80.h (COFF_MAGIC): Don't define.
+ * config/tc-z8k.h (COFF_MAGIC): Don't define.
+
+2023-05-30 Alan Modra <amodra@gmail.com>
+
+ Delete include/aout/encap.h
+ This file is unused and as the header comment says, obsolete.
+
+ Regen binutils POTFILES.in
+ for od-pe.c
+
+2023-05-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix linefeed scrolling in tuiterm
+ I came across a bug in the implementation of line feed in tuiterm, and added a
+ unit test that exposes it.
+
+ Before sending the line feed we have:
+ ...
+ Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 3):
+ 0 abcdefgh
+ 1 ijklmnop
+ 2 qrstuvwx
+ 3 yz01234
+ ...
+ and after it we have:
+ ...
+ Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 1):
+ 0 ijklmnop
+ 1 qrstuvwx
+ 2 yz01234
+ 3 yz01234
+ ...
+
+ Note how the cursor started at row 3 and after the line feed ended up at
+ row 1, while it should have stayed in row 3.
+
+ Fix this by moving "incr _cur_row -1" one level up in the loop nest in
+ proc _ctl_0x0a.
+
+ Tested on x86_64-linux.
+
+2023-05-29 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/mi: fix ^running record with multiple MI interpreters
+ I stumbled on the mi_proceeded and running_result_record_printed
+ globals, which are shared by all MI interpreter instances (it's unlikely
+ that people use multiple MI interpreter instances, but it's possible).
+ After poking at it, I found this bug:
+
+ 1. Start GDB in MI mode
+ 2. Add a second MI interpreter with the new-ui command
+ 3. Use -exec-run on the second interpreter
+
+ This is the output I get on the first interpreter:
+
+ =thread-group-added,id="i1"
+ ~"Reading symbols from a.out...\n"
+ ~"New UI allocated\n"
+ (gdb)
+ =thread-group-started,id="i1",pid="94718"
+ =thread-created,id="1",group-id="i1"
+ ^running
+ *running,thread-id="all"
+
+ And this is the output I get on the second intepreter:
+
+ =thread-group-added,id="i1"
+ (gdb)
+ -exec-run
+ =thread-group-started,id="i1",pid="94718"
+ =thread-created,id="1",group-id="i1"
+ *running,thread-id="all"
+
+ The problem here is that the `^running` reply to the -exec-run command
+ is printed on the wrong UI. It is printed on the first one, it should
+ be printed on the second (the one on which we sent the -exec-run).
+
+ What happens under the hood is that captured_mi_execute_command, while
+ executing a command for the second intepreter, clears the
+ running_result_record_printed and mi_proceeded globals.
+ mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets
+ called for the first intepreter first. Since the
+
+ !running_result_record_printed && mi_proceeded
+
+ condition is true, it prints a ^running, and sets
+ running_result_record_printed. When mi_on_resume_1 gets called for the
+ second interpreter, running_result_record_printed is already set, so
+ ^running is not printed there.
+
+ It took me a while to understand the relationship between these two
+ variables. I think that in the end, this is what we want to track:
+
+ 1. When executing an MI command, take note if that command causes a
+ "proceed". This is done in mi_about_to_proceed.
+ 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want
+ to output a ^running record. And we want to remember that we did,
+ because...
+ 3. Back in captured_mi_execute_command, if we did not output a
+ ^running, we want to output a ^done.
+
+ Moving those two variables to the mi_interp struture appears to fix it.
+ Only for the interpreter doing the -exec-run command does the
+ running_result_record_printed flag get cleared, and therefore only or
+ that one does the ^running record get printed.
+
+ Add a new test for this, that does pretty much what the reproducer above
+ shows. Without the fix, the test fails because
+ mi_send_resuming_command_raw never sees the ^running record.
+
+ Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+
+2023-05-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-28 Tom de Vries <tdevries@suse.de>
+
+ [readline] Fix double free in _rl_scxt_dispose
+ Consider the following scenario. We start gdb in TUI mode:
+ ...
+ $ gdb -q -tui
+ ...
+ and type ^R which gives us the reverse-isearch prompt in the cmd window:
+ ...
+ (reverse-i-search)`':
+ ...
+ and then type "foo", right-arrow-key, and ^C.
+
+ In TUI mode, gdb uses a custom rl_getc_function tui_getc.
+
+ When pressing the right-arrow-key, tui_getc:
+ - attempts to scroll the TUI src window, without any effect, and
+ - returns 0.
+
+ The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char:
+ ...
+ /* We intercepted the control character, so return 0 (which readline
+ will interpret as a no-op). */
+ return 0;
+ ...
+
+ However, after this 0 is returned by the rl_read_key () call in
+ _rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets
+ 0 as the first part of an utf-8 multibyte char, and tries to read the next
+ char.
+
+ In this state, the ^C takes effect and we run into a double free because
+ _rl_isearch_cleanup is called twice.
+
+ Both these issues need fixing independently, though after fixing the first we
+ no longer trigger the second.
+
+ The first issue is caused by the subtle difference between:
+ - a char array containing 0 chars, which is zero-terminated, and
+ - a char array containing 1 char, which is zero.
+
+ In mbrtowc terms, this is the difference between:
+ ...
+ mbrtowc (&wc, "", 0, &ps);
+ ...
+ which returns -2, and:
+ ...
+ mbrtowc (&wc, "", 1, &ps);
+ ...
+ which returns 0.
+
+ Note that _rl_read_mbstring calls _rl_get_char_len without passing it an
+ explicit length parameter, and consequently it cannot distinguish between the
+ two, and defaults to the "0 chars" choice.
+
+ Note that the same problem doesn't exist in _rl_read_mbchar.
+
+ Fix this by defaulting to the "1 char" choice in _rl_get_char_len:
+ ...
+ - if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src))
+ + if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src))
+ ...
+
+ The second problem happens when the call to _rl_search_getchar in
+ _rl_isearch_callback returns. At that point _rl_isearch_cleanup has already
+ been called from the signal handler, but we proceed regardless, using a cxt
+ pointer that has been freed.
+
+ Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to
+ _rl_search_getchar:
+ ...
+ c = _rl_search_getchar (cxt);
+ + if (!RL_ISSTATE (RL_STATE_ISEARCH))
+ + return 1;
+ ...
+
+ Tested on x86_64-linux.
+
+ Approved-By: Chet Ramey <chet.ramey@case.edu>
+
+ PR tui/30056
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056
+
+2023-05-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-27 Nelson Chu <nelson@nelson.ba.rivosinc.com>
+
+ [PR ld/22263][PR ld/25694] RISC-V: Avoid dynamic TLS relocs in PIE.
+ Lots of targets already fixed the TEXTREL problem for TLS in PIE.
+
+ * For PR ld/25694,
+ In the check_reloc, refer to spare and loongarch, they don't need to reserve
+ any local dynamic reloc for TLS LE in pie/pde, and similar to other targets.
+ So it seems like riscv was too conservative to estimate the TLS LE before.
+ Just break and don't goto static_reloc for TLS LE in pie/pde can fix the
+ TEXTREL problem.
+
+ * For PR ld/22263,
+ The risc-v code for TLS GD/IE in the relocate_section seems same as MIPS port.
+ So similar to MIPS, pr22570, commits 9143e72c6d4d and 1cb83cac9a89, it seems
+ also the right way to do the same thing for risc-v.
+
+ On risc-v, fixes
+ FAIL: Build pr22263-1
+
+ RISC-V haven't supported the TLS transitions, so will need the same fix (use
+ bfd_link_dll) in the future.
+
+ bfd/
+ PR ld/22263
+ PR ld/25694
+ * elfnn-riscv.c (riscv_elf_check_relocs): Replace bfd_link_pic with
+ bfd_link_dll for TLS IE. Don't need to reserve the local dynamic
+ relocation for TLS LE in pie/pde, and report error in pic just like
+ before.
+ (riscv_elf_relocate_section): For TLS GD/IE, use bfd_link_dll rather
+ than !bfd_link_pic in determining the dynamic symbol index. Avoid
+ the index of -1.
+
+2023-05-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-26 Nick Clifton <nickc@redhat.com>
+
+ Enhance objdump's --private option so that it can display the contents of PE format files.
+ * od-pe.c: New file: Dumps fields in PE format headers.
+ * configure.ac (od_vectors): Add objdump_private_desc_pe for PE format targets. (od_files): Add od-pe for PE format targets.
+ * configure: Regenerate.
+ * Makefile.am (CFILES): Add od-pe.c (EXTRA_objdump_SOURCE): Likewise.
+ * Makefile.in: Generate.
+ * NEWS: Mention the new feature.
+ * doc/binutils.texi: Document the new support.
+ * objdump.c (wide_output): Change from local to global.
+ * objdump.h (wide_output): Prototype. (objdump_private_desc_pe): Prototype.
+ * testsuite/binutils-all/objdump.exp: Add a test of the new feature.
+
+2023-05-26 Andreas Schwab <schwab@linux-m68k.org>
+
+ Remove duplicate definition
+ * coff/pe.h (IMAGE_FILE_MACHINE_AMD64): Remove duplicate
+ definition. Alphabetize.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ x86: fix disassembler build after 1a3b4f90bc5f
+ In commit 1a3b4f90bc5f ("x86: convert two pointers to (indexing)
+ integers") I neglected the fact that compilers may warn about comparing
+ ptrdiff_t (signed long) with size_t (unsigned long) values. Since just
+ before we've checked that the value is positive, simply add a cast
+ (despite my dislike for casts).
+
+2023-05-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add test-case gdb.tui/color-prompt.exp
+ Add a test-case that sets a prompt with color in TUI.
+
+ The line containing the prompt is shown by get_line_with_attrs as follows:
+ ...
+ <fg:31>(gdb) <fg:default>
+ ...
+
+ The 31 means red, but only for foreground colors, for background colors 41
+ means red.
+
+ Make this more readable by using color names for both foreground and
+ background, such that we have instead:
+ ....
+ <fg:red>(gdb) <fg:default>
+ ...
+
+ Tested on x86_64-linux.
+
+2023-05-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add invisible and blinking attributes in tuiterm
+ I noticed curses using the invisible and blinking attributes.
+
+ Add these in tuiterm.
+
+ Tested on x86_64-linux.
+
+2023-05-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix reverse attribute in tuiterm
+ I noticed in proc Term::_csi_m arguments that while parameters 7 and 27 are
+ supposed to set the reverse attribute to 1 and 0, in fact it's set to 1 in
+ both cases:
+ ...
+ 7 {
+ set _attrs(reverse) 1
+ }
+ ...
+ 27 {
+ set _attrs(reverse) 1
+ }
+ ...
+
+ Fix this and add a regression test in gdb.tui/tuiterm.exp.
+
+ Tested on x86_64-linux.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ iamcu: suppress tests which can't possibly work
+ With neither --32 nor --64 passed to gas, advanced features like AVX
+ aren't available without explicitly enabling them.
+
+ x86-64: improve gas diagnostic when no 32-bit target is configured
+ Make this similar to --64 and --x32: Check whether a suitable target
+ exists.
+
+ x86-64: conditionalize tests using --32
+ Using this option doesn't really work when no support for any 32-bit
+ target was configured in (as is the case for at least cloudabi and
+ rdos).
+
+ x86: split gas testsuite .exp file
+ The set of 32-bit-only and 64-bit-only tests has grown quite large. In
+ particular when one's after only the results for the 64-bit set, having
+ them live in a separate .exp file is easier / faster.
+
+ x86: convert two pointers to (indexing) integers
+ This in particular reduces the number of pointers to non-const that we
+ have (and that could potentially be used for undue modification of
+ state). As a result, fetch_code()'s 2nd parameter can then also become
+ pointer-to-const.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ x86: disassembling over-long insns
+ The present way of dealing with them - misusing MAX_MNEM_SIZE, which has
+ nothing to do with insn length - leads to inconsistent results. Since we
+ allow for up to MAX_CODE_LENGTH - 1 prefix bytes (which then could be
+ followed by another MAX_CODE_LENGTH "normal" insn bytes until we're done
+ decoding), size the_buffer[] accordingly.
+
+ Move struct dis_private down to be able to use MAX_CODE_LENGTH without
+ moving its #define. While doing this also alter the order to have the
+ potentially large array last.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ x86: use fixed-width type for codep and friends
+ This first of all removes a dependency on bfd_byte and unsigned char
+ being the same types. It further eliminates the need to mask by 0xff
+ when fetching values (which wasn't done fully consistently anyway),
+ improving code legibility.
+
+ While there, where possible add const.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ x86: figure braces aren't really part of mnemonics
+ Instead they're separators for pseudo-prefixes. Don't insert them in
+ mnemonic_chars[], handling them explicitly in parse_insn() instead. Note
+ that this eliminates the need for another separator after a pseudo-
+ prefix. While maybe not overly interesting for a following real
+ mnemonic, I view this as quite desirable between multiple successive
+ pseudo-prefixes (bringing things in line with the other use of figure
+ braces in AVX512's zeroing-masking).
+
+ Drop the unused is_mnemonic_char() at this occasion.
+
+2023-05-26 Jan Beulich <jbeulich@suse.com>
+
+ x86: de-duplicate operand_special_chars[] wrt extra_symbol_chars[]
+ Having to add characters to both arrays can easily lead to oversights.
+ Consuming extra_symbol_chars[] when populating operand_chars[] also
+ allows to drop two special cases in md_begin().
+
+ Constify operand_special_chars[] at this occasion.
+
+2023-05-26 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe/doc: minor improvements for readability
+ libsframe/
+ * sframe-spec.texi: Cosmetic fixes.
+
+2023-05-26 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: revisit sframe_find_fre API
+ Inspite of implementing a rather simple functionality, this function was
+ relatively difficult to follow, and maintain. Some changes are done now
+ to address that - refactor the function and use better names to make it
+ more readable.
+
+ The changes to the implementation do not cause any change in the
+ contract of the API.
+
+ libsframe/
+ * sframe.c (sframe_fre_get_end_ip_offset): to here...
+ (sframe_find_fre): Refactor some bits from...
+
+2023-05-26 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use const char * consistently for immutable FRE buffers
+ libsframe/
+ * sframe.c (sframe_decode_fre): Use const char * datatype when
+ handling buffer containing the FREs.
+ (sframe_fre_get_end_ip_offset): Likewise.
+ (sframe_find_fre): Likewise.
+ (sframe_decoder_get_fre): Likewise.
+
+ libsframe: use uint8_t data type for FRE info related stubs
+ libsframe/
+ * sframe.c: Use uint8_t for FRE offset count and FRE offset
+ size. Use uint8_t for FRE info word as well.
+
+2023-05-26 Alan Modra <amodra@gmail.com>
+
+ PR22263 ld test
+ A number of targets that I test regularly fail the "Build pr22263-1"
+ test for various reasons.
+
+ arm-linux-gnueabi: "undefined reference to `__aeabi_read_tp'"
+ ia64-linux-gnu: "Explicit stops are ignored in auto mode"
+ m68k-linux-gnu: "undefined reference to `__m68k_read_tp'"
+ microblaze-linux-gnu: "undefined reference to `__tls_get_addr'"
+ nios2-linux-gnu, s390-linux-gnu and sh4-linux-gnu have a tprel reloc in .got
+ riscv64-linux-gnu has a dynamic relocation in text
+
+ So only riscv really fails the pr. The rest fail due to test issues
+ or lack of a linker optimisation. Lack of an optimisation isn't
+ really a fail, but it's worth keeping the test to ensure those
+ optimisations don't regress. The xfail targets may not be an
+ exhaustive list. This just tidies test results for those for which I
+ have cross compilers installed.
+
+ PR 22263
+ * testsuite/ld-elf/tls.exp: Split pr22263 test into two parts,
+ one to check for -z text errors, the other to check tprel
+ linker optimisation. Supply needed symbols and assembler flags.
+ xfail the linker optimisation on targets known to fail.
+
+2023-05-26 Tom Tromey <tom@tromey.com>
+
+ Make MI commands const-correct
+ I've had this patch for a while now and figured I'd update it and send
+ it. It changes MI commands to use a "const char * const" for their
+ argv parameter.
+
+ Regression tested on x86-64 Fedora 36.
+
+ Acked-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-05-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-25 Ciaran Woodward <ciaranwoodward@xmos.com>
+
+ Fix scoped_value_mark not working with empty value chain
+ The scoped_value_mark helper class was setting its internal
+ mark value to NULL to indicate that the value chain had already
+ been freed to mark.
+
+ However, value_mark() also returns NULL if the value chain is
+ empty at the time of call.
+
+ This lead to the situation that if the value chain was empty
+ at the time the scoped_value_mark was created, the class
+ would not correctly clean up the state when it was destroyed,
+ because it believed it had already been freed.
+
+ I noticed this because I was setting a watchpoint very early
+ in my debug session, and it was becoming a software watchpoint
+ rather than hardware. Running any command that called evaluate()
+ beforehand (such as 'x 0') would mean that a hardware watchpoint
+ was correctly used. After some careful examination of the
+ differences in execution, I noticed that values were being freed
+ later in the 'bad case', which lead me to notice the issue with
+ scoped_value_mark.
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove breakpoint_pointer_iterator
+ Remove the breakpoint_pointer_iterator layer. Adjust all users of
+ all_breakpoints and all_tracepoints to use references instead of
+ pointers.
+
+ Change-Id: I376826f812117cee1e6b199c384a10376973af5d
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: make filtered_iterator::operator* return the same thing as underlying iterator
+ This is the same idea as the previous patch, but for filtered_iterator.
+ Without this patch, I would see this when applying the patch that
+ removes reference_to_pointer_iterator from breakpoint_range:
+
+ CXX breakpoint.o
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void download_tracepoint_locations()’:
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:11007:41: error: cannot allocate an object of abstract type ‘breakpoint’
+ 11007 | for (breakpoint &b : all_tracepoints ())
+ | ^
+ In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
+ from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
+ from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
+ from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
+ from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note: because the following virtual functions are pure within ‘breakpoint’:
+ 619 | struct breakpoint : public intrusive_list_node<breakpoint>
+ | ^~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note: ‘virtual breakpoint::~breakpoint()’
+ 250 | breakpoint::~breakpoint ()
+ | ^~~~~~~~~~
+
+ Change-Id: I05285ff27d21cb0ab80cba392ec4e959167e3cd7
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: make basic_safe_iterator::operator* return the same thing as underlying iterator
+ Using the following patch that removes the reference_to_pointer_iterator
+ from breakpoint_range, I would get:
+
+ CXX breakpoint.o
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’:
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’
+ 3030 | for (breakpoint &b : all_breakpoints_safe ())
+ | ^
+ In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
+ from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
+ from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
+ from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
+ from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note: because the following virtual functions are pure within ‘breakpoint’:
+ 619 | struct breakpoint : public intrusive_list_node<breakpoint>
+ | ^~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note: ‘virtual breakpoint::~breakpoint()’
+ 250 | breakpoint::~breakpoint ()
+ | ^~~~~~~~~~
+
+ This is because the operator* method of the basic_safe_iterator iterator
+ wrapper returns a value_type. So, even if the method of the underlying
+ iterator (breakpoint_iterator, an intrusive_list iterator) returns a
+ `breakpoint &`, the method of the wrapper returns a `breakpoint`.
+
+ I think it would make sense for iterator wrappers such as
+ basic_safe_iterator to return the exact same thing as the iterator they
+ wrap. At least, it fixes my problem.
+
+ Change-Id: Ibbcd390ac03d2fb6ae4854923750c8d7c3c04e8a
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: link breakpoints with intrusive_list
+ Change-Id: I043d8d6f3dd864d80d5088f6ffc2c098337249ea
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove bp_location_pointer_iterator
+ Remove the bp_location_pointer_iterator layer. Adjust all users of
+ breakpoint::locations to use references instead of pointers.
+
+ Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use intrusive_list for breakpoint locations
+ Replace the hand-maintained linked lists of breakpoint locations with
+ and intrusive list.
+
+ - Remove breakpoint::loc, add breakpoint::m_locations.
+
+ - Add methods for the various manipulations that need to be done on the
+ location list, while maintaining reasonably good encapsulation.
+
+ - bp_location currently has a default constructor because of one use
+ in hoist_existing_locations. hoist_existing_locations now returns a
+ bp_location_list, and doesn't need the default-constructor
+ bp_location anymore, so remove the bp_location default constructor.
+
+ - I needed to add a call to clear_locations in delete_breakpoint to
+ avoid a use-after-free.
+
+ - Add a breakpoint::last_loc method, for use in
+ set_breakpoint_condition.
+
+ bp_location_range uses reference_to_pointer_iterator, so that all
+ existing callers of breakpoint::locations don't need to change right
+ now. It will be removed in the next patch.
+
+ The rest of the changes are to adapt the call sites to use the new
+ methods, of breakpoint::locations, rather than breakpoint::loc directly.
+
+ Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add missing increment/decrement operators to reference_to_pointer_iterator
+ Using the following patch, I would get this build failure:
+
+ CXX breakpoint.o
+ In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66,
+ from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36,
+ from /usr/include/c++/13.1.1/bits/hashtable.h:35,
+ from /usr/include/c++/13.1.1/bits/unordered_map.h:33,
+ from /usr/include/c++/13.1.1/unordered_map:41,
+ from /usr/include/c++/13.1.1/functional:63,
+ from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
+ from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206,
+ from /home/smarchi/src/binutils-gdb/gdb/defs.h:26,
+ from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20:
+ /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’:
+ /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21: required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’
+ /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19: required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’
+ /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19: required from here
+ /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’)
+ 179 | --__i;
+ | ^~~~~
+
+ This points out that while intrusive_list_iterator has an operator--,
+ the reference_to_pointer_iterator wrapper does not. I'm not to sure why
+ the compiler chooses the overload of __advance that accepts a
+ _BidirectionalIterator, given that reference_to_pointer_iterator can't
+ be decremented, but adding those operators seems like the right thing to
+ do in any case, for completeness.
+
+ Change-Id: I8e2044b6734fadf0f21093047cf35bb7080dbdc3
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add breakpoint::first_loc methods
+ Add convenience first_loc methods to struct breakpoint (const and
+ non-const overloads). A subsequent patch changes the list of locations
+ to be an intrusive_list and makes the actual list private, so these
+ spots would need to change from:
+
+ b->loc
+
+ to something ugly like:
+
+ *b->locations ().begin ()
+
+ That would make the code much heavier and not readable. There is a
+ surprisingly big number of places that access the first location of
+ breakpoints. Whether this is correct, or these spots fail to consider
+ the possibility of multi-location breakpoints, I don't know. But
+ anyhow, I think that using this instead:
+
+ b->first_loc ()
+
+ conveys the intention better than the other two forms.
+
+ Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add breakpoint "has locations" methods
+ Add three convenience methods to struct breakpoint:
+
+ - has_locations: returns true if the breakpoint has at least one
+ location
+ - has_single_location: returns true if the breakpoint has exactly one
+ location
+ - has_multiple_locations: returns true if the breakpoint has more than
+ one location
+
+ A subsequent patch changes the list of breakpoints to be an
+ intrusive_list, so all these spots would need to change. But in any
+ case, I think that this:
+
+ if (b->has_multiple_locations ())
+
+ conveys the intention better than:
+
+ if (b->loc != nullptr && b->loc->next != nullptr)
+
+ Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: constify breakpoint::print_it parameter
+ The print_it method itself is const. In a subsequent patch, the
+ locations that come out of a const breakpoint will be const as well. It
+ will therefore be needed to make the last_loc output parameter const as
+ well. Make that change now to reduce the size of the following patches.
+
+ Change-Id: I7ed962950bc9582646e31e2e42beca2a1c9c5105
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make some breakpoint methods use `this`
+ Some implementations of breakpoint::check_status and
+ breakpoint::print_it do this:
+
+ struct breakpoint *b = bs->breakpoint_at;
+
+ bs->breakpoint_at is always the same as `this` (we can get convinced by
+ looking at the call sites of check_status and print_it), so it would
+ just be clearer to access fields through `this` instead.
+
+ Change-Id: Ic542a64fcd88e31ae2aad6feff1da278c7086891
+ Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: get gdbarch from syscall_catchpoint instead of location
+ I noticed some methods of syscall_catchpoint doing this:
+
+ struct gdbarch *gdbarch = loc->owner->gdbarch;
+
+ `loc` is the list of locations of this catchpoint. Logically, the owner
+ the locations are this catchpoint. So this just ends up getting
+ this->gdbarch. Remove the unnecessary indirection through the loc.
+
+ syscall_catchpoint::print_recreate does something slightly different,
+ getting its arch from the loc:
+
+ struct gdbarch *gdbarch = loc->gdbarch;
+
+ I suppose it's always going to be the same arch, so get it from the
+ catchpoint there too.
+
+ Change-Id: I6f6a6f8e0cd7cfb754cecfb6249e71ec12ba4855
+ Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-25 Alan Modra <amodra@gmail.com>
+
+ PR29189, dlltool delaylibs corrupt float/double arguments
+ PR 29189
+ * dlltool.c (i386_x64_trampoline): Save and restore xmm0-5. Make
+ use of parameter save area for integer arg regs. Comment.
+
+2023-05-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add support for references to checked_static_cast
+ Add a checked_static_cast overload that works with references. A bad
+ dynamic cast with references throws std::bad_cast, it would be possible
+ to implement the new overload based on that, but it seemed simpler to
+ just piggy back off the existing function.
+
+ I found some potential uses of this new overload in amd-dbgapi-target.c,
+ update them to illustrate the use of the new overload. To build
+ amd-dbgapi-target.c, on needs the amd-dbgapi library, which I don't
+ expect many people to have. But I have it, and it builds fine here. I
+ did test the new overload by making a purposely bad cast and it did
+ catch it.
+
+ Change-Id: Id6b6a7db09fe3b4aa43cddb60575ff5f46761e96
+ Reviewed-By: Lancelot SIX <lsix@lancelotsix.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix race in gdb.server/multi-ui-errors.exp
+ After this commit:
+
+ commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd
+ Date: Thu Mar 9 10:45:03 2023 +0100
+
+ [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
+
+ I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
+ which looked like this:
+
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
+ interrupt
+ (gdb)
+ Program received signal SIGINT, Interrupt.
+ 0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
+ FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
+ PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
+ p server_pid
+ $1 = 718174
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid
+
+ This is triggered by this code in gdb.server/multi-ui-errors.exp:
+
+ gdb_test "interrupt"
+
+ gdb_test_multiple "" "interrupt arrived" {
+ -re "Program received signal SIGINT, Interrupt\\.\r\n" {
+ pass $gdb_test_name
+ }
+ }
+
+ The problem here is that the first interrupt will trigger the prompt
+ to be printed, and then, after some time the inferior will be
+ interrupted.
+
+ However the default pattern for gdb_test includes a '$' end anchor.
+ If expect sees the prompt with nothing following it then everything is
+ fine, and the test passes.
+
+ However, if the interrupt is quick and so what expect sees is this:
+
+ (gdb)
+ Program received signal SIGINT, Interrupt.
+ 0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
+
+ In this case the end anchor means that the gdb_test fails to match,
+ and eventually times out.
+
+ Fix this by passing -no-prompt-anchor to gdb_test.
+
+ Reviewed-By: Tom de Vries <tdevries@suse.de>
+
+2023-05-24 Matti Puputti <matti.puputti@intel.com>
+
+ gdb, infcmd: Support jump command with same line in multiple symtabs
+ If a header file defining a static function is included in multiple source
+ files, each calling the function, and GDB is asked to jump to a line inside
+ that function, there would be multiple locations matching the target. The
+ solution in this commit is to select the location in the current symtab.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-24 Tom Tromey <tromey@adacore.com>
+
+ Add "args" and "env" parameters to DAP launch request
+ This patch augments the DAP launch request with some optional new
+ parameters that let the client control the command-line arguments and
+ the environment of the inferior.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-24 Tom Tromey <tromey@adacore.com>
+
+ Add attributes and methods to gdb.Inferior
+ This adds two new attributes and three new methods to gdb.Inferior.
+
+ The attributes let Python code see the command-line arguments and the
+ name of "main". Argument setting is also supported.
+
+ The methods let Python code manipulate the inferior's environment
+ variables.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-24 Andreas Schwab <schwab@suse.de>
+
+ Remove accidentally added file
+
+2023-05-24 Alan Modra <amodra@gmail.com>
+
+ Don't optimise bfd_seek to same position
+ It's not worth avoiding an fseek to the same position, and can cause
+ problems if the linker's output file (which is opened "w+") is read,
+ because that can result in writing, reading, then writing again.
+
+ POSIX.1-2017 (IEEE Std 1003.1) says of fopen:
+ "When a file is opened with update mode ('+' as the second or third
+ character in the mode argument), both input and output may be
+ performed on the associated stream. However, the application shall
+ ensure that output is not directly followed by input without an
+ intervening call to fflush() or to a file positioning function
+ (fseek(), fsetpos(), or rewind()), and input is not directly followed
+ by output without an intervening call to a file positioning function,
+ unless the input operation encounters end-of-file."
+
+ * bfdio.c (bfd_seek): Always call iovec->bseek.
+
+2023-05-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-23 Tom Tromey <tromey@adacore.com>
+
+ Handle DAP evaluate request without a frame ID
+ DAP specifies that if an evaluate request does not have a frameID
+ parameter, then the expression is evaluated in the global scope.
+
+2023-05-23 Tom Tromey <tromey@adacore.com>
+
+ Add global_context parameter to gdb.parse_and_eval
+ This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
+ This lets users request a parse that is done at "global scope".
+
+ I considered letting callers pass in a block instead, with None
+ meaning "global" -- but then there didn't seem to be a clean way to
+ express the default for this parameter.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-23 Tom Tromey <tromey@adacore.com>
+
+ Add flags to parse_and_eval
+ This adds a flags parameter to parse_and_eval.
+
+ Add PARSER_LEAVE_BLOCK_ALONE flag
+ This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API
+ to respect it. This flag lets callers avoid any change to the
+ passed-in block and expression PC, letting them specify the context
+ exactly. In particular, now nullptr can be used to indicate that the
+ parse should not examine any local variables.
+
+ Add PARSER_DEBUG flag
+ This adds a new PARSER_DEBUG constant and changes the parser code to
+ use it. This lets us make the 'parser_debug' global 'static'.
+
+ Rearrange parser_state
+ This patch mildly rearranges parser_state, moving all the bool fields
+ together.
+
+ Boolify parser_state::comma_terminates
+ parser_state::comma_terminates ought to be boolean, and changing it
+ does not require any other changes.
+
+ Simplify parser_state constructor
+ This simplifies the parser_state constructor by having it accept a
+ parser_flags parameter.
+
+ Introduce and use parser flags
+ This patch adds a new parser_flags type and changes the parser APIs to
+ use it rather than a collection of 'int' and 'bool'. More flags will
+ be added in subsquent patches.
+
+ Move innermost_block_tracker to expression.h
+ I think parser-defs.h should hold declarations that can be used by
+ parser implementations, whereas expression.h should hold declarations
+ that are used by code that wants to call a parser. Following this
+ logic, this patch moves innermost_block_tracker to expression.h.
+
+ Avoid forward declaration in parse.c
+ This minorly rearranges parse.c to avoid the need for a forward
+ declaration.
+
+ Implement DAP loadedSources request
+ This implements the DAP loadedSources request, using gdb.execute_mi to
+ avoid having to write another custom Python API.
+
+2023-05-23 Tom Tromey <tromey@adacore.com>
+
+ Implement gdb.execute_mi
+ This adds a new Python function, gdb.execute_mi, that can be used to
+ invoke an MI command but get the output as a Python object, rather
+ than a string. This is done by implementing a new ui_out subclass
+ that builds a Python object.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-23 Tom Tromey <tromey@adacore.com>
+
+ Add second mi_parse constructor
+ This adds a second mi_parse constructor. This constructor takes a
+ command name and vector of arguments, and does not do any escape
+ processing. This also changes mi_parse::args to handle parse objects
+ created this new way.
+
+ Introduce mi_parse helper methods
+ This introduces some helper methods for mi_parse that handle some of
+ the details of parsing. This approach lets us reuse them later.
+
+ Introduce "static constructor" for mi_parse
+ Change the mi_parse function to be a static method of mi_parse. This
+ lets us remove the 'set_args' setter function.
+
+ Change mi_parse_argv to a method
+ This changes mi_parse_argv to be a method of mi_parse. This is just a
+ minor cleanup.
+
+ Use accessor for mi_parse::args
+ This changes mi_parse::args to be a private member, retrieved via
+ accessor. It also changes this member to be a std::string. This
+ makes it simpler for a subsequent patch to implement different
+ behavior for argument parsing.
+
+ Use member initializers in mi_parse
+ This changes mi_parse to use member initializers rather than a
+ constructor. This is easier to follow.
+
+ Use field_signed from Python MI commands
+ If an MI command written in Python includes a number in its output,
+ currently that is simply emitted as a string. However, it's
+ convenient for a later patch if these are emitted using field_signed.
+ This does not make a difference to ordinary MI clients.
+
+2023-05-23 Aaron Merey <amerey@redhat.com>
+
+ gdb/cli-out.c: clear_current_line shouldn't trigger pagination prompt
+ clear_current_line overwrites the current line with chars_per_line
+ blank spaces. Printing the final space triggers a condition in
+ pager_file::puts that causes lines_printed to be incremented. If
+ lines_printed becomes greater than or equal to lines_allowed, the
+ pagination prompt will appear if enabled.
+
+ In this case the prompt is unnecessary since after printing the final
+ space clear_current_line immediately moves the cursor to the beginning
+ of the line with '\r'. A new line isn't actually started, so the prompt
+ ends up being spurious.
+
+ Additionally it's possible for gdb to crash during this pagination prompt.
+ Answering the prompt with 'q' throws an exception intended to bring gdb
+ back to the main event loop. But since commit 0fea10f32746,
+ clear_current_line may be called under the progress_update destructor.
+ The exception will try to propagate through the destructor, causing an abort.
+
+ To fix this, pagination is disabled for the duration for clear_current_line.
+ clear_current_line is also renamed to clear_progress_notify to help
+ indicate that it is a special purpose function intended for use with
+ do_progress_notify.
+
+ Acked-by: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-23 Michael Matz <matz@suse.de>
+
+ PR30437 aarch64: make RELA relocs idempotent
+ normally RELA relocs in BFD should not consider the contents of the
+ relocated place. The aarch64 psABI is even stricter, it specifies
+ (section 5.7.16) that all RELA relocs _must_ be idempotent.
+
+ Since the inception of the aarch64 BFD backend all the relocs have a
+ non-zero src_mask, and hence break this invariant. It's normally not
+ a very visible problem as one can see it only when the relocated place
+ already contains a non-zero value, which usually only happens sometimes
+ when using 'ld -r' (or as in the testcase when jumping through hoops to
+ generate the relocations). Or with alternative toolchains that do encode
+ stuff in the relocated places with the assumption that a relocation
+ to that place ignores whatever is there (as they can according to
+ the psABI).
+
+ Golang is such a toolchain and https://github.com/golang/go/issues/39927
+ is ultimately caused by this problem: the testcase testGCData failing
+ is caused by the garbage collection data-structure to describe a type
+ containing pointers to be wrong. It's wrong because a field that's
+ supposed to contain a file-relative offset (to some gcbits) has a
+ relocation applied and that relocation has an addend which also is
+ already part of the go-produced object file (so the addend is
+ implicitely applied twice).
+
+ bfd/
+ PR ld/30437
+ * elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
+ if all relocation descriptors.
+
+ ld/
+ * testsuite/ld-aarch64/rela-idempotent.s: New testcase.
+ * testsuite/ld-aarch64/rela-idempotent.d: New.
+ * testsuite/ld-aarch64/aarch64-elf.exp: Run it.
+
+2023-05-23 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the opcodes directory
+
+2023-05-23 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.exp
+ When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
+ machine, the compiled test case would segfault when returning from
+ the function can_relocate_call, with a suggestion of a broken stack.
+ The example assembly in the commment was the following:
+
+ f:
+ MOV $1, %[ok]
+ JMP end
+ set_point0:
+ CALL f ; tracepoint here.
+ end:
+
+ And the segmentation fault happening at the final "ret" instruction of
+ can_relocate_call. Looking at the disassembled version of the later
+ half of the important function, we see:
+
+ Clang version (f starting at 11a4):
+ 00000000000011ae <set_point0>:
+ 11ae: e8 f1 ff ff ff callq 11a4 <can_relocate_call+0x14>
+ 11b3: 89 45 fc mov %eax,-0x4(%rbp)
+ 11b6: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
+ 11ba: 0f 85 0a 00 00 00 jne 11ca <set_point0+0x1c>
+ 11c0: e8 5b 00 00 00 callq 1220 <pass>
+ 11c5: e9 05 00 00 00 jmpq 11cf <set_point0+0x21>
+ 11ca: e8 61 00 00 00 callq 1230 <fail>
+ 11cf: 48 83 c4 10 add $0x10,%rsp
+ 11d3: 5d pop %rbp
+ 11d4: c3 retq
+ 11d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1)
+ 11dc: 00 00 00 00
+
+ gcc version (f starting at 401125):
+ 000000000040112c <set_point0>:
+ 40112c: e8 f4 ff ff ff callq 401125 <can_relocate_call+0x11>
+ 401131: 89 45 fc mov %eax,-0x4(%rbp)
+ 401134: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
+ 401138: 75 07 jne 401141 <set_point0+0x15>
+ 40113a: e8 c7 ff ff ff callq 401106 <pass>
+ 40113f: eb 05 jmp 401146 <set_point0+0x1a>
+ 401141: e8 c7 ff ff ff callq 40110d <fail>
+ 401146: 90 nop
+ 401147: c9 leaveq
+ 401148: c3 retq
+
+ The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
+ difference: GCC's version uses the leaveq instruction, which resets rsp
+ based on rbp, while clang adds the same constant to rsp that it
+ subtracted in the prologue. Clang fails because the return address that
+ is added by the "call f" instruction isn't accounted for.
+
+ This commit fixes that by adding a return instruction to f, which leaves
+ the rsp as the compilers would expect.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-23 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: address quoted-symbol related FIXMEs
+ If in a "word ptr <address>" or alike construct the "ptr" part is
+ double-quoted, it shouldn't be recognized as the specific keyword we're
+ looking for (just like we don't recognize double-quoted operator or
+ register names anymore). Be careful though to tell closing from opening
+ double-quotes, as a quoted symbol may follow right afterwards.
+
+2023-05-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't recognize quoted symbol names as registers or operators
+ The concept of quoted symbols names was introduced pretty late. Utilize
+ it to allow access to symbols with names matching that of a register (or,
+ in Intel syntax, also an identifier-like operator).
+
+ This is primarily to aid gcc when generating Intel syntax output; see
+ their bug target/53929.
+
+2023-05-23 Zhang, Jun <jun.zhang@intel.com>
+
+ Support Intel FRED LKGS
+ gas/ChangeLog:
+
+ * NEWS: Support Intel FRED LKGS.
+ * config/tc-i386.c: Add fred lkgs
+ * doc/c-i386.texi: Document .fred, .lkgs.
+ * testsuite/gas/i386/i386.exp: Add FRED LKGS tests
+ * testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred.s: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c: New entry for fred, lkgs.
+ * i386-gen.c: Add CPU_FRED CPU_LKGS.
+ * i386-init.h : Regenerated.
+ * i386-mnem.h : Regenerated.
+ * i386-opc.h: Add fred, lkgs.
+ * i386-opc.tbl: Add FRED, LKGS instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-05-23 liuhongt <hongtao.liu@intel.com>
+
+ Revert "Support Intel FRED LKGS"
+ This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.
+
+2023-05-23 Zhang, Jun <jun.zhang@intel.com>
+
+ Support Intel FRED LKGS
+ gas/ChangeLog:
+
+ * NEWS: Support Intel FRED LKGS.
+ * config/tc-i386.c: Add fred lkgs
+ * doc/c-i386.texi: Document .fred, .lkgs.
+ * testsuite/gas/i386/i386.exp: Add FRED LKGS tests
+ * testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred.d: Ditto.
+ * testsuite/gas/i386/x86-64-fred.s: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.d: Ditto.
+ * testsuite/gas/i386/x86-64-lkgs.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c: New entry for fred, lkgs.
+ * i386-gen.c: Add CPU_FRED CPU_LKGS.
+ * i386-init.h : Regenerated.
+ * i386-mnem.h : Regenerated.
+ * i386-opc.h: Add fred, lkgs.
+ * i386-opc.tbl: Add FRED, LKGS instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-05-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix buglet in tui_update_variables
+ I noticed a buglet in tui_update_variables:
+ ...
+ entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
+ if (tui_border_lrcorner != (chtype) entry->value)
+ {
+ tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value;
+ ...
+
+ When assigning the new value to tui_border_lrcorner, an entry->value of -1 is
+ taken into account, but not when comparing to the current value of
+ tui_border_lrcorner.
+
+ Fix this by introducing:
+ ...
+ int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
+ ...
+ and using this in both comparison and assignment.
+
+ Tested on x86_64-linux.
+
+2023-05-22 Tom Tromey <tromey@adacore.com>
+
+ Remove some FIXME comments from DAP
+ I recently added a 'dap' component to bugzilla, and I filed a few bugs
+ there. This patch removes the corresponding FIXME comments.
+
+ A few such comments still exist. In at least one case, I have a fix
+ I'll be submitting eventually; in others I think I need to do a bit of
+ investigation to properly file a bug report.
+
+2023-05-22 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb: add Richard Bunt to gdb/MAINTAINERS
+
+2023-05-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add Term::get_line_with_attrs
+ Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that
+ annotates a tuiterm line with the active attributes.
+
+ For instance, the line representing the TUI status window with attribute mode
+ standout looks like this with Term::get_line:
+ ...
+ exec No process In: ... L?? PC: ??
+ ...
+ but like this with Term::get_line_with_attrs:
+ ...
+ <reverse:1>exec No process In: ... L?? PC: ?? <reverse:0>
+ ...
+
+ Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses
+ Term::get_line_with_attrs instead of Term::get_line.
+
+ Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
+ on x86_64-linux.
+
+2023-05-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Factor out Term::_reset_attrs
+ Factor out new proc Term::_reset_attrs.
+
+ Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
+ on x86_64-linux.
+
+2023-05-22 Alan Modra <amodra@gmail.com>
+
+ Re: readelf: Support SHT_RELR/DT_RELR for -r
+ Revert value of DT_ENCODING to as it was before commit a7fd118627, and
+ adjust readelf.
+
+ include/
+ * elf/common.h (DT_ENCODING): Set back to 32.
+ binutils/
+ * readelf.c (struct filedata): Don't size dynamic_info array
+ using DT_ENCODING.
+
+2023-05-22 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 report number of stub iterations
+ As a developer it is sometimes useful to know how many times stubs
+ have been resized. Report the count for users too, in ld --stats.
+
+2023-05-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-20 Alan Modra <amodra@gmail.com>
+
+ Re: Bug 23686, two segment faults in nm
+ The fix for pr23686 had a hole in the reloc address sanity check,
+ the calculation could overflow. Note that stabsize is known to be a
+ non-zero multiple of 12 so stabsize - 4 can't underflow.
+
+ PR 23686
+ * syms.c (_bfd_stab_section_find_nearest_line): Correct
+ r->address sanity check.
+
+2023-05-20 Alan Modra <amodra@gmail.com>
+
+ coffcode.h handle_COMDAT tidy
+ I started down the path of attempting to fix
+ https://sourceware.org/pipermail/binutils/2023-April/127263.html but
+ decided after a while that I didn't want to mess with this code..
+
+ This patch is a just a few things that I thought worth doing, the main
+ one being reporting of errors up the call chain. The while loop to
+ for loop change is shamelessly stolen from Oleg.
+
+ * coffcode.h (handle_COMDAT): Return bool. Make sec_flags a
+ flagword*, and adjust to suit. Replace while loop with for
+ loop. Check isym.n_numaux before reading aux entries. Alloc
+ coff_comdat_info and name in one call to bfd_alloc. Remove
+ goto breakloop.
+ (styp_to_sec_flags): Adjust handle_COMDAT call.
+
+2023-05-20 Alan Modra <amodra@gmail.com>
+
+ tic54x set_arch_mach
+ The tic54x backend provides its own coff_set_arch_mach, but wants to
+ use the standard coff_set_section_contents. BFD_JUMP_TABLE_WRITE
+ defines both of these functions, so the code also provides a wrapper
+ for coff_set_section_contents. This is all quite OK, but I was on a
+ mission to remove unnecessary declarations in coffcode.h, and on
+ deleting the one for coff_set_arch_mach ran into a warning about the
+ function being unused. I could have kept that declaration with its
+ ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the
+ definition but the latter is not usual and looks odd to me. So I
+ had a closer look at tic54x_set_arch_mach and decided the function is
+ very likely wrong to allow bfd_arch_unknown. Thus the backend should
+ be using the standard coff_set_arch_mach.
+
+ * coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs.
+ (tic54x_coff_set_arch_mach): Delete.
+ (tic54x_set_section_contents): Delete.
+ * coffcode.h: Delete unnecessary forward declarations.
+
+2023-05-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-19 Tom Tromey <tromey@adacore.com>
+
+ Update documentation for Python Frame.older and Frame.newer
+ I noticed that Frame.older and Frame.newer don't document that they
+ return None at the ends of the stack. This patch updates the
+ documentation, and also fixes a somewhat related typo in a comment
+ that I noticed while digging into this.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ ld: drop stray blank from ld.texi
+ At least older makeinfo complains about it. Also fix an apparent typo
+ while touching that line.
+
+2023-05-19 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: fix post-hook execution for remote targets
+ Commit b5661ff2 ("gdb: fix possible use-after-free when
+ executing commands") attempted to fix possible use-after-free
+ in case command redefines itself.
+
+ Commit 37e5833d ("gdb: fix command lookup in execute_command ()")
+ updated the previous fix to handle subcommands as well by using the
+ original command string to lookup the command again after its execution.
+
+ This fixed the test in gdb.base/define.exp but it turned out that it
+ does not work (at least) for "target remote" and "target extended-remote".
+
+ The problem is that the command buffer P passed to execute_command ()
+ gets overwritten in dont_repeat () while executing "target remote"
+ command itself:
+
+ #0 dont_repeat () at top.c:822
+ #1 0x000055555730982a in target_preopen (from_tty=1) at target.c:2483
+ #2 0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0)
+ at remote.c:5946
+ #3 0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272
+ #4 0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490)
+ at target.c:853
+ #5 0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1)
+ at cli/cli-decode.c:2737
+ #6 0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688
+
+ Therefore the second call to lookup_cmd () at line 697 fails to find
+ command because the original command string is gone.
+
+ This commit addresses this particular problem by creating a *copy* of
+ original command string for the sole purpose of using it after command
+ execution to lookup the command again. It may not be the most efficient
+ way but it's safer given that command buffer is shared and overwritten
+ in hard-to-foresee situations.
+
+ Tested on x86_64-linux.
+
+ PR 30249
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-19 Richard Bunt <richard.bunt@linaro.org>
+
+ gdb: Remove redundant frame switching
+ 547ce8f00b fixed an issue where dynamic types were not being resolved
+ correctly prior to printing a value. The same issue was discovered when
+ printing the value using mi-mode, which was not covered by the fix.
+ Porting the fix to the mi-mode code path resolved the issue.
+
+ However, it was discovered that a later patch series, ending
+ 2fc3b8a4cb8, independently fixed the issue in both the cli- and mi-mode
+ code paths, making the original fix unneeded.
+
+ This commit removes this extra frame switch and adds test coverage for
+ the mi-mode scenario to protect against any future divergence in this
+ area.
+
+ GDB built with GCC 11.
+
+ No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1,
+ Intel 22.1; Platforms: x86_64, aarch64.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: safety checks in skip_prologue_using_sal
+ While working on the previous patch I reverted this commit:
+
+ commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
+ Date: Tue Nov 28 16:23:32 2006 +0000
+
+ * symtab.c (find_pc_sect_line): Do not return a line before
+ the start of a symtab.
+
+ When I re-ran the testsuite I saw some GDB crashes in the tests:
+
+ gdb.dwarf2/dw2-line-number-zero.exp
+ gdb.dwarf2/dw2-lines.exp
+ gdb.dwarf2/dw2-vendor-extended-opcode.exp
+
+ GDB was reading beyond the end of an array in the function
+ skip_prologue_using_sal.
+
+ Now, without the above commit reverted I don't believe that this
+ should ever happen. Reverting the above commit effectively breaks
+ GDB's symtab_and_line lookup, we try to find a result for an address,
+ and return the wrong symtab and line-table. In
+ skip_prologue_using_sal we then walk the line table looking for an
+ appropriate entry, except we never find one, and GDB just keeps going,
+ wandering off the end of the array.
+
+ However, I think adding extra protection to prevent walking off the
+ end of the array is pretty cheap, and if something does go wrong in
+ the future then this should prevent a random crash.
+
+ Obviously, I have no reproducer for this, as I said, I don't think
+ this should impact GDB at all, this is just adding a little extra
+ caution.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: test for a function with no line table
+ This commit adds a test for the following commit:
+
+ commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
+ Date: Tue Nov 28 16:23:32 2006 +0000
+
+ * symtab.c (find_pc_sect_line): Do not return a line before
+ the start of a symtab.
+
+ We have been carrying a test for that commit in the Fedora GDB tree
+ since that commit was added to GDB. I don't know why the test wasn't
+ added along with the original commit, but as was written, the test is
+ pretty gross, it uses objcopy to pull the .text section from an object
+ file, which was then injected into another source file within a .asm
+ statement...
+
+ ... these days we can just make use of the DWARF assembler to achieve
+ the same results, so I've rewritten the test and think it is worth
+ adding this to upstream GDB.
+
+ The original patch was about about how we find the best symtab and
+ line table entry, and what to do when GDB can't find a good match.
+
+ The new test creates a CU with two functions, only one of which is
+ covered by the line table. With the above patch reverted GDB returns
+ an invalid address.
+
+ With the above patch reverted I did run the testsuite to see what
+ other tests might already be exercising this functionality, and I
+ found two tests:
+
+ gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
+ gdb.dwarf2/dw2-vendor-extended-opcode.exp
+
+ These are pretty similar, they either create minimal, or no line table
+ for one of the functions in the source file, and as a consequence GDB
+ returns an unexpected address at some point during the test.
+
+ However, both of those tests are really focused on other issues, so I
+ think this new test does add some value. Plus the new test is not
+ large, so it's not a huge cost to also run this new test.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/breakpoint: use warning function instead of gdb_printf
+ Noticed that in breakpoint.c, in one place, we do this:
+
+ gdb_printf (_("warning: Error removing "
+ "breakpoint %d\n"),
+ old_loc->owner->number);
+
+ Instead of using the `warning` function. There are a number of
+ differences between using gdb_printf like this and calling `warning`,
+ the main one is probably that real warnings are sent to gdb_stderr,
+ while the above gdb_printf call will go to gdb_stdout.
+
+ In this commit I:
+
+ 1. Change to call `warning`, we can drop the "warning: " prefix from
+ the string in breakpoint.c,
+
+ 2. Update the warning text, I now start with a lower case 'e', which
+ I believe is the GDB style for warnings,
+
+ 3. And I have included the address of the bp_location in the warning
+ messsage,
+
+ 4. Finally, I update all the tests (2) that include this error
+ message.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: handle older Python versions in gdb.python/py-disasm.exp
+ It was pointed out on the mailing list that the new tests added in
+ this commit:
+
+ commit 4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1
+ Date: Tue Jan 24 15:35:45 2023 +0000
+
+ gdb/python: extend the Python Disassembler API to allow for styling
+
+ will fail when GDB is built with Python 3.6 or earlier. This is
+ because the error that is emitted when a function argument is missing
+ changed in Python 3.7, instead of an error like this:
+
+ Python Exception <class 'TypeError'>: function missing required argument 'style' (pos 1)
+
+ earlier versions of Python emit:
+
+ Python Exception <class 'TypeError'>: Required argument 'style' (pos 1) not found
+
+ and the new tests didn't allow for this.
+
+ This commit fixes this by allowing either pattern. I've tested this
+ building GDB against Python 3.7.9 and 3.6.15, with this commit all
+ tests in gdb.python/py-disasm.exp now pass.
+
+2023-05-19 Kuan-Lin Chen <rufus@andestech.com>
+
+ RISC-V: Support subtraction of .uleb128.
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/96d6e190e9fc04a8517f9ff7fb9aed3e9876cbd6
+
+ There are some known limitations for now,
+
+ * Do not shrink the length of the uleb128 value, even if the value is reduced
+ after relaxations. Also reports error if the length grows up.
+
+ * The R_RISCV_SET_ULEB128 needs to be paired with and be placed before the
+ R_RISCV_SUB_ULEB128.
+
+ bfd/
+ * bfd-in2.h: Regenerated.
+ * elfnn-riscv.c (perform_relocation): Perform R_RISCV_SUB_ULEB128 and
+ R_RISCV_SET_ULEB128 relocations. Do not shrink the length of the
+ uleb128 value, and report error if the length grows up. Called the
+ generic functions, _bfd_read_unsigned_leb128 and _bfd_write_unsigned_leb128,
+ to encode the uleb128 into the section contents.
+ (riscv_elf_relocate_section): Make sure that the R_RISCV_SET_ULEB128
+ must be paired with and be placed before the R_RISCV_SUB_ULEB128.
+ * elfxx-riscv.c (howto_table): Added R_RISCV_SUB_ULEB128 and
+ R_RISCV_SET_ULEB128.
+ (riscv_reloc_map): Likewise.
+ (riscv_elf_ignore_reloc): New function.
+ * libbfd.h: Regenerated.
+ * reloc.c (BFD_RELOC_RISCV_SET_ULEB128, BFD_RELOC_RISCV_SUB_ULEB128):
+ New relocations to support .uleb128 subtraction.
+ gas/
+ * config/tc-riscv.c (md_apply_fix): Added BFD_RELOC_RISCV_SET_ULEB128
+ and BFD_RELOC_RISCV_SUB_ULEB128.
+ (s_riscv_leb128): Updated to allow uleb128 subtraction.
+ (riscv_insert_uleb128_fixes): New function, scan uleb128 subtraction
+ expressions and insert fixups for them.
+ (riscv_md_finish): Called riscv_insert_uleb128_fixes for all sections.
+ include/
+ * elf/riscv.h ((R_RISCV_SET_ULEB128, (R_RISCV_SUB_ULEB128): Defined.
+ ld/
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+ * testsuite/ld-riscv-elf/uleb128*: New testcase for uleb128 subtraction.
+ binutils/
+ * testsuite/binutils-all/nm.exp: Updated since RISCV supports .uleb128.
+
+2023-05-19 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Minor improvements for dis-assembler.
+ * Extract all private_data initializations into riscv_init_disasm_info, which
+ called from print_insn_riscv rather than riscv_disassemble_insn.
+
+ * The disassemble_free_target seems like the right place to release all target
+ private_data, also including the internal data structures, like riscv_subsets.
+ Therefore, add a new function, disassemble_free_riscv, to release them for safe.
+
+ opcodes/
+ * disassemble.c (disassemble_free_target): Called disassemble_free_riscv
+ for riscv to release private_data and internal data structures.
+ * disassemble.h: Added extern disassemble_free_riscv.
+ * riscv-dis.c (riscv_init_disasm_info): New function, used to init
+ riscv_private_data.
+ (riscv_disassemble_insn): Moved riscv_private_data initializations
+ into riscv_init_disasm_info.
+ (print_insn_riscv): Called riscv_init_disasm_info to init
+ riscv_private_data once time.
+ (disassemble_free_riscv): New function, used to free the internal data
+ structures, like riscv_subsets.
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: permit all relational operators in insn operands
+ Oddly enough == and != were not permitted, because of '=' not having
+ been listed in operand_special_chars[].
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: further adjust extend-to-32bit-address conditions
+ While a442cac5084e ("ix86: wrap constants") helped address a number of
+ inconsistencies between BFD64 and !BFD64 builds, it has also resulted in
+ certain bogus uses of constants to no longer be warned about. Leverage
+ the md_optimize_expr() hook to adjust when to actually truncate
+ expressions to 32 bits - any involvement of binary expressions (which
+ would be evaluated in 32 bits only when !BFD64) signals the need for
+ doing so. Plain constants (or ones merely subject to unary operators)
+ should remain un-truncated - they would be handled as bignums when
+ !BFD64, and hence are okay to permit.
+
+ To compensate
+ - slightly extend optimize_imm() (to be honest I never understood why
+ the code being added - or something similar - wasn't there in the
+ first place),
+ - adjust expectations of the disp-imm-32 testcase (there are now
+ warnings, as there should be for any code which won't build [warning-
+ free] when !BFD64, and Disp8/Imm8 are no longer used in the warned
+ about cases).
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ gas: invoke md_optimize_expr() also for unary expressions
+ Give backends a chance to see these, just as they can see binary ones.
+ Most of those which use this hook already cope with NULL being passed
+ for the left operand (typically because of checking the operator first).
+ Adjust the two which don't.
+
+ Take the opportunity and also document the hook.
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ gas: maintain O_constant signedness in more cases
+ Unary '~' doesn't really produce an unsigned result. Neither does
+ subtraction (unless taking operand values into consideration). And an
+ abstract operator applied to two operands which aren't both unsigned
+ can't be assumed to yield an unsigned result; exceptions are
+ - shifts, where only signedness of the left hand operand matters,
+ - comparisons, which - unlike unary '!' - produce signed results (they
+ deliver 0 or ~0, as opposed to '!', which yields 0 or 1),
+ - logical operators (yielding 0 or 1 and hence treated like unary '!').
+
+ While doing this (specifically while extending the all/quad testcase),
+ update .quad and .8byte documentation: With 64-bit architectures now
+ being common, it is highly inappropriate to state that these directives
+ unconditionally require bignums.
+
+2023-05-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: tighten extend-to-32bit-address conditions
+ In a442cac5084e ("ix86: wrap constants") I made the truncation condition
+ too relaxed: Any indication of a mode that's possible with BFD64 only
+ should avoid the truncation. Therefore, like in the other two cases of
+ calls to extend_to_32bit_address(), also check whether we're generating
+ a 64-bit object.
+
+2023-05-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-18 Tom Tromey <tromey@adacore.com>
+
+ Use lower-case in @sc in the documentation
+ Eli pointed out that @sc only produces small caps for lower case
+ letters in its argument, so it's weird to write it using upper-case
+ letters. This patch fixes the instances I found.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function parameters (PR 30414)
+ gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound
+ values by reading some output from the inferior. This is racy when
+ running on boards where the inferior I/O is on a separate TTY than
+ GDB's, such as native-gdbserver.
+
+ I sometimes see this behavior:
+
+ (gdb) continue
+ Continuing.
+
+ Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
+ ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
+ 45 print *, "" ! Test Breakpoint
+ (gdb) Remote debugging from host ::1, port 37496
+
+ Expected GDB Output:
+
+ LBOUND = (-8, -10)
+ UBOUND = (-1, -2)
+ APB: Run a test here
+ APB: Expected lbound '(-8, -10)'
+ APB: Expected ubound ''
+
+ What happened is that expect read the output from GDB before the output
+ from the inferior, triggering this gdb_test_multiple clause:
+
+ -re "$gdb_prompt $" {
+ set found_prompt true
+
+ if {$found_dealloc_breakpoint
+ || ($expected_lbound != "" && $expected_ubound != "")} {
+ # We're done.
+ } else {
+ exp_continue
+ }
+ }
+
+ So it set found_prompt, but the gdb_test_multiple kept going because
+ found_dealloc_breakpoint is false (this is the flag indicating that the
+ test is finished) and we still don't have expected_lbound and
+ expected_ubound. Then, expect reads in the inferior I/O, triggering
+ this clause:
+
+ -re ".*LBOUND = (\[^\r\n\]+)\r\n" {
+ set expected_lbound $expect_out(1,string)
+ if {!$found_prompt} {
+ exp_continue
+ }
+ }
+
+ This sets expected_lbound, but since found_prompt is true, we don't do
+ exp_continue, and exit the gdb_test_multiple, without having an
+ expected_ubound.
+
+ Change the test to read the values from the lb and ub function
+ parameters instead. As far as I understand, this still exercises what
+ we want to test. These variables contain the return values of the
+ lbound and ubound functions as computed by the program. We'll use them
+ to check the return values of the lbound and ubound functions as
+ computed by GDB.
+
+ Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414
+
+2023-05-18 Hui Li <lihui@loongson.cn>
+
+ gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_
+ In the current code, when execute the following test on LoongArch:
+
+ $ make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
+ === gdb Summary ===
+
+ # of expected passes 111
+ # of unexpected failures 62
+
+ According to IFUNC's working process [1]. first time the IFUNC function
+ is called, the dynamic linker will not simply fill the .got.plt entry
+ with the actual address of IFUNC symbol, it will call the IFUNC resolver
+ function and take the return address, uses it as the sym-bound address
+ and puts it in the .got.plt entry. Initial address in .got.plt entry is
+ not a real function addresss. Depending on the compiler implementation,
+ some different addresses will be filled in. Most architectures will use
+ a .plt entry address to fill in the corresponding .got.plt entry.
+
+ In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real
+ IFUNC function addresss. First check to see if the real address for
+ the IFUNC symbol has been resolved by the following function:
+
+ elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p)
+ {
+ if (elf_gnu_ifunc_resolve_by_cache (name, addr_p))
+ return true;
+
+ if (elf_gnu_ifunc_resolve_by_got (name, addr_p))
+ return true;
+
+ return false;
+ }
+
+ in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the
+ .got.plt entry and determines if the contents is the correct address
+ by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working
+ principle analysis above, the address filled in the .got.plt entry is
+ not the actual target function address initially, it would be a .plt
+ entry address corresponding symbol like *@plt. In this case, gdb just
+ go back to execute the resolver function and puts the return address
+ in the .got.plt entry. After that, gdb can get a real ifun address via
+ .got.plt entry.
+
+ On LoongArch, initially, each address filled in the .got.plt entries
+ is the first .plt entry address. Some architectures such as LoongArch
+ define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt
+ section. This symbol is the first plt entry, so gdb needs to check
+ this symbol in elf_gnu_ifunc_record_cache().
+
+ On LoongArch .got.plt and .plt section as follow:
+
+ $objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0
+ ...
+ 0000000120010008 <.got.plt>:
+ 120010008: ffffffff 0xffffffff
+ 12001000c: ffffffff 0xffffffff
+ ...
+ 120010018: 20004000 ll.w $zero, $zero, 64(0x40)
+ 12001001c: 00000001 0x00000001
+ 120010020: 20004000 ll.w $zero, $zero, 64(0x40)
+ 120010024: 00000001 0x00000001
+ 120010028: 20004000 ll.w $zero, $zero, 64(0x40)
+ 12001002c: 00000001 0x00000001
+ 120010030: 20004000 ll.w $zero, $zero, 64(0x40)
+ 120010034: 00000001 0x00000001
+
+ ...
+ Disassembly of section .plt:
+
+ 0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>:
+ 120004000: 1c00018e pcaddu12i $t2, 12(0xc)
+ 120004004: 0011bdad sub.d $t1, $t1, $t3
+ 120004008: 28c021cf ld.d $t3, $t2, 8(0x8)
+ 12000400c: 02ff51ad addi.d $t1, $t1, -44(0xfd4)
+ 120004010: 02c021cc addi.d $t0, $t2, 8(0x8)
+ 120004014: 004505ad srli.d $t1, $t1, 0x1
+ 120004018: 28c0218c ld.d $t0, $t0, 8(0x8)
+ 12000401c: 4c0001e0 jirl $zero, $t3, 0
+
+ 0000000120004020 <__libc_start_main@plt>:
+ 120004020: 1c00018f pcaddu12i $t3, 12(0xc)
+ 120004024: 28ffe1ef ld.d $t3, $t3, -8(0xff8)
+ 120004028: 4c0001ed jirl $t1, $t3, 0
+ 12000402c: 03400000 andi $zero, $zero, 0x0
+
+ 0000000120004030 <abort@plt>:
+ 120004030: 1c00018f pcaddu12i $t3, 12(0xc)
+ 120004034: 28ffc1ef ld.d $t3, $t3, -16(0xff0)
+ 120004038: 4c0001ed jirl $t1, $t3, 0
+ 12000403c: 03400000 andi $zero, $zero, 0x0
+
+ 0000000120004040 <gnu_ifunc@plt>:
+ 120004040: 1c00018f pcaddu12i $t3, 12(0xc)
+ 120004044: 28ffa1ef ld.d $t3, $t3, -24(0xfe8)
+ 120004048: 4c0001ed jirl $t1, $t3, 0
+ 12000404c: 03400000 andi $zero, $zero, 0x0
+ ...
+
+ With this patch:
+
+ $make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
+ === gdb Summary ===
+
+ #of expected passes 173
+
+ [1] https://sourceware.org/glibc/wiki/GNU_IFUNC
+
+2023-05-18 Alan Modra <amodra@gmail.com>
+
+ Re: Add section caches to coff_data_type
+ Another thing, section target_index is renumbered in
+ coff_compute_section_file_positions and _bfd_xcoff_bfd_final_link. I
+ don't know that there is currently any way that the output bfd
+ section_by_target_index could be populated before this point but
+ clear them out so no one need worry about it.
+
+ * coffcode.h (coff_compute_section_file_positions): Clear
+ section_by_target_index hash table when changing target_index.
+ (_bfd_xcoff_bfd_final_link): Likewise.
+
+2023-05-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix whitespace and indentation in lib/tuiterm.exp
+ I noticed a trailing whitespace and some indentation errors in lib/tuiterm.exp.
+
+ Fix these.
+
+ Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
+ on x86_64-linux.
+
+2023-05-18 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: testsuite: add tests for sframe_get_funcdesc_with_addr API
+ sframe_get_funcdesc_with_addr API is currently used internally by the
+ sframe_find_fre ().
+
+ In this test, we create three dummy SFrame FDEs with 4 FREs each. Then,
+ we use few negative tests to lookup FREs with PCs not in the range of
+ PCs covered by the FDEs, ensuring graceful return from
+ sframe_get_funcdesc_with_addr in all cases. Some positive tests are
+ also added that exercise further scenarios as well.
+
+ libsframe/
+ * Makefile.in: Regenerated.
+ * testsuite/libsframe.find/find.exp: Include new test.
+ * testsuite/libsframe.find/findfunc-1.c: New Test.
+ * testsuite/libsframe.find/local.mk: Include new test.
+
+2023-05-18 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: testsuite: add new tests for sframe_find_fre API
+ libsframe provides an API to find the FRE associated with a given PC in
+ the program. This patch adds a direct test of this API.
+
+ In this test, we create two dummy SFrame FDEs with 4 FREs each. Then we
+ test that sframe_find_fre () works for the first, second, third and the
+ last FRE from one of the FDEs. Such a test ensures better regression
+ testing for the sframe_find_fre () function which is going to be the
+ bread and butter of an SFrame based stack tracer.
+
+ libsframe/
+ * Makefile.in: Regenerated.
+ * testsuite/libsframe.find/find.exp: New test.
+ * testsuite/libsframe.find/findfre-1.c: New test.
+ * testsuite/libsframe.find/local.mk: Build new test.
+ * testsuite/local.mk: Include libsframe.find.
+
+2023-05-18 Alan Modra <amodra@gmail.com>
+
+ Re: Add section caches to coff_data_type
+ Commit 0e759f232b6d regressed these tests:
+ rs6000-aix7.2 +FAIL: Garbage collection test 1 (32-bit)
+ rs6000-aix7.2 +FAIL: Garbage collection test 1 (64-bit)
+ rs6000-aix7.2 +FAIL: Glink test 1 (32-bit)
+ rs6000-aix7.2 +FAIL: Glink test 1 (64-bit)
+
+ Investigation showed segfaults in coff_section_from_bfd_index called
+ by xcoff_write_global_symbol due to the hash table pointer being
+ NULL. Well, yes, the hash table isn't initialised for the output bfd.
+ mkobject_hook is the wrong place to do that.
+
+ * coffcode.h: Revert 0e759f232b6d changes.
+ * peicode.h: Likewise.
+ * coff-x86_64.c (htab_hash_section_index, htab_eq_section_index):
+ Moved here from coffcode.h.
+ (coff_amd64_rtype_to_howto): Create section_by_index htab.
+ * coffgen.c (htab_hash_section_target_index),
+ (htab_eq_section_target_index): Moved here from coffcode.h.
+ (coff_section_from_bfd_index): Create section_by_target_index
+ htab. Stash newly created sections in htab.
+
+2023-05-18 Alan Modra <amodra@gmail.com>
+
+ PR11601, Solaris assembler compatibility doesn't work
+ Well, it doesn't work on x86 or ppc, which both have # starting
+ comments anywhere on a line. I think it is therefore only useful on
+ sparc.
+
+ PR 11601
+ * config/obj-elf.c (obj_elf_section_word): Only compile for sparc.
+ (obj_elf_section): Only support solaris .section directive on
+ sparc.
+ * doc/as.texi (Section): Mention that solaris .section
+ directive is only supported for sparc.
+
+2023-05-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-17 Tom Tromey <tom@tromey.com>
+
+ Special case "&str" in Rust parser
+ "&str" is an important type in Rust -- it's the type of string
+ literals. However, the compiler puts it in the DWARF in a funny way.
+ The slice itself is present and named "&str". However, the Rust
+ parser doesn't look for types with names like this, but instead tries
+ to construct them from components. In this case it tries to make a
+ pointer-to-"str" -- but "str" isn't always available, and in any case
+ that wouldn't yield the best result.
+
+ This patch adds a special case for &str.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-17 Luca Bacci <luca.bacci@outlook.com>
+
+ Decorated symbols in import libs (BUG 30421)
+ PR 30421
+ * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it.
+ * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype.
+ * libcoff.h: Regenerate.
+
+ * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function.
+ * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function.
+ * pe-dll.c (make_one): Check for decoated symbols.
+
+2023-05-17 Alan Modra <amodra@gmail.com>
+
+ PR29961, plugin-api.h: "Could not detect architecture endianess"
+ Found when attempting to build binutils on sparc sunos-5.8 where
+ sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER
+ variants. This patch adds the extra tests to cope with the old
+ machine, and tidies the header a little.
+
+ PR 29961
+ plugin-api.h: When handling non-gcc or gcc < 4.6.0 include
+ necessary header files before testing macros. Make more use
+ of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests.
+
+2023-05-17 Alan Modra <amodra@gmail.com>
+
+ gcc-4.5 build fixes
+ Trying to build binutils with an older gcc currently fails. Working
+ around these gcc bugs is not onerous so let's fix them.
+
+ bfd/
+ * elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun
+ pointer.
+ * elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat"
+ variable to "status".
+ gas/
+ * compress-debug.c (compress_finish): Supply all fields in
+ ZSTD_inBuffer initialisation.
+ include/
+ * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
+ forward declaration.
+ opcodes/
+ * loongarch-opc.c: Supply all fields of zero struct initialisation
+ in various opcode tables.
+
+2023-05-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: include a new function in the right place
+ Static function name is not available in stripped libraries.
+ In this case, gprofng maps PC to a fake function like <static>@0xPC (<libname>).
+ Sometimes gprofng creates two functions instead of one.
+ Also FUNC_FLAG_SIMULATED is needed for these fake functions.
+
+ gprofng/ChangeLog
+ 2023-05-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/LoadObject.cc (LoadObject::find_function): Set FUNC_FLAG_SIMULATED.
+ Include a new function in the right place.
+
+2023-05-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Don't show line number for lines not in source file
+ Currently, for a source file containing only 5 lines, we also show line
+ numbers 6 and 7 if they're in scope of the source window:
+ ...
+ 0 +-compact-source.c----------------+
+ 1 |___3_{ |
+ 2 |___4_ return 0; |
+ 3 |___5_} |
+ 4 |___6_ |
+ 5 |___7_ |
+ 6 +---------------------------------+
+ ...
+
+ Fix this by not showing line numbers not in a source file, such that we have instead:
+ ...
+ 0 +-compact-source.c----------------+
+ 1 |___3_{ |
+ 2 |___4_ return 0; |
+ 3 |___5_} |
+ 4 | |
+ 5 | |
+ 6 +---------------------------------+
+ ...
+
+ Tested on x86_64-linux.
+
+ Suggested-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-16 Nick Clifton <nickc@redhat.com>
+
+ Document how to use the linker to create a resource only DLL.
+ PR 30359
+ * ld.texi (WIN32): Document how to create a resource only DLL.
+
+2023-05-16 Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
+
+ Add section caches to coff_data_type
+ * libcoff-in.h (struct coff_tdata): Add section_by_index and section_by_target_index hash tables.
+ * libcoff.h: Regenerate.
+ * coffcode.h (htab_hash_section_index): New function. (htab_eq_section_index): New function. (htab_hash_section_target_index): New function. (htab_eq_section_target_index): New function. (coff_mkobject_hool): Create the hash tables.
+ * peicode.h: Add the same new functions. (pe_mkobject_hook): Create the hash tables.
+ * coff-x86_64.c (coff_amd64_rtype_to_howto): Use the new tables to speed up lookups.
+ * coffgen.c (coff_section_from_bfd_index): Likewise. (_bfd_coff_close_and_cleanup): Delete the hash tables.
+
+2023-05-16 Paul Pluzhnikov <ppluzhnikov@google.com>
+
+ Update comments for the gdb/24331 fix.
+ Approved-by: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix formatting of gdb.python/py-disasm.py
+ Run black on gdb.python/py-disasm.py file and commit the changes.
+
+2023-05-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: make gdb_supported_languages a caching proc
+ Rewrite gdb_supported_languages as a caching proc that actually
+ queries GDB for the list of supported languages, rather than just
+ containing a hard-coded list of languages.
+
+ There's only one test that uses this proc right now,
+ gdb.python/py-function.exp, and that still passes after this change,
+ with no changes in the test names.
+
+2023-05-16 Nick Clifton <nickc@redhat.com>
+
+ -Ur option documentation
+ * ld.texi (-Ur): Clarify the actions of this option.
+
+2023-05-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix regressions in break-main-file-remove-fail.exp
+ After this commit:
+
+ commit a68f7e9844208ad8cd498f89b5100084ece7d0f6
+ Date: Tue May 9 10:28:42 2023 +0100
+
+ gdb/testsuite: extend special '^' handling to gdb_test_multiple
+
+ buildbot notified me of a regression on s390 in the test:
+
+ gdb.base/break-main-file-remove-fail.exp
+
+ the failure looks like this:
+
+ print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096)
+ warning: Error removing breakpoint 0
+ $2 = 0
+ (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)"
+
+ On the mailing list it has been reported that this failure also
+ impacts arm, aarch64, and possibly ppc/ppc64 too.
+
+ The above commit changed get_integer_valueof so that no output is
+ expected between the command and the '$2 = 0' line. In this case the
+ 'warning: Error removing breakpoint 0' output is causing the
+ get_integer_valueof call to fail.
+
+ The reason for this warning is that this test deliberately calls
+ munmap on a page of the inferior's code. The test is checking that
+ GDB can handle the situation where a s/w breakpoint can't be
+ removed (due to the page no longer being readable/writable).
+
+ The test that is supposed to trigger the warning is later in the test
+ script when we delete a breakpoint.
+
+ So why do some targets trigger the warning earlier during the inferior
+ call?
+
+ The impacted targets use AT_ENTRY_POINT as their strategy for handling
+ inferior calls, that is, the trampoline that calls the inferior
+ function is placed at the program's entry point, e.g. often the _start
+ label.
+
+ If this location happens to be on the same page as the page that the
+ test script unmaps then, when the inferior function call returns, GDB
+ will not be able to remove the temporary breakpoint that is inserted
+ to catch the inferior function call returning! As a result we end up
+ seeing the warning earlier than expected.
+
+ I did wonder if this means I should relax the pattern in
+ get_integer_valueof - just accept that there might be additional
+ output from GDB which we should ignore.
+
+ However, I don't think this the right way to go. With the change in
+ a68f7e984420 we are now stricter for GDB emitting additional,
+ unexpected, output, and I think that is a good thing.
+
+ So, I think, in this case, in order to handle the possible extra
+ output, we should implement something like get_integer_valueof
+ directly in the gdb.base/break-main-file-remove-fail.exp test script.
+ This local version will handle the possible warning output.
+
+ After this the test should pass again on the impacted targets.
+
+2023-05-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: extend the Python Disassembler API to allow for styling
+ This commit extends the Python Disassembler API to allow for styling
+ of the instructions.
+
+ Before this commit the Python Disassembler API allowed the user to do
+ two things:
+
+ - They could intercept instruction disassembly requests and return a
+ string of their choosing, this string then became the disassembled
+ instruction, or
+
+ - They could call builtin_disassemble, which would call back into
+ libopcode to perform the disassembly. As libopcode printed the
+ instruction GDB would collect these print requests and build a
+ string. This string was then returned from the builtin_disassemble
+ call, and the user could modify or extend this string as needed.
+
+ Neither of these approaches allowed for, or preserved, disassembler
+ styling, which is now available within libopcodes for many of the more
+ popular architectures GDB supports.
+
+ This commit aims to fill this gap. After this commit a user will be
+ able to do the following things:
+
+ - Implement a custom instruction disassembler entirely in Python
+ without calling back into libopcodes, the custom disassembler will
+ be able to return styling information such that GDB will display
+ the instruction fully styled. All of GDB's existing style
+ settings will affect how instructions coming from the Python
+ disassembler are displayed in the expected manner.
+
+ - Call builtin_disassemble and receive a result that represents how
+ libopcode would like the instruction styled. The user can then
+ adjust or extend the disassembled instruction before returning the
+ result to GDB. Again, the instruction will be styled as expected.
+
+ To achieve this I will add two new classes to GDB,
+ DisassemblerTextPart and DisassemblerAddressPart.
+
+ Within builtin_disassemble, instead of capturing the print calls from
+ libopcodes and building a single string, we will now create either a
+ text part or address part and store these parts in a vector.
+
+ The DisassemblerTextPart will capture a small piece of text along with
+ the associated style that should be used to display the text. This
+ corresponds to the disassembler calling
+ disassemble_info::fprintf_styled_func, or for disassemblers that don't
+ support styling disassemble_info::fprintf_func.
+
+ The DisassemblerAddressPart is used when libopcodes requests that an
+ address be printed, and takes care of printing the address and
+ associated symbol, this corresponds to the disassembler calling
+ disassemble_info::print_address_func.
+
+ These parts are then placed within the DisassemblerResult when
+ builtin_disassemble returns.
+
+ Alternatively, the user can directly create parts by calling two new
+ methods on the DisassembleInfo class: DisassembleInfo.text_part and
+ DisassembleInfo.address_part.
+
+ Having created these parts the user can then pass these parts when
+ initializing a new DisassemblerResult object.
+
+ Finally, when we return from Python to gdbpy_print_insn, one way or
+ another, the result being returned will have a list of parts. Back in
+ GDB's C++ code we walk the list of parts and call back into GDB's core
+ to display the disassembled instruction with the correct styling.
+
+ The new API lives in parallel with the old API. Any existing code
+ that creates a DisassemblerResult using a single string immediately
+ creates a single DisassemblerTextPart containing the entire
+ instruction and gives this part the default text style. This is also
+ what happens if the user calls builtin_disassemble for an architecture
+ that doesn't (yet) support libopcode styling.
+
+ This matches up with what happens when the Python API is not involved,
+ an architecture without disassembler styling support uses the old
+ libopcodes printing API (the API that doesn't pass style info), and
+ GDB just prints everything using the default text style.
+
+ The reason that parts are created by calling methods on
+ DisassembleInfo, rather than calling the class constructor directly,
+ is DisassemblerAddressPart. Ideally this part would only hold the
+ address which the part represents, but in order to support backwards
+ compatibility we need to be able to convert the
+ DisassemblerAddressPart into a string. To do that we need to call
+ GDB's internal print_address function, and to do that we need an
+ gdbarch.
+
+ What this means is that the DisassemblerAddressPart needs to take a
+ gdb.Architecture object at creation time. The only valid place a user
+ can pull this from is from the DisassembleInfo object, so having the
+ DisassembleInfo act as a factory ensures that the correct gdbarch is
+ passed over each time. I implemented both solutions (the one
+ presented here, and an alternative where parts could be constructed
+ directly), and this felt like the cleanest solution.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: rework how the disassembler API reads the result object
+ This commit is a refactor ahead of the next change which will make
+ disassembler styling available through the Python API.
+
+ Unfortunately, in order to make the styling support available, I think
+ the easiest solution is to make a very small change to the existing
+ API.
+
+ The current API relies on returning a DisassemblerResult object to
+ represent each disassembled instruction. Currently GDB allows the
+ DisassemblerResult class to be sub-classed, which could mean that a
+ user tries to override the various attributes that exist on the
+ DisassemblerResult object.
+
+ This commit removes this ability, effectively making the
+ DisassemblerResult class final.
+
+ Though this is a change to the existing API, I'm hoping this isn't
+ going to cause too many issues:
+
+ - The Python disassembler API was only added in the previous release
+ of GDB, so I don't expect it to be widely used yet, and
+
+ - It's not clear to me why a user would need to sub-class the
+ DisassemblerResult type, I allowed it in the original patch
+ because at the time I couldn't see any reason to NOT allow it.
+
+ Having prevented sub-classing I can now rework the tail end of the
+ gdbpy_print_insn function; instead of pulling the results out of the
+ DisassemblerResult object by calling back into Python, I now cast the
+ Python object back to its C++ type (disasm_result_object), and access
+ the fields directly from there. In later commits I will be reworking
+ the disasm_result_object type in order to hold information about the
+ styled disassembler output.
+
+ The tests that dealt with sub-classing DisassemblerResult have been
+ removed, and a new test that confirms that DisassemblerResult can't be
+ sub-classed has been added.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-15 Tom Tromey <tom@tromey.com>
+
+ Correctly handle forward DIE references in scanner
+ The cooked index scanner has special code to handle forward DIE
+ references. However, a bug report lead to the discovery that this
+ code does not work -- the "deferred_entry::spec_offset" field is
+ written to but never used, i.e., the lookup is done using the wrong
+ key.
+
+ This patch fixes the bug and adds a regression test.
+
+ The test in the bug itself used a thread_local variable, which
+ provoked a failure at runtime. This test instead uses "maint print
+ objfiles" and then inspects to ensure that the entry in question has a
+ parent. This lets us avoid a clang dependency in the test.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271
+
+2023-05-15 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix PLT entry generate bug
+ If a function symbol only get its address by la.global, without
+ directly called by bl instruction, the PLT entry is not required.
+
+ bfd/ChangeLog:
+
+ * elfnn-loongarch.c (loongarch_elf_adjust_dynamic_symbol): Fix PLT
+ entry generate bug.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/shared.exp: Clear xfail for LoongArch.
+
+2023-05-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-13 Paul Pluzhnikov <ppluzhnikov@google.com>
+
+ Fix bad interaction between element limit and repeated values (BZ#24331).
+ Currently
+
+ print -elements=3 -- "AAAAAA"
+
+ prints complete string, which is not what the user asked for.
+
+ Fix two buggy tests exposed by the fix, and add a new test.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-05-13 Alan Modra <amodra@gmail.com>
+
+ PR28955 mips gas segfault
+ Testing for NULL in pic_need_relax fixes the other call to this
+ function in md_estimate_size_before_relax.
+
+ PR 28955
+ * config/tc-mips.c (mips_frob_file): Move NULL sym test to..
+ (pic_need_relax): ..here.
+
+2023-05-13 Alan Modra <amodra@gmail.com>
+
+ PR28902, -T script with INSERT ordering
+ The answer to PR28902 may be deduced from the existing INSERT
+ documentation that says the default script is parsed after the -T
+ INSERT script, if you assume (correctly) that nothing special is done
+ when inserting into -T scripts overriding the default script. In both
+ cases INSERT handling looks for the specified output section later on
+ the internal list of parsed script commands. This isn't obvious
+ though, so make the ordering explicit, and mention that section
+ assignments are the same too.
+
+ PR 28902
+ * ld.texi (INSERT): Specify ordering when -T is used both to
+ override the default script and to augment.
+
+2023-05-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-12 Tom Tromey <tromey@adacore.com>
+
+ Fix regression due to Pragma Import series
+ A co-worker here at AdaCore discovered that the Pragma Import series
+ caused a rgression. When debugging gnat1, gdb started asking for
+ overload resolution like:
+
+ (gdb) call pp(n)
+ Multiple matches for pp
+ [0] cancel
+ [1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
+ [2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
+
+ This worked before the series, and is strange anyway, because the
+ matches refer to the same function.
+
+ This patch adds a test case for this situation and fixes the bug by
+ pruning identical functions in remove_extra_symbols.
+
+2023-05-12 Tom Tromey <tromey@adacore.com>
+
+ Use bool and early loop exit in remove_extra_symbols
+ This changes remove_extra_symbols to use bool rather than int, and
+ changes the nested loops to exit early when "remove_p" is set.
+
+ Use reference parameter in remove_extra_symbols
+ Changing ada-lang.c:remove_extra_symbols to take a reference parameter
+ makes the code a bit easier to read, by replacing "(*syms)" with plain
+ "syms".
+
+ Handle Ada Pragma Import and Pragma Export
+ Ada can import C APIs and also export Ada constructs to C via Pragma
+ Import and Pragma Export. This patch adds support for these to gdb,
+ by arranging to either defer some aspects of a symbol to the
+ underlying C symbol (for Import) or by introducing a second symbol
+ (for Export). A somewhat tricky approach is needed, both because gdb
+ doesn't generally handle symbol aliasing, and because Ada treats
+ symbol names in an unusual way (as compared to the rest of gdb).
+
+ Introduce symbol_block_ops::get_block_value
+ This adds a new callback to symbol_block_ops. This callback lets a
+ LOC_BLOCK symbol implement its own function to find the underlying
+ block.
+
+ Define symbol::value_block separately
+ This moves the definition of symbol::value_block outside of the class.
+ A subsequent patch will change this method to use SYMBOL_BLOCK_OPS,
+ and it seemed simplest to move this method out-of-line, and cleaner to
+ do this as a separate change.
+
+ Bump MAX_SYMBOL_IMPLS
+ A subsequent patch will introduce more aclass registrations, causing
+ the number to go over the current maximum. This bumps the number.
+ Note that there's a separate static assert that ensures that this
+ number doesn't get too large for the field size in the symbol.
+
+ Introduce lookup_minimal_symbol_linkage
+ This introduces a new function, lookup_minimal_symbol_linkage, and
+ refactors a couple other existing functions to call it. This function
+ will be used in a subsequent patch.
+
+2023-05-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unnecessary call to std::string constructor
+ I spotted this explicit call to std::string, which creates an
+ unnecessary temporary extra std::string, while calling emplace_back.
+ I'm not sure if it has any impact in an optimized build, maybe the
+ compiler elides it. But still, it's unnecessary.
+
+ Change-Id: I873337ea91db29ac06267aff8fc12dcf52824cac
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-12 Tom Tromey <tromey@adacore.com>
+
+ Add dynamic_prop::is_constant
+ I noticed many spots checking whether a dynamic property's kind is
+ PROP_CONST. Some spots, I think, are doing a slightly incorrect check
+ -- checking for != PROP_UNDEFINED where == PROP_CONST is actually
+ required, the key thing being that const_val may only be called for
+ PROP_CONST properties.
+
+ This patch adds dynamic::is_constant and then updates these checks to
+ use it.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-05-12 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP register scope
+ I noticed that gdb's DAP code did not provide a way to see register
+ values. DAP defines a "register" scope, which this patch implements.
+ This patch also adds the missing (and optional) "presentationHint" to
+ scopes.
+
+2023-05-12 Tom Tromey <tromey@adacore.com>
+
+ Fix calling debuginfo-less functions in Ada
+ A co-worker at AdaCore noticed that calling a function without
+ debuginfo yields:
+
+ (gdb) print plus_one(23)
+ 'pck.plus_one' has unknown return type; cast the call to its declared return type
+
+ However, this also happens if you follow the directions and add the
+ cast.
+
+ This patch fixes the problem and adds a regression test.
+
+2023-05-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: implement DisassemblerResult.__str__ method
+ Add the DisassemblerResult.__str__ method. This gives the same result
+ as the DisassemblerResult.string attribute, but can be useful
+ sometimes depending on how the user is trying to print the object.
+
+ There's a test for the new functionality.
+
+2023-05-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: implement __repr__ methods for py-disasm.c types
+ Add a __repr__ method for the DisassembleInfo and DisassemblerResult
+ types, and add some tests for these new methods.
+
+2023-05-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: improve Python Disassembler API documentation
+ Some small improvements to the Python Disassembler API documentation:
+
+ * Be consistent about using the package scope in the @deftp lines,
+
+ * Rework the description of the DisassemblerResult class to include
+ mention of builtin_disassemble.
+
+2023-05-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: extend special '^' handling to gdb_test_multiple
+ The commit:
+
+ commit 08ec06d6440745ef9204d39197aa1e732df41056
+ Date: Wed Mar 29 10:41:07 2023 +0100
+
+ gdb/testsuite: special case '^' in gdb_test pattern
+
+ Added some special handling of '^' to gdb_test -- a leading '^' will
+ cause the command regexp to automatically be included in the expected
+ output pattern.
+
+ It was pointed out that the '-wrap' flag of gdb_test_multiple is
+ supposed to work in the same way as gdb_test, and that the recent
+ changes for '^' had not been replicated for gdb_test_multiple. This
+ patch addresses this issue.
+
+ So, after this commit, the following two constructs should have the
+ same meaning:
+
+ gdb_test "command" "^output" "test name"
+
+ gdb_test_multiple "command" "test name" {
+ -re -wrap "^output" {
+ pass $gdb_test_name
+ }
+ }
+
+ In both cases the '^' will case gdb.exp to inject a regexp that
+ matches 'command' after the '^' and before the 'output', this is in
+ addition to adding the $gdb_prompt pattern after 'output' in the
+ normal way.
+
+ The special '^' handling is only applied when '-wrap' is used, as this
+ is the only mode that aims to mimic gdb_test.
+
+ While working on this patch I realised that I could actually improve
+ the logic for the special '^' handling in the case where the expected
+ output pattern is empty. I replicated these updates for both gdb_test
+ and gdb_test_multiple in order to keep these two paths in sync.
+
+ There were a small number of tests that needed adjustment after this
+ change, mostly just removing command regexps that are now added
+ automatically, but the gdb.base/settings.exp case was a little weird
+ as it turns out trying to match a single blank line is probably harder
+ now than it used to be -- still, I suspect this is a pretty rare case,
+ so I think the benefits (improved anchoring) outweigh this small
+ downside (IMHO).
+
+2023-05-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix error message for $_gdb_maint_setting
+ I spotted this behaviour:
+
+ (gdb) p $_gdb_maint_setting("xxx")
+ First argument of $_gdb_maint_setting must be a valid setting of the 'show' command.
+
+ Notice that GDB claims I need to use a setting from the 'show'
+ command, which isn't correct for $_gdb_maint_setting, in this case I
+ need to use a setting from 'maintenance show'.
+
+ This same issue is present for $_gdb_maint_setting_str.
+
+ This commit fixes this minor issue.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32
+ When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board
+ unix/-m32 we have:
+ ...
+ (gdb) print noptr^M
+ $1 = {0, <optimized out>, <optimized out>, <optimized out>}^M
+ (gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
+ ...
+
+ The problem happens when evaluating this dwarf expression:
+ ...
+ <45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \
+ (DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8)
+ ...
+
+ The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and
+ the "generic type" has the size of an address on the target machine, which for
+ target board unix/-m32 is 4 bytes. Consequently, the constant is abbreviated.
+
+ Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes
+ large, and we hit this clause in rw_pieced_value:
+ ...
+ /* Use zeroes if piece reaches beyond stack value. */
+ if (p->offset + p->size > stack_value_size_bits)
+ break;
+ ...
+ and consequently get a zero.
+
+ We could just add require is_target_64 to the test-case, but instead, add a
+ 32-bit case and require is_target_64 just for the 64-bit case.
+
+ Tested on x86_64-linux.
+
+2023-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make is_64_target more robust
+ I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and
+ with target board dwarf64 ran into:
+ ...
+ FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
+ ...
+ due to is_target_64 failing because of:
+ ...
+ builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
+ -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \
+ is_64_target.c^M
+ gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \
+ '-gdwarf -g64' for debug level^M
+ compiler exited with status 1
+ ...
+
+ The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64
+ fails for both cases.
+
+ The reason that is_target_64 is failing for target board dwarf64, is because
+ of using system compiler 7.5.0 which doesn't support -gdwarf64.
+
+ Fix this by making is_target_64 use nodebug instead of debug for compilation.
+
+ Tested on x86_64-linux.
+
+2023-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Fix wrapping for TERM=ansi
+ I. Auto-detected width (xterm vs. ansi)
+
+ Say we have a terminal with a width of 40 chars:
+ ...
+ $ echo $COLUMNS
+ 40
+ ...
+
+ With TERM=xterm, we report a width of 40 chars:
+ ...
+ $ TERM=xterm gdb
+ (gdb) show width
+ Number of characters gdb thinks are in a line is 40.
+ ...
+
+ And with TERM=ansi, a width of 39 chars:
+ ...
+ $ TERM=ansi gdb
+ (gdb) show width
+ Number of characters gdb thinks are in a line is 39.
+ ...
+
+ Gdb uses readline to auto-detect screen size, and readline decides in the
+ TERM=ansi case that the terminal does not have reliable auto-wrap, and
+ consequently decides to hide the last terminal column from the readline user
+ (in other words GDB), hence we get 39 instead of 40.
+
+ II. Types of wrapping
+
+ Looking a bit more in detail inside gdb, it seems there are two types of
+ wrapping:
+ - readline wrapping (in other words, prompt edit wrapping), and
+ - gdb output wrapping (can be observed by issuing "info sources").
+ This type of wrapping attempts to wrap some of the gdb output earlier
+ than the indicated width, to not break lines in inconvenient places.
+
+ III. Readline wrapping, auto-detected screen size
+
+ Let's investigate readline wrapping with the auto-detected screen widths.
+
+ First, let's try with xterm:
+ ...
+ $ TERM=xterm gdb
+ (gdb) 7890123456789012345678901234567890
+ 123
+ ...
+ That looks as expected, wrapping occurs after 40 chars.
+
+ Now, let's try with ansi:
+ ...
+ $ TERM=ansi gdb
+ (gdb) 78901234567890123456789012345678
+ 90123
+ ...
+ It looks like wrapping occurred after 38, while readline should be capable of
+ wrapping after 39 chars.
+
+ This is caused by readline hiding the last column, twice.
+
+ In more detail:
+ - readline detects the screen width: 40,
+ - readline hides the last column, setting the readline screen width to 39,
+ - readline reports 39 to gdb as screen width,
+ - gdb sets its width setting to 39,
+ - gdb sets readline screen width to 39,
+ - readline hides the last column, again, setting the readline screen width to
+ 38.
+
+ This is reported as PR cli/30346.
+
+ IV. gdb output wrapping, auto-detected screen size
+
+ Say we set the terminal width to 56. With TERM=xterm, we have:
+ ...
+ /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
+ /data/vries/hello.c,
+ ...
+ but with TERM=ansi:
+ ...
+ /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
+ data/vries/hello.c,
+ ...
+
+ So what happened here? With TERM=ansi, the width setting is auto-detected to
+ 55, and gdb assumes the terminal inserts a line break there, which it doesn't
+ because the terminal width is 56.
+
+ This is reported as PR cli/30411.
+
+ V. Fix PRs
+
+ Fix both mentioned PRs by taking into account the hidden column when readline
+ reports the screen width in init_page_info, and updating chars_per_line
+ accordingly.
+
+ Note that now we report the same width for both TERM=xterm and TERM=ansi,
+ which is much clearer.
+
+ The point where readline respectively expects or ensures wrapping is still
+ indicated by "maint info screen", for xterm:
+ ...
+ Number of characters readline reports are in a line is 40.
+ ...
+ and ansi:
+ ...
+ Number of characters readline reports are in a line is 39.
+ ...
+
+ VI. Testing
+
+ PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
+ and gdb.tui/wrap-line.exp, so remove the KFAILs there.
+
+ I didn't manage to come up with a regression test for PR cli/30411. Perhaps
+ that would be easier if we had a maintenance command that echoes its arguments
+ while applying gdb output wrapping.
+
+ Tested on x86_64-linux.
+
+ PR cli/30346
+ PR cli/30411
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411
+
+2023-05-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: move a few more disassembler helper functions
+ ... such that they wouldn't need forward declarations anymore. Note that
+ append_seg() already was suitably placed.
+
+ x86: move get<N>() disassembler helper functions
+ ... such that none of them would need forward declarations anymore.
+
+ x86: slightly simplify i386_parse_name()
+ With the switch to parse_real_register() (commit 4faaa10f3fab) "bad_reg"
+ cannot come back anymore. Drop the respective check.
+
+2023-05-12 Jan Beulich <jbeulich@suse.com>
+
+ gas: equates of registers
+ There are two problems: symbol_equated_p() doesn't recognize equates of
+ registers, and S_CAN_BE_REDEFINED() goes by section rather than by
+ expression type. Both together undermine .eqv and .equiv clearly meaning
+ to guard the involved symbols against re-definition (both ways).
+
+ To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
+ now checking for O_register,
+ - for targets creating register symbols through symbol_{new,create}() ->
+ symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
+ mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
+ symbol_init() set their expressions to O_register,
+ - x86'es parse_register() also can't go by section anymore when
+ trying to "look through" equates; probably symbol_equated_p() should
+ have been used there from the beginning, if only that had worked for
+ equates of registers,
+ - various targets need to "look through" equates when parsing insn
+ operands (which also helps transitive forward equates); perhaps even
+ more ought to, but many don't look to consider the possibility of
+ register equates in the first place.
+
+ This was uncovered by code reported in PR gas/30274 (duplicating
+ PR gas/30272), except that there .eqv was used when really .equ was
+ meant. Therefore that bug report is addressed here only in so far as
+ gas wouldn't crash anymore; the code there still won't assemble
+ successfully, just that now the issues there are properly diagnosed.
+
+2023-05-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-11 Tom Tromey <tom@tromey.com>
+
+ Do not print <synthetic pointer> when piece is optimized out
+ A user reported a bug where printing a certain array of integer types
+ would result in the nonsensical:
+
+ (gdb) p l_126
+ $1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>}
+
+ I tracked this down to some issues in the DWARF expression code.
+ First, check_pieced_synthetic_pointer did not account for the
+ situation where a location expression does not describe all the bits
+ of a value -- in this case it returned true, meaning there is a
+ synthetic pointer, but in fact these bits are optimized out. (It
+ turns out this incorrect output had already been erroneously tested
+ for as well.)
+
+ Next, rw_pieced_value did not mark these bits as optimized-out,
+ either.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296
+
+2023-05-11 Aaron Merey <amerey@redhat.com>
+
+ gdb/testsuite: Match file size in gdb.debuginfod/crc_mismatch.exp
+ gdb's debuginfod progress messages include the size of the file being
+ downloaded if the size information is available at the time the message
+ is printed. For example:
+
+ Downloading 10 MB separate debug info for /lib64/libxyz.so
+
+ This size information is omitted if it's not available at the time of
+ printing:
+
+ Downloading separate debug info for /lib64/libxyz.so
+
+ A pattern in crc_mismatch.exp fails to be matched if a progress message
+ includes a file size. Add a wildcard to the pattern so that it matches
+ the progress message whether or not it includes the file size.
+
+2023-05-11 Johnson Sun <j3.soon777@gmail.com>
+
+ Disable out-of-scope watchpoints
+ Currently, when a local software watchpoint goes out of scope, GDB sets
+ the watchpoint's disposition to `delete at next stop' and then normal
+ stops (i.e., stop and wait for the next GDB command). When GDB normal
+ stops, it automatically deletes the breakpoints with their disposition
+ set to `delete at next stop'.
+
+ Suppose a Python script decides not to normal stop when a local
+ software watchpoint goes out of scope, the watchpoint will not be
+ automatically deleted even when its disposition is set to
+ `delete at next stop'.
+
+ Since GDB single-steps the program and tests the watched expression
+ after each instruction, not deleting the watchpoint causes the
+ watchpoint to be hit many more times than it should, as reported in
+ PR python/29603.
+
+ This was happening because the watchpoint is not deleted or disabled
+ when going out of scope.
+
+ This commit fixes this issue by disabling the watchpoint when going out
+ of scope. It also adds a test to ensure this feature isn't regressed in
+ the future.
+
+ Calling `breakpoint_auto_delete' on all kinds of stops (in
+ `fetch_inferior_event') seem to solve this issue, but is in fact
+ inappropriate, since `breakpoint_auto_delete' goes over all breakpoints
+ instead of just going through the bpstat chain (which only contains the
+ breakpoints that were hit right now).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29603
+ Change-Id: Ia85e670b2bcba2799219abe4b6be3b582387e383
+
+2023-05-11 Tom Tromey <tromey@adacore.com>
+
+ Add "scheduler-locking" to documentation index
+ I noticed that "scheduler-locking" does not appear in the index of the
+ gdb manual. This patch corrects this oversight.
+
+2023-05-11 Joseph Myers <joseph@codesourcery.com>
+
+ Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]
+ This is one part of the fix for GCC PR109128, along with a
+ corresponding GCC change. Without this patch, what happens in the
+ linker, when an unused object in a .a file has offload data, is that
+ elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p,
+ which ends up calling the plugin's claim_file_handler, which then
+ records the object as one with offload data. That is, the linker never
+ decides to use the object in the first place, but use of this _p
+ interface (called as part of trying to decide whether to use the
+ object) results in the plugin deciding to use its offload data (and a
+ consequent mismatch in the offload data present at runtime).
+
+ The new hook allows the linker plugin to distinguish calls to
+ claim_file_handler that know the object is being used by the linker
+ (from ldmain.c:add_archive_element), from calls that don't know it's
+ being used by the linker (from elf_link_is_defined_archive_symbol); in
+ the latter case, the plugin should avoid recording the object as one
+ with offload data.
+
+ bfd/
+ * plugin.c (struct plugin_list_entry): Add claim_file_v2.
+ (register_claim_file_v2): New.
+ (try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
+ (ld_plugin_object_p): Take second argument.
+ (bfd_link_plugin_object_p): Update call to ld_plugin_object_p.
+ (register_ld_plugin_object_p): Update argument prototype.
+ (bfd_plugin_object_p): Update call to ld_plugin_object_p.
+ * plugin.h (register_ld_plugin_object_p): Update argument
+ prototype.
+
+ include/
+ * plugin.api.h (ld_plugin_claim_file_handler_v2)
+ (ld_plugin_register_claim_file_v2)
+ (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
+ (struct ld_plugin_tv): Add tv_register_claim_file_v2.
+
+ ld/
+ * plugin.c (struct plugin): Add claim_file_handler_v2.
+ (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
+ (plugin_object_p): Add second argument. Update call to
+ plugin_call_claim_file.
+ (register_claim_file_v2): New.
+ (set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
+ (plugin_call_claim_file): Add argument known_used.
+ (plugin_maybe_claim): Update call to plugin_object_p.
+ * testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle
+ LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
+ * testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d,
+ testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d,
+ testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d,
+ testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d,
+ testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d,
+ testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d,
+ testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d,
+ testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d,
+ testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d,
+ testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d:
+ Update test expectations.
+
+2023-05-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix tui compact-source a bit more
+ Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp
+ is incorrect:
+ ...
+ 0 +-compact-source.c--------------------------------------------------------+
+ 1 |___3_{ |
+ 2 |___4_ return 0; |
+ 3 |___5_} |
+ 4 |___6_ |
+ 5 |___7_ |
+ 6 |___8_ |
+ 7 |___9_ |
+ 8 +-------------------------------------------------------------------------+
+ ...
+
+ The last line number in the source file is 5, and there are 7 lines to display
+ source lines, so if we'd scroll all the way down, the first line number in the
+ source window would be 5, and the last one would be 11.
+
+ To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of
+ ___4_, even though all line numbers currently in the src window (3-9) can be
+ represented with only 1 digit.
+
+ Fix this in tui_source_window::set_contents, by updating the computation of
+ max_line_nr:
+ ...
+ - int max_line_nr = std::max (lines_in_file, last_line_nr_in_window);
+ + int max_line_nr = lines_in_file + nlines - 1;
+ ...
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/rust: fix crash for expression debug with strings
+ While working on another patch I did this:
+
+ (gdb) set debug expression 1
+ (gdb) set language rust
+ (gdb) p "foo"
+ Operation: OP_AGGREGATE
+ Type: &str
+
+ Fatal signal: Segmentation fault
+ ... etc ...
+
+ The problem is that the second field of the rust_aggregate_operation
+ is created as a nullptr, this can be seen in rust-parse.c. in the
+ function rust_parser::parse_string().
+
+ However, in expop.h, in the function dump_for_expression, we make the
+ assumption that the expressions will never be nullptr.
+
+ I did consider moving the nullptr handling into a new function
+ rust_aggregate_operation::dump, however, as the expression debug
+ dumping code is not exercised as much as it might be, I would rather
+ that this code be hardened and able to handle a nullptr without
+ crashing, so I propose that we add nullptr handling into the general
+ dump_for_expression function. The behaviour is now:
+
+ (gdb) set debug expression 1
+ (gdb) set language rust
+ (gdb) p "foo"
+ Operation: OP_AGGREGATE
+ Type: &str
+ nullptr
+ Vector:
+ String: data_ptr
+ Operation: UNOP_ADDR
+ Operation: OP_STRING
+ String: foo
+ String: length
+ Operation: OP_LONG
+ Type: usize
+ Constant: 3
+ evaluation of this expression requires the target program to be active
+ (gdb)
+
+ There's a new test to check for this case.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-10 Alan Modra <amodra@gmail.com>
+
+ Re: stack overflow in debug_write_type
+ Apparently u.kindirect->slot can point at a NULL.
+
+ * debug.c (debug_write_type): Don't segfault on NULL indirect.
+
+2023-05-10 Luca Bonissi <gcc@scarsita.it>
+
+ or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large
+ PR 30422
+ * elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs.
+
+2023-05-10 Nick Clifton <nickc@redhat.com>
+
+ Add linker option to include local symbols in the linker map.
+ PR 16566
+ * ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section.
+ * ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS.
+ * lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals.
+ * NEWS: Mention the new feature.
+ * ld.h (struct ld_config_type): Add print_map_locals field.
+ * ld.texi: Document the new command line option.
+ * testsuite/ld-scripts/sizeof.s: Add a local symbol.
+ * testsuite/ld-scripts/map-locals.d: New test control file.
+ * testsuite/ld-scripts/map-address.exp: Run the new test.
+
+2023-05-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix tui compact-source
+ Consider a hello.c, with less than 10 lines:
+ ...
+ $ wc -l hello.c
+ 8 hello.c
+ ...
+ and compiled with -g into an a.out.
+
+ With compact-source off:
+ ...
+ $ gdb -q a.out \
+ -ex "set tui border-kind ascii" \
+ -ex "maint set tui-left-margin-verbose on" \
+ -ex "set tui compact-source off" \
+ -ex "tui enable"
+ ...
+ we get:
+ ...
+ +-./data/hello.c-----------------------+
+ |___000005_{ |
+ |___000006_ printf ("hello\n"); |
+ |___000007_ return 0; |
+ |___000008_} |
+ |___000009_ |
+ |___000010_ |
+ |___000011_ |
+ ...
+ but with compact-source on:
+ ...
+ +-./data/hello.c-----------------------+
+ |___5{ |
+ |___6 printf ("hello\n"); |
+ |___7 return 0; |
+ |___8} |
+ |___9 |
+ |___1 |
+ |___1 |
+ ...
+
+ There are a couple of problems with compact-source.
+
+ First of all the documentation mentions:
+ ...
+ The default display uses more space for line numbers and starts the
+ source text at the next tab stop; the compact display uses only as
+ much space as is needed for the line numbers in the current file, and
+ only a single space to separate the line numbers from the source.
+ ...
+
+ The bit about the default display and the next tab stop looks incorrect. The
+ source doesn't start at a tab stop, instead it uses a single space to separate
+ the line numbers from the source.
+
+ Then the documentation mentions that there's single space in the compact
+ display, but evidently that's missing.
+
+ Then there's the fact that the line numbers "10" and "11" are both abbreviated
+ to "1" in the compact case.
+
+ The abbreviation is due to allocating space for <lines in source>, which is
+ 8 for this example, and takes a single digit. The line numbers though
+ continue past the end of the file, so fix this by allocating space for
+ max (<lines in source>, <last line in window>), which in this example takes 2
+ digits.
+
+ The missing space is due to some confusion about what the "1" here in
+ tui_source_window::set_contents represent:
+ ...
+ double l = log10 ((double) offsets->size ());
+ m_digits = 1 + (int) l;
+ ...
+
+ It could be the trailing space that's mentioned in tui-source.h:
+ ...
+ /* How many digits to use when formatting the line number. This
+ includes the trailing space. */
+ int m_digits;
+ ...
+
+ Then again, it could be part of the calculation for the number of digits
+ needed for printing. With this minimal example:
+ ...
+ int main () {
+ for (int i = 8; i <= 11; ++i) {
+ double l = log10 ((double) i);
+ printf ("%d %d\n", i, (int)l);
+ }
+ return 0;
+ }
+ ...
+ we get:
+ ...
+ $ ./a.out
+ 8 0
+ 9 0
+ 10 1
+ 11 1
+ ...
+ which shows that the number of digits needed for printing i is
+ "1 + (int)log10 ((double) i)".
+
+ Fix this by introducing named variables needed_digits and trailing_space, each
+ adding 1.
+
+ With the fixes, we get for compact-source on:
+ ...
+ +-./data/hello.c-----------------------+
+ |___05_{ |
+ |___06_ printf ("hello\n"); |
+ |___07_ return 0; |
+ |___08_} |
+ |___09_ |
+ |___10_ |
+ |___11_ |
+ |...
+
+ Also fix the documentation and help text to actually match effect of
+ compact-source.
+
+ Tested on x86_64-linux.
+
+2023-05-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-09 Dan Callaghan <dan.callaghan@morsemicro.com>
+
+ Support higher baud rates when they are defined
+ On Linux at least, baud rate codes are defined up to B4000000. Allow the
+ user to select them if they are present in the system headers.
+
+ Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e
+
+2023-05-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy
+ Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a
+ use-after-free in the breakpoints iterations (see below for full ASan
+ report). This makes gdb.base/stale-infcall.exp fail when GDB is build
+ with ASan.
+
+ check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints,
+ possibly deleting the current breakpoint as well as related breakpoints.
+ The problem arises when a breakpoint in the B->related_breakpoint chain
+ is also B->next. In that case, deleting that related breakpoint frees
+ the breakpoint that all_breakpoints_safe has saved.
+
+ The old code worked around that by manually changing B_TMP, which was
+ the next breakpoint saved by the "safe iterator":
+
+ while (b->related_breakpoint != b)
+ {
+ if (b_tmp == b->related_breakpoint)
+ b_tmp = b->related_breakpoint->next;
+ delete_breakpoint (b->related_breakpoint);
+ }
+
+ (Note that this seemed to assume that b->related_breakpoint->next was
+ the same as b->next->next, not sure this is guaranteed.)
+
+ The new code kept the B_TMP variable, but it's not useful in that
+ context. We can't go change the next breakpoint as saved by the safe
+ iterator, like we did before. I suggest fixing that by saving the
+ breakpoints to delete in a map and deleting them all at the end.
+
+ Here's the full ASan report:
+
+ (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1
+ print infcall ()
+ =================================================================
+ ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60
+ READ of size 8 at 0x611000034980 thread T0
+ #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66
+ #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84
+ #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611
+ #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
+ #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
+ #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
+ #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
+ #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
+ #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
+ #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
+ #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
+ #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
+ #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
+ #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
+ #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
+ #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
+ #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
+ #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
+ #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
+ #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
+ #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
+ #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
+ #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
+ #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
+ #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
+ #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
+ #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
+ #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
+ #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
+ #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
+ #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
+ #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
+ #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192
+ #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225
+ #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155
+ #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
+ #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
+ #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
+ #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412
+ #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476
+ #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320
+ #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339
+ #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
+ #44 0x7f5a7e43984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
+ #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
+ #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995)
+
+ 0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50)
+ freed by thread T0 here:
+ #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164
+ #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304
+ #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404
+ #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673
+ #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
+ #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
+ #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
+ #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
+ #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
+ #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
+ #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
+ #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
+ #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
+ #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
+ #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
+ #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
+ #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
+ #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
+ #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
+ #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
+ #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
+ #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
+ #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
+ #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
+ #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
+ #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
+ #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
+ #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
+ #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
+
+ previously allocated by thread T0 here:
+ #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
+ #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129
+ #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169
+ #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582
+ #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260
+ #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
+ #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
+ #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
+ #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
+ #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
+ #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
+ #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
+ #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
+ #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
+ #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
+ #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
+ #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
+ #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
+ #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
+ #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
+ #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
+ #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
+
+ Change-Id: Id00c17ab677f847fbf4efdf0f4038373668d3d88
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-09 Enze Li <enze.li@gmx.com>
+
+ Correct a spelling mistake in the binutils README file.
+
+2023-05-09 Alan Modra <amodra@gmail.com>
+
+ stack overflow in debug_write_type
+ Another fuzzer attack. This one was a "set" with elements using an
+ indirect type pointing back at the set. The existing recursion check
+ only prevented simple recursion.
+
+ * debug.c (struct debug_type_s): Add mark.
+ (debug_write_type): Set mark and check before recursing into
+ indirect types.
+
+2023-05-09 Alan Modra <amodra@gmail.com>
+
+ alpha-vms reloc sanity check
+ Stops fuzzed files triggering reads past the end of the reloc buffer.
+
+ * vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records.
+
+2023-05-09 Alan Modra <amodra@gmail.com>
+
+ regen ld/Makefile.in
+
+2023-05-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-08 John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Clear upper ZMM registers in the right location.
+ This was previously clearing the upper 32 bytes of ZMM0-15 rather than
+ ZMM16-31.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-05-08 John Baldwin <jhb@FreeBSD.org>
+
+ x86-fbsd-nat: Add missing public label.
+ These two methods are both overrides of public methods in base
+ classes.
+
+2023-05-08 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb: Avoid warning for the jump command inside an inline function.
+ When stopped inside an inline function, trying to jump to a different line
+ of the same function currently results in a warning about jumping to another
+ function. Fix this by taking inline functions into account.
+
+ Before:
+ Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22
+ 22 a = a + x; /* inline-funct */
+ (gdb) j 21
+ Line 21 is not in `function_inline(int)'. Jump anyway? (y or n)
+
+ After:
+ Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22
+ 22 a = a + x; /* inline-funct */
+ (gdb) j 21
+ Continuing at 0x400679.
+
+ Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21
+ 21 a += 1020 + a; /* increment-funct */
+
+ This was regression-tested on X86-64 Linux.
+
+ Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-08 Alan Modra <amodra@gmail.com>
+
+ pe.em and pep.em make_import_fixup
+ This is a little cleanup that I made when looking at pr30343 that
+ makes it more obvious that make_import_fixup in both files are
+ identical (and in fact the new pep.em read_addend could be used in
+ both files).
+
+ * emultempl/pep.em (read_addend): Extract from..
+ (make_import_fixup): ..here.
+ * emultempl/pe.em (read_addend): Similarly.
+ (make_import_fixup): Similarly. Add debug code from pep.em.
+
+2023-05-08 Alan Modra <amodra@gmail.com>
+
+ PR30343, LTO ignores linker reference to _pei386_runtime_relocator
+ Make a reference to _pei386_runtime_relocator before LTO recompilation.
+ This is done regardless of whether such a reference will be used,
+ because it can't be known whether it is needed before LTO.
+
+ I also found it necessary to enable long section names for the bfd
+ created in make_runtime_pseudo_reloc, because otherwise when writing
+ it out to the bfd-in-memory we get the section written as .rdata_r
+ which when read back in leads to a linker warning ".rdata_r: section
+ below image base" and likely runtime misbehaviour.
+
+ PR 30343
+ * emultempl/pe.em (make_runtime_ref): New function.
+ (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function.
+ (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define.
+ * emultempl/pep.em: Similarly to pe.em.
+ * pe-dll.c (make_runtime_pseudo_reloc): Set long section names.
+
+2023-05-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-07 Tom Tromey <tom@tromey.com>
+
+ Remove parameter from select_source_symtab
+ I noticed that select_source_symtab is only ever called with nullptr
+ as an argument, so this patch removes the parameter and associated
+ logic.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-05-07 Tom Tromey <tom@tromey.com>
+
+ Remove ALL_BREAKPOINTS_SAFE
+ There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro;
+ this patch replaces it with a for-each and an explicit temporary
+ variable.
+
+ Remove ALL_DICT_SYMBOLS
+ This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can
+ be used.
+
+ Remove ALL_OBJFILE_OSECTIONS
+ This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each
+ can be used.
+
+ Rename objfile::sections
+ I think objfile::sections makes sense as the name of the method to
+ iterate over an objfile's sections, so this patch renames the existing
+ field to objfile::sections_start in preparation for that.
+
+2023-05-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-06 Tom Tromey <tom@tromey.com>
+
+ Allow pretty-print of static members
+ Python pretty-printers haven't applied to static members for quite
+ some time. I tracked this down to the call to cp_print_value_fields
+ in cp_print_static_field -- it doesn't let pretty-printers have a
+ chance to print the value. This patch fixes the problem.
+
+ The way that static members are handled is very weird to me. I tend
+ to think this should be done more globally, like in value_print.
+ However, I haven't made any big change.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+ Tested-by: Keith Seitz <keiths@redhat.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057
+
+2023-05-06 YunQiang Su <yunqiang.su@cipunited.com>
+
+ gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA
+ It is added since 2016 by
+ Add support for .MIPS.abiflags and .gnu.attributes sections
+ b52717c0e104eb603e8189c3c0d3658ef5d903f5
+ But never documented.
+
+2023-05-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-05 Tom Tromey <tromey@adacore.com>
+
+ Filter out types from DAP scopes request
+ The DAP scopes request examines the symbols in a block tree, but
+ neglects to omit types. This patch fixes the problem.
+
+2023-05-05 Tom Tromey <tromey@adacore.com>
+
+ Use discrete_position in ada-valprint.c
+ I found a couple of spots in ada-valprint.c that use an explicit loop,
+ but where discrete_position could be used instead.
+
+ Reviewed-by: Keith Seitz <keiths@redhat.com>
+
+2023-05-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add mechanism to manage Python initialization functions
+ Currently, when we add a new python sub-system to GDB,
+ e.g. py-inferior.c, we end up having to create a new function like
+ gdbpy_initialize_inferior, which then has to be called from the
+ function do_start_initialization in python.c.
+
+ In some cases (py-micmd.c and py-tui.c), we have two functions
+ gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
+ from finalize_python which is also in python.c.
+
+ This commit proposes a mechanism to manage these initialization and
+ finalization calls, this means that adding a new Python subsystem will
+ no longer require changes to python.c or python-internal.h, instead,
+ the initialization and finalization functions will be registered
+ directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.
+
+ The initialization and finalization functions are managed through a
+ new class gdbpy_initialize_file in python-internal.h. This class
+ contains a single global vector of all the initialization and
+ finalization functions.
+
+ In each Python sub-system we create a new gdbpy_initialize_file
+ object, the object constructor takes care of registering the two
+ callback functions.
+
+ Now from python.c we can call static functions on the
+ gdbpy_initialize_file class which take care of walking the callback
+ list and invoking each callback in turn.
+
+ To slightly simplify the Python sub-system files I added a new macro
+ GDBPY_INITIALIZE_FILE, which hides the need to create an object. We
+ can now just do this:
+
+ GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);
+
+ One possible problem with this change is that there is now no
+ guaranteed ordering of how the various sub-systems are initialized (or
+ finalized). To try and avoid dependencies creeping in I have added a
+ use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
+ the same environment variable used in the generated init.c file.
+
+ Just like with init.c, when this environment variable is set we
+ reverse the list of Python initialization (and finalization)
+ functions. As there is already a test that starts GDB with the
+ environment variable set then this should offer some level of
+ protection against dependencies creeping in - though for full
+ protection I guess we'd need to run all gdb.python/*.exp tests with
+ the variable set.
+
+ I have tested this patch with the environment variable set, and saw no
+ regressions, so I think we are fine right now.
+
+ One other change of note was for gdbpy_initialize_gdb_readline, this
+ function previously returned void. In order to make this function
+ have the correct signature I've updated its return type to int, and we
+ now return 0 to indicate success.
+
+ All of the other initialize (and finalize) functions have been made
+ static within their respective sub-system files.
+
+ There should be no user visible changes after this commit.
+
+2023-05-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: more newline pattern cleanup
+ After this commit:
+
+ commit e2f620135d92f7cd670af4e524fffec7ac307666
+ Date: Thu Mar 30 13:26:25 2023 +0100
+
+ gdb/testsuite: change newline patterns used in gdb_test
+
+ It was pointed out in PR gdb/30403 that the same patterns can be found
+ in other lib/gdb.exp procs and that it would probably be a good idea
+ if these procs remained in sync with gdb_test. Actually, the bug
+ specifically calls out gdb_test_multiple when using with '-wrap', but
+ I found a couple of other locations in gdb_continue_to_breakpoint,
+ gdb_test_multiline, get_valueof, and get_local_valueof.
+
+ In all these locations one or both of the following issues are
+ addressed:
+
+ 1. A leading pattern of '[\r\n]*' is pointless. If there is a
+ newline it will be matched, but if there is not then the testsuite
+ doesn't care. Also, as expect is happy to skip non-matched output
+ at the start of a pattern, if there is a newline expect is happy to
+ skip over it before matching the rest. As such, this leading
+ pattern is removed.
+
+ 2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
+ unexpected blank lines at the end of a command's output, but also,
+ if the pattern from the test script ends with a '\r', '\n', or '.'
+ then these will partially match the trailing newline, with the
+ remainder of the newline matched by the pattern from gdb.exp. This
+ split matching doesn't add any value, it's just something that has
+ appeared as a consequence of how gdb.exp was originally written. In
+ this case the '\[\r\n\]*' is replaced with '\r\n'.
+
+ I've rerun the testsuite and fixed the regressions that I saw, these
+ were places where GDB emits a blank line at the end of the command
+ output, which we now need to explicitly match in the test script, this
+ was for:
+
+ gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
+ gdb.guile/guile.exp
+ gdb.python/python.exp
+
+ Or a location where the test script was matching part of the newline
+ sequence, while gdb.exp was previously matching the remainder of the
+ newline sequence. Now we rely on gdb.exp to match the complete
+ newline sequence, this was for:
+
+ gdb.base/commands.exp
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
+
+2023-05-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Generate long string in gdb.base/page.exp
+ I noticed in gdb.base/page.exp:
+ ...
+ set fours [string repeat 4 40]
+ ...
+ but then shortly afterwards:
+ ...
+ [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444]
+ ...
+
+ Summarize the long string in the same way using string repeat:
+ ...
+ [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]]
+ ...
+
+ Tested on x86_64-linux.
+
+2023-05-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: tighten patterns in build-id-no-debug-warning.exp
+ Tighten the expected output pattern in the test script:
+
+ gdb.debuginfod/build-id-no-debug-warning.exp
+
+ While working on some other patch I broke GDB such that this warning:
+
+ warning: "FILENAME": separate debug info file has no debug info
+
+ (which is generated in build-id.c) didn't actually include the
+ FILENAME any more -- yet this test script continued to pass. It turns
+ out that this script doesn't actually check for FILENAME.
+
+ This commit extends the test pattern to check for the full warning
+ string, including FILENAME, and also removes some uses of '.*' to make
+ the test stricter.
+
+2023-05-05 Tom Tromey <tom@tromey.com>
+
+ Simplify decode_locdesc
+ While looking into another bug, I noticed that the DWARF cooked
+ indexer picks up an address for this symbol:
+
+ <1><82>: Abbrev Number: 2 (DW_TAG_variable)
+ <83> DW_AT_specification: <0x9f>
+ <87> DW_AT_location : 10 byte block: e 0 0 0 0 0 0 0 0 e0 (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)
+ <92> DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E
+
+ This happens because decode_locdesc allows the use of
+ DW_OP_GNU_push_tls_address.
+
+ This didn't make sense to me. I looked into it a bit more, and I
+ think decode_locdesc is used in three ways:
+
+ 1. Find a constant address of a symbol that happens to be encoded as a
+ location expression.
+
+ 2. Find the offset of a function in a virtual table. (This one should
+ probably be replaced by code to just evaluate the expression in
+ gnu-v3-abi.c -- but there's no point yet because no compiler
+ actually seems to emit correct DWARF here, see the bug linked in
+ the patch.)
+
+ 3. Find the offset of a field, if the offset is a constant.
+
+ None of these require TLS.
+
+ This patch simplifies decode_locdesc by removing any opcodes that
+ don't fit into the above. It also changes the API a little, to make
+ it less difficult to use.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-05-05 Tom Tromey <tom@tromey.com>
+
+ Simplify auto_load_expand_dir_vars and remove substitute_path_component
+ This simplifies auto_load_expand_dir_vars to first split the string,
+ then do any needed substitutions. This was suggested by Simon, and is
+ much simpler than the current approach.
+
+ Then this patch also removes substitute_path_component, as it is no
+ longer called. This is nice because it helps with the long term goal
+ of removing utils.h.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-05-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.base/wrap-line.exp
+ Add a test-case that tests prompt edit wrapping in CLI, both
+ for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width.
+
+ In the TERM=ansi case with auto-detected width we run into PR cli/30346, so
+ add a KFAIL for that failure mode.
+
+ Tested on x86_64-linux.
+
+2023-05-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.tui/wrap-line.exp
+ Add a test-case that tests prompt edit wrapping behaviour in the tuiterm, both
+ for CLI and TUI, both with auto-detected and hard-coded width.
+
+ In the CLI case with auto-detected width we run into PR cli/30411, so add a
+ KFAIL for that failure mode.
+
+ Tested on x86_64-linux.
+
+2023-05-05 Nick Clifton <nickc@redhat.com>
+
+ Debug info is lost for functions only called from functions marked with cmse_nonsecure_entr
+ PR 30354
+ * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies.
+
+2023-05-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-04 Bruno Larsen <blarsen@redhat.com>
+
+ Revert "gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp"
+ This reverts commit 476410b3bca1389ee69e9c8fa18aaee16793a56d.
+
+ One of Simon's recent commits (2a740b3ba4c9f39c86dd75e0914ee00942cab471)
+ changed the way recording a remote target works and fixed the underlying
+ issue of the bug, so the KFails can be removed from the test.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-05-04 Gareth Rees <grees@undo.io>
+
+ Don't treat references to compound values as "simple".
+ SUMMARY
+
+ The '--simple-values' argument to '-stack-list-arguments' and similar
+ GDB/MI commands does not take reference types into account, so that
+ references to arbitrarily large structures are considered "simple" and
+ printed. This means that the '--simple-values' argument cannot be used
+ by IDEs when tracing the stack due to the time taken to print large
+ structures passed by reference.
+
+ DETAILS
+
+ Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals',
+ '-stack-list-variables' and so on) take a PRINT-VALUES argument which
+ may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2).
+ In the '--simple-values' case, the command is supposed to print the
+ name, type, and value of variables with simple types, and print only the
+ name and type of variables with compound types.
+
+ The '--simple-values' argument ought to be suitable for IDEs that need
+ to update their user interface with the program's call stack every time
+ the program stops. However, it does not take C++ reference types into
+ account, and this makes the argument unsuitable for this purpose.
+
+ For example, consider the following C++ program:
+
+ struct s {
+ int v[10];
+ };
+
+ int
+ sum(const struct s &s)
+ {
+ int total = 0;
+ for (int i = 0; i < 10; ++i) total += s.v[i];
+ return total;
+ }
+
+ int
+ main(void)
+ {
+ struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } };
+ return sum(s);
+ }
+
+ If we start GDB in MI mode and continue to 'sum', the behaviour of
+ '-stack-list-arguments' is as follows:
+
+ (gdb)
+ -stack-list-arguments --simple-values
+ ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}]
+
+ Note that the value of the argument 's' was printed, even though 's' is
+ a reference to a structure, which is not a simple value.
+
+ See https://github.com/microsoft/MIEngine/pull/673 for a case where this
+ behaviour caused Microsoft to avoid the use of '--simple-values' in
+ their MIEngine debug adapter, because it caused Visual Studio Code to
+ take too long to refresh the call stack in the user interface.
+
+ SOLUTIONS
+
+ There are two ways we could fix this problem, depending on whether we
+ consider the current behaviour to be a bug.
+
+ 1. If the current behaviour is a bug, then we can update the behaviour
+ of '--simple-values' so that it takes reference types into account:
+ that is, a value is simple if it is neither an array, struct, or
+ union, nor a reference to an array, struct or union.
+
+ In this case we must add a feature to the '-list-features' command so
+ that IDEs can detect that it is safe to use the '--simple-values'
+ argument when refreshing the call stack.
+
+ 2. If the current behaviour is not a bug, then we can add a new option
+ for the PRINT-VALUES argument, for example, '--scalar-values' (3),
+ that would be suitable for use by IDEs.
+
+ In this case we must add a feature to the '-list-features' command
+ so that IDEs can detect that the '--scalar-values' argument is
+ available for use when refreshing the call stack.
+
+ PATCH
+
+ This patch implements solution (1) as I think the current behaviour of
+ not printing structures, but printing references to structures, is
+ contrary to reasonable expectation.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554
+
+2023-05-04 Nick Clifton <nickc@redhat.com>
+
+ Stop the linker from loosing the entry point for COFF/PE code when compiling with LTO enabled.
+ PR 30300
+ * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically.
+ * emultempl/pe.em (set_entry_point): Likewise.
+
+2023-05-04 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ ld: pru: Place exception-handling sections correctly
+ * scripttempl/pru.sc (OUTPUT_SECTION_ALIGN): New helper variable to place at end of DMEM output sections.
+ (.data): Use the helper variable.
+ (.eh_frame): New output section.
+ (.gnu_extab): Ditto.
+ (.gcc_except_table): Ditto.
+ (.resource_table): Use the helper variable.
+
+2023-05-04 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: tighten post-relocation-operator separator expectation
+ As per the spec merely a blank isn't okay as a separator, the operand
+ to the relocation function ought to be parenthesized. Enforcing this
+ then also eliminates an inconsistency in that
+
+ lui t0, %hi sym
+ lui t0, %hi 0x1000
+
+ were accepted, but
+
+ lui t0, %hi +sym
+ lui t0, %hi -0x1000
+
+ were not.
+
+2023-05-04 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ gas: fix building tc-bpf.c on s390x
+ char is unsigned on s390x, so there are a lot of warnings like:
+
+ gas/config/tc-bpf.c: In function 'get_token':
+ gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits]
+ 900 | if (ch == EOF || len > MAX_TOKEN_SZ)
+ | ^~
+
+ Change its type to int, like in the other similar code.
+
+ There is also:
+
+ gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+ 735 | dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]);
+ | ~~~~~~~~~~~^~~~~~~~~~
+
+ -Wmaybe-uninitialized doesn't seem to understand the FSM; just
+ initialize bpf_endianness to silence it. Add an assertion to
+ build_bpf_endianness() in order to catch potential bugs.
+
+2023-05-04 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: revert "default r6 if vendor is img"
+ In commit: 9171de358f230b64646bbb525a74e5f8e3dbe0dc,
+ The default output is set to r6 if the vendor is img,
+ It is ugly and should not be in upstream.
+
+ Let's revert it.
+
+2023-05-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix frame_list position in frame.c
+ In commit 995a34b1772 ("Guard against frame.c destructors running before
+ frame-info.c's") the following problem was addressed.
+
+ The frame_info_ptr destructor:
+ ...
+ ~frame_info_ptr ()
+ {
+ frame_list.erase (frame_list.iterator_to (*this));
+ }
+ ...
+ uses frame_list, which is a static member of class frame_info_ptr,
+ instantiated in frame-info.c:
+ ...
+ intrusive_list<frame_info_ptr> frame_info_ptr::frame_list;
+ ...
+
+ Then there's a static frame_info_pointer variable named selected_frame in
+ frame.c:
+ ...
+ static frame_info_ptr selected_frame;
+ ...
+
+ Because the destructor of selected_frame uses frame_list, its destructor needs
+ to be called before the destructor of frame_list.
+
+ But because they're in different compilation units, the initialization order and
+ consequently destruction order is not guarantueed.
+
+ The commit fixed this by handling the case that the destructor of frame_list
+ is called first, adding a check on is_linked ():
+ ...
+ ~frame_info_ptr ()
+ {
+ - frame_list.erase (frame_list.iterator_to (*this));
+ + /* If this node has static storage, it may be deleted after
+ + frame_list. Attempting to erase ourselves would then trigger
+ + internal errors, so make sure we are still linked first. */
+ + if (is_linked ())
+ + frame_list.erase (frame_list.iterator_to (*this));
+ }
+ ...
+
+ However, since then frame_list has been moved into frame.c, and
+ initialization/destruction order is guarantueed inside a compilation unit.
+
+ Revert aforementioned commit, and fix the destruction order problem by moving
+ frame_list before selected_frame.
+
+ Reverting the commit is another way of fixing the already fixed
+ Wdangling-pointer warning reported in PR build/30413, in a different way than
+ commit 9b0ccb1ebae ("Pass const frame_info_ptr reference for
+ skip_[language_]trampoline").
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Tested on x86_64-linux.
+ PR build/30413
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413
+
+2023-05-03 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/show_args_command: print to the ui_file argument
+ The show_args_command uses gdb_printf without specifying the ui_file.
+ This means that it prints to gdb_stdout instead of the stream given as
+ an argument to the function.
+
+ This commit fixes this.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-05-03 Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
+
+ Make ar faster
+ * archive.c (_bfd_write_archive_contents): Use a larger buffer in order to improve efficiency.
+
+2023-05-03 Mark Wielaard <mark@klomp.org>
+
+ Pass const frame_info_ptr reference for skip_[language_]trampoline
+ g++ 13.1.1 produces a -Werror=dangling-pointer=
+
+ In file included from ../../binutils-gdb/gdb/frame.h:75,
+ from ../../binutils-gdb/gdb/symtab.h:40,
+ from ../../binutils-gdb/gdb/language.c:33:
+ In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’,
+ inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24,
+ inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26,
+ inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49:
+ gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=]
+ 415 | m_back = &elem;
+ | ~~~~~~~^~~~~~~
+ gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’:
+ gdb/language.c:530:49: note: ‘<anonymous>’ declared here
+ 530 | CORE_ADDR real_pc = lang->skip_trampoline (frame, pc);
+ | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
+ gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here
+ 359 | static intrusive_list<frame_info_ptr> frame_list;
+ | ^~~~~~~~~~
+
+ Each new frame_info_ptr is being pushed on a static frame list and g++
+ cannot see why that is safe in case the frame_info_ptr is created and
+ destroyed immediately when passed as value.
+
+ It isn't clear why only in this one place g++ sees the issue (probably
+ because it can inline enough code in this specific case).
+
+ Since passing the frame_info_ptr as const reference is cheaper, use
+ that as workaround for this warning.
+
+ PR build/30413
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413
+
+ Tested-by: Kevin Buettner <kevinb@redhat.com>
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+ Reviewed-by: Tom Tromey <tom@tromey.com>
+
+2023-05-03 Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
+
+ Improve the speed of computing checksums for COFF binaries.
+ * coffcode.h (coff_read_word_from_buffer): New function.
+ * coffcode.h (COFF_CHECKSUM_BUFFER_SIZE): New constant.
+ * coffcode.h (coff_compute_checksum): Improve speed by reducing the number of seeks and reads used.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ Remove unused args from bfd_make_debug_symbol
+ The ptr and size args are unused. Make the function look the same as
+ bfd_make_empty_symbol.
+
+ Generated docs and include files
+ bfd/doc/chew.c extracts documentation from source code comments
+ annotated with keywords, and generates much of bfd.h and libbfd.h from
+ those same comments. The docs have suffered from people (me too)
+ adding things like CODE_FRAGMENT to the source to put code into bfd.h
+ without realising that CODE_FRAGMENT also puts @example around said
+ code into the docs. So we have random senseless things in the docs.
+ This patch fixes that problem (well, the senseless things from
+ CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
+ few chew.c features. libbfd.h now automatically gets ATTRIBUTE_HIDDEN
+ prototypes, and indentation in bfd.h and libbfd.h is better.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ Move bfd_alloc, bfd_zalloc and bfd_release to libbfd.c
+ These functions don't belong in opncls.c.
+
+ * libbfd-in.h (bfd_release): Delete prototype.
+ * opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to..
+ * libbfd.c: ..here. Include objalloc.c and provide bfd_release
+ with a FUNCTION comment.
+ * bfd-in2.h: Regenerate.
+ * libbfd.h: Regenerate.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ Move bfd_elf_bfd_from_remote_memory to opncls.c
+ bfd_elf_bfd_from_remote_memory is just a wrapper, and the function
+ could be implemented for other formats. Move it to opncls.c because
+ it acts a little like some of the other bfd_open* routines. Also give
+ it the usual FUNCTION etc. comment so prototypes and docs are handled
+ automatically.
+
+ * elf.c (bfd_elf_bfd_from_remote_memory): Move to..
+ * opncls.c: ..here, add FUNCTION comment.
+ * bfd-in.h (bfd_elf_bfd_from_remote_memory): Delete prototype.
+ * bfd-in2.h: Regenerate.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ hash.c: replace some unsigned long with unsigned int
+ * hash.c (higher_prime_number): Use uint32_t param, return value,
+ tables and variables.
+ (bfd_default_hash_table_size): Make it an unsigned int.
+ (bfd_hash_set_default_size): Use unsigned int param and return.
+ * bfd-in.h (bfd_hash_set_default_size): Update prototype.
+ * bfd-in2.h: Regenerate.
+
+ libbfc.c: Use stdint types for unsigned char and unsigned long
+ * libbfd.c (bfd_put_8): Use bfd_byte rather than unsigned char.
+ (bfd_get_8, bfd_get_signed_8): Likewise.
+ (_bfd_read_unsigned_leb128, _bfd_safe_read_leb128): Likewise.
+ (_bfd_read_signed_leb128): Likewise.
+ (bfd_getb24, bfd_getl24): Replace unsigned long with uint32_t.
+ (bfd_getb32, bfd_getl32): Likewise.
+ (bfd_getb_signed_32, bfd_getl_signed_32): Likewise.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ Change signature of bfd crc functions
+ The crc calculated is 32 bits. Replace uses of unsigned long with
+ uint32_t. Also use bfd_byte* for buffers.
+
+ bfd/
+ * opncls.c (bfd_calc_gnu_debuglink_crc32): Use stdint types.
+ (bfd_get_debug_link_info_1, bfd_get_debug_link_info): Likewise.
+ (separate_debug_file_exists, bfd_follow_gnu_debuglink): Likewise.
+ (bfd_fill_in_gnu_debuglink_section): Likewise.
+ * bfd-in2.h: Regenerate.
+ gdb/
+ * auto-load.c (auto_load_objfile_script): Update type of
+ bfd_get_debug_link_info argument.
+ * symfile.c (find_separate_debug_file_by_debuglink): Likewise.
+ * gdb_bfd.c (get_file_crc): Update type of
+ bfd_calc_gnu_debuglink_crc32 argument.
+
+2023-05-03 Alan Modra <amodra@gmail.com>
+
+ _bfd_mips_elf_lo16_reloc vallo comment
+ This explains exactly why the high reloc adjustment is as it is,
+ replacing the rather nebulous existing comment. I've also changed the
+ expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better
+ matches part of the standard 16-bit sign extension (resulting in
+ exactly the same value), and hoisted the calculation out of the loop.
+
+ * elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo
+ comment. Hoist calculation out of loop.
+
+2023-05-02 Alexandra Hájková <ahajkova@redhat.com>
+
+ gdb.base/watchpoint-unaligned.exp: Always initialize wpoffset_to_wpnum
+ Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types.
+
+ ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
+ ERROR: can't read "wpoffset_to_wpnum(1)": no such element in array
+ ERROR: tcl error code TCL READ VARNAME
+ ERROR: tcl error info:
+ can't read "wpoffset_to_wpnum(1)": no such element in array
+ while executing
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340
+
+ Reviewed-by: Luis Machado <luis.machado@arm.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-05-02 Mark Wielaard <mark@klomp.org>
+
+ xcoffread.c: Fix -Werror=dangling-pointer= issue with main_subfile.
+ GCC 13 points out that main_subfile has local function scope, but a
+ pointer to it is assigned to the global inclTable array subfile
+ element field:
+
+ In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
+ inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
+ inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
+ xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
+ 629 | inclTable[ii].subfile = &main_subfile;
+ | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
+ xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
+ xcoffread.c:579:18: note: ‘main_subfile’ declared here
+ 579 | struct subfile main_subfile;
+ | ^~~~~~~~~~~~
+ xcoffread.c:496:19: note: ‘inclTable’ declared here
+ 496 | static InclTable *inclTable; /* global include table */
+ | ^~~~~~~~~
+
+ Fix this by making main_subfile file static. And allocate and
+ deallocated together with inclTable in allocate_include_entry and
+ xcoff_symfile_finish. Adjust the use of main_subfile in
+ process_linenos to take a pointer to the subfile.
+
+2023-05-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use set in lmap in gdb.dwarf2/dw2-abs-hi-pc.exp
+ In gdb.dwarf2/dw2-abs-hi-pc.exp we do:
+ ...
+ set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
+ ...
+
+ The use of expr is not idiomatic. Fix this by using set instead:
+ ...
+ set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }]
+ ...
+
+ Reported-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andreas Schwab <schwab@suse.de>
+
+2023-05-02 Aditya Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix Assertion pid != 0 failure in AIX.
+ In AIX if there is a main and a thread created from it , then once the
+ program completed execution and goes to pd_disable () inferior_ptid
+ had pid 0 leading to an assertion failure while finding the thread's data
+ in aix-thread.c file.
+
+ This patch is a fix for the same.
+
+2023-05-02 Tom Tromey <tom@tromey.com>
+
+ Remove error_stream
+ error_stream is trivial and only used in a couple of spots in
+ breakpoint.c. This patch removes it in favor of just writing it out
+ at the spots where it was used.
+
+2023-05-02 Nick Clifton <nickc@redhat.com>
+
+ Remove Dimity Diky as MSP430 maintainer.
+
+2023-05-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: compile gdb.linespec/cp-completion-aliases.exp as C++
+ Noticed in passing that the prepare_for_testing call in
+ gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag,
+ despite this being a C++ test.
+
+ I guess, as the source file has the '.cc' extension, all the compilers
+ are doing the right thing anyway -- the source file uses templates, so
+ is definitely being compiled as C++.
+
+ I noticed this when I tried to set CXX_FOR_TARGET (but not
+ CC_FOR_TARGET) and spotted that this script was still using the C
+ compiler.
+
+ Fixed in this commit by adding the 'c++' flag for prepare_for_testing.
+
+2023-05-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-05-01 Tom Tromey <tromey@adacore.com>
+
+ Document DAP 'launch' parameter
+ The Debugger Adapter Protocol defines a "launch" request but leaves
+ the parameters up to the implementation:
+
+ Since launching is debugger/runtime specific, the arguments for
+ this request are not part of this specification.
+
+ This patch adds some documentation for the parameter GDB currently
+ defines. Note that I plan to add more parameters here, and perhaps
+ there will be other extensions in time as well.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-05-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove ui_interp_info
+ I don't think that having struct ui_interp_info separated from struct ui
+ is very useful. As of today, it looks like an unnecessary indirection
+ layer. Move the contents of ui_interp_info directly into struct ui, and
+ update all users.
+
+ Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521
+
+2023-05-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: store interps in an intrusive_list
+ Use intrusive_list, instead of hand-made linked list.
+
+ Change-Id: Idc857b40dfa3e3c35671045898331cca2c928097
+
+2023-05-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move struct ui and related things to ui.{c,h}
+ I'd like to move some things so they become methods on struct ui. But
+ first, I think that struct ui and the related things are big enough to
+ deserve their own file, instead of being scattered through top.{c,h} and
+ event-top.c.
+
+ Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
+
+2023-05-01 Tom Tromey <tromey@adacore.com>
+
+ Turn set_inferior_args_vector into method of inferior
+ This patch turns set_inferior_args_vector into an overload of
+ inferior::set_args.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-05-01 Tom Tromey <tromey@adacore.com>
+
+ Remove evaluate_type
+ Like evaluate_expression, evaluate_type is also just a simple wrapper.
+ Removing it makes the code a little nicer.
+
+ Remove evaluate_expression
+ evaluate_expression is just a little wrapper for a method on
+ expression. Removing it also removes a lot of ugly (IMO) calls to
+ get().
+
+ Remove op_name
+ op_name is only needed in a single place, so remove it and inline it
+ there.
+
+2023-05-01 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in Rust expression parser
+ A user found that an array expression with just a single value (like
+ "[23]") caused the Rust expression parser to crash.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30410
+
+2023-05-01 Tom Tromey <tom@tromey.com>
+
+ Replace field_is_static with a method
+ This changes field_is_static to be a method on struct field, and
+ updates all the callers. Most of this patch was written by script.
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-05-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix TUI resizing for TERM=ansi
+ With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
+ (maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
+ fix) and a message:
+ ...
+ @@ resize done 0, size = 77x20
+ ...
+ with the resulting width being 77 instead of the expected 78.
+
+ [ The discrepancy also manifests in CLI, filed as PR30346. ]
+
+ The discrepancy comes from tui_resize_all, where we ask readline for the
+ screen size:
+ ...
+ rl_get_screen_size (&screenheight, &screenwidth);
+ ...
+
+ As it happens, when TERM is set to ansi, readline decides that the terminal
+ cannot auto-wrap lines, and reserves one column to deal with that, and as a
+ result reports back one less than the actual screen width:
+ ...
+ $ echo $COLUMNS
+ 78
+ $ TERM=xterm gdb -ex "show width" -ex q
+ Number of characters gdb thinks are in a line is 78.
+ $ TERM=ansi gdb -ex "show width" -ex q
+ Number of characters gdb thinks are in a line is 77.
+ ...
+
+ In tui_resize_all, we need the actual screen width, and using a screenwidth of
+ one less than the actual value garbles the screen.
+
+ This is currently not causing trouble in testing because we have a workaround
+ in place in proc Term::resize. If we disable the workaround:
+ ...
+ - stty columns [expr {$_cols + 1}] < $::gdb_tty_name
+ + stty columns $_cols < $::gdb_tty_name
+ ...
+ and dump the screen we get the same type of screen garbling:
+ ...
+ 0 +---------------------------------------+|
+ 1 ||
+ 2 ||
+ 3 ||
+ ...
+
+ Another way to reproduce the problem is using command "maint info screen".
+ After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
+ get:
+ ...
+ Number of characters curses thinks are in a line is 78.
+ ...
+ and after maximizing and demaximizing the window we get:
+ ...
+ Number of characters curses thinks are in a line is 77.
+ ...
+ If we use TERM=xterm, we do get the expected 78.
+
+ Fix this by:
+ - detecting when readline will report back less than the actual screen width,
+ - accordingly setting a new variable readline_hidden_cols,
+ - using readline_hidden_cols in tui_resize_all to fix the resize problem, and
+ - removing the workaround in Term::resize.
+
+ The test-case gdb.tui/empty.exp serves as regression test.
+
+ I've applied the same fix in tui_async_resize_screen, the new test-case
+ gdb.tui/resize-2.exp serves as a regression test for that change. Without
+ that fix, we have:
+ ...
+ FAIL: gdb.tui/resize-2.exp: again: gdb width 80
+ ...
+
+ Tested on x86_64-linux.
+
+ PR tui/30337
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337
+
+2023-04-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/readline.exp with stub-termcap
+ When doing a build which uses stub-termcap, we run into:
+ ...
+ (gdb) set width 7
+ <b) FAIL: gdb.base/readline.exp: set width 7 (timeout)
+ ...
+
+ Since readline can't detect very basic terminal support, it falls back on
+ horizontal scrolling.
+
+ Fix this by detecting the horizontal scrolling case, and skipping the
+ subsequent test.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30400
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400
+
+2023-04-29 Manoj Gupta <manojgupta@google.com>
+
+ gdb: Fix building with latest libc++
+ Latest libc++[1] causes transitive include to <locale> when
+ <mutex> or <thread> header is included. This causes
+ gdb to not build[2] since <locale> defines isupper/islower etc.
+ functions that are explicitly macroed-out in safe-ctype.h to
+ prevent their use.
+ Use the suggestion from libc++ to include <locale> internally when
+ building in C++ mode to avoid build errors.
+ Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
+ to keep this isolated to gdb since rest of binutils
+ does not seem to use much C++.
+
+ [1]: https://reviews.llvm.org/D144331
+ [2]: https://issuetracker.google.com/issues/277967395
+
+2023-04-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/excep_handle.exp for updated gdb_test
+ Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9
+ ("gdb/testsuite: change newline patterns used in gdb_test"):
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
+ 26 when Constraint_Error =>^M
+ (gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
+ exception handlers
+ ...
+
+ The output is supposed to be matched by:
+ ...
+ gdb_test "continue" \
+ "Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
+ "continuing to first Constraint_Error exception handlers"
+ ...
+ but the $eol bit no longer matches due to the stricter matching introduced
+ in aforementioned commit.
+
+ Fix this by dropping the "$eol.*" bit.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30399
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399
+
+2023-04-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build without ncurses in maintenance_info_screen
+ With a build without ncurses we run into:
+ ...
+ src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’:
+ src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope
+ COLS);
+ ^~~~
+ src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope
+ LINES);
+ ^~~~~
+ ...
+
+ Fix this by using HAVE_LIBCURSES.
+
+ Tested on x86_64-linux.
+
+ PR build/30391
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30391
+
+2023-04-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/main.exp without TUI
+ With a build with --disable-tui, we get:
+ ...
+ (gdb) PASS: gdb.tui/main.exp: set interactive-mode off
+ maint set tui-left-margin-verbose on^M
+ Undefined maintenance set command: "tui-left-margin-verbose on". \
+ Try "help maintenance set".^M
+ (gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on
+ ...
+
+ Fix this by adding the missing "require allow_tui_tests".
+
+ Tested on x86_64-linux.
+
+2023-04-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: check thread exists when creating thread-specific b/p
+ I noticed the following behaviour:
+
+ $ gdb -q -i=mi /tmp/hello.x
+ =thread-group-added,id="i1"
+ =cmd-param-changed,param="print pretty",value="on"
+ ~"Reading symbols from /tmp/hello.x...\n"
+ (gdb)
+ -break-insert -p 99 main
+ ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
+ (gdb)
+ info breakpoints
+ &"info breakpoints\n"
+ ~"Num Type Disp Enb Address What\n"
+ ~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n"
+ &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
+ &"\n"
+ &"----- Backtrace -----\n"
+ &"Backtrace unavailable\n"
+ &"---------------------\n"
+ &"\nThis is a bug, please report it."
+ &" For instructions, see:\n"
+ &"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
+ Aborted (core dumped)
+
+ What we see here is that when using the MI a user can create
+ thread-specific breakpoints for non-existent threads. Then if we try
+ to use the CLI 'info breakpoints' command GDB throws an assertion.
+ The assert is a result of the print_thread_id call when trying to
+ build the 'stop only in thread xx.yy' line; print_thread_id requires a
+ valid thread_info pointer, which we can't have for a non-existent
+ thread.
+
+ In contrast, when using the CLI we see this behaviour:
+
+ $ gdb -q /tmp/hello.x
+ Reading symbols from /tmp/hello.x...
+ (gdb) break main thread 99
+ Unknown thread 99.
+ (gdb)
+
+ The CLI doesn't allow a breakpoint to be created for a non-existent
+ thread. So the 'info breakpoints' command is always fine.
+
+ Interestingly, the MI -break-info command doesn't crash, this is
+ because the MI uses global thread-ids, and so never calls
+ print_thread_id. However, GDB does support using CLI and MI in
+ parallel, so we need to solve this problem.
+
+ One option would be to change the CLI behaviour to allow printing
+ breakpoints for non-existent threads. This would preserve the current
+ MI behaviour.
+
+ The other option is to pull the MI into line with the CLI and prevent
+ breakpoints being created for non-existent threads. This is good for
+ consistency, but is a breaking change for the MI.
+
+ In the end I figured that it was probably better to retain the
+ consistent CLI behaviour, and just made the MI reject requests to
+ place a breakpoint on a non-existent thread. The only test we had
+ that depended on the old behaviour was
+ gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit:
+
+ commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c
+ Date: Fri Feb 17 10:48:06 2023 +0000
+
+ gdb: don't duplicate 'thread' field in MI breakpoint output
+
+ I certainly didn't intend for this test to rely on this feature of the
+ MI, so I propose to update this test to only create breakpoints for
+ threads that exist.
+
+ Actually, I've added a new test that checks the MI rejects creating a
+ breakpoint for a non-existent thread, and I've also extended the test
+ to run with the separate MI/CLI UIs, and then tested 'info
+ breakpoints' to ensure this command doesn't crash.
+
+ I've extended the documentation of the `-p` flag to explain the
+ constraints better.
+
+ I have also added a NEWS entry just in case someone runs into this
+ issue, at least then they'll know this change in behaviour was
+ intentional.
+
+ One thing that I did wonder about while writing this patch, is whether
+ we should treat requests like this, on both the MI and CLI, as another
+ form of pending breakpoint, something like:
+
+ (gdb) break foo thread 9
+ Thread 9 does not exist.
+ Make breakpoint pending on future thread creation? (y or [n]) y
+ Breakpoint 1 (foo thread 9) pending.
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 1 breakpoint keep y <PENDING> foo thread 9
+
+ Don't know if folk think that would be a useful idea or not? Either
+ way, I think that would be a separate patch from this one.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make deprecated_show_value_hack static
+ The deprecated_show_value_hack function is now only used inside
+ cli-setshow.c, so lets make the function static to discourage its use
+ anywhere else.
+
+ There should be no user visible changes after this commit
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make set/show inferior-tty work with $_gdb_setting_str
+ Like the previous two commits, this commit fixes set/show inferior-tty
+ to work with $_gdb_setting_str.
+
+ Instead of using a scratch variable which is then pushed into the
+ current inferior from a set callback, move to the API that allows for
+ getters and setters, and store the value directly within the current
+ inferior.
+
+ Update an existing test to check the inferior-tty setting.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make set/show cwd work with $_gdb_setting_str
+ The previous commit fixed set/show args when used with
+ $_gdb_setting_str, this commit fixes set/show cwd.
+
+ Instead of using a scratch variable which is then pushed into the
+ current inferior from a set callback, move to the API that allows for
+ getters and setters, and store the value directly within the current
+ inferior.
+
+ Update the existing test to check the cwd setting.
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make set/show args work with $_gdb_setting_str
+ I noticed that $_gdb_setting_str was not working with 'args', e.g.:
+
+ $ gdb -q --args /tmp/hello.x arg1 arg2 arg3
+ Reading symbols from /tmp/hello.x...
+ (gdb) show args
+ Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
+ (gdb) print $_gdb_setting_str("args")
+ $1 = ""
+
+ This is because the 'args' setting is implemented using a scratch
+ variable ('inferior_args_scratch') which is updated when the user does
+ 'set args ...'. There is then a function 'set_args_command' which is
+ responsible for copying the scratch area into the current inferior.
+
+ However, when the user sets the arguments via the command line the
+ scratch variable is not updated, instead the arguments are pushed
+ straight into the current inferior.
+
+ There is a second problem, when the current inferior changes the
+ scratch area is not updated, which means that the value returned will
+ only ever reflect the last call to 'set args ...' regardless of which
+ inferior is currently selected.
+
+ Luckily, the fix is pretty easy, set/show variables have an
+ alternative API which requires we provide some getter and setter
+ functions. With this done the scratch variable can be removed and the
+ value returned will now always reflect the current inferior.
+
+ While working on set/show args I also rewrote show_args_command to
+ remove the use of deprecated_show_value_hack.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: cleanup command creation in infcmd.c
+ In infcmd.c, in order to add command completion to some of the 'set'
+ commands, we are currently creating the command, then looking up the
+ command by calling lookup_cmd.
+
+ This is no longer necessary, we already return the relevant
+ cmd_list_element object when the set/show command is created, and we
+ can use that to set the command completion callback.
+
+ I don't know if there's actually any tests for completion of these
+ commands, but I manually checked, and each command still appears to
+ offer the expected filename completion.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/record-full: disable range stepping when resuming threads
+ I see these failures, when running with the native-gdbserver of
+ native-extended-gdbserver boards:
+
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
+ FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
+ FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
+ FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
+ FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body
+
+ Let's use this simpler program to illustrate the problem:
+
+ int main()
+ {
+ int a = 362;
+ a = a * 17;
+ return a;
+ }
+
+ It compiles down to:
+
+ int a = 362;
+ 401689: c7 45 fc 6a 01 00 00 movl $0x16a,-0x4(%rbp)
+ a = a * 17;
+ 401690: 8b 55 fc mov -0x4(%rbp),%edx
+ 401693: 89 d0 mov %edx,%eax
+ 401695: c1 e0 04 shl $0x4,%eax
+ 401698: 01 d0 add %edx,%eax
+ 40169a: 89 45 fc mov %eax,-0x4(%rbp)
+ return a;
+ 40169d: 8b 45 fc mov -0x4(%rbp),%eax
+
+ When single stepping these lines, debugging locally, while recording,
+ these are the recorded instructions (basically one for each instruction
+ shown above):
+
+ (gdb) maintenance print record-instruction 0
+ 4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00
+ Register rip changed: (void (*)()) 0x40169a <main+21>
+ (gdb) maintenance print record-instruction -1
+ Register rax changed: 5792
+ Register eflags changed: [ PF AF IF ]
+ Register rip changed: (void (*)()) 0x401698 <main+19>
+ (gdb) maintenance print record-instruction -2
+ Register rax changed: 362
+ Register eflags changed: [ PF ZF IF ]
+ Register rip changed: (void (*)()) 0x401695 <main+16>
+ (gdb) maintenance print record-instruction -3
+ Register rax changed: 4200069
+ Register rip changed: (void (*)()) 0x401693 <main+14>
+ (gdb) maintenance print record-instruction -4
+ Register rdx changed: 140737488346696
+ Register rip changed: (void (*)()) 0x401690 <main+11>
+ (gdb) maintenance print record-instruction -5
+ 4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00
+ Register rip changed: (void (*)()) 0x401689 <main+4>
+ (gdb) maintenance print record-instruction -6
+ Not enough recorded history
+
+ But when debugging remotely:
+
+ (gdb) maintenance print record-instruction 0
+ Register rdx changed: 140737488346728
+ Register rip changed: (void (*)()) 0x401690 <main+11>
+ (gdb) maintenance print record-instruction -1
+ 4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
+ Register rip changed: (void (*)()) 0x401689 <main+4>
+ (gdb) maintenance print record-instruction -2
+ Not enough recorded history
+
+ In this list, we only have entries for the beginning of each line. This
+ is because of the remote target's support for range stepping. The
+ record-full layer can only record instructions when the underlying
+ process target reports a stop. With range stepping, the remote target
+ single-steps multiple instructions at a time, so the record-full target
+ doesn't get to see and record them all.
+
+ Fix this by making the record-full layer disable range-stepping
+ before handing the resume request to the beneath layer, forcing the
+ remote target to report stops for each instruction.
+
+ Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d
+
+2023-04-28 Keith Seitz <keiths@redhat.com>
+
+ Allow strings with printf/eval
+ PR 13098 explains that if a user attempts to use a string with either
+ `printf' (or `eval'), gdb returns an error (inferior not running):
+
+ (gdb) printf "%s\n", "hello"
+ evaluation of this expression requires the target program to be active
+
+ However, the parser can certainly handle this case:
+
+ (gdb) p "hello"
+ $1 = "hello"
+
+ This discrepancy occurs because printf_c_string does not handle
+ this specific case. The passed-in value that we are attempting to print
+ as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.
+
+ printf_c_string will only attempt to print a string from the value's
+ contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
+ type is considered a string type:
+
+ if (value->type ()->code () != TYPE_CODE_PTR
+ && value->lval () == lval_internalvar
+ && c_is_string_type_p (value->type ()))
+ {
+ ...
+ }
+
+ Otherwise, it attempts to read the value of the string from the target's
+ memory (which is what actually generates the "evaluation of this ..."
+ error message).
+
+2023-04-28 Tom Tromey <tromey@adacore.com>
+
+ Move find_minimal_symbol_address to minsyms.c
+ I found find_minimal_symbol_address in parse.c, but it seems to me
+ that it belongs in minsyms.c.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-04-28 Tom Tromey <tromey@adacore.com>
+
+ Do not change type in get_discrete_low_bound
+ get_discrete_low_bound has this code:
+
+ /* Set unsigned indicator if warranted. */
+ if (low >= 0)
+ type->set_is_unsigned (true);
+
+ It's bad to modify a type in a getter like this, so this patch removes
+ this code. FWIW I looked and this code has been there since at least
+ 1999 (it was in the initial sourceware import).
+
+ Types in general would benefit from const-ification, which would
+ probably reveal more code like this, but I haven't attempted that.
+
+ Regression tested on x86-64 Fedora 36.
+
+ Reviewed-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-04-28 Tom Tromey <tromey@adacore.com>
+
+ Remove @var from @defun in Python documentation
+ Eli pointed out that @var isn't needed in @defun in Texinfo. This
+ patch removes the cases I found in python.texi. I also renamed some
+ variables in one spot, because "-" isn't valid in a Python variable
+ name.
+
+2023-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: additional test fixes after gdb_test changes
+ After this commit:
+
+ commit e2f620135d92f7cd670af4e524fffec7ac307666
+ Date: Thu Mar 30 13:26:25 2023 +0100
+
+ gdb/testsuite: change newline patterns used in gdb_test
+
+ There were some regressions in gdb.trace/*.exp tests when run with the
+ native-gdbserver board. This commit fixes these regressions.
+
+ All the problems are caused by unnecessary trailing newline characters
+ included in the patterns passed to gdb_test. After the above commit
+ the testsuite is stricter when matching trailing newlines, and so the
+ additional trailing newline characters are now causing the test to
+ fail. Fix by removing all the excess trailing newline characters.
+
+ In some cases this cleanup means we should use gdb_test_no_output,
+ I've done that where appropriate. In a couple of other places I've
+ made use of multi_line to better build the expected output pattern.
+
+2023-04-28 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Use run_cc_link_tests for PR ld/26391 tests
+ Use run_cc_link_tests for PR ld/26391 tests to compile PR ld/26391 tests
+ in C.
+
+ PR ld/30002
+ * testsuite/ld-elf/elf.exp: Use run_cc_link_tests for PR ld/26391
+ tests.
+
+2023-04-28 Eli Zaretskii <eliz@gnu.org>
+
+ Fix a typo in gdb.texinfo.
+
+2023-04-28 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Enable x0 base relaxation for relax_pc even if --no-relax-gp.
+ Let --no-relax-gp only disable the gp relaxation for lui and pcrel
+ relaxations, since x0 base and gp relaxations are different optimizations
+ in fact, but just use the same function to handle.
+
+ bfd/
+ * elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui,
+ set gp to zero when --no-relax-gp, then we should still keep the
+ x0 base relaxation.
+ (_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when
+ --no-relax-gp, we will disable the gp relaxation in the
+ _bfd_riscv_relax_pc.
+
+2023-04-28 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Relax R_RISCV_[PCREL_]LO12_I/S to R_RISCV_GPREL_I/S for undefined weak.
+ bfd/
+ *elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol,
+ just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't
+ update the rs1 to zero until relocate_section.
+ (_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S.
+
+2023-04-28 Jan Beulich <jbeulich@suse.com>
+
+ x86: limit data passed to i386_dis_printf()
+ The function doesn't use "ins" for other than retrieving "info". Remove
+ a thus pointless level of indirection.
+
+ x86: limit data passed to prefix_name()
+ Make apparent that neither what "ins" points to nor, in particular, that
+ "ins->info->private_data" is actually used in the function.
+
+ x86/Intel: reduce ELF/PE conditional scope in x86_cons()
+ All the Intel syntax related state adjustments apply independent of
+ target or object format.
+
+ gas: move shift count check
+ ... out of mainline code, grouping together the two case labels. This
+ then also make more obvious that the comment there applies to both forms
+ of shifts.
+
+ x86: rework AMX control insn disassembly
+ Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth,
+ and only then prefix, resulting in fewer table entries. Note that in the
+ course of the re-work
+ - TILEZERO has a previously missing decode step through rm_table[]
+ added,
+ - a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an
+ infix).
+
+2023-04-28 Jan Beulich <jbeulich@suse.com>
+
+ x86: rework AMX multiplication insn disassembly
+ Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
+ and prefix last, resulting in fewer table entries. Note that in the
+ course of the re-work wrong M_0 suffixes are also corrected to be M_1
+ (partly infixes now).
+
+ Since it ended up confusing while testing the change, also adjust the
+ test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).
+
+2023-04-28 Alan Modra <amodra@gmail.com>
+
+ Re: Keeping track of rs6000-coff archive element pointers
+ Commit de7b90610e9e left a hole in the element checking, explained by
+ the comment added to _bfd_xcoff_openr_next_archived_file. While
+ fixing this, tidy some types used to hold unsigned values so that
+ casts are not needed to avoid signed/unsigned comparison warnings.
+ Also tidy a few things in xcoff.h.
+
+ bfd/
+ * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check
+ that we aren't pointing back at the last element. Make
+ filestart a ufile_ptr. Update for xcoff_artdata change.
+ (_bfd_strntol, _bfd_strntoll): Return unsigned values.
+ (_bfd_xcoff_slurp_armap): Make off a ufile_ptr.
+ (add_ranges): Update for xcoff_artdata change.
+ * libbfd-in.h (struct artdata): Make first_file_filepos a
+ ufile_ptr.
+ * libbfd.h: Regenerate.
+ include/
+ * coff/xcoff.h (struct xcoff_artdata): Replace min_elt with
+ ar_hdr_size.
+ (xcoff_big_format_p): In the !SMALL_ARCHIVE case return true
+ for anything but a small archive.
+
+2023-04-28 Alan Modra <amodra@gmail.com>
+
+ Remove deprecated bfd_read
+ 20+ years is long enough to warn.
+
+ * bfd-in.h (bfd_read, bfd_write): Don't define
+ (_bfd_warn_deprecated): Don't declare.
+ * bfd-in2.h: Regenerate.
+ * libbfd.c (_bfd_warn_deprecated): Delete.
+
+2023-04-28 Alan Modra <amodra@gmail.com>
+
+ Make bfd_byte an int8_t, flagword a uint32_t
+ * bfd-in.h (bfd_byte): Typedef as int8_t.
+ (flagword): Typedef as uint32_t.
+ (bfd_vma, bfd_signed_vma, bfd_size_type, symvalue): Use stdint
+ types in !BFD64 case.
+ * bfd-in2.h: Regenerate.
+
+2023-04-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-27 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: bpf: fix tests for pseudo-c syntax
+ This patch fixes the GAS BPF testsuite so the tests for pseudo-c
+ syntax are actually executed.
+
+ 2023-04-27 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * testsuite/gas/bpf/mem.dump: New file.
+ * testsuite/gas/bpf/mem-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/mem.d: #dump mem.dump.
+ * testsuite/gas/bpf/lddw.dump: New file.
+ * testsuite/gas/bpf/lddw-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/lddw.d: #dump lddw.dump.
+ * testsuite/gas/bpf/jump.dump: New file.
+ * testsuite/gas/bpf/jump-pseudoc.d: Likewise
+ * testsuite/gas/bpf/jump.d: #dump jump.dump.
+ * testsuite/gas/bpf/jump32.dump: New file.
+ * testsuite/gas/bpf/jump32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/jump32.d: #dump jump32.dump.
+ * testsuite/gas/bpf/lddw-be.dump: New file.
+ * testsuite/gas/bpf/lddw-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/lddw-be.d: #dump lddw-be.dump.
+ * testsuite/gas/bpf/indcall-1.dump: New file.
+ * testsuite/gas/bpf/indcall-1-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/indcall-1.d: #dump indcall-1.dump.
+ * testsuite/gas/bpf/indcall-1-pseudoc.s (main): Fix lddw
+ instruction.
+ * testsuite/gas/bpf/atomic.dump: New file.
+ * testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/atomic.d: #dump atomic.dump.
+ * testsuite/gas/bpf/alu32.dump: New file.
+ * testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu32.d: #dump alu32.dump.
+ * testsuite/gas/bpf/alu.dump: New file.
+ * testsuite/gas/bpf/alu-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu.d: #dump alu.dump.
+
+ * testsuite/gas/bpf/alu-be.dump: New file.
+ * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
+ * testsuite/gas/bpf/alu-be.d: #dump alu-be.dump.
+ * testsuite/gas/bpf/alu32-be-pseudoc.d: New file.
+ * testsuite/gas/bpf/alu32-be-dump: Likewise.
+ * testsuite/gas/bpf/alu32-be.d: #dump alu32-be-dump.
+ * testsuite/gas/bpf/bpf.exp: Run *-pseudoc tests.
+
+2023-04-27 Tom Tromey <tromey@adacore.com>
+
+ Avoid some compiler warnings in gdb.ada
+ Running gdb.ada/verylong.exp shows a warning from the Ada compiler:
+
+ prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default]
+
+ This patch fixes the problem, and another similar one in
+ unchecked_union.exp.
+
+2023-04-27 Michael Matz <matz@suse.de>
+
+ Fix PR30358, performance with --sort-section
+ since af31506c we only use the binary tree when section sorting is
+ required. While its unbalanced and hence can degrade to a linear list
+ it should otherwise have been equivalent to the old code relying on
+ insertion sort. Unfortunately it was not. The old code directly used
+ lang_add_section to populate the sorted list, the new code first
+ populates the tree and only then does lang_add_section on the sorted
+ result.
+
+ In the testcase we have very many linkonce section groups, and hence
+ lang_add_section won't actually insert anything for most of them. That
+ limited the to-be-sorted list length previously. The tree-sorting code
+ OTOH first created a tree of all candidates sections, including those
+ that wouldn't be inserted by lang_add_section, hence increasing the size
+ of the sorting problem. In the testcase the chain length went from
+ about 1500 to 106000, and in the degenerated case (as in the testcase)
+ that goes in quadratically.
+
+ This splits out most of the early-out code from lang_add_section to its
+ own function and uses the latter to avoid inserting into the tree. This
+ refactoring slightly changes the order of early-out tests (the ones
+ based on section flags is now done last, and only in lang_add_section).
+ The new function is not a pure predicate: it can give warnings and it
+ might change output_section, like the old early-out code did. I have
+ also added a skip-warning case in the first discard case, whose
+ non-existence seemed to have been an oversight.
+
+ PR 30358
+ * ldlang.c (wont_add_section_p): Split out from ...
+ (lang_add_section): ... here.
+ (output_section_callback_sort): Use wont_add_section_p to not
+ always add sections to the sort tree.
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: extend the documentation of the jump command
+ This commit addresses PR gdb/7946. While checking for bugs relating
+ to the jump command I noticed a long standing bug that points out a
+ deficiency with GDB's documentation of the jump command.
+
+ The bug points out that 'jump 0x...' is not always the same as 'set
+ $pc = 0x...' and then 'continue'. Writing directly to the $pc
+ register does not update any auxiliary state, e.g. $npc on SPARC,
+ while using 'jump' does.
+
+ It felt like this would be an easy issue to address by adding a
+ paragraph to the docs, so I took a stab at writing something suitable.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7946
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: special case '^' in gdb_test pattern
+ In this commit I propose that we add special handling for the '^' when
+ used at the start of a gdb_test pattern. Consider this usage:
+
+ gdb_test "some_command" "^command output pattern"
+
+ I think the intention here is pretty clear - run 'some_command', and
+ the output from the command should be exactly 'command output
+ pattern'.
+
+ After the previous commit which tightened up how gdb_test matches the
+ final newline and prompt we know that the only thing after the output
+ pattern will be a single newline and prompt, and the leading '^'
+ ensures that there's no output before 'command output pattern', so
+ this will do what I want, right?
+
+ ... except it doesn't. The command itself will also needs to be
+ matched, so I should really write:
+
+ gdb_test "some_command" "^some_command\r\ncommand output pattern"
+
+ which will do what I want, right? Well, that's fine until I change
+ the command and include some regexp character, then I have to write:
+
+ gdb_test "some_command" \
+ "^[string_to_regexp some_command]\r\ncommand output pattern"
+
+ but this all gets a bit verbose, so in most cases I simply don't
+ bother anchoring the output with a '^', and a quick scan of the
+ testsuite would indicate that most other folk don't both either.
+
+ What I propose is this: the *only* thing that can appear immediately
+ after the '^' is the command converted into a regexp, so lets do that
+ automatically, moving the work into gdb_test. Thus, when I write:
+
+ gdb_test "some_command" "^command output pattern"
+
+ Inside gdb_test we will spot the leading '^' in the pattern, and
+ inject the regexp version of the command after the '^', followed by a
+ '\r\n'.
+
+ My hope is that given this new ability, folk will be more inclined to
+ anchor their output patterns when this makes sense to do so. This
+ should increase our ability to catch any unexpected output from GDB
+ that appears as a result of running a particular command.
+
+ There is one problem case we need to consider, sometime people do
+ this:
+
+ gdb_test "" "^expected output pattern"
+
+ In this case no command is sent to GDB, but we are still expecting
+ some output from GDB. This might be a result of some asynchronous
+ event for example. As there is no command sent to GDB (from the
+ gdb_test) there will be no command text to parse.
+
+ In this case my proposed new feature injects the command regexp, which
+ is the empty string (as the command itself is empty), but still
+ injects the '\r\n' after the command regexp, thus we end up with this
+ pattern:
+
+ ^\r\nexpected output pattern
+
+ This extra '\r\n' is not what we should expected here, and so there is
+ a special case inside gdb_test -- if the command is empty then don't
+ add anything after the '^' character.
+
+ There are a bunch of tests that do already use '^' followed by the
+ command, and these can all be simplified in this commit.
+
+ I've tried to run all the tests that I can to check this commit, but I
+ am certain that there will be some tests that I manage to miss.
+ Apologies for any regressions this commit causes, hopefully fixing the
+ regressions will not be too hard.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: change newline patterns used in gdb_test
+ This commit makes two changes to how we match newline characters in
+ the gdb_test proc.
+
+ First, for the newline pattern between the command output and the
+ prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
+
+ The old pattern would spot multiple newlines, and so there are a few
+ places where, as part of this commit, I've needed to add an extra
+ trailing '\r\n' to the pattern in the main test file, where GDB's
+ output actually includes a blank line.
+
+ But I think this is a good thing. If a command produces a blank line
+ then we should be checking for it, the current gdb_test doesn't do
+ that. But also, with the current gdb_test, if a blank line suddenly
+ appears in the output, this is going to be silently ignored, and I
+ think this is wrong, the test should fail in that case.
+
+ Additionally, the existing pattern will happily match a partial
+ newline. There are a strangely large number of tests that end with a
+ random '.' character. Not matching a literal period, but matching any
+ single character, this is then matching half of the trailing newline
+ sequence, while the \[\r\n\]+ in gdb_test is matching the other half
+ of the sequence. I can think of no reason why this would be
+ intentional, I suspect that the expected output at one time included a
+ period, which has since been remove, but I haven't bothered to check
+ on this. In this commit I've removed all these unneeded trailing '.'
+ characters.
+
+ The basic rule of gdb_test after this is that the expected pattern
+ needs to match everything up to, but not including the newline
+ sequence immediately before the GDB prompt. This is generally how the
+ proc is used anyway, so in almost all cases, this commit represents no
+ significant change.
+
+ Second, while I was cleaning up newline matching in gdb_test, I've
+ also removed the '[\r\n]*' that was added to the start of the pattern
+ passed to gdb_test_multiple.
+
+ The addition of this pattern adds no value. If the user pattern
+ matches at the start of a line then this would match against the
+ newline sequence. But, due to the '*', if the user pattern doesn't
+ match at the start of a line then this group doesn't care, it'll
+ happily match nothing.
+
+ As such, there's no value to it, it just adds more complexity for no
+ gain, so I'm removing it. No tests will need updating as a
+ consequence of this part of the patch.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: use 'return' in gdb_test_no_output
+ A TCL proc will return the return value of the last command executed
+ within the proc's body if there is no explicit return call, so
+ gdb_test_no_output is already returning the return value of
+ gdb_test_multiple.
+
+ However, I'm not a fan of (relying on) this implicit return value
+ behaviour -- I prefer to be explicit about what we are doing. So in
+ this commit I have extended the comment on gdb_test_no_output to
+ document the possible return values (just as gdb_test does), and
+ explicitly call return.
+
+ This should make no different to our testing, but I think it's clearer
+ now what the gdb_test_no_output proc is expected to do.
+
+ The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the
+ return value of gdb_test_no_output, and continue to pass after this
+ change.
+
+ I also spotted that gdb.base/watchpoint.exp could be updated to make
+ use of gdb_test_no_output, so I did that.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove some trailing newlines from warning messages
+ While working on a later patch in this series, which tightens up some
+ of our pattern matching when using gdb_test, I ran into some failures
+ caused by some warnings having a trailing newline character.
+
+ The warning function already adds a trailing newline, and it is my
+ understanding that we should not be adding a second by including a
+ newline at the end of any warning message.
+
+ The problem cases I found were in language.c and remote.c, in this
+ patch I fix the cases I hit, but I also checked all the other warning
+ calls in these two files and removed any additional trailing newlines
+ I found.
+
+ In remote.c the warning actually had a newline character in the middle
+ of the warning message (in addition to the trailing newline), which
+ I've removed. I don't think it's helpful to forcibly split a warning
+ as was done here -- in the middle of a sentence. Additionally, the
+ message isn't even that long (71 characters), so I think removing this
+ newline is an improvement.
+
+ None of the expected test result need updating with this commit,
+ currently the patterns in gdb_test will match one or more newline
+ sequences, so the tests are as happy with one newline (after this
+ commit) as they are with two newlines (before this commit). A later
+ commit will change gdb_test so that it is not so forgiving, and these
+ warnings would have caused some failures.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp
+ I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
+ fail when run from a particular directory.
+
+ The test tries to find the number of the first internal breakpoint
+ using this proc:
+
+ proc get_first_maint_bp_num { } {
+ gdb_test_multiple "maint info break" "find first internal bp num" {
+ -re -wrap "(-\[0-9\]).*" {
+ return $expect_out(1,string)
+ }
+ }
+ return ""
+ }
+
+ The problem is, at the time we issue 'maint info break' there are both
+ internal breakpoint and non-internal (user created) breakpoints in
+ place. The user created breakpoints include the path to the source
+ file.
+
+ Sometimes, I'll be working from a directory that includes a number,
+ like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
+ matches the '-1' from 'blah-1'. In this case there's no significant
+ problem as it turns out that -1 is the number of the first internal
+ breakpoint.
+
+ Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
+ case the above pattern patches '-4' from 'blah-4'. It turns out this
+ is also not a problem -- the test doesn't actually need the first
+ internal breakpoint number, it just needs the number of any internal
+ breakpoint.
+
+ But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
+ which case the pattern above matches '-0' from 'blah-0', and in this
+ case the test fails - there is no internal breakpoint '-0'.
+
+ Fix this by spotting that the internal breakpoint numbers always
+ occurs after a '\r\n', and that they never start with a 0. Our
+ pattern becomes:
+
+ -re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
+ return $expect_out(1,string)
+ }
+
+ After this I'm no longer seeing any failures.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb, doc: add index entry for the $_inferior_thread_count convenience var
+ Add a marker in the documentation for indexing the $_inferior_thread_count
+ variable.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-04-27 Nick Clifton <nickc@redhat.com>
+
+ Add support for %x and %lx formats to the linker's vinfo() function.
+
+2023-04-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-26 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Support XVentanaCondOps extension
+ Ventana Micro has published the specification for their
+ XVentanaCondOps ("conditional ops") extension at
+ https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
+ which contains two new instructions
+ - vt.maskc
+ - vt.maskcn
+ that can be used in constructing branchless sequences for
+ various conditional-arithmetic, conditional-logical, and
+ conditional-select operations.
+
+ To support such vendor-defined instructions in the mainline binutils,
+ this change also adds a riscv_supported_vendor_x_ext secondary
+ dispatch table (but also keeps the behaviour of allowing any unknow
+ X-extension to be specified in addition to the known ones from this
+ table).
+
+ As discussed, this change already includes the planned/agreed future
+ requirements for X-extensions (which are likely to be captured in the
+ riscv-toolchain-conventions repository):
+ - a public specification document is available (see above) and is
+ referenced from the gas-documentation
+ - the naming follows chapter 27 of the RISC-V ISA specification
+ - instructions are prefixed by a vendor-prefix (vt for Ventana)
+ to ensure that they neither conflict with future standard
+ extensions nor clash with other vendors
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
+ (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
+
+ gas/ChangeLog:
+
+ * doc/c-riscv.texi: Add section to list custom extensions and
+ their documentation URLs.
+ * testsuite/gas/riscv/x-ventana-condops.d: New test.
+ * testsuite/gas/riscv/x-ventana-condops.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
+ * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Add vt.maskc and vt.maskcn.
+
+ Series-version: 1
+ Series-to: binutils@sourceware.org
+ Series-cc: Kito Cheng <kito.cheng@sifive.com>
+ Series-cc: Nelson Chu <nelson.chu@sifive.com>
+ Series-cc: Greg Favor <gfavor@ventanamicro.com>
+ Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
+
+2023-04-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gas: documentation for the BPF pseudo-c asm syntax
+ This patch expands the GAS manual in order to specify the alternate
+ pseudo-C assembly syntax used in BPF, and now supported by the
+ assembler.
+
+ gas/ChangeLog:
+
+ 2023-04-19 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ PR gas/29757
+ * doc/c-bpf.texi (BPF Pseudo-C Syntax): New section.
+
+2023-04-26 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ gas: BPF pseudo-c syntax tests
+ This patch expands the GAS BPF testsuite in order to also test the
+ alternative pseudo-C syntax used in BPF assembly.
+
+ This includes three main changes:
+
+ - Some general GAS tests involving assignment and equality operands in
+ expressions (such as = and ==) are disabled in bpf-* targets,
+ because the syntax collides with the pseudo-C BPF assembly syntax.
+
+ - New tests are added to the BPF GAS testsuite that test the pseudo-c
+ syntax. Tests for all BPF instructions are included.
+
+ - New tests are added to the BPF GAS testsuite that test the support
+ for both syntaxes in the same source.
+
+ gas/ChangeLog:
+
+ 2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ PR gas/29728
+ * testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
+ targets.
+ * testsuite/gas/all/eqv-dot.d: Likewise.
+ * testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.
+ * testsuite/gas/bpf/alu-pseudoc.s: New file.
+ * testsuite/gas/bpf/pseudoc-normal.s: Likewise.
+ * testsuite/gas/bpf/pseudoc-normal.d: Likewise.
+ * testsuite/gas/bpf/pseudoc-normal-be.d: Likewise.
+ * testsuite/gas/bpf/mem-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/lddw-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/jump32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/jump-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
+ * testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests.
+
+2023-04-26 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ gas: support for the BPF pseudo-c assembly syntax
+ This patch adds support to the GNU assembler for an alternative
+ assembly syntax used in BPF. This syntax is C-like and very
+ unconventional for an assembly language, but it is generated by
+ clang/llvm and is also used in inline asm templates in kernel code, so
+ we ought to support it.
+
+ After this patch, the assembler is able to parse instructions in both
+ supported syntax: the normal assembly-like syntax and the pseudo-C
+ syntax. Instruction formats can be mixed in the source program: the
+ assembler recognizes the right syntax to use.
+
+ gas/ChangeLog:
+
+ 2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ PR gas/29728
+ * config/tc-bpf.h (TC_EQUAL_IN_INSN): Define.
+ * config/tc-bpf.c (LEX_IS_SYMBOL_COMPONENT): Define.
+ (LEX_IS_WHITESPACE): Likewise.
+ (LEX_IS_NEWLINE): Likewise.
+ (LEX_IS_ARITHM_OP): Likewise.
+ (LEX_IS_STAR): Likewise.
+ (LEX_IS_CLSE_BR): Likewise.
+ (LEX_IS_OPEN_BR): Likewise.
+ (LEX_IS_EQUAL): Likewise.
+ (LEX_IS_EXCLA): Likewise.
+ (ST_EOI): Likewise.
+ (MAX_TOKEN_SZ): Likewise.
+ (init_pseudoc_lex): New function.
+ (md_begin): Call init_pseudoc_lex.
+ (valid_expr): New function.
+ (build_bpf_non_generic_load): Likewise.
+ (build_bpf_atomic_insn): Likewise.
+ (build_bpf_jmp_insn): Likewise.
+ (build_bpf_arithm_insn): Likewise.
+ (build_bpf_endianness): Likewise.
+ (build_bpf_load_store_insn): Likewise.
+ (look_for_reserved_word): Likewise.
+ (is_register): Likewise.
+ (is_cast): Likewise.
+ (get_token): Likewise.
+ (bpf_pseudoc_to_normal_syntax): Likewise.
+ (md_assemble): Try pseudo-C syntax if an instruction cannot be
+ parsed.
+
+2023-04-26 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ sim: bpf: update to new BPF relocations
+ This patch updates the BPF GNU sim testsuite in order to match the new
+ BPF relocations introduced in binutils in a recent patch [1].
+
+ [1] https://sourceware.org/pipermail/binutils/2023-March/126429.html
+
+2023-04-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix length of status line string
+ In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
+ ...
+ + std::string string_val = string.release ();
+ ...
+ without updating subsequent uses of string.size (), which returns 0 after the
+ string.release () call.
+
+ Fix this by:
+ - using string_val.size () instead of string.size (), and
+ - adding an assert that would have caught this regression.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+ PR tui/30389
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389
+
+2023-04-26 Tom Tromey <tromey@adacore.com>
+
+ Rewrite gdb_mpz::operator==
+ Simon pointed out that the recent changes to gdb_mpz caused a build
+ failure on amd64 macOS. It turns out to be somewhat difficult to
+ overload a method in a way that will work "naturally" for all integer
+ types; especially in a case like gdb_mpz::operator==, where it's
+ desirable to special case all integer types that are no wider than
+ 'long'.
+
+ After a false start, I came up with this patch, which seems to work.
+ It applies the desirable GMP special cases directly in the body,
+ rather than via overloads.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-04-26 Luis Machado <luis.machado@arm.com>
+
+ Updated debug architecture version checks for fbsd
+ There are two new debug architecture version entries. I updated the
+ code for Linux, but fbsd also needs updating.
+
+ This patch does this, and should be pretty straightforward.
+
+ I can't test this on native fbsd, but I'm fairly confident it should
+ work.
+
+2023-04-26 Luis Machado <luis.machado@arm.com>
+
+ Add new debug architecture version
+ Teach gdb about a new debug architecture version for AArch64 (0x11).
+
+ No user-visible changes.
+
+ Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
+
+2023-04-26 Alan Modra <amodra@gmail.com>
+
+ i386-dis.c UB shift and other tidies
+ 1) i386-dis.c:12055:11: runtime error: left shift of negative value -1
+ Bit twiddling is best done unsigned, due to UB on overflow of signed
+ expressions. Fix this by using bfd_vma rather than bfd_signed_vma
+ everywhere in i386-dis.c except print_displacement.
+
+ 2) Return get32s and get16 value in a bfd_vma, reducing the need for
+ temp variables.
+
+ 3) Introduce get16s and get8s functions to simplify the code.
+
+ 4) With some optimisation options gcc-13 legitimately complains about
+ a fall-through in OP_I. Fix that. OP_I also doesn't need to use
+ "mask" which was wrong for w_mode anyway.
+
+ 5) Masking with & 0xffffffff is better than casting to unsigned. We
+ don't know for sure that unsigned int is 32-bit.
+
+ 6) We also don't know that unsigned char is 8 bits. Mask codep
+ accesses everywhere. I don't expect binutils will work on anything
+ other than an 8-bit char host, but if we are masking codep accesses in
+ some places we might as well be consistent. (Better would be to use
+ stdint.h types more in binutils.)
+
+2023-04-26 Alan Modra <amodra@gmail.com>
+
+ binutils runtest $CC
+ I noticed in the binutile Makefile that runtest is being invoked with
+ CC, CC_FOR_BUILD and other compiler related flags in the environment.
+ That doesn't work. Those variables ought to be passed on the runtest
+ command line.
+
+ After fixing that I had some fails due to binutils testprog.c now
+ being compiled with the default "-g -O2" picked up in
+ CFLAGS_FOR_TARGET. Hack around that by passing -O0.
+
+ Also, with the binutils testsuite now taking notice of CC_FOR_TARGET,
+ I found a couple of debuginfod.exp fails with one of my compilers that
+ happened to be built without --debug-id being enabled by default.
+
+ * Makefile.am (check-DEJAGNU): Pass $CC and other variable on
+ the runtest command line rather than futilely in the
+ environment. Add -O0 to CFLAGS_FOR_TARGET.
+ * Makefile.in: Regenerate.
+ * testsuite/binutils-all/debuginfod.exp: Compile testprog.c
+ with -Wl,--build-id.
+
+2023-04-26 Alan Modra <amodra@gmail.com>
+
+ Avoid another -Werror=dangling-pointer
+ write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used
+
+ * write.c (chain_frchains_together_1): Rewrite loop as a do
+ while to avoid false positive -Wdangling-pointer.
+
+2023-04-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-25 Tom Tromey <tromey@adacore.com>
+
+ Use scoped_restore in varobj.c
+ One spot in varobj.c should use scoped_restore to save and restore
+ input_radix. Note that the current code may fail to restore it on
+ error, so this patch fixes a latent bug.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-04-25 Tom Tromey <tromey@adacore.com>
+
+ Remove some "goto"s from parse.c
+ parser_state::push_dollar has some unnecessary "goto"s. Replacing
+ them cleans up the code. Regression tested on x86-64 Fedora 36.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-04-25 Michael Matz <matz@suse.de>
+
+ section-select: Fix performance problem (PR30367)
+ when using many wild-statements with non-wildcard filenames we
+ were running into quadraticness via repeatedly using lookup_name
+ on a long list of loaded files. I've originally retained using
+ lookup_name because that preserved existing behaviour most obviously.
+ In particular in matching wild-statements when using a non-wildcard
+ filename it matches against local_sym_name, not the filename member.
+ If the wildspec would have an archive-spec or a wildcard it would use
+ the filename member, though. Also it would load the named file
+ (and ignore it, as being not equal to the currently considered
+ input-statement).
+
+ Rewrite this to not use lookup_name but retain the comparison
+ against local_sym_name with a comment to that effect.
+
+ PR 30367
+ * ldlang.c (walk_wild_section_match): Don't use lookup_name
+ but directly compare spec and local_sym_name.
+
+2023-04-25 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: adjust logic to avoid register name symbols
+ Special casing GPR names in my_getSmallExpression() leads to a number of
+ inconsistencies. Generalize this by utilizing the md_parse_name() hook,
+ limited to when instruction operands are being parsed (really: probed).
+ Then both the GPR lookup there and the yet more ad hoc workaround for
+ PR/gas 29940 can be removed (including its extension needed for making
+ the compressed form JAL work again).
+
+ RISC-V: test for expected / no unexpected symbols
+ Both the temporary workaround for PR/gas 29940 and the existing special
+ casing of GPRs in my_getSmallExpression() aren't really tested anywhere
+ (i.e. with the workarounds remove testing would still succeed). Nor is
+ there any test for uses of symbols with names matching GPRs, where such
+ is permitted. Before altering how this is to be dealt with, install two
+ testcases covering the expected behavior. (For now this includes only
+ known affected insns; re-ordering of entries in riscv_opcodes[] could,
+ however, yield more of them.)
+
+ RISC-V: don't recognize bogus relocations
+ With my_getSmallExpression() consistently and silently failing on
+ relocation operators not fitting an insn, it is no longer necessary to
+ hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a
+ subsequent parsing attempt for another operand combination might
+ succeed). This also eliminates the latent problem of percent_op_itype[]
+ and percent_op_stype[] growing a non-identical set of recognized
+ relocation operators.
+
+ RISC-V: avoid redundant and misleading/wrong error messages
+ The use of a wrong (for the insn) relocation operator (or a future one
+ which simply isn't recognized by older gas yet) doesn't render the (rest
+ of the) expression "bad". Furthermore alongside the error from
+ expression() in most cases the parser would emit another error then
+ anyway. Suppress the call to my_getExpression() in such a case,
+ arranging for a guaranteed subsequent error message by marking the
+ expression "illegal".
+
+ RISC-V: drop "percent_op" parameter from my_getOpcodeExpression()
+ Both callers check for no relocations, so there's no point parsing for
+ some. Have the function pass percent_op_null into
+ my_getSmallExpression(). Note that there's no point passing
+ percent_op_itype: Elsewhere, especially when processing compressed alias
+ insns ahead of non-alias ones, this has the effect of avoiding "bad
+ expression" errors when another parsing pass may follow (and succeed).
+ Here, however, all alternative forms of an insn type will again start
+ with the same O4 or O2, so avoiding errors earlier on doesn't really
+ help. Plus constructs with a relocation specifier (as percent_op_itype
+ would permit) can't be specified anyway, as the scrubber eats the
+ whitespace between .insn's type and the O4 or O2 expression when that
+ starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
+ riscv_ip() looks only for whitespace when finding the end of a mnemonic.
+
+ RISC-V: minor effort reduction in relocation specifier parsing
+ The sole caller of parse_relocation() has already checked for the %
+ prefix, so there's no need to check for it again in the strncasecmp()
+ and there's also no reason to make the involved string literals longer
+ than necessary.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.tui/empty.exp
+ In test-case gdb.tui/empty.exp we run into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ PASS: gdb.tui/empty.exp: src: 90x40: box 1
+ ...
+
+ We timeout here in Term::resize:
+ ...
+ # Due to the strange column resizing behavior, and because we
+ # don't care about this intermediate resize, we don't check
+ # the size here.
+ wait_for "@@ resize done $_resize_count"
+ ...
+ because the string we're trying to match is split over two lines:
+ ...
+ 25 -----------------------------------------------------------------------------+No
+ 26 ne No process In: L?? PC: ?? @@
+ 27 resize done 0, size = 79x40
+ 28 (gdb)
+ ...
+
+ Fix this by dropping the "@@ " prefix.
+
+ Tested on x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.tui/completion.exp
+ With test-case gdb.tui/completion.exp, we run into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ PASS: gdb.tui/completion.exp: check focus completions
+ ...
+
+ The timeout happens in this command:
+ ...
+ Term::command "layout src"
+ ...
+ which waits for:
+ - "(gdb) layout src", and then
+ - "(gdb) ".
+
+ Because the "layout src" command enables the TUI there's just a prompt.
+
+ Fix this by using Term::command_no_prompt_prefix.
+
+ Tested on x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.tui/new-layout.exp
+ In test-case gdb.tui/new-layout.exp we run into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ PASS: gdb.tui/new-layout.exp: layout=cmd_only {cmd 1} {} {}: \
+ bottom of cmd window is blank
+ ...
+
+ The timeout happens here:
+ ...
+ Term::command "layout src"
+ ...
+
+ Before the "layout src" command we have:
+ ...
+ Screen Dump (size 80 columns x 24 rows, cursor at column 46, row 7):
+ 0 +-tui-layout.c-------------------------+(gdb) layout example3
+ 1 | 20 { |(gdb) layout src
+ 2 | 21 return 0; |(gdb) winheight cmd 8
+ 3 | 22 } |(gdb) layout example4
+ 4 | 23 |(gdb) layout src
+ 5 | 24 |(gdb) winheight cmd 8
+ 6 | 25 |(gdb) layout example5
+ 7 | 26 |(gdb)
+ 8 | 27 |
+ 9 | 28 |
+ 10 | 29 |
+ 11 | 30 |
+ 12 | 31 |
+ 13 | 32 |
+ 14 | 33 |
+ 15 | 34 |
+ 16 | 35 |
+ 17 | 36 |
+ 18 | 37 |
+ 19 | 38 |
+ 20 | 39 |
+ 21 | 40 |
+ 22 +--------------------------------------+
+ 23 exec No process In: L?? PC: ??
+ ...
+ and after:
+ ...
+ Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 16):
+ 0 +-tui-layout.c-----------------------------------------------------------------+
+ 1 | 20 { |
+ 2 | 21 return 0; |
+ 3 | 22 } |
+ 4 | 23 |
+ 5 | 24 |
+ 6 | 25 |
+ 7 | 26 |
+ 8 | 27 |
+ 9 | 28 |
+ 10 | 29 |
+ 11 | 30 |
+ 12 | 31 |
+ 13 | 32 |
+ 14 +------------------------------------------------------------------------------+
+ 15 exec No process In: L?? PC: ??
+ 16 (gdb)
+ 17
+ 18
+ 19
+ 20
+ 21
+ 22
+ 23
+ ...
+
+ The Term::command "layout src" is waiting to match:
+ - "(gdb) layout src", and then
+ - "(gdb) ".
+
+ The first part fails to match on a line:
+ ...
+ | 26 |(gdb) layout src
+ ...
+ because it expects the prompt at the start of the line.
+
+ Fix this by allowing the prompt at the start of a window as well.
+
+ Tested by x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.tui/main.exp
+ With test-case gdb.tui/main.exp we run into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ PASS: gdb.tui/main.exp: show main after file
+ ...
+
+ The problem is that this command:
+ ...
+ Term::command "file [standard_output_file $testfile]"
+ ...
+ tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up
+ over two lines:
+ ...
+ 16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma
+ 17 in
+ 18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t
+ 19 ui/main/main...
+ 20 (gdb)
+ ...
+
+ Fix this by matching "Reading symbols from" instead.
+
+ Tested on x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.tui/corefile-run.exp
+ With test-case gdb.tui/corefile-run.exp we run into:
+ ...
+ WARNING: timeout in accept_gdb_output
+ PASS: gdb.tui/corefile-run.exp: load corefile
+ ...
+
+ The timeout happens in this command:
+ ...
+ Term::command "core-file $core"
+ ...
+ because it tries to match "(gdb) $cmd" but $cmd is split over two lines:
+ ...
+ 16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co
+ 17 refile-run/corefile-run.core
+ 18 [New LWP 5370]
+ 19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb
+ 20 .tui/corefile-run/coref'.
+ 21 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+ 22 #0 main () at tui-layout.c:21
+ 23 (gdb)
+ ...
+
+ Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead.
+
+ Tested on x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add debug prints in Term::wait_for
+ The semantics of wait_for are non-trivial, and a bit hard to understand
+ sometimes.
+
+ Add some debug prints in wait_for that make it clear:
+ - what regexps we're trying to match,
+ - what strings we compare to the regexps, and
+ - whether there's a match or mismatch.
+
+ I've added this ad-hoc a couple of times, and it seems that it's worth having
+ readily available.
+
+ The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the
+ RUNTESTFLAGS:
+ ...
+ $ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1"
+ ...
+
+ Tested on x86_64-linux.
+
+2023-04-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add warning for timeout in accept_gdb_output
+ In accept_gdb_output we have:
+ ...
+ timeout {
+ # Assume a timeout means we somehow missed the
+ # expected result, and carry on.
+ return 0
+ }
+ ...
+
+ The timeout is silent, and though in some places the return value is checked,
+ this is not done consistently, and consequently there are silent timeouts
+ when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).
+
+ Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
+ 50 seconds overall:
+ ...
+ real 1m0.275s
+ user 0m10.440s
+ sys 0m1.343s
+ ...
+
+ With an entire testsuite run taking about 30 minutes, that is about 2.5% of
+ the time spent waiting in TUI tests.
+
+ Let's make the timeouts visible using a warning, such that they can be fixed.
+
+ Tested on x86_64-linux.
+
+2023-04-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix auto-indent in gdb.gdb/python-helper.exp
+ When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
+ (emacs).
+
+ The problem is that this:
+ ...
+ if { 1 } {
+ foo "{" "}"<ENTER>bar
+ }
+ ...
+ produces this:
+ ...
+ if { 1 } {
+ foo "{" "}"
+ bar
+ }
+ ...
+
+ Note that this doesn't happen for "{}".
+
+ Fix this by using "\{" and "\}".
+
+ Tested on x86_64-linux.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto
+ On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
+ -O2 -g -flto=auto, I run into:
+ ...
+ FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
+ FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
+ FAIL: gdb.gdb/python-helper.exp: print *type->main_type
+ ...
+
+ Fix the first two FAILs by using $bkptno_numopt_re.
+
+ The last FAIL is due to:
+ ...
+ (outer-gdb) print *type->main_type^M
+ A syntax error in expression, near `->main_type'.^M
+ (outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
+ ...
+ because:
+ ...
+ (outer-gdb) print type^M
+ Attempt to use a type name as an expression^M
+ ...
+
+ Fix this by making the test unresolved if "print type" or
+ "print type->main_type" doesn't succeed.
+
+ On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
+ -O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
+ not hitting. Fix this by detecting the situation and bailing out.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multiple
+ While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
+ combination with -prompt and found out that it doesn't work, because -wrap uses
+ "$gdb_prompt $" instead of $prompt_regexp.
+
+ Fix this by making -wrap use $prompt_regexp.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove end_stepping_range observable
+ I noticed that this observable was never notified, which means we can
+ probably safely remove it. The notification was removed in:
+
+ commit 243a925328f8e3184b2356bee497181049c0174f
+ Author: Pedro Alves <palves@redhat.com>
+ Date: Wed Sep 9 18:23:24 2015 +0100
+
+ Replace "struct continuation" mechanism by something more extensible
+
+ print_end_stepping_range_reason in turn becomes unused, so remote it as
+ well.
+
+ Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use -std=gnu99 for gdb.server/attach-flag.exp
+ When using a compiler defaulting to -std=gnu90, we run into:
+ ...
+ Running gdb.server/attach-flag.exp ...
+ gdb compile failed, attach-flag.c: In function 'main':
+ attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
+ in C99 or C11 mode
+ for (int i = 0; i < NTHREADS; i++)
+ ^~~
+ attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
+ -std=gnu11 to compile your code
+ ...
+
+ Fix this by using -std=gnu99.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.exp
+ Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
+ require this.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64le
+ When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
+ ...
+ Running gdb/testsuite/gdb.multi/multi-arch.exp ...
+ gdb compile failed, In file included from /usr/include/features.h:399:0,
+ from /usr/include/stdio.h:27,
+ from gdb/testsuite/gdb.multi/hangout.c:18:
+ /usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
+ No such file or directory
+ # include <gnu/stubs-32.h>
+ ^
+ compilation terminated.
+ ...
+
+ The problem is that the test-case attempts to use gcc -m32 to produce an
+ executable while that's not available.
+
+ Fix this by:
+ - introduce a new caching proc have_compile_and_link_flag, and
+ - using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.
+
+ Tested on:
+ - x86_64-linux (openSUSE Leap 15.4), and
+ - powerpc64le-linux (CentOS-7).
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add basic lmap for tcl < 8.6
+ With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
+ ...
+ ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
+ ERROR: invalid command name "lmap"
+ while executing
+ "::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
+ dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
+ ...
+
+ Fix this by adding basic lmap support for tcl version < 8.6.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Don't use string cat in gdb.dwarf2/dw2-abs-hi-pc.exp
+ Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
+ ...
+ set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
+ ...
+ but that's only supported starting tcl 8.6.
+
+ Fix this by using "expr" instead:
+ ...
+ set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
+ ...
+
+ Tested on x86_64-linux.
+
+2023-04-24 Nick Clifton <nickc@redhat.com>
+
+ New georgian translation for the bfd sub-directory
+
+2023-04-24 Alan Modra <amodra@gmail.com>
+
+ Revert "x86: work around compiler diagnosing dangling pointer"
+ This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.
+
+2023-04-24 Alan Modra <amodra@gmail.com>
+
+ gcc-13 i386-dis.c warning
+ opcodes/i386-dis.c: In function ‘print_insn’:
+ opcodes/i386-dis.c:9865:22: error: storing the address of local
+ variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]
+
+ * i386-dis.c (print_insn): Clear info->private_data before
+ returning.
+
+2023-04-24 Alan Modra <amodra@gmail.com>
+
+ asan: segfault in coff_mangle_symbols
+ The testcase managed to trigger creation of a wild pointer in
+ coff_slurp_symbol_table. Stop that happening, and fix an unrelated
+ problem I happened to see in bfd_coff_get_syment.
+
+ * coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
+ converting n_value from a pointer to an index.
+ * coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
+ symbol value before converting to a pointer.
+
+2023-04-24 Alan Modra <amodra@gmail.com>
+
+ objcopy of archives tidy
+ This makes sure the input element bfd is closed before exiting the
+ loop copying elements.
+
+ * objcopy.c (copy_archive): Rename output_bfd to output_element.
+ Localise last_element. Close this_element in more error cases.
+
+2023-04-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Skip dap tests for tcl 8.5
+ When running the dap tests on a system with tcl 8.5, we run into:
+ ...
+ ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
+ ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
+ digit, double, false, graph, integer, list, lower, print, punct, space, \
+ true, upper, wideinteger, wordchar, or xdigit
+ while executing
+ "string is entier $num"
+ (procedure "num" line 16)
+ invoked from within
+ ...
+
+ Fix this by:
+ - requiring tcl 8.6 in allow_dap_tests, and
+ - adding the missing require allow_dap_tests in gdb.dap/memory.exp.
+
+ Tested on x86_64-linux.
+
+2023-04-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: work around compiler diagnosing dangling pointer
+ For quite come time print_insn() has been storing the address of a local
+ variable into info->private_data. Since the compiler can't know that the
+ field won't be accessed again after print_insn() returns, it may kind of
+ legitimately diagnose this. And recent enough gcc does as of the
+ introduction of the fetch_error() return paths (replacing setjmp()-based
+ error handling).
+
+ Utilizing that neither prefix_name() nor i386_dis_printf() actually use
+ info->private_data, zap the pointer in fetch_error(), after having
+ retrieved it for local use.
+
+2023-04-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-23 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: fix loongson3 llsc workaround
+ -mfix-looongson3-llsc may add sync instructions not needed on some
+ asm code with lots of debug info.
+
+ PR: 30153
+ * gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.
+
+2023-04-23 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: default output r6 obj if the triple is r6
+ If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
+ r6 objects by default.
+ The triples with vendor `img` should do same.
+
+ The examples include:
+ as xx.s -o xx.o
+ ld -r -b binary xx.dat -o xx.o
+
+2023-04-23 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: support mips*64 as CPU and gnuabi64 as ABI
+ For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
+ used as the cpu name in triple.
+ Let's recognize them by `mips*64*(el)`.
+
+ For 64bit Ports, like Debian's mips64el and mips64r6el ports,
+ `gnuabi64` is used as the abi section.
+ Let's use N64 abi by default for the triple with gnuabi64.
+
+2023-04-23 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix loongarch32 test fails
+ Regenerated macro_op_32.d and add skip loongarch64-*-*.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/loongarch/macro_op_32.d: Regenerated.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated.
+
+2023-04-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove debug prints in gdb_find_gdc
+ When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
+ rather than dejagnu's copy (mimicing what happens with an older dejagnu
+ without find_gdc), I run into these debug prints:
+ ...
+ Tool Root: /data/vries/gdb/leap-15-4/build
+ CC: gdc
+ ...
+
+ Remove these.
+
+ Tested on x86_64-linux.
+
+2023-04-22 WANG Rui <r@hev.cc>
+
+ gdb: Fix false match issue in skip_prologue_using_linetable
+ [ Changes in v2:
+ - rebase on trunk
+ Changes in v3:
+ - add test-case ]
+
+ We should exclude matches to the ending PC to prevent false matches with the
+ next function, as prologue_end is located at the end PC.
+
+ <fun1>:
+ 0x00: ... <-- start_pc
+ 0x04: ...
+ 0x08: ... <-- breakpoint
+ 0x0c: ret
+ <fun2>:
+ 0x10: ret <-- end_pc | prologue_end of fun2
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
+ Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+ [1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
+
+ PR symtab/30369
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
+
+2023-04-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove language_auto
+ I think that the language_auto enumerator and the auto_language class
+ can be removed. There isn't really an "auto" language, it's only a
+ construct of the "set language" command to say "pick the appropriate
+ language automatically". But "auto" is never the current language. The
+ `current_language` points to the current effective language, and the
+ fact that we're in "auto language" mode is noted by the language_mode
+ global.
+
+ - Change set_language to handle the "auto" (and "local", which is a
+ synonym) early, instead of in the for loop. I think it makes the two
+ cases (auto vs explicit language) more clearly separated anyway.
+
+ - Adjust add_set_language_command to hard-code the "auto" string,
+ instead of using the "auto" language definition.
+
+ - Remove auto_language, rename auto_or_unknown_language to
+ unknown_language and move the bits of the existing unknown_language
+ in there.
+
+ - Remove the set_language at the end of _initialize_language. I think
+ it's not needed, because we call set_language in gdb_init, after all
+ _initialize functions are called. There is some chance that an
+ _initialize function that runs after _initialize_language implicitly
+ depends on current_language being set, but my testsuite runs haven't
+ found anything like that.
+
+ - Use language_unknown instead of language_auto when creating a minimal
+ symbol (minimal_symbol_reader::record_full). I think that this value
+ is used to indicate that we don't know the symbol of the minimal
+ symbol (yet), so language_unknown makes sense to me. Update a
+ condition accordingly in ada-lang.c. symbol_find_demangled_name also
+ appears to "normalize" this value from "unknown" to "auto", remove
+ that part and update the condition to just check for
+ language_unknown.
+
+ Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: switch "set language" to getter/setter
+ The `language` global variable is mostly a scratch variable used for the
+ setting. The source of truth is really current_language and
+ language_mode (auto vs manual), which are set by the
+ set_language_command callback.
+
+ Switch the setting to use the add_setshow_enum_cmd overload that takes a
+ value getter and setter.
+
+ Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove return value of set_language
+ set_language returns the previous language, but nothing uses it. Remove
+ the return value. This lets us remove the assignment to
+ current_language, in _initialize_language.
+
+ Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add make-check-all.sh
+ Directory gdb/testsuite/boards contains a number of host/target boards, which
+ run a test-case (or test-cases) in a different way.
+
+ The benefits of using these boards are:
+ - improving test coverage of gdb,
+ - making the testsuite more robust, and
+ - making sure the test-cases work for non-native and remote setups, if
+ possible.
+
+ Each board is slightly different, and developers need to learn how to use each
+ one, what parameters to pass and how, and which ones can be used in
+ combination with each other. This is a threshold to start using them.
+
+ And then there quite a few, so I suppose typically only a few will be used by
+ each developer.
+
+ Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
+ drop-in replacement of make check, while excercising all host/target boards in
+ gdb/testsuite/boards.
+
+ An example of make-check-all.sh for one test-case is:
+ ...
+ $ ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
+ LOCAL:
+ # of expected passes 8
+ TARGET BOARD: cc-with-gdb-index
+ # of expected passes 8
+ ...
+ HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
+ # of expected passes 8
+ HOST/TARGET BOARD: local-remote-host-native
+ # of expected passes 8
+ ...
+
+ Shell-checked and tested on x86_64-linux.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-04-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Add maint info screen
+ While working on PRs tui/30337 and cli/30346 I came across various notions of
+ width in gdb, as reported by gdb, readline, curses and the environment
+ variables.
+
+ As for gdb, readline and the environment variables, the way things work
+ is:
+ - Gdb asks readline to detect screen size,
+ - readline sets the actual screen size in the environment variables
+ COLUMNS and LINES,
+ - readline reports back a screen size to gdb, which may have one column
+ less than the actual screen size, to deal with lack of auto-wrap.
+ This becomes gdb's notion of screen size (in other words the point where
+ we can expect the gdb command line to wrap),
+ - Gdb then explicitly sets readline's screen size, which readline itself may
+ adjust to deal with lack of auto-wrap. This becomes readlines notion
+ of screen size (well, internally the unadjusted one, but it'll report back
+ the adjusted one).
+
+ Add a command "maint info screen" that prints these notions, both for width
+ and height.
+
+ For TERM=xterm we have:
+ ...
+ $ TERM=xterm gdb -ex "maint info screen"
+ Number of characters gdb thinks are in a line is 118.
+ Number of characters readline reports are in a line is 118.
+ Number of characters curses thinks are in a line is 118.
+ Number of characters environment thinks are in a line is 118 (COLUMNS).
+ Number of lines gdb thinks are in a page is 27.
+ Number of lines readline reports are in a page is 27.
+ Number of lines curses thinks are in a page is 27.
+ Number of lines environment thinks are in a page is 27 (LINES).
+ ...
+
+ And for TERM=ansi:
+ ...
+ $ TERM=ansi gdb -ex "maint info screen"
+ Number of characters gdb thinks are in a line is 117.
+ Number of characters readline reports are in a line is 116.
+ Number of characters curses thinks are in a line is 118.
+ Number of characters environment thinks are in a line is 118 (COLUMNS).
+ Number of lines gdb thinks are in a page is 27.
+ Number of lines readline reports are in a page is 27.
+ Number of lines curses thinks are in a page is 27.
+ Number of lines environment thinks are in a page is 27 (LINES).
+ ...
+
+ [ The fact that we have "characters readline reports are in a line is 116" is
+ is due to gdb making readline adjust twice for the lack of auto-wrap, this is
+ PR cli/30346.
+
+ Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
+ "maint info screen":
+ ...
+ Number of characters characters curses thinks are in a line is 110.
+ Number of characters environment thinks are in a line is 111 (COLUMNS). ]
+
+ And for TERM=ansi, with width and heigth set to 0:
+ ...
+ Number of characters gdb thinks are in a line is 4294967295 (unlimited).
+ Number of characters readline reports are in a line is 32766 (unlimited - 1).
+ Number of characters curses thinks are in a line is 118.
+ Number of characters environment thinks are in a line is 118 (COLUMNS).
+ Number of lines gdb thinks are in a page is 4294967295 (unlimited).
+ Number of lines readline reports are in a page is 32767 (unlimited).
+ Number of lines curses thinks are in a page is 27.
+ Number of lines environment thinks are in a page is 27 (LINES).
+ ...
+
+ [ Note that when doing a resize by say maximizing or de-maximizing a terminal,
+ all reported values are updated, except for curses when not in TUI mode.
+
+ Maybe that means there's a bug. If not, then maybe we should not print
+ the curses lines unless in TUI mode, or annotate those lines such that it's
+ clear that the values may be not up-to-date. ]
+
+ I'd like to use this command in the regression test for PR cli/30346.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-21 Tom Tromey <tromey@adacore.com>
+
+ Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.c
+ A recent change in opcodes/i386-dis.c caused a build failure on my
+ x86-64 Fedora 36 system, which uses:
+
+ $ gcc --version
+ gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
+ [...]
+
+ The error is:
+
+ ../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
+ ../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
+ 12705 | disp = val & 0x8000 ? val - 0x10000 : val;
+ | ~~~~^~~~~~~~
+
+ This patch fixes the warning.
+
+ opcodes/ChangeLog
+ 2023-04-21 Tom Tromey <tromey@adacore.com>
+
+ * i386-dis.c (OP_J): Check result of get16.
+
+2023-04-21 Tom Tromey <tromey@adacore.com>
+
+ Use entry values for 32-bit PPC struct return
+ AdaCore has a local patch for PPC "finish", but last year, Ulrich
+ Weigand pointed out that this patch was incorrect. It may work for
+ simple functions like the one in the internal test, but nothing
+ guarantees that r3 will be preserved by the callee, so checking r3 on
+ exit is not always correct.
+
+ This patch fixes the problem using the same approach as PPC64: use the
+ entry value of r3, if available. Ulrich confirmed this matches the
+ PPC32 ABI.
+
+2023-04-21 Tom Tromey <tromey@adacore.com>
+
+ Handle erroneous DW_AT_call_return_pc
+ On PPC64, with the test case included in an earlier patch, we found
+ that "finish" would still not correctly find the return value via
+ entry values.
+
+ The issue is simple. The compiler emits:
+
+ 0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large>
+ 0x00000000100032bc <+32>: nop
+ 0x00000000100032c0 <+36>: li r9,42
+
+ ... but the DWARF says:
+
+ <162a> DW_AT_call_return_pc: 0x100032c0
+
+ That is, the declared return PC is one instruction past the actual
+ return PC.
+
+ This patch adds a new arch hook to handle this scenario, and
+ implements it for PPC64. Some care is taken so that GDB will continue
+ to work if this compiler bug is fixed. A GCC patch is here:
+
+ https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html
+
+ No check for 'nop' is done, as subsequent discussion revealed that the
+ linker might replace this with another instruction.
+
+2023-04-21 Tom Tromey <tromey@adacore.com>
+
+ Handle function descriptors in call_site_target
+ call_site_target::iterate_over_addresses may look up a minimal symbol.
+ On platforms like PPC64 that use function descriptors, this may find
+ an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
+ to convert from a function descriptor to the address recorded at the
+ call site.
+
+ I've added a new test case that is based on the internal AdaCore test
+ that provoked this bug. However, I'm unable to test it as-is on
+ PPC64.
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop (explicit) BFD64 dependency from disassembler
+ get64() is unreachable when !BFD64 (due to a check relatively early in
+ print_insn()). Let's avoid the associated #ifdef-ary (or else we should
+ extend it to remove more dead code).
+
+ x86: drop use of setjmp() from disassembler
+ With the longjmp() uses all gone, the setjmp() isn't necessary anymore
+ either.
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: change fetch error handling for get<N>()
+ Make them return boolean and convert FETCH_DATA() uses to fetch_code().
+ With this no further users of FETCH_DATA() remain, so the macro and its
+ backing function are dropped as well.
+
+ Leave value types as they were for the helper functions, even if I don't
+ think that beyond get64() use of bfd_{,signed_}vma is really necessary.
+ With type change of "disp" in OP_E_memory(), change the 2nd parameter of
+ print_displacement() to a signed type as well, though (eliminating the
+ need for a local variable of signed type). This also eliminates the need
+ for custom printing of '-' in Intel syntax displacement expressions.
+
+ While there drop forward declarations which aren't really needed.
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: change fetch error handling when processing operands
+ Make the handler functions all return boolean and convert FETCH_DATA()
+ uses to fetch_code().
+
+ x86: change fetch error handling in get_valid_dis386()
+ Introduce a special error indicator node, for the sole (real) caller
+ to recognize and act upon.
+
+ x86: change fetch error handling in ckprefix()
+ Use a tristate (enum) return value type to be able to express all three
+ cases which are of interest to the (sole) caller. This also allows doing
+ away with the abuse of "rex_used".
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: change fetch error handling in top-level function
+ ... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
+ error handling is problematic, as per
+ https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
+ using more conventional error handling instead.
+
+ Also introduce a fetch_modrm() helper, for subsequent re-use.
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: move fetch error handling into a helper function
+ ... such that it can be used from other than the setjmp() error handling
+ path.
+
+ Since I'd like the function's parameter to be pointer-to-const, two
+ other functions need respective constification then, too (along with
+ needing to be forward-declared).
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ bfd: fix STRICT_PE_FORMAT build
+ A semicolon was missing and "name" needs to be pointer-to-const. While
+ adding "const" there, also add it for "sec".
+
+2023-04-21 Lifang Xia <lifang_xia@linux.alibaba.com>
+
+ RISC-V: Optimize relaxation of gp with max_alignment.
+ This should be the first related issue, which posted in riscv-gnu-toolchain,
+ https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497
+
+ If the output sections are not between gp and the symbol, then their alignments
+ shouldn't affect the gp relaxation. However, this patch improves this idea
+ even more, it limits the range to the gp+-2k, which means only the output
+ section which are in the [gp-2K, gp+2K) range need to be considered.
+
+ Even if the output section candidates may be different for each relax passes,
+ the symbol that can be relaxed ar this round will not be truncated at next
+ round. That is because this round you can do relaxation which means that the
+ section where the symbol is located is within the [gp-2K, gp+2K) range, so all
+ the output section alignments between them should be considered. In other
+ words, if the alignments between them may cause truncated, then we should
+ already preserve the size and won't do the gp relaxation this time.
+
+ This patch can resolve the github issue which mentioned above, and also passed
+ all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
+ safe enough to commit.
+
+ Originally, this patch also do the same optimization for the call relaxations,
+ https://sourceware.org/pipermail/binutils/2022-October/123918.html
+ But just in case there is something that has not been considered, we only
+ deal with the gp relaxation at this time.
+
+ bfd/
+ * elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
+ max_alignment_for_gp. It is used to record the maximum alignment of
+ the output sections, which are in the [gp-2K, gp+2k) range.
+ (riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
+ (_bfd_riscv_get_max_alignment): Added new parameter, gp. If gp is
+ zero, then all the output section alignments are possible candidates;
+ Otherwise, only the output sections which are in the [gp-2K, gp+2K)
+ range need to be considered.
+ (_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
+ non-zero gp if the max_alignment_for_gp is -1.
+ (_bfd_riscv_relax_pc): Likewise.
+ (_bfd_riscv_relax_section): Record the first input section, so that
+ we can reset the max_alignment_for_gp for each repeated relax passes.
+ ld/
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+ * testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase. It fails
+ without this patch.
+
+2023-04-21 Jan Beulich <jbeulich@suse.com>
+
+ ld: add missing period after @xref
+ At least older versions of one of the doc generation tools complain
+ (warn) about it missing.
+
+2023-04-21 Alan Modra <amodra@gmail.com>
+
+ Keeping track of rs6000-coff archive element pointers
+ rs6000-coff archives use a linked list of file offsets, where each
+ element points to the next element. The idea is to allow updating of
+ large archives quickly without rewriting the whole archive. (binutils
+ ar does not do this.) Unfortunately this is an easy target for
+ fuzzers to create an archive that will cause ar or any other tool
+ processing archives to hang. I'd implemented guards against pointing
+ back to the previous element, but of course that didn't last long.
+
+ So this patch implements a scheme to keep track of file offset ranges
+ used by elements as _bfd_read_ar_hdr is called for each element. See
+ the add_range function comment. I needed a place to stash the list,
+ so chose the obvious artdata.tdata backend extension to archive's
+ tdata, already used by xcoff. That involved a little cleanup, because
+ while it would be possible to continue using different artdata.tdata
+ for the big and small archives, it's nicer to use a union.
+
+ If anyone is concerned this list of element ranges might grow large
+ and thus significantly slow down the tools, adjacent ranges are
+ merged. In fact something like "ar t" will only ever have one range
+ on xcoff archives generated by binutils/ar. I agree there might still
+ be a problem with ld random element access via the armap.
+
+ include/
+ * coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
+ (SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
+ (struct ar_ranges, struct xcoff_artdata): New.
+ (x_artdata): Define.
+ (xcoff_big_format_p): Rewrite.
+ (xcoff_ardata, xcoff_ardata_big): Delete.
+ bfd/
+ * coff-rs6000.c: Replace uses of xcoff_ardata and
+ xcoff_ardata_big throughout file.
+ (_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
+ (add_range): New function.
+ (_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak.
+ (_bfd_xcoff_openr_next_archived_file): Remove old sanity
+ checks. Set up range for header.
+ (xcoff_write_archive_contents_old): Make the temporary
+ artdata.tdata used here to pass info down to
+ _bfd_compute_and_write_armap a struct xcoff_artdata.
+ (xcoff_write_archive_contents_big): Likewise.
+ * coff64-rs6000.c: Replace uses of xcoff_ardata and
+ xcoff_ardata_big throughout file.
+ (xcoff64_archive_p): Adjust artdata.tdata allocation.
+
+2023-04-21 Alan Modra <amodra@gmail.com>
+
+ Delete struct artdata archive_head
+ This element is unused. Ideally we'd be moving archive_head and
+ other archive specific fields from struct bfd to here, but that's a
+ much larger change than this little bit of cleanup.
+
+ * libbfd-in.h (struct artdata): Delete archive_head.
+ * libbfd.h: Regenerate.
+ * archive.c,
+ * coff-rs6000.c,
+ * coff64-rs6000.c: Delete comments mentioning artdata archive_head.
+
+2023-04-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-20 Nick Clifton <nickc@redhat.com>
+
+ Add a SECURITY.txt file describing the GNU Binutils' project's stance on security related bugs.
+
+2023-04-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: adjust an ILP32 testcase using .insn
+ In commit 6967633c8b49 ("x86: convert testcases to use .insn") an ILP32
+ clone of a testcase was missed in the set of tests needing --divide
+ added.
+
+ Reported-by: Clément Chigot <chigot@adacore.com>
+
+2023-04-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-20 Alan Modra <amodra@gmail.com>
+
+ sh4-linux segfaults running ld testsuite
+ Segmentation fault
+ FAIL: pr22269-1 (static pie undefined weak)
+ and others running "visibility (hidden undef)" tests
+
+ No code has any right to access bfd_link_hash_entry u.def without
+ first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.
+
+ * elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
+ relocs in GOT unless symbol is defined.
+
+2023-04-20 Alan Modra <amodra@gmail.com>
+
+ PR30343 infrastructure
+ Make ldemul_before_plugin_all_symbols_read more useful.
+
+ * ldlang.c (lang_process): Move call to
+ ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
+ Allow backends to add to gc_sym_list before handling entry sym.
+ * ldelf.c (ldelf_before_plugin_all_symbols_read): Test
+ lto_plugin_active.
+
+2023-04-20 Alan Modra <amodra@gmail.com>
+
+ ubsan: signed integer overflow in display_debug_lines_raw
+ This one was caused by me unnecessarily promoting an "int adv" to
+ "int64_t adv". The expression overflowing was 4259 + 9223372036854775807
+ with the left number being unsigned int.
+
+ * dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
+ with uint16_t and unsigned char with uint8_t. Make li_line_base
+ an int8_t.
+ * dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.
+
+2023-04-20 Alan Modra <amodra@gmail.com>
+
+ Yet another out-of-memory fuzzed object
+ Do I care about out of memory conditions triggered by fuzzers? Not
+ much. Your operating system ought to be able to handle it by killing
+ the memory hog. Oh well, this one was an element of a coff-alpha
+ archive that said it was a little less that 2**64 in size. The
+ coff-alpha compression scheme expands at most 8 times, so we can do
+ better in bfd_get_file_size.
+
+ * bfdio.c (bfd_get_file_size): Assume elements in compressed
+ archive can only expand a maximum of eight times.
+ * coffgen.c (_bfd_coff_get_external_symbols): Sanity check
+ size of symbol table agains file size.
+
+2023-04-20 Alan Modra <amodra@gmail.com>
+
+ buffer overflow in print_symname
+ * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate
+ string sections.
+
+2023-04-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: minor formatting fixes in sframe_encoder_write_fre
+ libsframe/
+ * sframe.c (sframe_encoder_write_fre): Formatting fixes for
+ readability.
+
+ libsframe: use consistent function argument names
+ libsframe/
+ * sframe.c (sframe_decoder_get_header): Use consistent function
+ arg names.
+ (sframe_decoder_free): Likewise.
+ (sframe_encode): Use more appropriate var name.
+
+2023-04-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: correct some typos
+ include/
+ * sframe.h: Correct a typo.
+
+ libsframe/
+ * sframe.c: Likewise.
+
+2023-04-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: use return type of bool for predicate functions
+ libsframe/
+ * sframe.c (sframe_header_sanity_check_p): Change return type to
+ bool.
+ (sframe_fre_sanity_check_p): Likewise.
+
+ gas: sframe: fix comment
+
+ gas: sframe: use ATTRIBUTE_UNUSED consistently
+ gas/
+ * gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
+ consistently.
+ (output_sframe): Likewise.
+ (sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.
+
+2023-04-19 Tom Tromey <tromey@adacore.com>
+
+ Remove adjust_type_signedness
+ I happened across adjust_type_signedness, which may be used to modify
+ a type when printing an Ada value. Modifying a type like this is a
+ bad idea -- they should normally be considered immutable. Removing
+ this function still passes both the dejagnu and internal AdaCore
+ tests, though, so this patch drops it.
+
+ As this was reviewed internally, and only affect Ada, I am checking it
+ in.
+
+2023-04-19 Nick Clifton <nickc@redhat.com>
+
+ Fix: readelf: loc_offset XX too big
+ PR 30355
+ * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section.
+
+2023-04-19 Jan Beulich <jbeulich@suse.com>
+
+ gas: document that get_symbol_name() can clobber the input buffer
+ Callers which want to make further parsing attempts at the buffer passed
+ to the function need to be aware that due to the potential of string
+ concatenation the input buffer may be altered in ways beyond what can be
+ undone by putting back at *input_line_pointer the character that the
+ function returns.
+
+2023-04-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: parse_register() must not alter the parsed string
+ This reverts the code change done by 100f993c53a5 ("x86: Check
+ unbalanced braces in memory reference"), which wrongly identified
+ e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T
+ syntax") as the root cause of PR gas/30248. (The testcase is left in
+ place, no matter that it's at best marginally useful in that shape.)
+
+ The problem instead is that parse_register() alters the string handed to
+ it, thus breaking valid assumptions in subsequent parsing code. Since
+ the function's behavior is a result of get_symbol_name()'s, make a copy
+ of the incoming string before invoking that function.
+
+ Like for parse_real_register() follow the model of strtol() et al: input
+ string is const-qualified to signal that the string isn't altered, but
+ the returned "end" pointer is not const-qualified, requiring const to be
+ cast away (which generally is a bad idea, but the alternative would
+ again be more convoluted code).
+
+2023-04-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: parse_real_register() does not alter the parsed string
+ Follow the model of strtol() et al - input string is const-qualified to
+ signal that the string isn't altered, but the returned "end" pointer is
+ not const-qualified, requiring const to be cast away (which generally is
+ a bad idea, but the alternative would be more convoluted code).
+
+2023-04-19 Nick Clifton <nickc@redhat.com>
+
+ Updated Hungarian translation for the gprof directory
+
+2023-04-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: re-format Python code with black 23
+ Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b
+
+2023-04-18 Carl Love <cel@us.ibm.com>
+
+ PowerPC: fix _Float128 type output string
+ PowerPC supports two 128-bit floating point formats, the IBM long double
+ and IEEE 128-bit float. The issue is the DWARF information does not
+ distinguish between the two. There have been proposals of how to extend
+ the DWARF information as discussed in
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
+
+ but has not been fully implemented.
+
+ GCC introduced the _Float128 internal type as a work around for the issue.
+ The workaround is not transparent to GDB. The internal _Float128 type
+ name is printed rather then the user specified long double type. This
+ patch adds a new gdbarch method to allow PowerPC to detect the GCC
+ workaround. The workaround checks for "_Float128" name when reading the
+ base typedef from the die_info. If the workaround is detected, the type
+ and format fields from the _Float128 typedef are copied to the long
+ double typedef. The same is done for the complex long double typedef.
+
+ This patch fixes 74 regression test failures in
+ gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
+ default on GCC. It fixes one regression test failure in
+ gdb.base/complex-parts.exp.
+
+ The patch has been tested on Power 10 where GCC defaults to IEEE Float
+ 128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The
+ patch as also been tested on X86-64 with no new regression failures.
+
+2023-04-18 mengqinggang <mengqinggang@loongson.cn>
+
+ Symbols with GOT relocatios do not fix adjustbale
+ gas
+ * config/tc-loongarch.c (loongarch_fix_adjustable): Symbols with GOT relocatios do not fix adjustbale.
+ * testsuite/gas/loongarch/macro_op_large_abs.d: Regenerated.
+ * testsuite/gas/loongarch/macro_op_large_pc.d: Regenerated.
+ ld
+ * testsuite/ld-loongarch-elf/macro_op.d: Regenerated. -
+
+2023-04-18 Thomas Koenig <tkoenig@netcologne.de>
+
+ Assembler Internal Docs: Describe handling of opcodes for relaxation a bit better.
+
+2023-04-18 Kito Cheng <kito.cheng@sifive.com>
+
+ RISC-V: Cache the latest mapping symbol and its boundary.
+ This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188
+
+ Current flow:
+ 1) Scan any mapping symbol less than this instruciton.
+ 2) If not found, did a backward search.
+
+ The flow seems not big issue, let run an example here:
+
+ $x:
+ 0x0 a <--- Found at step 1
+ 0x4 b <--- Not found in step 1, but found at step 2
+ 0x8 c <--- Not found in step 1, but found at step 2
+ $d
+ 0x12 .word 1234 <-- Found at step 1
+
+ The instruciton didn't have the same address with mapping symbol will
+ still did backward search again and again.
+
+ So the new flow is:
+ 1) Use the last mapping symbol status if the address is still within the range
+ of the current mapping symbol.
+ 2) Scan any mapping symbol less than this instruciton.
+ 3) If not found, did a backward search.
+ 4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
+ and cache that.
+
+ Use the same example to run the new flow again:
+
+ $x:
+ 0x0 a <--- Found at step 2, the boundary is 0x12
+ 0x4 b <--- Cache hit at step 1, within the boundary.
+ 0x8 c <--- Cache hit at step 1, within the boundary.
+ $d
+ 0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.
+
+ The disassemble time of the test cases has been reduced from ~20 minutes to ~4
+ seconds.
+
+ opcode/ChangeLog
+ PR 30282
+ * riscv-dis.c (last_map_symbol_boundary): New.
+ (last_map_state): New.
+ (last_map_section): New.
+ (riscv_search_mapping_symbol): Cache the result of latest
+ mapping symbol.
+
+2023-04-18 Alan Modra <amodra@gmail.com>
+
+ objdump use of uninitialised value in pr_string_field
+ PR 30365
+ * rdcoff.c (parse_coff_struct_type): Leave bitsize zero when no
+ auxents.
+
+ objdump buffer overflow in fetch_indexed_string
+ PR 30361
+ * dwarf.c (fetch_indexed_string): Sanity check string index.
+
+2023-04-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30360 Seg. Fault when application uses std::thread
+ We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
+ Some of these functions have versions. For example,
+
+ % nm -D /lib64/gprofng/libgp-collector.so | grep thread_create@ | sort
+ 000000000004b420 T pthread_create@GLIBC_2.34
+ 000000000004b490 T pthread_create@GLIBC_2.17
+ 000000000004b500 T pthread_create@GLIBC_2.2.5
+ 000000000004b570 T pthread_create@GLIBC_2.1
+ 000000000004b5e0 T pthread_create@GLIBC_2.0
+
+ Our library does not set the default version for symbols.
+ This is correct because we don't know which libC will be used.
+
+ gcc and g++ links differently the version symbols when the default version is
+ not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using
+ our pthread_create@GLIBC_2.0 by default.
+
+ The current implementation of the interposed functions is:
+ If we are in our pthread_create@GLIBC_<NN>,
+ we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call
+ the same function from libC.
+ In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC.
+ We need to call the default version symbol from libC.
+
+ gprofng/ChangeLog
+ 2023-04-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30360
+ * libcollector/iotrace.c: Find and call a default libC version symbol.
+ * libcollector/dispatcher.c: Likewise.
+ * libcollector/iotrace.c: Likewise.
+ * libcollector/linetrace.c: Likewise.
+ * libcollector/mmaptrace.c: Likewise.
+ * libcollector/synctrace.c: Likewise.
+ * libcollector/collector.h (REAL_DCL): Remove an unused argument.
+
+2023-04-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Update documentation
+ This patch addresses bugzilla 29521:
+ Bug 29521 - [docs] man pages are not in the release tarball
+
+ The dependence on help2man to create the man pages has been eliminated.
+ All man pages are now written in Texinfo. Texi2pod and pod2man are used
+ to generate the man pages from the source.
+
+ The user guide has been significantly expanded. It also includes all
+ the man pages. These are formatted appropriately in the INFO, PDF, and
+ HTML formats.
+
+ The index in the user guide has been enhanced to include an overview
+ of all options and commands that have been documented so far.
+
+ The work on the documentation has not been completed, but this is
+ a significant step forward.
+
+ gprofng/ChangeLog
+ 2023-04-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29521
+ * doc/Makefile.am: Build documentation.
+ * doc/gprofng.texi: Update documentation.
+ * doc/version.texi: Likewise.
+ * src/Makefile.am: Move the man pages generation to doc/Makefile.am.
+ * gp-display-html/Makefile.am: Likewise.
+ * doc/gp-archive.texi: New file.
+ * doc/gp-collect-app.texi: New file.
+ * doc/gp-display-html.texi: New file.
+ * doc/gp-display-src.texi: New file.
+ * doc/gp-display-text.texi: New file.
+ * doc/gp-macros.texi: New file.
+ * doc/gprofng_ug.texi: New file.
+ * doc/Makefile.in: Rebuild.
+ * gp-display-html/Makefile.in: Rebuild.
+ * src/Makefile.in" Rebuild.
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Remove some unnecessary casts from ada-lang.c
+ I noticed some unnecessary casts to LONGEST in ada-lang.c. This patch
+ removes the ones I think are very clearly not needed. I'm checking
+ this in as obvious.
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/amdgpu: add follow fork and exec support
+ Prior to this patch, it's not possible for GDB to debug GPU code in fork
+ children or after an exec. The amd-dbgapi target attaches to processes
+ when an inferior appears due to a "run" or "attach" command, but not
+ after a fork or exec. This patch adds support for that, such that it's
+ possible to for an inferior to fork and for GDB to debug the GPU code in
+ the child.
+
+ To achieve that, use the inferior_forked and inferior_execd observers.
+
+ In the case of fork, we have nothing to do if `child_inf` is nullptr,
+ meaning that GDB won't debug the child. We also don't attach if the
+ inferior has vforked. We are already attached to the parent's address
+ space, which is shared with the child, so trying to attach would cause
+ problems. And anyway, the inferior can't do anything other than exec or
+ exit, it certainly won't start GPU kernels before exec'ing.
+
+ In the case of exec, we detach from the exec'ing inferior and attach to
+ the following inferior. This works regardless of whether they are the
+ same or not. If they are the same, meaning the execution continues in
+ the existing inferior, we need to do a detach/attach anyway, as
+ amd-dbgapi needs to be aware of the new address space created by the
+ exec.
+
+ Note that we use observers and not target_ops::follow_{fork,exec} here.
+ When the amd-dbgapi target is compiled in, it will attach (in the
+ amd_dbgapi_process_attach sense, not the ptrace sense) to native
+ inferiors when they appear, but won't push itself on the inferior's
+ target stack just yet. It only pushes itself if the inferior
+ initializes the ROCm runtime. So, if a non-GPU-using inferior calls
+ fork, an amd_dbgapi_target::follow_fork method would not get called.
+ Same for exec. A previous version of the code had the amd-dbgapi target
+ pushed all the time, in which case we could use the target methods. But
+ we prefer having the target pushed only when necessary, it's less
+ intrusive when doing native debugging that doesn't involve the GPU.
+
+ Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: switch to right inferior in fetch_inferior_event
+ The problem explained and fixed in the previous patch could have also
+ been fixed by this patch. But I think it's good change anyhow, that
+ could prevent future bugs, so here it is.
+
+ fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
+ of the process target of the inferior used to fetch the event. The idea is
+ that the event handling code will need to do some target calls, so we want to
+ switch to an inferior that has target target.
+
+ However, you can have two inferiors that share a process target, but with one
+ inferior having an additional target on top:
+
+ inf 1 inf 2
+ ----- -----
+ another target
+ process target process target
+ exec exec
+
+ Let's say inferior 2 is selected by do_target_wait and returns an event that is
+ really synthetized by "another target". This "another target" could be a
+ thread or record stratum target (in the case explained by the previous patch,
+ it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
+ layer). fetch_inferior_event will then switch to the first inferior with
+ "process target", so inferior 1. handle_signal_stop then tries to fetch the
+ thread's registers:
+
+ ecs->event_thread->set_stop_pc
+ (regcache_read_pc (get_thread_regcache (ecs->event_thread)));
+
+ This will try to get the thread's register by calling into the current target
+ stack, the stack of inferior 1. This is problematic because "another target"
+ might have a special fetch_registers implementation.
+
+ I think it would be a good idea to switch to the inferior for which the
+ even was reported, not just some inferior of the same process target.
+ This will ensure that any target call done before we eventually call
+ context_switch will be done on the full target stack that reported the
+ event.
+
+ Not all events are associated to an inferior though. For instance,
+ TARGET_WAITKIND_NO_RESUMED. In those cases, some targets return
+ null_ptid, some return minus_one_ptid (ideally the expected return value
+ should be clearly defined / documented). So, if the ptid returned is
+ either of these, switch to an arbitrary inferior with that process
+ target, as before.
+
+ Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make regcache::raw_update switch to right inferior
+ With the following patch, which teaches the amd-dbgapi target to handle
+ inferiors that fork, we end up with target stacks in the following
+ state, when an inferior that does not use the GPU forks an inferior that
+ eventually uses the GPU.
+
+ inf 1 inf 2
+ ----- -----
+ amd-dbgapi
+ linux-nat linux-nat
+ exec exec
+
+ When a GPU thread from inferior 2 hits a breakpoint, the following
+ sequence of events would happen, if it was not for the current patch.
+
+ - we start with inferior 1 as current
+ - do_target_wait_1 makes inferior 2 current, does a target_wait, which
+ returns a stop event for an amd-dbgapi wave (thread).
+ - do_target_wait's scoped_restore_current_thread restores inferior 1 as
+ current
+ - fetch_inferior_event calls switch_to_target_no_thread with linux-nat
+ as the process target, since linux-nat is officially the process
+ target of inferior 2. This makes inferior 1 the current inferior, as
+ it's the first inferior with that target.
+ - In handle_signal_stop, we have:
+
+ ecs->event_thread->suspend.stop_pc
+ = regcache_read_pc (get_thread_regcache (ecs->event_thread));
+
+ context_switch (ecs);
+
+ regcache_read_pc executes while inferior 1 is still the current one
+ (because it's before the `context_switch`). This is a problem,
+ because the regcache is for a ptid managed by the amd-dbgapi target
+ (e.g. (12345, 1, 1)), a ptid that does not make sense for the
+ linux-nat target. The fetch_registers target call goes directly
+ to the linux-nat target, which gets confused.
+ - We would then get an error like:
+
+ Couldn't get extended state status: No such process.
+
+ ... since linux-nat tries to do a ptrace call on tid 1.
+
+ GDB should switch to the inferior the ptid belongs to before doing the
+ target call to fetch registers, to make sure the call hits the right
+ target stack (it should be handled by the amd-dbgapi target in this
+ case). In fact the following patch does this change, and it would be
+ enough to fix this specific problem.
+
+ However, I propose to change regcache to make it switch to the right
+ inferior, if needed, before doing target calls. That makes the
+ interface as a whole more independent of the global context.
+
+ My first attempt at doing this was to find an inferior using the process
+ stratum target and the ptid that regcache already knows about:
+
+ gdb::optional<scoped_restore_current_thread> restore_thread;
+ inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
+ if (inf != current_inferior ())
+ {
+ restore_thread.emplace ();
+ switch_to_inferior_no_thread (inf);
+ }
+
+ However, this caused some failures in fork-related tests and gdbserver
+ boards. When we detach a fork child, we may create a regcache for the
+ child, but there is no corresponding inferior. For instance, to restore
+ the PC after a displaced step over the fork syscall. So
+ find_inferior_ptid would return nullptr, and
+ switch_to_inferior_no_thread would hit a failed assertion.
+
+ So, this patch adds to regcache the information "the inferior to switch
+ to to makes target calls". In typical cases, it will be the inferior
+ that matches the regcache's ptid. But in some cases, like the detached
+ fork child one, it will be another inferior (in this example, it will be
+ the fork parent inferior).
+
+ The problem that we witnessed was in regcache::raw_update specifically,
+ but I looked for other regcache methods doing target calls, and added
+ the same inferior switching code to raw_write too.
+
+ In the regcache constructor and in get_thread_arch_aspace_regcache,
+ "inf_for_target_calls" replaces the process_stratum_target parameter.
+ We suppose that the process stratum target that would be passed
+ otherwise is the same that is in inf_for_target_calls's target stack, so
+ we don't need to pass both in parallel. The process stratum target is
+ still used as a key in the `target_pid_ptid_regcache_map` map, but
+ that's it.
+
+ There is one spot that needs to be updated outside of the regcache code,
+ which is the path that handles the "restore PC after a displaced step in
+ a fork child we're about to detach" case mentioned above.
+
+ regcache_test_data needs to be changed to include full-fledged mock
+ contexts (because there now needs to be inferiors, not just targets).
+
+ Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add maybe_switch_inferior function
+ Add the maybe_switch_inferior function, which ensures that the given
+ inferior is the current one. Return an instantiated
+ scoped_restore_current_thread object only we actually needed to switch
+ inferior.
+
+ Returning a scoped_restore_current_thread requires it to be
+ move-constructible, so give it a move constructor.
+
+ Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove regcache::target
+ The regcache class takes a process_stratum_target and then exposes it
+ through regcache::target. But it doesn't use it itself, suggesting it
+ doesn't really make sense to put it there. The only user of
+ regcache::target is record_btrace_target::fetch_registers, but it might
+ as well just get it from the current target stack. This simplifies a
+ little bit a patch later in this series.
+
+ Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add inferior_forked observable
+ In the upcoming patch to support fork in the amd-dbgapi target, the
+ amd-dbgapi target will need to be notified of fork events through an
+ observer, to attach itself (attach in the amd-dbgapi sense, not ptrace
+ sense) to the new inferior / process.
+
+ The reason that this can't be done through target_ops::follow_fork is
+ that the amd-dbgapi target isn't pushed on the inferior's target stack
+ right away. It attaches itself to the process and only pushes itself on
+ its target stack if and when the inferior initializes the ROCm runtime.
+
+ If an inferior that is not using the ROCm runtime forks, we want to be
+ notified of it, so we can attach to the child, and catch if the child
+ starts using the ROCm runtime.
+
+ So, add a new observable and notify it in follow_fork_inferior. It will
+ be used later in this series.
+
+ Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: pass execing and following inferior to inferior_execd observers
+ The upcoming patch to support exec in the amd-dbgapi target needs to
+ detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi
+ to the inferior continuing the execution. They may or may not be the
+ same, depending on the `set follow-exec-mode` setting. But even if they
+ are the same, we need to do the detach / attach dance.
+
+ With the current observable signature, the observers only receive the
+ inferior in which execution continues (the "following" inferior).
+
+ Change the signature to pass both inferiors, and update all existing
+ observers.
+
+ Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Add 128-bit integer support to the Ada parser
+ This adds support for 128-bit integers to the Ada parser.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30188
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Remove some Ada parser helper functions
+ These helper functions in the Ada parser don't seem all that
+ worthwhile to me, so this patch removes them.
+
+ Add overload of fits_in_type
+ This adds an overload of fits_in_type that accepts a gdb_mpz. A
+ subsequent patch will use this.
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Add 128-bit integer support to the Rust parser
+ This adds support for 128-bit integers to the Rust parser.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Convert long_const_operation to use gdb_mpz
+ This changes long_const_operation to use gdb_mpz for its storage.
+
+2023-04-17 Tom Tromey <tromey@adacore.com>
+
+ Additions to gdb_mpz
+ In preparation for adding more 128-bit support to gdb, a few additions
+ to gdb_mpz are needed.
+
+ First, this adds a new 'as_integer_truncate' method. This method
+ works like 'as_integer' but does not require the value to fit in the
+ target type -- it just truncates.
+
+ Second, gdb_mpz::export_bits is changed to handle the somewhat unusual
+ situation of zero-length types. This can happen for a Rust '()' type;
+ but I think other languages have zero-bit integer types as well.
+
+ Finally, this adds some operator== overloads.
+
+2023-04-17 Nick Clifton <nickc@redhat.com>
+
+ Make the .rsrc section read only.
+ PR 30142
+ * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
+ * rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.
+
+2023-04-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle empty file name in .debug_line section
+ With DWARF 5, it's possible to produce an empty file name in the File Name
+ Table of the .debug_line section:
+ ...
+ The File Name Table (offset 0x112, lines 1, columns 2):
+ Entry Dir Name
+ 0 1 (indirect line string, offset: 0x2d):
+ ...
+
+ Currently, when gdb reads an exec containing such debug info, it segfaults:
+ ...
+ Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
+ 0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
+ gdb/dwarf2/read.c:18716
+ 18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
+ ...
+ because read_direct_string transforms "" into a nullptr, and we end up
+ dereferencing the nullptr.
+
+ Note that the behaviour of read_direct_string has been present since repo
+ creation.
+
+ Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
+ filenames.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+ PR symtab/30357
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
+
+2023-04-17 Nick Clifton <nickc@redhat.com>
+
+ Add support for the .gnu.sgstubs section to the linker for ARM/ELF based targets.
+ PR 30354
+ * emulparams/armelf.sh (OTHER_PLT_SECTIONS): Define in order to handle the .gnu.sgstubs section.
+
+2023-04-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: accept script argument for mi_make_breakpoint_pending
+ This commit changes mi_make_breakpoint_pending to accept the 'script'
+ and 'times' arguments.
+
+ I've then added a new test that makes use of 'scripts' in
+ gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.
+
+ There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
+ argument -- previously this argument was being ignored, but is now
+ used.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: avoid {"} pattern in lib/mi-support.exp
+ Commit:
+
+ commit c569a946f6925d3f210c3eaf74dcda56843350ef
+ Date: Fri Mar 24 10:45:37 2023 +0100
+
+ [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument
+
+ Introduced the use of {"} in mi-support.exp. There is absolutely
+ nothing wrong with this in any way. However, this is causing my
+ editor to get the syntax highlighting of this file wrong after this
+ point.
+
+ Maybe the real answer is to use a better editor, or fix my current
+ editor.... but I'm hoping I can instead take the lazy approach of just
+ changing {"} to "\"", which is handled fine, and means exactly the
+ same as far as I understand it.
+
+ There should be no change in what is tested after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-14 Luis Machado <luis.machado@arm.com>
+
+ pauth: Create new feature string for pauth to prevent crashing older gdb's
+ Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever
+ a target reports the pauth feature string in the target description and also
+ provide additional register outside of gdb's known and expected feature
+ strings.
+
+ This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out
+ there that will crash on connection to the above targets.
+
+ QEMU has postponed inclusion of the pauth feature string in version 8, and
+ instead we agreed to use a new feature name to prevent crashing those older
+ gdb's.
+
+ Initially there was a plan to backport a trivial fix all the way to gdb 9, but
+ given QEMU's choice, this is no longer needed.
+
+ This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used
+ by all targets going forward, except native linux gdb and gdbserver, for
+ backwards compatibility with older gdb's/gdbserver's.
+
+ gdb/gdbserver will still emit the old feature string for Linux since it doesn't
+ report additional system registers and thus doesn't cause a crash of older
+ gdb's. We can revisit this in the future once the problematic gdb's are likely
+ no longer in use.
+
+ I've added some documentation to explain the situation.
+
+2023-04-14 Luis Machado <luis.machado@arm.com>
+
+ debug registers: Add missing debug version entry for FEAT_Debugv8p8
+ The Arm Architecture Reference Manual defines debug version 0b1010 for
+ FEAT_Debugv8p8. This is used to identify valid hardware debug registers.
+
+ gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
+ teaches gdb about this new version.
+
+ No visible changes should happen as consequence of this patch, but in the
+ future gdb will be able to identify debug registers in newer hardware.
+
+ Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
+
+2023-04-14 Hui Li <lihui@loongson.cn>
+
+ gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp
+ (1) Description of problem
+
+ In the current code, when execute the following test on LoongArch:
+
+ $make check-gdb TESTS="gdb.base/dump.exp"
+ ```
+ FAIL: gdb.base/dump.exp: dump array as value, intel hex
+ FAIL: gdb.base/dump.exp: dump struct as value, intel hex
+ FAIL: gdb.base/dump.exp: dump array as memory, ihex
+ FAIL: gdb.base/dump.exp: dump struct as memory, ihex
+
+ ```
+ These tests passed on the X86_64,
+
+ (2) Root cause
+
+ On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
+ so dump ihex test failed.
+
+ gdb.base/dump.exp has the following code to check 64-bit address
+
+ ```
+ # Check the address of a variable. If it is bigger than 32-bit,
+ # assume our target has 64-bit addresses that are not supported by SREC,
+ # IHEX and TEKHEX. We skip those tests then.
+ set max_32bit_address "0xffffffff"
+ set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
+ if {${data_address} > ${max_32bit_address}} {
+ set is64bitonly "yes"
+ }
+ ```
+
+ We check the "&intarray" on different target as follow:
+
+ ```
+ $gdb gdb/testsuite/outputs/gdb.base/dump/dump
+ ...
+ (gdb) start
+ ...
+
+ On X86_64:
+ (gdb) print /x &intarray
+ $1 = 0x404060
+
+ On LoongArch:
+ (gdb) print /x &intarray
+ $1 = 0x120008068
+ ```
+ The variable address difference here is due to the link script
+ of linker.
+
+ ```
+ On X86_64:
+ $ld --verbose
+ ...
+ PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
+ . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
+
+ On LoongArch:
+ $ld --verbose
+ ...
+ PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
+ . = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;
+
+ ```
+
+ (3) How to fix
+
+ Because 64-bit variable address out of range for IHEX, it's not an
+ functional problem for LoongArch. Refer to the handling of 64-bit
+ targets in this testsuite, use the "is64bitonly" flag to skip those
+ tests for the target has 64-bit addresses.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-04-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add regression test for PR30325
+ Add regression tests for PR30325, one for the asm window and one for the
+ source window.
+
+ Use maint set tui-left-margin verbose to make the extend of the left margin
+ clear.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-04-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-13 Tom Tromey <tromey@adacore.com>
+
+ Avoid double-free with debuginfod
+ PR gdb/29257 points out a possible double free when debuginfod is in
+ use. Aside from some ugly warts in the symbol code (an ongoing
+ issue), the underlying issue in this particular case is that elfread.c
+ seems to assume that symfile_bfd_open will return NULL on error,
+ whereas in reality it throws an exception. As this code isn't
+ prepared for an exception, bad things result.
+
+ This patch fixes the problem by introducing a non-throwing variant of
+ symfile_bfd_open and using it in the affected places.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257
+
+2023-04-13 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update ARC specific linker tests.
+ All the tests are designed for a little-endian ARC system. Thus,
+ update the arc predicate in arc.exp, improve the matching pattern for
+ linker relaxation test, and add linker scripts to nps-1x tests.
+
+ arc: Update ARC's CFI tests.
+ The double store/loads instructions (e.g. STD/LDD) are not baseline
+ ARC ISA. The same holds for some short instructions. Update the
+ tests to use base ARC ISA.
+
+2023-04-13 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: Update GAS test
+
+2023-04-13 Alan Modra <amodra@gmail.com>
+
+ Preserve a few more bfd fields in check_format_matches
+ AOUT and COFF targets set symcount and start_address in their object_p
+ functions. If these are used anywhere then it would pay to save and
+ restore them so that a successful match gets the values expected
+ rather than that for a later unsuccessful target match.
+
+ * format.c (struct bfd_preserve): Move some fields. Add
+ symcount, read_only and start_address.
+ (bfd_preserve_save): Save..
+ (bfd_preserve_restore): ..and restore..
+ (bfd_reinit): ..and zero new fields.
+
+2023-04-13 Alan Modra <amodra@gmail.com>
+
+ Re: pe_ILF_object_p and bfd_check_format_matches
+ The last patch wasn't quite correct. bfd_preserve_restore also needs
+ to handle an in-memory to file backed transition, seen in a testcase
+ ILF object matching both pei-arm-little and pei-arm-wince-little.
+ There the first match is saved in preserve_match, and restored at the
+ end of the bfd_check_format_matches loop making the bfd in-memory. On
+ finding more than one match the function wants to restore the bfd back
+ to its original state with another bfd_preserve_restore call before
+ exiting with a bfd_error_file_ambiguously_recognized error.
+
+ It is also not correct to restore abfd->iostream unless the iovec
+ changes. abfd->iostream is a FILE* when using cache_iovec, and if
+ the file has been closed and reopened the iostream may have changed.
+
+ * format.c (io_reinit): New function.
+ (bfd_reinit, bfd_preserve_restore): Use it.
+
+2023-04-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Revert workaround in tui_source_window::show_line_number
+ The m_digits member of tui_source_window is documented as having semantics:
+ ...
+ /* How many digits to use when formatting the line number. This
+ includes the trailing space. */
+ ...
+
+ The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source
+ code") started printing two trailing spaces instead:
+ ...
+ - xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
+ + xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
+ ...
+
+ Now that PR30325 is fixed, this no longer has any effect.
+
+ Fix this by reverting to the original behaviour: print one trailing space
+ char.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-04-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix left margin in disassembly window
+ With a hello world a.out, and maint set tui-left-margin-verbose on, we have
+ this disassembly window:
+ ...
+ ┌───────────────────────────────────────────────────────────┐
+ │___ 0x555555555149 <main> endbr64 │
+ │___ 0x55555555514d <main+4> push %rbp │
+ │___ 0x55555555514e <main+5> mov %rsp,%rbp │
+ │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│
+ │___ 0x555555555158 <main+15> mov %rax,%rdi │
+ ...
+ Note the space between "B+>" and 0x555555555151. The space shows that a bit
+ of the left margin is not written, which is a problem because that location is
+ showing a character previously written, which happens to be a space, but also
+ may be something else, for instance a '[' as reported in PR tui/30325.
+
+ The problem is caused by confusion about the meaning of:
+ ...
+ #define TUI_EXECINFO_SIZE 4
+ ...
+
+ There's the meaning of defining the size of this zero-terminated char array:
+ ...
+ char element[TUI_EXECINFO_SIZE];
+ ...
+ which is used to print the "B+>" bit, which is 3 chars wide.
+
+ And there's the meaning of defining part of the size of the left margin:
+ ...
+ int left_margin () const
+ { return 1 + TUI_EXECINFO_SIZE + extra_margin (); }
+ ...
+ where it represents 4 chars.
+
+ The discrepancy between the two causes the space between "B+>" and
+ "0x555555555151".
+
+ Fix this by redefining TUI_EXECINFO_SIZE to 3, and using:
+ ...
+ char element[TUI_EXECINFO_SIZE + 1];
+ ...
+ such that we have:
+ ...
+ |B+>0x555555555151 <main+8> lea 0xeac(%rip),%rax │
+ ...
+
+ This changes the layout of the disassembly window back to what it was before
+ commit 9e820dec13e ("Use a curses pad for source and disassembly windows"),
+ the commit that introduced the PR30325 regression.
+
+ This also changes the source window from:
+ ...
+ │___000005__{ |
+ ...
+ to:
+ ...
+ │___000005_{ |
+ ...
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30325
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-04-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Add maint set/show tui-left-margin-verbose
+ The TUI has two types of windows derived from tui_source_window_base:
+ - tui_source_window (the source window), and
+ - tui_disasm_window (the disassembly window).
+
+ The two windows share a common concept: the left margin.
+
+ With a hello world a.out, we can see the source window:
+ ...
+ ┌─/home/vries/hello.c───────────────────────────────────────┐
+ │ 5 { │
+ │B+> 6 printf ("hello\n"); │
+ │ 7 return 0; │
+ │ 8 } │
+ │ 9 │
+ │
+ ...
+ where the left margin is the part holding "B+>" and the line number, and the
+ disassembly window:
+ ...
+ ┌───────────────────────────────────────────────────────────┐
+ │ 0x555555555149 <main> endbr64 │
+ │ 0x55555555514d <main+4> push %rbp │
+ │ 0x55555555514e <main+5> mov %rsp,%rbp │
+ │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│
+ │ 0x555555555158 <main+15> mov %rax,%rdi │
+ ...
+ where the left margin is just the bit holding "B+>".
+
+ Because the left margin contains some spaces, it's not clear where it starts
+ and ends, making it harder to observe problems related to it.
+
+ Add a new maintenance command "maint set tui-left-margin-verbose", that when
+ set to on replaces the spaces in the left margin with either '_' or '0',
+ giving us this for the source window:
+ ...
+ ┌─/home/vries/hello.c───────────────────────────────────────┐
+ │___000005__{ │
+ │B+>000006__ printf ("hello\n"); │
+ │___000007__ return 0; │
+ │___000008__} │
+ ...
+ and this for the disassembly window:
+ ...
+ ┌───────────────────────────────────────────────────────────┐
+ │___ 0x555555555149 <main> endbr64 │
+ │___ 0x55555555514d <main+4> push %rbp │
+ │___ 0x55555555514e <main+5> mov %rsp,%rbp │
+ │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│
+ │___ 0x555555555158 <main+15> mov %rax,%rdi │
+ ...
+
+ Note the space between "B+>" and 0x555555555151. The space shows that a bit
+ of the left margin is not written, a problem reported as PR tui/30325.
+
+ Specifically, PR tui/30325 is about the fact that the '[' character from the
+ string "[ No Assembly Available ]" ends up in that same spot:
+ ...
+ │B+>[0x555555555151 <main+8> lea 0xeac(%rip),%rax│
+ ...
+ which only happens for certain window widths.
+
+ The new command allows us to spot the problem with any window width.
+
+ Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces
+ between line numbers and source code"), we have:
+ ...
+ ┌─/home/vries/hello.c───────────────────────────────────────┐
+ │___000005_ { │
+ │B+>000006_ printf ("hello\n"); │
+ │___000007_ return 0; │
+ │___000008_ } │
+ ...
+ showing a similar problem at the space between '_' and '{'.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-04-12 Tom Tromey <tom@tromey.com>
+
+ Use SELF_CHECK in all unit tests
+ I noticed a few unit tests are using gdb_assert. I think this was an
+ older style, before SELF_CHECK was added. This patch switches them
+ over.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-04-12 Claudiu Zissulescu <claziss@gmail.com>
+
+ arc: remove faulty instructions
+ Clean not implemented ARC instruction from ARC instruction table.
+
+2023-04-12 Tom Tromey <tromey@adacore.com>
+
+ Use 'require' with gnatmake_version_at_least
+ I found a couple of tests that check gnatmake_version_at_least using
+ "if" where "require" would be a little cleaner. This patch converts
+ these.
+
+2023-04-12 YunQiang Su <yunqiang.su@cipunited.com>
+
+ MIPS: make mipsisa32 and mipsisa64 link more systematic
+ Introduce `static const struct mips_mach_extension mips_mach_32_64[]`
+ and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`,
+ to make mipsisa32 and mipsisa64 interlink more systemtic.
+
+ Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and
+ mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1),
+ so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64.
+
+ Note: R6 is not compatible with pre-R6.
+
+ bfd/ChangeLog:
+
+ * elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and
+ mipsisa64 interlink more systematic.
+ (mips_mach_32_64): new struct added.
+ (mips_mach_extends_32_64): new function added.
+
+2023-04-12 Nick Clifton <nickc@redhat.com>
+
+ Fix typos in the linker's documentation of the --enable-non-contiguous-regions option.
+
+2023-04-12 Alan Modra <amodra@gmail.com>
+
+ PR30326, uninitialised value in objdump compare_relocs
+ This is a fuzzing PR, with a testcase involving a SHF_ALLOC and
+ SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc
+ section. BFD doesn't handle compressed relocation sections, with most
+ of the code reading relocs using sh_size (often no bfd section is
+ created) but in the case of SHF_ALLOC dynamic relocs we had some code
+ using the bfd section size. This led to a mismatch, sh_size is
+ compressed, size is uncompressed, and from that some uninitialised
+ memory. Consistently using sh_size is enough to fix this PR, but I've
+ also added tests to exclude SHF_COMPRESSED reloc sections from
+ consideration.
+
+ PR 30362
+ * elf.c (bfd_section_from_shdr): Exclude reloc sections with
+ SHF_COMPRESSED flag from normal reloc processing.
+ (_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude
+ SHF_COMPRESSED sections from consideration. Use sh_size when
+ sizing to match slurp_relocs.
+ (_bfd_elf_canonicalize_dynamic_reloc): Likewise.
+ (_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size
+ plt relocs.
+ * 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.
+
+2023-04-12 Alan Modra <amodra@gmail.com>
+
+ ubsan: dwarf2.c:2232:7: runtime error: index 16 out of bounds
+ Except it isn't out of bounds because space for a larger array has
+ been allocated.
+
+ * dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
+ (alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.
+
+2023-04-12 Alan Modra <amodra@gmail.com>
+
+ Fail of x86_64 AMX-COMPLEX insns (Intel disassembly)
+ x86_64-w64-mingw32 pads sections.
+
+ * testsuite/gas/i386/x86-64-amx-complex-intel.d: Don't fail
+ due to nop padding.
+
+2023-04-12 Alan Modra <amodra@gmail.com>
+
+ pe_ILF_object_p and bfd_check_format_matches
+ If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the
+ bfd from being file backed to in-memory. This can have unfortunate
+ results for targets checked by bfd_check_format_matches after that
+ point as they will be matching against the created in-memory image
+ rather than the file. bfd_preserve_restore also has a problem if it
+ flips the BFD_IN_MEMORY flag, because the flag affects iostream
+ meaning and should be set if using _bfd_memory_iovec. To fix these
+ problems, save and restore iostream and iovec along with flags, and
+ modify bfd_reinit to make the bfd file backed again. Restoring the
+ iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY
+ (part of BFD_FLAGS_SAVED) to be removed.
+ One more detail: If restoring from file backed to in-memory then the
+ bfd needs to be forcibly removed from the cache lru list, since after
+ the bfd becomes in-memory a bfd_close will delete the bfd's memory
+ leaving the lru list pointing into freed memory.
+
+ * cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here..
+ (bfd_cache_lookup_worker): ..rather than here.
+ (bfd_cache_close): Comment.
+ * format.c (struct bfd_preserve): Add iovec and iostream fields.
+ (bfd_preserve_save): Save them..
+ (bfd_preserve_restore): ..and restore them, calling
+ bfd_cache_close if the iovec differs.
+ (bfd_reinit): Add preserve param. If the bfd has been flipped
+ to in-memory, reopen the file. Restore flags.
+ * peicode.h (pe_ILF_cleanup): New function.
+ (pe_ILF_object_p): Return it.
+ * bfd.c (BFD_FLAGS_SAVED): Delete.
+ * bfd-in2.h: Regenerate.
+
+2023-04-12 Alan Modra <amodra@gmail.com>
+
+ Comment typo fix
+
+2023-04-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-11 Nathan Sidwell <nathan@acm.org>
+
+ bfd: optimize bfd_elf_hash
+ The bfd_elf_hash loop is taken straight from the sysV document, but it
+ is poorly optimized. This refactoring removes about 5 x86 insns from
+ the 15 insn loop.
+
+ 1) The if (..) is meaningless -- we're xoring with that value, and of
+ course xor 0 is a nop. On x86 (at least) we actually compute the xor'd
+ value and then cmov. Removing the if test removes the cmov.
+
+ 2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits
+ will be shifted out in the next iteration. All we need to do is sink
+ a mask of those 4 bits out of the loop.
+
+ 3) anding with 0xf0 after shifting by 24 bits can allow betterin
+ encoding on RISC ISAs than masking with '0xf0 << 24' before shifting.
+ RISC ISAs often require materializing larger constants.
+
+ bfd/
+ * elf.c (bfd_elf_hash): Refactor to optimize loop.
+ (bfd_elf_gnu_hash): Refactor to use 32-bit type.
+
+2023-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, doc: correct argument description for info connections/inferiors
+ It said for 'info inferiors' and 'info connections' that the argument
+ could be 'a space separated list of inferior numbers' which is correct
+ but incomplete. In fact the arguments can be any space separated
+ combination of numbers and (ascending) ranges.
+
+ The beginning of the section now describes the ID list as a new keyword.
+
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-04-11 Nick Clifton <nickc@redhat.com>
+
+ Replace an assertion in the dwarf code with a warning message.
+ PR 30327
+ * dwarf.c (read_and_display_attr_value): Warn if the number of views is greater than the number of locations.
+
+ Fix an illegal memorty access when running gprof over corrupt data.
+ PR 30324
+ * symtab.c (symtab_finalize): Only change the end address if dst has been updated.
+
+ Fix an attempt to allocate an excessive amount of memory when parsing a corrupt DWARF file.
+ PR 30313
+ * dwarf.c (display_debug_lines_decoded): Check for an overlarge number of files or directories.
+
+ Fix a potential illegal memory access when displaying corrupt DWARF information.
+ PR 30312
+ * dwarf.c (prealloc_cu_tu_list): Always allocate at least one entry.
+
+ Fix an attempt to allocate an overlarge amount of memory when decoding a corrupt ELF format file.
+ PR 30311
+ * readelf.c (uncompress_section_contents): Check for a suspiciously large uncompressed size.
+
+ Fix illegal memory access when disassembling corrupt NFP binaries.
+ PR 30310
+ * nfp-dis.c (init_nfp6000_priv): Check that the output section exists.
+
+2023-04-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix indentation within print_one_breakpoint_location
+ Spotted some code in print_one_breakpoint_location that was not
+ indented correctly, this commit just changes the indentation.
+
+ There should be no user visible changes after this commit.
+
+2023-04-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix typo gdb_name_name -> gdb_test_name
+ Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name
+ instead of $gdb_test_name in one place. Fixed in this commit.
+
+2023-04-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: warn when converting h/w watchpoints to s/w
+ On amd64 (at least) if a user sets a watchpoint before the inferior
+ has started then GDB will assume that a hardware watchpoint can be
+ created.
+
+ When the inferior starts there is a chance that the watchpoint can't
+ actually be create as a hardware watchpoint, in which case (currently)
+ GDB will silently convert the watchpoint to a software watchpoint.
+ Here's an example session:
+
+ (gdb) p sizeof var
+ $1 = 4000
+ (gdb) watch var
+ Hardware watchpoint 1: var
+ (gdb) info watchpoints
+ Num Type Disp Enb Address What
+ 1 hw watchpoint keep y var
+ (gdb) starti
+ Starting program: /home/andrew/tmp/watch
+
+ Program stopped.
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) info watchpoints
+ Num Type Disp Enb Address What
+ 1 watchpoint keep y var
+ (gdb)
+
+ Notice that before the `starti` command the watchpoint is showing as a
+ hardware watchpoint, but afterwards it is showing as a software
+ watchpoint. Additionally, note that we clearly told the user we
+ created a hardware watchpoint:
+
+ (gdb) watch var
+ Hardware watchpoint 1: var
+
+ I think this is bad. I used `starti`, but if the user did `start` or
+ even `run` then the inferior is going to be _very_ slow, which will be
+ unexpected -- after all, we clearly told the user that we created a
+ hardware watchpoint, and the manual clearly says that hardware
+ watchpoints are fast (at least compared to s/w watchpoints).
+
+ In this patch I propose adding a new warning which will be emitted
+ when GDB downgrades a h/w watchpoint to s/w. The session now looks
+ like this:
+
+ (gdb) p sizeof var
+ $1 = 4000
+ (gdb) watch var
+ Hardware watchpoint 1: var
+ (gdb) info watchpoints
+ Num Type Disp Enb Address What
+ 1 hw watchpoint keep y var
+ (gdb) starti
+ Starting program: /home/andrew/tmp/watch
+ warning: watchpoint 1 downgraded to software watchpoint
+
+ Program stopped.
+ 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb) info watchpoints
+ Num Type Disp Enb Address What
+ 1 watchpoint keep y var
+ (gdb)
+
+ The important line is:
+
+ warning: watchpoint 1 downgraded to software watchpoint
+
+ It's not much, but hopefully it will be enough to indicate to the user
+ that something unexpected has occurred, and hopefully, they will not
+ be surprised when the inferior runs much slower than they expected.
+
+ I've added an amd64 only test in gdb.arch/, I didn't want to try
+ adding this as a global test as other architectures might be able to
+ support the watchpoint request in h/w.
+
+ Also the test is skipped for extended-remote boards as there's a
+ different set of options for limiting hardware watchpoints on remote
+ targets, and this test isn't about them.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-04-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: Support c.li in prologue unwinder
+ I was seeing some failures in gdb.threads/omp-par-scope.exp when run
+ on a riscv64 target. It turns out the cause of the problem is that I
+ didn't have debug information installed for libgomp.so, which this
+ test makes use of. The test requires GDB to backtrace through a
+ libgomp function, and the riscv prologue unwinder was failing to
+ unwind this particular stack frame.
+
+ The reason for the failure to unwind was that the function prologue
+ includes a c.li (compressed load immediate) instruction, and the riscv
+ prologue scanning unwinder doesn't know what to do with this
+ instruction, though the unwinder does understand c.lui (compressed
+ load unsigned immediate).
+
+ This commit adds support for c.li. After this GDB is able to unwind
+ through libgomp, and I no longer see any unexpected failures in
+ gdb.threads/omp-par-scope.exp.
+
+ I've also included a new test in gdb.arch/ which specifically checks
+ for our c.li support.
+
+2023-04-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-10 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb/dwarf: Fix MinGW build
+ Unfortunately MinGW doesn't support std::future yet, so this causes the
+ build to fail. Use GDB's version which provides a fallback for this case.
+
+ Tested for regressions on native aarch64-linux.
+
+ Approved-By: Tom Tromey <tromey@adacore.com>
+
+2023-04-10 Tom Tromey <tromey@adacore.com>
+
+ Handle unwinding from SEGV on Windows
+ PR win32/30255 points out that a call to a NULL function pointer will
+ leave gdb unable to "bt" on Windows.
+
+ I tracked this down to the amd64 windows unwinder. If we treat this
+ scenario as if it were a leaf function, unwinding works fine.
+
+ I'm not completely sure this patch is the best way. I considered
+ having it check for 'pc==0' -- but then I figured this could affect
+ any inaccessible PC, not just the special 0 value.
+
+ No test case because I can't run dejagnu tests on Windows. I tested
+ this by hand using the test case in the bug.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30255
+
+2023-04-10 Haochen Jiang <haochen.jiang@intel.com>
+
+ x86: Add inval tests for AMX instructions
+ gas/ChangeLog:
+
+ * testsuite/gas/i386/i386.exp: Run AMX-FP16 and AMX-COMPLEX
+ inval testcases.
+ * testsuite/gas/i386/x86-64-amx-inval.l: Add AMX-BF16 tests.
+ * testsuite/gas/i386/x86-64-amx-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-inval.l: New test.
+ * testsuite/gas/i386/x86-64-amx-complex-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-amx-fp16-inval.s: Ditto.
+
+2023-04-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-08 Philippe Blain <levraiphilippeblain@gmail.com>
+
+ Fix typos in previous commit of gdb.texinfo.
+ * gdb/doc/gdb.texinfo (Requirements): Fix typos.
+
+2023-04-08 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGS
+ This is a bug in the intersection of two obscure options that cannot
+ even be invoked from ld with a feature added to stop ld of the
+ same input file repeatedly from crashing the linker.
+
+ The latter fix involved tracking input files (internally to libctf) not
+ just with their input CU name but with a version of their input CU name
+ that was augmented with a numeric prefix if their linker input file name
+ was changed, to prevent distinct CTF dicts with the same cuname from
+ overwriting each other. (We can't use just the linker input file name
+ because one linker input can contain many CU dicts, particularly under
+ ld -r). If these inputs then produced conflicting types, those types
+ were emitted into similarly-named output dicts, so we needed similar
+ machinery to detect clashing output dicts and add a numeric prefix to
+ them as well.
+
+ This works fine, except that if you used the cu-mapping feature to force
+ double-linking of CTF (so that your CTF can be grouped into output dicts
+ larger than a single translation unit) and then also used
+ CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the
+ mapping to be created (even if empty), we did the creation of empty dicts
+ first, and then all the actual content got considered to be a clash. So
+ you ended up with a pile of useless empty dicts and then all the content
+ was in full dicts with the same names suffixed with a #0. This seems
+ likely to confuse consumers that use this facility.
+
+ Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking
+ is complete, not before it runs.
+
+ No impact on ld, which does not do cu-mapped links or pass
+ CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link().
+
+ libctf/
+ * ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one
+ already exists and we are making one for no input in particular.
+ (ctf_link): Emit empty CTF dicts corresponding to no input in
+ particular only after linkiing is complete.
+
+2023-04-08 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: propagate errors from parents correctly
+ CTF dicts have per-dict errno values: as with other errno values these
+ are set on error and left unchanged on success. This means that all
+ errors *must* set the CTF errno: if a call leaves it unchanged, the
+ caller is apt to find a previous, lingering error and misinterpret
+ it as the real error.
+
+ There are many places in libctf where we carry out operations on parent
+ dicts as a result of carrying out other user-requested operations on
+ child dicts (e.g. looking up information on a pointer to a type will
+ look up the type as well: the pointer might well be in a child and the
+ type it's a pointer to in the parent). Those operations on the parent
+ might fail; if they do, the error must be correctly reflected on the
+ child that the user-visible operation was carried out on. In many
+ places this was not happening.
+
+ So, audit and fix all those places. Add tests for as many of those
+ cases as possible so they don't regress.
+
+ libctf/
+ * ctf-create.c (ctf_add_slice): Use the original dict.
+ * ctf-lookup.c (ctf_lookup_variable): Propagate errors.
+ (ctf_lookup_symbol_idx): Likewise.
+ * ctf-types.c (ctf_member_next): Likewise.
+ (ctf_type_resolve_unsliced): Likewise.
+ (ctf_type_aname): Likewise.
+ (ctf_member_info): Likewise.
+ (ctf_type_rvisit): Likewise.
+ (ctf_func_type_info): Set the error on the right dict.
+ (ctf_type_encoding): Use the original dict.
+ * testsuite/libctf-writable/error-propagation.*: New test.
+
+2023-04-08 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, tests: do not assume host and target have identical field offsets
+ The newly-introduced libctf-lookup unnamed-field-info test checks
+ C compiler-observed field offsets against libctf-computed ones
+ by #including the testcase in the lookup runner as well as
+ generating CTF for it. This only works if the host, on which
+ the lookup runner is compiled and executed, is the same architecture as
+ the target, for which the CTF is generated: when crossing, the trick
+ may fail.
+
+ So pass down an indication of whether this is a cross into the
+ testsuite, and add a new no_cross flag to .lk files that is used to
+ suppress test execution when a cross-compiler is being tested.
+
+ libctf/
+ * Makefile.am (check_DEJAGNU): Pass down TEST_CROSS.
+ * Makefile.in: Regenerated.
+ * testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to
+ implement the new no_cross option.
+ * testsuite/libctf-lookup/unnamed-field-info.lk: Mark as
+ no_cross.
+
+2023-04-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-07 Tom Tromey <tromey@adacore.com>
+
+ Rewrite Ada symbol cache
+ In an experiment I'm trying, I needed Ada symbol cache entries to be
+ allocated with 'new'. This patch reimplements the symbol cache to use
+ the libiberty hash table and to use new and delete. A couple of other
+ minor cleanups are done.
+
+ Add Ada test case for break using a label
+ I noticed there aren't any Ada test cases for setting a breakpoint
+ using a label. This patch adds one, adapted from the AdaCore test
+ suite.
+
+ Use ui_out for "maint info frame-unwinders"
+ This changes "maint info frame-unwinders" to use ui-out. This makes
+ the table slightly nicer. In general I think it's better to use
+ ui-out for tables.
+
+2023-04-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add -q to INTERNAL_GDBFLAGS
+ Whenever we start gdb in the testsuite, we have the rather verbose:
+ ...
+ $ gdb
+ GNU gdb (GDB) 14.0.50.20230405-git
+ Copyright (C) 2023 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law.
+ Type "show copying" and "show warranty" for details.
+ This GDB was configured as "x86_64-pc-linux-gnu".
+ Type "show configuration" for configuration details.
+ For bug reporting instructions, please see:
+ <https://www.gnu.org/software/gdb/bugs/>.
+ Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+
+ For help, type "help".
+ Type "apropos word" to search for commands related to "word".
+ (gdb)
+ ...
+
+ This makes gdb.log longer than necessary and harder to read.
+
+ We do need to test that the output is produced, but that should be limited to
+ one or a few test-cases.
+
+ Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have:
+ ...
+ $ gdb -q
+ (gdb)
+ ...
+
+ Tested on x86_64-linux.
+
+2023-04-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing .note.GNU-stack in gdb.arch/amd64-disp-step-self-call.exp
+ For test-case gdb.arch/amd64-disp-step-self-call.exp I get:
+ ...
+ gdb compile failed, ld: warning: amd64-disp-step-self-call0.o: \
+ missing .note.GNU-stack section implies executable stack
+ ld: NOTE: This behaviour is deprecated and will be removed in a future \
+ version of the linker
+ ...
+
+ Fix this by adding the missing .note.GNU-stack.
+
+ Likewise for gdb.arch/i386-disp-step-self-call.exp.
+
+ Tested on x86_64-linux.
+
+2023-04-07 Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel AMX-COMPLEX
+ gas/ChangeLog:
+
+ * NEWS: Support Intel AMX-COMPLEX.
+ * config/tc-i386.c: Add amx_complex.
+ * doc/c-i386.texi: Document .amx_complex.
+ * testsuite/gas/i386/i386.exp: Run AMX-COMPLEX tests.
+ * testsuite/gas/i386/amx-complex-inval.l: New test.
+ * testsuite/gas/i386/amx-complex-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-bad.s: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex.d: Ditto.
+ * testsuite/gas/i386/x86-64-amx-complex.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (MOD_VEX_0F386C_X86_64_W_0): New.
+ (PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0): Ditto.
+ (X86_64_VEX_0F386C): Ditto.
+ (VEX_LEN_0F386C_X86_64_W_0_M_1): Ditto.
+ (VEX_W_0F386C_X86_64): Ditto.
+ (mod_table): Add MOD_VEX_0F386C_X86_64_W_0.
+ (prefix_table): Add PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0.
+ (x86_64_table): Add X86_64_VEX_0F386C.
+ (vex_len_table): Add VEX_LEN_0F386C_X86_64_W_0_M_1.
+ (vex_w_table): Add VEX_W_0F386C_X86_64.
+ * i386-gen.c (cpu_flag_init): Add CPU_AMX_COMPLEX_FLAGS and
+ CPU_ANY_AMX_COMPLEX_FLAGS.
+ * i386-init.h: Regenerated.
+ * i386-mnem.h: Ditto.
+ * i386-opc.h (CpuAMX_COMPLEX): New.
+ (i386_cpu_flags): Add cpuamx_complex.
+ * i386-opc.tbl: Add AMX-COMPLEX instructions.
+ * i386-tbl.h: Regenerated.
+
+2023-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: updates for gdb.arch/{amd64,i386}-disp-step-self-call.exp
+ This commit:
+
+ commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
+ Date: Wed Feb 22 12:15:34 2023 +0000
+
+ gdb: fix reg corruption from displaced stepping on amd64
+
+ Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and
+ gdb.arch/i386-disp-step-self-call.exp. These scripts contained a test
+ that included a stack address in the test name, this makes it harder
+ to compare results between runs.
+
+ This commit gives the tests proper names that doesn't include an
+ address.
+
+ Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were
+ writing 8-bytes rather than 4 in order to clear the return address
+ entry on the stack. This is also fixed in this commit.
+
+2023-04-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-06 Tom Tromey <tromey@adacore.com>
+
+ Use unique_xmalloc_ptr in apply_ext_lang_type_printers
+ This changes apply_ext_lang_type_printers to use unique_xmalloc_ptr,
+ removing some manual memory management. Regression tested on x86-64
+ Fedora 36.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-04-06 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC
+ Clang with LTO (clang -flto) garbage collects unused global variables,
+ Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with
+ hundreds of FAILs like so:
+
+ $ make check \
+ TESTS="gdb.*/align-*.exp" \
+ RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'"
+ ...
+ FAIL: gdb.base/align-c.exp: get integer valueof "a_char"
+ FAIL: gdb.base/align-c.exp: print _Alignof(char)
+ FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char"
+ FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char)
+ FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char"
+ ...
+
+ AIX GCC has the same issue, and there the easier way of adding
+ __attribute__((used)) to globals does not help.
+
+ So add explicit uses of all globals to the generated code.
+
+ For the C++ test, that reveals that the static variable members of the
+ generated structs are not defined anywhere, leading to undefined
+ references. Fixed by emitting initialization for all static members.
+
+ Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's
+ because the align-c++.exp testcase is compiling with the C compiler
+ driver. Fixed by passing "c++" as option to prepare_for_testing.
+
+ Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: run black code formatter on gdbarch_components.py
+ The following commit changed gdbarch_components.py but failed to
+ format it with black:
+
+ commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
+ Date: Wed Feb 22 12:15:34 2023 +0000
+
+ gdb: fix reg corruption from displaced stepping on amd64
+
+ This commit just runs black on the file and commits the result.
+
+ The change is just the addition of an extra "," -- there will be no
+ change to the generated source files after this commit.
+
+ There will be no user visible changes after this commit.
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: allow Frame.read_var to accept named arguments
+ This commit allows Frame.read_var to accept named arguments, and also
+ improves (I think) some of the error messages emitted when values of
+ the wrong type are passed to this function.
+
+ The read_var method takes two arguments, one a variable, which is
+ either a gdb.Symbol or a string, while the second, optional, argument
+ is always a gdb.Block.
+
+ I'm now using 'O!' as the format specifier for the second argument,
+ which allows the argument type to be checked early on. Currently, if
+ the second argument is of the wrong type then we get this error:
+
+ (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ RuntimeError: Second argument must be block.
+ Error while executing Python code.
+ (gdb)
+
+ After this commit, we now get an error like this:
+
+ (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ TypeError: argument 2 must be gdb.Block, not str
+ Error while executing Python code.
+ (gdb)
+
+ Changes are:
+
+ 1. Exception type is TypeError not RuntimeError, this is unfortunate
+ as user code _could_ be relying on this, but I think the improvement
+ is worth the risk, user code relying on the exact exception type is
+ likely to be pretty rare,
+
+ 2. New error message gives argument position and expected argument
+ type, as well as the type that was passed.
+
+ If the first argument, the variable, has the wrong type then the
+ previous exception was already a TypeError, however, I've updated the
+ text of the exception to more closely match the "standard" error
+ message we see above. If the first argument has the wrong type then
+ before this commit we saw this:
+
+ (gdb) python print(gdb.selected_frame().read_var(123))
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ TypeError: Argument must be a symbol or string.
+ Error while executing Python code.
+ (gdb)
+
+ And after we see this:
+
+ (gdb) python print(gdb.selected_frame().read_var(123))
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ TypeError: argument 1 must be gdb.Symbol or str, not int
+ Error while executing Python code.
+ (gdb)
+
+ For existing code that doesn't use named arguments and doesn't rely on
+ exceptions, there will be no changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: convert Frame.read_register to take named arguments
+ Following on from the previous commit, this updates
+ Frame.read_register to accept named arguments. As with the previous
+ commit there's no huge benefit for the users in accepting named
+ arguments here -- this function only takes a single argument after
+ all.
+
+ But I do think it is worth keeping Frame.read_register method in sync
+ with the PendingFrame.read_register method, this allows for the
+ possibility that the user has some code that can operate on either a
+ Frame or a Pending frame.
+
+ Minor update to allow for named arguments, and an extra test to check
+ the new functionality.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: have PendingFrame methods accept keyword arguments
+ Update the two gdb.PendingFrame methods gdb.PendingFrame.read_register
+ and gdb.PendingFrame.create_unwind_info to accept keyword arguments.
+
+ There's no huge benefit for making this change, both of these methods
+ only take a single argument, so it is (maybe) less likely that a user
+ will take advantage of the keyword arguments in these cases, but I
+ think it's nice to be consistent, and I don't see any particular draw
+ backs to making this change.
+
+ For PendingFrame.read_register I've changed the argument name from
+ 'reg' to 'register' in the documentation and used 'register' as the
+ argument name in GDB. My preference for APIs is to use full words
+ where possible, and given we didn't support named arguments before
+ this change should not break any existing code.
+
+ There should be no user visible changes (for existing code) after this
+ commit.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: have UnwindInfo.add_saved_register accept named args
+ Update gdb.UnwindInfo.add_saved_register to accept named keyword
+ arguments.
+
+ As part of this update we now use gdb_PyArg_ParseTupleAndKeywords
+ instead of PyArg_UnpackTuple to parse the function arguments.
+
+ By switching to gdb_PyArg_ParseTupleAndKeywords, we can now use 'O!'
+ as the argument format for the function's value argument. This means
+ that we can check the argument type (is gdb.Value) as part of the
+ argument processing rather than manually performing the check later in
+ the function. One result of this is that we now get a better error
+ message (at least, I think so). Previously we would get something
+ like:
+
+ ValueError: Bad register value
+
+ Now we get:
+
+ TypeError: argument 2 must be gdb.Value, not XXXX
+
+ It's unfortunate that the exception type changed, but I think the new
+ exception type actually makes more sense.
+
+ My preference for argument names is to use full words where that's not
+ too excessive. As such, I've updated the name of the argument from
+ 'reg' to 'register' in the documentation, which is the argument name
+ I've made GDB look for here.
+
+ For existing unwinder code that doesn't throw any exceptions nothing
+ should change with this commit. It is possible that a user has some
+ code that throws and catches the ValueError, and this code will break
+ after this commit, but I think this is going to be sufficiently rare
+ that we can take the risk here.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix reg corruption from displaced stepping on amd64
+ This commit aims to address a problem that exists with the current
+ approach to displaced stepping, and was identified in PR gdb/22921.
+
+ Displaced stepping is currently supported on AArch64, ARM, amd64,
+ i386, rs6000 (ppc), and s390. Of these, I believe there is a problem
+ with the current approach which will impact amd64 and ARM, and can
+ lead to random register corruption when the inferior makes use of
+ asynchronous signals and GDB is using displaced stepping.
+
+ The problem can be found in displaced_step_buffers::finish in
+ displaced-stepping.c, and is this; after GDB tries to perform a
+ displaced step, and the inferior stops, GDB classifies the stop into
+ one of two states, either the displaced step succeeded, or the
+ displaced step failed.
+
+ If the displaced step succeeded then gdbarch_displaced_step_fixup is
+ called, which has the job of fixing up the state of the current
+ inferior as if the step had not been performed in a displaced manner.
+ This all seems just fine.
+
+ However, if the displaced step is considered to have not completed
+ then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB
+ remains in displaced_step_buffers::finish and just performs a minimal
+ fixup which involves adjusting the program counter back to its
+ original value.
+
+ The problem here is that for amd64 and ARM setting up for a displaced
+ step can involve changing the values in some temporary registers. If
+ the displaced step succeeds then this is fine; after the step the
+ temporary registers are restored to their original values in the
+ architecture specific code.
+
+ But if the displaced step does not succeed then the temporary
+ registers are never restored, and they retain their modified values.
+
+ In this context a temporary register is simply any register that is
+ not otherwise used by the instruction being stepped that the
+ architecture specific code considers safe to borrow for the lifetime
+ of the instruction being stepped.
+
+ In the bug PR gdb/22921, the amd64 instruction being stepped is
+ an rip-relative instruction like this:
+
+ jmp *0x2fe2(%rip)
+
+ When we displaced step this instruction we borrow a register, and
+ modify the instruction to something like:
+
+ jmp *0x2fe2(%rcx)
+
+ with %rcx having its value adjusted to contain the original %rip
+ value.
+
+ Now if the displaced step does not succeed, then %rcx will be left
+ with a corrupted value. Obviously corrupting any register is bad; in
+ the bug report this problem was spotted because %rcx is used as a
+ function argument register.
+
+ And finally, why might a displaced step not succeed? Asynchronous
+ signals provides one reason. GDB sets up for the displaced step and,
+ at that precise moment, the OS delivers a signal (SIGALRM in the bug
+ report), the signal stops the inferior at the address of the displaced
+ instruction. GDB cancels the displaced instruction, handles the
+ signal, and then tries again with the displaced step. But it is that
+ first cancellation of the displaced step that causes the problem; in
+ that case GDB (correctly) sees the displaced step as having not
+ completed, and so does not perform the architecture specific fixup,
+ leaving the register corrupted.
+
+ The reason why I think AArch64, rs600, i386, and s390 are not effected
+ by this problem is that I don't believe these architectures make use
+ of any temporary registers, so when a displaced step is not completed
+ successfully, the minimal fix up is sufficient.
+
+ On amd64 we use at most one temporary register.
+
+ On ARM, looking at arm_displaced_step_copy_insn_closure, we could
+ modify up to 16 temporary registers, and the instruction being
+ displaced stepped could be expanded to multiple replacement
+ instructions, which increases the chances of this bug triggering.
+
+ This commit only aims to address the issue on amd64 for now, though I
+ believe that the approach I'm proposing here might be applicable for
+ ARM too.
+
+ What I propose is that we always call gdbarch_displaced_step_fixup.
+
+ We will now pass an extra argument to gdbarch_displaced_step_fixup,
+ this a boolean that indicates whether GDB thinks the displaced step
+ completed successfully or not.
+
+ When this flag is false this indicates that the displaced step halted
+ for some "other" reason. On ARM GDB can potentially read the
+ inferior's program counter in order figure out how far through the
+ sequence of replacement instructions we got, and from that GDB can
+ figure out what fixup needs to be performed.
+
+ On targets like amd64 the problem is slightly easier as displaced
+ stepping only uses a single replacement instruction. If the displaced
+ step didn't complete the GDB knows that the single instruction didn't
+ execute.
+
+ The point is that by always calling gdbarch_displaced_step_fixup, each
+ architecture can now ensure that the inferior state is fixed up
+ correctly in all cases, not just the success case.
+
+ On amd64 this ensures that we always restore the temporary register
+ value, and so bug PR gdb/22921 is resolved.
+
+ In order to move all architectures to this new API, I have moved the
+ minimal roll-back version of the code inside the architecture specific
+ fixup functions for AArch64, rs600, s390, and ARM. For all of these
+ except ARM I think this is good enough, as no temporaries are used all
+ that's needed is the program counter restore anyway.
+
+ For ARM the minimal code is no worse than what we had before, though I
+ do consider this architecture's displaced-stepping broken.
+
+ I've updated the gdb.arch/amd64-disp-step.exp test to cover the
+ 'jmpq*' instruction that was causing problems in the original bug, and
+ also added support for testing the displaced step in the presence of
+ asynchronous signal delivery.
+
+ I've also added two new tests (for amd64 and i386) that check that GDB
+ can correctly handle displaced stepping over a single instruction that
+ branches to itself. I added these tests after a first version of this
+ patch relied too much on checking the program-counter value in order
+ to see if the displaced instruction had executed. This works fine in
+ almost all cases, but when an instruction branches to itself a pure
+ program counter check is not sufficient. The new tests expose this
+ problem.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22921
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-04-06 Alan Modra <amodra@gmail.com>
+
+ Re: objcopy write_debugging_info memory leaks
+ Oops, tried to free too much
+
+ * wrstabs.c (write_stabs_in_sections_debugging_info): Don't
+ free strings.
+
+2023-04-06 Alan Modra <amodra@gmail.com>
+
+ objdump print_debugging_info memory leaks
+ Fix memory leaks and do a general tidy of the code for printing coff
+ and stabs debug.
+
+ * prdbg.c: Delete unnneeded forward function declarations.
+ Delete unnecessary casts throughout. Free all strings
+ returned from pop_type throughout file.
+ (struct pr_stack): Delete "num_parents". Replace tests for
+ "num_parents" non-zero with tests of "parents" non-NULL
+ throughout. Free "parents" before assigning, and set to NULL
+ after freeing. Remove const from "method". Always strdup
+ strings assigned to method, and free before assigning.
+ (print_debugging_info): Free info.stack and info.filename.
+
+2023-04-06 Alan Modra <amodra@gmail.com>
+
+ objdump -g on gcc COFF/PE files
+ objdump -g can't be used much. Trying to dump PE files invariably
+ seems to run into "debug_name_type: no current file" or similar
+ errors, because parse_coff expects a C_FILE symbol to be the first
+ symbol. Dumping -gstabs output works since the N_SO stab is present.
+ Pre-setting the file name won't hurt stabs dumping.
+
+ * rddbg.c (read_debugging_info): Call debug_set_filename.
+
+2023-04-06 Alan Modra <amodra@gmail.com>
+
+ gas/write.c use better types
+ A tiny tidy.
+
+ * write.c (frags_chained): Make it a bool.
+ (n_fixups): Make it unsigned.
+
+2023-04-06 Alan Modra <amodra@gmail.com>
+
+ objcopy write_debugging_info memory leaks
+ The old stabs code didn't bother too much about freeing memory.
+ This patch corrects that and avoids some dubious copying of strings.
+
+ * objcopy.c (write_debugging_info): Free both strings and
+ syms on failure to create sections.
+ * wrstabs.c: Delete unnecessary forward declarations and casts
+ throughout file.
+ (stab_write_symbol_and_free): New function. Use it
+ throughout, simplifying return paths.
+ (stab_push_string): Don't strdup string. Use it thoughout
+ for malloced strings.
+ (stab_push_string_dup): New function. Use it throughout for
+ strings in auto buffers.
+ (write_stabs_in_sections_debugging_info): Free malloced memory.
+ (stab_enum_type): Increase buffer sizing for worst case.
+ (stab_range_type, stab_array_type): Reduce buffer size.
+ (stab_set_type): Likewise.
+ (stab_method_type): Free args on error return. Correct
+ buffer size.
+ (stab_struct_field): Fix memory leaks.
+ (stab_class_static_member, stab_class_baseclass): Likewise.
+ (stab_start_class_type): Likewise. Correct buffer size.
+ (stab_class_start_method): Correct buffer size.
+ (stab_class_method_var): Free memory on error return.
+ (stab_start_function): Fix "rettype" memory leak.
+
+2023-04-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb/testsuite: Default to assembler's preferred debug format in asm-source.exp
+ The stabs debug format is obsolete and there's no reason to think that
+ toolchains still have good support for it. Therefore, if a specific debug
+ format wasn't set in asm-source.exp then leave it to the assembler to
+ decide which one to use.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb: Fix reading of partial symtabs in dbxread.c
+ After commit 9675da25357c ("Use unrelocated_addr in minimal symbols"),
+ aarch64-linux started failing gdb.asm/asm-source.exp:
+
+ Running /home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.asm/asm-source.exp ...
+ PASS: gdb.asm/asm-source.exp: f at main
+ PASS: gdb.asm/asm-source.exp: n at main
+ PASS: gdb.asm/asm-source.exp: next over macro
+ FAIL: gdb.asm/asm-source.exp: step into foo2
+ PASS: gdb.asm/asm-source.exp: info target
+ PASS: gdb.asm/asm-source.exp: info symbol
+ PASS: gdb.asm/asm-source.exp: list
+ PASS: gdb.asm/asm-source.exp: search
+ FAIL: gdb.asm/asm-source.exp: f in foo2
+ FAIL: gdb.asm/asm-source.exp: n in foo2 (the program exited)
+ FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
+ FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
+ PASS: gdb.asm/asm-source.exp: s 2
+ PASS: gdb.asm/asm-source.exp: n 2
+ FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
+ PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
+ FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
+ FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
+ PASS: gdb.asm/asm-source.exp: info sources
+ FAIL: gdb.asm/asm-source.exp: info line
+ FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
+ FAIL: gdb.asm/asm-source.exp: return from foo2
+ PASS: gdb.asm/asm-source.exp: look at global variable
+ PASS: gdb.asm/asm-source.exp: x/i &globalvar
+ PASS: gdb.asm/asm-source.exp: disassem &globalvar, (int *) &globalvar+1
+ PASS: gdb.asm/asm-source.exp: look at static variable
+ PASS: gdb.asm/asm-source.exp: x/i &staticvar
+ PASS: gdb.asm/asm-source.exp: disassem &staticvar, (int *) &staticvar+1
+ PASS: gdb.asm/asm-source.exp: look at static function
+
+ The problem is simple: a pair of parentheses was removed from the
+ expression calculating text_end and thus text_size was only added if
+ lowest_text_address wasn't equal to -1.
+
+ This patch restores the previous behaviour and fixes the testcase.
+ Tested on native aarch64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-05 Eli Zaretskii <eliz@gnu.org>
+
+ Improve documentation of GDB build requirements and options
+ MPFR is now mandatory, so its previous description in Requirements
+ was inappropriate and out of place. In addition, the description
+ of how to go about specifying 'configure' time options for
+ building with libraries was highly repetitive. Some of the text
+ was also outdated and used wrong markup.
+
+ Original patch and suggestions from Philippe Blain
+ <levraiphilippeblain@gmail.com>.
+
+ ChangeLog:
+ 2023-04-05 Eli Zaretskii <eliz@gnu.org>
+
+ * gdb/doc/gdb.texinfo (Requirements, Configure Options): Update and
+ rearrange; improve and fix markup.
+
+2023-04-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb, doc: add the missing '-gid' option to 'info threads'
+ The 'info threads' command does not show the '-gid' option
+ in the syntax. Add the option. The flag is already explained
+ in the command description and used in the examples.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-04-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb: boolify 'should_print_thread'
+ Convert the return type of 'should_print_thread' from int to bool.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make find_thread_ptid a process_stratum_target method
+ Make find_thread_ptid (the overload that takes a process_stratum_target)
+ a method of process_stratum_target.
+
+ Change-Id: Ib190a925a83c6b93e9c585dc7c6ab65efbdd8629
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make find_thread_ptid an inferior method
+ Make find_thread_ptid (the overload that takes an inferior) a method of
+ struct inferior.
+
+ Change-Id: Ie5b9fa623ff35aa7ddb45e2805254fc8e83c9cd4
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-04-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-04 Jan Beulich <jbeulich@suse.com>
+
+ bfd+ld: when / whether to generate .c files
+ Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re-
+ generated in x86-only builds, I came across 769a27ade588 ("Re: bfd
+ BLD-POTFILES.in dependencies"). I think this went slightly too far, as
+ outside of maintainer mode dependencies will cause the subset of files
+ to be (re-)generated which are actually needed for the build.
+ Generating them all is only needed when wanting to update certain files
+ under bfd/po/, i.e. in maintainer mode.
+
+ In the course of looking around in an attempt to try to understand how
+ things are meant to work, I further noticed that ld has got things
+ slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't
+ quite right (the output doesn't change when any of the enumerated files
+ changes; it's the mere presence which matters); like in bfd it looks
+ like we would better extend BUILT_SOURCES accordingly.
+
+ Furthermore it became apparent that ld fails to enumerate the .c files
+ generated from the .l and .y ones. While in their absence it was benign
+ whether translatable strings in the source files were actually marked as
+ such, this now becomes relevant. Mark respective strings at the same
+ time, but skipping ones which look to be of interest for debugging
+ purposes only (e.g. such used by printf() enclosed in #ifdef TRACE).
+
+2023-04-04 Alan Modra <amodra@gmail.com>
+
+ Use bfd_alloc memory for read_debugging_info storage
+ Trying to free malloc'd memory used by the stabs and coff debug info
+ parsers is complicated, and traversing the trees generated requires a
+ lot of code. It's better to bfd_alloc the memory which allows it all
+ to be freed without fuss when the bfd is closed. In the process of
+ doing this I reverted most of commit a6336913332.
+
+ Some of the stabs handling code grows arrays of pointers with realloc,
+ to deal with arbitrary numbers of fields, function args, etc. The
+ code still does that but copies over to bfd_alloc memory when
+ finished. The alternative is to parse twice, once to size, then again
+ to populate the arrays. I think that complication is unwarranted.
+
+ Note that there is a greater than zero chance this patch breaks
+ something, eg. that I missed an attempt to free obj_alloc memory.
+ Also it seems there are no tests in the binutils testsuite aimed at
+ exercising objdump --debugging.
+
+ * budbg.h (finish_stab, parse_stab): Update prototypes
+ * debug.c: Include bucomm.h.
+ (struct debug_handle): Add "abfd" field.
+ (debug_init): Add "abfd" param. bfd_alloc handle.
+ (debug_xalloc, debug_xzalloc): New functions. Use throughout
+ in place of xmalloc and memset.
+ (debug_start_source): Remove "name_used" param.
+ * debug.h (debug_init, debug_start_source): Update prototypes.
+ (debug_xalloc, debug_xzalloc): Declare.
+ * objcopy.c (copy_object): Don't free dhandle.
+ * objdump.c (dump_bfd): Likewise.
+ * rdcoff.c (coff_get_slot): Add dhandle arg. debug_xzalloc
+ memory in place of xcalloc. Update callers.
+ (parse_coff_struct_type): Don't leak on error return. Copy
+ fields over to debug_xalloc memory.
+ (parse_coff_enum_type): Copy names and vals over the
+ debug_xalloc memory.
+ * rddbg.c (read_debugging_info): Adjust debug_init call.
+ Don't free dhandle.
+ (read_section_stabs_debugging_info): Don't free shandle.
+ Adjust parse_stab call. Call finish_stab on error return.
+ (read_symbol_stabs_debugging_info): Similarly.
+ * stabs.c (savestring): Delete unnecessary forward declaration.
+ Add dhandle param. debug_xalloc memory. Update callers.
+ (start_stab): Delete unnecessary casts.
+ (finish_stab): Add "emit" param. Free file_types, so_string,
+ and stabs handle.
+ (parse_stab): Delete string_used param. Revert code dealing
+ with string_used. Copy so_string passed to debug_set_filename
+ and stored as main_filename to debug_xalloc memory. Similarly
+ for string passed to debug_start_source and push_bincl. Copy
+ args to debug_xalloc memory. Don't leak args.
+ (parse_stab_enum_type): Copy names and values to debug_xalloc
+ memory. Don't free name.
+ (parse_stab_struct_type): Don't free fields.
+ (parse_stab_baseclasses): Delete unnecessary cast.
+ (parse_stab_struct_fields): Return debug_xalloc fields.
+ (parse_stab_cpp_abbrev): Use debug_xalloc for _vb$ type name.
+ (parse_stab_one_struct_field): Don't free name.
+ (parse_stab_members): Copy variants and methods to
+ debug_xalloc memory. Don't free name or argtypes.
+ (parse_stab_argtypes): Use debug_xalloc memory for physname
+ and args.
+ (push_bincl): Add dhandle param. Use debug_xalloc memory.
+ (stab_record_variable): Use debug_xalloc memory.
+ (stab_emit_pending_vars): Don't free var list.
+ (stab_find_slot): Add dhandle param. Use debug_xzalloc
+ memory. Update all callers.
+ (stab_find_tagged_type): Don't free name. Use debug_xzalloc.
+ (stab_demangle_qualified): Don't free name.
+ (stab_demangle_template): Don't free s1.
+ (stab_demangle_args): Tidy pvarargs refs. Copy *pargs on
+ success to debug_xalloc memory, free on failure.
+ (stab_demangle_fund_type): Don't free name.
+ (stab_demangle_v3_arglist): Copy args to debug_xalloc memory.
+ Don't free dt.
+
+2023-04-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-03 Tom Tromey <tromey@adacore.com>
+
+ Add readMemory and writeMemory requests to DAP
+ This adds the DAP readMemory and writeMemory requests. A small change
+ to the evaluation code is needed in order to test this -- this is one
+ of the few ways for a client to actually acquire a memory reference.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: cleanup around some set_momentary_breakpoint_at_pc calls
+ I noticed a couple of places in infrun.c where we call
+ set_momentary_breakpoint_at_pc, and then set the newly created
+ breakpoint's thread field, these are in:
+
+ insert_exception_resume_breakpoint
+ insert_exception_resume_from_probe
+
+ Function set_momentary_breakpoint_at_pc calls
+ set_momentary_breakpoint, which always creates the breakpoint as
+ thread-specific for the current inferior_thread().
+
+ The two insert_* functions mentioned above take an arbitrary
+ thread_info* as an argument and set the breakpoint::thread to hold the
+ thread number of that arbitrary thread.
+
+ However, the insert_* functions store the breakpoint pointer within
+ the current inferior_thread(), so we know that the thread being passed
+ in must be the currently selected thread.
+
+ What this means is that we can:
+
+ 1. Assert that the thread being passed in is the currently selected
+ thread, and
+
+ 2. No longer adjust the breakpoint::thread field, this will already
+ have been set correctly be calling set_momentary_breakpoint_at_pc.
+
+ There should be no user visible changes after this commit.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't always print breakpoint location after failed condition check
+ Consider the following session:
+
+ (gdb) list some_func
+ 1 int
+ 2 some_func ()
+ 3 {
+ 4 int *p = 0;
+ 5 return *p;
+ 6 }
+ 7
+ 8 void
+ 9 foo ()
+ 10 {
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing condition for breakpoint 1:
+ The program being debugged stopped while in a function called from GDB.
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+
+ Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ (gdb)
+
+ What happens here is the breakpoint condition includes a call to an
+ inferior function, and the inferior function segfaults. We can see
+ that GDB reports the segfault, and then gives an error message that
+ indicates that an inferior function call was interrupted.
+
+ After this GDB appears to report that it is stopped at Breakpoint 1,
+ inside some_func.
+
+ I find this second stop report a little confusing. While it is true
+ that GDB stopped as a result of hitting breakpoint 1, I think the
+ message GDB currently prints might give the impression that GDB is
+ actually stopped at a location of breakpoint 1, which is not the case.
+
+ Also, I find the second stop message draws attention away from
+ the "Program received signal SIGSEGV, Segmentation fault" stop
+ message, and this second stop might be thought of as replacing in
+ someway the earlier message.
+
+ In short, I think things would be clearer if the second stop message
+ were not reported at all, so the output should, I think, look like
+ this:
+
+ (gdb) list some_func
+ 1 int
+ 2 some_func ()
+ 3 {
+ 4 int *p = 0;
+ 5 return *p;
+ 6 }
+ 7
+ 8 void
+ 9 foo ()
+ 10 {
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing condition for breakpoint 1:
+ The program being debugged stopped while in a function called from GDB.
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+ (gdb)
+
+ The user can still find the number of the breakpoint that triggered
+ the initial stop in this line:
+
+ Error in testing condition for breakpoint 1:
+
+ But there's now only one stop reason reported, the SIGSEGV, which I
+ think is much clearer.
+
+ To achieve this change I set the bpstat::print field when:
+
+ (a) a breakpoint condition evaluation failed, and
+
+ (b) the $pc of the thread changed during condition evaluation.
+
+ I've updated the existing tests that checked the error message printed
+ when a breakpoint condition evaluation failed.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: avoid repeated signal reporting during failed conditional breakpoint
+ Consider the following case:
+
+ (gdb) list some_func
+ 1 int
+ 2 some_func ()
+ 3 {
+ 4 int *p = 0;
+ 5 return *p;
+ 6 }
+ 7
+ 8 void
+ 9 foo ()
+ 10 {
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing breakpoint condition:
+ The program being debugged was signaled while in a function called from GDB.
+ GDB remains in the frame where the signal was received.
+ To change this behavior use "set unwindonsignal on".
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+
+ Program received signal SIGSEGV, Segmentation fault.
+
+ Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ (gdb)
+
+ Notice that this line:
+
+ Program received signal SIGSEGV, Segmentation fault.
+
+ Appears twice in the output. The first time is followed by the
+ current location. The second time is a little odd, why do we print
+ that?
+
+ Printing that line is controlled, in part, by a global variable,
+ stopped_by_random_signal. This variable is reset to zero in
+ handle_signal_stop, and is set if/when GDB figures out that the
+ inferior stopped due to some random signal.
+
+ The problem is, in our case, GDB first stops at the breakpoint for
+ foo, and enters handle_signal_stop and the stopped_by_random_signal
+ global is reset to 0.
+
+ Later within handle_signal_stop GDB calls bpstat_stop_status, it is
+ within this function (via bpstat_check_breakpoint_conditions) that the
+ breakpoint condition is checked, and, we end up calling the inferior
+ function (some_func in our example above).
+
+ In our case above the thread performing the inferior function call
+ segfaults in some_func. GDB catches the SIGSEGV and handles the stop,
+ this causes us to reenter handle_signal_stop. The global variable
+ stopped_by_random_signal is updated, this time it is set to true
+ because the thread stopped due to SIGSEGV. As a result of this we
+ print the first instance of the line (as seen above in the example).
+
+ Finally we unwind GDB's call stack, the inferior function call is
+ complete, and we return to the original handle_signal_stop. However,
+ the stopped_by_random_signal global is still carrying the value as
+ computed for the inferior function call's stop, which is why we now
+ print a second instance of the line, as seen in the example.
+
+ To prevent this, I propose adding a scoped_restore before we start an
+ inferior function call. This will save and restore the global
+ stopped_by_random_signal value.
+
+ With this done, the output from our example is now this:
+
+ (gdb) list some_func
+ 1 int
+ 2 some_func ()
+ 3 {
+ 4 int *p = 0;
+ 5 return *p;
+ 6 }
+ 7
+ 8 void
+ 9 foo ()
+ 10 {
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing condition for breakpoint 1:
+ The program being debugged stopped while in a function called from GDB.
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+
+ Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ (gdb)
+
+ We now only see the 'Program received signal SIGSEGV, ...' line once,
+ which I think makes more sense.
+
+ Finally, I'm aware that the last few lines, that report the stop as
+ being at 'Breakpoint 1', when this is not where the thread is actually
+ located anymore, is not great. I'll address that in the next commit.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: allow agent expressions to fail with invalid memory access
+ This commit extends gdbserver to take account of a failed memory
+ access from agent_mem_read, and to return a new eval_result_type
+ expr_eval_invalid_memory_access.
+
+ I have only updated the agent_mem_read calls related directly to
+ reading memory, I have not updated any of the calls related to
+ tracepoint data collection. This is just because I'm not familiar
+ with that area of gdb/gdbserver, and I don't want to break anything,
+ so leaving the existing behaviour untouched seems like the safest
+ approach.
+
+ I've then updated gdb.base/bp-cond-failure.exp to test evaluating the
+ breakpoints on the target, and have also extended the test so that it
+ checks for different sizes of memory access.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: allows agent_mem_read to return an error code
+ Currently the gdbserver function agent_mem_read ignores any errors
+ from calling read_inferior_memory. This means that if there is an
+ attempt to access invalid memory then this will appear to succeed.
+
+ In this patch I update agent_mem_read so that if read_inferior_memory
+ fails, agent_mem_read will return an error code.
+
+ However, none of the callers of agent_mem_read actually check the
+ return value, so this commit will have no effect on anything. In the
+ next commit I will update the users of agent_mem_read to check for the
+ error code.
+
+ I've also updated the header comments on agent_mem_read to better
+ reflect what the function does, and its possible return values.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: include breakpoint number in testing condition error message
+ When GDB fails to test the condition of a conditional breakpoint, for
+ whatever reason, the error message looks like this:
+
+ (gdb) break foo if (*(int *) 0) == 1
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+ Error in testing breakpoint condition:
+ Cannot access memory at address 0x0
+
+ Breakpoint 1, foo () at bpcond.c:11
+ 11 int a = 32;
+ (gdb)
+
+ The line I'm interested in for this commit is this one:
+
+ Error in testing breakpoint condition:
+
+ In the case above we can figure out that the problematic breakpoint
+ was #1 because in the final line of the message GDB reports the stop
+ at breakpoint #1.
+
+ However, in the next few patches I plan to change this. In some cases
+ I don't think it makes sense for GDB to report the stop as being at
+ breakpoint #1, consider this case:
+
+ (gdb) list some_func
+ 1 int
+ 2 some_func ()
+ 3 {
+ 4 int *p = 0;
+ 5 return *p;
+ 6 }
+ 7
+ 8 void
+ 9 foo ()
+ 10 {
+ (gdb) break foo if (some_func ())
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ Error in testing breakpoint condition:
+ The program being debugged was signaled while in a function called from GDB.
+ GDB remains in the frame where the signal was received.
+ To change this behavior use "set unwindonsignal on".
+ Evaluation of the expression containing the function
+ (some_func) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+
+ Program received signal SIGSEGV, Segmentation fault.
+
+ Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
+ 5 return *p;
+ (gdb)
+
+ Notice that, the final lines of output reports the stop as being at
+ breakpoint #1, even though the inferior in not located within
+ some_func, and it's certainly not located at the breakpoint location.
+
+ I find this behaviour confusing, and propose that this should be
+ changed. However, if I make that change then every reference to
+ breakpoint #1 will be lost from the error message.
+
+ So, in this commit, in preparation for the later commits, I propose to
+ change the 'Error in testing breakpoint condition:' line to this:
+
+ Error in testing condition for breakpoint NUMBER:
+
+ where NUMBER will be filled in as appropriate. Here's the first
+ example with the updated error:
+
+ (gdb) break foo if (*(int *) 0) == 0
+ Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
+ (gdb) r
+ Starting program: /tmp/bpcond
+ Error in testing condition for breakpoint 1:
+ Cannot access memory at address 0x0
+
+ Breakpoint 1, foo () at bpcond.c:11
+ 11 int a = 32;
+ (gdb)
+
+ The breakpoint number does now appear twice in the output, but I don't
+ see that as a negative.
+
+ This commit just changes the one line of the error, and updates the
+ few tests that either included the old error in comments, or actually
+ checked for the error in the expected output.
+
+ As the only test that checked the line I modified is a Python test,
+ I've added a new test that doesn't rely on Python that checks the
+ error message in detail.
+
+ While working on the new test, I spotted that it would fail when run
+ with native-gdbserver and native-extended-gdbserver target boards.
+ This turns out to be due to a gdbserver bug. To avoid cluttering this
+ commit I've added a work around to the new test script so that the
+ test passes for the remote boards, in the next few commits I will fix
+ gdbserver, and update the test script to remove the work around.
+
+2023-04-03 Alan Modra <amodra@gmail.com>
+
+ asan: csky floatformat_to_double uninitialised value
+ * csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't
+ access ibytes after read_memory_func error. Change type of
+ ibytes to avoid casts.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: fix regressions in gdb.base/unwind-on-each-insn.exp
+ This commit builds on the previous one to fix all the remaining
+ failures in gdb.base/unwind-on-each-insn.exp for RISC-V.
+
+ The problem we have in gdb.base/unwind-on-each-insn.exp is that, when
+ we are in the function epilogue, the previous frame and stack pointer
+ values are being restored, and so, the values that we calculated
+ during the function prologue are no longer suitable.
+
+ Here's an example from the function 'bar' in the mentioned test. This
+ was compiled for 64-bit RISC-V with compressed instruction support:
+
+ Dump of assembler code for function bar:
+ 0x000000000001018a <+0>: add sp,sp,-32
+ 0x000000000001018c <+2>: sd ra,24(sp)
+ 0x000000000001018e <+4>: sd fp,16(sp)
+ 0x0000000000010190 <+6>: add fp,sp,32
+ 0x0000000000010192 <+8>: sd a0,-24(fp)
+ 0x0000000000010196 <+12>: ld a0,-24(fp)
+ 0x000000000001019a <+16>: jal 0x10178 <foo>
+ 0x000000000001019e <+20>: nop
+ 0x00000000000101a0 <+22>: ld ra,24(sp)
+ 0x00000000000101a2 <+24>: ld fp,16(sp)
+ 0x00000000000101a4 <+26>: add sp,sp,32
+ 0x00000000000101a6 <+28>: ret
+ End of assembler dump.
+
+ When we are at address 0x101a4 the previous instruction has restored
+ the frame-pointer, as such GDB's (current) preference for using the
+ frame-pointer as the frame base address is clearly not going to work.
+ We need to switch to using the stack-pointer instead.
+
+ At address 0x101a6 the previous instruction has restored the
+ stack-pointer value. Currently GDB will not understand this and so
+ will still assume the stack has been decreased by 32 bytes in this
+ function.
+
+ My proposed solution is to extend GDB such that GDB will scan the
+ instructions at the current $pc looking for this pattern:
+
+ ld fp,16(sp)
+ add sp,sp,32
+ ret
+
+ Obviously the immediates can change, but the basic pattern indicates
+ that the function is in the process of restoring state before
+ returning. If GDB sees this pattern then GDB can use the inferior's
+ position within this instruction sequence to help calculate the
+ correct frame-id.
+
+ With this implemented then gdb.base/unwind-on-each-insn.exp now fully
+ passes.
+
+ Obviously what I've implemented is just a heuristic. It's not going
+ to work for every function. If the compiler reorders the
+ instructions, or merges the epilogue back into the function body then
+ GDB is once again going to get the frame-id wrong.
+
+ I'm OK with that, we're no worse off that we are right now in that
+ situation (plus we can always improve the heuristic later).
+
+ Remember, this is for debugging code without debug information,
+ and (in our imagined situation) with more aggressive levels of
+ optimisation being used. Obviously GDB is going to struggle in these
+ situations.
+
+ My thinking is, lets get something in place now. Then, later, if
+ possible, we might be able to improve the logic to cover more
+ situations -- if there's an interest in doing so. But I figure we
+ need something in place as a starting point.
+
+ After this commit gdb.base/unwind-on-each-insn.exp passes with no
+ failures on RV64.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: support c.ldsp and c.lwsp in prologue scanner
+ Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp
+ instructions.
+
+ This fixes some of the failures in gdb.base/unwind-on-each-insn.exp,
+ though there are further failures that are not fixed by this commit.
+
+ This change started as a wider fix that would address all the failures
+ in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed
+ support for the two additional compressed instructions.
+
+ When I added support for those two compressed instructions I noticed
+ that some of the failures in gdb.base/unwind-on-each-insn.exp resolved
+ themselves!
+
+ Here's what's going on:
+
+ The reason for the failures is that GDB is trying to build the
+ frame-id during the last few instructions of the function. These are
+ the instructions that restore the frame and stack pointers just prior
+ to the return instruction itself.
+
+ By the time we reach the function epilogue the stack offset that we
+ calculated during the prologue scan is no longer valid, and so we
+ calculate the wrong frame-id.
+
+ However, in the particular case of interest here, the test function
+ 'foo', the function is so simple and short (the empty function) that
+ GDB's prologue scan could, in theory, scan every instruction of the
+ function.
+
+ I say "could, in theory," because currently GDB stops the prologue
+ scan early when it hits an unknown instruction. The unknown
+ instruction happens to be one of the compressed instructions that I'm
+ adding support for in this commit.
+
+ Now that GDB understands the compressed instructions the prologue scan
+ really does go from the start of the function right up to the current
+ program counter. As such, GDB sees that the stack frame has been
+ allocated, and then deallocated, and so builds the correct frame-id.
+
+ Of course, most real functions are not as simple as the test function
+ 'foo'. As such, we can't usually rely on scanning right up to the end
+ of the function -- there are some instructions we always need to stop
+ at because GDB can't reason about how they change the inferior
+ state (e.g. a function call). The test function 'bar' is just such an
+ example.
+
+ After this commit, we can now build the frame-id correctly for every
+ instruction in 'foo', but there are some tests still failing in 'bar'.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: convert riscv debug settings to new debug print scheme
+ Convert the RISC-V specific debug settings to use the new debug
+ printing scheme. This updates the following settings:
+
+ set/show debug riscv breakpoints
+ set/show debug riscv gdbarch
+ set/show debug riscv infcall
+ set/show debug riscv unwinder
+
+ All of these settings now take a boolean rather than an integer, and
+ all print their output using the new debug scheme.
+
+ There should be no visible change for anyone not turning on debug.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: adjust whitespace in cpsie instruction
+ While I was working on the disassembler styling for ARM I noticed that
+ the whitespace in the cpsie instruction was inconsistent with most of
+ the other ARM disassembly output, the disassembly for cpsie looks like
+ this:
+
+ cpsie if,#10
+
+ notice there's no space before the '#10' immediate, most other ARM
+ instructions have a space before each operand.
+
+ This commit updates the disassembler to add the missing space, and
+ updates the tests I found that tested this instruction.
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: gdb.server/server-kill.exp 'info frame' before kill_server
+ This commit follows on from the following two commits:
+
+ commit 80dc83fd0e70f4d522a534bc601df5e05b81d564
+ Date: Fri Jun 11 11:30:47 2021 +0100
+
+ gdb/remote: handle target dying just before a stepi
+
+ And:
+
+ commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53
+ Date: Thu Mar 9 10:45:03 2023 +0100
+
+ [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
+
+ The first of these commits fixed an issue in GDB and tried to extend
+ the gdb.server/server-kill.exp test to cover the GDB fix.
+
+ Unfortunately, the changes to gdb.server/server-kill.exp were not
+ correct, and were causing problems when trying to run with the
+ remote-gdbserver-on-localhost board file.
+
+ The second commit reverts some of the gdb.server/server-kill.exp
+ changes introduced in the first commit so that the test will now work
+ correctly with the remote-gdbserver-on-localhost board file.
+
+ The second commit is just about GDB's testing infrastructure -- it's
+ not about the original fix to GDB from the first commit, the actual
+ GDB change was fine.
+
+ While reviewing the second commit I wanted to check that the problem
+ fixed in the first commit is still being tested by the
+ gdb.server/server-kill.exp script, so I reverted the change to
+ breakpoint.c that is the core of the first commit and ran the test
+ script ..... and saw no failures.
+
+ The first commit is about GDB discovering that gdbserver has died
+ while trying to insert a breakpoint. As soon as GDB spots that
+ gdbserver is gone we mourn the remote inferior, which ends up deleting
+ all the breakpoints associated with the remote inferiors. We then
+ throw an exception which is caught in the insert breakpoints code, and
+ we try to display an error that includes the breakpoint number
+ .... but the breakpoint has already been deleted ... and so GDB
+ crashes.
+
+ After digging a little, what I found is that today, when the test does
+ 'stepi' the first thing we end up doing is calculating the frame-id as
+ part of the stepi logic, it is during this frame-id calculation that
+ we mourn the remote inferior, delete the breakpoints, and throw an
+ exception. The exception is caught by the top level interpreter loop,
+ and so we never try to print the breakpoint number which is what
+ caused the original crash.
+
+ If I add an 'info frame' command to the test script, prior to killing
+ gdbserver, then now when we 'stepi' GDB already has the frame-id
+ calculated, and the first thing we do is try to insert the
+ breakpoints, this will trigger the original bug.
+
+ In order to reproduce this experiment you'll need to change a function
+ in breakpoint.c, like this:
+
+ static void
+ rethrow_on_target_close_error (const gdb_exception &e)
+ {
+ return;
+ }
+
+ Then run gdb.server/server-kill.exp with and without this patch. You
+ should find that without this patch there are zero test failures,
+ while with this patch there will be one failure like this:
+
+ (gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
+ Executing on target: kill -9 4513 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 4513
+ stepi
+ ../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ ...
+
+2023-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix failure in gdb.python/py-unwind.exp
+ A potential test failure was introduced with commit:
+
+ commit 6bf5f25bb150c0fbcb125e3ee466ba8f9680310b
+ Date: Wed Mar 8 16:11:30 2023 +0000
+
+ gdb/python: make the gdb.unwinder.Unwinder class more robust
+
+ In this commit a new test was added, however the expected output
+ pattern varies depending on which Python version GDB is linked
+ against.
+
+ Older versions of Python result in output like this:
+
+ (gdb) python global_test_unwinder.name = "foo"
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ AttributeError: can't set attribute
+ Error while executing Python code.
+ (gdb)
+
+ While more recent versions of Python give a similar, but slightly more
+ verbose error message, like this:
+
+ (gdb) python global_test_unwinder.name = "foo"
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ AttributeError: can't set attribute 'name'
+ Error while executing Python code.
+ (gdb)
+
+ The test was only accepting the first version of the output. This
+ commit extends the test pattern so that either version will be
+ accepted.
+
+2023-04-03 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] tpidr2: Fix erroneous detection logic for TPIDR2
+ The detection logic for TPIDR2 was implemented incorrectly. Originally
+ the detection was supposed to be through a ptrace error code, but in reality,
+ for backwards compatibility, the detection should be based on the size of
+ the returned iovec.
+
+ For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a
+ iovec size of 16. If a target only supports TPIDR and not TPIDR2, it will
+ return a iovec size of 8, even if we asked for 16 bytes.
+
+ This patch fixes this issue in code that is shared between gdb and gdbserver,
+ therefore both gdb and gdbserver are fixed.
+
+ Tested on AArch64/Linux Ubuntu 20.04.
+
+2023-04-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-02 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow printing ecoff debug info file name
+ A case of a string section ending with an unterminated string. Fix it
+ by allocating one more byte and making it zero. Also make functions
+ reading the data return void* so that casts are not needed.
+
+ * ecoff.c (READ): Delete type param. Allocate one extra byte
+ to terminate string sections with a NUL. Adjust invocation.
+ * elfxx-mips.c (READ): Likewise.
+ * libbfd-in.h (_bfd_alloc_and_read): Return a void*.
+ (_bfd_malloc_and_read): Likewise.
+ * libbfd.h: Regenerate.
+
+2023-04-02 Alan Modra <amodra@gmail.com>
+
+ ubsan: aarch64 parse_vector_reg_list
+ tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places
+ cannot be represented in type 'int'.
+
+ * config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left
+ shift.
+
+2023-04-02 Alan Modra <amodra@gmail.com>
+
+ rddbg.c stabs FIXMEs
+ This should sort out some very old FIXMEs in code handling stabs
+ debug info. Necessary if we are to fuss over freeing up memory before
+ objdump and objcopy exit. It is of course better from a user
+ viewpoint to *not* free memory, which takes some time, and leave that
+ to process exit. The only reason to do so is that having many memory
+ leaks in binutils/ code tends to hide leaks in bfd/ or opcodes/, which
+ we should care about.
+
+ * budbg.h (parse_stab): Update prototype.
+ * debug.h (debug_start_source): Update prototype.
+ * debug.c (debug_start_source): Add name_used. Set if stashed.
+ * rddbg.c (read_symbol_stabs_debugging_info): Always malloc
+ stab string passed to parse_stab. Free stab string when
+ unreferenced.
+ (read_section_stabs_debugging_info): Likewise, and strings
+ section contents.
+ * stabs.c (parse_stab): Add string_used param. Set if string
+ stashed. Pass to debug_start_source. Realloc file_types
+ array rather that using malloc. Clarify comment about
+ debug_make_indirect_type.
+
+2023-04-02 Alan Modra <amodra@gmail.com>
+
+ Memory leak in process_abbrev_set
+ We may have added some abbrevs to the list before hitting an error.
+ Free the list elements too. free_abbrev_list returns list->next so we
+ need to init it earlier to avoid an uninitialised memory access.
+
+ * dwarf.c (process_abbrev_set): Call free_abbrev_list on errors.
+ Set list->next earlier.
+
+2023-04-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused parameters in print_doc_of_command, apropos_cmd
+ I noticed the prefix parameter was unused in print_doc_of_command. And
+ when removing it, it becomes unused in apropos_cmd.
+
+ Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e
+
+2023-04-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-04-01 Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ gdb/arm: Fix backtrace for pthread_cond_timedwait
+ GDB expected PC should point right after the SVC instruction when the
+ syscall is active. But some active syscalls keep PC pointing to the SVC
+ instruction itself.
+
+ This leads to a broken backtrace like:
+ Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+ #0 0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
+ #1 0xb6e21f80 in ?? ()
+
+ The reason is that .ARM.exidx unwinder gives up if PC does not point
+ right after the SVC (syscall) instruction. I did not investigate why but
+ some syscalls will point PC to the SVC instruction itself. This happens
+ for the "futex" syscall used by pthread_cond_timedwait.
+
+ That normally does not matter as ARM prologue unwinder gets called
+ instead of the .ARM.exidx one. Unfortunately some glibc calls have more
+ complicated prologue where the GDB unwinder fails to properly determine
+ the return address (that is in fact an orthogonal GDB bug). I expect it
+ is due to the "vpush" there in this case but I did not investigate it more:
+
+ Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4:
+ 0xb6f8757c <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
+ 0xb6f87580 <+4>: mov r10, r2
+ 0xb6f87584 <+8>: vpush {d8}
+
+ Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11).
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2023-04-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-31 H.J. Lu <hjl.tools@gmail.com>
+
+ lto: Don't add indirect symbols for versioned aliases in IR
+ Linker adds indirect symbols for versioned symbol aliases, which are
+ created by ".symver foo, foo@FOO", by checking symbol type, value and
+ section so that references to foo will be replaced by references to
+ foo@FOO if foo and foo@FOO have the same symbol type, value and section.
+ But in IR, since all symbols of the same type have the same value and
+ section, we can't tell if a symbol is an alias of another symbol by
+ their types, values and sections. We shouldn't add indirect symbols
+ for versioned symbol aliases in IR.
+
+ bfd/
+
+ PR ld/30281
+ * elflink.c (elf_link_add_object_symbols): Don't add indirect
+ symbols for ".symver foo, foo@FOO" aliases in IR.
+
+ ld/
+
+ PR ld/30281
+ * testsuite/ld-plugin/lto.exp: Add PR ld/30281 test.
+ * testsuite/ld-plugin/pr30281.t: New file.
+ * testsuite/ld-plugin/pr30281.c: Likewise.
+
+2023-03-31 Tom Tromey <tom@tromey.com>
+
+ Fix maybe-uninitialized warning in frame.c
+ A recent patch caused my system gcc (Fedora 36, so gcc 12.2.1) to warn
+ about sym_addr being possibly uninitialized in frame.c. It isn't, but
+ the compiler can't tell. So, this patch initializes the variable. I
+ also fixed a formatting buglet that I missed in review.
+
+2023-03-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/trace-commands.exp with editing off
+ With test-case gdb.base/trace-commands.exp and editing off, I run into fails
+ because multi-line commands are issued using gdb_test_sequence, which
+ doesn't handle them correctly.
+
+ Fix this by using gdb_test instead.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30288
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
+
+2023-03-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/threadapply.exp with editing off
+ With test-case gdb.threads/threadapply.exp and editing set to on, we have:
+ ...
+ (gdb) define remove^M
+ Type commands for definition of "remove".^M
+ End with a line saying just "end".^M
+ >remove-inferiors 3^M
+ >end^M
+ (gdb)
+ ...
+ but with editing set to off, we run into:
+ ...
+ (gdb) define remove^M
+ Type commands for definition of "remove".^M
+ End with a line saying just "end".^M
+ >remove-inferiors 3^M
+ end^M
+ >(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
+ define remove (timeout)
+ ...
+
+ The commands are issued by this test:
+ ...
+ gdb_define_cmd "remove" {
+ "remove-inferiors 3"
+ }
+ ...
+ which does:
+ - gdb_test_multiple "define remove", followed by
+ - gdb_test_multiple "remove-inferiors 3\nend".
+
+ Proc gdb_test_multiple has special handling for multi-line commands, which
+ splits it up into subcommands, and for each subcommand issues it and then
+ waits for the resulting prompt (the secondary prompt ">" for all but the last
+ subcommand).
+
+ However, that doesn't work as expected in this case because the initial
+ gdb_test_multiple "define remove" fails to match all resulting output, and
+ consequently the secondary prompt resulting from "define remove" is counted as
+ if it was the one resulting from "remove-inferiors 3".
+
+ Fix this by matching the entire output of "define remove", including the
+ secondary prompt.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30288
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
+
+2023-03-31 Tom Tromey <tom@tromey.com>
+
+ Remove language_demangle
+ I noticed that language_demangle shadows the global
+ "current_language". When I went to fix this, though, I then saw that
+ language_demangle is only called in two places, and has a comment
+ saying it should be removed. This patch removes it. Note that the
+ NULL check in language_demangle is not needed by either of the
+ existing callers.
+
+ Regression tested on x86-64 Fedora 36.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-31 Tom Tromey <tom@tromey.com>
+
+ Fix race in background index-cache writing
+ Tom de Vries pointed out a bug in the index-cache background writer --
+ sometimes it will fail. He also noted that it fails when the number
+ of worker threads is set to zero. These turn out to be the same
+ problem -- the cache can't be written to until the per-BFD's
+ "index_table" member is set.
+
+ This patch avoids the race by rearranging the code slightly, to ensure
+ the cache cannot possibly be written before the member is set.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261
+
+2023-03-31 Richard Bunt <richard.bunt@linaro.org>
+
+ GDB: Add `info main' command
+ Allow consumers of GDB to extract the name of the main method. This is
+ most useful for Fortran programs which have a variable main method.
+
+ Used by both MAP and DDT e.g. it is used to detect the presence of debug
+ information.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
+
+2023-03-31 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Bring back the handling of DW_CC_program
+ Fix a functional regression and restore the handling of DW_CC_program
+ code of DW_AT_calling_convention attribute for determining the name of
+ the starting function of the program where the DW_AT_main_subprogram
+ attribute has not been provided, such as with Fortran code compiled with
+ GCC versions 4.5.4 and below, or where DWARF version 3 or below has been
+ requested. Without it "main" is considered the starting function. Cf.
+ GCC PR fortran/43414.
+
+ Original code was removed with commit 6209cde4ddb8 ("Delete DWARF
+ psymtab code"), and then an update to complement commit 81873cc81eff
+ ("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also
+ been included here.
+
+2023-03-31 Richard Bunt <richard.bunt@linaro.org>
+
+ GDB: Favor full symbol main name for backtrace stop
+ In the case where a Fortran program has a program name of "main" and
+ there is also a minimal symbol called main, such as with programs built
+ with GCC version 4.4.7 or below, the backtrace will erroneously stop at
+ the minimal symbol rather than the user specified main, e.g.:
+
+ (gdb) bt
+ #0 bar () at .../gdb/testsuite/gdb.fortran/backtrace.f90:17
+ #1 0x0000000000402556 in foo () at .../gdb/testsuite/gdb.fortran/backtrace.f90:21
+ #2 0x0000000000402575 in main () at .../gdb/testsuite/gdb.fortran/backtrace.f90:31
+ #3 0x00000000004025aa in main ()
+ (gdb)
+
+ This patch fixes this issue by increasing the precedence of the full
+ symbol when the language of the current frame is Fortran.
+
+ Newer versions of GCC transform the program name to "MAIN__" in this
+ case, avoiding the problem.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
+
+2023-03-31 Ari Hannula <ari.hannula@intel.com>
+
+ gdb: Remove extra if statement
+ The removed if statement is already checked in the parent if else
+ statement.
+
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-03-31 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Allocate "various" operand type
+ This commit intends to move operands that require very special handling or
+ operand types that are so minor (e.g. only useful on a few instructions)
+ under "W". I also intend this "W" to be "temporary" operand storage until
+ we can find good two character (or less) operand type.
+
+ In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved
+ to "Wif" because of its special handling (and allocating single character
+ "f" for this operand type seemed too much).
+
+ Current expected allocation guideline is as follows:
+
+ 1. 'W'
+ 2. The most closely related single-letter extension in lowercase
+ (strongly recommended but not mandatory)
+ 3. Identify operand type
+
+ The author currently plans to allocate following three-character operand
+ types (for operands including instructions from unratified extensions).
+
+ 1. "Wif" ('Zicbop': fetch offset)
+ 2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions)
+ 3. "Wfm" / "WfM"
+ 'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling
+ solely for widening conversion instructions.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from
+ "f" to "Wif".
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Move from "f" to "Wif".
+ * riscv-opc.c (riscv_opcodes): Reflect new operand type.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: convert testcases to use .insn
+ This can't be done for all insns currently encoded with .byte. For one
+ outside of 64-bit mode unused (typically ignored) register encoding bits
+ in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
+ the necessary registers cannot be specified (and some of these bits
+ can't even be used outside of 64-bit mode). And then there are odd tests
+ like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
+ together with EVEX.W (which could be expressed; note though EVEX.W set
+ is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
+ it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
+ because that's another #UD reason).
+
+ In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
+ byte but insufficient displacement bytes, some using SIB encoding with
+ the SIB byte actually being the supposed immediate. Some of these could
+ be expressed by .insn, but I don't want to introduce bogus examples.
+ These will all need adjustment anyway once the disassembler is improved
+ in the way it deals with unrecognized encodings.
+
+ Generally generated code is meant to remain the same. {,x86-64-}nops.d
+ are exceptions because insn prefixes are emitted in a different order.
+ opcode{,-intel,-suffix}.d are also adjusted (along with an according
+ correction to opcode.s) to cover an apparent typo in the original tests
+ (xor when or was meant).
+
+ Where necessary --divide is added as gas option, to allow for the use
+ of the extension opcode functionality.
+
+ Comments are being adjusted where obviously wrong/misleading.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: document .insn
+ ... and mention its introduction in NEWS.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: handle immediate operands for .insn
+ Since we have no insn suffix and it's also not realistic to infer
+ immediate size from the size of other (typically register) operands
+ (like optimize_imm() does), and since we also don't have a template
+ telling us permitted size(s), a new syntax construct is introduced to
+ allow size (and signedness) specification. In the absence of such, the
+ size is inferred from significant bits (which obviously may yield
+ inconsistent results at least for effectively negative values, depending
+ on whether BFD64 is enabled), and only if supplied expressions can be
+ evaluated at parsing time. Being explicit is generally recommended to
+ users.
+
+ Size specification is permitted at bit granularity, but of course the
+ eventually emitted immediate values will be padded up to 8-, 16-, 32-,
+ or 64-bit fields.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: allow for multiple immediates in output_disp()
+ .insn isn't going to have a constraint of only a single immediate when,
+ in particular, RIP-relative addressing is used.
+
+ x86: handle EVEX Disp8 for .insn
+ In particular the scaling factor cannot always be determined from pre-
+ existing operand attributes. Introduce a new {:d<N>} vector operand
+ syntax extension, restricted to .insn only, to allow specifying this in
+ (at least) otherwise ambiguous cases.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: process instruction operands for .insn
+ Deal with register and memory operands; immediate operands will follow
+ later, as will the handling of EVEX embedded broadcast and EVEX Disp8
+ scaling.
+
+ Note that because we can't really know how to encode their use, %cr8 and
+ up cannot be used with .insn outside of 64-bit mode. Users would need to
+ specify an explicit LOCK prefix in combination with %cr0 etc.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: parse special opcode modifiers for .insn
+ So called "short form" encoding is specified by a trailing "+r", whereas
+ a possible extension opcode is specified by the usual "/<digit>". Take
+ these off the expression before handing it to get_absolute_expression().
+
+ Note that on targets where / starts a comment, --divide needs passing to
+ gas in order to make use of the extension opcode functionality.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: parse VEX and alike specifiers for .insn
+ All encoding spaces can be used this way; there's a certain risk that
+ the bits presently reserved could be used for other purposes down the
+ road, but people using .insn are expected to know what they're doing
+ anyway. Plus this way there's at least _some_ way to have those bits
+ set.
+
+ For now this will only allow operand-less insns to be encoded this way.
+
+2023-03-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: introduce .insn directive
+ For starters this deals with only very basic constructs.
+
+ Arm64/ELF: accept relocations against STN_UNDEF
+ While only a secondary issue there, the testcase of PR gas/27212 exposes
+ an oversight in relocation handling: Just like e.g. Arm32, which has a
+ similar comment and a similar check, relocations against STN_UNDEF have
+ to be permitted to satisfy the ELF spec.
+
+2023-03-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-30 Kevin Buettner <kevinb@redhat.com>
+
+ PR gdb/30219: Clear sync_quit_force_run in quit_force
+ PR 30219 shows an internal error due to a "Bad switch" in
+ print_exception() in gdb/exceptions.c. The switch in question
+ contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
+ for the recently added RETURN_FORCED_QUIT. This commit adds that case.
+
+ Making the above change allows the errant test case to pass, but does
+ not fix the underlying problem, which I'll describe shortly. Even
+ though the addition of a case for RETURN_FORCED_QUIT isn't the actual
+ fix, I still think it's important to add this case so that other
+ situations which lead to print_exeption() being called won't generate
+ that "Bad switch" internal error.
+
+ In order to understand the underlying problem, please examine
+ this portion of the backtrace from the bug report:
+
+ 0x5576e4ff5780 print_exception
+ /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
+ 0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
+ /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
+ 0x5576e6a896dd quit_force(int*, int)
+ /home/smarchi/src/binutils-gdb/gdb/top.c:1849
+
+ The real problem is in quit_force; here's the try/catch which
+ eventually leads to the internal error:
+
+ /* Get out of tfind mode, and kill or detach all inferiors. */
+ try
+ {
+ disconnect_tracing ();
+ for (inferior *inf : all_inferiors ())
+ kill_or_detach (inf, from_tty);
+ }
+ catch (const gdb_exception &ex)
+ {
+ exception_print (gdb_stderr, ex);
+ }
+
+ While running the calls in the try-block, a QUIT check is being
+ performed. This check finds that sync_quit_force_run is (still) set,
+ causing a gdb_exception_forced_quit to be thrown. The exception
+ gdb_exception_forced_quit is derived from gdb_exception, causing
+ exception_print to be called. As shown by the backtrace,
+ print_exception is then called, leading to the internal error.
+
+ The actual fix, also implemented by this commit, is to clear
+ sync_quit_force_run along with the quit flag. This will allow the
+ various cleanup code, called by quit_force, to run without triggering
+ a gdb_exception_forced_quit. (Though, if another SIGTERM is sent to
+ the gdb process, these flags will be set again and a QUIT check in the
+ cleanup code will detect it and throw the exception.)
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Remove stray reglist variable
+ Sorry for not catching this during testing. I was using a
+ host compiler that predated the switch to -fno-common.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the RPRFM instruction
+ This patch adds the RPRFM (range prefetch) instruction.
+ It was introduced as part of SME2, but it belongs to the
+ prefetch hint space and so doesn't require any specific
+ ISA flags.
+
+ The aarch64_rprfmop_array initialiser (deliberately) only
+ fills in the leading non-null elements.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SVE FCLAMP instruction
+
+ aarch64: Add new SVE shift instructions
+ This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN
+ instructions.
+
+ aarch64: Add new SVE saturating conversion instructions
+ This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions,
+ which are available when FEAT_SME2 is implemented.
+
+ aarch64: Add new SVE dot-product instructions
+ This patch adds the SVE FDOT, SDOT and UDOT instructions,
+ which are available when FEAT_SME2 is implemented. The patch
+ also reorders the existing SVE_Zm3_22_INDEX to keep the
+ operands numerically sorted.
+
+ aarch64: Add the SVE BFMLSL instructions
+ This patch adds the SVE BFMLSLB and BFMLSLT instructions,
+ which are available when FEAT_SME2 is implemented.
+
+ aarch64: Add the SME2 UZP and ZIP instructions
+ This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2}
+ into single instructions.
+
+ aarch64: Add the SME2 UNPK instructions
+ This patch adds SUNPK and UUNPK, which unpack one register's
+ worth of elements to two registers' worth, or two registers'
+ worth to four registers' worth.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 shift instructions
+ There are two instruction formats here:
+
+ - SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two
+ or four registers.
+
+ - SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of
+ four registers.
+
+ These are the first SME2 instructions to have immediate operands.
+ The patch makes sure that, when parsing SME2 instructions with
+ immediate operands, the new predicate-as-counter registers are
+ parsed as registers rather than as #-less immediates.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 saturating conversion instructions
+ There are two instruction formats here:
+
+ - SQCVT, SQCVTU and UQCVT, which operate on lists of two or
+ four registers.
+
+ - SQCVTN, SQCVTUN and UQCVTN, which operate on lists of
+ four registers.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 FP<->FP conversion instructions
+ This patch adds the BFCVT{,N} and FCVT{,N} instructions,
+ which narrow a pair of .S registers to a single .H register.
+
+ aarch64: Add the SME2 FP<->int conversion instructions
+ This patch adds the SME2 versions of the FP<->integer conversion
+ instructions FCVT* and *CVTF. It also adds FP rounding instructions
+ FRINT*, which share the same format.
+
+ aarch64: Add the SME2 CLAMP instructions
+ FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP
+ doesn't have a .B form.
+
+ aarch64: Add the SME2 MOPA and MOPS instructions
+ [BSU]MOP[AS] share the same format.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 vertical dot-product instructions
+ There are three instruction formats here:
+ - BFVDOT + FVDOT
+ - SVDOT + UVDOT
+ - SUVDOT + USVDOT
+
+ There are also 64-bit forms of SVDOT and UVDOT.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 dot-product instructions
+ BFDOT, FDOT and USDOT share the same instruction format.
+ SDOT and UDOT share a different format. SUDOT does not
+ have the multi vector x multi vector forms, since they
+ would be redundant with USDOT.
+
+ aarch64: Add the SME2 MLALL and MLSLL instructions
+ SMLALL, SMLSLL, UMLALL and UMLSLL have the same format.
+ USMLALL and SUMLALL allow the same operand types as those
+ instructions, except that SUMLALL does not have the multi-vector
+ x multi-vector forms (which would be redundant with USMLALL).
+
+ aarch64: Add the SME2 MLAL and MLSL instructions
+ The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same
+ encoding. They are the first instance of a ZA (as opposed to ZA tile)
+ operand having a range of offsets. As with ZA tiles, the expected
+ range size is encoded in the operand-specific data field.
+
+ aarch64: Add the SME2 FMLA and FMLS instructions
+
+ aarch64: Add the SME2 maximum/minimum instructions
+ This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM}
+ and {S,U}{MAX,MIN}. SQDMULH, SRSHL and URSHL have the same form
+ as SMAX etc., so the patch adds them too.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 ADD and SUB instructions
+ Add support for the SME2 ADD. SUB, FADD and FSUB instructions.
+ SUB and FSUB have the same form as ADD and FADD, except that
+ ADD also has a 2-operand accumulating form.
+
+ The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the
+ 64-bit FADD/FSUB instructions require FEAT_SME_F64F64.
+
+ These are the first instructions to have tied register list
+ operands, as opposed to tied single registers.
+
+ The parse_operands change prevents unsuffixed Z registers (width==-1)
+ from being treated as though they had an Advanced SIMD-style suffix
+ (.4s etc.). It means that:
+
+ Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'
+
+ becomes:
+
+ Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 ZT0 instructions
+ SME2 adds lookup table instructions for quantisation. They use
+ a new lookup table register called ZT0.
+
+ LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>],
+ which is the first time that this syntax has been used.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 predicate-related instructions
+ Implementation-wise, the main things to note here are:
+
+ - the WHILE* instructions have forms that return a pair of predicate
+ registers. This is the first time that we've had lists of predicate
+ registers, and they wrap around after register 15 rather than after
+ register 31.
+
+ - the predicate-as-counter WHILE* instructions have a fourth operand
+ that specifies the vector length. We can treat this as an enumeration,
+ except that immediate values aren't allowed.
+
+ - PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>].
+ This is the first instance of a vector/predicate index having
+ no suffix.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 multivector LD1 and ST1 instructions
+ SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers.
+ The registers can be consecutive or strided. In the strided case,
+ 2-register lists have a stride of 8, starting at register x0xxx.
+ 4-register lists have a stride of 4, starting at register x00xx.
+
+ The instructions are predicated on a predicate-as-counter register in
+ the range pn8-pn15. Although we already had register fields with upper
+ bounds of 7 and 15, this is the first plain register operand to have a
+ nonzero lower bound. The patch uses the operand-specific data field
+ to record the minimum value, rather than having separate inserters
+ and extractors for each lower bound. This in turn required adding
+ an extra bit to the field.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add the SME2 MOVA instructions
+ SME2 defines new MOVA instructions for moving multiple registers
+ to and from ZA. As with SME, the instructions are also available
+ through MOV aliases.
+
+ One notable feature of these instructions (and many other SME2
+ instructions) is that some register lists must start at a multiple
+ of the list's size. The patch uses the general error "start register
+ out of range" when this constraint isn't met, rather than an error
+ specifically about multiples. This ensures that the error is
+ consistent between these simple consecutive lists and later
+ strided lists, for which the requirements aren't a simple multiple.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for predicate-as-counter registers
+ SME2 adds a new format for the existing SVE predicate registers:
+ predicates as counters rather than predicates as masks. In assembly
+ code, operands that interpret predicates as counters are written
+ pn<N> rather than p<N>.
+
+ This patch adds support for these registers and extends some
+ existing instructions to support them. Since the new forms
+ are just a programmer convenience, there's no need to make them
+ more restrictive than the earlier predicate-as-mask forms.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64; Add support for vector offset ranges
+ Some SME2 instructions operate on a range of consecutive ZA vectors.
+ This is indicated by syntax such as:
+
+ za[<Wv>, <imml>:<immh>]
+
+ Like with the earlier vgx2 and vgx4 support, we get better error
+ messages if the parser allows all ZA indices to have a range.
+ We can then reject invalid cases during constraint checking.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for vgx2 and vgx4
+ Many SME2 instructions operate on groups of 2 or 4 ZA vectors.
+ This is indicated by adding a "vgx2" or "vgx4" group size to the
+ ZA index. The group size is optional in assembly but preferred
+ for disassembly.
+
+ There is not a binary distinction between mnemonics that have
+ group sizes and mnemonics that don't, nor between mnemonics that
+ take vgx2 and mnemonics that take vgx4. We therefore get better
+ error messages if we allow any ZA index to have a group size
+ during parsing, and wait until constraint checking to reject
+ invalid sizes.
+
+ A quirk of the way errors are reported means that if an instruction
+ is wrong both in its qualifiers and its use of a group size, we'll
+ print suggested alternative instructions that also have an incorrect
+ group size. But that's a general property that also applies to
+ things like out-of-range immediates. It's also not obviously the
+ wrong thing to do. We need to be relatively confident that we're
+ looking at the right opcode before reporting detailed operand-specific
+ errors, so doing qualifier checking first seems resonable.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array
+ SME2 adds various new fields that are similar to
+ AARCH64_OPND_SME_ZA_array, but are distinguished by the size of
+ their offset fields. This patch adds _off4 to the name of the
+ field that we already have.
+
+ aarch64: Add a _10 suffix to FLD_imm3
+ SME2 adds various new 3-bit immediate fields, so this patch adds
+ an lsb position suffix to the name of the field that we already have.
+
+ aarch64: Add +sme2
+ This patch adds bare-bones support for +sme2. Later patches
+ fill in the rest.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Prefer register ranges & support wrapping
+ Until now, binutils has supported register ranges such
+ as { v0.4s - v3.4s } as an unofficial shorthand for
+ { v0.4s, v1.4s, v2.4s, v3.4s }. The SME2 ISA embraces this form
+ and makes it the preferred disassembly. It also embraces wrapped
+ lists such as { z31.s - z2.s }, which is something that binutils
+ didn't previously allow.
+
+ The range form was already binutils's preferred disassembly for 3- and
+ 4-register lists. This patch prefers it for 2-register lists too.
+ The patch also adds support for wrap-around.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for strided register lists
+ SME2 has instructions that accept strided register lists,
+ such as { z0.s, z4.s, z8.s, z12.s }. The purpose of this
+ patch is to extend binutils to support such lists.
+
+ The parsing code already had (unused) support for strides of 2.
+ The idea here is instead to accept all strides during parsing
+ and reject invalid strides during constraint checking.
+
+ The SME2 instructions that accept strided operands also have
+ non-strided forms. The errors about invalid strides therefore
+ take a bitmask of acceptable strides, which allows multiple
+ possibilities to be summed up in a single message.
+
+ I've tried to update all code that handles register lists.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Sort fields alphanumerically
+ This patch just sorts the field enum alphanumerically, which makes
+ it easier to see if a particular field has already been defined.
+
+ aarch64: Resync field names
+ This patch just makes the comments in aarch64-opc.c:fields match
+ the names of the associated FLD_* enum.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Regularise FLD_* suffixes
+ Some FLD_imm* suffixes used a counting scheme such as FLD_immN,
+ FLD_immN_2, FLD_immN_3, etc., while others used the lsb as the
+ suffix. The latter seems more mnemonic, and was a big help
+ in doing the SME2 work.
+
+ Similarly, the _10 suffix on FLD_SME_size_10 was nonobvious.
+ Presumably it indicated a 2-bit field, but it actually starts
+ in bit 22.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Rename some of GAS's REG_TYPE_* macros
+ In GAS, the vector and predicate registers are identified by
+ REG_TYPE_VN, REG_TYPE_ZN and REG_TYPE_PN. This "N" is obviously
+ a placeholder for the register number. However, we don't use that
+ convention for integer and FP registers, and (more importantly)
+ SME2 adds "predicate-as-counter" registers that are denoted PN.
+
+ This patch therefore drops the "N" suffix from the existing
+ registers. The main hitch is that Z was also used for the
+ zero register in things like R_Z, but using ZR seems more
+ consistent with the SP-based names.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add a aarch64_cpu_supports_inst_p helper
+ Quite a lot of SME2 instructions have an opcode bit that selects
+ between 32-bit and 64-bit forms of an instruction, with the 32-bit
+ forms being part of base SME2 and with the 64-bit forms being part
+ of an optional extension. It's nevertheless useful to have a single
+ opcode entry for both forms since (a) that matches the ISA definition
+ and (b) it tends to improve error reporting.
+
+ This patch therefore adds a libopcodes function called
+ aarch64_cpu_supports_inst_p that tests whether the target
+ supports a particular instruction. In future it will depend
+ on internal libopcodes routines.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Reorder some OP_SVE_* macros
+ This patch just moves some out-of-order-looking OP_SVE_* macros.
+
+ aarch64: Rename aarch64-tbl.h OP_SME_* macros
+ This patch renames the OP_SME_* macros in aarch64-tbl.h so that
+ they follow the same scheme as the OP_SVE_* ones. It also uses
+ OP_SVE_ as the prefix, since there is no real distinction between
+ the SVE and SME uses of qualifiers: a macro defined for one can
+ be useful for the other too.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak priorities of parsing-related errors
+ There are three main kinds of error reported during parsing,
+ in increasing order of priority:
+
+ - AARCH64_OPDE_RECOVERABLE (register seen instead of immediate)
+ - AARCH64_OPDE_SYNTAX_ERROR
+ - AARCH64_OPDE_FATAL_SYNTAX_ERROR
+
+ This priority makes sense when comparing errors reported against the
+ same operand. But if we get to operand 3 (say) and see a register
+ instead of an immediate, that's likely to be a better match than
+ something that fails with a syntax error at operand 1.
+
+ The idea of this patch is to prioritise parsing-related errors
+ based on operand index first, then by error code. Post-parsing
+ errors still win over parsing errors, and their relative priorities
+ don't change.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Try to report invalid variants against the closest match
+ If an instruction has invalid qualifiers, GAS would report the
+ error against the final opcode entry that got to the qualifier-
+ checking stage. It seems better to report the error against
+ the opcode entry that had the closest match, just like we
+ pick the closest match within an opcode entry for the
+ "did you mean this?" message.
+
+ This patch adds the number of invalid operands as an
+ argument to AARCH64_OPDE_INVALID_VARIANT and then picks the
+ AARCH64_OPDE_INVALID_VARIANT with the lowest argument.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak register list errors
+ The error for invalid register lists had the form:
+
+ invalid number of registers in the list; N registers are expected at operand M -- `insn'
+
+ This seems a bit verbose. Also, the "bracketing" is really:
+
+ (invalid number of registers in the list; N registers are expected) at operand M
+
+ but the semicolon works against that.
+
+ This patch goes for slightly shorter messages, setting a template
+ that later patches can use for more complex cases.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Make AARCH64_OPDE_REG_LIST take a bitfield
+ AARCH64_OPDE_REG_LIST took a single operand that specified the
+ expected number of registers. However, there are quite a few
+ SME2 instructions that have both 2-register forms and (separate)
+ 4-register forms. If the user tries to use a 3-register list,
+ it isn't obvious which opcode entry they meant. Saying that we
+ expect 2 registers and saying that we expect 4 registers would
+ both be wrong.
+
+ This patch therefore switches the operand to a bitfield. If a
+ AARCH64_OPDE_REG_LIST is reported against multiple opcode entries,
+ the patch ORs up the expected lengths.
+
+ This has no user-visible effect yet. A later patch adds more error
+ strings, alongside tests that use them.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add an operand class for SVE register lists
+ SVE register lists were classified as SVE_REG, since there had been
+ no particular reason to separate them out. However, some SME2
+ instructions have tied register list operands, and so we need to
+ distinguish registers and register lists when checking whether two
+ operands match.
+
+ Also, the register list operands used a general error message,
+ even though we already have a dedicated error code for register
+ lists that are the wrong length.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Commonise checks for index operands
+ This patch splits out the constraint checking for index operands,
+ so that it can be reused by new SME2 operands.
+
+ aarch64: Add an error code for out-of-range registers
+ libopcodes currently reports out-of-range registers as a general
+ AARCH64_OPDE_OTHER_ERROR. However, this means that each register
+ range needs its own hard-coded string, which is a bit cumbersome
+ if the range is determined programmatically. This patch therefore
+ adds a dedicated error type for out-of-range errors.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Deprioritise AARCH64_OPDE_REG_LIST
+ SME2 has many instructions that take a list of SVE registers.
+ There are often multiple forms, with different forms taking
+ different numbers of registers.
+
+ This means that if, after a successful parse and qualifier match,
+ we find that the number of registers does not match the opcode entry,
+ the associated error should have a lower priority/severity than other
+ errors reported at the same stage. For example, if there are 2-register
+ and 4-register forms of an instruction, and if the assembly code uses
+ the 2-register form with an out-of-range value, the out-of-range value
+ error against the 2-register instruction should have a higher priority
+ than the "wrong number of registers" error against the 4-register
+ instruction.
+
+ This is tested by the main SME2 patches, but seemed worth splitting out.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Update operand_mismatch_kind_names
+ The contents of operand_mismatch_kind_names were out of sync
+ with the enum.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Rework reporting of failed register checks
+ There are many opcode table entries that share the same mnemonic.
+ Trying to parse an invalid assembly line will trigger an error for
+ each of these entries, but the specific error might vary from one
+ entry to another, depending on the exact nature of the problem.
+
+ GAS has quite an elaborate system for picking the most appropriate
+ error out of all the failed matches. And in many cases it works well.
+ However, one of the limitations is that the error is always reported
+ against a single opcode table entry. If that table entry isn't the
+ one that the user intended to use, then the error can end up being
+ overly specific.
+
+ This is particularly true if an instruction has a typoed register
+ name, or uses a type of register that is not accepted by any
+ opcode table entry. For example, one of the expected error
+ matches for an attempted SVE2 instruction is:
+
+ Error: operand 1 must be a SIMD scalar register -- `addp z32\.s,p0/m,z32\.s,z0\.s'
+
+ even though the hypothetical user was presumably attempting to use
+ the SVE form of ADDP rather than the Advanced SIMD one. There are
+ many other instances of this in the testsuite.
+
+ The problem becomes especially acute with SME2, since many SME2
+ instructions reuse existing mnemonics. This could lead to us
+ reporting an SME-related error against a non-SME instruction,
+ or a non-SME-related error against an SME instruction.
+
+ This patch tries to improve things by collecting together all
+ the register types that an opcode table entry expected for a
+ given operand. It also records what kind of register was
+ actually seen, if any. It then tries to summarise all this
+ in a more directed way, falling back to a generic error if
+ the combination defies a neat summary.
+
+ The patch includes tests for all new messages except REG_TYPE_ZA,
+ which only triggers with SME2.
+
+ To test this, I created an assembly file that contained the cross
+ product of all known mnemonics and one example from each register
+ class. I then looked for cases where the new routines fell back on the
+ generic errors ("expected a register" or "unexpected register type").
+ I locally added dummy messages for each one until there were no
+ more hits. The patch adds a specimen instruction to diagnostics.s
+ for each of these combinations. In each case, the combination didn't
+ seem like something that could be summarised in a natural way, so the
+ generic messages seemed better. There's always going to be an element
+ of personal taste around this kind of thing though.
+
+ Adding more register types made 1<<REG_TYPE_MAX exceed the range
+ of the type, but we don't actually need/want 1<<REG_TYPE_MAX.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Try to avoid inappropriate default errors
+ After parsing a '{' and the first register, parse_typed_reg would
+ report errors in subsequent registers in the same way as for the
+ first register. It used set_default_error, which reports errors
+ of the form "operand N must be X".
+
+ The problem is that if there are multiple opcode entries for the
+ same mnemonic, there could be several matches that lead to a
+ default error. There's no guarantee that the default error for
+ the register list is the one that will be chosen.
+
+ To take an example from the testsuite:
+
+ ext z0.b,{z31.b,z32.b},#0
+
+ gave:
+
+ operand 2 must be an SVE vector register
+
+ with the error being reported against the single-vector version
+ of ext, even though the operand is clearly a list.
+
+ This patch uses set_fatal_syntax_error to bump the priority of the
+ error once we're sure that the operand is a list of the right type.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Improve errors for malformed register lists
+ parse_typed_reg is used for parsing both bare registers and
+ registers that occur in lists. If it doesn't see a register,
+ or sees an unexpected kind of register, it queues a default
+ error to report the problem. These default errors have the form
+ "operand N must be an X", where X comes from the operand table.
+
+ If there are multiple opcode entries that report default errors,
+ GAS tries to pick the most appropriate one, using the opcode
+ table order as a tiebreaker. But this can lead to cases where
+ a syntax error in a register list is reported against an opcode
+ that doesn't accept register lists. For example, the unlikely
+ error:
+
+ ext z0.b,{,},#0
+
+ is reported as:
+
+ operand 2 must be an SVE vector register -- `ext z0.b,{,},#0'
+
+ even though operand 2 can be a register list.
+
+ If we've parsed the opening '{' of a register list, and then see
+ something that isn't remotely register-like, it seems better to
+ report that directly as a syntax error, rather than rely on the
+ default error. The operand won't be a valid list of anything,
+ so there's no need to pick a specific Y in "operand N must be
+ a list of Y".
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak parsing of integer & FP registers
+ Integer registers were parsed indirectly through
+ aarch64_reg_parse_32_64 (and thus aarch64_addr_reg_parse) rather
+ than directly through parse_reg. This was because we need the
+ qualifier associated with the register, and the logic to calculate
+ that was buried in aarch64_addr_reg_parse.
+
+ The code that parses FP registers had the same need, but it
+ open-coded the calculation of the qualifier.
+
+ This patch tries to handle both cases in the same way. It is
+ needed by a later patch that tries to improve the register-related
+ diagnostics.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak errors for base & offset registers
+ parse_address_main currently uses get_reg_expected_msg to
+ report invalid base and offset registers, but the disadvantage
+ of doing that is that it isn't immediately clear which register
+ is wrong (the base or the offset).
+
+ A later patch moves away from using get_reg_expected_msg for failed
+ type checks, but doing that here didn't seem like the best approach.
+ The patch tries to use more tailored messages instead.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak error for missing immediate offset
+ This patch tweaks the error message that is printed when
+ a ZA-style index is missing the immediate offset.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Move w12-w15 range check to libopcodes
+ In SME, the vector select register had to be in the range
+ w12-w15, so it made sense to enforce that during parsing.
+ However, SME2 adds instructions for which the range is
+ w8-w11 instead.
+
+ This patch therefore moves the range check from the parsing
+ stage to the constraint-checking stage.
+
+ Also, the previous error used a capitalised range W12-W15,
+ whereas other register range errors used lowercase ranges
+ like p0-p7. A quick internal poll showed a preference for
+ the lowercase form, so the patch uses that.
+
+ The patch uses "selection register" rather than "vector
+ select register" so that the terminology extends more
+ naturally to PSEL.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Commonise index parsing
+ Just a minor clean-up to factor out the index parsing, partly to
+ ensure that the error handling remains consistent. No behavioural
+ change intended.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Consolidate ZA slice parsing
+ Now that parse_typed_reg checks the range of tile register numbers
+ and libopcodes checks the range of vector select offsets, there's
+ very little difference between the parsing of ZA tile indices,
+ ZA array indices, and PSEL indices. The main one is that ZA
+ array indices don't currently allow "za" to be qualified,
+ but we need to remove that restriction for SME2.
+
+ This patch therefore consolidates all three parsers into a single
+ routine, parameterised by the type of register that they expect.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Move ZA range checks to aarch64-opc.c
+ This patch moves the range checks on ZA vector select offsets from
+ gas to libopcodes. Doing the checks there means that the error
+ messages contain the expected range. It also fits in better
+ with the error severity scheme, which becomes important later.
+ (This is because out-of-range indices are treated as more severe than
+ syntax errors, on the basis that parsing must have succeeded if we get
+ to the point of checking the completed opcode.)
+
+ The patch also adds a new check_za_access function for checking
+ ZA accesses. That's a bit over the top for one offset check, but the
+ function becomes more complex with later patches.
+
+ sme-9-illegal.s checked for an invalid .q suffix using:
+
+ psel p1, p15, p3.q[w15]
+
+ but this is doubly invalid because it misses the immediate part
+ of the index. The patch keeps that test but adds another with
+ a zero index, so that .q is the only thing wrong.
+
+ The aarch64-tbl.h change includes neatening up the backslash
+ positions.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Pass aarch64_indexed_za to parsers
+ ZA indices have more parts than most operands, so passing these
+ parts around individually is more awkward than for other operand
+ types. Things aren't too bad at the moment, but SME2 adds two
+ further pieces: an offset range and a vector group size.
+
+ This patch therefore replaces arguments for the individual pieces
+ with a single argument for the index as a whole.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Make indexed_za use 64-bit immediates
+ A later patch moves the range checking for ZA vector select
+ offsets from gas to libopcodes. That in turn requires the
+ immediate field to be big enough to support all parsed values.
+
+ This shouldn't be a particularly size-sensitive structure,
+ so there should be no memory problems with doing this.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Rename za_tile_vector to za_index
+ za_tile_vector is also used for indexing ZA as a whole, rather than
+ just for indexing tiles. The former is more common than the latter
+ in SME2, so this patch generalises the name to "indexed_za".
+
+ The patch also names the associated structure, so that later patches
+ can reuse it during parsing.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Treat ZA as a register
+ We already treat the ZA tiles ZA0-ZA15 as registers. This patch
+ does the same for ZA itself. parse_sme_zero_mask can then parse
+ ZA tiles and ZA in the same way, through parsed_type_reg.
+
+ One important effect of going through parsed_type_reg (in general)
+ is that it allows ZA to take qualifiers. This is necessary for many
+ SME2 instructions.
+
+ However, to support existing unqualified uses of ZA, parse_reg_with_qual
+ needs to treat the qualiier as optional. Hopefully the net effect is
+ to give better error messages, since now that SME2 makes "za.<T>"
+ valid in some contexts, it might be natural to use it (incorrectly)
+ in ZERO too.
+
+ While there, the patch also tweaks the error messages for invalid
+ ZA tiles, to try to make some cases more specific.
+
+ For now, parse_sme_za_array just uses parse_reg, rather than
+ parse_typed_reg/parse_reg_with_qual. A later patch consolidates
+ the parsing further.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Consolidate ZA tile range checks
+ Now that all parsing of ZA tile names goes through parse_typed_reg,
+ we can check there for out-of-range tile numbers. The other check
+ performed by parse_sme_zada_operand was to reject .q, but that can
+ now be done via F_STRICT instead. (.q tiles are valid in other
+ contexts, so they shouldn't be rejected in parse_typed_reg.)
+
+ aarch64: Reuse parse_typed_reg for ZA tiles
+ This patch reuses the general parse_typed_reg for ZA tiles.
+ This involves adding a way of suppressing the usual treatment
+ of register indices, since ZA indices look very different from
+ Advanced SIMD and SVE vector indices.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Rework parse_typed_reg interface
+ parse_typed_reg returned a register number and passed the
+ register type back using a pointer parameter. It seems simpler
+ to return the register entry instead, since that has both pieces
+ of information in one place.
+
+ The patch also replaces the boolean in_reg_list parameter with
+ a mask of flags. This hopefully makes calls easier to read
+ (more self-documenting than "true" or "false"), but more
+ importantly, it allows a later patch to add a second flag.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Move vectype_to_qualifier further up
+ This patch just moves vectype_to_qualifier further up, so that
+ a later patch can call it at an earlier point in the file.
+ No behavioural change intended.
+
+ aarch64: Add REG_TYPE_ZATHV
+ This patch adds a multi-register type that includes both REG_TYPE_ZATH
+ and REG_TYPE_ZATV. This slightly simplifies the existing code, but the
+ main purpose is to enable later patches.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Rename REG_TYPE_ZA* to REG_TYPE_ZAT*
+ The ZA tile registers were called REG_TYPE_ZA, REG_TYPE_ZAH and
+ REG_TYPE_ZAV. However, a later patch wants to make plain "za"
+ a register type too, and REG_TYPE_ZA is the obvious name for that.
+
+ This patch therefore adds "T" (tile) to the existing names.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Use aarch64_operand_error more widely
+ GAS's aarch64_instruction had its own cut-down error record,
+ but it's better for later patches if it reuses the binutils-wide
+ aarch64_operand_error instead. The main difference is that
+ aarch64_operand_error can store arguments to the error while
+ aarch64_instruction couldn't.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Make SME instructions use F_STRICT
+ This patch makes all SME instructions use F_STRICT, so that qualifiers
+ have to be provided explicitly rather than being inferred from other
+ operands. The main change is to move the qualifier setting from the
+ operand-level decoders to the opcode level.
+
+ This is one step towards consolidating the ZA parsing code and
+ extending it to handle SME2.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Fix SVE2 register/immediate distinction
+ GAS refuses to interpret register names like x0 as unadorned
+ immediates, due to the obvious potential for confusion with
+ register operands. (An explicit #x0 is OK.)
+
+ For compatibility reasons, we can't extend the set of registers
+ that GAS rejects for existing instructions. For example:
+
+ mov x0, z0
+
+ was valid code before SVE was added, so it needs to stay valid
+ code even when SVE is enabled. But we can make GAS reject newer
+ registers in newer instructions. The SVE instruction:
+
+ and z0.s, z0.s, z0.h
+
+ is therefore invalid, rather than z0.h being an immediate.
+
+ This patch extends the SVE behaviour to SVE2. The old call
+ to AARCH64_CPU_HAS_FEATURE was technically the wrong way around,
+ although it didn't matter in practice for base SVE instructions
+ since their avariants only set SVE.
+
+2023-03-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Restrict range of PRFM opcodes
+ In the register-index forms of PRFM, the unallocated prefetch opcodes
+ 24-31 have been reused for the encoding of the new RPRFM instruction.
+ The PRFM opcode space is now capped at 23 for these forms. The other
+ forms of PRFM are unaffected.
+
+ aarch64: Fix PSEL opcode mask
+ The opcode mask for PSEL was missing some bits, which meant
+ that some upcoming SME2 opcodes would be misinterpreted as PSELs.
+
+ aarch64: Add sme-i16i64 and sme-f64f64 aliases
+ Most extension flags are named after the associated architectural
+ FEAT_* flags, but sme-i64 and sme-f64 were exceptions. This patch
+ adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too
+ for compatibility.
+
+2023-03-30 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access triggered by parsing corrupt DWARF info.
+ PR 30284
+ * dwarf.c (read_and_display_attr_value): Detect and ignore negative base values.
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: Add new gdb.unwinder.FrameId class
+ When writing an unwinder it is necessary to create a new class to act
+ as a frame-id. This new class is almost certainly just going to set a
+ 'sp' and 'pc' attribute within the instance.
+
+ This commit adds a little helper class gdb.unwinder.FrameId that does
+ this job. Users can make use of this to avoid having to write out
+ standard boilerplate code any time they write an unwinder.
+
+ Of course, if the user wants their FrameId class to be more
+ complicated in some way, then they can still write their own class,
+ just like they could before.
+
+ I've simplified the example code in the documentation to now use the
+ new helper class, and I've also made use of this helper within the
+ testsuite.
+
+ Any existing user code will continue to work just as it did before
+ after this change.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args
+ Currently when creating a gdb.UnwindInfo object a user must call
+ gdb.PendingFrame.create_unwind_info and pass a frame-id object.
+
+ The frame-id object should have at least a 'sp' attribute, and
+ probably a 'pc' attribute too (it can also, in some cases have a
+ 'special' attribute).
+
+ Currently all of these frame-id attributes need to be gdb.Value
+ objects, but the only reason for that requirement is that we have some
+ code in py-unwind.c that only handles gdb.Value objects.
+
+ If instead we switch to using get_addr_from_python in py-utils.c then
+ we will support both gdb.Value objects and also raw numbers, which
+ might make things simpler in some cases.
+
+ So, I started rewriting pyuw_object_attribute_to_pointer (in
+ py-unwind.c) to use get_addr_from_python. However, while looking at
+ the code I noticed a problem.
+
+ The pyuw_object_attribute_to_pointer function returns a boolean flag,
+ if everything goes OK we return true, but we return false in two
+ cases, (1) when the attribute is not present, which might be
+ acceptable, or might be an error, and (2) when we get an error trying
+ to extract the attribute value, in which case a Python error will have
+ been set.
+
+ Now in pending_framepy_create_unwind_info we have this code:
+
+ if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
+ {
+ PyErr_SetString (PyExc_ValueError,
+ _("frame_id should have 'sp' attribute."));
+ return NULL;
+ }
+
+ Notice how we always set an error. This will override any error that
+ is already set.
+
+ So, if you create a frame-id object that has an 'sp' attribute, but
+ the attribute is not a gdb.Value, then currently we fail to extract
+ the attribute value (it's not a gdb.Value) and set this error in
+ pyuw_object_attribute_to_pointer:
+
+ rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
+ if (!rc)
+ PyErr_Format (
+ PyExc_ValueError,
+ _("The value of the '%s' attribute is not a pointer."),
+ attr_name);
+
+ Then we return to pending_framepy_create_unwind_info and immediately
+ override this error with the error about 'sp' being missing.
+
+ This all feels very confused.
+
+ Here's my proposed solution: pyuw_object_attribute_to_pointer will now
+ return a tri-state enum, with states OK, MISSING, or ERROR. The
+ meanings of these states are:
+
+ OK - Attribute exists and was extracted fine,
+
+ MISSING - Attribute doesn't exist, no Python error was set.
+
+ ERROR - Attribute does exist, but there was an error while
+ extracting it, a Python error was set.
+
+ We need to update pending_framepy_create_unwind_info, the only user of
+ pyuw_object_attribute_to_pointer, but now I think things are much
+ clearer. Errors from lower levels are not blindly overridden with the
+ generic meaningless error message, but we still get the "missing 'sp'
+ attribute" error when appropriate.
+
+ This change also includes the switch to get_addr_from_python which was
+ what started this whole journey.
+
+ For well behaving user code there should be no visible changes after
+ this commit.
+
+ For user code that hits an error, hopefully the new errors should be
+ more helpful in figuring out what's gone wrong.
+
+ Additionally, users can now use integers for the 'sp' and 'pc'
+ attributes in their frame-id objects if that is useful.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have value_as_address call unpack_pointer
+ While refactoring some other code in gdb/python/* I wanted to merge
+ two code paths. One path calls value_as_address, while the other
+ calls unpack_pointer.
+
+ I suspect calling value_as_address is the correct choice, but, while
+ examining the code I noticed that value_as_address calls unpack_long
+ rather than unpack_pointer.
+
+ Under the hood, unpack_pointer does just call unpack_long so there's
+ no real difference here, but it feels like value_as_address should
+ call unpack_pointer.
+
+ I've updated the code to use unpack_pointer, and changed a related
+ comment to say that we call unpack_pointer. I've also adjusted the
+ header comment on value_as_address. The existing header refers to
+ some code that is now commented out.
+
+ Rather than trying to describe the whole algorithm of
+ value_as_address, which is already well commented within the function,
+ I've just trimmed the comment on value_as_address to be a brief
+ summary of what the function does.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.UnwindInfo
+ It is not currently possible to directly create gdb.UnwindInfo
+ instances, they need to be created by calling
+ gdb.PendingFrame.create_unwind_info so that the newly created
+ UnwindInfo can be linked to the pending frame.
+
+ As such there's no tp_init method defined for UnwindInfo.
+
+ A consequence of all this is that it doesn't really make sense to
+ allow sub-classing of gdb.UnwindInfo. Any sub-class can't call the
+ parents __init__ method to correctly link up the PendingFrame
+ object (there is no parent __init__ method). And any instances that
+ sub-classes UnwindInfo but doesn't call the parent __init__ is going
+ to be invalid for use in GDB.
+
+ This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo
+ class, which prevents the class being sub-classed. Then I've added a
+ test to check that this is indeed prevented.
+
+ Any functional user code will not have any issues with this change.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add __repr__ for PendingFrame and UnwindInfo
+ Having a useful __repr__ method can make debugging Python code that
+ little bit easier. This commit adds __repr__ for gdb.PendingFrame and
+ gdb.UnwindInfo classes, along with some tests.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add some additional methods to gdb.PendingFrame
+ The gdb.Frame class has far more methods than gdb.PendingFrame. Given
+ that a PendingFrame hasn't yet been claimed by an unwinder, there is a
+ limit to which methods we can add to it, but many of the methods that
+ the Frame class has, the PendingFrame class could also support.
+
+ In this commit I've added those methods to PendingFrame that I believe
+ are safe.
+
+ In terms of implementation: if I was starting from scratch then I
+ would implement many of these (or most of these) as attributes rather
+ than methods. However, given both Frame and PendingFrame are just
+ different representation of a frame, I think there is value in keeping
+ the interface for the two classes the same. For this reason
+ everything here is a method -- that's what the Frame class does.
+
+ The new methods I've added are:
+
+ - gdb.PendingFrame.is_valid: Return True if the pending frame
+ object is valid.
+
+ - gdb.PendingFrame.name: Return the name for the frame's function,
+ or None.
+
+ - gdb.PendingFrame.pc: Return the $pc register value for this
+ frame.
+
+ - gdb.PendingFrame.language: Return a string containing the
+ language for this frame, or None.
+
+ - gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
+ for the current location within the pending frame, or None.
+
+ - gdb.PendingFrame.block: Return a gdb.Block for the current
+ pending frame, or None.
+
+ - gdb.PendingFrame.function: Return a gdb.Symbol for the current
+ pending frame, or None.
+
+ In every case I've just copied the implementation over from gdb.Frame
+ and cleaned the code slightly e.g. NULL to nullptr. Additionally each
+ function required a small update to reflect the PendingFrame type, but
+ that's pretty minor.
+
+ There are tests for all the new methods.
+
+ For more extensive testing, I added the following code to the file
+ gdb/python/lib/command/unwinders.py:
+
+ from gdb.unwinder import Unwinder
+
+ class TestUnwinder(Unwinder):
+ def __init__(self):
+ super().__init__("XXX_TestUnwinder_XXX")
+
+ def __call__(self,pending_frame):
+ lang = pending_frame.language()
+ try:
+ block = pending_frame.block()
+ assert isinstance(block, gdb.Block)
+ except RuntimeError as rte:
+ assert str(rte) == "Cannot locate block for frame."
+ function = pending_frame.function()
+ arch = pending_frame.architecture()
+ assert arch is None or isinstance(arch, gdb.Architecture)
+ name = pending_frame.name()
+ assert name is None or isinstance(name, str)
+ valid = pending_frame.is_valid()
+ pc = pending_frame.pc()
+ sal = pending_frame.find_sal()
+ assert sal is None or isinstance(sal, gdb.Symtab_and_line)
+ return None
+
+ gdb.unwinder.register_unwinder(None, TestUnwinder())
+
+ This registers a global unwinder that calls each of the new
+ PendingFrame methods and checks the result is of an acceptable type.
+ The unwinder never claims any frames though, so shouldn't change how
+ GDB actually behaves.
+
+ I then ran the testsuite. There was only a single regression, a test
+ that uses 'disable unwinder' and expects a single unwinder to be
+ disabled -- the extra unwinder is now disabled too, which changes the
+ test output. So I'm reasonably confident that the new methods are not
+ going to crash GDB.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c
+ This commit copies the pattern that is present in many other py-*.c
+ files: having a single macro to check that the Python object is still
+ valid.
+
+ This cleans up the code a little throughout the py-unwind.c file.
+
+ Some of the exception messages will change slightly with this commit,
+ though the type of the exceptions is still ValueError in all cases.
+
+ I started writing some tests for this change and immediately ran into
+ a problem: GDB would crash. It turns out that the PendingFrame
+ objects are not being marked as invalid!
+
+ In pyuw_sniffer where the pending frames are created, we make use of a
+ scoped_restore to invalidate the pending frame objects. However, this
+ only restores the pending_frame_object::frame_info field to its
+ previous value -- and it turns out we never actually give this field
+ an initial value, it's left undefined.
+
+ So, when the scoped_restore (called invalidate_frame) performs its
+ cleanup, it actually restores the frame_info field to an undefined
+ value. If this undefined value is not nullptr then any future
+ accesses to the PendingFrame object result in undefined behaviour and
+ most likely, a crash.
+
+ As part of this commit I now initialize the frame_info field, which
+ ensures all the new tests now pass.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: remove unneeded nullptr check in frapy_block
+ Spotted a redundant nullptr check in python/py-frame.c in the function
+ frapy_block. This was introduced in commit 57126e4a45e3000e when we
+ expanded an earlier check in return early if the pointer in question
+ is nullptr.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: make the gdb.unwinder.Unwinder class more robust
+ This commit makes a few related changes to the gdb.unwinder.Unwinder
+ class attributes:
+
+ 1. The 'name' attribute is now a read-only attribute. This prevents
+ user code from changing the name after registering the unwinder. It
+ seems very unlikely that any user is actually trying to do this in
+ the wild, so I'm not very worried that this will upset anyone,
+
+ 2. We now validate that the name is a string in the
+ Unwinder.__init__ method, and throw an error if this is not the
+ case. Hopefully nobody was doing this in the wild. This should
+ make it easier to ensure the 'info unwinder' command shows sane
+ output (how to display a non-string name for an unwinder?),
+
+ 3. The 'enabled' attribute is now implemented with a getter and
+ setter. In the setter we ensure that the new value is a boolean,
+ but the real important change is that we call
+ 'gdb.invalidate_cached_frames()'. This means that the backtrace
+ will be updated if a user manually disables an unwinder (rather than
+ calling the 'disable unwinder' command). It is not unreasonable to
+ think that a user might register multiple unwinders (relating to
+ some project) and have one command that disables/enables all the
+ related unwinders. This command might operate by poking the enabled
+ attribute of each unwinder object directly, after this commit, this
+ would now work correctly.
+
+ There's tests for all the changes, and lots of documentation updates
+ that both cover the new changes, but also further improve (I think)
+ the general documentation for GDB's Unwinder API.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-30 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access when an accessing a zer0-lengthverdef table.
+ PR 30285
+ * elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated.
+
+2023-03-30 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Add version symbols to libgprofng.ver
+ gprofng/ChangeLog
+ 2023-03-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30089
+ * libcollector/libgprofng.ver: Add version symbols.
+ * libcollector/synctrace.c: Fix typo for pthread_mutex_lock.
+
+2023-03-30 Alan Modra <amodra@gmail.com>
+
+ Setting sh_link for SHT_REL/SHT_RELA
+ It's wrong to have an alloc reloc section trying to use a non-alloc
+ symbol table.
+
+ * elf.c (assign_section_numbers <SHT_REL, SHT_RELA>): Correct
+ comment. Always set sh_link to .dynsym for alloc reloc
+ sections and to .symtab for non-alloc.
+
+2023-03-30 Alan Modra <amodra@gmail.com>
+
+ Fix memory leak in bfd_get_debug_link_info_1
+ * opncls.c (bfd_get_alt_debug_link_info): Don't bother freeing
+ after bfd_malloc_and_get_section failure.
+ (get_build_id): Likewise.
+ (bfd_get_debug_link_info_1): Likewise. Free section contents
+ when crc not present.
+ * section.c (bfd_malloc_and_get_section): Document that the
+ buffer is NULL on error return.
+
+ Tidy leaked objcopy memory
+ * objcopy.c (delete_symbol_htabs): Also free symbols.
+ (write_debugging_info): Free strings and syms once written.
+ * wrstabs.c (write_stabs_in_sections_debugging_info): memset
+ entire info struct. Free hash tables before returning. Free
+ syms on error return.
+
+ Tidy memory on addr2line failures
+ * addr2line.c (process_file): Close bfd on error paths.
+
+2023-03-30 Roland McGrath <mcgrathr@google.com>
+
+ Fix typo in ld manual --enable-non-contiguous-regions example
+
+2023-03-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-30 Palmer Dabbelt <palmer@rivosinc.com>
+
+ RISC-V: PR28789, Reject R_RISCV_PCREL relocations with ABS symbol in PIC/PIE.
+ The non-preemptible SHN_ABS symbol with a pc-relative relocation should be
+ disallowed when generating shared object (pic and pie). Generally, the
+ following cases, which refer to pr25749, will cause a symbol be
+ non-preemptible,
+
+ * -pie, or -shared with -symbolic
+ * STV_HIDDEN, STV_INTERNAL, STV_PROTECTED
+ * Have dynamic symbol table, but without the symbol
+ * VER_NDX_LOCAL
+
+ However, PCREL_HI20/LO12 relocs are always bind locally when generating
+ shared object, so not only the non-preemptible absolute symbol need to
+ be disallowed, all absolute symbol references need but except that they
+ are defined in linker script. If we also disallow the absolute symbol
+ in linker script, then the glibc-linux toolchain build failed, so regard
+ them as pc-relative symbols, just like what x86 did.
+
+ Maybe we should add this check for all pc-relative relocations, rather
+ than just handle in R_RISCV_PCREL relocs. Ideally, since the value of
+ SHN_ABS symbol is a constant, only S - A relocations should be allowed
+ in the shared object, so only BFD_RELOC_8/16/32/64 are allowed, which
+ means R_RISCV_32/R_RISCV_64.
+
+ bfd/
+ PR 28789
+ * elfnn-riscv.c (riscv_elf_check_relocs): The absolute symbol cannot be
+ referneced with pc-relative relocation when generating shared object.
+ ld/
+ PR 28789
+ * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+ * ld/testsuite/ld-riscv-elf/pcrel-reloc*: New testcases.
+
+2023-03-30 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Clarify link behaviors of R_RISCV_32/64 relocations with ABS symbol.
+ There are two improvements, which are all referenced to aarch64,
+
+ * R_RISCV_32 with non ABS symbol cannot be used under RV64 when making
+ shard objects.
+
+ * Don't need dynamic relocation for R_RISCV_32/64 under RV32/RV64 when
+ making shared objects, if the referenced symbol is local ABS symbol.
+
+ However, considering this link,
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/341
+
+ Seems like we should makes all R_RISCV_32/64 relocs with ABS symbol
+ that don't need any dynamic relocations when making the shared objects.
+ But anyway, I just sync the current behavior as aarch64 ld, in case
+ there are any unexpected behaviors happen.
+
+ Passed the gcc/binutils regressions in riscv-gnu-toolchain.
+
+ bfd/
+ * elfnn-riscv.c (riscv_elf_check_relocs): Only allow R_RISCV_32 with ABS
+ symbol under RV64.
+ (riscv_elf_relocate_section): R_RISCV_32/64 with local ABS symbol under
+ RV32/RV64 doesn't need any dynamic relocation when making shared objects.
+ I just make the implementations similar to other targets, so that will be
+ more easy to mainatain.
+ ld/
+ * testsuite/ld-riscv-elf/data-reloc*: New testcases.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Added new data-reloc* testcases,
+ and need to make ifunc-seperate* testcases work for rv32.
+ * testsuite/ld-riscv-elf/ifunc-seperate-caller-nonplt.s: Likewise.
+ * testsuite/ld-riscv-elf/ifunc-seperate-caller-plt.s: Likewise.
+
+2023-03-30 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Extract the ld code which are too complicated, and may be reused.
+ These types of codes are different for each target, I am not sure what are the
+ best for RISC-V, so extract them out may be more easy to compare what's the
+ difference.
+
+ bfd/
+ * elfnn-riscv.c (RISCV_NEED_DYNAMIC_RELOC): New defined. Extracted
+ from riscv_elf_check_relocs, to see if dynamic reloc is needed for the
+ specific relocation.
+ (RISCV_GENERATE_DYNAMIC_RELOC): New defined. Extracted from
+ riscv_elf_relocate_section, to see if R_RISCV_32/64 need to generate
+ dynamic relocation.
+ (RISCV_COPY_INPUT_RELOC): New defined. Extracted from
+ riscv_elf_relocate_section, to see if R_RISCV_32/64 need to copy itslef
+ tp output file.
+ (RISCV_RESOLVED_LOCALLY): New defined. Extracted from
+ riscv_elf_relocate_section, to see if R_RISCV_GOT_HI20 can be resolved
+ locally.
+
+2023-03-29 Tom Tromey <tromey@adacore.com>
+
+ Use the correct frame when evaluating a dynamic property
+ The test case in this patch shows an unusual situation: an Ada array
+ has a dynamic bound, but the bound comes from a frame that's referred
+ to by the static link. This frame is correctly found when evaluating
+ the array variable itself, but is lost when evaluating the array's
+ bounds.
+
+ This patch fixes the problem by passing this frame through to
+ value_at_lazy in the DWARF expression evaluator.
+
+2023-03-29 Tom Tromey <tromey@adacore.com>
+
+ Pass a frame to value_at_lazy and value_from_contents_and_address
+ This patch adds a 'frame' parameter to value_at_lazy and ensures that
+ it is passed down to the call to resolve_dynamic_type. This required
+ also adding a frame parameter to value_from_contents_and_address.
+
+ Nothing passes this parameter to value_at_lazy yet, so this patch
+ should have no visible effect.
+
+2023-03-29 Tom Tromey <tromey@adacore.com>
+
+ Add frame parameter to resolve_dynamic_type
+ This adds a frame parameter to resolve_dynamic_type and arranges for
+ it to be passed through the call tree and, in particular, to all calls
+ to dwarf2_evaluate_property.
+
+ Nothing passes this parameter yet, so this patch should have no
+ visible effect.
+
+ A 'const frame_info_ptr *' is used here to avoid including frame.h
+ from gdbtypes.h.
+
+2023-03-29 Tom Tromey <tromey@adacore.com>
+
+ Remove version_at_least
+ version_at_least is a less capable variant of version_compare, so this
+ patch removes it.
+
+ Rewrite version_compare and rust_at_least
+ This rewrites version_compare to allow the input lists to have
+ different lengths, then rewrites rust_at_least to use version_compare.
+
+ Introduce rust_at_least helper proc
+ This adds a 'rust_at_least' helper proc, for checking the version of
+ the Rust compiler in use. It then changes various tests to use this
+ with 'require'.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require gnatmake 11 for gdb.ada/verylong.exp
+ With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
+ ...
+ compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
+ prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
+ prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
+ gnatmake: "prog.adb" compilation error
+
+ FAIL: gdb.ada/verylong.exp: compilation prog.adb
+ ...
+
+ AFAICT, support for Long_Long_Long_Integer was added in gcc 11.
+
+ Fix this by requiring gnatmake version 11 or higher in the test-case.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ doc: fix informations typo in gdb.texinfo
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-03-29 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, infcmd: remove redundant ERROR_NO_INFERIOR in continue_command
+ The ERROR_NO_INFERIOR macro is already called at the beginning of the
+ function continue_command. Since target/inferior are not switched in-between,
+ the second call to it is redundant.
+
+ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2023-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move displaced_step_dump_bytes into gdbsupport (and rename)
+ It was pointed out during review of another patch that the function
+ displaced_step_dump_bytes really isn't specific to displaced stepping,
+ and should really get a more generic name and move into gdbsupport/.
+
+ This commit does just that. The function is renamed to
+ bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The
+ function implementation doesn't really change. Much...
+
+ ... I have updated the function to take an array view, which makes it
+ slightly easier to call in a couple of places where we already have a
+ gdb::bytes_vector. I've then added an inline wrapper to convert a raw
+ pointer and length into an array view, which is used in places where
+ we don't easily have a gdb::bytes_vector (or similar).
+
+ Updated all users of displaced_step_dump_bytes.
+
+ There should be no user visible changes after this commit.
+
+ Finally, I ended up having to add an include of gdb_assert.h into
+ array-view.h. When I include array-view.h into common-utils.h I ran
+ into build problems because array-view.h calls gdb_assert.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: more debug output for displaced stepping
+ While investigating a displaced stepping issue I wanted an easy way to
+ see what GDB thought the original instruction was, and what
+ instruction GDB replaced that with when performing the displaced step.
+
+ We do print out the address that is being stepped, so I can track down
+ the original instruction, I just need to go find the information
+ myself.
+
+ And we do print out the bytes of the new instruction, so I can figure
+ out what the replacement instruction was, but it's not really easy.
+
+ Also, the code that prints the bytes of the replacement instruction
+ only prints 4 bytes, which clearly isn't always going to be correct.
+
+ In this commit I remove the existing code that prints the bytes of the
+ replacement instruction, and add two new blocks of code to
+ displaced_step_prepare_throw. This new code prints the original
+ instruction, and the replacement instruction. In each case we print
+ both the bytes that make up the instruction and the completely
+ disassembled instruction.
+
+ Here's an example of what the output looks like on x86-64 (this is
+ with 'set debug displaced on'). The two interesting lines contain the
+ strings 'original insn' and 'replacement insn':
+
+ (gdb) step
+ [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
+ [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 <puts@got.plt>
+ [displaced] prepare: selected buffer at 0x401052
+ [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
+ [displaced] fixup_riprel: %rip-relative addressing used.
+ [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
+ [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
+ [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
+ [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx)
+ [displaced] finish: restored 2892655.2892655.0 0x401052
+ [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
+ [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
+ 0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
+ (gdb)
+
+ One final note. For many targets that support displaced stepping (in
+ fact all targets except ARM) the replacement instruction is always a
+ single instruction. But on ARM the replacement could actually be a
+ series of instructions.
+
+ The debug code tries to handle this by disassembling the entire
+ displaced stepping buffer. Obviously this might actually print more
+ than is necessary, but there's (currently) no easy way to know how
+ many instructions to disassemble; that knowledge is all locked in the
+ architecture specific code. Still I don't think it really hurts, if
+ someone is looking at this debug then hopefully they known what to
+ expect.
+
+ Obviously we can imagine schemes where the architecture specific
+ displaced stepping code could communicate back how many bytes its
+ replacement sequence was, and then our debug print code could use this
+ to limit the disassembly. But this seems like a lot of effort just to
+ save printing a few additional instructions in some debug output.
+
+ I'm not proposing to do anything about this issue for now.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-symbol.exp for remote host
+ Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less
+ strict.
+
+ Likewise in gdb.guile/scm-symtab.exp.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix /gdb.guile/scm-parameter.exp for remote host
+ Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
+ account that gdb_reinitialize_dir has no effect for remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host
+ Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host
+ Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-cmd.exp without readline
+ Fix test-case gdb.guile/scm-cmd.exp using readline_is_used.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/guile.exp for remote host
+ Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-29 Alan Modra <amodra@gmail.com>
+
+ Sanity check section size in bfd_init_section_compress_status
+ This function doesn't just initialise for compression, it actually
+ compresses. This patch sanity checks section size before allocating
+ buffers for the uncompressed contents.
+
+ * compress.c (bfd_init_section_compress_status): Sanity check
+ section size.
+
+2023-03-29 Alan Modra <amodra@gmail.com>
+
+ Re: Fix an aout memory leak
+ We have way too much duplicated code in bfd. Apply dd3a3d0af9f6 and
+ 920581c57e08 to pdp11.c.
+
+ * pdp11.c (bfd_free_cached_info): Free line_buf. Return true
+ if tdata.aout_data is NULL.
+
+2023-03-29 Alan Modra <amodra@gmail.com>
+
+ ld testsuite CFLAGS_FOR_TARGET
+ run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it
+ detects the program being run is a compiler. Since the program being
+ run in lto.exp linking pr28138 is "sh", we need to add these by hand.
+ This isn't exactly as run_host_cmd does, as it lacks reordering of
+ any user -B option in $CC_FOR_TARGET, but it's better than ignoring
+ gcc_B_opt. This fixes a mips64 testsuite fail.
+
+ ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there
+ is no need for the ld_compile command line to include
+ CFLAGS_FOR_TARGET. Fixing this is just a tidy.
+
+ * testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET
+ and $ld_L_opt to pr28138 link line.
+ * testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass
+ unnecessary flags to ld_compile.
+ (run_ld_link_exec_tests, run_cc_link_tests): Likewise.
+
+2023-03-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-28 Tom Tromey <tom@tromey.com>
+
+ Rename "raw" to "unrelocated"
+ Per an earlier discussion, this patch renames the existing "raw" APIs
+ to use the word "unrelocated" instead.
+
+ Use unrelocated_addr in minimal symbols
+ This changes minimal symbols to use unrelocated_addr. I believe this
+ detected a latent bug in add_pe_forwarded_sym.
+
+ Use unrelocated_addr in psymbols
+ This changes psymbols themselves to use unrelocated_addr. This
+ transform is largely mechanical. I don't think it finds any bugs.
+
+ Use unrelocated_addr in partial symbol tables
+ This changes partial symbol tables to use unrelocated_addr for the
+ text_high and text_low members. This revealed some latent bugs in
+ ctfread.c, which are fixed here.
+
+ Move definition of unrelocated_addr earlier
+ This moves the definition of unrelocated_addr a bit earlier in
+ symtab.h, so that it can be used elsewhere in the file.
+
+ Use function_view in gdb_bfd_lookup_symbol
+ This changes gdb_bfd_lookup_symbol to use a function_view. This
+ simplifies the code a little bit.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.btrace/multi-inferior.exp for remote host
+ Fix test-case gdb.btrace/multi-inferior.exp for remote host using
+ gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.btrace/gcore.exp for remote host
+ Fix test-case gdb.btrace/gcore.exp for remote host using
+ host_standard_output.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.btrace/reconnect.exp for remote target
+ Fix test-case gdb.btrace/reconnect.exp for target board
+ remote-gdbserver-on-localhost using gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom Tromey <tromey@adacore.com>
+
+ Put pretty-printers to_string output in varobj result
+ PR mi/11335 points out that an MI varobj will not display the result
+ of a pretty-printer's "to_string" method. Instead, it always shows
+ "{...}".
+
+ This does not seem very useful, and there have been multiple
+ complaints about it over the years. This patch changes varobj to emit
+ this string when possible, and updates the test suite.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
+
+2023-03-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: allow "require" callbacks to provide a reason
+ When an allow_* proc returns false, it can be a bit difficult what check
+ failed exactly, if the procedure does multiple checks. To make
+ investigation easier, I propose to allow the "require" callbacks to be
+ able to return a list of two elements: the zero/non-zero value, and a
+ reason string.
+
+ Use the new feature in allow_hipcc_tests to demonstrate it (it's also
+ where I hit actually hit this inconvenience). On my computer (where GDB
+ is built with amd-dbgapi support but where I don't have a suitable GPU
+ target), I get:
+
+ UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)
+
+ vs before:
+
+ UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests
+
+ Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/server-kill-python.exp for remote host
+ Fix test-case gdb.server/server-kill-python.exp for remote host using
+ gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/sysroot.exp for remote host
+ Fix test-case gdb.server/sysroot.exp for remote host, by:
+ - using gdb_remote_download, and
+ - disabling the "local" scenario for remote host/target, unless
+ remote host == remote target.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require non-remote host for gdb.server/multi-ui-errors.exp
+ Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
+ it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
+ remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/solib-list.exp for remote host
+ Fix test-case gdb.server/solib-list.exp for remote host using
+ gdb_remote_download.
+
+ Likewise in another test-case.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/file-transfer.exp for remote host
+ Fix test-case gdb.server/file-transfer.exp for remote host using
+ gdb_remote_download and host_standard_output_file.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix local-remote-host-native.exp for gdb.server tests
+ When running test-case gdb.server/stop-reply-no-thread-multi.exp with
+ host+target board local-remote-host-native, I run into a time-out:
+ ...
+ (gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
+ to_disable=: disconnect
+ builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \
+ localhost:2346 stop-reply-no-thread-multi^M
+ Process stop-reply-no-thread-multi created; pid = 32600^M
+ Listening on port 2346^M
+ set remote threads-packet off^M
+ FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
+ to_disable=: set remote threads-packet off (timeout)
+ ...
+
+ This is due to this line in ${board}_spawn:
+ ...
+ set board_info($board,fileid) $spawn_id
+ ...
+
+ We have the following series of events:
+ - gdb is spawned, setting fileid
+ - a few gdb commands (set height etc) are send using fileid, arrive at gdb and
+ are successful
+ - gdbserver is spawned, overwriting fileid
+ - the next gdb command is sent using fileid, so it's send
+ to gdbserver instead of gdb, and we run into the timeout.
+
+ There is some notion of current gdb, tracked in both gdb_spawn_id and fileid
+ of the host board (see switch_gdb_spawn_id). And because the host and target
+ board are the same, spawning something on the target overwrites the fileid on
+ host, and consequently the current gdb.
+
+ Fix this by only setting fileid when spawning gdb.
+
+ Tested on x86_64-linux.
+
+ Now gdb.server/*.exp passes for host+target board local-remote-host-native,
+ except for file-transfer.exp.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734
+
+2023-03-28 Enze Li <enze.li@hotmail.com>
+
+ gdb: use dynamic year in update-freebsd.sh
+ When running update-freebsd.sh on FreeBSD, I see the following
+ modification in freebsd.xml,
+
+ -<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc.
+ +<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc.
+
+ It means that each time, when we running the update-freebsd.sh on
+ FreeBSD, we have to correct the year of copyright manually. So fix this
+ issue by using dynamic year.
+
+ Tested by regenerating freebsd.xml on FreeBSD/amd64.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/non-existing-program.exp with remote-gdbserver-on-localhost
+ With test-case gdb.server/non-existing-program.exp and native, I have reliably:
+ ...
+ (gdb) builtin_spawn gdbserver stdio non-existing-program^M
+ stdin/stdout redirected^M
+ /bin/bash: line 0: exec: non-existing-program: not found^M
+ During startup program exited with code 127.^M
+ Exiting^M
+ PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
+ ...
+
+ But with target board remote-gdbserver-on-localhost I sometimes have:
+ ...
+ (gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
+ stdio non-existing-program^M
+ stdin/stdout redirected^M
+ /bin/bash: line 0: exec: non-existing-program: not found^M
+ During startup program exited with code 127.^M
+ Exiting^M
+ Connection to localhost closed.^M^M
+ PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
+ ...
+ and sometimes the exact same output, but a FAIL instead.
+
+ Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Alan Modra <amodra@gmail.com>
+
+ Avoid undefined behaviour in m68hc11 md_begin
+ Given p = A where p is a pointer to some type and A is an array of
+ that type, then the expression p - 1 + 1 evokes undefined behaviour
+ according to the C standard.
+
+ gcc-13 -fsanitize=address,undefined complains about this, but not
+ where the undefined behaviour actually occurs at tc-m68hc11.c:646.
+ Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store
+ to address 0x62600000016c with insufficient space for an object of
+ type 'int'". Which is a lie. There most definitely is space there.
+ Oh well, diagnostics are sometimes hard to get right. The UB is easy
+ to avoid.
+
+ PR 30279
+ * config/tc-m68hc11.c (md_begin): Avoid undefined pointer
+ decrement. Remove unnecessary cast.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow gdb.rust/expr.exp without rust compiler
+ Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
+ the wrong answer for gdb.rust/expr.exp, which doesn't require it.
+
+ Fix this by using can_compile rust in the test-cases that need it, and just
+ returning 1 in allow_rust_tests.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add can_compile rust
+ If I deinstall the rust compiler, I get:
+ ...
+ gdb compile failed, default_target_compile: Can't find rustc --color never.
+ UNTESTED: gdb.rust/watch.exp: failed to prepare
+ ...
+
+ Fix this by adding can_compile rust, and using it in allow_rust_tests, such
+ that we have instead:
+ ...
+ UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
+ ...
+
+ Since the rest of the code in allow_rust_tests is also about availability of
+ the rust compiler, move it to can_compile.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Unsupport gdb.rust for remote host
+ With test-case gdb.rust/watch.exp and remote host I run into:
+ ...
+ Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300)
+ ...
+ ld:watch.rs: file format not recognized; treating as linker script
+ ld:watch.rs:1: syntax error
+ ...
+ UNTESTED: gdb.rust/watch.exp: failed to prepare
+ ...
+
+ The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.
+
+ Fix this by returning 0 in allow_rust_tests for remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-28 Alan Modra <amodra@gmail.com>
+
+ ubsan: elfnn-aarch64.c:4595:19: runtime error: load of value 190
+ which is not a valid value for type '_Bool'
+
+ * elfnn-aarch64.c (stub_hash_newfunc): Clear all fields past root.
+
+2023-03-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gnat_runtime_has_debug_info for remote host
+ Fix gnat_runtime_has_debug_info for remote host by checking for
+ allow_ada_tests.
+
+ This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
+ remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-27 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Use correct constant for target_waitstatus::sig.
+ Use GDB_SIGNAL_TRAP instead of SIGTRAP. This is a no-op since the
+ value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but
+ it is more correct.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-27 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Avoid a direct write to target_waitstatus::kind.
+ This is in #ifdef'd code for a workaround for FreeBSD versions older
+ than 11.1 which is why it wasn't caught earlier.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-27 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Add missing spaces.
+ No functional change, just style fixes.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: 30089 [display text] Invalid number of threads
+ The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34
+ We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
+ Some of these functions have versions. For example, dlopen@GLIBC_2.34,
+ dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc.
+ We have to interpose each of the functions because we don't know
+ which version of libC will be used during profiling.
+ Historically, we have used three versions of scripts (mapfile.aarch64-Linux,
+ mapfile.amd64-Linux, mapfile.intel-Linux).
+ Three are not needed. One is enough
+
+ The fixes below include:
+ - merged all version symbols into one version script.
+ - added new version symbols which are defined in latest versions of libC.
+ - removed unused defines and duplicated code.
+ - added the DCL_FUNC_VER macro to define the version symbols.
+
+ Tested on x86_64 and aarch64 (OL8/OL9). No regression.
+
+ gprofng/ChangeLog
+ 2023-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30089
+ * libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.*
+ * libcollector/configure.ac: Delete GPROFNG_VARIANT.
+ * src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h
+ * libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER).
+ Remove unused defines.
+ * libcollector/dispatcher.c: Interpose functions from libC.
+ Clean up the old code.
+ * libcollector/iotrace.c: Likewise.
+ * libcollector/libcol_util.c: Likewise.
+ * libcollector/linetrace.c: Likewise.
+ * libcollector/mmaptrace.c: Likewise.
+ * libcollector/synctrace.c: Likewise.
+ * libcollector/libgprofng.ver: New file.
+ * libcollector/Makefile.in: Rebuild.
+ * libcollector/configure: Rebuild.
+ * libcollector/mapfile.aarch64-Linux: Removed.
+ * libcollector/mapfile.amd64-Linux: Removed.
+ * libcollector/mapfile.intel-Linux: Removed.
+ * libcollector/mapfile.sparc-Linux: Removed.
+ * libcollector/mapfile.sparcv9-Linux: Removed.
+
+2023-03-27 Pedro Alves <pedro@palves.net>
+
+ linux-nat: introduce pending_status_str
+ I noticed that some debug log output printing an lwp's pending status
+ wasn't considering lp->waitstatus. This fixes it, by introducing a
+ new pending_status_str function.
+
+ Also fix the comment in gdb/linux-nat.h describing
+ lwp_info::waitstatus and details the description of lwp_info::status
+ while at it.
+
+ Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-03-27 Pedro Alves <pedro@palves.net>
+
+ displaced step: pass down target_waitstatus instead of gdb_signal
+ This commit tweaks displaced_step_finish & friends to pass down a
+ target_waitstatus instead of a gdb_signal. This is needed because a
+ patch later in the step-over-{thread-exit,clone] series will want to
+ make displaced_step_buffers::finish handle
+ TARGET_WAITKIND_THREAD_EXITED. It also helps with the
+ TARGET_WAITKIND_THREAD_CLONED patch later in that same series.
+
+ It's also a bit more logical this way, as we don't have to pass down
+ signals when the thread didn't actually stop for a signal. So we can
+ also think of it as a clean up.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
+ Change-Id: I4c5d338647b028071bc498c4e47063795a2db4c0
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.stabs/exclfwd.exp for remote host
+ Fix test-case gdb.stabs/exclfwd.exp for remote host using include_file.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.stabs/weird.exp for remote host
+ Fix test-case gdb.stabs/weird.exp for remote host by not using an absolute
+ destfile argument to gdb_remote_download, which doesn't work well with remotedir.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.gdb/unittest.exp for remote host
+ Fix test-case gdb.gdb/unittest.exp for remote host, by:
+ - disabling the completion tests if readline is not used, and
+ - not using with_gdb_cwd $dir for remote host (because it does
+ not support changing to ".").
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Skip do_self_tests on remote host
+ In do_self_tests we try to find out the location of the gdb to debug, which
+ will then be copied and renamed to xgdb.
+
+ In principle, the host board specifies the location of GDB, on host.
+
+ With remote host, we could upload that gdb from host to build/target, but we
+ would miss the data directory (which is listed as the reason to skip
+ do_self_tests for remote target).
+
+ We could fix that by instead taking the gdb from build instead, but that
+ wouldn't work with installed testing.
+
+ It seems easier to just skip this on remote host.
+
+ It could be made to work for the "[is_remote host] && [is_remote target]
+ && host == target" scenario (see board local-remote-host-native.exp), but
+ that doesn't seem worth the effort.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Change symbol::line to unsigned int
+ A user here at AdaCore noticed that, when debugging a certain program,
+ a stack frame reported line 34358, where it should have been line
+ 99894.
+
+ After debugging a bit, I discovered:
+
+ (top) p (99894 & ~65536)
+ $60 = 34358
+
+ That line, symbol::line is too narrow.
+
+ This patch widens the member and changes all the uses that currently
+ use the narrower type.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Fix 128-bit integer bug in Ada
+ While working on 128-bit integer support, I found one spot in Ada that
+ needed a fix as well.
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Use gdb_gmp for scalar arithmetic
+ This changes gdb to use scalar arithmetic for expression evaluation.
+
+ I suspect this patch is not truly complete, as there may be code paths
+ that still don't correctly handle 128-bit integers. However, many
+ things do work now.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30190
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Use value_true in value_equal and value_less
+ Both value_equal and value_less use value_as_long to check a
+ presumably boolean result of calling value_binop. However,
+ value_binop in this case actually returns an int as wide as its
+ arguments, and this approach can then fail for integers wider than
+ LONGEST. Instead, rewrite this in a form that works for any size
+ integer.
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Simplify binop_promote
+ binop_promote currently only handles integer sizes up to
+ builtin_long_long. However, this may not handle 128-bit types.
+ Simplify this code, unify the C and non-C (but not OpenCL, as I don't
+ know how to test this) cases, and handle 128-bit integers as well.
+
+ This still doesn't exactly follow C or C++ rules. This could be
+ implemented, but if so, I think it makes more sense as a C-specific
+ expression node.
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Add value_as_mpz and value_from_mpz
+ This adds the two new functions, value_as_mpz and value_from_mpz,
+ useful for manipulation values via gdb_mpz.
+
+ Add truncation mode to gdb_mpz
+ This renames gdb_mpz::safe_export to export_bits, and adds a new flag
+ to export a truncated value. This is needed by value arithmetic.
+
+ Avoid a copy in gdb_mpz::safe_export
+ Currently, gdb_mpz::safe_export will always make a copy of *this.
+ However, this copy isn't always needed. This patch makes this code
+ slightly more efficient, by avoiding the copy when possible.
+
+ Add many operators to gdb_mpz
+ This adds many operator overloads and other useful methods to gdb_mpz.
+ This is preparation for using this class for scalar arithmetic in gdb
+ expression evaluation.
+
+2023-03-27 Tom Tromey <tromey@adacore.com>
+
+ Populate seen_names hash in cooked_index_shard::do_finalize
+ Hannes pointed out that cooked_index_shard::do_finalize never
+ populates the seen_names hash table. This patch adds the necessary
+ store. This reduces memory use a little for "gdb gdb":
+
+ (before) Space used: 28909568 (+0 for this command)
+ (after) Space used: 28884992 (+0 for this command)
+
+ What this means, btw, is that in gdb there are not many symbols that
+ are both mentioned in many CUs and that also require name
+ canonicalization. It's possible this would differ in other programs.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.asm/asm-source.exp for remote host
+ Fix test-case gdb.asm/asm-source.exp for remote host using
+ host_standard_output_file and gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/imported-unit-bp-c.exp for remote host
+ Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a
+ downloaded source file.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Unsupport gdb.dwarf2/gdb-add-index-symlink.exp for remote host
+ Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote
+ host, because the current implementation of gdb_ensure_index doesn't support it.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote host
+ Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using
+ host_standard_output_file.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp for remote host
+ Fix test-case gdb.dwarf2/enqueued-cu-base-addr.exp for remote host by using
+ $testfile instead $binfile.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote host
+ Fix test-case gdb.dwarf2/gdb-index.exp on remote host using
+ gdb_remote_download and host_standard_output_file.
+
+ Also declare the test-case unsupported with readnow.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp for remote host
+ Fix test-case gdb.dwarf2/per-bfd-sharing.exp for remote host using
+ gdb_remote_download.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix quoting issue in gdb.base/index-cache.exp
+ For test-case gdb.base/index-cache.exp and remote host, this:
+ ...
+ lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret
+ ...
+ gives us:
+ ...
+ Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index (timeout = 300)
+ builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M
+ rm: missing operand^M
+ Try 'rm --help' for more information.^M
+ FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir
+ ...
+
+ Fix this using quote_for_host. Likewise in gdb.dwarf2/per-bfd-sharing.exp.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix quoting issues in gdb.dwarf2 for remote host
+ A few test-cases in gdb.dwarf2 use something like:
+ ...
+ additional_flags=\"-DFOO=BAR + 10\"
+ ...
+ which doesn't work on remote host.
+
+ Fix this by introducing a new proc quote_for_host that also works for remote
+ host, such that we have:
+ ...
+ additional_flags=[quote_for_host -DFOO=BAR + 10]
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix have_index for remote host
+ Proc have_index is mostly used with $binfile, which gives problems
+ for remote host.
+
+ Fix this by using "file tail" on the proc argument.
+
+ Tested on x86_64-linux.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing include_file in gdb.dwarf/*.exp
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add test-case gdb.dlang/dlang-start-2.exp
+ For test-case gdb.dlang/dlang-start.exp, I run into:
+ ...
+ UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
+ ...
+
+ My distro has no support for gdc, but I'd like to have the test-case
+ running and passing, so let's rewrite the test-case using dwarf assembly
+ and add it alongside (rather than replacing it, because it's good to use
+ actual compiler output if we have it available).
+
+ My distro does have a package providing dmd, so let's mimic that debug info in
+ the dwarf assembly. This gives us:
+ ...
+ (gdb) start ^M
+ Temporary breakpoint 1 at 0x4004ab^M
+ Starting program: dlang-start-2 ^M
+ ^M
+ Temporary breakpoint 1, 0x00000000004004ab in _Dmain ()^M
+ ...
+
+ The "_Dmain ()" should probably be "D main", I've filed PR30276 about that.
+
+ Also add a "show language" to check that we automatically set the language
+ correctly to D.
+
+ Note that the dwarf assembly also describes main, otherwise the test-case
+ doesn't function as regression test for commit 47fe57c9281 ("Fix "start" for
+ D, Rust, etc").
+
+ Tested on x86_64-linux.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ Tidy tc-ppc.c XCOFF auxent access
+ It's better not to drill down into u.auxent but instead use a pointer
+ to the combined_entry_type. That way the fix_scnlen field is
+ available, and no one looking at the codes needs to wonder whether
+ coffsymbol (symbol_get_bfdsym (sym))->native[i + 1] is the same
+ auxent.
+
+ * config/tc-ppc.c (ppc_frob_symbol): Tidy XCOFF auxent access.
+ (ppc_adjust_symtab): Likewise.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ Remove coff_pointerize_aux table_end param
+ I'm fairly certain the table_end checks are redundant now. This
+ patch reverts commit 334d4ced42d3.
+
+ * coffgen.c (coff_pointerize_aux): Remove table_end parameter.
+ (coff_get_normalized_symtab): Adjust to suit.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ Use stdint types in coff internal_auxent
+ long is a poor choice of type to store 32-bit values read from
+ objects files by H_GET_32. H_GET_32 doesn't sign extend so tests like
+ that in gdb/coffread.c for "negative" values won't work if long is
+ larger than 32 bits. If long is 32-bit then code needs to be careful
+ to not accidentally index negative array elements. (I'd rather see a
+ segfault on an unmapped 4G array index than silently reading bogus
+ data.) long is also a poor choice for x_sect.s_scnlen, which might
+ have 64-bit values. It's better to use unsigned exact width types to
+ avoid surprises.
+
+ I decided to change the field names too, which makes most of this
+ patch simply renaming. Besides that there are a few places where
+ casts are no longer needed, and where printf format strings or tests
+ need adjusting.
+
+ include/
+ * coff/internal.h (union internal_auxent): Use unsigned stdint
+ types. Rename l fields to u32 and u64 as appropriate.
+ bfd/
+ * coff-bfd.c,
+ * coff-rs6000.c,
+ * coff64-rs6000.c,
+ * coffcode.h,
+ * coffgen.c,
+ * cofflink.c,
+ * coffswap.h,
+ * peXXigen.c,
+ * xcofflink.c: Adjust to suit internal_auxent changes.
+ binutils/
+ * rdcoff.c: Adjust to suit internal_auxent changes.
+ gas/
+ * config/obj-coff.h,
+ * config/tc-ppc.c: Adjust to suit internal_auxent changes.
+ gdb/
+ * coffread.c,
+ * xcoffread.c: Adjust to suit internal_auxent changes.
+ ld/
+ * pe-dll.c: Adjust to suit internal_auxent changes.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ Set proper union selector tag
+ * coff-bfd.c (bfd_coff_get_auxent): After converting sym pointer
+ to an index, reset the union tag.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ coffgrok access of u.auxent.x_sym.x_tagndx.p
+ u.auxent.x_sym.x_tagndx is a union. The p field is only valid when
+ fix_tag is set. This patch fixes code in coffgrok.c that accessed the
+ field without first checking fix_tag, and removes a whole lot of code
+ validating bogus pointers to prevent segfaults (which no longer
+ happen, I checked the referenced PR 17512 testcases). The patch also
+ documents this in the fix_tag comment, makes is_sym a bitfield, and
+ sorts the selecter fields a little.
+
+ bfd/
+ * coffcode.h (combined_entry_type): Make is_sym a bitfield.
+ Sort and comment on union selectors.
+ * libcoff.h: Regenerate.
+ binutils/
+ * coffgrok.c (do_type): Make aux a combined_entry_type. Test
+ fix_tag before accessing u.auxent.x_sym.x_tagndx.p. Remove
+ now unnecessary pointer bounds checking.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ Duplicate DW_AT_call_file leak
+ When given two or more DW_AT_call_file for a given function we
+ currently leak the concat memory.
+
+ * dwarf2.c (scan_unit_for_symbols): Don't leak on duplicate
+ DW_AT_call_file.
+
+2023-03-27 Alan Modra <amodra@gmail.com>
+
+ XCOFF sanity check
+ * coffcode.h (coff_pointerize_aux_hook): Sanity check
+ x_csect.x_scnlen against raw_syment_count.
+
+2023-03-27 Nick Clifton <nickc@redhat.com>
+
+ Add an option to the gold linker to put its version string into the .comment section.
+ PR 30187
+ * options.h (class General_options): Add enable-linker-version.
+ * layout.cc (Layout::create_gold_note): If linker-version is enabled put the version string into the .comment section.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle missing gdc in gdb.dlang/dlang-start.exp
+ On openSUSE Leap 15.4, I get:
+ ...
+ Running gdb.dlang/dlang-start.exp ...
+ gdb compile failed, default_target_compile: Can't find gdc.
+ UNTESTED: gdb.dlang/dlang-start.exp: failed to prepare
+ ...
+
+ Fix this by:
+ - introducing a new proc can_compile, and
+ - requiring "can_compile d" in the test-case,
+ such that I have instead:
+ ...
+ Running gdb.dlang/dlang-start.exp ...
+ UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
+ ...
+
+ Tested on x86_64-linux, on openSUSE Leap 15.4 and Fedora 37.
+
+2023-03-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove superfluous pid in temp files
+ While trying to use gdb_can_simple_compile with a d program, I ran into:
+ ...
+ /data/vries/gdb/f37/build/gdb/testsuite/temp/105856/can_compile_d-105856.d: \
+ error: module 'can_compile_d-105856' has non-identifier characters in \
+ filename, use module declaration instead
+ ...
+
+ The d compiler has a problem with the filename can_compile_d-105856.d, which
+ contains the pid. The pid is added by gdb_simple_compile:
+ ...
+ set obj [standard_temp_file $name-[pid].$postfix]
+ ...
+ but it's unnecessary because standard_temp_file already uses the pid.
+
+ Fix this by removing "[pid]" in all calls to standard_temp_file.
+
+ Tested on x86_64-linux.
+
+2023-03-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Introduce allow_dap_tests
+ Simon pointed out that with gdb.dap/*.exp and target board
+ native-gdbserver, we run into problems.
+
+ I see for each test-case:
+ ...
+ +++ run
+ Traceback (most recent call last):
+ File "startup.py", line 146, in exec_and_log
+ output = gdb.execute(cmd, from_tty=True, to_string=True)
+ gdb.error: Don't know how to run. Try "help target".
+ ...
+
+ Likewise with target board native-extended-gdbserver.
+
+ Fix this by:
+ - adding a new proc allow_dap_tests,
+ - using it in all the gdb.dap tests, and
+ - bailing out if GDBFLAGS/INTERNAL_GDBFLAGS contains
+ "set auto-connect-native-target off".
+
+ Tested on x86_64-linux.
+
+ Reported-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-03-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-24 Tom Tromey <tromey@adacore.com>
+
+ Preserve name of range types
+ The type-allocation patches introduced a small regression that was
+ picked up by the AdaCore internal test suite. Previously, the name of
+ a range type was preserved by resolve_dynamic_range, but now it is
+ not. This patch changes this code to preserve the name.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-03-24 Tom Tromey <tromey@adacore.com>
+
+ Implement repl evaluation for DAP
+ The evaluate command supports a "context" parameter which tells the
+ adapter the context in which an evaluation occurs. One of the
+ supported values is "repl", which we took to mean evaluation of a gdb
+ command. That is what this patch implements.
+
+ Note that some gdb commands probably will not work correctly with the
+ rest of the protocol. For example if the user types "continue",
+ confusion may result.
+
+ This patch requires the earlier patch to fix up scopes in DAP.
+
+2023-03-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix line number of static const class member
+ Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there
+ was a silent regression on openSUSE Leap 15.4 for test-case
+ gdb.cp/m-static.exp, from:
+ ...
+ (gdb) info variable everywhere^M
+ All variables matching regular expression "everywhere":^M
+ ^M
+ File /home/vries/tmp.local-remote-host-native/m-static.h:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ (gdb)
+ ...
+ to:
+ ...
+ (gdb) info variable everywhere^M
+ All variables matching regular expression "everywhere":^M
+ ^M
+ File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ ^M
+ File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ (gdb)
+ ...
+
+ Another regression was found due to that commit, and it was fixed in commit
+ 99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by
+ limiting the scope of the fix in the original commit.
+
+ Fix this regression by yet further limiting the scope of that fix, making sure
+ that this bit in dwarf_decode_lines is executed again for m-static1.cc:
+ ...
+ /* Make sure a symtab is created for every file, even files
+ which contain only variables (i.e. no code with associated
+ line numbers). */
+ ...
+
+ Tested on x86_64-linux.
+
+ PR symtab/30265
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265
+
+2023-03-24 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: get the offsets of fields of unnamed structs/unions right
+ We were failing to add the offsets of the containing struct/union
+ in this case, leading to all offsets being relative to the unnamed
+ struct/union itself.
+
+ libctf/
+ PR libctf/30264
+ * ctf-types.c (ctf_member_info): Add the offset of the unnamed
+ member of the current struct as necessary.
+ * testsuite/libctf-lookup/unnamed-field-info*: New test.
+
+2023-03-24 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: fix a comment typo
+ ctf_dedup's intern() function does not return a dynamically allocated
+ string, so I just spent ten minutes auditing for obvious memory leaks
+ that couldn't actually happen. Update the comment to note what it
+ actually returns (a pointer into an atoms table: i.e. possibly not
+ a new string, and not so easily leakable).
+
+ libctf/
+ * ctf-dedup.c (intern): Update comment.
+
+2023-03-24 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: work around an uninitialized variable warning
+ GCC 11+ complains that sym is uninitialized in ctf_symbol_next. It
+ isn't, but it's not quite smart enough to figure that out (it requires
+ domain-specific knowledge of the state of the ctf_next_t iterator
+ over multiple calls).
+
+ libctf/
+ * ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable
+ value for returning if never reset during the function.
+
+2023-03-24 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: fix assertion failure with no system qsort_r
+ If no suitable qsort_r is found in libc, we fall back to an
+ implementation in ctf-qsort.c. But this implementation routinely calls
+ the comparison function with two identical arguments. The comparison
+ function that ensures that the order of output types is stable is not
+ ready for this, misinterprets it as a type appearing more that once (a
+ can-never-happen condition) and fails with an assertion failure.
+
+ Fixed, audited for further instances of the same failure (none found)
+ and added a no-qsort test to my regular testsuite run.
+
+ libctf/:
+ PR libctf/30013
+ * ctf-dedup.c (sort_output_mapping): Inputs are always equal to
+ themselves.
+
+2023-03-24 Tom Tromey <tromey@adacore.com>
+
+ Fix race in DAP startup
+ Internal AdaCore DAP testing on Windows has had occasional failures
+ that show:
+
+ assert threading.current_thread() is _dap_thread
+
+ I think this is a race in DAP startup: the _dap_thread global is only
+ set on return from start_thread, but it seems possible that the thread
+ itself could already run and encounter a @in_dap_thread decorator.
+
+ This patch fixes the problem by setting the global before running any
+ of the code in the new thread. This also lets us remove a FIXME.
+
+2023-03-24 Luis Machado <luis.machado@arm.com>
+
+ aarch64: Check for valid inferior thread/regcache before reading pauth registers
+ There were reports of gdb throwing internal errors when calling
+ inferior_thread ()/get_current_regcache () on a system with
+ Pointer Authentication enabled.
+
+ In such cases, gdb produces the following backtrace:
+
+ ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0xaaaae04a571f gdb_internal_backtrace_1
+ ../../../repos/binutils-gdb/gdb/bt-utils.c:122
+ 0xaaaae04a57f3 _Z22gdb_internal_backtracev
+ ../../../repos/binutils-gdb/gdb/bt-utils.c:168
+ 0xaaaae0b52ccf internal_vproblem
+ ../../../repos/binutils-gdb/gdb/utils.c:401
+ 0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list
+ ../../../repos/binutils-gdb/gdb/utils.c:481
+ 0xaaaae0e24b8f _Z18internal_error_locPKciS0_z
+ ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
+ 0xaaaae0a88983 _Z15inferior_threadv
+ ../../../repos/binutils-gdb/gdb/thread.c:86
+ 0xaaaae0956c87 _Z20get_current_regcachev
+ ../../../repos/binutils-gdb/gdb/regcache.c:428
+ 0xaaaae035223f aarch64_remove_non_address_bits
+ ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572
+ 0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm
+ ../../../repos/binutils-gdb/gdb/gdbarch.c:3109
+ 0xaaaae0a692d7 memory_xfer_partial
+ ../../../repos/binutils-gdb/gdb/target.c:1620
+ 0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm
+ ../../../repos/binutils-gdb/gdb/target.c:1684
+ 0xaaaae0a69e9f target_read_partial
+ ../../../repos/binutils-gdb/gdb/target.c:1937
+ 0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml
+ ../../../repos/binutils-gdb/gdb/target.c:1977
+ 0xaaaae0a69937 _Z18target_read_memorymPhl
+ ../../../repos/binutils-gdb/gdb/target.c:1773
+ 0xaaaae08be523 ps_xfer_memory
+ ../../../repos/binutils-gdb/gdb/proc-service.c:90
+ 0xaaaae08be6db ps_pdread
+ ../../../repos/binutils-gdb/gdb/proc-service.c:124
+ 0x40001ed7c3b3 _td_fetch_value
+ /build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115
+ 0x40001ed791ef td_ta_map_lwp2thr
+ /build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194
+ 0xaaaae07f4473 thread_from_lwp
+ ../../../repos/binutils-gdb/gdb/linux-thread-db.c:413
+ 0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
+ ../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420
+ 0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
+ ../../../repos/binutils-gdb/gdb/target.c:2586
+ 0xaaaae0789cf7 do_target_wait_1
+ ../../../repos/binutils-gdb/gdb/infrun.c:3825
+ 0xaaaae0789e6f operator()
+ ../../../repos/binutils-gdb/gdb/infrun.c:3884
+ 0xaaaae078a167 do_target_wait
+ ../../../repos/binutils-gdb/gdb/infrun.c:3903
+ 0xaaaae078b0af _Z20fetch_inferior_eventv
+ ../../../repos/binutils-gdb/gdb/infrun.c:4314
+ 0xaaaae076652f _Z22inferior_event_handler19inferior_event_type
+ ../../../repos/binutils-gdb/gdb/inf-loop.c:41
+ 0xaaaae07dc68b handle_target_event
+ ../../../repos/binutils-gdb/gdb/linux-nat.c:4206
+ 0xaaaae0e25fbb handle_file_event
+ ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573
+ 0xaaaae0e264f3 gdb_wait_for_event
+ ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694
+ 0xaaaae0e24f9b _Z16gdb_do_one_eventi
+ ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217
+ 0xaaaae080f033 start_event_loop
+ ../../../repos/binutils-gdb/gdb/main.c:411
+ 0xaaaae080f1b7 captured_command_loop
+ ../../../repos/binutils-gdb/gdb/main.c:475
+ 0xaaaae0810b97 captured_main
+ ../../../repos/binutils-gdb/gdb/main.c:1318
+ 0xaaaae0810c1b _Z8gdb_mainP18captured_main_args
+ ../../../repos/binutils-gdb/gdb/main.c:1337
+ 0xaaaae0338453 main
+ ../../../repos/binutils-gdb/gdb/gdb.c:32
+ ---------------------
+ ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n)
+
+ We also see failures across the testsuite if the tests get executed on a target
+ that has native support for the pointer authentication feature. But
+ gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of
+ tests that run into errors and internal errors.
+
+ This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which
+ enabled more broad use of pointer authentication masks to remove non-address
+ bits of pointers, but wasn't immediately detected because systems with native
+ support for pointer authentication are not that common yet.
+
+ The above crash happens because gdb is in the middle of handling an event,
+ and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the
+ current thread. This means a call to inferior_thread () will assert, and
+ attempting to call get_current_regcache () will also call inferior_thread (),
+ resulting in an assertion as well.
+
+ target_has_registers was one function that seemed useful for detecting these
+ types of situation where we don't have a register cache. The problem with that
+ is the inconsistent state of inferior_ptid, which is used by
+ target_has_registers.
+
+ Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from
+ do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to
+ ps_xfer_memory sets inferior_ptid momentarily before reading memory:
+
+ 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 restore_inferior;
+ set_current_inferior (ph->thread->inf);
+
+ scoped_restore_current_program_space restore_current_progspace;
+ set_current_program_space (ph->thread->inf->pspace);
+
+ scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid);
+ inferior_ptid = ph->thread->ptid;
+
+ CORE_ADDR core_addr = ps_addr_to_core_addr (addr);
+
+ int ret;
+ if (write)
+ ret = target_write_memory (core_addr, buf, len);
+ else
+ ret = target_read_memory (core_addr, buf, len);
+ return (ret == 0 ? PS_OK : PS_ERR);
+ }
+
+ Maybe this shouldn't happen, or maybe it is just an unfortunate state to be
+ in. But this prevents the use of target_has_registers to guard against the
+ lack of registers, since, although current_thread_ is still nullptr,
+ inferior_ptid is valid and is not null_ptid.
+
+ There is another crash scenario after we kill a previously active inferior, in
+ which case the gdbarch will still say we support pointer authentication but we
+ will also have no current thread (inferior_thread () will assert etc).
+
+ If the target has support for pointer authentication, gdb needs to use
+ a couple (or 4, for bare-metal) mask registers to mask off some bits of
+ pointers, and for that it needs to access the registers.
+
+ At some points, like the one from the backtrace above, there is no active
+ thread/current regcache because gdb is in the middle of doing event handling
+ and switching between threads.
+
+ Simon suggested the use of inferior_ptid to fetch the register cache, as
+ opposed to relying on the current register cache. Though we need to make sure
+ inferior_ptid is valid (not null_ptid), I think this works nicely.
+
+ With inferior_ptid, we can do safety checks along the way, making sure we have
+ a thread to fetch a register cache from and checking if the thread is actually
+ stopped or running.
+
+ The following patch implements this idea with safety checks to make sure we
+ don't run into assertions or errors. If any of the checks fail, we fallback to
+ using a default mask to remove non-address bits of a pointer.
+
+ I discussed with Pedro the possibility of caching the mask register values
+ (which are per-process and can change mid-execution), but there isn't a good
+ spot to cache those values. Besides, the mask registers can change constantly
+ for bare-metal debugging when switching between exception levels.
+
+ In some cases, it is just not possible to get access to these mask registers,
+ like the case where threads are running. In those cases, using a default mask
+ to remove the non-address bits should be enough.
+
+ This can happen when we let threads run in the background and then we attempt
+ to access a memory address (now that gdb is capable of reading memory even
+ with threads running). Thus gdb will attempt to remove non-address bits
+ of that memory access, will attempt to access registers, running into errors.
+
+ Regression-tested on aarch64-linux Ubuntu 20.04.
+
+2023-03-24 Alan Modra <amodra@gmail.com>
+
+ Tidy string_ptr increment
+ * peicode.h (pe_ILF_make_a_symbol): Use sprintf output to
+ increment string_ptr to end of new string.
+
+ Tidy dwarf1 cached section contents
+ * dwarf1.c (_bfd_dwarf1_cleanup_debug_info): New function.
+ * libbfd-in.h (_bfd_dwarf1_cleanup_debug_info): Declare.
+ * elf.c (_bfd_elf_close_and_cleanup): Call it.
+ * elf-bfd.h (struct elf_obj_tdata): Make dwarf1_find_line_info
+ a void*.
+ * libbfd.h: Regenerate.
+
+2023-03-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument
+ In proc mi_expect_stop there's a proc argument reason that's handled like so:
+ ...
+ set r "reason=\"$reason\","
+ ...
+
+ That's fine for say:
+ ...
+ set reason "foo"
+ ...
+ for which this evaluates to:
+ ...
+ set r "reason=\"foo\","
+ ...
+
+ But there are more complex uses, for instance:
+ ...
+ set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
+ ...
+ which evaluates to:
+ ...
+ set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
+ ...
+
+ Note how in this reason argument, the first two '\"' seems to form a pair
+ surrounding ',disp=', which is not the case, which is confusing.
+
+ Fix this by only adding the quotes in mi_expect_stop if the string doesn't
+ already contain quotes, such that we have the more readable:
+ ...
+ set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/m-static.exp regression on Ubuntu 20.04
+ In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I
+ needed to change ".*/" into "(.*/)?" in:
+ ...
+ gdb_test "info variable everywhere" \
+ "File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;"
+ ...
+
+ However, due to the fact that I got this output:
+ ...
+ (gdb) info variable everywhere^M
+ All variables matching regular expression "everywhere":^M
+ ^M
+ File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ ^M
+ File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ ...
+ I decided to make the matching somewhat stricter, to make sure that the two
+ matched lines were subsequent.
+
+ The commit turned out to be more strict than intended, and caused a regression
+ on Ubuntu 20.04, where the output was instead:
+ ...
+ (gdb) info variable everywhere^M
+ All variables matching regular expression "everywhere":^M
+ ^M
+ File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
+ 8: const int gnu_obj_4::everywhere;^M
+ ...
+
+ At that point I realized I'm looking at a bug (filed as PR symtab/30265),
+ which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu
+ 20.04 for readnow, but not for native.
+
+ Before my commit, the test-case passed whether the bug manifested or not.
+
+ After my commit, the test-case only passed when the bug manifested.
+
+ Fix the test-case regression by reverting to the situation before the commit:
+ pass whether the bug manifests or not. We could add an xfail for the PR, but
+ I'm expecting a fix soon, so that doesn't look worth the effort.
+
+ Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with
+ native and readnow.
+
+ Reported-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/dap] Add logging of ignored lines
+ This input sequence is accepted by DAP:
+ ...
+ {"seq": 4, "type": "request", "command": "configurationDone"}Content-Length: 84
+ ...
+
+ This input sequence has the same effect:
+ ...
+ {"seq": 4, "type": "request", "command": "configurationDone"}ignorethis
+ Content-Length: 84
+ ...
+ but the 'ignorethis' part is silently ignored.
+
+ Log the ignored bit, such that we have:
+ ...
+ READ: <<<{"seq": 4, "type": "request", "command": "configurationDone"}>>>
+ WROTE: <<<{"request_seq": 4, "type": "response", "command": "configurationDone"
+ , "success": true}>>>
+ +++ run
+ IGNORED: <<<b'ignorethis'>>>
+ ...
+
+2023-03-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-23 Tom Tromey <tromey@adacore.com>
+
+ Fix minor grammar issue in python.texi
+ I noticed a minor grammar problem in the 'GDB/MI Commands In Python'
+ node of the manual. I'm checking in this patch to correct it.
+
+2023-03-23 Frederic Cambus <fred@statdns.com>
+
+ Add support to readelf for the PT_OPENBSD_MUTABLE segment type.
+ binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type.
+ include * elf/common.h (PT_OPENBSD_MUTABLE): Define.
+
+2023-03-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use gdb_remote_download in allow_opencl_tests
+ Simon reported that doing:
+ ...
+ $ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
+ ...
+ could run into:
+ ...
+ ERROR: remote_download to target of \
+ /data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
+ cp: cannot create regular file 'opencl_kernel.cl': File exists
+ ...
+
+ Fix this by using gdb_remote_download (instead of plain remote_download) in
+ allow_opencl_test, which takes care of:
+ - downloading to a location which is safe for parallel testing, by
+ using standard_output_file, and
+ - cleaning up the downloaded file, meaning we can remove the corresponding
+ "remote_file target delete ${clprogram}" lines in allow_opencl_test.
+
+ Tested on x86_64-linux.
+
+ Reported-by: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Optimize BTI stubs PR30076
+ Don't insert a second stub if the target is already compatible with
+ an indirect branch.
+
+2023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Fix stubs that may break BTI PR30076
+ Insert two stubs in a BTI enabled binary when fixing long calls: The
+ first is near the call site and uses an indirect jump like before,
+ but it targets the second stub that is near the call target site and
+ uses a direct jump.
+
+ This is needed when a single stub breaks BTI compatibility.
+
+ The stub layout is kept fixed between sizing and building the stubs,
+ so the location of the second stub is known at build time, this may
+ introduce padding between stubs when those are relaxed. Stub layout
+ with BTI disabled is unchanged.
+
+2023-03-23 Szabolcs Nagy <szabolcs.nagy@arm.com>
+
+ bfd: aarch64: Refactor stub sizing code
+ elfNN_aarch64_size_stubs has grown big, so factor out the call stub
+ related code before adding new logic there.
+
+2023-03-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: add systemtap support
+ This commit is initial support for SystemTap for RISC-V Linux. The
+ following two tests exercise SystemTap functionality, and are showing
+ many failures, which are all fixed by this commit:
+
+ gdb.cp/exceptprint.exp
+ gdb.base/stap-probe.exp
+
+ One thing I wasn't sure about is if the SystemTap support should be
+ Linux specific, or architecture specific. For aarch64, arm, ia64, and
+ ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c
+ file, while for amd64, i386, and s390 the implementation lives in
+ ARCH-tdep.c. I have no idea which of these is the better choice -- or
+ maybe both choices are correct in the right circumstances, and I'm
+ just not aware of how to choose between them.
+
+ Anyway, for this patch I selected riscv-tdep.c (though clearly, moving
+ the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a
+ more appropriate location).
+
+ The stap-probe.exp file tests immediate, register, and register
+ indirect operands, all of which appear to be working fine with this
+ commit. The generic expression support doesn't appear to be
+ architecture specific, so I'd expect that to work fine too.
+
+2023-03-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove gdbarch_displaced_step_fixup_p
+ The comment on the gdbarch_displaced_step_fixup gdbarch method
+ indicates that this method is optional and that GDB will perform some
+ default if this method is not supplied. As such we define a predicate
+ gdbarch_displaced_step_fixup_p.
+
+ It may have been true at one point that the fixup method was optional,
+ but it is no longer true. If this method is not defined and GDB tries
+ to complete a displaced step, then GDB is going to crash.
+
+ Additionally the gdbarch_displaced_step_fixup_p predicate is not used
+ anywhere in GDB.
+
+ In this commit I have removed the gdbarch_displaced_step_fixup_p
+ predicate, and I have updated the validation check for the
+ gdbarch_displaced_step_fixup method; if the
+ gdbarch_displaced_step_copy_insn method is defined then the fixup
+ method must also be defined.
+
+ I believe I've manually checked all the current places where
+ gdbarch_displaced_step_copy_insn is defined and they all also define
+ the fixup method, so this change should cause no problems for anyone.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-03-22 Tom Tromey <tromey@adacore.com>
+
+ Remove unnecessary cast
+ I found an upcast from template_symbol to symbol. This was necessary
+ long ago, but since symbols use inheritance now, it is not. This
+ patch removes it. Tested by rebuilding.
+
+2023-03-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: adjust test cases to previous "maintenance info line-table" change
+ Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show
+ relocated addresses again") changed the format of that command, but
+ failed to adjust some test cases that relied on it. This patch fixes
+ it.
+
+ The failures fixed are:
+
+ FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
+ FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
+ FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table
+
+ Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c
+
+2023-03-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/cp-relocate.exp for remote host
+ Fix test-case gdb.cp/cp-relocate.exp for remote host using
+ gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/annota{2,3}.exp for native-extended-gdbserver
+ When running test-cases gdb.cp/annota{2,3}.exp with target board
+ native-extended-gdbserver, we run into a few FAILs, due to the test-cases
+ trying to match inferior output together with gdb output.
+
+ Fix this by ignoring the inferior output in this case.
+
+ Tested on x86_64-linux.
+
+2023-03-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/*.exp for remote host
+ Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
+ include_file.
+
+ Tested on x86_64-linux.
+
+2023-03-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make "maintenance info line-table" show relocated addresses again
+ Commit 1acc9dca423f ("Change linetables to be objfile-independent")
+ changed "maintenance info line-table" to print unrelocated addresses
+ instead of relocated. This breaks a few tests on systems where that
+ matters. The ones I see are:
+
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
+ FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
+ FAIL: gdb.base/async.exp: stepi&
+ FAIL: gdb.base/async.exp: nexti&
+ FAIL: gdb.base/async.exp: finish&
+
+ These tests run "maintenance info line-table" to record the address of
+ some lines, and then use these addresses in expected patterns. It
+ therefore expects these addresses to match the runtime addresses,
+ therefore the relocated addresses.
+
+ Add back the relocated addresses, next to the unrelocated addresses,
+ like so:
+
+ INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END
+ 0 6 0x0000555555555119 0x0000000000001119 Y
+ 1 7 0x000055555555511d 0x000000000000111d Y
+ 2 8 0x0000555555555123 0x0000000000001123 Y
+ 3 END 0x0000555555555125 0x0000000000001125 Y
+
+ The unrelocated addresses can always be useful trying to map this
+ information with a DWARF info dump.
+
+ Adjust the is_stmt_addresses proc in the testsuite to match the new
+ output.
+
+ Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf
+
+2023-03-22 Alan Modra <amodra@gmail.com>
+
+ coff_get_normalized_symtab bfd_release
+ We can't free "internal" on errors, since bfd_coff_swap_sym_in may
+ call bfd_alloc. For example, _bfd_XXi_swap_sym_in may even create new
+ sections, which use bfd_alloc'd memory. If "internal" is freed, all
+ more recently bfd_alloc'd memory is also freed.
+
+ * coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
+ error.
+
+2023-03-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-21 Alan Modra <amodra@gmail.com>
+
+ Remove unnecessary memsets in sframe-dump.c
+ * sframe-dump.c (dump_sframe_func_with_fres): Don't memset temp.
+
+ Sanity check coff-sh and coff-mcore sym string offset
+ * coff-mcore.c (coff_mcore_relocate_section): Sanity check sym
+ string offset when setting up name for use by error messages.
+ * coff-sh.c (sh_relocate_section): Likewise.
+
+2023-03-21 Alan Modra <amodra@gmail.com>
+
+ PR17910 sym string offset check
+ As far as I can see the only place that sets obj_coff_strings without
+ setting obj_coff_strings_len is pe_ILF_build_a_bfd. Fix that and we
+ can simplify the sym string offset check. This is just a tidy.
+ pe_ILF_build_a_bfd doesn't create bad symbols and
+ _bfd_coff_read_string_table will always result in non-zero
+ obj_coff_strings_len when obj_coff_strings is non-NULL.
+
+ PR 17910
+ * coffgen.c (_bfd_coff_internal_syment_name): Always sanity
+ check sym string offset.
+ * peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len.
+
+2023-03-21 Alan Modra <amodra@gmail.com>
+
+ PE fake section for C_SECTION syms
+ It's an odd thing to have objdump -x show a different section table
+ to objdump -h, but that can happen if swapping in symbols leads to
+ creating sections. Setting SEC_LINKER_CREATED stops the display of
+ these sections, so that you get shown what is in the object file.
+
+ * peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on
+ fake section created for C_SECTION syms. Don't zero asection
+ fields that are already zero.
+
+2023-03-21 Alan Modra <amodra@gmail.com>
+
+ XCOFF: use bfd_coff_close_and_cleanup
+ Free memory on closing bfds. The COFF close_and_cleanup does more
+ work than _bfd_generic_close_and_cleanup (defined as
+ _bfd_archive_close_and_cleanup).
+
+ * coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as
+ _bfd_coff_close_and_cleanup.
+ * coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use
+ _bfd_coff_close_and_cleanup.
+
+2023-03-21 Alan Modra <amodra@gmail.com>
+
+ gas: expand_irp memory leaks
+ * macro.c (expand_irp): Free memory on error return paths.
+
+2023-03-21 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Check unbalanced braces in memory reference
+ Check unbalanced braces in memory reference to avoid assembler crash
+ caused by
+
+ commit e87fb6a6d0cdfc0e9c471b7825c20c238c2cf506
+ Author: Jan Beulich <jbeulich@suse.com>
+ Date: Wed Oct 5 09:16:24 2022 +0200
+
+ x86/gas: support quoted address scale factor in AT&T syntax
+
+ PR gas/30248
+ * config/tc-i386.c (i386_att_operand): Check unbalanced braces
+ in memory reference.
+ * testsuite/gas/i386/i386.exp: Run pr30248.
+ * testsuite/gas/i386/pr30248.d: New file.
+ * testsuite/gas/i386/pr30248.err: Likewise.
+ * testsuite/gas/i386/pr30248.s: Likewise.
+
+2023-03-21 Carl Love <cel@us.ibm.com>
+
+ PowerPC: regression fix for reverse-finish command.
+ The recent commit:
+
+ commit 2a8339b71f37f2d02f5b2194929c9d702ef27223
+ Author: Carl Love <cel@us.ibm.com>
+ Date: Thu Mar 9 16:10:18 2023 -0500
+
+ PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
+
+ PPC64 multiple entry points, a normal entry point and an alternate entry
+ point. The alternate entry point is to setup the Table of Contents (TOC)
+ register before continuing at the normal entry point. When the TOC is
+ already valid, the normal entry point is used, this is typically the case.
+ The alternate entry point is typically referred to as the global entry
+ point (GEP) in IBM. The normal entry point is typically referred to as
+ the local entry point (LEP).
+ .....
+
+ Is causing regression failures on on PowerPC platforms. The regression
+ failures are in tests:
+
+ gdb.reverse/finish-precsave.exp
+ gdb.btrace/tailcall.exp
+ gdb.mi/mi-reverse.exp
+ gdb.btrace/step.exp
+ gdb.reverse/until-precsave.exp
+ gdb.reverse/finish-reverse.exp
+ gdb.btrace/tailcall-only.exp
+
+ The issue is in gdb/infcmd.c, function finish_command. The value of the
+ two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed
+ to SAL.PC. However, SAL has just been declared. The value of SAL.PC is
+ zero at this point. The intialization of ALT_ENTRY_POINT and ENTRY_POINT
+ needs to be after the initialization of SAL.
+
+ This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT
+ variables to fix the regression failures.
+
+ The patch has been tested on Power10 and on X86.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check remote_exec results in board files
+ Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is
+ checked.
+
+ Tested on x86_64-linux.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.exp
+ In a recent commit I forgot to add a double quote before chmod here:
+ ...
+ remote_exec build $rsh_cmd chmod go-rx ."
+ ...
+
+ Fix it by adding the missing double quote.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.exp
+ Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp,
+ I don't see a relevant difference with the implementation of standard_file
+ in dejagnu.
+
+ Simplify the board by removing ${board}_file.
+
+ Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use localhost instead of 127.0.0.1 for boards
+ Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1".
+
+ Use instead "localhost".
+
+ Tested on x86_64-linux.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.xml/tdesc-regs.exp for remote host
+ Fix test-case gdb.xml/tdesc-regs.exp for remote host by using appropriate
+ filenames.
+
+ Tested on x86_64-linux.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.xml/tdesc-reload.exp for remote host
+ Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate
+ filenames.
+
+ Tested on x86_64-linux.
+
+2023-03-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Set remotedir in local-remote-host-native.exp
+ In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I
+ removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs
+ in test-case gdb.testsuite/board-sanity.exp.
+
+ Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for
+ a host board no longer make compilation fail due to commit 80d6c79866f
+ ("[gdb/testsuite] Handle remotedir in remote_upload").
+
+ This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit
+ 3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards").
+
+ Tested on x86_64-linux.
+
+2023-03-21 Jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Fix disassemble fetch fail return value.
+ This bug reported in
+ https://sourceware.org/bugzilla/show_bug.cgi?id=30184
+ And discussed in
+ https://sourceware.org/pipermail/binutils/2023-February/126213.html
+
+ We also checked the implementation of return value in arm and mips.
+ So this patch changes the return value to -1, that can fix bugs and maintain
+ consistency with other architectures.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_riscv):Change the return value.
+
+2023-03-21 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Remove .c header files from rs6000-aix-nat.c file
+ Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64
+ definitions are moved to ppc-tdep.h we no longer need to import these .c files.
+
+2023-03-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-20 Tom Tromey <tom@tromey.com>
+
+ Remove some unnecessary includes from *-exp.y
+ I noticed a weird comment in one of the .y files, and then ended up
+ removing some unnecessary #includes from these files.
+
+ Tested by rebuilding.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-20 Tom Tromey <tromey@adacore.com>
+
+ Remove mi_version function
+ The mi_version function is unused, and I think it's better overall if
+ it is never used. This patch removes it. Tested by rebuilding.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-20 Tom Tromey <tromey@adacore.com>
+
+ Update python-helper.exp for type allocation changes
+ The type allocation changes introduced a failure in python-helper.exp
+ that I did not notice. The bug is that, with these patches,
+ arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
+ This patch updates the test to allow this.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30253
+
+2023-03-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle remotedir in remote_upload
+ Dejagnu's remotedir implementation has support in remote_exec and
+ remote_download, but not remote_upload.
+
+ Consider the following scenario:
+ - downloading an executable to target,
+ - running it,
+ - uploading a file produced by the executable
+ while assuming remote target user remote-target with homedir
+ /home/remote-target and remotedir set to /home/remote-target/tmp.
+
+ Concretely, it looks like this:
+ ...
+ # binfile == "$outputs/gdb.abc/a.out"
+ set target_binfile [remote_download target $binfile]
+ # target_binfile == "/home/remote-target/tmp/a.out"
+ remote_exec target $target_binfile
+ # Running $target_binfile produced /home/remote-target/tmp/result.txt.
+ set result [remote_upload target /home/remote-target/tmp/result.txt \
+ $outputs/gdb.abc/result.txt]
+ # result == $outputs/gdb.abc/result.txt.
+ ...
+
+ Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
+ overriding dejagnu's remote_upload, such that we can simplify the
+ remote_upload call to:
+ ...
+ set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
+ ...
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30250
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250
+
+2023-03-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix crash during command completion
+ In some cases GDB will fail when attempting to complete a command that
+ involves a rust symbol, the failure can manifest as a crash.
+
+ The problem is caused by the completion_match_for_lcd object being
+ left containing invalid data during calls to cp_symbol_name_matches_1.
+
+ The first question to address is why we are calling a C++ support
+ function when handling a rust symbol. That's due to GDB's auto
+ language detection for msymbols, in some cases GDB can't tell if a
+ symbol is a rust symbol, or a C++ symbol.
+
+ The test application contains symbols for functions which are
+ statically linked in from various rust support libraries. There's no
+ DWARF for these symbols, so all GDB has is the msymbols built from the
+ ELF symbol table.
+
+ Here's the problematic symbol that leads to our crash:
+
+ mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE
+ demangled: core::str::<impl str>::parse
+
+ As an msymbol this is initially created with language auto, then GDB
+ eventually calls symbol_find_demangled_name, which loops over all
+ languages calling language_defn::sniff_from_mangled_name, the first
+ language that can demangle the symbol gets assigned as the language
+ for that symbol.
+
+ Unfortunately, there's overlap in the mangled symbol names,
+ some (legacy) rust symbols can be demangled as both rust and C++, see
+ cplus_demangle in libiberty/cplus-dem.c where this is mentioned.
+
+ And so, because we check the C++ language before we check for rust,
+ then the msymbol is (incorrectly) given the C++ language.
+
+ Now it's true that is some cases we might be able to figure out that a
+ demangled symbol is not actually a valid C++ symbol, for example, in
+ our case, the construct '::<impl str>::' is not, I believe, valid in a
+ C++ symbol, we could look for ':<' and '>:' and refuse to accept this
+ as a C++ symbol.
+
+ However, I'm not sure it is always possible to tell that a demangled
+ symbol is rust or C++, so, I think, we have to accept that some times
+ we will get this language detection wrong.
+
+ If we accept that we can't fix the symbol language detection 100% of
+ the time, then we should make sure that GDB doesn't crash when it gets
+ the language wrong, that is what this commit addresses.
+
+ In our test case the user tries to complete a symbol name like this:
+
+ (gdb) complete break pars
+
+ This results in GDB trying to find all symbols that match 'pars',
+ eventually we consider our problematic symbol, and we end up with a
+ call stack that looks like this:
+
+ #0 0x0000000000f3c6bd in strncmp_iw_with_mode
+ #1 0x0000000000706d8d in cp_symbol_name_matches_1
+ #2 0x0000000000706fa4 in cp_symbol_name_matches
+ #3 0x0000000000df3c45 in compare_symbol_name
+ #4 0x0000000000df3c91 in completion_list_add_name
+ #5 0x0000000000df3f1d in completion_list_add_msymbol
+ #6 0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on
+ #7 0x0000000000658c08 in language_defn::collect_symbol_completion_matches
+ #8 0x0000000000df54c9 in collect_symbol_completion_matches
+ #9 0x00000000009d98fb in linespec_complete_function
+ #10 0x00000000009d99f0 in complete_linespec_component
+ #11 0x00000000009da200 in linespec_complete
+ #12 0x00000000006e4132 in complete_address_and_linespec_locations
+ #13 0x00000000006e4ac3 in location_completer
+
+ In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly
+ tries to match the demangled problematic symbol name against the user
+ supplied text ('pars'). Each time around the loop another component
+ of the symbol name is stripped off, thus, we check 'pars' against
+ these options:
+
+ core::str::<impl str>::parse
+ str::<impl str>::parse
+ <impl str>::parse
+ parse
+
+ As soon as we get a match the cp_symbol_name_matches_1 exits its loop
+ and returns. In our case, when we're looking for 'pars', the match
+ occurs on the last iteration of the loop, when we are comparing to
+ 'parse'.
+
+ Now the problem here is that cp_symbol_name_matches_1 uses the
+ strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for
+ skipping over template parameters. This allows GDB to match the
+ symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'.
+ Inside strncmp_iw_with_mode GDB will record any template arguments
+ that it has skipped over inside the completion_match_for_lcd object
+ that is passed in as an argument.
+
+ And so, when GDB tries to match against '<impl str>::parse', the first
+ thing it sees is '<impl str>', GDB assumes this is a template argument
+ and records this as a skipped region within the
+ completion_match_for_lcd object. After '<impl str>' GDB sees a ':'
+ character, which doesn't match with the 'pars' the user supplied, so
+ strncmp_iw_with_mode returns a value indicating a non-match. GDB then
+ removes the '<impl str>' component from the symbol name and tries
+ again, this time comparing to 'parse', which does match.
+
+ Having found a match, then in cp_symbol_name_matches_1 we record the
+ match string, and the full symbol name within the
+ completion_match_result object, and return.
+
+ The problem here is that the skipped region, the '<impl str>' that we
+ recorded in the penultimate loop iteration was never discarded, its
+ still there in our returned result.
+
+ If we look at what the pointers held in the completion_match_result
+ that cp_symbol_name_matches_1 returns, this is what we see:
+
+ core::str::<impl str>::parse
+ | \________/ |
+ | | '--- completion match string
+ | '---skip range
+ '--- full symbol name
+
+ When GDB calls completion_match_for_lcd::finish, GDB tries to create a
+ string using the completion match string (parse), but excluding the
+ skip range, as the stored skip range is before the start of the
+ completion match string, then GDB tries to do some weird string
+ creation, which will cause GDB to crash.
+
+ The reason we don't often see this problem in C++ is that for C++
+ symbols there is always some non-template text before the template
+ argument. This non-template text means GDB is likely to either match
+ the symbol, or reject the symbol without storing a skip range.
+
+ However, notice, I did say, we don't often see this problem. Once I
+ understood the issue, I was able to reproduce the crash using a pure
+ C++ example:
+
+ template<typename S>
+ struct foo
+ {
+ template<typename T>
+ foo (int p1, T a)
+ {
+ s = 0;
+ }
+
+ S s;
+ };
+
+ int
+ main ()
+ {
+ foo<int> obj (2.3, 0);
+ return 0;
+ }
+
+ Then in GDB:
+
+ (gdb) complete break foo(int
+
+ The problem here is that the C++ symbol for the constructor looks like
+ this:
+
+ foo<int>::foo<double>(int, double)
+
+ When GDB enters cp_symbol_name_matches_1 the symbols it examines are:
+
+ foo<int>::foo<double>(int, double)
+ foo<double>(int, double)
+
+ The first iteration of the loop will match the 'foo', then add the
+ '<int>' template argument will be added as a skip range. When GDB
+ find the ':' after the '<int>' the first iteration of the loop fails
+ to match, GDB removes the 'foo<int>::' component, and starts the
+ second iteration of the loop.
+
+ Again, GDB matches the 'foo', and now adds '<double>' as a skip
+ region. After that the '(int' successfully matches, and so the second
+ iteration of the loop succeeds, but, once again we left the '<int>' in
+ place as a skip region, even though this occurs before the start of
+ our match string, and this will cause GDB to crash.
+
+ This problem was reported to the mailing list, and a solution
+ discussed in this thread:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html
+
+ The solution proposed here is similar to one proposed by the original
+ bug reported, but implemented in a different location within GDB.
+ Instead of placing the fix in strncmp_iw_with_mode, I place the fix in
+ cp_symbol_name_matches_1. I believe this is a better location as it
+ is this function that implements the loop, and it is this loop, which
+ repeatedly calls strncmp_iw_with_mode, that should be resetting the
+ result object state (I believe).
+
+ What I have done is add an assert to strncmp_iw_with_mode that the
+ incoming result object is empty.
+
+ I've also added some other asserts in related code, in
+ completion_match_for_lcd::mark_ignored_range, I make some basic
+ assertions about the incoming range pointers, and in
+ completion_match_for_lcd::finish I also make some assertions about how
+ the skip ranges relate to the match pointer.
+
+ There's two new tests. The original rust example that was used in the
+ initial bug report, and a C++ test. The rust example depends on which
+ symbols are pulled in from the rust libraries, so it is possible that,
+ at some future date, the problematic symbol will disappear from this
+ test program. The C++ test should be more reliable, as this only
+ depends on symbols from within the C++ source code.
+
+ Since I originally posted this patch to the mailing list, the
+ following patch has been merged:
+
+ commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb
+ Date: Sun Mar 19 09:13:10 2023 -0600
+
+ Use rust_demangle to fix a crash
+
+ This solves the problem of a rust symbol ending up in the C++ specific
+ code by changing the order languages are sorted. However, this new
+ commit doesn't address the issue in the C++ code which was fixed with
+ this commit.
+
+ Given that the C++ issue is real, and has a reproducer, I'm still
+ going to merge this fix. I've left the discussion of rust in this
+ commit message as I originally wrote it, but it should be read within
+ the context of GDB prior to commit 6e7eef72164c00d6a5a7.
+
+ Co-Authored-By: Zheng Zhan <zzlossdev@163.com>
+
+2023-03-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop identifier_chars[]
+ It tries to resemble what's underlying is_part_of_name(), but doesn't
+ quite achieve that: '$' for example is unconditionally marked as part of
+ symbol names, but was included as identifier char for Intel syntax only.
+ Note that i386_att_operand() checks for the immediate prefix first, so
+ the wider coverage by starts_memory_operand() is has no real effect
+ there, but it does matter for something like
+
+ mov %fs:$dollar, %eax
+
+ which previously wasn't accepted (but which clearly is a memory
+ reference - there's no point in forcing people to parenthesize the
+ symbol name). Similarly including '%' as an identfier for Intel syntax
+ had no real significance to the rest of the assembler. If '%' was to be
+ valid in (unquoted) symbol names, LEX_PCT would need to be defined.
+
+ Note further that this also addresses the latent issue of a sub-target
+ defining LEX_AT or LEX_QM to zero: That would make '@' and/or '?' no
+ valid part of symbol names, but would have included them in what
+ is_identifier_char() considers a valid part of a name. (There's a minor
+ related issue which is actually being eliminated: te-interix.h allows
+ '@' only in the middle of symbol names, yet starts_memory_operand()
+ specifically looks at the first character of [possibly] a symbol name.)
+
+ In parse_real_register() there's no point also checking is_name_ender()
+ as at this point no character is marked solely LEX_END_NAME by any sub-
+ target. Checking is_name_beginner() is also pointless as the hash lookup
+ will fail anyway for a zero-length name.
+
+ While touching the check in parse_real_register() also drop the
+ "allow_naked_reg" part of the condition: This has only led to
+ inconsistent error messages.
+
+2023-03-20 Jan Beulich <jbeulich@suse.com>
+
+ x86/AT&T: restrict recognition of the "absolute branch" prefix character
+ While in principle merely rejecting this for .insn would be sufficient
+ for the purposes there, be more generic and reject it for anything that
+ isn't going to be a branch: All elements of same-mnemonic template
+ groups either are branches, or are not, and the few cases possibly
+ requiring a 2nd parsing pass aren't affected either. This then also
+ improves diagnostics for misuses like
+
+ inc *%eax
+ incl %fs:*(%eax)
+ add *$1, %eax
+
+2023-03-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop "shimm" special case template expansions
+ With VexVVVV only being boolean, the SSE shift-by-immediate instructions
+ don't need special casing anymore for SSE2AVX handling. Simplify the two
+ respective templates. (No change to generated tables.)
+
+2023-03-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: VexVVVV is now merely a boolean
+ With the SDM long having dropped the NDS/NDD/DDS concept of identifying
+ encoding variants, we can finally do away with this concept as well. Of
+ the few consumers of the attribute, only an assertion was still checking
+ for a particular value, which we don't really need to retain.
+
+ When touching lines anyway, modernize other aspects as well. This often
+ improves similarity to adjacent lines.
+
+2023-03-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-work build_modrm_byte()'s register assignment
+ The function has accumulated a number of special cases for no real
+ reason. Some were necessary because insn attributes (SwapSources in
+ particular) weren't suitably utilized instead. Note that the addition of
+ SwapSources actually increases consistency among the templates: Like
+ others which already have the attribute, these are all insns where the
+ VEX.VVVV-encoded register comes first (or last when looking at the SDM).
+
+ Note that the vexvvvv attribute now has merely boolean meaning anymore,
+ in line with the SDM long having dropped the NDS/NDD/DDS concept of
+ identifying encoding variants. The fallout will be taken care of
+ subsequently, though, to not further clutter the change here.
+
+ As to the TILEZERO special case: If more instructions like this
+ appeared, a new attribute would likely be the way to go. But as long as
+ it's only a single insn, going from the mnemonic is cheaper.
+
+2023-03-20 Cupertino Miranda <cupertino.miranda@oracle.com>
+
+ Changed ld and gas BPF tests
+ Recent BPF patch removed and renamed the list of relocations based on
+ the limitations of BPF instruction set.
+ This patch is a correction to the tests.
+
+ Reloc howto access broken for BPF
+ Forgot to change the logic to access the reloc howto from
+ bpf_elf_relocate_section.
+ Problem was introduced in previous BPF commit.
+
+2023-03-20 Tom Tromey <tom@tromey.com>
+
+ Use rust_demangle to fix a crash
+ PR rust/30211 points out a crash caused by a particular completion.
+ This turns out to happen because a Rust minsym winds up in a
+ C++-specific path in strncmp_iw_with_mode, which ultimately causes the
+ completer to pass invalid arguments to string::append.
+
+ This patch fixes the bug by reordering the language constants so that
+ Rust comes before C++, and then using rust_demangle. This ensures
+ that minsyms are correctly marked as "Rust", avoiding this code and
+ thus the crash.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20367
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30211
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-03-20 Tom Tromey <tromey@adacore.com>
+
+ Make ui_out::do_progress_end 'private'
+ I noticed that ui_out::do_progress_end is public, just to support one
+ use in debuginfod-support.c. This patch makes it private, updates
+ progress_info to call it from its destructor, and finally changes
+ debuginfod-support.c to follow.
+
+2023-03-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't use the global thread-id in the saved breakpoints file
+ I noticed that breakpoint::print_recreate_thread was printing the
+ global thread-id. This function is used to implement the 'save
+ breakpoints' command, and should be writing out suitable CLI commands
+ for recreating the current breakpoints. The CLI does not use global
+ thread-ids, but instead uses the inferior specific thread-ids,
+ e.g. "2.1".
+
+ After some discussion on the mailing list it was suggested that the
+ most consistent solution would be for the saved breakpoints file to
+ always contain the inferior-qualified thread-id, so the file would
+ include "thread 1.1" instead of just "thread 1", even when there is
+ only a single inferior.
+
+ So, this commit adds print_full_thread_id, which is just like the
+ existing print_thread_id, only it always prints the inferior-qualified
+ thread-id.
+
+ I then update the existing print_thread_id to make use of this new
+ function, and finally, I update breakpoint::print_recreate_thread to
+ also use this new function.
+
+ There's a multi-inferior test that confirms the saved breakpoints file
+ correctly includes the fully-qualified thread-id, and I've also
+ updated the single inferior test gdb.base/save-bp.exp to have it
+ validate that the saved breakpoints file includes the
+ inferior-qualified thread-id, even for this single inferior case.
+
+2023-03-20 Alan Modra <amodra@gmail.com>
+
+ Revert "segfault at i386-dis.c:9815"
+ This reverts commit 92d450c79ad321e42f9a77692b5db10d0f7b9344.
+
+ Accessing these local var structs using a volatile qualified pointer
+ may indeed read the object, but I don't think changed values are
+ guaranteed to be written back to the object unless the actual object
+ is declared volatile. That would probably slow down i386 disassembly
+ unacceptably.
+
+2023-03-20 Alan Modra <amodra@gmail.com>
+
+ libctf: unused variable
+ * ctf-archive.c (arc_mmap_writeout): Delete unused variable.
+
+2023-03-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: Use prototype to call libc functions
+ libcollector may not link against libC.
+ We use dlsym() to get a function from libc.
+ In some files, pointers to these functions do not have prototypes.
+ I also moved the shared definitions to libcollector/collect.h.
+
+ gprofng/ChangeLog
+ 2023-03-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ libcollector/collector.c: Add prototypes.
+ libcollector/dispatcher.c: Likewise.
+ libcollector/heaptrace.c: Likewise.
+ libcollector/iotrace.c: Likewise.
+ libcollector/linetrace.c: Likewise.
+ libcollector/mmaptrace.c: Likewise.
+ libcollector/synctrace.c: Likewise.
+ libcollector/collector.h: Add CALL_REAL(), NULL_PTR(), and DBG_LT.
+
+2023-03-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-19 Tom Tromey <tom@tromey.com>
+
+ Don't declare psymbol_functions::fill_psymbol_map
+ psymbol_functions::fill_psymbol_map was removed, but I forgot to
+ remove the declaration. This patch removes it. Tested by rebuilding.
+
+2023-03-19 Alan Modra <amodra@gmail.com>
+
+ segfault at i386-dis.c:9815
+ * i386-dis.c (print_insn): Access "ins" and "priv" via volatile
+ pointers after second sigsetjmp return.
+
+2023-03-19 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Enable vector register visibility in core file for AIX binutils
+ This patch will enable vector register visibility when AIX FOLKS do
+ core file analysis.
+
+2023-03-19 Alan Modra <amodra@gmail.com>
+
+ Regen ld/po/BLD-POTFILES.in
+
+2023-03-19 Alan Modra <amodra@gmail.com>
+
+ XCOFF archive sanity check
+ XCOFF archive elements are in a linked list. Add a little more sanity
+ checking. This of course doesn't stop the fuzzers finding a way to
+ make a loop, but this check is cheap.
+
+ * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Sanity
+ check that next element isn't pointing back to the header.
+
+2023-03-19 Alan Modra <amodra@gmail.com>
+
+ rewrite_elf_program_header and want_p_paddr_set_to_zero
+ Layout in rewrite_elf_program_header is really done by lma, even if
+ program headers are going to have their p_paddr forced to zero. Thus
+ when not matching against an existing segment, don't try to use a
+ "vma" from elf_segment_map.
+
+ * elf.c (is_contained_by): Replace "bed" param with "use_vaddr".
+ (IS_SECTION_IN_INPUT_SEGMENT): Adjust is_contained_by call.
+ (rewrite_elf_program_header): Always match against lma in
+ calls to is_contained_by using new maps.
+
+2023-03-19 Alan Modra <amodra@gmail.com>
+
+ Another sanity check for read_section_stabs_debugging_info
+ * rddbg.c (read_section_stabs_debugging_info): Ignore invalid
+ stab sections with size less than 12 bytes.
+
+ ctf segfaults
+ PR 30228
+ PR 30229
+ * ctf-open.c (ctf_bufopen_internal): Check for NULL cts_data.
+ * ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Likewise.
+
+2023-03-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove objfile_type
+ This removes objfile_type, in favor of always using the per-arch
+ builtins.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Add some types to struct builtin_type
+ This adds some types to struct builtin_type, ensuring it contains all
+ the types currently used by objfile_type.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Rename objfile_type to builtin_type
+ This renames objfile_type to be an overload of builtin_type, in
+ preparation for their unification.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Use builtin type when appropriate
+ There are a few spots that check whether a type is objfile-owned, and
+ then choose either the objfile- or arch-specific builtin type. I
+ don't think there is a need to do this any more (if there ever was),
+ because it is ok for an objfile-allocated type to refer to an
+ arch-allocated type.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Use type allocator for set types
+ This changes the set type creation function to accept a type
+ allocator, and updates all the callers. Note that symbol readers
+ should generally allocate on the relevant objfile, regardless of the
+ underlying type of the set, which is what this patch implements.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Use type allocator for array types
+ This changes the array type creation functions to accept a type
+ allocator, and updates all the callers. Note that symbol readers
+ should generally allocate on the relevant objfile, regardless of the
+ placement of the index type of the array, which is what this patch
+ implements.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Use type allocator for range types
+ This changes the range type creation functions to accept a type
+ allocator, and updates all the callers. Note that symbol readers
+ should generally allocate on the relevant objfile, regardless of the
+ underlying type of the range, which is what this patch implements.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_pointer_type and init_pointer_type
+ This unifies arch_pointer_type and init_pointer_type by using a type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_decfloat_type and init_decfloat_type
+ This unifies arch_decfloat_type and init_decfloat_type by using a type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_float_type and init_float_type
+ This unifies arch_float_type and init_float_type by using a type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_boolean_type and init_boolean_type
+ This unifies arch_boolean_type and init_boolean_type by using a type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_character_type and init_character_type
+ This unifies arch_character_type and init_character_type by using a
+ type allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Unify arch_integer_type and init_integer_type
+ This unifies arch_integer_type and init_integer_type by using a type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove init_type
+ This removes init_type, replacing all uses with the new type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove arch_type
+ This removes arch_type, replacing all uses with the new type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Reuse existing builtin types
+ This changes a few spots to reuse the existing builting "void" type,
+ rather than construct a new one.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove alloc_type
+ This removes alloc_type, replacing all uses with the new type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove alloc_type_copy
+ This removes alloc_type_copy, replacing all uses with the new type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Remove alloc_type_arch
+ This removes alloc_type_arch, replacing all uses with the new type
+ allocator.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom Tromey <tom@tromey.com>
+
+ Introduce type_allocator
+ This introduces a new type_allocator class. This class will be used
+ to abstract out the placement of new types, so that type-creation code
+ can be simplified and shared.
+
+ Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle unbuffer_output.c for remote host
+ Handle $srcdir/lib/unbuffer_output.c using lappend_include_file.
+
+ Tested on x86_64-linux.
+
+2023-03-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle my-syscalls.h for remote host
+ Handle $srcdir/lib/my-syscalls.h using lappend_include_dir.
+
+ Tested on x86_64-linux.
+
+2023-03-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle attributes.h for remote host
+ Handle $srcdir/lib/attributes.h using lappend_include_dir.
+
+ Tested on x86_64-linux.
+
+2023-03-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-17 Tom Tromey <tom@tromey.com>
+
+ Fix line table regression
+ Simon pointed out a line table regression, and after a couple of false
+ starts, I was able to reproduce it by hand using his instructions.
+
+ The bug is that most of the code in do_mixed_source_and_assembly uses
+ unrelocated addresses, but one spot does:
+
+ pc = low;
+
+ ... after the text offset has been removed.
+
+ This patch fixes the problem by introducing a new type to represent
+ unrelocated addresses in the line table. This prevents this sort of
+ bug to some degree (it's still possible to manipulate a CORE_ADDR in a
+ bad way, this is unavoidable).
+
+ However, this did let the compiler flag a few spots in that function,
+ and now it's not possible to compare an unrelocated address from a
+ line table with an ordinary CORE_ADDR.
+
+ Regression tested on x86-64 Fedora 36, though note this setup never
+ reproduced the bug in the first place. I also tested it by hand on
+ the disasm-optim test program.
+
+2023-03-17 Frederic Cambus <fred@statdns.com>
+
+ Update the NetBSD system call table to add eventfd(2) and timerfd(2).
+ Generated from sys/sys/syscall.h revision 1.321.
+
+2023-03-17 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce bp_loc_tracepoint
+ Since commit cb1e4e32c2d9 ("catch catch/throw/rethrow", breakpoint ->
+ catchpoint), this simple tracing scenario does not work:
+
+ $ gdb/gdb -nx -q --data-directory=gdb/data-directory ./test
+ Reading symbols from ./test...
+ (gdb) tar rem :1234
+ Remote debugging using :1234
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2
+ (gdb) trace do_something
+ Tracepoint 1 at 0x555555555144: file test.c, line 5.
+ (gdb) tstart
+ (gdb) continue
+ Continuing.
+ Target returns error code '01'.
+
+ The root cause is that the bp_location::nserted flag does not transfer
+ anymore from an old bp_location to the new matching one. When a shared
+ library gets loaded, GDB computes new breakpoint locations for each
+ breakpoint in update_breakpoint_locations. The new locations are in the
+ breakpoint::loc chain, while the old locations are still in the
+ bp_locations global vector. Later, update_global_location_list is
+ called. It tries to map old locations to new locations, and if
+ necessary transfer some properties, like the inserted flag.
+
+ Since commit cb1e4e32c2d9, the inserted flag isn't transferred for
+ locations of tracepoints. This is because bl_address_is_meaningful used
+ to be implemented like this:
+
+ static int
+ breakpoint_address_is_meaningful (struct breakpoint *bpt)
+ {
+ enum bptype type = bpt->type;
+
+ return (type != bp_watchpoint && type != bp_catchpoint);
+ }
+
+ and was changed to this:
+
+ static bool
+ bl_address_is_meaningful (bp_location *loc)
+ {
+ return loc->loc_type != bp_loc_other;
+ }
+
+ Because locations for tracepoints have the bp_loc_other type,
+ bl_address_is_meaningful started to return false for them, where it
+ returned true before. This made update_global_location_list skip the
+ part where it calls swap_insertion.
+
+ I think this can be solved by introduced a new bp_loc_tracepoint
+ bp_loc_type.
+
+ I don't know if it's accurate, but my understanding is that bp_loc_type
+ describes roughly "how do we ask the target to insert that location".
+ bp_loc_software_breakpoint are inserted using
+ target_ops::insert_breakpoint_location. bp_loc_hardware_breakpoint are
+ inserted using target_ops::insert_hw_breakpoint.
+ bp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted
+ using target_ops::insert_watchpoint. For all these, the address is
+ meaningful, as we ask the target to insert the point at a specific
+ address. bp_loc_other is a catch-all for "the rest", in practice for
+ catchpoints that don't have a specific address (hence why
+ bl_address_is_meaningful returns false for them). For instance,
+ inserting a signal catchpoint is done by asking the target to report
+ that specific signal. GDB doesn't associate an address to that.
+
+ But tracepoints do have a meaningful address to thems, so they can't be
+ bp_loc_other, with that logic. They also can't be
+ bp_loc_software_breakpoint, because we don't want GDB to insert
+ breakpoints for them (even though they might be implemented using
+ software breakpoints by the remote side). So, the new bp_loc_tracepoint
+ type describes that the way to insert these locations is with
+ target_ops::download_tracepoint. It makes bl_address_is_meaningful
+ return true for them. And they'll be ignored by insert_bp_location and
+ GDB won't try to insert a memory breakpoint for them.
+
+ With this, I see a few instances of 'Target returns error code: 01'
+ disappearing from gdb.log, and the results of gdb.trace/*.exp improve a
+ little bit:
+
+ -# of expected passes 3765
+ +# of expected passes 3781
+ -# of unexpected failures 518
+ +# of unexpected failures 498
+
+ Things remain quite broken in that area though.
+
+ Change-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3
+
+2023-03-17 Carl Love <cel@us.ibm.com>
+
+ PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
+ PPC64 multiple entry points, a normal entry point and an alternate entry
+ point. The alternate entry point is to setup the Table of Contents (TOC)
+ register before continuing at the normal entry point. When the TOC is
+ already valid, the normal entry point is used, this is typically the case.
+ The alternate entry point is typically referred to as the global entry
+ point (GEP) in IBM. The normal entry point is typically referred to as
+ the local entry point (LEP).
+
+ When GDB is executing the finish command in reverse, the function
+ finish_backward currently sets the break point at the alternate entry point.
+ This issue is if the function, when executing in the forward direction,
+ entered the function via the normal entry point, execution in the reverse
+ direction will never sees the break point at the alternate entry point. In
+ this case, the reverse execution continues until the next break point is
+ encountered thus stopping at the wrong place.
+
+ This patch adds a new address to struct execution_control_state to hold the
+ address of the alternate entry point (GEP). The finish_backwards function
+ is updated, if the stopping point is between the normal entry point (LEP)
+ and the end of the function, a breakpoint is set at the normal entry point.
+ If the stopping point is between the entry points, a breakpoint is set at
+ the alternate entry point. This ensures that GDB will always stop at the
+ normal entry point. If the function did enter via the alternate entry
+ point, GDB will detect that and continue to execute backwards in the
+ function until the alternate entry point is reached.
+
+ The patch fixes the behavior of the reverse-finish command on PowerPC to
+ match the behavior of the command on other platforms, specifically X86.
+ The patch does not change the behavior of the command on X86.
+
+ A new test is added to verify the reverse-finish command on PowerPC
+ correctly stops at the instruction where the function call is made.
+
+ The patch fixes 11 regression errors in test gdb.reverse/finish-precsave.exp
+ and 11 regression errors in test gdb.reverse/finish-reverse.exp.
+
+ The patch has been tested on Power 10 and X86 processor with no new
+ regression failures.
+
+2023-03-17 Carl Love <cel@us.ibm.com>
+
+ Move step_until procedure
+ Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp
+ is moved to lib/gdb.exp and renamed repeat_cmd_until. The existing procedure
+ gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until
+ procedure. The existing procedure gdb_step_until is changed to just call
+ the new repeat_cmd_until procedure with the command set to "step" and an
+ optional CURRENT string. The default CURRENT string is set to "\}" to work
+ with the existing uses of procedure gdb_step_until.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix regexp in gdb.arch/ftrace-insn-reloc.exp
+ With test-case gdb.arch/ftrace-insn-reloc.exp and host board
+ local-remote-host-notty and target board native-gdbserver I run into:
+ ...
+ (gdb) info sharedlibrary^M
+ From To Syms Read Shared Object Library^M
+ $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
+ $hex $hex Yes /home/remote-host/libinproctrace.so^M
+ $hex $hex Yes /lib64/libm.so.6^M
+ $hex $hex Yes /lib64/libc.so.6^M
+ $hex $hex Yes /lib64/libdl.so.2^M
+ $hex $hex Yes (*) /usr/lib64/libstdc++.so.6^M
+ $hex $hex Yes (*) /lib64/libgcc_s.so.1^M
+ $hex $hex Yes /lib64/libpthread.so.0^M
+ (*): Shared library is missing debugging information.^M
+ (gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
+ ...
+ due to trying to match libinproctrace.so using the target path, while the
+ command lists it using the host path.
+
+ Fix this by making the regexp less strict.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle remote host in gdb_load_shlib
+ With test-case gdb.arch/ftrace-insn-reloc.exp and host board
+ local-remote-host-notty and target board native-gdbserver I run into:
+ ...
+ (gdb) tstart^M
+ Target returns error code '.In-process agent library not loaded in process. \
+ Fast and static trace points unavailable.'.^M
+ (gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
+ ...
+
+ Fix this by:
+ - handling remote host in gdb_load_shlib, and
+ - moving the gdb_load_shlib to after the clean_restart, such that the
+ set solib-search-path can take effect.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/i386-biarch-core.exp for remote host
+ Fix test-case gdb.arch/i386-biarch-core.exp using gdb_download_remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle REMOTE_HOST_USERNAME in local-remote-host
+ Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for
+ REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.
+
+ This helps to keep the home dir clean.
+
+ Since the setup makes $build/gdb/testsuite on build unreadable for the remote
+ host, we run into permission problems for GDB and the data-directory, so fix
+ this (as was done for gdbserver in gdbserver-base.exp) using file normalize.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Set remotedir by default in some boards
+ When doing a gdb_simple_compile, and downloading the resulting exec $obj
+ to target the result $target_obj may be a relative file path, which may give
+ problems when trying to do:
+ ...
+ remote_exec target $target_obj
+ ...
+
+ Fix/workaround this on some target boards by setting remotedir by default, and
+ add a corresponding test in gdb.testsuite/board-sanity.exp.
+
+ This doesn't work for host/target board local-remote-host-native, so xfail this.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix have_avx for remote target
+ In proc have_avx we compile some source into an exec, resulting in a file $obj
+ on build, and then attempt to execute it on target:
+ ...
+ set result [remote_exec target $obj]
+ ...
+
+ Fix this by using gdb_remote_download target.
+
+ Likewise in a few other procs that use "remote_exec target".
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle precise-aligned-alloc.c for remote host
+ With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
+ host board local-remote-host-notty and target board native-gdbserver I run
+ into:
+ ...
+ gdb compile failed, i386-sse.c:68:10: fatal error: \
+ ../lib/precise-aligned-alloc.c: No such file or directory
+ #include "../lib/precise-aligned-alloc.c"
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ ...
+
+ Fix this using '#include "precise-aligned-alloc.c"' and making that work with
+ non-remote and remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle remote host in escape_for_host
+ With test-case gdb.arch/ftrace-insn-reloc.exp and host board
+ local-remote-host-notty and target board native-gdbserver, I run into:
+ ...
+ FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
+ ...
+ due to having:
+ ...
+ $ readelf -d ftrace-insn-reloc | grep RUNPATH
+ 0x000000000000001d (RUNPATH) Library runpath: []
+ ...
+ instead of:
+ ...
+ $ readelf -d ftrace-insn-reloc | grep RUNPATH
+ 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN]
+ ...
+
+ Handle this in escape_for_host.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add escape_for_host
+ In gdb_compile we have:
+ ...
+ lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
+ ...
+ and we could improve readability by using {} rather than "":
+ ...
+ lappend new_options {ldflags=-Wl,-rpath,\$ORIGIN}
+ ...
+
+ But rather than manually adding escapes in a string, add a new proc
+ escape_for_host that care of this for us, allowing us to write:
+ ...
+ lappend new_options [escape_for_host {ldflags=-Wl,-rpath,$ORIGIN}]
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-17 Alan Modra <amodra@gmail.com>
+
+ mach-o: out of memory in get_dynamic_reloc_upper_bound
+ * mach-o.c (bfd_mach_o_canonicalize_dynamic_reloc): Move sanity
+ checks..
+ (bfd_mach_o_get_dynamic_reloc_upper_bound): ..to here.
+
+ Another source_sh
+ * scripttempl/z80.sc: Use source_sh to source elf.sc.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Declare ada unsupported for remote host
+ Currently gdb_ada_compile doesn't support remote host.
+
+ Make this explicit in allow_ada_tests.
+
+ Tested on x86_64-linux.
+
+2023-03-17 Jan Beulich <jbeulich@suse.com>
+
+ gas: apply md_register_arithmetic also to unary '+'
+ Even a unary '+' has to be considered arithmetic; at least on x86 in
+ Intel Syntax mode otherwise bogus insn operands may be accepted.
+ Convert this specific case to binary + (i.e. 0 + <register>). (An
+ implication is that md_operator(,1,) would need to deal with arch-
+ specific equivalents of unary '+' is a similar way, if such an arch-
+ specific variant would be specified in the first place.)
+
+ To avoid duplicating what make_expr_symbol() does to construct a
+ constant-zero expression, simply make its previously local variable a
+ file-scope static one. This way there's also no need to invoke
+ clean_up_expression().
+
+2023-03-17 Jan Beulich <jbeulich@suse.com>
+
+ gas: expose flag_macro_alternate globally
+ Yet again with the removal of gasp about 20 years ago this extra level
+ of indirection isn't necessary anymore either. Drop macro.c's local
+ variable and make as.c's global.
+
+ While doing the conversion, switch the variable to "bool".
+
+2023-03-17 Jan Beulich <jbeulich@suse.com>
+
+ gas: use flag_mri directly in macro processing
+ Again with the removal of gasp about 20 years ago the extra level of
+ indirection isn't necessary anymore. Drop macro.c's local variable and
+ use the global flag directly.
+
+ gas: isolate macro_strip_at to macro.c
+ This removes a leftover from i960 support; with that nothing is left
+ which would set macro_strip_at to non-zero, so the variable is converted
+ to a #define (retaining the logic in case a new user would appear) and
+ macro_init()'s respective parameter is dropped.
+
+ gas: drop function pointer parameter from macro_init()
+ With the removal of gasp (about 20 years ago) the need for this kind-
+ of-hook has disappeared. Go a step beyond merely moving the to be called
+ function: Inline its contents right at the sole call site.
+
+2023-03-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix filename in gdb.debuginfod/crc_mismatch.exp
+ After running test-case gdb.debuginfod/crc_mismatch.exp, I find a dir called '$':
+ ...
+ $ ls $build/gdb/testsuite/
+ $ config.log gdb.log lib outputs site.exp
+ cache config.status gdb.sum Makefile site.bak temp
+ ...
+
+ Fix this by removing the stray '$' here:
+ ...
+ set debugfile "$[standard_output_file ${testfile}.debug]"
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: extended documentation for inferior function calls
+ I noticed that the documentation for inferior function calls doesn't
+ say much about what happens if/when an inferior function call is
+ interrupted, i.e. it doesn't describe what the dummy frame looks like
+ on the stack, or how GDB behaves when the inferior is continued and
+ reaches the dummy frame.
+
+ This commit aims to add some of this missing information.
+
+2023-03-16 Tom Tromey <tromey@adacore.com>
+
+ Fix build breakage in rs6000-aix-tdep.c
+ A recent change to rs6000-aix-tdep.c broke the build. This patch
+ fixes it by declaring a few target descriptions in ppc-tdep.h and then
+ not including the various features .c files in rs6000-aix-tdep.c.
+
+2023-03-16 Hui Li <lihui@loongson.cn>
+
+ gdb/testsuite: Add support for LoongArch in gdb.base/float.exp
+ The test results on LoongArch as follows:
+
+ Without this patch:
+
+ ```
+ $ make check-gdb TESTS="gdb.base/float.exp"
+ === gdb Summary ===
+
+ # of expected passes 2
+ # of unexpected failures 1
+
+ ```
+ With this patch:
+
+ ```
+ $ make check-gdb TESTS="gdb.base/float.exp"
+ === gdb Summary ===
+
+ # of expected passes 3
+
+ ```
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-16 Christophe Lyon <christophe.lyon@linaro.org>
+
+ Re: Add --enable-linker-version option
+ The recently-added ld-version*.d tests expect
+ .*GNU ld \(GNU Binutils\) 2.*
+ in the .comment section.
+
+ However, when buidling --with-pkgversion=XXX, we get
+ GNU ld (XXX) 2.[...]
+ instead, leading to a spurious FAIL.
+
+ This small patch replaces "GNU Binutils" with ".*" instead.
+
+ I inspected other testcases to see if we already had similar
+ occurrences but I couldn't see any, so I hope this fix is OK for the
+ purpose?
+
+ Thanks,
+
+ Christophe
+
+2023-03-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: spring clean the Python unwinders documentation
+ The documentation for the Python Unwinders API could do with some
+ improvement. The 'Unwinder Skeleton Code' has an error: it says
+ 'unwinders' when it should say 'unwinder' in one case.
+
+ Additionally, by placing the 'Unwinder Skeleton Code' before the
+ section 'Registering an Unwinder' we have skipping including the
+ registration line in the skeleton code. But this is confusion for
+ users (I think) as the skeleton code is almost complete, except for
+ one missing line which the user has to figure out for themselves. By
+ reordering the sections, it is now obvious that the registration
+ should be included in the skeleton code, and the example is therefore
+ almost complete.
+
+ Additionally, in the example skeleton code the way in which the
+ frame-id was being built (using the current stack point and program
+ counter is (a) not correct, and (b) counter to what is laid out in the
+ 'Unwinder Input' section when describing building a frame-id.
+
+ I've removed the incorrect code and replaced it with more generic
+ comments indicating what needs to be done. As the actual actions that
+ need to be performed are both architecture specific, and dependent on
+ the function being unwound, it's almost impossible to include more
+ exact code here, but I think what I'm proposing is less misleading
+ than what we had before.
+
+ I've also added more cross references.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-03-16 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: disable ilp32 tests for aarch64-qnx
+ aarch64nto32 emulation isn't supported. The tests will then fall back
+ on aarch64elf32. It does work but some extra warnings are being
+ generated because the "-z relro" being added aarch64nto but ignored by
+ aarch64elf32 emulation.
+ Skip the tests to avoid any problems.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-aarch64/emit-relocs-112-overflow.d: Skip for
+ aarch64nto.
+ * testsuite/ld-aarch64/emit-relocs-112.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-113.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-114-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-114.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-115.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-116-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-116.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-117.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-118-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-118.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-119.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-22.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-23.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-28.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-86-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-86.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-87.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-88-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-88.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-89.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-90-overflow.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-90.d: Likewise.
+ * testsuite/ld-aarch64/emit-relocs-92.d: Likewise.
+ * testsuite/ld-aarch64/tls-desc-ie-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-all-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-gd-ie-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-gd-le-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-gdesc-le-2-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-gdesc-le-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-ie-le-2-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-ie-le-3-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-ie-le-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-ld-le-small-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-relax-ld-le-tiny-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-tiny-desc-ie-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-tiny-desc-le-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-tiny-gd-ie-ilp32.d: Likewise.
+ * testsuite/ld-aarch64/tls-tiny-gd-le-ilp32.d: Likewise.
+
+2023-03-16 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: add aarch64nto to ld-aarch64
+ ld/ChangeLog:
+
+ * testsuite/ld-aarch64/aarch64-elf.exp: Add support for
+ aarch64nto.
+
+2023-03-16 Clément Chigot <chigot@adacore.com>
+
+ ld: add support of QNX stack arguments for aarch64nto
+ QNX is handling the stack argument using a .note section. Generate it
+ according to ELF argument -zexecstack, -zstack-size and a new NTO
+ argument --lazy-stack. Another NTO argument --stack mimicking
+ -zstack-size is added in order to ensure compatibility with previously
+ made NTO linkers.
+ This requires a new emultempl nto.em which is applied above the default
+ ${ARCH}elf.em.
+
+ ld/ChangeLog:
+
+ * emulparams/aarch64nto.sh: Move to nto.em.
+ * emultempl/nto.em: New file.
+ * testsuite/ld-aarch64/aarch64-nto.exp: New test.
+ * testsuite/ld-aarch64/nto-stack-note-1.d: New test.
+ * testsuite/ld-aarch64/nto-stack-note-2.d: New test.
+ * testsuite/ld-aarch64/start.s: New test.
+
+2023-03-16 Clément Chigot <chigot@adacore.com>
+
+ readelf: add support for QNT_STACK note subsections
+ QNX provides some .note subsections. QNT_STACK is the one controling
+ the stack allocation.
+
+ bfd/ChangeLog:
+
+ * elf.c (BFD_QNT_CORE_INFO): Delete.
+ (BFD_QNT_CORE_STATUS): Likewise.
+ (BFD_QNT_CORE_GREG): Likewise.
+ (BFD_QNT_CORE_FPREG): Likewise.
+ (elfcore_grok_nto_note): Replace BFD_QNT_* by QNT_*.
+
+ binutils/ChangeLog:
+
+ * readelf.c (get_qnx_elfcore_note_type): New function.
+ (print_qnx_note): New function.
+ (process_note): Add support for QNX support.
+
+ include/ChangeLog:
+
+ * elf/common.h (QNT_DEBUG_FULLPATH): New define.
+ (QNT_DEBUG_RELOC): New define.
+ (QNT_STACK): New define.
+ (QNT_GENERATOR): New define.
+ (QNT_DEFAULT_LIB): New define.
+ (QNT_CORE_SYSINFO): New define.
+ (QNT_CORE_INFO): New define.
+ (QNT_CORE_STATUS): New define.
+ (QNT_CORE_GREG): New define.
+ (QNT_CORE_FPREG): New define.
+ (QNT_LINK_MAP): New define.
+
+2023-03-16 Clément Chigot <chigot@adacore.com>
+
+ configure: add new target aarch64-*-nto*
+ This target has its own ld emulation based on aarch64elf.em.
+
+2023-03-16 Cupertino Miranda <cupertino.miranda@oracle.com>
+
+ BPF relocations review / refactoring
+ - Removed not needed relocations.
+ - Renamed relocations to match llvm and linux kernel.
+
+ Relocation changes:
+ R_BPF_INSN_64 => R_BPF_64_64
+ R_BPF_INSN_DISP32 => R_BPF_64_32
+ R_BPF_DATA_32 => R_BPF_64_ABS32
+ R_BPF_DATA_64 => R_BPF_64_ABS64
+
+ ChangeLog:
+
+ * bfd/bpf-reloc.def: Created file with BPF_HOWTO macro entries.
+ * bfd/reloc.c: Removed non needed relocations.
+ * bfd/bfd-in2.h: regenerated.
+ * bfd/libbfd.h: regenerated.
+ * bfd/elf64-bpf.c: Changed relocations.
+ * include/elf/bpf.h: Adapted relocation values/names.
+ * gas/config/tc-bpf.c: Changed relocation mapping.
+
+2023-03-16 Alan Modra <amodra@gmail.com>
+
+ Re: Add --enable-linker-verssion
+ Output sections without any input sections to initialise their flags
+ have their flags initialised by data statements to LOAD, ALLOC,
+ HAS_CONTENTS by default. This is wrong for .comment. Fix that by
+ making the script initialise the section type to INFO, one of the
+ noalloc section types. That also allows the address of .comment to be
+ set to zero, as is usual for non-alloc sections.
+
+ Also, use source_sh for all of the sourced scripts to set up make
+ dependencies.
+
+ PR 30187
+ * scripttempl/misc-sections.sc: Set .comment address to zero
+ and type to INFO.
+ * scripttempl/ft32.sc: Fix breakages from last edit.
+ * scripttempl/arclinux.sc: Use source_sh to source DWARF.sc
+ and misc-sections.sc.
+ * scripttempl/avr.sc: Likewise.
+ * scripttempl/dlx.sc: Likewise.
+ * scripttempl/elf.sc: Likewise.
+ * scripttempl/elf32cr16.sc: Likewise.
+ * scripttempl/elf32crx.sc: Likewise.
+ * scripttempl/elf32msp430.sc: Likewise.
+ * scripttempl/elf64bpf.sc: Likewise.
+ * scripttempl/elf64hppa.sc: Likewise.
+ * scripttempl/elf_chaos.sc: Likewise.
+ * scripttempl/elfarc.sc: Likewise.
+ * scripttempl/elfarcv2.sc: Likewise.
+ * scripttempl/elfd10v.sc: Likewise.
+ * scripttempl/elfd30v.sc: Likewise.
+ * scripttempl/elfm68hc11.sc: Likewise.
+ * scripttempl/elfm68hc12.sc: Likewise.
+ * scripttempl/elfm9s12z.sc: Likewise.
+ * scripttempl/elfmicroblaze.sc: Likewise.
+ * scripttempl/elfxgate.sc: Likewise.
+ * scripttempl/elfxtensa.sc: Likewise.
+ * scripttempl/epiphany_4x4.sc: Likewise.
+ * scripttempl/i386beos.sc: Likewise.
+ * scripttempl/i386go32.sc: Likewise.
+ * scripttempl/ia64vms.sc: Likewise.
+ * scripttempl/ip2k.sc: Likewise.
+ * scripttempl/iq2000.sc: Likewise.
+ * scripttempl/mep.sc: Likewise.
+ * scripttempl/mmo.sc: Likewise.
+ * scripttempl/nds32elf.sc: Likewise.
+ * scripttempl/pru.sc: Likewise.
+ * scripttempl/v850.sc: Likewise.
+ * scripttempl/v850_rh850.sc: Likewise.
+ * scripttempl/visium.sc: Likewise.
+ * scripttempl/xstormy16.sc: Likewise.
+ * scripttempl/z80.sc: Likewise.
+ * testsuite/ld-scripts/ld-version-2.d: Don't skip ft32 or pru.
+
+2023-03-16 Alan Modra <amodra@gmail.com>
+
+ cpu/mem.opc whitespace tidy
+ cpu/
+ * mep.opc: Whitespace and formatting.
+ opcodes/
+ * mep-asm.c: Regenerate.
+ * mep-dis.c: Regenerate.
+
+2023-03-16 Alan Modra <amodra@gmail.com>
+
+ PR30217, dynamic relocations using local dynamic symbols
+ glibc's ld.so ignores local dynamic symbols. It's been that way
+ forever. We therefore can't use them on dynamic relocations. Fixing
+ that problem uncovered another problem in sorting of dynamic relocs,
+ caused no doubt by copying make_iplt_section (where we don't want
+ reloc sorting by the generic gold function, we want iplt relocs last)
+ to make_lplt_section (where we do want sorting).
+
+ PR 30217
+ * powerpc.cc (branch_needs_plt_entry): New function.
+ (Target_powerpc::plt_off): Use it here..
+ (Target_powerpc::Scan::global): ..and here to correct PLT16 reloc
+ handling for forced-local global symbols.
+ (Output_data_plt_powerpc::add_entry): Rename "stash"
+ parameter "is_local". Emit relative relocs for globals that
+ are forced local, and don't set_needs_dynsym_entry.
+ (Target_powerpc::make_lplt_section): Don't create a separate
+ reloc section, use rela_dyn.
+ (Target_powerpc::make_brlt_section): Likewise.
+
+2023-03-16 Alan Modra <amodra@gmail.com>
+
+ Re: Sanity check read_section_stabs_debugging_info
+ * rddbg.c (read_section_stabs_debugging_info): Don't segfault on
+ zero size string section.
+
+2023-03-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-15 Tom Tromey <tromey@adacore.com>
+
+ Fix formatting in gdb/printing.py
+ According to black 23, gdb/printing.py was mis-formatted. This patch
+ fixes it.
+
+2023-03-15 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Enable vector register visibility in core for AIX.
+ This patch enables AIX folks to see vector register contents while they
+ analyse the core file.
+
+2023-03-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix re-used exec in gdb.arch/ftrace-insn-reloc.exp
+ In test-case gdb.arch/ftrace-insn-reloc.exp we generate two executables with
+ the same name, which is confusing and known to cause trouble.
+
+ Fix this by making the executable names unique.
+
+ Tested on x86_64-linux.
+
+2023-03-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/amd64-stap-special-operands.exp for remote host
+ With test-case gdb.arch/amd64-stap-special-operands.exp and host board
+ local-remote-host-notty and target board native-gdbserver I run into:
+ ...
+ (gdb) break -pstap three_arg^M
+ No probe matching objfile=`<any>', provider=`<any>', name=`three_arg'^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.arch/amd64-stap-special-operands.exp: probe: three_arg: \
+ gdb_breakpoint: set breakpoint at -pstap three_arg
+ ...
+ due to compiling two executables with the same name, and when uploading the
+ second one from host to build, we run into:
+ ...
+ Upload from 127.0.0.1 failed, \
+ $outputs/gdb.arch/amd64-stap-special-operands/amd64-stap-special-operands: \
+ Text file busy.
+ ...
+
+ Fix this by making the executable names unique.
+
+ Tested on x86_64-linux.
+
+2023-03-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/i386-pkru.exp for native-gdbserver
+ With test-case gdb.arch/i386-pkru.exp and target board native-gdbserver we run
+ into:
+ ...
+ FAIL: gdb.arch/i386-pkru.exp: variable after reading pkru
+ ...
+
+ This looks similar to the the problem for which there's already an xfail, so
+ fix this by extending the xfail matching.
+
+ Tested on x86_64-linux.
+
+ Also tested on openSUSE Tumbleweed, where all tests in the test-case pass.
+
+2023-03-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Unset DEBUGINFOD_URLS on remote host
+ When running test-case gdb.arch/i386-pkru.exp with host board
+ local-remote-host-notty and target board native-gdbserver on openSUSE
+ Tumbleweed (with DEBUGINFOD_URLS set), I run into:
+ ...
+ This GDB supports auto-downloading debuginfo from the following URLs:^M
+ <https://debuginfod.opensuse.org/>^M
+ Enable debuginfod for this session? (y or [n]) ^CQuit^M
+ (gdb) FAIL: gdb.arch/i386-pkru.exp: runto: run to main
+ ...
+
+ The problem is that the unsetenv for DEBUGINFOD_URLS in default_gdb_init:
+ ...
+ # If DEBUGINFOD_URLS is set, gdb will try to download sources and
+ # debug info for f.i. system libraries. Prevent this.
+ unset -nocomplain ::env(DEBUGINFOD_URLS)
+ ...
+ doesn't work on remote host.
+
+ Fix this by using "set debuginfod enabled off" for remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/amd64*.exp with local-remote-host-native.exp
+ There's a number of gdb.arch/amd64*.exp test-cases that fail with host+target
+ board local-remote-host-native.exp because of using a .S file, generated from
+ a .c file.
+
+ If a test-case compiles the .S file when executing on remote host,
+ the .S file is already copied from build to host, such that it's available for
+ the compiler.
+
+ But that's not the case for the .c file, which is needed by gdb to show a
+ source line:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, fn2 (y=y@entry=25, x=x@entry=6) at amd64-entry-value-inline.c:32^M
+ 32 in gdb.arch/amd64-entry-value-inline.c^M
+ (gdb) FAIL: gdb.arch/amd64-entry-value-inline.exp: continue to breakpoint: \
+ break-here
+ ...
+
+ Fix this by using "gdb_remote_download host <.c file>".
+
+ Tested on x86_64-linux, with host+target board local-remote-host-native.
+
+2023-03-15 Nick Clifton <nickc@redhat.com>
+
+ Add --enable-linker-version option to bfd linker to add an entry in the .comment section.
+ PR 30187
+ * NEWS: Mention the new feature. * ld.texi: Document the new feature. * ldgram.y: Handle LINKER_VERSION token. * ldlang.c (lang_add_version): New function. (enable_linker_version): New global variable. * ldlang.h (land_add_version): Prototype. (enable_linker_version): Export. * ldlex.h (OPTION_ENABLE_LINKER_VERSION): Define. (OPTION_DISABLE_LINKER_VERSION): Define. * ldlex.l (LINKER_VERSION): Add token. * lexsup.c (ld_options): Add --enable-linker-version and --disable-linker-version. (parse_args): Handle the new options. * scripttempl/arclinux.sc: Remove stabs and comment sections and replace with inclusion of misc-sections.sc * scripttempl/avr.sc: Likewise. * scripttempl/dlx.sc: Likewise. * scripttempl/elf.sc: Likewise. * scripttempl/elf32cr16.sc: Likewise. * scripttempl/elf32crx.sc: Likewise. * scripttempl/elf32msp430.sc: Likewise. * scripttempl/elf64bpf.sc: Likewise. * scripttempl/elf64hppa.sc: Likewise. * scripttempl/elf_chaos.sc: Likewise. * scripttempl/elfarc.sc: Likewise. * scripttempl/elfarcv2.sc: Likewise. * scripttempl/elfd10v.sc: Likewise. * scripttempl/elfd30v.sc: Likewise. * scripttempl/elfm68hc11.sc: Likewise. * scripttempl/elfm68hc12.sc: Likewise. * scripttempl/elfm9s12z.sc: Likewise. * scripttempl/elfmicroblaze.sc: Likewise. * scripttempl/elfxgate.sc: Likewise. * scripttempl/elfxtensa.sc: Likewise. * scripttempl/epiphany_4x4.sc: Likewise. * scripttempl/ft32.sc: Likewise. * scripttempl/ip2k.sc: Likewise. * scripttempl/iq2000.sc: Likewise. * scripttempl/mep.sc: Likewise. * scripttempl/nds32elf.sc: Likewise. * scripttempl/pru.sc: Likewise. * scripttempl/v850.sc: Likewise. * scripttempl/v850_rh850.sc: Likewise. * scripttempl/visium.sc: Likewise. * scripttempl/xstormy16.sc: Likewise. * scripttempl/z80.sc: Likewise. * testsuite/ld-scripts/script.exp: Run new tests. * scripttempl/misc-sections.sc: New file. * testsuite/ld-scripts/ld-version-2.d: New file. * testsuite/ld-scripts/ld-version.d: New file. * testsuite/ld-scripts/ld-version.t: New file.
+
+ Fix an illegal memory access when disassembling a corrupt MeP file.
+ PR 30231
+ * mep.opc (mep_print_insn): Check for an out of range index.
+
+ Fix an illegal memory access when disassebling a corrupt ARM file.
+ PR 30230
+ * arm-dis.c (get_sym_code_type): Check for non-ELF symbols.
+
+2023-03-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Implement DAP variables, scopes, and evaluate requests
+ The DAP code already claimed to implement "scopes" and "evaluate", but
+ this wasn't done completely correctly. This patch implements these
+ and also implements the "variables" request.
+
+ After this patch, variables and scopes correctly report their
+ sub-structure. This also interfaces with the gdb pretty-printer API,
+ so the output of pretty-printers is available.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Hide the implementation of gdb_mpf
+ This renames the data member of gdb_mpf and makes it private. It also
+ adds a single new method to aid in this change. Unlike the earlier
+ changes here, I did this one all together because gdb_mpf has very few
+ uses.
+
+ Rename gdb_mpq::val and make contents private
+ This changes gdb_mpq to hide its data, and renames the data member
+ from 'val' to 'm_val', following gdb convention.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Add operators and methods to gdb_mpq
+ This adds some operators and methods to gdb_mpq, in preparation for
+ making its implementation private.
+
+ This only adds the operators currently needed by gdb. More could be
+ added as necessary.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Rename gdb_mpz::val and make contents private
+ This changes gdb_mpz to hide its data, and renames the data member
+ from 'val' to 'm_val', following gdb convention.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Add methods and operators to gdb_mpz
+ This adds various methods and operators to gdb_mpz, as a step toward
+ hiding the implementation.
+
+ This only adds the operators that were needed. Many more could be
+ added as required.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Clean up gmp-utils.h includes
+ gmp-utils.h includes "defs.h", but normally the rule in gdb is that
+ the .c files include this first. This patch changes this code to
+ match the rest of gdb.
+
+2023-03-14 Tom Tromey <tromey@adacore.com>
+
+ Fix DAP frame bug with older versions of Python
+ Tom de Vries pointed out that one DAP test failed on Python 3.6
+ because gdb.Frame is not hashable.
+
+ This patch fixes the problem by using a list to hold the frames. This
+ is less efficient but there normally won't be that many frames.
+
+ Tested-by: Tom de Vries <tdevries@suse.de>
+
+2023-03-14 Nick Clifton <nickc@redhat.com>
+
+ Prevent an over large memory allocation in readelf when parsing a corrupt DWARF file.
+ PR 30227
+ * dwarf.c (process_cu_tu_index): Prevent excessive memory allocation when nused is large and ncols is zero.
+
+2023-03-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.testsuite/board-sanity.exp
+ Add a test-case that tests the sanity of target/host boards.
+
+ It contains a number of tests related to remote file manipulation, exercising:
+ - remote_upload
+ - remote_download
+ - remote_file exists
+ - remote_file delete
+ which check that these work together as expected.
+
+ Tested on x86_64-linux, with all relevant gdb/testsuite/boards/*.exp boards.
+
+ For target board remote-stdio-gdbserver.exp, this revealed a trivial problem
+ with the return value of proc ${board}_file for delete, so fix this.
+
+ The test-case shows that the proc ${board}_download in
+ local-remote-host-native.exp is broken, so remove it.
+
+ Likewise for board local-remote-host.exp, so remove proc ${board}_download and
+ associated ${board}_file.
+
+ Tested on x86_64-linux.
+
+2023-03-14 Nick Clifton <nickc@redhat.com>
+
+ Adjust the decoded line output to fit into 80 columns.
+ PR 30216
+ * dwarf.c (display_debug_lines_decoded): Reduce space for filenames.
+ * testsuite/binutils-all/dw5.W: Adjust expected output.
+ * testsuite/binutils-all/objdump.WL: Adjust expected output.
+
+ Fix assembler documentation regarding data directives.
+ PR 30206
+ * doc/as.texi (Pseudo Ops): Document that data directives such as .byte and .int are not intended for encoding instructions.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ objdump segfault after symbol table error
+ This memcpy segfaults if symcount is -1 (=> syms is NULL).
+ memcpy (sorted_syms, symcount ? syms : dynsyms,
+ sorted_symcount * sizeof (asymbol *));
+
+ * objdump.c (slurp_symtab): Don't leave symcount as -1 after
+ an error.
+ (slurp_dynamic_symtab): Likewise for dynsymcount.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ Sanity check read_section_stabs_debugging_info
+ * rddbg.c (read_section_stabs_debugging_info): Exclude sections
+ without contents. Use bfd_malloc_and_get_section. Don't alloc
+ one extra for strings.
+
+ gas/read.c: init more statics
+ * read.c (current_name, current_label, dwarf_file, dwarf_line): Move
+ to file scope.
+ (pobegin): Tidy pop_override_ok.
+ (read_a_source_file): Make last_eol an auto var.
+ (s_reloc): Constify bfd_relocs.
+ (read_begin): Init more variables.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ gas .include and .incbin
+ This fixes a bug in .include and .incbin where given an absolute path
+ the -I dirs would be searched for the path.
+
+ * read.c (include_dir_count, include_dir_maxlen): Make them size_t.
+ (search_and_open): New function.
+ (s_incbin, s_include): Use search_and_open.
+ (init_include_dir): New function.
+ (add_include_dir): Don't set initial "." dir here.
+ * read.h (include_dir_count, include_dir_maxlen): Update.
+ (init_include_dir, search_and_open): Declare.
+ * as.c (gas_early_init): Call init_include_dir.
+ * config/tc-rx.c (rx_include): Avoid warning by using size_t.
+ * config/tc-tic54x.c (tic54x_set_default_include): Simplify and
+ use notes for include path.
+ (tic54x_mlib): Use search_and_open.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ gas/dwarf2dbg.c init more statics
+ * dwarf2dbg.c (dw2_line, dw2_filename): Move to file scope and..
+ (dwarf2_gen_line_info): ..renamed from here.
+ (label_num, last_used, last_used_dir_len): Move to file scope.
+ (dwarf2_init): Init moved statics, except last_used_dir_len.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ gas/ecoff.c: don't use zero struct copies to init
+ It might have made sense once upon a time, but doesn't nowadays when
+ compilers expand memset inline.
+
+ * ecoff.c (add_aux_sym_tir, allocate_scope, allocate_vlinks),
+ (allocate_shash, allocate_thash, allocate_tag, allocate_forward),
+ (allocate_thead, allocate_lineno_list): Use memset rather than
+ copying zero struct.
+
+2023-03-14 Alan Modra <amodra@gmail.com>
+
+ gas/compress-debug.c init all of strm
+ * compress-debug.c (compress_init): Clear all of strm.
+
+2023-03-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add gdbarch::displaced_step_buffer_length
+ The gdbarch::max_insn_length field is used mostly to support displaced
+ stepping; it controls the size of the buffers allocated for the
+ displaced-step instruction, and is also used when first copying the
+ instruction, and later, when fixing up the instruction, in order to
+ read in and parse the instruction being stepped.
+
+ However, it has started to be used in other places in GDB, for
+ example, it's used in the Python disassembler API, and it is used on
+ amd64 as part of branch-tracing instruction classification.
+
+ The problem is that the value assigned to max_insn_length is not
+ always the maximum instruction length, but sometimes is a multiple of
+ that length, as required to support displaced stepping, see rs600,
+ ARM, and AArch64 for examples of this.
+
+ It seems to me that we are overloading the meaning of the
+ max_insn_length field, and I think that could potentially lead to
+ confusion.
+
+ I propose that we add a new gdbarch field,
+ gdbarch::displaced_step_buffer_length, this new field will do
+ exactly what it says on the tin; represent the required displaced step
+ buffer size. The max_insn_length field can then do exactly what it
+ claims to do; represent the maximum length of a single instruction.
+
+ As some architectures (e.g. i386, and amd64) only require their
+ displaced step buffers to be a single instruction in size, I propose
+ that the default for displaced_step_buffer_length will be the
+ value of max_insn_length. Architectures than need more buffer space
+ can then override this default as needed.
+
+ I've updated all architectures to setup the new field if appropriate,
+ and I've audited all calls to gdbarch_max_insn_length and switched to
+ gdbarch_displaced_step_buffer_length where appropriate.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdbarch: make invalid=True the default for all Components
+ This commit switches the default value for the 'invalid' field from
+ False to True. All components that previous set the invalid field to
+ True explicitly have had the field removed.
+
+ I think that True is a good choice for the default, this means that we
+ now get the validity checks by default, and if anyone adds a new
+ Component they need to make a choice to add an 'invalid=False' line
+ and disable the validation.
+
+ The flip side of this is that 'invalid=False' seems to be far more
+ common than 'invalid=True'. But I don't see a huge problem with this,
+ we shouldn't be aiming to reduce our typing, rather we should choose
+ based on which is least likely to introduce bugs. I think assuming
+ that we should do a validity check will achieve that.
+
+ Some additional components need to have an 'invalid=False' line added
+ to their definition, these are components that have a predefault
+ value, which is sufficient; the tdep code doesn't need to replace this
+ value if it doesn't want to.
+
+ Without adding the 'invalid=False' these components would be
+ considered to be invalid if they have not changed from their
+ predefault value -- but the predefault is fine.
+
+ There's no change in the generated code after this commit, so there
+ will be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdbarch: remove some unneeded predefault="0" from gdbarch_components.py
+ I noticed that there are a bunch of 'predefault="0"' lines in
+ gdbarch_components.py, and that some (just some, not all) of these are
+ not needed.
+
+ The gdbarch is already zero initialized, but these lines seem to
+ exists so that we can know when to compare against "0" and when to
+ compare against "NULL". At least, this seems to be useful in some
+ places in the generated code.
+
+ Specifically, if we remove the predefault="0" line from the
+ max_insn_length component then we end up generating a line like:
+
+ gdb_assert (gdbarch->max_insn_length != NULL);
+
+ which doesn't compile as we compare a ULONGEST to NULL.
+
+ In this commit I remove all the predefault="0" lines that I claim are
+ obviously not needed. These are lines for components that are not
+ Values (i.e. the component holds a function pointer anyway), or for
+ Value components that hold a pointer type, in which case using NULL is
+ fine.
+
+ The only changes after this commit are some fields that have nullptr
+ as their initial value, and gcore_bfd_target now compares to NULL not
+ 0 in gdbarch_gcore_bfd_target_p, which, given the field is of type
+ 'const char *', seems like an improvement.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdbarch: improve generation of validation in gdbarch getters
+ We currently generate some validation code within the gdbarch getter
+ methods.
+
+ This commit adjusts the algorithm used to generate this validation
+ slightly to make the gdbarch.py code (I think) clearer; there's no
+ significant changes to what is generated.
+
+ The validation algorithm for gdbarch values is now:
+
+ - If the Value has an 'invalid' field that is a string, use that for
+ validation,
+
+ - If the Value has its 'predicate' field set to true, then check the
+ predicate returns true, this ensures the predicate has been
+ called,
+
+ - If the Value has its 'invalid' field set to True, or the Value has
+ 'postdefault' field, then check the fields has changed from its
+ initial value,
+
+ - Otherwise no validation is performed.
+
+ The only changes after this commit are:
+
+ - Some comments change slightly, and
+
+ - For 'gcore_bfd_target' and 'max_insn_length' we now validate by
+ calling the predicate rather than checking the field value
+ directly, the underlying check being performed is unchanged
+ though.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdbarch: use predefault for more value components within gdbarch
+ For some reason the following value components of gdbarch:
+
+ bfloat16_format
+ half_format
+ float_format
+ double_format
+ long_double_format
+ so_ops
+
+ All use a postdefault but no predefault to set the default value for
+ the component.
+
+ As the postdefault values for these components are all constant
+ pointers that don't depend on other fields within the gdbarch, then I
+ don't see any reason why we couldn't use a predefault instead.
+
+ So lets do that.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py
+ This commit ensures that the 'invalid' property of all components is
+ either True, False, or a string.
+
+ Additionally, this commit allows a component to have both a predicate
+ and for the 'invalid' property to be a string.
+
+ Removing the option for 'invalid' to be None allows us to simplify the
+ algorithms in gdbarch.py a little.
+
+ Allowing a component to have both a predicate and an 'invalid' string
+ means that we can validate the value that a tdep sets into a field,
+ but also allow a predicate to ensure that the field has changed from
+ the default.
+
+ This functionality isn't going to be used in this series, but I have
+ tested it locally and believe that it would work, and this might make
+ it easier for others to add new components in the future.
+
+ In gdbarch_types.py, I've updated the type annotations to show that
+ the 'invalid' field should not be None, and I've changed the default
+ for this field from None to False.
+
+ The change to using False as the default is temporary. Later in this
+ series I'm going to change the default to True, but we need more fixes
+ before that can be done.
+
+ Additionally, in gdbarch_types.py I've removed an assert from
+ Component.get_predicate. This assert ensured that we didn't have the
+ predicate field set to True and the invalid field set to a string.
+ However, no component currently uses this configuration, and after
+ this commit, that combination is now supported, so the assert can be
+ removed.
+
+ As a consequence of the gdbarch_types.py changes we see some
+ additional comments generated in gdbarch.c about verification being
+ skipped due to the invalid field being False. This comment is inline
+ with plenty of other getters that also have a similar comment. Plenty
+ of the getters do have validation, so I think it is reasonable to have
+ a comment noting that the validation has been skipped for a specific
+ reason, rather than due to some bug.
+
+ In gdbarch_components.py I've had to add 'invalid=True' for two
+ components: gcore_bfd_target and max_insn_length, without this the
+ validation in the gdbarch getter would disappear.
+
+ And in gdbarch.py I've reworked the logic for generating the
+ verify_gdbarch function, and for generating the getter functions.
+
+ The logic for generating the getter functions is still not ideal, I
+ ended up having to add this additional logic block:
+
+ elif c.postdefault is not None and c.predefault is not None:
+ print(" /* Check variable changed from pre-default. */", file=f)
+ print(f" gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f)
+
+ which was needed to ensure we continued to generate the same code as
+ before, without this the fact that invalid is now False when it would
+ previously have been None, meant that we dropped the gdb_assert in
+ favour of a comment like:
+
+ print(f" /* Skip verify of {c.name}, invalid_p == 0 */", file=f)
+
+ which is clearly not a good change. We could potentially look at
+ improving this in a later commit, but I don't plan to do that in this
+ series.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: split postdefault setup from invalid check in gdbarch.py
+ Restructure how gdbarch.py generates the verify_gdbarch function.
+ Previously the postdefault handling was bundled together with the
+ validation. This means that a field can't have both a postdefault,
+ and set its invalid attribute to a string.
+
+ This doesn't seem reasonable to me, I see no reason why a field can't
+ have both a postdefault (used when the tdep doesn't set the field),
+ and an invalid expression, which can be used to validate the value
+ that a tdep might set.
+
+ In this commit I restructure the verify_gdbarch generation code to
+ allow the above, there is no change in the actual generated code in
+ this commit, that will come in later commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: remove yet more 'invalid=True' from gdbarch_components.py
+ Following on from the previous commit, this commit removes yet more
+ 'invalid=True' lines from gdbarch_components.py where the invalid
+ setting has no effect.
+
+ Due to the algorithm used in gdbarch.py for generated verify_gdbarch,
+ if a component has a postdefault value then no invalid check will ever
+ be generated for the component, as such setting 'invalid=True' on the
+ component is pointless. This commit removes the setting of invalid.
+
+ There is no change in the generated code after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: remove unused 'invalid=True' from gdbarch_components.py
+ Due to the algorithm used to generate verify_gdbarch in gdbarch.py, if
+ a component has a predicate, then a validation check will never be
+ generated.
+
+ There are a bunch of components that are declared with both a
+ predicate AND have 'invalid=True' set. The 'invalid=True' has no
+ effect.
+
+ In this commit I clean things up by removing all these additional
+ 'invalid=True' lines. There's no change in any of the generated files
+ after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-13 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in inside_main_func
+ gdb 13.1 crashes while running the rust compiler's debugger tests.
+ The crash has a number of causes.
+
+ First, the rust compiler still uses the C++-like _Z mangling, but with
+ its own twist -- some hex digits added to the end of a symbol. So,
+ while gdb finds the correct name of "main":
+
+ (top-gdb) p name
+ $13 = 0x292e0c0 "rustc_gdb_1031745::main"
+
+ It isn't found in the minsyms, because C++ demangling yields:
+
+ [99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v
+
+ This could perhaps be fixed. I also filed a new PR to suggest
+ preferring the linkage name of the main program.
+
+ Next, the rust compiler emits both a DW_TAG_subprogram and a
+ DW_TAG_namespace for "main". This happens because the file is named
+ "main.rs" -- i.e., the bug is specific to the source file name. The
+ crash also seems to require the nested function inside of 'main', at
+ least for me. The namespace always is generated, but perhaps this
+ changes the ordering in the DWARF.
+
+ When inside_main_func looks up the main symbol, it finds the namespace
+ symbol rather than the function. (I filed a bug about fixing gdb's
+ symbol tables -- long overdue.)
+
+ Meanwhile, as I think it's important to fix this crash sooner rather
+ than later, this patch changes inside_main_func to check that the
+ symbol that is found is LOC_BLOCK. This perhaps should have been done
+ in the first place, anyway.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30158
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/tui-window-factory.exp for remote host
+ When running gdb.python/tui-window.exp with host board
+ local-remote-host-notty and target board native-gdbserver, I get:
+ ...
+ FAIL: gdb.python/tui-window-factory.exp: msg_2: \
+ check test_window box (box check: ul corner is l, not +)
+ ...
+
+ The problem is that the result of Term::prepare_for_tui is not checked.
+
+ Fix this by adding the missing check.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/tui-window.exp for remote host
+ When running gdb.python/tui-window.exp with host board
+ local-remote-host-notty and target board native-gdbserver, I get:
+ ...
+ UNSUPPORTED: gdb.python/tui-window.exp: TUI not supported
+ FAIL: gdb.python/tui-window.exp: test title
+ ...
+
+ Fix this by adding the missing return after the unsupported.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/completion.exp for local-remote-host-notty
+ When running test-case gdb.tui/completion.exp with host board
+ local-remote-host-notty and target board native-gdbserver, I get:
+ ...
+ FAIL: gdb.tui/completion.exp: completion of layout names: \
+ tab completion (timeout)
+ ...
+
+ The test-case contains a few tests that do tab completion, which requires
+ readline, which is unavailable with host board local-remote-host-notty.
+
+ Fix this by adding the missing check for readline_is_used.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/tui-layout.exp for remote host
+ When running test-case gdb.tui/tui-layout.exp with host board
+ local-remote-host-notty and target board native-gdbserver, I get:
+ ...
+ FAIL: gdb.tui/tui-layout.exp: terminal=dumb: execution=false: layout=asm: \
+ layout asm (timeout)
+ ...
+
+ The problem is that the test-case expects that the default "setenv TERM dumb"
+ has effect, which is not the case for remote host.
+
+ Fix this by skipping the test for remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/tui-nl-filtered-output.exp for remote host
+ When running test-case gdb.tui/tui-nl-filtered-output.exp with host board
+ local-remote-host-notty and target board native-gdbserver, I get:
+ ...
+ FAIL: gdb.tui/tui-nl-filtered-output.exp: check printf output
+ ...
+
+ The problem is that Term::enter_tui is returning 0, but the test-case doesn't
+ check for this, and consequently runs unsupported tests.
+
+ Fix this by adding the missing check.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require ![is_remote host] for TUI
+ When running test-case gdb.tui/corefile-run.exp with both host and target board
+ local-remote-host-native.exp, we run into:
+ ...
+ FAIL: gdb.tui/corefile-run.exp: load corefile
+ ...
+ while this passes with USE_TUI=0.
+
+ The problem is that the TUI setup code uses "setenv TERM ansi", which has no
+ effect on remote host.
+
+ I can confirm this analysis by working around this problem in
+ local-remote-host-native.exp like this:
+ ...
+ - spawn $RSH -t -l $username $remote $cmd
+ + spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
+ ...
+
+ For now, simply make TUI unsupported for remote host, by returning 0 in
+ prepare_for_tui.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle USE_TUI in gdb.tui/corefile-run.exp
+ Once in a while I find myself rewriting a TUI test-case into a non-TUI
+ test-case, to better understand whether the problem I'm looking at is
+ related to the TUI or not.
+
+ I've got the impression that I've done this sufficiently often that it's worth
+ committing the non-TUI version, so having just written a non-TUI version of
+ gdb.tui/corefile-run.exp, let's commit it.
+
+ The non-TUI version can be enabled by doing:
+ ...
+ $ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0"
+ ...
+
+ Also remove hard-coding of a source line number.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix untested message in gdb.tui/corefile-run.exp
+ In test-case gdb.tui/corefile-run.exp, we have this bit:
+ ...
+ require !use_gdb_stub
+ if { [target_info gdb_protocol] == "extended-remote" } {
+ untested "not supported"
+ return
+ }
+ ...
+
+ So with target board native-gdbserver we get:
+ ...
+ UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
+ ...
+ and with target board native-extended-gdbserver instead:
+ ...
+ UNTESTED: gdb.tui/corefile-run.exp: not supported
+ ...
+
+ Fix this by:
+ - adding an optional argument target_description to proc
+ target_can_use_run_cmd
+ - handling the target_description == core &&
+ [target_info gdb_protocol] == "extended-remote" case in the proc
+ - using require {target_can_use_run_cmd core}
+ such that now in both cases we have:
+ ...
+ UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
+ target_can_use_run_cmd core
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/step-bg-decr-pc-switch-thread.exp for native-gdbserver
+ With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board
+ native-gdbserver, I run into:
+ ...
+ (gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \
+ switch to main thread
+ Remote debugging from host ::1, port 43914^M
+ monitor exit^M
+ Cannot execute this command while the target is running.^M
+ Use the "interrupt" command to stop the target^M
+ and then try again.^M
+ (gdb) WARNING: Timed out waiting for EOF in server after monitor exit
+ ...
+
+ Fix this by following the advice and issuing an interrupt command, allowing
+ the following monitor exit command to succeed.
+
+ Tested on x86_64-linux.
+
+2023-03-13 Bruno Larsen <blarsen@redhat.com>
+
+ [gdb/obvious]: fix python formatting for test gdb.python/py-typeprint.py
+ python black formatter was complaining about the formatting of
+ gdb.python/py-typeprint.py, so this commit corrects it.
+
+2023-03-13 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: add regression test for per-objfile typeprinters
+ PR python/17136 reported an unhandled exception when using typeprinters
+ only valid on some objfiles, rather than being a global typeprinter. The
+ fix was accepted without a regression test, and we've been carrying one
+ out-of-tree for a while but I think it's worth upstreaming. The code
+ itself was developed by Jan Kratochvil.
+
+ Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-03-13 Tom Tromey <tromey@adacore.com>
+
+ Remove dead code from scalar_binop
+ scalar_binop has code for "&&" and "||", but I think this code can't
+ currently be run -- and, furthermore, it doesn't make sense to have
+ this code here, as the point of these operators is to short-circuit
+ evaluation.
+
+ This patch removes the dead code.
+
+ Regression tested on x86-64 Fedora 36.
+
+ Approved-by: Kevin Buettner <kevinb@redhat.com>
+
+2023-03-13 Luis Machado <luis.machado@arm.com>
+
+ aarch64: Expand documentation of XML features
+ Similar to the arm target documentation situation, the documentation of the
+ XML features for AArch64 targets is rather brief. I have received the same
+ feedback that what gdb carries in the documentation is quite unclear from the
+ perspective of what debugging servers should define in the XML features, how and
+ what the outcome is in gdb.
+
+ This patch attempts to clarify a bit more what all the possible features are.
+
+2023-03-13 Luis Machado <luis.machado@arm.com>
+
+ arm: Expand documentation of XML features
+ The documentation of the XML features for Arm targets is very brief. I have
+ received feedback saying it is quite unclear from the perspective of the
+ debugging servers what should be defined in the XML features, how and
+ what the outcome is in gdb.
+
+ This patch attempts to clarify a bit more what all the possible features are.
+
+2023-03-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix the Dwarf reader
+ gprofng/ChangeLog
+ 2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng/src/DwarfLib.cc (DwrLineRegs::getPath): Add a DW_AT_comp_dir
+ string if the directoty table has relative names.
+
+2023-03-11 Tom Tromey <tom@tromey.com>
+
+ Change linetable_entry::is_stmt to bool
+ This changes linetable_entry::is_stmt to type bool, rather than
+ unsigned.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-11 Tom Tromey <tom@tromey.com>
+
+ Remove extra scopes from objfile_relocate1
+ objfile_relocate1 introduces new scopes that aren't necessary. I
+ noticed this while working on an earlier patch in this series. This
+ patch removes these.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-11 Tom Tromey <tom@tromey.com>
+
+ Constify linetables
+ Linetables no longer change after they are created. This patch
+ applies const to them.
+
+ Note there is one hack to cast away const in mdebugread.c. This code
+ allocates a linetable using 'malloc', then later copies it to the
+ obstack. While this could be cleaned up, I chose not to do so because
+ I have no way of testing it.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-11 Tom Tromey <tom@tromey.com>
+
+ Change linetables to be objfile-independent
+ This changes linetables to not add the text offset to the addresses
+ they contain. I did this in a few steps, necessarily combined
+ together in one patch: I renamed the 'pc' member to 'm_pc', added the
+ appropriate accessors, and then recompiled. Then I fixed all the
+ errors. Where possible I generally chose to use the raw_pc accessor,
+ as it is less expensive.
+
+ Note that this patch discounts the possibility that the text section
+ offset might cause wraparound in the addresses in the line table.
+ However, this was already discounted -- in particular,
+ objfile_relocate1 did not re-sort the table in this scenario. (There
+ was a bug open about this, but as far as I can tell this has never
+ happened, it's not even clear what inspired that bug.)
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-11 Tom Tromey <tom@tromey.com>
+
+ Add operator< and operator== to linetable_entry
+ This adds a couple of comparison operators to linetable_entry, and
+ simplifies both the calls to sort and one other spot that checks for
+ equality.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR30195 [display text] Source code location can not be found
+ gprofng/ChangeLog
+ 2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30195
+ gprofng/src/DwarfLib.cc (DwrLineRegs::reset): Set 'file = 1;'.
+
+2023-03-10 John Baldwin <jhb@FreeBSD.org>
+
+ PR gdb/30214: Prefer local include paths to system include paths
+ Some systems may install binutils headers into a system location
+ (e.g. /usr/local/include on FreeBSD) which may also include headers
+ for other external packages used by GDB such as zlib or zstd. If a
+ system include path such as /usr/local/include is added before local
+ include paths to directories within a clone or release tarball, then
+ headers from the external binutils package are used which can result
+ in build failures if the external binutils package is out of sync with
+ the version of GDB being built.
+
+ To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
+ for "local" componenets before external components.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-10 Fangrui Song <maskray@google.com>
+
+ ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)
+ Similar to d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274 for x86_64.
+
+ _Thread_local int a;
+ int main() { return a; }
+
+ % gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
+ /usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
+ /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
+ collect2: error: ld returned 1 exit status
+
+ This commit fixes the issue.
+
+ There is an argument that the -fno-plt TLS sequence was added after
+ R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
+ intended to be unsupported.
+
+ Unfortunately this standpoint has caused interop difficulty: some
+ projects specify -mrelax-relocations=no to build relocatable object
+ files compatible with older linkers (e.g.
+ https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
+ (e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
+ today). Many uses have not been cleaned up in practice, and compiling
+ with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
+ error which is hard to reason about.
+
+ It seems easier to apply this simple change to prevent the footgun.
+
+ PR ld/24784
+ * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.
+
+2023-03-10 Fangrui Song <maskray@google.com>
+
+ ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)
+ _Thread_local int a;
+ int main() { return a; }
+
+ % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
+ /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
+ /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
+ collect2: error: ld returned 1 exit status
+
+ This commit fixes the issue.
+
+ There is an argument that the -fno-plt TLS sequence was added after
+ R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
+ intended to be unsupported.
+
+ Unfortunately this standpoint has caused interop difficulty: some
+ projects specify -mrelax-relocations=no to build relocatable object
+ files compatible with older linkers (e.g.
+ https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
+ (e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
+ today). Many uses have not been cleaned up in practice, and compiling
+ with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
+ error which is hard to reason about.
+
+ There is another argument which may be weaker but relevant to the
+ necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
+ likely need some assembler support to disable relaxation. Without the
+ support and if the compiler needs to support many gas version, the
+ simplest solution would be to use -Wa,-mrelax-relocations=no.
+
+ PR ld/24784
+ * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
+ R_X86_64_GOTPCREL.
+
+2023-03-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-completion.exp
+ With test-case gdb.python/py-completion.exp and target board
+ native-extended-gdbserver I get this warning:
+ ...
+ (gdb) PASS: gdb.python/py-completion.exp: discard #2
+ completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
+ PASS: gdb.python/py-completion.exp: completefilecommandcond completion
+ Remote debugging from host ::1, port 53346^M
+ monitor exit^M
+ not implemented^M
+ (gdb) WARNING: Timed out waiting for EOF in server after monitor exit
+ ...
+
+ Fix this by adding the missing "discard #3", such that we have instead:
+ ...
+ (gdb) PASS: gdb.python/py-completion.exp: discard #2
+ completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
+ PASS: gdb.python/py-completion.exp: completefilecommandcond completion
+ ^M
+ not implemented^M
+ (gdb) PASS: gdb.python/py-completion.exp: discard #3
+ Remote debugging from host ::1, port 36278^M
+ monitor exit^M
+ (gdb)
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-cmd.exp
+ [ Using $pp as shorthand for the pagination prompt
+ "--Type <RET> for more, q to quit, c to continue without paging--". ]
+
+ The test-case gdb.python/py-cmd.exp passes, but the handling of the
+ test_multiline command output looks a bit odd:
+ ...
+ (gdb) test_multiline
+ test_multiline output
+ ...
+ test_multiline output
+ $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
+ q
+ test_multiline
+ Quit
+ (gdb) test_multiline
+ test_multiline output
+ ...
+ test_multiline output
+ $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
+ ...
+
+ What happens is:
+ - a test_multiline command is issued
+ - some output is printed, followed by a pagination prompt
+ - the test-case concludes that pagination occurred, and produces a PASS
+ - "q\n" is replied to the pagination prompt
+ - without waiting for response to the "q\n", another test_multiline command is
+ issued
+ - in response to the "q\n" we get "Quit\n(gdb) "
+ - some output is printed, followed by a pagination prompt
+ - the test-case concludes that there's a valid response to the "q\n", and
+ produces a PASS, consuming the second pagination prompt, but without a reply.
+
+ My conclusion is that the second test_multiline command is unintentional, so fix
+ this by removing it.
+
+ Without it, we have the more straightforward:
+ ...
+ (gdb) test_multiline
+ test_multiline output
+ ...
+ test_multiline output
+ $ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
+ q
+ Quit
+ (gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
+ ...
+
+ This also fixes the following warning with target board native-gdbserver:
+ ...
+ WARNING: Timed out waiting for EOF in server after monitor exit
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix py-autoloaded-pretty-printers-in-newobjfile-event.exp for remote target
+ With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp
+ and target board remote-gdbserver-on-localhost, I run into:
+ ...
+ FAIL: $exp: runto: run to main
+ ...
+
+ I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into:
+ ...
+ (gdb) print all_good^M
+ $1 = false^M
+ (gdb) FAIL: $exp: print all_good
+ info pretty-printer^M
+ ...
+
+ Sysroot is set to "target:", so gdb downloads the shared library from the target
+ (Using $so as shorthand for
+ libpy-autoloaded-pretty-printers-in-newobjfile-event.so):
+ ...
+ Reading /home/remote-target/$so from remote target...^M
+ ...
+ and internally refers to it as "target:/home/remote-target/$so".
+
+ In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts
+ for $so once it checks for is_target_filename.
+
+ Fix this by declaring auto-load unsupported if sysroot starts with "target:".
+
+ Tested on x86_64-linux.
+
+2023-03-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-event-load.exp for remote target
+ Fix test-case gdb.python/py-event-load.exp for target board
+ remote-gdbserver-on-localhost using gdb_download_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-10 Tom Tromey <tom@tromey.com>
+
+ Use require with test_compiler_info
+ One spot that checks test_compiler_info can be switched to use
+ 'require'.
+
+ More uses of require with istarget
+ I found a few more spots that check istarget that can be switched to
+ use 'require'.
+
+ Use require with gdb_skip_stdio_test
+ One use of gdb_skip_stdio_test can use 'require'.
+
+ Use require with target_info
+ This changes many tests to use 'require' when checking target_info.
+ In a few spots, the require is hoisted to the top of the file, to
+ avoid doing any extra work when the test is going to be skipped
+ anyway.
+
+2023-03-10 Tom Tromey <tromey@adacore.com>
+
+ Move allocate_stub_method to stabsread.c
+ allocate_stub_method is only called from stabsread.c, and I don't
+ think it will be needed anywhere else. So, move it and make it
+ static. Tested by rebuilding.
+
+2023-03-10 Alan Modra <amodra@gmail.com>
+
+ Revert ld ASCII support
+ Revert "Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant."
+ This reverts commit adbe951fc95943016325af08d677f18e8c177ac1.
+
+ Revert "ld test asciz and ascii fails"
+ This reverts the ascii.d part of commit 5f497256bee624f0fa470949aa41534093bc5b25.
+
+ Revert "Add support for the ASCII directive inside linker scripts."
+ This mostly reverts commit 9fe129a4105bb59398f73ce96938a94f19265b79
+ leaving the asciz.d and asciz.t changes in place.
+
+2023-03-10 Alan Modra <amodra@gmail.com>
+
+ Revert ld DIGEST support
+ This is a hopefully temporary reversion of new ld features for
+ embedded processors by Ulf Samuelsson, plus some followup patches.
+
+ Squashed together from the following:
+
+ Revert "lddigest 32-bit support and gcc-4 compile errors"
+ This reverts commit d7ee19be87110a8f5342cec6e323d83d01c641d1.
+
+ Revert "ld: Use correct types for crc64 calculations"
+ This reverts commit 9a534b9f8e3d0f3cdb5a20f19ff165693fbb84d2.
+
+ Revert "Re: DIGEST: testsuite"
+ This reverts commit c8e85484d8a0fe9f7b88e00a6b9ae63bcb53ba32.
+
+ Revert "Regen potfiles"
+ This reverts commit 4d98c966f8bf305ab25badd34cb295631873cf7c.
+
+ Revert "DIGEST: Makefile.*"
+ This reverts commit 78ef6ab03f56ce83a606d974bb8a9f34b5d6e0b7.
+
+ Revert "DIGEST: calculation"
+ This reverts commit 5243990191e683d5066d3dd622c76deaba0bf15c.
+
+ Revert "DIGEST: ldlang.*: add timestamp"
+ This reverts commit bd9466d4aa277a469a9d8b12f0a6e6fa51678e36.
+
+ Revert "DIGEST: ldmain.c"
+ This reverts commit c8f8653fa7eeb3dc0769ac23039eadb5c5f09dff.
+
+ Revert "DIGEST: ldgram.y"
+ This reverts commit d73c01be2669e9c5267fab669a269f95a32048c9.
+
+ Revert "DIGEST: ldlex.l"
+ This reverts commit 48b5163a9dd5759cc87171331bbd6e902c547b5a.
+
+ Revert "DIGEST: testsuite"
+ This reverts commit a4135d1a4886400ea29af2da782dd8dd40ccad23.
+
+ Revert "DIGEST: Documentation"
+ This reverts commit 3ec28966c3e4c63704212778f96c517cbf2e0090.
+
+ Revert "DIGEST: NEWS"
+ This reverts commit 099bf2927d446424e8585a60cf4ce63209999aa2.
+
+ Revert "DIGEST: LICENSING"
+ This reverts commit 5c8a0c6654fb55926985edf3b360b62d4f20691d.
+
+2023-03-10 Jan Beulich <jbeulich@suse.com>
+
+ Arm64/gas: drop redundant feature prereqs
+ Logic exists to deal with prereqs or prereqs, and in many cases
+ transitive prereqs are already not spelled out explicitly. Drop further
+ ones:
+ - FP is already a prereq to F16,
+ - SIMD and F16 are already prereqs to COMPNUM, and
+ - SVE2 and BFLOAT16 are already prereqs to SME.
+
+ Arm64/gas: add missing prereq features
+ A number of newer features are really SIMD or FP extensions, but don't
+ have this properly specified.
+
+ x86: decouple broadcast type and bytes fields
+ Keep both representing exclusively what was parsed from input, to avoid
+ the need for (potentially bogus) calculations when processing .insn.
+
+ x86-64: adjust REX-prefix part of SSE2AVX test
+ Before altering how build_modrm_byte() works, arrange for this part of
+ the testcase to actually use distinguishable source and destination
+ register numbers, such that incorrect propagation of, in particular, the
+ high bit encodings (from REX to VEX) can be noticed (in turn
+ specifically assertions [not] triggering in the respective code).
+
+2023-03-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: move more disp processing out of md_assemble()
+ Put it in optimize_disp() such that it can then be re-used by .insn
+ handling. The movement makes it necessary (or at least very desirable,
+ to avoid introducing a fragile cast) to convert to local variable to
+ "unsigned", which in turn requires an adjustment to the pre-existing
+ loop header.
+
+ Having the caller pass in the specific template under consideration has
+ another benefit then: We can replace the two uses of current_templates
+ in the function as well, thus no longer looking at some merely "related"
+ template. (This may allow further tightening, but if so that's to be the
+ subject of another change.)
+
+2023-03-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: use set_rex_vrex() also for short-form handling
+ This is benign for all existing insns, but is going to be needed for
+ handling of .insn operands. The earlier use requires moving up the
+ function, to avoid the need for a forward declaration.
+
+2023-03-10 Alan Modra <amodra@gmail.com>
+
+ eh static data
+ Fix another case of oss-fuzz tripping over gas static state,
+ ie. starting over testing another input file with rubbish left
+ uncleared in bss. size_end_sym pointed at garbage.
+
+ * ehopt.c (get_cie_info): Delete forward declaration.
+ (struct frame_data): Move to file scope.
+ (frame): New static, packaged..
+ (check_eh_frame): ..eh_frame_data and debug_frame_data.
+ (eh_begin): New function.
+ * as.c (gas_init): Call eh_begin.
+ * as.h (eh_begin): Declare.
+
+2023-03-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb, gdbserver, gdbsupport: fix whitespace issues
+ Replace spaces with tabs in a bunch of places.
+
+ Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/pending-fork-event-detach.exp for remote target
+ Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
+ remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.
+
+ Then, fix the test-case for target board remote-stdio-gdbserver with
+ REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
+ on target using remote_download, and using the resulting path.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Alan Modra <amodra@gmail.com>
+
+ objdump: report no section contents
+ objdump's read_section is never used for bss-style sections, so to
+ plug a hole that fuzzers have found, exclude sections without
+ SEC_HAS_CONTENTS.
+
+ * objdump.c (read_section): Report and return an error on
+ a no contents section.
+
+2023-03-09 Alan Modra <amodra@gmail.com>
+
+ gas: allow frag address wrapping in absolute section
+ This:
+ .struct -1
+ x:
+ .fill 1
+ y:
+ results in an internal error in frag_new due to abs_section_offset
+ wrapping from -1 to 0. Frags in the absolute section don't do much so
+ I think we can allow the address wrap.
+
+ * frags.c (frag_new): Allow address wrap in absolute section.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/multiple-successive-infcall.exp on native-gdbserver
+ With test-case gdb.threads/multiple-successive-infcall.exp and target board
+ native-gdbserver I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ [New Thread 758.759]^M
+ ^M
+ Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
+ multiple-successive-infcall.c:97^M
+ 97 thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
+ (gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
+ created new thread
+ ...
+
+ The problem is that the new thread message doesn't match the regexp, which
+ expects something like this instead:
+ ...
+ [New Thread 0x7ffff746e700 (LWP 570)]^M
+ ...
+
+ Fix this by accepting this form of new thread message.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
+ With test-case gdb.threads/thread-specific-bp.exp and target board
+ native-gdbserver I run into:
+ ...
+ (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
+ continue^M
+ Continuing.^M
+ Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
+ ^M
+ Thread 1 "thread-specific" hit Breakpoint 4, end () at \
+ thread-specific-bp.c:29^M
+ 29 }^M
+ (gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
+ continue to end (timeout)
+ ...
+
+ The problem is that the test-case tries to match the "[Thread ... exited]"
+ message which we do see with native testing:
+ ...
+ Continuing.^M
+ [Thread 0x7ffff746e700 (LWP 7047) exited]^M
+ Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
+ ...
+
+ The fact that the message is missing was reported as PR remote/30129.
+
+ We could add a KFAIL for this, but the functionality the test-case is trying
+ to test has nothing to do with the message, so it should pass. I only added
+ matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix
+ gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
+ broke testing on native-gdbserver.
+
+ Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
+ instead.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/*.exp for remote target
+ Fix test-cases for target board remote-gdbserver-on-localhost by using
+ gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/unittest.exp for remote target
+ With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
+ get:
+ ...
+ (gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
+ --selftest^M
+ Selftests have been disabled for this build.^M
+ UNSUPPORTED: gdb.server/unittest.exp: unit tests
+ ...
+ but with target board remote-stdio-gdbserver I get instead:
+ ...
+ (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
+ /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
+ Selftests have been disabled for this build.^M
+ Connection to localhost closed.^M^M
+ FAIL: gdb.server/unittest.exp: unit tests
+ ...
+
+ Fix this by making the regexp less strict.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.exp
+ With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver
+ I run into:
+ ...
+ (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \
+ --selftest^M
+ Selftests have been disabled for this build.^M
+ UNSUPPORTED: gdb.server/unittest.exp: unit tests
+ ...
+ due to using the system gdbserver /usr/bin/gdbserver rather than the one from
+ the build.
+
+ Fix this by removing the hard-coding of /usr/bin/gdbserver in
+ remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we
+ have instead:
+ ...
+ (gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
+ /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
+ Running selftest remote_memory_tagging.^M
+ Ran 1 unit tests, 0 failed^M
+ Connection to localhost closed.^M^M
+ PASS: gdb.server/unittest.exp: unit tests
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/sysroot.exp for remote target
+ Fix test-case gdb.server/sysroot.exp with target board
+ remote-gdbserver-on-localhost, by:
+ - using gdb_remote_download, and
+ - disabling the "local" scenario for remote host.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
+ Test-case gdb.server/multi-ui-errors.exp fails for target board
+ remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
+ ...
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
+ Executing on target: kill -9 6447 (timeout = 300)
+ builtin_spawn [open ...]^M
+ XYZ1ZYX
+ sh: line 0: kill: (6447) - Operation not permitted
+ ...
+
+ The problem is that the kill command:
+ ...
+ remote_exec target "kill -9 $gdbserver_pid"
+ ...
+ intended to kill gdbserver instead tries to kill the ssh client session in
+ which the gdbserver runs, and fails because it's trying as the remote target
+ user (remote-target on localhost) to kill a pid owned by the the build user
+ ($USER on localhost).
+
+ Fix this by getting the gdbserver pid using the ppid trick from
+ server-kill.exp.
+
+ Likewise in gdb.server/server-kill-python.exp.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
+ In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
+ an observation is made that test-case gdb.server/server-kill.exp claims to
+ kill gdbserver, but actually kills the inferior. Consequently, the commit
+ adds testing of killing gdbserver alongside.
+
+ The problem is that:
+ - the original observation is incorrect (possibly caused by misreading getppid
+ as getpid)
+ - consequently, the test-case doesn't test killing the inferior, instead it
+ tests killing gdbserver twice
+ - the method to get the gdbserver PID added in the commit doesn't work
+ for target board remote-gdbserver-on-localhost, it returns the
+ PID of the ssh client session instead.
+
+ Fixing the method for getting the inferior PID gives us fails, and there's no
+ evidence that killing the inferior ever worked.
+
+ So, fix this by reverting the commit and just killing gdbserver, using the
+ original method of getting the gdbserver PID which does work for target board
+ remote-gdbserver-on-localhost.
+
+ Tested on x86_64-linux.
+
+2023-03-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target
+ Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
+ remote-gdbserver-on-localhost.
+
+ The problem is here:
+ ...
+ set target_exec [gdb_remote_download target $binfile.bak $binfile]
+ ...
+ A "gdb_remote_download target" copies from build to target. So $binfile is
+ assumed to be a target path, but it's actually a build path.
+
+ Fix this by:
+ - fist copying $binfile.bak to $binfile, and
+ - simply doing [gdb_remote_download target $binfile].
+
+ Then, $binfile.bak is created here:
+ ...
+ # Make sure we have the original symbol file in a safe place to copy from.
+ gdb_remote_download host $binfile $binfile.bak
+ ...
+ and since "gdb_remote_download host" copies from build to host, $binfile.bak
+ is assumed to be a host path, but it's actually a build path. This happens to
+ cause no problems in this configuration (because build == host), but it would
+ for a remote host configuration.
+
+ So let's fix this by making build rather than host the "safe place to copy
+ from".
+
+ Tested on x86_64-linux.
+
+2023-03-09 Alan Modra <amodra@gmail.com>
+
+ lddigest 32-bit support and gcc-4 compile errors
+ * ld.texi: Revert 2023-03-08 commit 9a534b9f8e3d.
+ * testsuite/ld-scripts/crc64-poly.d: Likewise.
+ * testsuite/ld-scripts/crc64-poly.t: Likewise.
+ * lddigest.c: Formatting.
+ (get_uint64_t): New function.
+ (lang_add_digest): Take etree_type* args. Replace "illegal" with
+ "invalid" in error message.
+ * lddigest.h (lang_add_digest): Update prototype.
+ * lddigest_tab.c (algorithms): Work around gcc-4 errors.
+ * ldgram.y (polynome): Adjust lang_add_digest call.
+ * testsuite/ld-scripts/crc64-poly-size.d: Update expected error.
+
+2023-03-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-08 Tom Tromey <tom@tromey.com>
+
+ Remove OBJF_REORDERED
+ OBJF_REORDERED is set for nearly every object format. And, despite
+ the ominous warnings here and there, it does not seem very expensive.
+ This patch removes the flag entirely.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-03-08 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix test gdb.arch/altivec-regs.exp
+ The test fails on Power 10 with the RHEL9 distro. It also fails on
+ Power 9.
+
+ The test set a the breakpoint in main that stops at line:
+ a = 9; /* start here */. The test then sets a break point at the same
+ line where it wants to start the test and does a continue. GDB does not
+ stop again on the same line where it is stopped, but rather continues to
+ the end of the program.
+
+ Initialize variable A to zero so the break on main will stop before setting
+ a break point on line a = 9; /* start here */.
+
+ Make the match on the breakpoint number generic.
+
+ Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
+ and Power 9 with Fedora 36 with no regression failures.
+
+2023-03-08 Nick Clifton <nickc@redhat.com>
+
+ ld: Use correct types for crc64 calculations
+
+2023-03-08 Alan Modra <amodra@gmail.com>
+
+ Tidy pe_ILF_build_a_bfd a little
+ * peicode.h (ILF section, pe_ILF_object_p): Correct comments
+ and update the reference to Microsoft's docs.
+ (pe_ILF_build_a_bfd): Move all symbol creation before flipping
+ the bfd over to in-memory.
+
+ Re: DIGEST: testsuite
+ Correct test target/skip lines to fix fails on alpha-dec-vms,
+ alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd,
+ ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and
+ tic54x-coff.
+
+ Regen potfiles
+
+2023-03-08 Alan Modra <amodra@gmail.com>
+
+ Re: Move nm.c cached line number info to bfd usrdata
+ Commit e3f450f3933d resulted in a nm -l segfault on object files
+ without undefined symbols. Fix that, and be paranoid about bfd
+ section count changing.
+
+ * nm.c (struct lineno_cache): Add seccount.
+ (free_lineno_cache): Don't segfault on NULL lc->relocs.
+ (print_symbol): Stash section count when creating arrays.
+
+2023-03-08 Alan Modra <amodra@gmail.com>
+
+ z8 and z80 coff_reloc16_extra_cases sanity checks
+ * reloc16.c (bfd_coff_reloc16_get_relocated_section_contents):
+ Use size_t variables. Sanity check reloc address. Handle
+ errors from bfd_coff_reloc16_extra_cases.
+ * coffcode.h (_bfd_coff_reloc16_extra_cases): Return bool, take
+ size_t* args.
+ (dummy_reloc16_extra_cases): Adjust to suit. Don't abort.
+ * coff-z80.c (extra_case): Sanity check reloc address. Return
+ errors. Tidy formatting. Use bfd_signed_vma temp var to
+ check for reloc overflow. Don't abort on unexpected reloc type,
+ instead print an error and return false.
+ * coff-z8k.c (extra_case): Likewise.
+ * libcoff.h: Regenerate.
+
+2023-03-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value
+ The AMD GPU support has been merged shortly after commit 4e1d2f5814b2
+ ("Add new overload of gdbarch_return_value"), which made it mandatory
+ for architectures to provide either a return_value or
+ return_value_as_value implementation. Because of my failure to test
+ properly after rebasing and before pushing, we get this with the current
+ master:
+
+ $ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch
+ /home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ...
+ return_value_as_value
+
+ I started trying to change GDB to not force architectures to provide a
+ return_value or return_value_as_value implementation, but Andrew pointed
+ out that any serious port will have an implementation one day or
+ another, and it's easy to add a dummy implementation in the mean time.
+ So it's better to not complicate the core of GDB to know how to deal
+ with this.
+
+ There is an implementation of return_value in the downstream ROCgdb port
+ (which we'll need to convert to the new return_value_as_value), which
+ we'll contribute soon-ish. In the mean time, add a dummy implementation
+ of return_value_as_value to avoid the failed assertion.
+
+ Change-Id: I26edf441b511170aa64068fd248ab6201158bb63
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2023-03-07 Tom Tromey <tom@tromey.com>
+
+ Merge forget_cached_source_info_for_objfile into objfile method
+ forget_cached_source_info_for_objfile does some objfile-specific work
+ and then calls objfile::forget_cached_source_info. It seems better to
+ me to just have the method do all the work.
+
+2023-03-07 Tom Tromey <tom@tromey.com>
+
+ Clean up attribute reprocessing
+ I ran across the attribute reprocessing code recently and noticed that
+ it unconditionally sets members of the CU when reading a DIE. Also,
+ each spot reading attributes needs to be careful to "reprocess" them
+ as a separate step.
+
+ This seemed excessive to me, because while reprocessing applies to any
+ DIE, setting the CU members is only necessary for the toplevel DIE in
+ any given CU.
+
+ This patch introduces a new read_toplevel_die function and changes a
+ few spots to call it. This is easily done because reading the
+ toplevel DIE is already special.
+
+ I left the reprocessing flag and associated checks in attribute. It
+ could be stripped out, but I am not sure it would provide much value
+ (maybe some iota of performance).
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-03-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: initialize interp::next
+ This field is never initialized, it seems to me like it would be a good
+ idea to initialize it to nullptr to avoid bad surprises.
+
+ Change-Id: I8c04319d564f5d385d8bf0acee758f6ce28b4447
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make interp::m_name an `const char *`
+ I realized that the memory for interp names does not need to be
+ allocated. The name used to register interp factory functions is always
+ a literal string, so has static storage duration. If we change
+ interp_lookup to pass that name instead of the string that it receives
+ as a parameter (which does not always have static storage duration),
+ then interps can simply store pointers to the name.
+
+ So, change interp_lookup to pass `factory.name` rather than `name`.
+ Change interp::m_name to be a `const char *` rather than an std::string.
+
+ Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make get_interp_info return a reference
+ get_interp_info and get_current_interp_info always return non-nullptr,
+ so they can return a reference instead of a pointer.
+
+ Since we don't need to copy it, make ui_interp_info non-copyiable, to
+ avoid a copying it in a local variable, instead of getting a reference.
+
+ Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-07 Tom Tromey <tromey@adacore.com>
+
+ Fix selfcheck regression due to new maint command
+ Simon points out that the new maint command, intended to fix a
+ regression, also introduces a new regression in "maint selftest".
+
+ This patch fixes the error. I did a full regression test on x86-64
+ Fedora 36.
+
+2023-03-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: read Dwarf 5
+ gprofng reads Dwarf to find function names, sources, and line numbers.
+ gprofng skips other debug information.
+ I fixed three places in gprofng Dwarf reader:
+ - parsing the compilation unit header.
+ - parsing the line number table header.
+ - parsing new DW_FORMs.
+
+ Tested on aarch64-linux/x86_64-linux.
+
+ gprofng/ChangeLog
+ 2023-03-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30195
+ gprofng/src/Dwarf.cc: Support Dwarf-5.
+ gprofng/src/DwarfLib.cc: Likewise.
+ gprofng/src/Dwarf.h: Likewise.
+ gprofng/src/DwarfLib.h: Likewise.
+ gprofng/src/collctrl.cc: Don't read freed memory.
+
+2023-03-07 Richard Purdie <richard.purdie@linuxfoundation.org>
+
+ gdb: Fix GDB_AC_CHECK_BFD macro regression
+ Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in
+ GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
+ this caused the configure check "checking for ELF support in BFD" to stop
+ working causing build failures as we need our LDFLAGS to be used for
+ correct linking.
+
+ That change also meant the code failed to match the comments. Add back the
+ missing LDFLAGS preservation, fix our builds and match the comment.
+
+ Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
+
+2023-03-07 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Enable vector instruction debugging for AIX
+ AIX now supports vector register contents debugging for both VMX
+ VSX registers.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/execl.exp for remote target
+ Fix test-case gdb.threads/execl.exp on target board
+ remote-gdbserver-on-localhost using gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom Tromey <tromey@adacore.com>
+
+ Ensure index cache entry written in test
+ Now that index cache files are written in the background, one test in
+ index-cache.exp is racy -- it assumes that the cache file will have
+ been written during startup.
+
+ This patch fixes the problem by introducing a new maintenance command
+ to wait for all pending writes to the index cache.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/skip-solib.exp for remote target
+ Fix test-case gdb.base/skip-solib.exp for target board
+ remote-gdbserver-on-localhost using gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.exp
+ In test-case gdb.base/skip-solib.exp the linking against a shared library is
+ done manually:
+ ...
+ if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \
+ [list debug "additional_flags=-L$testobjdir" \
+ "additional_flags=-l${test}" \
+ "ldflags=-Wl,-rpath=$testobjdir"]] != ""} {
+ ...
+
+ Instead, use the shlib gdb_compile option such that we simply have:
+ ...
+ [list debug shlib=$binfile_lib]] != ""} {
+ ...
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for remote target
+ Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board
+ remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/break-probes.exp for remote target
+ With test-case gdb.base/break-probes.exp and target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-zero-range.exp for remote-gdbserver-on-localhost
+ Fix test-case gdb.dwarf2/dw2-zero-range.exp for target board
+ remote-gdbserver-on-localhost using gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Ulf Samuelsson <ulf@emagii.com>
+
+ Build ldint
+
+2023-03-07 Ulf Samuelsson <ulf@emagii.com>
+
+ DIGEST: Makefile.*
+ The Makefile.in was generated using automake
+ after adding a few files.
+
+ When adding the ldreflect.* files, the autotools
+ versions were wrong.
+ After upgrading the host OS, autotools were upgraded to 2.71
+ reinstalling the desired 2.69 still generates a lot of changes.
+
+ Makefile.ini has therefore been manually edited.
+
+2023-03-07 Ulf Samuelsson <ulf@emagii.com>
+
+ DIGEST: calculation
+
+ DIGEST: ldlang.*: add timestamp
+
+ DIGEST: ldmain.c
+
+ DIGEST: ldgram.y
+
+ DIGEST: ldlex.l
+
+ DIGEST: testsuite
+
+ DIGEST: Documentation
+
+ DIGEST: NEWS
+
+ DIGEST: LICENSING
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
+ With test-case gdb.base/signals-state-child.exp on target board
+ remote-gdbserver-on-localhost I run into:
+ ...
+ builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
+ $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
+ bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
+ Permission denied^M
+ Connection to localhost closed.^M^M
+ FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
+ ...
+
+ The problem is that we're trying to run an executable on the target board using
+ a host path.
+
+ After fixing this by downloading the exec to the target board, we run into:
+ ...
+ builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
+ signals-state-child-standalone^M
+ bash: signals-state-child-standalone: command not found^M
+ Connection to localhost closed.^M^M
+ FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
+ ...
+
+ Fix this by using an absolute path name for the exec on the target board.
+
+ The dejagnu proc standard_file does not support op == "absolute" for target
+ boards, so add an implementation in remote-gdbserver-on-localhost.exp.
+
+ Also:
+ - fix a PATH-in-test-name issue
+ - cleanup gdb.txt and standalone.txt on target board
+
+ Tested on x86_64-linux.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/breakpoint-shlib-func.exp with remote-gdbserver-on-localhost
+ Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board
+ remote-gdbserver-on-localhost.
+
+ Fix this by adding the missing gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+2023-03-07 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Modify altivec-regs.exp testcase for AIX
+ On AIX, the debugger cannot access vector registers before they
+ are first used by the inferior. Hence we change the test case
+ such that some vector registers are accessed by the variable 'x' in AIX
+ and other targets are not affected as a consequence of the same.
+
+2023-03-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/*.exp with remote-gdbserver-on-localhost
+ When running test-cases gdb.mi/*.exp with target board
+ remote-gdbserver-on-localhost, we run into a few fails.
+
+ Fix these (and make things more similar to the gdb.exp procs) by:
+ - factoring out mi_load_shlib out of mi_load_shlibs
+ - making mi_load_shlib use gdb_download_shlib, like
+ gdb_load_shlib
+ - factoring out mi_locate_shlib out of mi_load_shlib
+ - making mi_locate_shlib check for mi_spawn_id, like
+ gdb_locate_shlib
+ - using gdb_download_shlib and mi_locate_shlib in the test-cases.
+
+ Tested on x86_64-linux, with and without target board
+ remote-gdbserver-on-localhost.
+
+2023-03-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.c
+ When building with clang 16, I see:
+
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.load_args = 1;
+ ^ ~
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.critical = 1;
+ ^ ~
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.interrupt = 1;
+ ^ ~
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.fp_sdcc = 1;
+ ^ ~
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.fp_sdcc = 1;
+ ^ ~
+ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ info->prologue_type.fp_sdcc = 1;
+ ^ ~
+
+ Fix that by using "unsigned int" as the bitfield's underlying type.
+
+ Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d
+
+2023-03-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h
+ When building with clang 16, we get:
+
+ CXX gdb.o
+ In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
+ In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]
+ integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
+ ^
+
+ The error message does not make it clear in the context of which enum
+ flag this fails (i.e. what is T in this context), but it doesn't really
+ matter, we have similar warning/errors for many of them, if we let the
+ build go through.
+
+ clang is right that the value -1 is invalid for the enum type we cast -1
+ to. However, we do need this expression in order to select an integer
+ type with the appropriate signedness. That is, with the same signedness
+ as the underlying type of the enum.
+
+ I first wondered if that was really needed, if we couldn't use
+ std::underlying_type for that. It turns out that the comment just above
+ says:
+
+ /* Note that std::underlying_type<enum_type> is not what we want here,
+ since that returns unsigned int even when the enum decays to signed
+ int. */
+
+ I was surprised, because std::is_signed<std::underlying_type<enum_type>>
+ returns the right thing. So I tried replacing all this with
+ std::underlying_type, see if that would work. Doing so causes some
+ build failures in unittests/enum-flags-selftests.c:
+
+ CXX unittests/enum-flags-selftests.o
+ /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s
+ elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla
+ gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte
+ sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true':
+ CHECK_VALID (true, int, true ? EF () : EF2 ())
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'
+ CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'
+ CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'
+ static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, \
+ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ This is a bit hard to decode, but basically enumerations have the
+ following funny property that they decay into a signed int, even if
+ their implicit underlying type is unsigned. This code:
+
+ enum A {};
+ enum B {};
+
+ int main() {
+ std::cout << std::is_signed<std::underlying_type<A>::type>::value
+ << std::endl;
+ std::cout << std::is_signed<std::underlying_type<B>::type>::value
+ << std::endl;
+ auto result = true ? A() : B();
+ std::cout << std::is_signed<decltype(result)>::value << std::endl;
+ }
+
+ produces:
+
+ 0
+ 0
+ 1
+
+ So, the "CHECK_VALID" above checks that this property works for enum flags the
+ same way as it would if you were using their underlying enum types. And
+ somehow, changing integer_for_size to use std::underlying_type breaks that.
+
+ Since the current code does what we want, and I don't see any way of doing it
+ differently, ignore -Wenum-constexpr-conversion around it.
+
+ Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2
+
+2023-03-07 John Baldwin <jhb@FreeBSD.org>
+
+ gdb.threads/next-bp-other-thread.c: Ensure child thread is started.
+ Use a pthread_barrier to ensure the child thread is started before
+ the main thread gets to the first breakpoint.
+
+ gdb.threads/execl.c: Ensure all threads are started before execl.
+ Use a pthread_barrier to ensure all threads are started before
+ proceeding to the breakpoint where info threads output is checked.
+
+2023-03-07 John Baldwin <jhb@FreeBSD.org>
+
+ gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.
+ - Some OS's use a different syscall for exit(). For example, the
+ BSD's use SYS_exit rather than SYS_exit_group. Update the C source
+ file and the expect script to support SYS_exit as an alternative to
+ SYS_exit_group.
+
+ - The cross-arch syscall number tests are all Linux-specific with
+ hardcoded syscall numbers specific to Linux kernels. Skip these
+ tests on non-Linux systems. FreeBSD kernels for example use the
+ same system call numbers on all platforms, so the test is also not
+ relevant on FreeBSD.
+
+2023-03-07 John Baldwin <jhb@FreeBSD.org>
+
+ gdb.threads/multi-create: Double the existing stack size.
+ Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the
+ stack on FreeBSD rather than raising it causing non-main threads in
+ the test program to overflow their stack and crash. Double the
+ existing stack size rather than assuming that the initial stack size
+ is PTHREAD_STACK_MIN.
+
+2023-03-07 John Baldwin <jhb@FreeBSD.org>
+
+ amd64-linux-tdep: Don't treat fs_base and gs_base as system registers.
+ These registers can be changed directly in userspace, and similar
+ registers to support TLS on other architectures (tpidr* on ARM and
+ AArch64, tp on RISC-V) are treated as general purpose registers.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-07 John Baldwin <jhb@FreeBSD.org>
+
+ gdb.arch/amd64-gs_base.exp: Support non-Linux.
+ The orig_rax pseudo-register is Linux-specific and isn't relevant to
+ this test. The fs_base and gs_base registers are also not treated as
+ system registers in other OS ABIs. This allows the test to pass on
+ FreeBSD.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-06 Kévin Le Gouguec <legouguec@adacore.com>
+
+ gdb/python: Fix --disable-tui build
+ As of 2023-02-13 "gdb/python: deallocate tui window factories at Python
+ shut down" (9ae4519da90), a TUI-less build fails with:
+
+ $src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’:
+ $src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared
+ 621 | gdbpy_tui_window_maker::invalidate_all ();
+ | ^~~~~~~~~~~~~~~~~~~~~~
+
+ Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an
+ #ifdef guard in gdbpy_finalize_tui as well.
+
+2023-03-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuite
+ Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests
+ the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather
+ than gdb.base.
+
+ Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to
+ gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with
+ recently added gdb.testsuite/gdb-caching-proc.exp.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow args in gdb_caching_proc
+ Test-case gdb.base/morestack.exp contains:
+ ...
+ require {have_compile_flag -fsplit-stack}
+ ...
+ and I want to cache the result of have_compile_flag.
+
+ Currently gdb_caching_proc doesn't allow args, so I could add:
+ ...
+ gdb_caching_proc have_compile_flag_fsplit_stack {
+ return [have_compile_flag -fsplit-stack]
+ }
+ ...
+ and then use that proc instead, but I find this cumbersome and
+ maintenance-unfriendly.
+
+ Instead, allow args in a gdb_caching_proc, such that I can simply do:
+ ...
+ -proc have_compile_flag { flag } {
+ +gdb_caching_proc have_compile_flag { flag } {
+ ...
+
+ Note that gdb_caching_procs with args do not work with the
+ gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use regular proc syntax for gdb_caching_proc
+ A regular tcl proc with no args looks like:
+ ...
+ proc foo {} {
+ return 1
+ }
+ ...
+ but a gdb_caching_proc deviates from that syntax by dropping the explicit no
+ args bit:
+ ...
+ gdb_caching_proc foo {
+ return 1
+ }
+ ...
+
+ Make the gdb_caching_proc use the same syntax as regular procs, such that we
+ have instead:
+ ...
+ gdb_caching_proc foo {} {
+ return 1
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.testsuite/gdb-caching-proc.exp
+ Add test-case gdb.testsuite/gdb-caching-proc.exp that excercises
+ gdb_caching_proc.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-06 Tom Tromey <tromey@adacore.com>
+
+ Fix DAP stackTrace through frames without debuginfo
+ The DAP stackTrace implementation did not fully account for frames
+ without debuginfo. Attemping this would yield a result like:
+
+ {"request_seq": 5, "type": "response", "command": "stackTrace", "success": false, "message": "'NoneType' object has no attribute 'filename'", "seq": 11}
+
+ This patch fixes the problem by adding another check for None.
+
+2023-03-06 Tom Tromey <tromey@adacore.com>
+
+ Remove exception_catchpoint::resources_needed
+ exception_catchpoint::resources_needed has a FIXME comment that I
+ think makes this method obsolete. Also, I note that similar
+ catchpoints, for example Ada catchpoints, don't have this method.
+ This patch removes the method. Regression tested on x86-64 Fedora 36.
+
+2023-03-06 Tom Tromey <tromey@adacore.com>
+
+ Remove two more files in gdb "distclean"
+ The recent work to have gdb link via libtool means that there are a
+ couple more generated files in the build directory that should be
+ removed by "distclean".
+
+ Note that gdb can't really fully implement distclean due to the desire
+ to put certain generated files into the distribution. Still, it can
+ get pretty close.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ macho null dereference read
+ The main problem here was not returning -1 from canonicalize_symtab on
+ an error, leaving the vector of relocs only partly initialised and one
+ with a null sym_ptr_ptr.
+
+ * mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error,
+ not 0.
+ (bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to
+ undefined section sym.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ PR30198, Assertion and segfault when linking x86_64 elf and coff
+ PR 30198
+ * coff-x86_64.c (coff_amd64_reloc): Set *error_message when
+ returning bfd_reloc_dangerous. Also check that __ImageBase is
+ defined before accessing h->u.def.
+
+ More _bfd_ecoff_locate_line sanity checks
+ * ecofflink.c (mk_fdrtab): Discard fdr with negative cpd.
+ (lookup_line): Sanity check fdr cbLineOffset and cbLine.
+ Sanity check pdr cbLineOffset.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ Correct odd loop in ecoff lookup_line
+ I can't see why this really odd looking loop was written the way it
+ was in commit a877f5917f90, but it can result in a buffer overrun.
+
+ * ecofflink.c (lookup_line): Don't swap in pdr at pdr_end.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ Downgrade objdump fatal errors to non-fatal
+ * objdump.c (slurp_symtab): Replace bfd_fatal calls with calls
+ to my_bfd_nonfatal.
+ (slurp_dynamic_symtab, disassemble_section): Likewise.
+ (disassemble_data): Replace fatal call with non_fatal call, and
+ set exit_status. Don't error on non-existent dynamic relocs.
+ Don't call bfd_fatal on bfd_canonicalize_dynamic_reloc error.
+ (dump_ctf, dump_section_sframe): Replace bfd_fatal calls with
+ calls to my_bfd_nonfatal and clean up memory.
+ (dump_relocs_in_section): Don't call bfd_fatal on errors.
+ (dump_dynamic_relocs): Likewise.
+ (display_any_bfd): Make archive nesting too depp non_fatal.
+
+ Downgrade addr2line fatal errors to non-fatal
+ * addr2line.c (slurp_symtab): Don't exit on errors.
+ (process_file): Likewise.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ Downgrade nm fatal errors to non-fatal
+ Many of the fatal errors in nm ought to be recoverable. This patch
+ downgrades most of them. The ones that are left are most likely due
+ to memory allocation failures.
+
+ * nm.c (print_symdef_entry): Don't bomb with a fatal error
+ on a corrupted archive symbol table.
+ (filter_symbols): Silently omit symbols that return NULL
+ from bfd_minisymbol_to_symbol rather than giving a fatal
+ error.
+ (display_rel_file): Don't give a fatal error on
+ bfd_read_minisymbols returning an error, or on not being able
+ to read dynamic symbols for synth syms.
+ (display_archive): Downgrade bfd_openr_next_archived_file
+ error.
+ (display_file): Don't bomb on a bfd_close failure.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ Move nm.c cached line number info to bfd usrdata
+ Replace the static variables used by nm to cache line number info
+ with a struct attached to the bfd. Cleaner, and it avoids any concern
+ that lineno_cache_bfd is somehow left pointing at memory for a closed
+ bfd and that memory is later reused for another bfd, not that I think
+ this is possible. Also don't bomb via bfd_fatal on errors getting
+ the line number info, just omit the line numbers.
+
+ * nm.c (struct lineno_cache): Rename from get_relocs_info.
+ Add symcount.
+ (lineno_cache_bfd, lineno_cache_rel_bfd): Delete.
+ (get_relocs): Adjust for struct rename. Don't call bfd_fatal
+ on errors.
+ (free_lineno_cache): New function.
+ (print_symbol): Use lineno_cache in place of statics. Don't
+ call bfd_fatal on errors reading symbols, just omit the line
+ info.
+ (display_archive, display_file): Call free_lineno_cache.
+
+2023-03-06 Alan Modra <amodra@gmail.com>
+
+ Correct objdump command line error handling
+ bfd_nonfatal is used when a bfd error is to be printed. That's not
+ the case for command line errors.
+
+ * objdump.c (nonfatal): Rename to my_bfd_nonfatal.
+ (main): Use non_fatal and call usage on unrecognized arg errors.
+ Don't set exit_status when calling usage.
+
+2023-03-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-03 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO`
+ When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash,
+ rather than bash, I get:
+
+ c&^M
+ Continuing.^M
+ (gdb) sh: 1: kill: Illegal option -S^M
+ ^M
+ Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M
+ 23 return 0;^M
+ FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout)
+
+ This is because it uses the kill command built-in the dash shell, and
+ using the SIG prefix with kill does not work with dash's kill. The
+ difference is listed in the documentation for bash's POSIX-correct mode
+ [1]:
+
+ The kill builtin does not accept signal names with a ‘SIG’ prefix.
+
+ Replace SIGINT with INT in that test.
+
+ By grepping, I found two other instances (gdb.base/sigwinch-notty.exp
+ and gdb.threads/detach-step-over.exp). Those were not problematic on my
+ system though. Since they are done through remote_exec, they don't go
+ through the shell and therefore invoke /bin/kill. On my Arch Linux,
+ it's:
+
+ $ /bin/kill --version
+ kill from util-linux 2.38.1 (with: sigqueue, pidfd)
+
+ and on my Ubuntu:
+
+ $ /bin/kill --version
+ kill from procps-ng 3.3.17
+
+ These two implementations accept "-SIGINT". But according to the POSIX
+ spec [2], the kill utility should recognize the signal name without the
+ SIG prefix (if it recognizes them with the SIG prefix, it's an
+ extension):
+
+ -s signal_name
+ Specify the signal to send, using one of the symbolic names defined
+ in the <signal.h> header. Values of signal_name shall be recognized
+ in a case-independent fashion, without the SIG prefix. In addition,
+ the symbolic name 0 shall be recognized, representing the signal
+ value zero. The corresponding signal shall be sent instead of SIGTERM.
+ -signal_name
+ [XSI] [Option Start]
+ Equivalent to -s signal_name. [Option End]
+
+ So, just in case some /bin/kill implementation happens to not recognize
+ the SIG prefixes, change these two other calls to remove the SIG
+ prefix.
+
+ [1] https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html
+ [2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html
+
+ Change-Id: I81ccedd6c9428ab63b9261813f1905a18941f8da
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use set always-read-ctf on instead of --strip-debug
+ Use "set always-read-ctf on" instead of --strip-debug in the ctf test-cases.
+
+ Tested on x86_64-linux.
+
+2023-03-03 Tom Tromey <tromey@adacore.com>
+
+ Update expected results in long_long.exp
+ Simon pointed out that the recent patch to add half-float support to
+ 'x/f' caused a couple of regressions in long_long.exp. This patch
+ fixes these by updating the expected results.
+
+2023-03-03 Nick Clifton <nickc@redhat.com>
+
+ Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant.
+ PR 30193 * ldgram.y (ASCII): Fail if the size is not a constant.
+
+2023-03-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: replace strlen call with std::string::size call
+ Small cleanup to use std::string::size instead of calling strlen on
+ the result of std::string::c_str.
+
+ Should be no user visible changes after this call.
+
+2023-03-03 Jan Beulich <jbeulich@suse.com>
+
+ x86: use swap_2_operands() in build_vex_prefix()
+ Open-coding part of what may eventually be needed is somewhat risky.
+ Let's use the function we have, taking care of all pieces of data which
+ may need swapping, no matter that
+ - right now i.flags[] and i.reloc[] aren't relevant here (yet),
+ - EVEX masking and embedded broadcast aren't applicable.
+
+ x86: drop redundant calculation of EVEX broadcast size
+ In commit a5748e0d8c50 ("x86/Intel: allow MASM representation of
+ embedded broadcast") I replaced the calculation of i.broadcast.bytes in
+ check_VecOperands() not paying attention to the immediately following
+ call to get_broadcast_bytes() doing exactly that (again) first thing.
+
+2023-03-03 Jan Beulich <jbeulich@suse.com>
+
+ gas: default .debug section compression method adjustments
+ While commit b0c295e1b8d0 ("add --enable-default-compressed-debug-
+ sections-algorithm configure option") adjusted flag_compress_debug's
+ initializer, it didn't alter the default used when the command line
+ option was specified with an (optional!) argument. This rendered help
+ text inconsistent with actual behavior in certain configurations.
+
+ As to help text - the default reported there clearly shouldn't be
+ affected by a possible earlier --compress-debug-sections= option, so
+ flag_compress_debug can't be used when emitting usage information.
+
+2023-03-03 Jan Beulich <jbeulich@suse.com>
+
+ x86: avoid .byte in testcases where possible
+ In the course of using the upcoming .insn directive to eliminate various
+ .byte uses in testcases I've come across these, which needlessly use
+ more .byte than necessary even without the availability of .insn.
+
+2023-03-03 Alan Modra <amodra@gmail.com>
+
+ Tidy type handling in binutils/rdcoff.c
+ There isn't really any good reason for code in rdcoff.c to distinguish
+ between "basic" types and any other type. This patch dispenses with
+ the array reserved for basic types and instead handles all types using
+ coff_get_slot, simplifying the code.
+
+ * rdcoff.c (struct coff_types, coff_slots): Merge. Delete
+ coff_slots.
+ (T_MAX): Delete.
+ (parse_coff_base_type): Use coff_get_slot to store baseic types.
+ (coff_get_slot, parse_coff_type, parse_coff_base_type),
+ (parse_coff_struct_type, parse_coff_enum_type),
+ (parse_coff_symbol, parse_coff): Pass types as coff_types**.
+
+2023-03-03 Alan Modra <amodra@gmail.com>
+
+ binutils coff type list
+ As for commit 72d225ef9cc7, handle type numbers starting anywhere.
+
+ PR 17512
+ * rdcoff.c (struct coff_slots): Add base_index.
+ (coff_get_slot): Delete pr17512 excessively large slot check.
+ Don't allocate entire array from 0 to type number, allocate a
+ sparse array.
+
+2023-03-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix -Wmaybe-uninitialized warning in value.c
+ Since commit 11470e70ea0d ("gdb: store internalvars in an std::map"), bulding
+ with -O2, with g++ 11.3.0 on Ubuntu 22.04, I see:
+
+ CXX value.o
+ In constructor ‘internalvar::internalvar(internalvar&&)’,
+ inlined from ‘constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const char*&; _U2 = internalvar; typename std::enable_if<(std::_PCC<true, _T1, _T2>::_MoveConstructiblePair<_U1, _U2>() && std::_PCC<true, _T1, _T2>::_ImplicitlyMoveConvertiblePair<_U1, _U2>()), bool>::type <anonymous> = true; _T1 = const char*; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:353:35,
+ inlined from ‘constexpr std::pair<typename std::__strip_reference_wrapper<typename std::decay<_Tp>::type>::__type, typename std::__strip_reference_wrapper<typename std::decay<_Tp2>::type>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = const char*&; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:572:72,
+ inlined from ‘internalvar* create_internalvar(const char*)’ at /home/smarchi/src/binutils-gdb/gdb/value.c:1933:52:
+ /home/smarchi/src/binutils-gdb/gdb/value.c:1831:8: warning: ‘<unnamed>.internalvar::u’ may be used uninitialized [-Wmaybe-uninitialized]
+ 1831 | struct internalvar
+ | ^~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/value.c: In function ‘internalvar* create_internalvar(const char*)’:
+ /home/smarchi/src/binutils-gdb/gdb/value.c:1933:76: note: ‘<anonymous>’ declared here
+ 1933 | auto pair = internalvars.emplace (std::make_pair (name, internalvar (name)));
+ | ^
+
+ This is because the union field internalvar::u is not initialized when
+ constructing the temporary internalvar object above. That object is then used
+ for move-construction, and the (implicit) move constructor copies the
+ uninitialized bytes of field u over from the temporary object to the new
+ internalvar object. The compiler therefore complains that we use uninitialized
+ bytes. I don't think it's really a problem, because the internalvar object is
+ in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
+ irrelevant. Still, mute the warning by default-initializing the union.
+
+ Change-Id: I70c392842f35255f50d8e63f4099cb6685366fb7
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-02 Tom Tromey <tromey@adacore.com>
+
+ Handle half-float in 'x' command
+ Using 'x/hf' should print bytes as float16, but instead it currently
+ prints as an integer. I tracked this down to a missing case in
+ float_type_from_length.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30161
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-02 Tom Tromey <tromey@adacore.com>
+
+ Fix some value comments
+ I noticed a very stale comment in valarith.c. This patch fixes a few
+ comments in this area.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-03-02 Hui Li <lihui@loongson.cn>
+
+ gdb: LoongArch: Add support for static data member in struct
+ As described in C++ reference [1], static data members are not part
+ of objects of a given class type. Modified compute_struct_member ()
+ to ignore static data member so that we can get the expected result.
+
+ loongson@linux:~$ cat test.c
+ #include<stdio.h>
+ struct struct_01 { static unsigned a; float b;};
+ unsigned struct_01::a = 66;
+ struct struct_01 struct_01_val = { 99.00 };
+ int check_arg_struct(struct struct_01 arg)
+ {
+ printf("arg.a = %d\n", arg.a);
+ printf("arg.b = %f\n", arg.b);
+ return 0;
+ }
+ int main()
+ {
+ check_arg_struct(struct_01_val);
+ return 0;
+ }
+ loongson@linux:~$ g++ -g test.c -o test++
+ loongson@linux:~$ gdb test++
+
+ Without this patch:
+ ...
+ (gdb) start
+ ...
+ (gdb) p check_arg_struct(struct_01_val)
+ arg.a = 66
+ arg.b = 0.000000
+ $1 = 0
+
+ With this patch:
+ ...
+ (gdb) start
+ ...
+ (gdb) p check_arg_struct(struct_01_val)
+ arg.a = 66
+ arg.b = 99.000000
+ $1 = 0
+
+ [1] https://learn.microsoft.com/en-us/cpp/cpp/static-members-cpp?view=msvc-170
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-02 Alan Modra <amodra@gmail.com>
+
+ Don't write zeros to a gap in the output file
+ Writing out zeros is counterproductive if a file system supports
+ sparse files. A very large gap need not take much actual disk space,
+ but it usually will if zeros are written.
+
+ memory_bseek also supports not writing out zeros in a gap.
+
+ * elf.c (write_zeros): Delete.
+ (assign_file_positions_for_load_sections): Don't call write_zeros.
+ Comment.
+
+2023-03-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add set/show always-read-ctf on/off
+ [ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add
+ maint set symbol-read-order", submitted here (
+ https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html
+ ). ]
+
+ With the test-case included in this patch, we run into:
+ ...
+ (gdb) file dwarf2-and-ctf
+ (gdb) print var_ctf^M
+ 'var_ctf' has unknown type; cast it to its declared type^M
+ ...
+
+ The problem is that the executable contains both ctf and dwarf2, so the ctf
+ info (which contains the type information about var_ctf) is ignored.
+
+ GDB has support for handling multiple debug formats, but the common use case
+ for ctf is to be used when dwarf2 is not present, and gdb reflects that,
+ assuming that by reading ctf in addition there won't be any extra information,
+ so it's not worth the additional cycles and memory.
+
+ Add a new command "set/show always-read-ctf on/off", that when on forces
+ unconditional reading of ctf, allowing us to do:
+ ...
+ (gdb) set always-read-ctf on
+ (gdb) file dwarf2-and-ctf
+ (gdb) print var_ctf^M
+ $2 = 2^M
+ ...
+
+ The setting is off by default, preserving current behaviour.
+
+ A bit of background on the relevance of reading order: the formats have a
+ priority relationship between them, where reading earlier means lower
+ priority. By reading the format with the most detail last, we ensure it has
+ the highest priority, which makes sure that in case there is overlapping info,
+ the most detailed info is found. This explains the current reading order of
+ mdebug, stabs and dwarf2.
+
+ Add the unconditional reading of ctf before dwarf2, because it's less detailed
+ than dwarf2. The conditional reading of ctf is still done after the attempt to
+ read dwarf2, necessarily so because we only know whether there's dwarf2 after
+ we've tried to read it.
+
+ The new command allow us to replace uses of -Wl,--strip-debug added in commit
+ 908a926ec4e ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by
+ uses of "set always-read-ctf on", but I've left that for another commit.
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: update some copyright years (2022 -> 2023)
+ The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
+ they end in 2022 instead of 2023. I suppose because I posted (or at
+ least prepared) the patches in 2022 but merged them in 2023, and forgot
+ to update the year. I found a bunch of other files that are in the same
+ situation. Fix them all up.
+
+ Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-03-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-03-01 Tom Tromey <tromey@adacore.com>
+
+ Use const for dwarf2_property_baton
+ Once a baton is stored in a struct type, it doesn't make sense to
+ modify it. This patch constifies the API.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-01 Tom Tromey <tromey@adacore.com>
+
+ Make gdb property batons type-safe
+ gdbtypes treats dynamic property batons as 'void *', but in actuality
+ the only users all use dwarf2_property_baton. This patch changes this
+ code to be type-safe. If a new type is needed here, it seems like
+ that too could be done in a type-safe way.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-03-01 Alan Modra <amodra@gmail.com>
+
+ More bounds checking in macro_expand
+ * macro.c (macro_expand): Ensure input string buffer is not
+ read past end.
+
+2023-03-01 Alan Modra <amodra@gmail.com>
+
+ Using .mri in assembly
+ Changing mri mode between macro definition and use isn't good. This
+ .macro x
+ .endm
+ .mri 1
+ x
+ leads to a segfault. Fixed with the following patch, but I suppose
+ what should really happen is that macros be marked as being mri mode
+ when defined, and that determine whether the magic NARG parameter be
+ supplied at expansion. Nobody has complained about this in 30 years
+ so I'm not inclined to change gas behaviour to that extent.
+
+ * macro.c (macro_expand): Don't segfault in mri mode if NARG
+ formal isn't found.
+
+2023-03-01 Tom Tromey <tromey@adacore.com>
+
+ Fix type of check_valid_shift_count parameter
+ check_valid_shift_count has an 'int' parameter that really should be
+ an enum exp_opcode. This patch makes the change. Tested by
+ rebuilding.
+
+2023-03-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix a whitespace issue in solib-rocm.c
+ Change-Id: I9cd236eaf161fe3a1abf0d212efca47a7149e021
+
+2023-03-01 Nick Clifton <nickc@redhat.com>
+
+ Fix typo with my email address
+
+2023-03-01 Tom Tromey <tom@tromey.com>
+
+ Fix btrace regression
+ Tom de Vries pointed out that my earlier patch:
+
+ commit 873a185be258ad2552b9579005852815b4da5baf
+ Date: Fri Dec 16 07:56:57 2022 -0700
+
+ Don't use struct buffer in handle_qxfer_btrace
+
+ regressed gdb.btrace/reconnect.exp. I didn't notice this because I
+ did not have libipt installed.
+
+ This patch fixes the bug.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30169
+ Tested-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-03-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add another xfail case in gdb.python/py-record-btrace.exp
+ I ran into:
+ ...
+ (gdb) PASS: gdb.python/py-record-btrace.exp: function call: \
+ python print(c.prev)
+ python print(c == c.next.prev)^M
+ Traceback (most recent call last):^M
+ File "<string>", line 1, in <module>^M
+ AttributeError: 'NoneType' object has no attribute 'prev'^M
+ Error while executing Python code.^M
+ (gdb) FAIL: gdb.python/py-record-btrace.exp: function call: \
+ python print(c == c.next.prev)
+ ...
+ due to having only 4 insn instead of 100:
+ ...
+ python print(len(insn))^M
+ 4^M
+ ...
+
+ This could be caused by the same hw bug as we already have an xfail for, so
+ expand the xfail matching.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30185
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30185
+
+ Approved-By: Markus T. Metzger <markus.t.metzger@intel.com>
+
+2023-03-01 Alan Modra <amodra@gmail.com>
+
+ Catch overflow in gas s_space
+ Also fix an error introduced in 1998 in reporting a zero count for
+ negative counts.
+
+ * read.c (s_space): Use unsigned multiply, and catch overflow.
+ Correct order of tests for invalid repeat counts. Ensure
+ ignored directives don't affect mri_pending_align.
+
+2023-03-01 Alan Modra <amodra@gmail.com>
+
+ gas s_fill caused internal error in frag_new
+ Fix an internal error after "non-constant fill count for absolute
+ section".
+
+ * read.c (s_fill): Don't create frags after errors.
+
+2023-03-01 Alan Modra <amodra@gmail.com>
+
+ Memory leak in gas do_repeat
+ * read.c (do_repeat): Free sb on error path.
+
+2023-03-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add HtabPrinter to gdb-gdb.py.in
+ When debugging GDB, I find it a bit tedious to inspect htab_t objects.
+ It is possible to find the entries by poking at the fields, but it's
+ annoying to do each time. I think a pretty printer would help. Add a
+ basic one to gdb-gdb.py.
+
+ The pretty printer advertises itself as "array-like", and the result
+ looks like:
+
+ (top-gdb) p bfcache
+ $3 = htab_t with 3 elements = {0x6210003252a0, 0x62100032caa0, 0x62100033baa0}
+
+ The htab_t itself doesn't know about the type of pointed objects. But
+ it's easy enough to cast the addresses to the right type to use them:
+
+ (top-gdb) print *((btrace_frame_cache *) 0x6210003252a0)
+ $6 = {tp = 0x61700002ed80, frame = 0x6210003251e0, bfun = 0x62000000b390}
+
+ Change-Id: Ia692e3555fe7a117b7ec087840246b1260a704c6
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-breakpoint.exp timeouts
+ On powerpc64le-linux, I run into two timeouts:
+ ...
+ FAIL: gdb.python/py-breakpoint.exp: test_watchpoints: \
+ Test watchpoint write (timeout)
+ FAIL: gdb.python/py-breakpoint.exp: test_bkpt_internal: \
+ Test watchpoint write (timeout)
+ ...
+
+ In this case, hw watchpoints are not supported, and using sw watchpoints
+ is slow.
+
+ Most of the time is spent in handling a try-catch, which triggers a malloc. I
+ think this bit is more relevant for the "catch throw" part of the test-case,
+ so fix the timeouts by setting the watchpoints after the try-catch.
+
+ Tested on x86_64-linux and powerpc64le-linux.
+
+2023-02-28 Tom Tromey <tromey@adacore.com>
+
+ Remove value_in
+ value_in is unused. From git log, it seems to have been part of the
+ Chill language, which was removed from gdb eons ago. This patch
+ removes the function. Tested by rebuilding.
+
+2023-02-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.rust/watch.exp on ppc64le
+ On x86_64-linux, I have:
+ ...
+ (gdb) watch -location y^M
+ Hardware watchpoint 2: -location y^M
+ (gdb) PASS: gdb.rust/watch.exp: watch -location y
+ ...
+ but on powerpc64le-linux, I run into:
+ ...
+ (gdb) watch -location y^M
+ Watchpoint 2: -location y^M
+ (gdb) FAIL: gdb.rust/watch.exp: watch -location y
+ ...
+ due to the regexp matching "Hardware watchpoint" but not "Watchpoint":
+ ...
+ gdb_test "watch -location y" ".*watchpoint .* -location .*"
+ ...
+
+ Fix this by making the regexp less restrictive.
+
+ Tested on x86_64-linux and powerpc64le-linux.
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix mi breakpoint-deleted notifications for thread-specific b/p
+ Background
+ ----------
+
+ When a thread-specific breakpoint is deleted as a result of the
+ specific thread exiting the function remove_threaded_breakpoints is
+ called which sets the disposition of the breakpoint to
+ disp_del_at_next_stop and sets the breakpoint number to 0. Setting
+ the breakpoint number to zero has the effect of hiding the breakpoint
+ from the user. We also print a message indicating that the breakpoint
+ has been deleted.
+
+ It was brought to my attention during a review of another patch[1]
+ that setting a breakpoints number to zero will suppress the MI
+ breakpoint-deleted notification for that breakpoint, and indeed, this
+ can be seen to be true, in delete_breakpoint, if the breakpoint number
+ is zero, then GDB will not notify the breakpoint_deleted observer.
+
+ It seems wrong that a user created, thread-specific breakpoint, will
+ have a =breakpoint-created notification, but will not have a
+ =breakpoint-deleted notification. I suspect that this is a bug.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html
+
+ The First Problem
+ -----------------
+
+ During my initial testing I wanted to see how GDB handled the
+ breakpoint after it's number was set to zero. To do this I created
+ the testcase gdb.threads/thread-bp-deleted.exp. This test creates a
+ worker thread, which immediately exits. After the worker thread has
+ exited the main thread spins in a loop.
+
+ In GDB I break once the worker thread has been created and place a
+ thread-specific breakpoint, then use 'continue&' to resume the
+ inferior in non-stop mode. The worker thread then exits, but the main
+ thread never stops - instead it sits in the spin. I then tried to use
+ 'maint info breakpoints' to see what GDB thought of the
+ thread-specific breakpoint.
+
+ Unfortunately, GDB crashed like this:
+
+ (gdb) continue&
+ Continuing.
+ (gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited]
+ Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
+ maint info breakpoints
+ ... snip some output ...
+
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ 0x5ffb62 gdb_internal_backtrace_1
+ ../../src/gdb/bt-utils.c:122
+ 0x5ffc05 _Z22gdb_internal_backtracev
+ ../../src/gdb/bt-utils.c:168
+ 0x89965e handle_fatal_signal
+ ../../src/gdb/event-top.c:964
+ 0x8997ca handle_sigsegv
+ ../../src/gdb/event-top.c:1037
+ 0x7f96f5971b1f ???
+ /usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
+ 0xe602b0 _Z15print_thread_idP11thread_info
+ ../../src/gdb/thread.c:1439
+ 0x5b3d05 print_one_breakpoint_location
+ ../../src/gdb/breakpoint.c:6542
+ 0x5b462e print_one_breakpoint
+ ../../src/gdb/breakpoint.c:6702
+ 0x5b5354 breakpoint_1
+ ../../src/gdb/breakpoint.c:6924
+ 0x5b58b8 maintenance_info_breakpoints
+ ../../src/gdb/breakpoint.c:7009
+ ... etc ...
+
+ As the thread-specific breakpoint is set to disp_del_at_next_stop, and
+ GDB hasn't stopped yet, then the breakpoint still exists in the global
+ breakpoint list.
+
+ The breakpoint will not show in 'info breakpoints' as its number is
+ zero, but it will show in 'maint info breakpoints'.
+
+ As GDB prints the breakpoint, the thread-id for the breakpoint is
+ printed as part of the 'stop only in thread ...' line. Printing the
+ thread-id involves calling find_thread_global_id to convert the global
+ thread-id into a thread_info*. Then calling print_thread_id to
+ convert the thread_info* into a string.
+
+ The problem is that find_thread_global_id returns nullptr as the
+ thread for the thread-specific breakpoint has exited. The
+ print_thread_id assumes it will be passed a non-nullptr. As a result
+ GDB crashes.
+
+ In this commit I've added an assert to print_thread_id (gdb/thread.c)
+ to check that the pointed passed in is not nullptr. This assert would
+ have triggered in the above case before GDB crashed.
+
+ MI Notifications: The Dangers Of Changing A Breakpoint's Number
+ ---------------------------------------------------------------
+
+ Currently the delete_breakpoint function doesn't trigger the
+ breakpoint_deleted observer for any breakpoint with the number zero.
+
+ There is a comment explaining why this is the case in the code; it's
+ something about watchpoints. But I did consider just removing the 'is
+ the number zero' guard and always triggering the breakpoint_deleted
+ observer, figuring that I'd then fix the watchpoint issue some other
+ way.
+
+ But I realised this wasn't going to be good enough. When the MI
+ notification was delivered the number would be zero, so any frontend
+ parsing the notifications would not be able to match
+ =breakpoint-deleted notification to the earlier =breakpoint-created
+ notification.
+
+ What this means is that, at the point the breakpoint_deleted observer
+ is called, the breakpoint's number must be correct.
+
+ MI Notifications: The Dangers Of Delaying Deletion
+ --------------------------------------------------
+
+ The test I used to expose the above crash also brought another problem
+ to my attention. In the above test we used 'continue&' to resume,
+ after which a thread exited, but the inferior didn't stop. Recreating
+ the same test in the MI looks like this:
+
+ -break-insert -p 2 main
+ ^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...}
+ (gdb)
+ -exec-continue
+ ^running
+ *running,thread-id="all"
+ (gdb)
+ ~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n"
+ =thread-exited,id="2",group-id="i1"
+ ~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n"
+
+ At this point the we have a single thread left, which is still
+ running:
+
+ -thread-info
+ ^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1"
+ (gdb)
+
+ Notice that we got the =thread-exited notification from GDB as soon as
+ the thread exited. We also saw the CLI line from GDB, the line
+ explaining that breakpoint 2 was deleted. But, as expected, we didn't
+ see the =breakpoint-deleted notification.
+
+ I say "as expected" because the number was set to zero. But, even if
+ the number was not set to zero we still wouldn't see the
+ notification. The MI notification is driven by the breakpoint_deleted
+ observer, which is only called when we actually delete the breakpoint,
+ which is only done the next time GDB stops.
+
+ Now, maybe this is fine. The notification is delivered a little
+ late. But remember, by setting the number to zero the breakpoint will
+ be hidden from the user, for example, the breakpoint is removed from
+ the MI's -break-info command output.
+
+ This means that GDB is in a position where the breakpoint doesn't show
+ up in the breakpoint table, but a =breakpoint-deleted notification has
+ not yet been sent out. This doesn't seem right to me.
+
+ What this means is that, when the thread exits, we should immediately
+ be sending out the =breakpoint-deleted notification. We should not
+ wait for GDB to next stop before sending the notification.
+
+ The Solution
+ ------------
+
+ My proposed solution is this; in remove_threaded_breakpoints, instead
+ of setting the disposition to disp_del_at_next_stop and setting the
+ number to zero, we now just call delete_breakpoint directly.
+
+ The notification will now be sent out immediately; as soon as the
+ thread exits.
+
+ As the number has not changed when delete_breakpoint is called, the
+ notification will have the correct number.
+
+ And as the breakpoint is immediately removed from the breakpoint list,
+ we no longer need to worry about 'maint info breakpoints' trying to
+ print the thread-id for an exited thread.
+
+ My only concern is that calling delete_breakpoint directly seems so
+ obvious that I wonder why the original patch (that added
+ remove_threaded_breakpoints) didn't take this approach. This code was
+ added in commit 49fa26b0411d, but the commit message offers no clues
+ to why this approach was taken, and the original email thread offers
+ no insights either[2]. There are no test regressions after making
+ this change, so I'm hopeful that this is going to be fine.
+
+ [2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html
+
+ The Complication
+ ----------------
+
+ Of course, it couldn't be that simple.
+
+ The script gdb.python/py-finish-breakpoint.exp had some regressions
+ during testing.
+
+ The problem was with the FinishBreakpoint.out_of_scope callback
+ implementation. This callback is supposed to trigger whenever the
+ FinishBreakpoint goes out of scope; and this includes when the thread
+ for the breakpoint exits.
+
+ The problem I ran into is the Python FinishBreakpoint implementation.
+ Specifically, after this change I was loosing some of the out_of_scope
+ calls.
+
+ The problem is that the out_of_scope call (of which I'm interested) is
+ triggered from the inferior_exit observer. Before my change the
+ observers were called in this order:
+
+ thread_exit
+ inferior_exit
+ breakpoint_deleted
+
+ The inferior_exit would trigger the out_of_scope call.
+
+ After my change the breakpoint_deleted notification (for
+ thread-specific breakpoints) occurs earlier, as soon as the
+ thread-exits, so now the order is:
+
+ thread_exit
+ breakpoint_deleted
+ inferior_exit
+
+ Currently, after the breakpoint_deleted call the Python object
+ associated with the breakpoint is released, so, when we get to the
+ inferior_exit observer, there's no longer a Python object to call the
+ out_of_scope method on.
+
+ My solution is to follow the model for how bpfinishpy_pre_stop_hook
+ and bpfinishpy_post_stop_hook are called, this is done from
+ gdbpy_breakpoint_cond_says_stop in py-breakpoint.c.
+
+ I've now added a new bpfinishpy_pre_delete_hook
+ gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook
+ function I check and where needed call the out_of_scope method.
+
+ With this fix in place I now see the
+ gdb.python/py-finish-breakpoint.exp test fully passing again.
+
+ Testing
+ -------
+
+ Tested on x86-64/Linux with unix, native-gdbserver, and
+ native-extended-gdbserver boards.
+
+ New tests added to covers all the cases I've discussed above.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix failure in gdb.mi/mi-pending.exp with extended-remote
+ I currently see this failure when running the gdb.mi/mi-pending.exp
+ test using the native-extended-remote board:
+
+ -break-insert -f -c x==4 mi-pendshr.c:pendfunc2
+ &"No source file named mi-pendshr.c.\n"
+ ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="mi-pendshr.c:pendfunc2",cond="x==4",evaluated-by="host",times="0",original-location="mi-pendshr.c:pendfunc2"}
+ (gdb)
+ FAIL: gdb.mi/mi-pending.exp: MI pending breakpoint on mi-pendshr.c:pendfunc2 if x==4 (unexpected output)
+
+ The failure is caused by the 'evaluated-by="host"' string, which only
+ appears in the output when the test is run using the
+ native-extended-remote board.
+
+ I could fix this by just updating the pattern in
+ gdb.mi/mi-pending.exp, but I have instead updated mi-pending.exp to
+ make more use of the support procs in mi-support.exp. This did
+ require making a couple of adjustments to mi-support.exp, but I think
+ the result is that mi-pending.exp is now easier to read, and I see no
+ failures with native-extended-remote anymore.
+
+ One of the test names has changed after this work, I think the old
+ test name was wrong - it described a breakpoint as pending when the
+ breakpoint was not pending, I suspect a copy & paste error.
+
+ But there's no changes to what is actually being tested after this
+ patch.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: introduce is_target_non_stop helper proc
+ I noticed that several tests included copy & pasted code to run the
+ 'maint show target-non-stop' command, and then switch based on the
+ result.
+
+ In this commit I factor this code out into a helper proc in
+ lib/gdb.exp, and update all the places I could find that used this
+ pattern to make use of the helper proc.
+
+ There should be no change in what is tested after this commit.
+
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite introduce foreach_mi_ui_mode helper proc
+ Introduce foreach_mi_ui_mode, a helper proc which can be used when
+ tests are going to be repeated once with the MI in the main UI, and
+ once with the MI on a separate UI.
+
+ The proc is used like this:
+
+ foreach_mi_ui_mode VAR {
+ # BODY
+ }
+
+ The BODY will be run twice, once with VAR set to 'main' and once with
+ VAR set to 'separate', inside BODY we can then change the behaviour
+ based on the current UI mode.
+
+ The point of this proc is that we sometimes shouldn't run the separate
+ UI tests (when gdb_debug_enabled is true), and this proc hides all
+ this logic. If the separate UI mode should not be used then BODY will
+ be run just once with VAR set to 'main'.
+
+ I've updated two tests that can make use of this helper proc. I'm
+ going to add another similar test in a later commit.
+
+ There should be no change to what is tested with this commit.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: extend the use of mi_clean_restart
+ The mi_clean_restart proc calls the mi_gdb_start proc passing no
+ arguments.
+
+ In this commit I add an extra (optional) argument to the
+ mi_clean_restart proc, and pass this through to mi_gdb_start.
+
+ The benefit of this is that we can now use mi_clean_restart when we
+ also want to pass the 'separate-mi-tty' or 'separate-inferior-tty'
+ flags to mi_gdb_start, and avoids having to otherwise duplicate the
+ contents of mi_clean_restart in different tests.
+
+ I've updated the obvious places where this new functionality can be
+ used, and I'm seeing no test regressions.
+
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: make more use of mi-support.exp
+ Building on the previous commit, now that the breakpoint related
+ support functions in lib/mi-support.exp can now help creating the
+ patterns for thread specific breakpoints, make use of this
+ functionality for gdb.mi/mi-nsmoribund.exp and gdb.mi/mi-pending.exp.
+
+ There should be no changes in what is tested after this commit.
+
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't duplicate 'thread' field in MI breakpoint output
+ When creating a thread-specific breakpoint with a single location, the
+ 'thread' field would be repeated in the MI output. This can be seen
+ in two existing tests gdb.mi/mi-nsmoribund.exp and
+ gdb.mi/mi-pending.exp, e.g.:
+
+ (gdb)
+ -break-insert -p 1 bar
+ ^done,bkpt={number="1",type="breakpoint",disp="keep",
+ enabled="y",
+ addr="0x000000000040110a",func="bar",
+ file="/tmp/mi-thread-specific-bp.c",
+ fullname="/tmp/mi-thread-specific-bp.c",
+ line="32",thread-groups=["i1"],
+ thread="1",thread="1", <================ DUPLICATION!
+ times="0",original-location="bar"}
+
+ I know we need to be careful when adjusting MI output, but I'm hopeful
+ in this case, as the field is duplicated, and the field contents are
+ always identical, that we might get away with removing one of the
+ duplicates.
+
+ The change in GDB is a fairly trivial condition change.
+
+ We did have a couple of tests that contained the duplicate fields in
+ their expected output, but given there was no comment pointing out
+ this oddity either in the GDB code, or in the test, I suspect this was
+ more a case of copying whatever output GDB produced and using that as
+ the expected results. I've updated these tests to remove the
+ duplication.
+
+ I've update lib/mi-support.exp to provide support for building
+ breakpoint patterns that contain the thread field, and I've made use
+ of this in a new test I've added that is just about creating
+ thread-specific breakpoints and checking the results. The two tests I
+ mentioned above as being updated could also use the new
+ lib/mi-support.exp functionality, but I'm going to do that in a later
+ patch, this way it is clear what changes I'm actually proposing to
+ make to the expected output.
+
+ As I said, I hope that frontends will be able to handle this change,
+ but I still think its worth adding a NEWS entry, that way, if someone
+ runs into problems, there's a chance they can figure out what's going
+ on.
+
+ This should not impact CLI output at all.
+
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove an out of date comment about disp_del_at_next_stop
+ Delete an out of date comment about disp_del_at_next_stop, the comment
+ says:
+
+ /* NOTE drow/2003-09-08: This state only exists for removing
+ watchpoints. It's not clear that it's necessary... */
+
+ I'm sure this was true when the comment was added, but today the
+ disp_del_at_next_stop state is not just used for deleting watchpoints,
+ which leaves us with "It's not clear that it's necessary...", which
+ doesn't really help at all.
+
+ And then this comment is located on one random place where
+ disp_del_at_next_stop is used, rather than at its definition site.
+
+ Lets just delete the comment.
+
+ No user visible changes after this commit.
+
+ Reviewed-By: Pedro Alves <pedro@palves.net>
+
+2023-02-28 Richard Ball <richard.ball@arm.com>
+
+ [Aarch64] Add Binutils support for MEC
+ This change supports MEC which is part of RME (Realm Management Extension).
+
+2023-02-28 Alan Modra <amodra@gmail.com>
+
+ chew.c printf of intptr_t
+ Seen when building binutils with gcc -m32 on x86_64-linux.
+ chew.c: In function ‘print’:
+ chew.c:1434:59: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘intptr_t’ {aka ‘int’} [-Wformat=]
+ 1434 | fprintf (stderr, "print: illegal print destination `%ld'\n", *isp);
+ | ~~^ ~~~~
+ | | |
+ | | intptr_t {aka int}
+ | long int
+ | %d
+
+ * chew.c: Include inttypes.h.
+ (print): Use PRIdPTR for *isp.
+
+2023-02-28 Mark Harmstone <mark@harmstone.com>
+
+ ld: Sort section contributions in PDB files
+ Microsoft's DIA library, and thus also MSVC and WinDbg, expects section
+ contributions to be ordered by section number and offset, otherwise it's
+ unable to resolve line numbers.
+
+2023-02-28 Alan Modra <amodra@gmail.com>
+
+ Free ecoff debug info
+ This frees memory associated with the mips ecoff find_nearest_line.
+
+ * elfxx-mips.x (free_ecoff_debug): New function, extracted from..
+ (_bfd_mips_elf_read_ecoff_info): ..here. Free ext_hdr earlier.
+ Don't clear already NULL fdr.
+ (struct mips_elf_find_line): Move earlier.
+ (_bfd_mips_elf_close_and_cleanup): Call free_ecoff_debug.
+ (_bfd_mips_elf_find_nearest_line): Likewise on error paths,
+ and to clean up input_debug when done.
+
+2023-02-28 Alan Modra <amodra@gmail.com>
+
+ Add some sanity checking in ECOFF lookup_line
+ More anti-fuzzer bounds checking for the ECOFF support. A lot of this
+ is in ancient code using "long" for counts and sizes, which is why the
+ patch uses "(long) ((unsigned long) x + 1) > 0" in a few places. The
+ unsigned long cast is so that "x + 1" doesn't trigger ubsan warnings
+ about signed integer overflow. It would be a good idea to replace
+ most of the longs used in binutils with size_t, but that's more than I
+ care to do for COFF/ECOFF.
+
+ * ecofflink.c (mk_fdrtab): Sanity check string offsets.
+ (lookup_line): Likewise, and symbol indices.
+
+2023-02-28 Alan Modra <amodra@gmail.com>
+
+ Another PE SEC_HAS_CONTENTS test
+ I'd skipped this one before, thinking "obfd, that's the linker output
+ bfd so no need to test". Wrong, this is objcopy output.
+
+ * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Test
+ SEC_HAS_CONTENTS before reading section.
+
+2023-02-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Forced quit cases handled by resetting sync_quit_force_run
+ During my audit of the use of gdb_exception with regard to QUIT
+ processing, I found a try/catch in the scoped_switch_fork_info
+ destructor.
+
+ Static analysis found this call path from the destructor to
+ maybe_quit():
+
+ scoped_switch_fork_info::~scoped_switch_fork_info()
+ -> remove_breakpoints()
+ -> remove_breakpoint(bp_location*)
+ -> remove_breakpoint_1(bp_location*, remove_bp_reason)
+ -> memory_validate_breakpoint(gdbarch*, bp_target_info*)
+ -> target_read_memory(unsigned long, unsigned char*, long)
+ -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
+ -> maybe_quit()
+
+ Since it's not safe to do a 'throw' from a destructor, we simply
+ call set_quit_flag and, for gdb_exception_forced_quit, also
+ set sync_quit_force_run. This will cause the appropriate
+ exception to be rethrown at the next QUIT check.
+
+ Another case is the try / catch in tui_getc() in tui-io.c. The
+ existing catch swallows the exception. I've added a catch for
+ 'gdb_exception_forced_quit', which also swallows the exception,
+ but also sets sync_quit_force_run and calls set_quit_flag in
+ order to restart forced quit processing at the next QUIT check.
+ This is required because it isn't safe to throw into/through
+ readline.
+
+ Thanks to Pedro Alves for suggesting this idea.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Introduce set_force_quit_flag and change type of sync_quit_force_run
+ At the moment, handle_sigterm() in event-top.c does the following:
+
+ sync_quit_force_run = 1;
+ set_quit_flag ();
+
+ This was used several more times in a later patch in this series, so
+ I'm introducing (at Pedro's suggestion) a new function named
+ 'set_force_quit_flag'. It simply sets sync_quit_force_run and also
+ calls set_quit_flag(). I've revised the later patch to call
+ set_force_quit_flag instead.
+
+ I noticed that sync_quit_force_run is declared as an int but is being
+ used as a bool, so I also changed its type to bool in this commit.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ QUIT processing w/ explicit throw for gdb_exception_forced_quit
+ This commit contains changes which have an explicit throw for
+ gdb_exception_forced_quit, or, in a couple of cases for gdb_exception,
+ but with a throw following a check to see if 'reason' is
+ RETURN_FORCED_QUIT.
+
+ Most of these are straightforward - it made sense to continue to allow
+ an existing catch of gdb_exception to also catch gdb_exception_quit;
+ in these cases, a catch/throw for gdb_exception_forced_quit was added.
+
+ There are two cases, however, which deserve a more detailed
+ explanation.
+
+ 1) remote_fileio_request in gdb/remote-fileio.c:
+
+ The try block calls do_remote_fileio_request which can (in turn)
+ call one of the functions in remote_fio_func_map[]. Taking the
+ first one, remote_fileio_func_open(), we have the following call
+ path to maybe_quit():
+
+ remote_fileio_func_open(remote_target*, char*)
+ -> target_read_memory(unsigned long, unsigned char*, long)
+ -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
+ -> maybe_quit()
+
+ Since there is a path to maybe_quit(), we must ensure that the
+ catch block is not permitted to swallow a QUIT representing a
+ SIGTERM.
+
+ However, for this case, we must take care not to change the way that
+ Ctrl-C / SIGINT is handled; we want to send a suitable EINTR reply to
+ the remote target should that happen. That being the case, I added a
+ catch/throw for gdb_exception_forced_quit. I also did a bit of
+ rewriting here, adding a catch for gdb_exception_quit in favor of
+ checking the 'reason' code in the catch block for gdb_exception.
+
+ 2) mi_execute_command in gdb/mi/mi-main.c:
+
+ The try block calls captured_mi_execute_command(); there exists
+ a call path to maybe_quit():
+
+ captured_mi_execute_command(ui_out*, mi_parse*)
+ -> mi_cmd_execute(mi_parse*)
+ -> get_current_frame()
+ -> get_prev_frame_always_1(frame_info*)
+ -> frame_register_unwind_location(frame_info*, int, int*, lval_type*, unsigned long*, int*)
+ -> frame_register_unwind(frame_info*, int, int*, int*, lval_type*, unsigned long*, int*, unsigned char*)
+ -> value_entirely_available(value*)
+ -> value_fetch_lazy(value*)
+ -> value_fetch_lazy_memory(value*)
+ -> read_value_memory(value*, long, int, unsigned long, unsigned char*, unsigned long)
+ -> maybe_quit()
+
+ That being the case, we can't allow the exception handler (catch block)
+ to swallow a gdb_exception_quit for SIGTERM. However, it does seem
+ reasonable to output the exception via the mi interface so that some
+ suitable message regarding SIGTERM might be printed; therefore, I
+ check the exception's 'reason' field for RETURN_FORCED_QUIT and
+ do a throw for this case.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Guile QUIT processing updates
+ This commit contains QUIT processing updates for GDB's Guile support.
+ As with the Python updates, we don't want to permit this code to
+ swallow the exception, gdb_exception_forced_quit, which is associated
+ with GDB receiving a SIGTERM.
+
+ I've adopted the same solution that I used for Python; whereever
+ a gdb_exception is caught in try/catch code in the Guile extension
+ language support, a catch for gdb_exception_forced_quit has been
+ added; this catch block will simply call quit_force(), which will
+ cause the necessary cleanups to occur followed by GDB exiting.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Python QUIT processing updates
+ See the previous patches in this series for the motivation behind
+ these changes.
+
+ This commit contains updates to Python's QUIT handling. Ideally, we'd
+ like to throw gdb_exception_forced_quit through the extension
+ language; I made an attempt to do this for gdb_exception_quit in an
+ earlier version of this patch, but Pedro pointed out that it is
+ (almost certainly) not safe to do so.
+
+ Still, we definitely don't want to swallow the exception representing
+ a SIGTERM for GDB, nor do we want to force modules written in the
+ extension language to have to explicitly handle this case. Since the
+ idea is for GDB to cleanup and quit for this exception, we'll simply
+ call quit_force() just as if the gdb_exception_forced_quit propagation
+ had managed to make it back to the top level.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Catch gdb_exception_error instead of gdb_exception (in many places)
+ As described in the previous commit for this series, I became
+ concerned that there might be instances in which a QUIT (due to either
+ a SIGINT or SIGTERM) might not cause execution to return to the top
+ level. In some (though very few) instances, it is okay to not
+ propagate the exception for a Ctrl-C / SIGINT, but I don't think that
+ it is ever okay to swallow the exception caused by a SIGTERM.
+ Allowing that to happen would definitely be a deviation from the
+ current behavior in which GDB exits upon receipt of a SIGTERM.
+
+ I looked at all cases where an exception handler catches a
+ gdb_exception. Handlers which did NOT need modification were those
+ which satisifed one or more of the following conditions:
+
+ 1) There is no call path to maybe_quit() in the try block. I used a
+ static analysis tool to help make this determination. In
+ instances where the tool didn't provide an answer of "yes, this
+ call path can result in maybe_quit() being called", I reviewed it
+ by hand.
+
+ 2) The catch block contains a throw for conditions that it
+ doesn't want to handle; these "not handled" conditions
+ must include the quit exception and the new "forced quit" exception.
+
+ 3) There was (also) a catch for gdb_exception_quit.
+
+ Any try/catch blocks not meeting the above conditions could
+ potentially swallow a QUIT exception.
+
+ My first thought was to add catch blocks for gdb_exception_quit and
+ then rethrow the exception. But Pedro pointed out that this can be
+ handled without adding additional code by simply catching
+ gdb_exception_error instead. That's what this patch series does.
+
+ There are some oddball cases which needed to be handled differently,
+ plus the extension languages, but those are handled in later patches.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-by: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit
+ When a GDB process receives the SIGTERM signal, handle_sigterm() in
+ event-top.c is called. The global variable 'sync_quit_force_run' is
+ set by this signal handler. It does some other things too, but the
+ setting of this global is the important bit for the SIGTERM part of
+ this discussion.
+
+ GDB will periodically check to see whether a Ctrl-C or SIGTERM has
+ been received. This is performed via use of the QUIT macro in
+ GDB's code. QUIT is defined to invoke maybe_quit(), which will be
+ periodically called during any lengthy operation. This is supposed to
+ ensure that the user won't have to wait too long for a Ctrl-C or
+ SIGTERM to be acted upon.
+
+ When a Ctrl-C / SIGINT is received, quit_handler() will decide whether
+ to pass the SIGINT onto the inferior or to call quit() which causes
+ gdb_exception_quit to be thrown. This exception (usually) propagates
+ to the top level. Control is then returned to the top level event
+ loop.
+
+ At the moment, SIGTERM is handled very differently. Instead of
+ throwing an exception, quit_force() is called. This does eventually
+ cause GDB to exit(), but prior to that happening, the inferiors
+ are killed or detached and other target related cleanup occurs.
+ As shown in this discussion between Pedro Alves and myself...
+
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180802.html
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180902.html
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180903.html
+
+ ...we found that it is possible for inferior_ptid and current_thread_
+ to get out of sync. When that happens, the "current_thread_ != nullptr"
+ assertion in inferior_thread() can fail resulting in a GDB internal
+ error.
+
+ Pedro recommended that we "let the normal quit exception propagate all
+ the way to the top level, and then have the top level call quit_force
+ if sync_quit_force_run is set." However, after the v2 series for this
+ patch set, we tweaked that idea by introducing a new exception for
+ handling SIGTERM.
+
+ This commit implements the obvious part of Pedro's suggestion:
+ Instead of calling quit_force from quit(), throw_forced_quit() is now
+ called instead. This causes the new exception 'gdb_exception_forced_quit'
+ to be thrown.
+
+ At the top level, I changed catch_command_errors() and captured_main()
+ to catch gdb_exception_forced_quit and then call quit_force() from the
+ catch block. I also changed start_event_loop() to also catch
+ gdb_exception_forced_quit; while we could also call quit_force() from
+ that catch block, it's sufficient to simply rethrow the exception
+ since it'll be caught by the newly added code in captured_main().
+
+ Making these changes fixed the failure / regression that I was seeing
+ for gdb.base/gdb-sigterm.exp when run on a machine with glibc-2.34.
+ However, there are many other paths back to the top level which this
+ test case does not test. I did an audit of all of the try / catch
+ code in GDB in which calls in the try-block might (eventually) call
+ QUIT. I found many cases where gdb_exception_quit and the new
+ gdb_exception_forced_quit will be swallowed. (When using GDB, have
+ you ever hit Ctrl-C and not have it do anything; if so, it could be
+ due to a swallowed gdb_exception_quit in one of the cases I've
+ identified.) The rest of the patches in this series deal with this
+ concern.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-by: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Kevin Buettner <kevinb@redhat.com>
+
+ Introduce gdb_exception_forced_quit
+ This commit adds a new exception 'gdb_exception_forced_quit', reason
+ code 'REASON_FORCED_QUIT', return mask 'RETURN_MASK_FORCED_QUIT', and
+ a wrapper for throwing the exception, throw_forced_quit().
+
+ The addition of this exception plus supporting code will allow us to
+ recognize that a SIGTERM has been received by GDB and then propagate
+ recognition of that fact to the upper levels of GDB where it can be
+ correctly handled. At the moment, when GDB receives a SIGTERM, it
+ will attempt to exit via a series of calls from the QUIT checking
+ code. However, before it can exit, it must do various cleanups, such
+ as killing or detaching all inferiors. Should these cleanups be
+ attempted while GDB is executing very low level code, such as reading
+ target memory from within ps_xfer_memory(), it can happen that some of
+ GDB's state is out of sync with regard to the cleanup code's
+ expectations. In the case just mentioned, it's been observed that
+ inferior_ptid and the current_thread_ are not in sync; this triggers
+ an assert / internal error.
+
+ This commit only introduces the exception plus supporting machinery;
+ changes which use this new exception are in later commits in this
+ series.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
+ Tested-by: Tom de Vries <tdevries@suse.de>
+ Approved-by: Pedro Alves <pedro@palves.net>
+
+2023-02-27 Tom Tromey <tom@tromey.com>
+
+ Fix value chain use-after-free
+ Hannes filed a bug showing a crash, where a pretty-printer written in
+ Python could cause a use-after-free. He sent a patch, but I thought a
+ different approach was needed.
+
+ In a much earlier patch (see bug #12533), we changed the Python code
+ to release new values from the value chain when constructing a
+ gdb.Value. The rationale for this is that if you write a command that
+ does a lot of computations in a loop, all the values will be kept live
+ by the value chain, resulting in gdb using a large amount of memory.
+
+ However, suppose a value is passed to Python from some code in gdb
+ that needs to use the value after the call into Python. In this
+ scenario, value_to_value_object will still release the value -- and
+ because gdb code doesn't generally keep strong references to values (a
+ consequence of the ancient decision to use the value chain to avoid
+ memory management), this will result in a use-after-free.
+
+ This scenario can happen, as it turns out, when a value is passed to
+ Python for pretty-printing. Now, normally this route boxes the value
+ via value_to_value_object_no_release, avoiding the problematic release
+ from the value chain. However, if you then call Value.cast, the
+ underlying value API might return the same value, when is then
+ released from the chain.
+
+ This patch fixes the problem by changing how value boxing is done.
+ value_to_value_object no longer removes a value from the chain.
+ Instead, every spot in gdb that might construct new values uses a
+ scoped_value_mark to ensure that the requirements of bug #12533 are
+ met. And, because incoming values aren't ever released from the chain
+ (the Value.cast one comes earlier on the chain than the
+ scoped_value_mark), the bug can no longer occur. (Note that many
+ spots in the Python layer already take this approach, so not many
+ places needed to be touched.)
+
+ In the future I think we should replace the use of raw "value *" with
+ value_ref_ptr pretty much everywhere. This will ensure lifetime
+ safety throughout gdb.
+
+ The test case in this patch comes from Hannes' original patch. I only
+ made a trivial ("require") change to it. However, while this fails
+ for him, I can't make it fail on this machine; nevertheless, he tried
+ my patch and reported the bug as being fixed.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30044
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Remove infrun_thread_thread_exit observer
+ After the previous patches, I believe this observer isn't necessary
+ anymore for anything. Remove it.
+
+ Change-Id: Idb33fb6b6f55589c8c523a92169b3ca95a23d0b9
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ all-stop "follow-fork parent" and selecting another thread
+ With:
+
+ - catch a fork in thread 1
+ - select thread 2
+ - set follow-fork child
+ - next
+
+ ... follow_fork notices that thread 1 had last stopped for a fork
+ which hasn't been followed yet, and because thread 1 is not the
+ current thread, GDB aborts the execution command, presenting the stop
+ in thread 1.
+
+ That makes sense, as only the forking thread (thread 1) survives in
+ the child, so better stop and let the user decide how to proceed.
+
+ However, with:
+
+ - catch a fork in thread 1
+ - select thread 2
+ - set follow-fork parent << note difference here
+ - next
+
+ ... GDB does the same: follow_fork notices that thread 1 had last
+ stopped for a fork which hasn't been followed yet, and because thread
+ 1 is not the current thread, GDB aborts the execution command,
+ presenting the stop in thread 1.
+
+ Aborting/stopping in this case doesn't make sense to me. As we're
+ following the parent, thread 2 will still continue to exist in the
+ parent. What the child does after we've followed the parent shouldn't
+ matter -- it can go on running free, be detached, etc., depending on
+ "set schedule-multiple", "set detach-on-fork", etc. That does not
+ influence the execution command that the user issued for the parent
+ thread.
+
+ So this patch changes GDB in that direction -- in follow_fork, if
+ following the parent, and we've switched threads meanwhile, switch
+ back to the unfollowed thread, follow it (stay with the parent), and
+ don't abort/stop. If we're following a fork (as opposed to vfork),
+ then switch back again to the thread that the user was trying to
+ resume. If following a vfork, however, stay with the vforking-thread
+ selected, as we will need to see a vfork_done event first, before we
+ can resume any other thread.
+
+ As I was working on this, I managed to end up calling target_resume
+ for a solo-thread resume (to collect the vfork_done event), with
+ scope_ptid pointing at the vfork parent thread, and inferior_ptid
+ pointing to the vfork child. For a solo-thread resume, the scope_ptid
+ argument to target_resume must the same as inferior_ptid. The mistake
+ was caught by the assertion in target_resume, like so:
+
+ ...
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [1722839.1722839.0] at 0x5555555553c3
+ [infrun] do_target_resume: resume_ptid=1722839.1722939.0, step=0, sig=GDB_SIGNAL_0
+ ../../src/gdb/target.c:2661: internal-error: target_resume: Assertion `inferior_ptid.matches (scope_ptid)' failed.
+ ...
+
+ but I think it doesn't hurt to catch such a mistake earlier, hence the
+ change in internal_resume_ptid.
+
+ Change-Id: I896705506a16d2488b1bfb4736315dd966f4e412
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Make follow_fork not rely on get_last_target_status
+ Currently, if
+
+ - you're in all-stop mode,
+ - the inferior last stopped because of a fork catchpoint,
+
+ when you next resume the program, gdb checks whether it had last
+ stopped for a fork/vfork, and if so,
+
+ a) if the current thread is the one that forked, gdb follows the
+ parent/child, depending on "set follow-fork" mode.
+
+ b) if the current thread is some other thread (because you switched
+ threads meanwhile), gdb switches back to that thread, gdb follows
+ the parent/child, and stops the resumption command.
+
+ There's a problem in b), however -- if you have "set schedule-multiple
+ off", which is the default, or "set scheduler-locking on", gdb will
+ still switch back to the forking thread, even if you didn't want to
+ resume it. For example, with:
+
+ (gdb) catch fork
+ (gdb) c
+ * thread 1 stops for fork
+ (gdb) thread 2
+ (gdb) set scheduler-locking on
+ (gdb) c
+
+ gdb switches back to thread 1, and follows the fork.
+
+ Or with:
+
+ (gdb) add-inferior -exec prog
+ (gdb) inferior 2
+ (gdb) start
+ (gdb) inferior 1
+ (gdb) catch fork
+ (gdb) c
+ * thread 1.1 stops for fork
+ (gdb) inferior 2
+ (gdb) set schedule-multiple off # this is the default
+ (gdb) c
+
+ gdb switches back to thread 1.1, and follows the fork.
+
+ Another issue is that, because follow_fork relies on
+ get_last_target_status to find the thread that has a pending fork, it
+ is possible to confuse it. For example, "run" or "start" call
+ init_wait_for_inferior, which clears the last target status, so this:
+
+ (gdb) catch fork
+ (gdb) c
+ * thread 1 stops for fork
+ (gdb) add-inferior -exec prog
+ (gdb) inferior 2
+ (gdb) start
+ (gdb) set follow-fork child
+ (gdb) inferior 1
+ (gdb) n
+
+ ... does not follow to the fork child of inferior 1, because the
+ get_last_target_status call in follow_fork doesn't return a
+ TARGET_WAITKIND_FORKED. Thanks to Simon for this example.
+
+ All of the above are fixed by this patch. It changes follow_fork to
+ not look at get_last_target_status, but to instead iterate over the
+ set of threads that the user is resuming, and find the one that has a
+ pending_follow kind of fork/vfork.
+
+ gdb.base/foll-fork.exp is augmented to exercise the last "start"
+ scenario described above. The other cases will be exercised in the
+ testcase added by the following patch.
+
+ Change-Id: Ifcca77e7b2456277387f40660ef06cec2b93b97e
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Improve "info program"
+ With gdb.base/catch-follow-exec.exp, we currently see:
+
+ ~~~~~~~~~~~~~~~
+ (gdb)
+ continue
+ Continuing.
+ process 693251 is executing new program: /usr/bin/ls
+ [New inferior 2]
+ [New process 693251]
+ [Switching to process 693251]
+
+ Thread 2.1 "ls" hit Catchpoint 2 (exec'd /usr/bin/ls), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2
+ (gdb)
+ info prog
+ No selected thread.
+ ~~~~~~~~~~~~~~~
+
+ Note the "No selected thread" output. That is totally bogus, because
+ there _is_ a selected thread. What GDB really means, is that it can't
+ find the thread that had the latest (user-visible) stop. And that
+ happens because "info program" gets that info from
+ get_last_target_status, and the last target status has been cleared.
+
+ However, GDB also checks if there is a selected thread, here:
+
+ if (ptid == null_ptid || ptid == minus_one_ptid)
+ error (_("No selected thread."));
+
+ .. the null_ptid part. That is also bogus, because what matters is
+ the thread that last reported a stop, not the current thread:
+
+ - in all-stop mode, "info program" displays info about the last stop.
+ That may have happened on a thread different from the selected
+ thread.
+
+ - in non-stop mode, because all threads are controlled individually,
+ "info program" shows info about the last stop of the selected
+ thread.
+
+ The current code already behaves this way, though in a poor way. This
+ patch reimplements it, such that the all-stop version now finds the
+ thread that last reported an event via the 'previous_thread' strong
+ reference. Being a strong reference means that if that thread has
+ exited since the event was reported, 'previous_thread' will still
+ point to it, so we can say that the thread exited meanwhile.
+
+ The patch also extends "info program" output a little, to let the user
+ know which thread we are printing info for. For example, for the
+ gdb.base/catch-follow-exec.exp case we shown above, we now get:
+
+ (gdb) info prog
+ Last stopped for thread 2.1 (process 710867).
+ Using the running image of child process 710867.
+ Program stopped at 0x7ffff7fd0100.
+ It stopped at breakpoint 2.
+ Type "info stack" or "info registers" for more information.
+ (gdb)
+
+ while in non-stop mode, we get:
+
+ (gdb) info prog
+ Selected thread 2.1 (process 710867).
+ Using the running image of child process 710867.
+ Program stopped at 0x7ffff7fd0100.
+ It stopped at breakpoint 2.
+ Type "info stack" or "info registers" for more information.
+ (gdb)
+
+ In both cases, the first line of output is new.
+
+ The existing code considered these running/exited cases as an error,
+ but I think that that's incorrect, since this is IMO just plain
+ execution info as well. So the patch makes those cases regular
+ prints, not errors.
+
+ If the thread is running, we get, in non-stop mode:
+
+ (gdb) info prog
+ Selected thread 2.1 (process 710867).
+ Selected thread is running.
+
+ ... and in all-stop:
+
+ (gdb) info prog
+ Last stopped for thread 2.1 (process 710867).
+ Thread is now running.
+
+ If the thread has exited, we get, in non-stop mode:
+
+ (gdb) info prog
+ Selected thread 2.1 (process 710867).
+ Selected thread has exited.
+
+ ... and in all-stop:
+
+ (gdb) info prog
+ Last stopped for thread 2.1 (process 710867).
+ Thread has since exited.
+
+ The gdb.base/info-program.exp testcase was much extended to test
+ all-stop/non-stop and single-threaded/multi-threaded.
+
+ Change-Id: I51d9d445f772d872af3eead3449ad4aa445781b1
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Convert previous_inferior_ptid to strong reference to thread_info
+ I originally wrote this patch, because while working on some other
+ patch, I spotted a regression in the
+ gdb.multi/multi-target-no-resumed.exp.exp testcase. Debugging the
+ issue, I realized that the problem was related to how I was using
+ previous_inferior_ptid to look up the thread the user had last
+ selected. The problem is that previous_inferior_ptid alone doesn't
+ tell you which target that ptid is from, and I was just always using
+ the current target, which was incorrect. Two different targets may
+ have threads with the same ptid.
+
+ I decided to fix this by replacing previous_inferior_ptid with a
+ strong reference to the thread, called previous_thread.
+
+ I have since found a new motivation for this change -- I would like to
+ tweak "info program" to not rely on get_last_target_status returning a
+ ptid that still exists in the thread list. With both the follow_fork
+ changes later in this series, and the step-over-thread-exit changes,
+ that can happen, as we'll delete threads and not clear the last
+ waitstatus.
+
+ A new update_previous_thread function is added that can be used to
+ update previous_thread from inferior_ptid. This must be called in
+ several places that really want to get rid of previous_thread thread,
+ and reset the thread id counter, otherwise we get regressions like
+ these:
+
+ (gdb) info threads -gid
+ Id GId Target Id Frame
+ - * 1 1 Thread 2974541.2974541 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
+ - (gdb) PASS: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid
+ + * 1 2 Thread 2958361.2958361 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21
+ + (gdb) FAIL: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid
+
+ and:
+
+ Core was generated by `build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/si'.
+ Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+ #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
+ 398 kill (getpid (), SIGABRT);
+ +[Current thread is 1 (LWP 2662066)]
+ Restored records from core file build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/sigall.precsave.
+ #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398
+ 398 kill (getpid (), SIGABRT);
+
+ continue
+ Continuing.
+
+ -Program received signal SIGABRT, Aborted.
+ +Thread 1 received signal SIGABRT, Aborted.
+ 0x00007ffff7dfd55b in kill () at ../sysdeps/unix/syscall-template.S:78
+ 78 ../sysdeps/unix/syscall-template.S: No such file or directory.
+ -(gdb) PASS: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT
+ +(gdb) FAIL: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT
+
+ I.e., GDB was failing to restart the thread counter back to 1, because
+ the previous_thread thread was being help due to the strong reference.
+
+ Tested on GNU/Linux native, gdbserver and gdbserver + "maint set
+ target-non-stop on".
+
+ gdb/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ * infcmd.c (kill_command, detach_command, disconnect_command):
+ Call update_previous_thread.
+ * infrun.c (previous_inferior_ptid): Delete.
+ (previous_thread): New.
+ (update_previous_thread): New.
+ (proceed, init_wait_for_inferior): Call update_previous_thread.
+ (normal_stop): Adjust to compare previous_thread and
+ inferior_thread. Call update_previous_thread.
+ * infrun.h (update_previous_thread): Declare.
+ * target.c (target_pre_inferior, target_preopen): Call
+ update_previous_thread.
+
+ Change-Id: I42779a1ee51a996fa1e8f6e1525c6605dbfd42c7
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Tweak "Using the running image of ..." output
+ Currently, "info files" and "info program" on a few native targets
+ show:
+
+ (gdb) info files
+ Symbols from "/home/pedro/gdb/tests/threads".
+ Native process:
+ Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ ...
+
+ (gdb) info program
+ Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968).
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ Program stopped at 0x555555555278.
+ ...
+
+
+ This patch changes them to:
+
+ (gdb) info files
+ Symbols from "/home/pedro/gdb/tests/threads".
+ Native process:
+ Using the running image of child process 1097968.
+ ^^^^^^^^^^^^^^^
+ ...
+
+ (gdb) info program
+ Using the running image of child process 1097968.
+ ^^^^^^^^^^^^^^^
+ Program stopped at 0x555555555278.
+ ...
+
+
+ ... which I think makes a lot more sense in this context. The "info
+ program" manual entry even says:
+
+ "Display information about the status of your program: whether it is
+ running or not, what process it is, and why it stopped."
+ ^^^^^^^^^^^^^
+
+ This change affects ptrace targets, procfs targets, and Windows.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I6aab061ff494a84ba3398cf98fd49efd7a6ec1ca
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make-target-delegates.py: add type annotations
+ Fixes all warnings given by pyright.
+
+ Change-Id: I480521bfc62960c4eccd9d32c886392b05a1ddaa
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make-target-delegates.py: add Entry type
+ Add the Entry type and use it in the `entries` map, rather than using an
+ ad-hoc str -> str map that comes from the re.match. This will make it
+ easier to make typing work in a subsequent patch, but it also helps
+ readers know what attributes exist for entries, which is not clear
+ currently.
+
+ Change-Id: I5b58dee1ed7ae85987b99bd417e641ede718624c
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make-target-delegates.py: make one string raw
+ Fixes the following flake8 warning:
+
+ make-target-delegates.py:36:39: W605 invalid escape sequence '\s'
+
+ Change-Id: I25eeb296f55765e17e5217a2d1e49018f63a3acd
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: gdbarch*.py, copyright.py: add type annotations
+ Add type annotations to gdbarch*.py to fix all errors shown by pyright.
+ There is one change in copyright.py too, to fix this one:
+
+ /home/simark/src/binutils-gdb/gdb/gdbarch.py
+ /home/simark/src/binutils-gdb/gdb/gdbarch.py:206:13 - error: Type of "copyright" is partially unknown
+ Type of "copyright" is "(tool: Unknown, description: Unknown) -> str" (reportUnknownMemberType)
+
+ Change-Id: Ia109b53e267f6e2f5bd79a1288d0d5c9508c9ac4
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: split gdbarch component types to gdbarch_types.py
+ Editing gdbarch-components.py is not an experience in an editor that is
+ minimally smart about Python. Because gdbarch-components.py is read and
+ exec'd by gdbarch.py, it doesn't import the Info / Method / Function /
+ Value types. And because these types are defined in gdbarch.py, it
+ can't import them, as that would make a cyclic dependency.
+
+ Solve this by introducing a third file, gdbarch_types.py, to define
+ these types. Make gdbarch.py and gdbarch-components.py import it.
+ Also, replace the read & exec of gdbarch-components.py by a regular
+ import. For this to work though, gdbarch-components.py needs to be
+ renamed to gdbarch_components.py.
+
+ Change-Id: Ibe994d56ef9efcc0698b3ca9670d4d9bf8bbb853
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: pyproject.toml: set pyright typeCheckingMode = "strict"
+ While working on other projects, I found the pyright type checker very
+ helpful when editing Python code. I don't think I have to explain the
+ advantages of type checking to a crowd used to C/C++.
+
+ Setting typeCheckingMode to "strict" makes pyright flag a bit more type
+ issues than the default of "basic".
+
+ Change-Id: I38818ec59f7f73c2ab020cc9226286cdd485abc7
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: gdbarch.py: remove Info.__init__
+ Info.__init__ currently assigns `self.predicate = None`. This was
+ helpful to ensure that all component types had a `predicate` attribute.
+ The generator code could then avoid having code like "if the component
+ is anything but Info, use predicate". Since the previous commit, all
+ component types have a predicate attribute which defaults to False. We
+ can therefore remove the assignment in Info.__init__, and in turn remove
+ Info.__init__. We however need to make the printer parameter of
+ _Component.__init__ optional, as Info don't need a printer.
+
+ Change-Id: I611edeca9cc9837eb49dddfe038595e1ff3b7239
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: gdbarch.py: spell out parameters of _Component.__init__
+ The way _Component uses kwargs is handy to save a few characters, but it
+ doesn't play well with static analysis. When editing gdbarch.py, my
+ editor (which uses pylance under the hood) knows nothing about the
+ properties of components. So it's full of squiggly lines, and typing
+ analysis (which I find really helpful) doesn't work. I therefore think
+ it would be better to spell out the parameters.
+
+ Change-Id: Iaf561beb0d0fbe170ce1c79252a291e0945e1830
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: reformat Python files with black 23.1.0
+ Change-Id: Ie8ec8870a16d71c5858f5d08958309d23c318302
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove invalid / dead code from gdbarch.py
+ My editor flagged that the variable `c` (in the lines removed by this
+ patch) was unknown. I guess it ends up working because there is a `c`
+ variable in the global scope. I tried putting `assert False` inside
+ that if, and it is not hit, showing that we never enter this if. So,
+ remove it. There is no change in the generated files.
+
+ Change-Id: Id3b9f67719e88cada7c6fde673c8d7842ab13617
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-27 Tom Tromey <tom@tromey.com>
+
+ Fix crash with "finish" in Rust
+ PR rust/30090 points out that a certain "finish" in a Rust program
+ will cause gdb to crash. This happens due to some confusion about
+ field indices in rust_language::print_enum. The fix is to use
+ value_primitive_field so that the correct type can be passed; other
+ spots in rust-lang.c already do this.
+
+ Note that the enclosed test case comes with an xfail. This is needed
+ because for this function, rustc doesn't follow the platform ABI.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30090
+
+2023-02-27 Tom Tromey <tom@tromey.com>
+
+ Remove old GNU indent directives
+ Now that gdb_indent.sh has been removed, I think it makes sense to
+ also remove the directives intended for GNU indent.
+
+2023-02-27 Tom Tromey <tromey@adacore.com>
+
+ Handle range types in ax-gdb.c
+ A range type can usually be treated the same as its underlying integer
+ type, at least for the purposes of agent expressions. This patch
+ arranges for range types to be handled this way in ax-gdb.c, letting a
+ somewhat larger subset of Ada expressions be compiled.
+
+2023-02-27 Tom Tromey <tromey@adacore.com>
+
+ Implement some agent expressions for Ada
+ Ada historically has not implemented agent expressions, and some Ada
+ constructs probably cannot reasonably be converted to agent
+ expressions. However, a subset of simple operations can be, and this
+ patch represents a first step in that direction.
+
+ On one internal AdaCore test case, this improves the performance of a
+ conditional breakpoint from 5 minutes to 5 seconds.
+
+ The main tricky part in this patch is ensuring the converted
+ expressions detect the cases that will not work. This is done by
+ examining the code in the corresponding evaluation methods.
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Regenerate Linux syscall group info
+ This commit makes use of the new script to regenerate the Linux
+ syscall group info against strace git hash
+ e88e5e9ae6da68f22d15f9be3193b1412ac9aa02.
+
+ Like so:
+
+ $ cd gdb/syscalls/
+ $ ./update-linux-defaults.sh ~/strace.git/
+ Generating linux-defaults.xml.in
+ $ make
+ for f in aarch64-linux.xml amd64-linux.xml arm-linux.xml bfin-linux.xml \
+ i386-linux.xml mips-n32-linux.xml mips-n64-linux.xml \
+ mips-o32-linux.xml ppc64-linux.xml ppc-linux.xml s390-linux.xml \
+ s390x-linux.xml sparc64-linux.xml sparc-linux.xml; do \
+ xsltproc --output $f apply-defaults.xsl $f.in; \
+ done
+
+ The result is that a lot more syscalls end up assigned to groups.
+ Some lose their group info, but that just mirrors what strace does.
+
+ The gdb/syscalls/linux-defaults.xml.in file shows a large diff because
+ the new version is ASCII sorted, while the current version was
+ somewhat (but not consistently) sorted by "family" of syscalls.
+
+ If I sort the old file and diff against the new, the difference is
+ like this:
+
+ <syscall name="accept4" groups="network"/>
+ <syscall name="accept" groups="network"/>
+ <syscall name="access" groups="file"/>
+ <syscall name="acct" groups="file"/>
+ - <syscall name="arch_prctl" groups="process"/>
+ <syscall name="bind" groups="network"/>
+ + <syscall name="bpf" groups="descriptor"/>
+ <syscall name="break" groups="memory"/>
+ <syscall name="brk" groups="memory"/>
+ + <syscall name="bsd43_fstatfs" groups="descriptor"/>
+ + <syscall name="bsd43_fstat" groups="descriptor"/>
+ + <syscall name="bsd43_killpg" groups="process"/>
+ + <syscall name="bsd43_kill" groups="process"/>
+ + <syscall name="bsd43_lstat" groups="file"/>
+ + <syscall name="bsd43_madvise" groups="memory"/>
+ + <syscall name="bsd43_mincore" groups="memory"/>
+ + <syscall name="bsd43_mmap" groups="descriptor,memory"/>
+ + <syscall name="bsd43_mprotect" groups="memory"/>
+ + <syscall name="bsd43_mremap" groups="memory"/>
+ + <syscall name="bsd43_munmap" groups="memory"/>
+ + <syscall name="bsd43_oldfstat" groups="descriptor"/>
+ + <syscall name="bsd43_oldstat" groups="file"/>
+ + <syscall name="bsd43_quotactl" groups="file"/>
+ + <syscall name="bsd43_sbreak" groups="memory"/>
+ + <syscall name="bsd43_sbrk" groups="memory"/>
+ + <syscall name="bsd43_statfs" groups="file"/>
+ + <syscall name="bsd43_stat" groups="file"/>
+ + <syscall name="cacheflush" groups="memory"/>
+ <syscall name="chdir" groups="file"/>
+ <syscall name="chmod" groups="file"/>
+ <syscall name="chown32" groups="file"/>
+ <syscall name="chown" groups="file"/>
+ <syscall name="chroot" groups="file"/>
+ + <syscall name="clone2" groups="process"/>
+ + <syscall name="clone3" groups="process"/>
+ <syscall name="clone" groups="process"/>
+ <syscall name="close" groups="descriptor"/>
+ <syscall name="connect" groups="network"/>
+ + <syscall name="copy_file_range" groups="descriptor"/>
+ <syscall name="creat" groups="descriptor,file"/>
+ <syscall name="dup2" groups="descriptor"/>
+ <syscall name="dup3" groups="descriptor"/>
+ @@ -28,14 +52,17 @@
+ <syscall name="epoll_create1" groups="descriptor"/>
+ <syscall name="epoll_create" groups="descriptor"/>
+ <syscall name="epoll_ctl" groups="descriptor"/>
+ + <syscall name="epoll_pwait2" groups="descriptor"/>
+ <syscall name="epoll_pwait" groups="descriptor"/>
+ <syscall name="epoll_wait" groups="descriptor"/>
+ <syscall name="eventfd2" groups="descriptor"/>
+ <syscall name="eventfd" groups="descriptor"/>
+ + <syscall name="execveat" groups="descriptor,file,process"/>
+ <syscall name="execve" groups="file,process"/>
+ <syscall name="execv" groups="file,process"/>
+ <syscall name="exit_group" groups="process"/>
+ <syscall name="exit" groups="process"/>
+ + <syscall name="faccessat2" groups="descriptor,file"/>
+ <syscall name="faccessat" groups="descriptor,file"/>
+ <syscall name="fadvise64_64" groups="descriptor"/>
+ <syscall name="fadvise64" groups="descriptor"/>
+ @@ -57,7 +84,11 @@
+ <syscall name="flock" groups="descriptor"/>
+ <syscall name="fork" groups="process"/>
+ <syscall name="fremovexattr" groups="descriptor"/>
+ + <syscall name="fsconfig" groups="descriptor,file"/>
+ <syscall name="fsetxattr" groups="descriptor"/>
+ + <syscall name="fsmount" groups="descriptor"/>
+ + <syscall name="fsopen" groups="descriptor"/>
+ + <syscall name="fspick" groups="descriptor,file"/>
+ <syscall name="fstat64" groups="descriptor"/>
+ <syscall name="fstatat64" groups="descriptor,file"/>
+ <syscall name="fstatfs64" groups="descriptor"/>
+ @@ -72,16 +103,26 @@
+ <syscall name="getdents" groups="descriptor"/>
+ <syscall name="get_mempolicy" groups="memory"/>
+ <syscall name="getpeername" groups="network"/>
+ + <syscall name="getpmsg" groups="network"/>
+ <syscall name="getsockname" groups="network"/>
+ <syscall name="getsockopt" groups="network"/>
+ <syscall name="getxattr" groups="file"/>
+ - <syscall name="inotify_add_watch" groups="descriptor"/>
+ + <syscall name="inotify_add_watch" groups="descriptor,file"/>
+ <syscall name="inotify_init1" groups="descriptor"/>
+ <syscall name="inotify_init" groups="descriptor"/>
+ <syscall name="inotify_rm_watch" groups="descriptor"/>
+ <syscall name="ioctl" groups="descriptor"/>
+ + <syscall name="io_destroy" groups="memory"/>
+ + <syscall name="io_setup" groups="memory"/>
+ + <syscall name="io_uring_enter" groups="descriptor,signal"/>
+ + <syscall name="io_uring_register" groups="descriptor,memory"/>
+ + <syscall name="io_uring_setup" groups="descriptor"/>
+ <syscall name="ipc" groups="ipc"/>
+ - <syscall name="kill" groups="signal"/>
+ + <syscall name="kexec_file_load" groups="descriptor"/>
+ + <syscall name="kill" groups="signal,process"/>
+ + <syscall name="landlock_add_rule" groups="descriptor"/>
+ + <syscall name="landlock_create_ruleset" groups="descriptor"/>
+ + <syscall name="landlock_restrict_self" groups="descriptor"/>
+ <syscall name="lchown32" groups="file"/>
+ <syscall name="lchown" groups="file"/>
+ <syscall name="lgetxattr" groups="file"/>
+ @@ -98,19 +139,31 @@
+ <syscall name="lstat" groups="file"/>
+ <syscall name="madvise" groups="memory"/>
+ <syscall name="mbind" groups="memory"/>
+ + <syscall name="memfd_create" groups="descriptor"/>
+ + <syscall name="memfd_secret" groups="descriptor"/>
+ <syscall name="migrate_pages" groups="memory"/>
+ <syscall name="mincore" groups="memory"/>
+ <syscall name="mkdirat" groups="descriptor,file"/>
+ <syscall name="mkdir" groups="file"/>
+ <syscall name="mknodat" groups="descriptor,file"/>
+ <syscall name="mknod" groups="file"/>
+ + <syscall name="mlock2" groups="memory"/>
+ <syscall name="mlockall" groups="memory"/>
+ <syscall name="mlock" groups="memory"/>
+ <syscall name="mmap2" groups="descriptor,memory"/>
+ <syscall name="mmap" groups="descriptor,memory"/>
+ + <syscall name="mount_setattr" groups="descriptor,file"/>
+ <syscall name="mount" groups="file"/>
+ + <syscall name="move_mount" groups="descriptor,file"/>
+ <syscall name="move_pages" groups="memory"/>
+ <syscall name="mprotect" groups="memory"/>
+ + <syscall name="mq_getsetattr" groups="descriptor"/>
+ + <syscall name="mq_notify" groups="descriptor"/>
+ + <syscall name="mq_open" groups="descriptor"/>
+ + <syscall name="mq_timedreceive" groups="descriptor"/>
+ + <syscall name="mq_timedreceive_time64" groups="descriptor"/>
+ + <syscall name="mq_timedsend" groups="descriptor"/>
+ + <syscall name="mq_timedsend_time64" groups="descriptor"/>
+ <syscall name="mremap" groups="memory"/>
+ <syscall name="msgctl" groups="ipc"/>
+ <syscall name="msgget" groups="ipc"/>
+ @@ -126,45 +179,98 @@
+ <syscall name="oldfstat" groups="descriptor"/>
+ <syscall name="oldlstat" groups="file"/>
+ <syscall name="oldstat" groups="file"/>
+ + <syscall name="oldumount" groups="file"/>
+ + <syscall name="openat2" groups="descriptor,file"/>
+ <syscall name="openat" groups="descriptor,file"/>
+ <syscall name="open_by_handle_at" groups="descriptor"/>
+ <syscall name="open" groups="descriptor,file"/>
+ + <syscall name="open_tree" groups="descriptor,file"/>
+ + <syscall name="osf_fstatfs64" groups="descriptor"/>
+ + <syscall name="osf_fstatfs" groups="descriptor"/>
+ + <syscall name="osf_fstat" groups="descriptor"/>
+ + <syscall name="osf_lstat" groups="file"/>
+ + <syscall name="osf_mincore" groups="memory"/>
+ + <syscall name="osf_mremap" groups="memory"/>
+ + <syscall name="osf_old_fstat" groups="descriptor"/>
+ + <syscall name="osf_old_killpg" groups="process"/>
+ + <syscall name="osf_old_lstat" groups="file"/>
+ + <syscall name="osf_old_stat" groups="file"/>
+ + <syscall name="osf_sbrk" groups="memory"/>
+ + <syscall name="osf_select" groups="descriptor"/>
+ + <syscall name="osf_shmat" groups="ipc,memory"/>
+ + <syscall name="osf_sigprocmask" groups="signal"/>
+ + <syscall name="osf_statfs64" groups="file"/>
+ + <syscall name="osf_statfs" groups="file"/>
+ + <syscall name="osf_stat" groups="file"/>
+ + <syscall name="osf_utimes" groups="file"/>
+ + <syscall name="osf_wait4" groups="process"/>
+ <syscall name="pause" groups="signal"/>
+ <syscall name="perf_event_open" groups="descriptor"/>
+ + <syscall name="pidfd_getfd" groups="descriptor"/>
+ + <syscall name="pidfd_open" groups="descriptor"/>
+ + <syscall name="pidfd_send_signal" groups="descriptor,signal,process"/>
+ <syscall name="pipe2" groups="descriptor"/>
+ <syscall name="pipe" groups="descriptor"/>
+ <syscall name="pivot_root" groups="file"/>
+ + <syscall name="pkey_mprotect" groups="memory"/>
+ <syscall name="poll" groups="descriptor"/>
+ + <syscall name="posix_fstatfs" groups="descriptor"/>
+ + <syscall name="posix_fstat" groups="descriptor"/>
+ + <syscall name="posix_kill" groups="process"/>
+ + <syscall name="posix_lstat" groups="file"/>
+ + <syscall name="posix_madvise" groups="memory"/>
+ + <syscall name="posix_mmap" groups="descriptor,memory"/>
+ + <syscall name="posix_munmap" groups="memory"/>
+ + <syscall name="posix_sbreak" groups="memory"/>
+ + <syscall name="posix_SGI_madvise" groups="memory"/>
+ + <syscall name="posix_SGI_mmap" groups="descriptor,memory"/>
+ + <syscall name="posix_SGI_mprotect" groups="memory"/>
+ + <syscall name="posix_SGI_msync" groups="memory"/>
+ + <syscall name="posix_SGI_munmap" groups="memory"/>
+ + <syscall name="posix_statfs" groups="file"/>
+ + <syscall name="posix_stat" groups="file"/>
+ <syscall name="ppoll" groups="descriptor"/>
+ + <syscall name="ppoll_time64" groups="descriptor"/>
+ <syscall name="pread64" groups="descriptor"/>
+ <syscall name="pread" groups="descriptor"/>
+ + <syscall name="preadv2" groups="descriptor"/>
+ <syscall name="preadv" groups="descriptor"/>
+ + <syscall name="process_madvise" groups="descriptor"/>
+ + <syscall name="process_mrelease" groups="descriptor"/>
+ <syscall name="pselect6" groups="descriptor"/>
+ + <syscall name="pselect6_time64" groups="descriptor"/>
+ + <syscall name="putpmsg" groups="network"/>
+ <syscall name="pwrite64" groups="descriptor"/>
+ <syscall name="pwrite" groups="descriptor"/>
+ + <syscall name="pwritev2" groups="descriptor"/>
+ <syscall name="pwritev" groups="descriptor"/>
+ + <syscall name="quotactl_fd" groups="descriptor"/>
+ <syscall name="quotactl" groups="file"/>
+ <syscall name="readahead" groups="descriptor"/>
+ <syscall name="readdir" groups="descriptor"/>
+ - <syscall name="read" groups="descriptor"/>
+ <syscall name="readlinkat" groups="descriptor,file"/>
+ <syscall name="readlink" groups="file"/>
+ + <syscall name="read" groups="descriptor"/>
+ <syscall name="readv" groups="descriptor"/>
+ <syscall name="recvfrom" groups="network"/>
+ - <syscall name="recv" groups="network"/>
+ + <syscall name="recvmmsg_time64" groups="network"/>
+ <syscall name="recvmmsg" groups="network"/>
+ <syscall name="recvmsg" groups="network"/>
+ + <syscall name="recv" groups="network"/>
+ <syscall name="remap_file_pages" groups="memory"/>
+ <syscall name="removexattr" groups="file"/>
+ + <syscall name="renameat2" groups="descriptor,file"/>
+ <syscall name="renameat" groups="descriptor,file"/>
+ <syscall name="rename" groups="file"/>
+ + <syscall name="riscv_flush_icache" groups="memory"/>
+ <syscall name="rmdir" groups="file"/>
+ <syscall name="rt_sigaction" groups="signal"/>
+ <syscall name="rt_sigpending" groups="signal"/>
+ <syscall name="rt_sigprocmask" groups="signal"/>
+ - <syscall name="rt_sigqueueinfo" groups="signal"/>
+ + <syscall name="rt_sigqueueinfo" groups="signal,process"/>
+ <syscall name="rt_sigreturn" groups="signal"/>
+ <syscall name="rt_sigsuspend" groups="signal"/>
+ + <syscall name="rt_sigtimedwait_time64" groups="signal"/>
+ <syscall name="rt_sigtimedwait" groups="signal"/>
+ <syscall name="rt_tgsigqueueinfo" groups="process,signal"/>
+ <syscall name="select" groups="descriptor"/>
+ @@ -172,12 +278,14 @@
+ <syscall name="semget" groups="ipc"/>
+ <syscall name="semop" groups="ipc"/>
+ <syscall name="semtimedop" groups="ipc"/>
+ + <syscall name="semtimedop_time64" groups="ipc"/>
+ <syscall name="sendfile64" groups="descriptor,network"/>
+ <syscall name="sendfile" groups="descriptor,network"/>
+ - <syscall name="send" groups="network"/>
+ <syscall name="sendmmsg" groups="network"/>
+ <syscall name="sendmsg" groups="network"/>
+ + <syscall name="send" groups="network"/>
+ <syscall name="sendto" groups="network"/>
+ + <syscall name="set_mempolicy_home_node" groups="memory"/>
+ <syscall name="set_mempolicy" groups="memory"/>
+ <syscall name="setns" groups="descriptor"/>
+ <syscall name="setsockopt" groups="network"/>
+ @@ -198,38 +306,78 @@
+ <syscall name="sigreturn" groups="signal"/>
+ <syscall name="sigsuspend" groups="signal"/>
+ <syscall name="socketcall" groups="descriptor"/>
+ - <syscall name="socket" groups="network"/>
+ <syscall name="socketpair" groups="network"/>
+ + <syscall name="socket" groups="network"/>
+ <syscall name="splice" groups="descriptor"/>
+ <syscall name="ssetmask" groups="signal"/>
+ <syscall name="stat64" groups="file"/>
+ <syscall name="statfs64" groups="file"/>
+ <syscall name="statfs" groups="file"/>
+ <syscall name="stat" groups="file"/>
+ + <syscall name="statx" groups="descriptor,file"/>
+ + <syscall name="svr4_fstatfs" groups="descriptor"/>
+ + <syscall name="svr4_fstat" groups="descriptor"/>
+ + <syscall name="svr4_fstatvfs" groups="descriptor"/>
+ + <syscall name="svr4_fxstat" groups="descriptor"/>
+ + <syscall name="svr4_kill" groups="process"/>
+ + <syscall name="svr4_lstat" groups="file"/>
+ + <syscall name="svr4_lxstat" groups="file"/>
+ + <syscall name="svr4_mincore" groups="memory"/>
+ + <syscall name="svr4_mmap" groups="descriptor,memory"/>
+ + <syscall name="svr4_mprotect" groups="memory"/>
+ + <syscall name="svr4_munmap" groups="memory"/>
+ + <syscall name="svr4_sbreak" groups="memory"/>
+ + <syscall name="svr4_statfs" groups="file"/>
+ + <syscall name="svr4_stat" groups="file"/>
+ + <syscall name="svr4_statvfs" groups="file"/>
+ + <syscall name="svr4_xstat" groups="file"/>
+ <syscall name="swapoff" groups="file"/>
+ <syscall name="swapon" groups="file"/>
+ <syscall name="symlinkat" groups="descriptor,file"/>
+ <syscall name="symlink" groups="file"/>
+ + <syscall name="sync_file_range2" groups="descriptor"/>
+ <syscall name="sync_file_range" groups="descriptor"/>
+ <syscall name="syncfs" groups="descriptor"/>
+ + <syscall name="sysv_brk" groups="memory"/>
+ + <syscall name="sysv_fstatfs" groups="descriptor"/>
+ + <syscall name="sysv_fstat" groups="descriptor"/>
+ + <syscall name="sysv_fstatvfs" groups="descriptor"/>
+ + <syscall name="sysv_fxstat" groups="descriptor"/>
+ + <syscall name="sysv_kill" groups="process"/>
+ + <syscall name="sysv_lstat" groups="file"/>
+ + <syscall name="sysv_lxstat" groups="file"/>
+ + <syscall name="sysv_madvise" groups="memory"/>
+ + <syscall name="sysv_mmap64" groups="descriptor,memory"/>
+ + <syscall name="sysv_mmap" groups="descriptor,memory"/>
+ + <syscall name="sysv_mprotect" groups="memory"/>
+ + <syscall name="sysv_msync" groups="memory"/>
+ + <syscall name="sysv_munmap" groups="memory"/>
+ + <syscall name="sysv_quotactl" groups="file"/>
+ + <syscall name="sysv_statfs" groups="file"/>
+ + <syscall name="sysv_stat" groups="file"/>
+ + <syscall name="sysv_statvfs" groups="file"/>
+ + <syscall name="sysv_xstat" groups="file"/>
+ <syscall name="tee" groups="descriptor"/>
+ - <syscall name="tgkill" groups="signal"/>
+ + <syscall name="tgkill" groups="signal,process"/>
+ <syscall name="timerfd_create" groups="descriptor"/>
+ + <syscall name="timerfd_gettime64" groups="descriptor"/>
+ <syscall name="timerfd_gettime" groups="descriptor"/>
+ - <syscall name="timerfd" groups="descriptor"/>
+ + <syscall name="timerfd_settime64" groups="descriptor"/>
+ <syscall name="timerfd_settime" groups="descriptor"/>
+ - <syscall name="tkill" groups="signal"/>
+ + <syscall name="timerfd" groups="descriptor"/>
+ + <syscall name="tkill" groups="signal,process"/>
+ <syscall name="truncate64" groups="file"/>
+ <syscall name="truncate" groups="file"/>
+ <syscall name="umount2" groups="file"/>
+ <syscall name="umount" groups="file"/>
+ <syscall name="unlinkat" groups="descriptor,file"/>
+ <syscall name="unlink" groups="file"/>
+ - <syscall name="unshare" groups="process"/>
+ <syscall name="uselib" groups="file"/>
+ - <syscall name="utime" groups="file"/>
+ + <syscall name="userfaultfd" groups="descriptor"/>
+ <syscall name="utimensat" groups="descriptor,file"/>
+ + <syscall name="utimensat_time64" groups="descriptor,file"/>
+ <syscall name="utimes" groups="file"/>
+ + <syscall name="utime" groups="file"/>
+ <syscall name="vfork" groups="process"/>
+ <syscall name="vmsplice" groups="descriptor"/>
+ <syscall name="wait4" groups="process"/>
+
+ Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1
+
+2023-02-27 Pedro Alves <pedro@palves.net>
+
+ Autogenerate gdb/syscalls/linux-defaults.xml.in (groups) from strace sources
+ I noticed that "catch syscall group:process" doesn't catch clone3,
+ while it does catch clone.
+
+ The catch syscall group information is recorded in the
+ gdb/syscalls/linux-defaults.xml.in file, which says:
+
+ <!-- The group field information was based on strace. -->
+
+ So I looked at the strace sources, to confirm that clone3 is in fact
+ recorded in the "process" group there too, and to check what other
+ syscalls might be missing groups.
+
+ After some digging, I found that strace records the group info in C
+ arrays, with entries like:
+ ...
+ [ 61] = { 4, TP, SEN(wait4), "wait4" },
+ [ 62] = { 2, TS|TP, SEN(kill), "kill" },
+ [ 63] = { 1, 0, SEN(uname), "uname" },
+ ...
+
+ You can see the current master's table for Linux x86-64 here:
+
+ https://github.com/strace/strace/blob/e88e5e9ae6da68f22d15f9be3193b1412ac9aa02/src/linux/x86_64/syscallent.h
+
+ The column with TS|TP above is what defines each syscall's groups. So
+ I wrote a script that extracts this information and generates
+ linux-defaults.xml.in.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I679d59d42fb2a914bf7a99e4c558e9696e5adff1
+
+2023-02-27 Clément Chigot <chigot@adacore.com>
+
+ gas/testsuite: adjust another test for case insensitive file systems
+ As 1fafeaac8503eea2f61c3a35f0eef183b7e7cc65, "line.s" and "Line.s" are
+ identical in case insensitive file systems. Thus, gas doesn't trigger
+ an input file switch.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/elf/dwarf-5-macro.s: Change Line.s to Line2.s.
+
+2023-02-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't treat empty enums as flag enums
+ In C++ it is possible to use an empty enum as a strong typedef. For
+ example, a user could write:
+
+ enum class my_type : unsigned char {};
+
+ Now my_type can be used like 'unsigned char' except the compiler will
+ not allow implicit conversion too and from the native 'unsigned char'
+ type.
+
+ This is used in the standard library for things like std::byte.
+
+ Currently, when GDB prints a value of type my_type, it looks like
+ this:
+
+ (gdb) print my_var
+ $1 = (unknown: 0x4)
+
+ Which isn't great. This gets worse when we consider something like:
+
+ std::vector<my_type> vec;
+
+ When using a pretty-printer, this could look like this:
+
+ std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)}
+
+ Clearly not great. This is described in PR gdb/30148.
+
+ The problem here is in dwarf2/read.c, we assume all enums are flag
+ enums unless we find an enumerator with a non-flag like value.
+ Clearly an empty enum contains no non-flag values, so we assume the
+ enum is a flag enum.
+
+ I propose adding an extra check here; that is, an empty enum should
+ never be a flag enum.
+
+ With this the above cases look more like:
+
+ (gdb) print my_var
+ $1 = 4
+
+ and:
+
+ std::vector of length 2, capacity 2 = {2, 4}
+
+ Which look much better.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-27 Benson Muite <benson_muite@emailplus.org>
+
+ Do not change the timestamp when updating the gas asconfig file.
+ PR 28909 * doc/local.mk (asconfig.texi): Use "cp -p" to preserve timestamps. * Makefile.in: Regenerate.
+
+2023-02-27 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ Fix missing "Core was generated by" when loading a x32 corefile.
+
+2023-02-27 Nick Clifton <nickc@redhat.com>
+
+ Updated Serbian translations for gold, gprof and opcodes sub-directories
+
+2023-02-27 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Improve testing of GDB's completion functions
+ When looking at some failures of gdb.linespec/cp-completion-aliases.exp,
+ I noticed that when a completion test will fail, it always fails with a
+ timeout. This is because most completion tests use gdb_test_multiple
+ and only add a check for the correct output. This commit adds new
+ options for both, tab and command completion.
+
+ For command completion, the new option will check if the prompt was
+ printed, and fail in this case. This is enough to know that the test has
+ failed because the check comes after the PASS path. For tab completion,
+ we have to check if GDB outputted more than just the input line, because
+ sometimes GDB would have printed a partial line before finishing with
+ the correct completion.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb, python: do minor modernization in execute_gdb_command
+ Use nullptr instead of NULL and boolify two local variables in
+ execute_gdb_command.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-26 Tom Tromey <tom@tromey.com>
+
+ Remove expand_symtab_containing_pc
+ The function expand_symtab_containing_pc is unused; remove it.
+ Tested by rebuilding.
+
+2023-02-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/amd64: replace xmalloc/alloca with gdb::byte_vector
+ Replace a couple of uses of xmalloc and alloc with a gdb::byte_vector
+ local variable instead.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-25 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/m68k: enable libopcodes styling for GDB
+ The following commit added libopcodes styling for m68k:
+
+ commit c22ff449275c91e4842bb10c650e83c572580f65
+ Date: Tue Feb 14 18:07:19 2023 +0100
+
+ opcodes: style m68k disassembler output
+
+ but didn't set disassemble_info::created_styled_output in
+ disassemble.c, which is needed in order for GDB to start using the
+ libopcodes based styling.
+
+ This commit fixes this small oversight. GDB now styles correctly.
+
+2023-02-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-24 Khem Raj <raj.khem@gmail.com>
+
+ gdbserver/linux-low.cc: Fix a typo in ternary operator
+
+2023-02-24 Tom Tromey <tom@tromey.com>
+
+ Remove struct buffer
+ I've long wanted to remove 'struct buffer', and thanks to Simon's
+ earlier patch, I was finally able to do so. My feeling has been that
+ gdb already has several decent structures available for growing
+ strings: std::string of course, but also obstack and even objalloc
+ from BFD and dyn-string from libiberty. The previous patches in this
+ series removed all the uses of struct buffer, so this one can remove
+ the code and the remaining #includes.
+
+ Don't use struct buffer in top.c
+ This changes top.c to use std::string rather than struct buffer. Like
+ the event-top.c change, this is not completely ideal in that it
+ requires a copy of the string.
+
+ Don't use struct buffer in event-top.c
+ This changes event-top.c to use std::string rather than struct buffer.
+ This isn't completely ideal, in that it requires a copy of the string
+ to be made.
+
+ Don't use struct buffer in handle_qxfer_threads
+ This changes handle_qxfer_threads, in gdbserver, to use std::string
+ rather than struct buffer.
+
+ Don't use struct buffer in handle_qxfer_btrace
+ This changes handle_qxfer_btrace and handle_qxfer_btrace_conf, in
+ gdbserver, to use std::string rather than struct buffer.
+
+ Don't use struct buffer in handle_qxfer_traceframe_info
+ This changes handle_qxfer_traceframe_info, in gdbserver, to use
+ std::string rather than struct buffer.
+
+ Remove struct buffer from tracefile-tfile.c
+ This changes tracefile-tfile.c to use std::string rather than struct
+ buffer.
+
+2023-02-24 Tom Tromey <tromey@adacore.com>
+
+ Write the DWARF index in the background
+ The new DWARF cooked indexer interacts poorly with the DWARF index
+ cache. In particular, the cache will require gdb to wait for the
+ cooked index to be finalized. As this happens in the foreground, it
+ means that users with this setting enabled will see a slowdown.
+
+ This patch changes gdb to write the cache entry a worker thread. (As
+ usual, in the absence of threads, this work is simply done immediately
+ in the main thread.)
+
+ Some care is taken to ensure that this can't crash, and that gdb will
+ not exit before the task is complete.
+
+ To avoid use-after-free problems, the DWARF per-BFD object explicitly
+ waits for the index cache task to complete.
+
+ To avoid gdb exiting early, an exit observer is used to wait for all
+ such pending tasks.
+
+ In normal use, neither of these waits will be very visible. For users
+ using "-batch" to pre-generate the index, though, it would be.
+ However I don't think there is much to be done about this, as it was
+ the status quo ante.
+
+2023-02-24 Tom Tromey <tromey@adacore.com>
+
+ Only use the per-BFD object to write a DWARF index
+ The DWARF index does not need access to the objfile or per-objfile
+ objects when writing -- it's entirely based on the objfile-independent
+ per-BFD data.
+
+ This patch implements this idea by changing the entire API to only be
+ passed the per-BFD object. This simplifies some lifetime reasoning
+ for the next patch.
+
+ This patch removes some code that ensures that the BFD came from a
+ file. It seems to me that checking for the existence of a build-id is
+ good enough for the index cache.
+
+2023-02-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix parenthesis position in comment
+ Change-Id: I535b597ab4482378910570d8dd69c090419941eb
+
+2023-02-24 Clément Chigot <chigot@adacore.com>
+
+ testsuite: prune DOS drive letter in test outputs
+ On DOS systems, absolute paths start with the drive letter. This can
+ trigger failures in the regexp from dump tests, especially for those
+ checking for warnings or errors. They are usually skipping everything
+ before the first ":" as it has to be the file path.
+ | [^:]*: warning: ...
+
+ In order to avoid modifying many regexps to allow such drive letters,
+ prune them from all the outputs if they are found at the beginning of
+ a line.
+
+ binutils/ChangeLog:
+
+ * testsuite/lib/binutils-common.exp (prune_dump_output): New
+ (run_dump_test): Use it.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/noinit-sections-2.l: Remove DOS drive letter
+ handler.
+
+2023-02-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: allow to request ModR/M encoding
+ Several insns have a (typically shorter) non-ModR/M and a (typically
+ longer) ModR/M encoding. In most cases the former is used by default.
+ This isn't too dissimilar from register-only insns sometimes having two
+ encoding forms. In those cases {load} or {store} can be used to control
+ the encoding used. Extend this to ModR/M-less encodings which have a
+ ModR/M counterpart (note that BSWAP hasn't). For insn reading and
+ writing their (explicit) memory operand, both prefixes are honored;
+ otherwise only the applicable one is.
+
+ Note that for some forms of XCHG, {store} has already been performing
+ this function, apparently as an unnoticed side effect of adding D to
+ the template.
+
+2023-02-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: MONITOR/MWAIT are not SSE3 insns
+ These have their own CPUID bit and hence they should also have their own
+ separate control.
+
+2023-02-24 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: don't permit LAHF/SAHF with "generic64"
+ The feature isn't universally available on 64-bit CPUs.
+
+ Note that in i386-gen.c:isa_dependencies[] I'm only adding it to models
+ where I'm certain the functionality exists. For Nocona and Core I'm
+ uncertain in particular.
+
+2023-02-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: have insns acting on segment selector values allow for consistent operands
+ While MOV to/from segment register as well as selector storing insns
+ already permit 32- and 64-bit GPR operands, selector loading insns and
+ ARPL do not. Split templates accordingly.
+
+2023-02-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: restrict insn templates accepting negative 8-bit immediates
+ For shifts (but not ordinary rotates) and other cases where an immediate
+ describes e.g. a bit count or position, allowing negative operands is at
+ best confusing. An extreme example would be the two rotate-through-carry
+ insns, where a negative value would _not_ mean rotating the
+ corresponding number of bits in the other direction. To refuse such,
+ give meaning to the combination of Imm8 and Imm8S in templates (so far
+ these weren't used together anywhere). The issue was with
+ smallest_imm_type() blindly setting .imm8 for signed numbers determined
+ to fit in a byte.
+
+ VPROT{B,W,D,Q} is a little special: The rotate count there is a signed
+ quantity, so Imm8 is replaced by Imm8S. Adjust affected testcases
+ accordingly as well.
+
+ Another small adjustment to the testsuite is necessary: AAM and AAD were
+ never sensible to use with 0xffffff90 operands. This should have been an
+ error.
+
+2023-02-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Cleanup unnecessary expr from require line
+ In a recent commit I've added:
+ ...
+ require {expr [have_compile_flag -fsplit-stack]}
+ ...
+ but actually the expr bit is unnecessary, and we can just use:
+ ...
+ require {have_compile_flag -fsplit-stack}
+ ...
+
+ Reported-By: Tom Tromey <tom@tromey.com>
+
+2023-02-24 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Fix out of bounds accesses with limited-length values
+ Fix accesses to limited-length values in `contents_copy_raw' and
+ `contents_copy_raw_bitwise' so that they observe the limit of the
+ original allocation.
+
+ Reported by Simon Marchi as a heap-buffer-overflow AddressSanitizer
+ issue triggered with gdb.ada/limited-length.exp.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-24 Nick Clifton <nickc@redhat.com>
+
+ Enhance better_fit() function to prefer function symbols over non-function symbols.
+
+2023-02-24 Alan Modra <amodra@gmail.com>
+
+ PR30155, ld segfault in _bfd_nearby_section
+ The segfault was a symptom of messing with the absolute section next
+ field, confusing bfd_section_removed_from_list in linker.c:fix_syms.
+ That's not all that was going wrong. The INSERT list of output
+ sections was being inserted into itself, ie. lost from the main
+ list of linker statements.
+
+ PR 30155
+ * ldlang.c (process_insert_statements): Handle pathological
+ case of the insert script being inserted before the first
+ output section statement in the default script.
+ (output_prev_sec_find): Don't test section owner here.
+ (insert_os_after): Change parameter to a list union pointer.
+ (lang_insert_orphan): Test section owner here and adjust
+ insert_os_after call.
+
+2023-02-24 Fangrui Song <i@maskray.me>
+
+ RISC-V: Add --[no-]relax-gp to ld
+ --relax enables all relaxations. --no-relax-gp disables GP relaxation to
+ allow measuring its effect.
+
+ The option can test effectiveness of GP relaxation and support some ABI
+ variants that use GP for other purposes.
+
+ Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/298
+
+ bfd/
+ * elfnn-riscv.c (struct riscv_elf_link_hash_table): Add params.
+ (riscv_elfNN_set_options): New.
+ (riscv_info_to_howto_rela): Check relax_gp.
+ (_bfd_riscv_relax_section): Likewise.
+ * elfxx-riscv.h (struct riscv_elf_params): New.
+ (riscv_elf32_set_options): New.
+ (riscv_elf64_set_options): New.
+ ld/
+ * emultempl/riscvelf.em: Add option parsing.
+ * testsuite/ld-riscv-elf/code-model-relax-medlow-01-norelaxgp.d: New.
+ * testsuite/ld-riscv-elf/pcgp-relax-01-norelaxgp.d: New.
+ * testsuite/ld-riscv-elf/pcgp-relax-02.d: Test --relax --relax-gp can be
+ used together.
+
+2023-02-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-23 Palmer Dabbelt <palmer@rivosinc.com>
+
+ gdb/doc: The RISC-V vector registers didn't change
+ When we merged the GDB vector register support we did it a bit early,
+ just eating the risk in the very unlikely case that the vector register
+ names changed. They didn't, so we can now remove the caveat in the docs
+ that they might.
+
+2023-02-23 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove --disable-gdbmi configure option
+ I noticed that the --disable-gdbmi option was broken for almost a year
+ (since 740b42ceb7c "gdb/python/mi: create MI commands using python").
+
+ The problem today is the python/py-cmd.c file. It is included in the
+ build if Python support is enabled, and it calls into some MI functions
+ (e.g. insert_mi_cmd_entry). If MI support is disabled, we get some
+ undefined symbols like:
+
+ mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >)
+ >>> referenced by py-micmd.c
+ >>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*))
+
+ The python/py-cmd.c file should be included in the build if both Python
+ and MI support are enabled. It is not a case we support today, but it
+ could be done with a bit more configure code. However, I think we
+ should just remove the --disable-gdbmi option, and just include MI
+ support unconditionally.
+
+ Tom Tromey proposed a while ago to remove this option, but it ended
+ staying:
+
+ https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/
+
+ However, there was no strong opposition to remove it. The argument was
+ just "bah, it doesn't hurt anybody".
+
+ But given today's case, I would rather remove complexity rather than add
+ some. I couldn't find anybody caring deeply for that option, and it's
+ not like MI adds any external dependency. It's just a bit more code.
+
+ Removing the option will not break anybody using --disable-gdbmi (it can
+ be found in many build scripts [1]), since we don't flag invalid
+ configure flags.
+
+ So, remove the option from configure.ac, and adjust Makefile.in
+ accordingly to always include the MI objects in the build.
+
+ [1] https://github.com/search?q=%22--disable-gdbmi%22&type=code
+
+ Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-23 Tom Tromey <tromey@adacore.com>
+
+ Fix Tcl quoting in gdb_assert
+ The gdb_assert proc under-quotes the expression that is passed in.
+ This leads to weird code in a couple of spots that tries to
+ compensate:
+
+ gdb_assert {{$all_regs eq $completed_regs}} ...
+
+ The fix is to add a bit of quoting when evaluating the expression.
+
+2023-02-23 Nick Clifton <nickc@redhat.com>
+
+ Fix _bfd_elf_find_function so that it can cope with overlapping symbols
+
+2023-02-23 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add AMDGPU header files to HFILES_NO_SRCDIR
+ Commit 18b4d0736bc5 ("gdb: initial support for ROCm platform (AMDGPU)
+ debugging") missed adding these header files to the HFILES_NO_SRCDIR
+ list in the Makefile. Fix that now.
+
+ Change-Id: Ifd387096aef3d147b51aefa2037da5bf6373ea64
+
+2023-02-23 Tom Tromey <tromey@adacore.com>
+
+ Remove 'eval' from gdb_breakpoint
+ Now that Tcl has the {*} operator, we can remove the use of eval from
+ gdb_breakpoint. Tested on x86-64 Fedora 36.
+
+2023-02-23 Hui Li <lihui@loongson.cn>
+
+ gdb: LoongArch: Support reg aliases in info reg command
+ According to LoongArch ELF ABI specification [1], support the register
+ aliases in "info register" command.
+
+ Without this patch:
+ ```
+ (gdb) info reg a0
+ Invalid register `a0'
+
+ ```
+ With this patch:
+
+ ```
+ (gdb) info reg a0
+
+ a0 0x1 1
+
+ ```
+ [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_register_convention
+
+2023-02-23 Hui Li <lihui@loongson.cn>
+
+ gdb: LoongArch: Modify the result of the info reg command
+ The "info register" command should only display general registers,
+ but it shows the information of all registers in the current code,
+ add loongarch_register_reggroup_p() so that we can get the expected
+ result.
+
+2023-02-23 Alexey Lapshin <alexey.lapshin@espressif.com>
+
+ bfd: xtensa: fix __stop_SECTION literal drop
+
+2023-02-23 Nick Clifton <nickc@redhat.com>
+
+ Fix the BFD library's find_nearest_line feature to produce consistent results.
+ PR 30150
+ * dwarf2.c (comp_unit_contains_address): Renamed to ... (comp_unit_may_contain_address): this,
+ and added code to return true if the CU's ranges have not yet been computed.
+ (_bfd_dwarf2_find_nearest_line_with_alt): Use the renamed function, simplifying code in the process.
+
+2023-02-23 Alan Modra <amodra@gmail.com>
+
+ dwarf1 .line SEC_HAS_CONTENTS
+ * dwarf1.c (parse_line_table): Ignore .line without SEC_HAS_CONTENTS.
+ Formatting.
+
+2023-02-23 Alan Modra <amodra@gmail.com>
+
+ ip2k: don't look at stab sections without relocs
+ No need to read contents if we won't do anything.
+
+ * elf32-ip2k.c (adjust_all_relocations): Skip stab sections
+ without relocs.
+
+2023-02-23 Alan Modra <amodra@gmail.com>
+
+ Test SEC_HAS_CONTENTS in relax routines
+ More places that generally expect instructions, so not zeros.
+
+ * coff-sh.c (sh_relax_section, sh_relax_delete_bytes): Exclude
+ sections without SEC_HAS_CONTENTS set.
+ * elf-m10200.c (mn10200_elf_relax_section): Likewise.
+ * elf32-arc.c (arc_elf_relax_section): Likewise.
+ * elf32-avr.c (elf32_avr_relax_section): Likewise.
+ * elf32-cr16.c (elf32_cr16_relax_section): Likewise.
+ * elf32-crx.c (elf32_crx_relax_section): Likewise.
+ * elf32-epiphany.c (epiphany_elf_relax_section): Likewise.
+ * elf32-ft32.c (ft32_elf_relax_section): Likewise.
+ * elf32-h8300.c (elf32_h8_relax_section): Likewise.
+ * elf32-ip2k.c (ip2k_elf_relax_section): Likewise.
+ * elf32-m32c.c (m32c_elf_relax_section): Likewise.
+ * elf32-m68hc11.c (m68hc11_elf_relax_section): Likewise.
+ * elf32-msp430.c (msp430_elf_relax_section): Likewise.
+ * elf32-pru.c (pru_elf32_relax_section): Likewise.
+ * elf32-rl78.c (rl78_elf_relax_section): Likewise.
+ * elf32-rx.c (elf32_rx_relax_section): Likewise.
+ * elf32-sh.c (sh_elf_relax_section): Likewise.
+ (sh_elf_relax_delete_bytes): Likewise.
+ * elf32-v850.c (v850_elf_relax_section): Likewise.
+ * elf64-alpha.c (elf64_alpha_relax_section): Likewise.
+ * elf64-ia64-vms.c (elf64_ia64_relax_section): Likewise.
+ * elfnn-ia64.c (elfNN_ia64_relax_section): Likewise.
+ * elfnn-riscv.c (_bfd_riscv_relax_section): Likewise.
+ * elfxx-mips.c (_bfd_mips_elf_relax_section): Likewise.
+
+2023-02-23 Alan Modra <amodra@gmail.com>
+
+ Test SEC_HAS_CONTENTS before reading section contents
+ bfd_malloc_and_get_section does size sanity checking before allocating
+ memory and reading contents. These size checks are not done for bss
+ style sections, because they typically don't occupy file space and
+ thus can't be compared against file size. However, if you are
+ expecting to look at something other than a whole lot of zeros, don't
+ allow fuzzers to avoid the size checking.
+
+ * cofflink.c (process_embedded_commands): Don't look at
+ sections without SEC_HAS_CONTENTS set.
+ * cpu-arm.c (bfd_arm_update_notes): Likewise.
+ (bfd_arm_get_mach_from_notes): Likewise.
+ * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Likewise.
+ * elf-hppa.h (elf_hppa_sort_unwind): Likewise.
+ * elf-m10300.c (mn10300_elf_relax_section): Likewise.
+ * elf-sframe.c (_bfd_elf_parse_sframe): Likewise.
+ * elf.c (_bfd_elf_print_private_bfd_data): Likewise.
+ * elf32-arm.c (bfd_elf32_arm_process_before_allocation): Likewise.
+ * elf32-avr.c (avr_elf32_load_property_records): Likewise.
+ * elf32-ppc.c (_bfd_elf_ppc_set_arch): Likewise.
+ (ppc_elf_get_synthetic_symtab, ppc_elf_relax_section): Likewise.
+ * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
+ (opd_entry_value, ppc64_elf_edit_opd, ppc64_elf_edit_toc): Likewise.
+ * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise.
+ * elflink.c (elf_link_add_object_symbols): Likewise.
+ (bfd_elf_get_bfd_needed_list): Likewise.
+ * elfnn-aarch64.c (get_plt_type): Likewise.
+ * elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.
+ * linker.c (_bfd_handle_already_linked): Likewise.
+ * opncls.c (bfd_get_debug_link_info_1): Likewise.
+ (bfd_get_alt_debug_link_info, get_build_id): Likewise.
+ * peXXigen.c (pe_print_idata, pe_print_pdata): Likewise.
+ (_bfd_XX_print_ce_compressed_pdata, pe_print_reloc): Likewise.
+ * pei-x86_64.c (pex64_bfd_print_pdata_section): Likewise.
+ * stabs.c (_bfd_link_section_stabs): Likewise.
+ (_bfd_discard_section_stabs): Likewise.
+ * xcofflink.c (_bfd_xcoff_get_dynamic_symtab_upper_bound): Likewise.
+ (_bfd_xcoff_canonicalize_dynamic_symtab): Likewise.
+ (_bfd_xcoff_get_dynamic_reloc_upper_bound): Likewise.
+ (_bfd_xcoff_canonicalize_dynamic_reloc): Likewise.
+ (xcoff_link_add_dynamic_symbols): Likewise.
+ (xcoff_link_check_dynamic_ar_symbols): Likewise.
+ (bfd_xcoff_build_dynamic_sections): Likewise.
+
+2023-02-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-22 Pedro Alves <pedro@palves.net>
+
+ gdb.reverse/time-reverse.exp: test both time syscall and C time function
+ Instead of only testing this on systems that have a SYS_time syscall,
+ test it everywhere using the time(2) C function, and in addition, run
+ the tests again using the SYS_time syscall.
+
+ The C variant ensures that if some platform uses some syscall we are
+ not aware of yet, we'll still exercise it, and likely fail, at which
+ point we should teach GDB about the syscall.
+
+ The explicit syscall variant is useful on platforms where the C
+ function does not call a syscall at all by default, e.g., on some
+ systems the C time function wraps an implementation provided by the
+ vDSO.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+ Change-Id: Id4b755d76577d02c46b8acbfa249d9c31b587633
+
+2023-02-22 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: LAR and LSL don't need REX.W
+ Just like we suppress emitting REX.W for e.g. MOV from/to segment
+ register, there's also no need for it for LAR and LSL - these can only
+ ever return 32-bit values and hence always zero-extend their results
+ anyway.
+
+ While there also drop the redundant Word from the first operand of
+ the second template each - this is already implied by Reg16.
+
+2023-02-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: optimize BT{,C,R,S} $imm,%reg
+ In 64-bit mode BT can have REX.W or a data size prefix dropped in
+ certain cases. Outside of 64-bit mode all 4 insns can have the data
+ size prefix dropped in certain cases.
+
+2023-02-22 Alan Modra <amodra@gmail.com>
+
+ set bfd_error on make_tempname or make_tempdir failure
+ * bucomm.c (make_tempname, make_tempdir): Set bfd_error on error.
+
+2023-02-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-21 Alan Modra <amodra@gmail.com>
+
+ Re: objdump read_section_stabs
+ Also fix ubsan "applying zero offset to null pointer".
+
+ * objdump.c (print_section_stabs): Avoid ubsan warning.
+
+2023-02-21 Alan Modra <amodra@gmail.com>
+
+ Re: objdump read_section_stabs
+ Commit f9c36cc99518 changed (and renamed) read_section_stabs with one
+ difference in overall behaviour. Previously read_section_stabs would
+ return a NULL for an empty section, which was then treated the same as
+ a missing section. Now an empty section is recognized and dumped.
+ This leads to NULL stabp and stabs_end in print_section_stabs. Since
+ stabs_end - STABSIZE is then a pointer to a very large address, the
+ test "stabp < stabs_end - STABSIZE" succeeds.
+
+ * objdump.c (print_section_stabs): Correct STABSIZE comparison.
+
+2023-02-21 Alan Modra <amodra@gmail.com>
+
+ debug_link duplicate file size checks
+ bfd_malloc_and_get_section does these checks.
+
+ * opncls.c (bfd_get_debug_link_info_1): Don't check section
+ size against file size.
+ (bfd_get_alt_debug_link_info): Likewise.
+
+2023-02-21 Tom Tromey <tom@tromey.com>
+
+ Issue error on erroneous expression
+ A while back I discovered that this does not issue an error:
+
+ (gdb) p $x = (void * ) 57
+ $3 = (void *) 0x39
+ (gdb) p $x + 7 = 3
+ $6 = (void *) 0x3
+
+ This patch fixes the bug.
+ Regression tested on x86-64 Fedora 36.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19312
+
+2023-02-21 Philippe Blain <levraiphilippeblain@gmail.com>
+
+ gdb: add --with-curses to --configuration output
+ 'gdb --configuration' does not mention if GDB was built with curses.
+ Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show
+ --enable-tui (or --disable-tui), but one might want to know if GDB was
+ built with curses independently of the availability of the TUI.
+
+ Since configure.ac uses AC_SEARCH_LIBS to check for the curses library,
+ we do not get an automatically defined HAVE_LIBCURSES symbol in
+ config.in. We do have symbols defined by AC_CHECK_HEADERS
+ (HAVE_CURSES_H, etc.) but it would be cumbersome to use those in
+ print_gdb_configuration because we would have to check for all 6 symbols
+ corresponding the 6 headers listed. This would also increase the
+ maintenance burden if support for other variations of curses are added.
+
+ Instead, define 'HAVE_LIBCURSES' ourselves by adding an
+ 'action-if-found' argument to AC_SEARCH_LIBS, and use it in
+ print_gdb_configuration.
+
+ While at it, remove the condition on 'ac_cv_search_waddstr' and set
+ 'curses_found' directly in 'action-if-found'.
+
+ Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require compilation flags in two gdb.arch/aarch64 test-cases
+ With test-cases gdb.arch/aarch64-mte-core.exp and gdb.arch/aarch64-pauth.exp I
+ run into compilation errors due to unsupported compilation flags.
+
+ Fix this by requiring the compilation flags, such that I have instead:
+ ...
+ UNSUPPORTED: gdb.arch/aarch64-mte-core.exp: require failed: \
+ have_compile_flag -march=armv8.5-a+memtag
+ UNSUPPORTED: gdb.arch/aarch64-pauth.exp: require failed: \
+ have_compile_flag -mbranch-protection=pac-ret+leaf
+ ...
+
+ Tested on aarch64-linux.
+
+2023-02-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require istarget x86* in gdb.reverse/step-indirect-call-thunk.exp
+ On aarch64-linux, I run into:
+ ...
+ Running gdb.reverse/step-indirect-call-thunk.exp ...
+ gdb compile failed, gcc: error: unrecognized command line option \
+ '-mindirect-branch=thunk'; did you mean '-findirect-inlining'?
+ gcc: error: unrecognized command line option '-mfunction-return=thunk'; \
+ did you mean '-Wfunction-elimination'?
+ UNTESTED: gdb.reverse/step-indirect-call-thunk.exp: failed to prepare
+ ...
+
+ Fix this by requiring istarget "x86*", similar to what was added in
+ gdb.base/step-indirect-call-thunk.exp by commit 43127ae5714 ("Fix
+ gdb.base/step-indirect-call-thunk.exp"), such that we have instead:
+ ...
+ UNSUPPORTED: gdb.reverse/step-indirect-call-thunk.exp: require failed: \
+ istarget "x86*
+ ...
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2023-02-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require -fsplit-stack in gdb.base/morestack.exp
+ On aarch64-linux, I run into:
+ ...
+ gdb compile failed, cc1: error: '-fsplit-stack' is not supported by this \
+ compiler configuration
+ UNTESTED: gdb.base/morestack.exp: failed to prepare
+ ...
+
+ Fix this by requiring -fsplit-stack, such that we have instead:
+ ...
+ UNSUPPORTED: gdb.base/morestack.exp: require failed: \
+ expr [have_compile_flag -fsplit-stack]
+ ...
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2023-02-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require syscall time in gdb.reverse/time-reverse.exp
+ On aarch64-linux, I run into:
+ ...
+ Running gdb.reverse/time-reverse.exp ...
+ gdb compile failed, gdb.reverse/time-reverse.c: In function 'main':
+ gdb.reverse/time-reverse.c:39:12: error: 'SYS_time' undeclared \
+ (first use in this function); did you mean 'SYS_times'?
+ syscall (SYS_time, &time_global);
+ ^~~~~~~~
+ SYS_times
+ gdb.reverse/time-reverse.c:39:12: note: each undeclared identifier is \
+ reported only once for each function it appears in
+ UNTESTED: gdb.reverse/time-reverse.exp: failed to prepare
+ ...
+
+ Fix this by adding a new proc have_syscall, and requiring syscall time, such
+ that we have instead:
+ ...
+ UNSUPPORTED: gdb.reverse/time-reverse.exp: require failed: \
+ expr [have_syscall time]
+ ...
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2023-02-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require python in gdb.dap/basic-dap.exp
+ When running test-case gdb.dap/basic-dap.exp with a gdb without python
+ support, I run into:
+ ...
+ builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 \
+ -data-directory data-directory -iex set debug dap-log-file dap.log.1 -q \
+ -i=dap
+ >>> {"seq": 1, "type": "request", "command": "initialize"}
+ Interpreter `dap' unrecognized
+ ERROR: eof reading json header
+ ...
+
+ Fix this by requiring python in the test-case.
+
+ Tested on x86_64-linux, both with a gdb without and with python.
+
+2023-02-21 Nick Clifton <nickc@redhat.com>
+
+ Update the description of the bfd_fill_in_gnu_debuglink_section function
+
+ Updated translatios for the bfd and gprof directories.
+
+2023-02-21 Clément Chigot <chigot@adacore.com>
+
+ gas/testsuite: adjust a test for case insensitive file systems
+ When dealing with case insensitive file systems, ".file line.s" and
+ ".file Line.s" are identical and thus gas won't change the current
+ input file.
+ However, in line.l test, it's expecting to trigger an input file switch.
+ As the second filename doesn't matter in it, change it to fit for those
+ file systems.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/elf/line.l: Change Line.s to Line2.s.
+ * testsuite/gas/elf/line.s: Adjust output.
+
+2023-02-21 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] Enable pointer authentication support for aarch64 bare metal/kernel mode addresses
+ At the moment GDB only handles pointer authentication (pauth) for userspace
+ addresses and if we're debugging a Linux-hosted program.
+
+ The Linux Kernel can be configured to use pauth instructions for some
+ additional security hardening, but GDB doesn't handle this well.
+
+ To overcome this limitation, GDB needs a couple things:
+
+ 1 - The target needs to advertise pauth support.
+ 2 - The hook to remove non-address bits from a pointer needs to be registered
+ in aarch64-tdep.c as opposed to aarch64-linux-tdep.c.
+
+ There is a patch for QEMU that addresses the first point, and it makes
+ QEMU's gdbstub expose a couple more pauth mask registers, so overall we will
+ have up to 4 pauth masks (2 masks or 4 masks):
+
+ pauth_dmask
+ pauth_cmask
+ pauth_dmask_high
+ pauth_cmask_high
+
+ pauth_dmask and pauth_cmask are the masks used to remove pauth signatures
+ from userspace addresses. pauth_dmask_high and pauth_cmask_high masks are used
+ to remove pauth signatures from kernel addresses.
+
+ The second point is easily addressed by moving code around.
+
+ When debugging a Linux Kernel built with pauth with an unpatched GDB, we get
+ the following backtrace:
+
+ #0 __fput (file=0xffff0000c17a6400) at /repos/linux/fs/file_table.c:296
+ #1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
+ #2 0x30008000080ade30 [PAC] in ?? ()
+ #3 0x30d48000080ade30 in ?? ()
+ Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+
+ With a patched GDB, we get something a lot more meaningful:
+
+ #0 __fput (file=0xffff0000c1bcfa00) at /repos/linux/fs/file_table.c:296
+ #1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
+ #2 0xffff8000080ade30 [PAC] in task_work_run () at /repos/linux/kernel/task_work.c:179
+ #3 0xffff80000801db90 [PAC] in resume_user_mode_work (regs=0xffff80000a96beb0) at /repos/linux/include/linux/resume_user_mode.h:49
+ #4 do_notify_resume (regs=regs@entry=0xffff80000a96beb0, thread_flags=4) at /repos/linux/arch/arm64/kernel/signal.c:1127
+ #5 0xffff800008fb9974 [PAC] in prepare_exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:137
+ #6 exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:142
+ #7 el0_svc (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:638
+ #8 0xffff800008fb9d34 [PAC] in el0t_64_sync_handler (regs=<optimized out>) at /repos/linux/arch/arm64/kernel/entry-common.c:655
+ #9 0xffff800008011548 [PAC] in el0t_64_sync () at /repos/linux/arch/arm64/kernel/entry.S:586
+ Backtrace stopped: Cannot access memory at address 0xffff80000a96c0c8
+
+2023-02-21 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: don't output to /dev/null
+ Mingw doesn't have /dev/null and thus "-o /dev/null" will fail.
+ Currently, all the options are checked using this "-o /dev/null",
+ resulting in them being disabled on mingw hosts.
+ Fix that by outputting to a real file for all targets.
+
+ ld/ChangeLog:
+
+ * testsuite/config/default.exp: Replace "-o /dev/null" by a
+ file.
+
+2023-02-21 Alan Modra <amodra@gmail.com>
+
+ Both FAIL and PASS "check sections 2"?
+ * testsuite/ld-checks/checks.exp (check sections 2): Don't
+ continue on with rest of test past first fail.
+
+ ld-libs test on alpha-vms
+ * testsuite/ld-libs/libs.exp: Don't run for alpha-vms.
+
+2023-02-21 Alan Modra <amodra@gmail.com>
+
+ alpha-*-vms missing libraries
+ For this:
+ ./ld-new: cannot find -limagelib: No such file or directory
+ ./ld-new: cannot find -lstarlet: No such file or directory
+ ./ld-new: cannot find -lsys$public_vectors: No such file or directory
+ the logs showed
+ creating dummy tmpdir/libimagelib:
+ creating dummy No
+ creating dummy such
+ etc.
+ So rubbish instead of tmpdir/libimagelib.a and the other required libs.
+
+ * testsuite/config/default.exp: Correct regex detecting missing
+ libraries automatically searched by alpha-dec-vms-ld.
+
+2023-02-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-20 Tom Tromey <tom@tromey.com>
+
+ Redefine FUNCTION in doc.str
+ FUNCTION is identical to func, so simplify doc.str.
+
+ 2023-02-17 Tom Tromey <tom@tromey.com>
+
+ * doc/doc.str (FUNCTION): Call func.
+
+2023-02-20 Tom Tromey <tom@tromey.com>
+
+ Hoist the SECTION comment in opncls.c
+ The opening and closing node in BFD starts:
+
+ File: bfd.info, [...]
+
+ /* Set to N to open the next N BFDs using an alternate id space. */
+ extern unsigned int bfd_use_reserved_id;
+
+ 2.13 Opening and closing BFDs
+ =============================
+
+ That is, there's a stray C comment and declaration before any other
+ text or subsections.
+
+ This occurs because the code fragment for bfd_use_reserved_id comes
+ before the SECTION comment. Hoisting it makes this a little nicer.
+
+ 2023-02-17 Tom Tromey <tom@tromey.com>
+
+ * opncls.c: Hoist the SECTION comment.
+
+2023-02-20 Tom Tromey <tom@tromey.com>
+
+ Don't use chew comments for static functions
+ I found a few static functions in the BFD manual. These can't be
+ called by any user of the library, so I don't think it's useful to put
+ them in the manual. This patch removes the chew markup from their
+ comments.
+
+ 2023-02-17 Tom Tromey <tom@tromey.com>
+
+ * opncls.c (bfd_get_debug_link_info_1, separate_debug_file_exists)
+ (separate_alt_debug_file_exists, find_separate_debug_file)
+ (get_build_id, get_build_id_name, check_build_id_file): Don't use
+ chew comments.
+
+2023-02-20 Tom Tromey <tom@tromey.com>
+
+ Fix formatting of long function description in chew output
+ Currently, if a function description spans a line, the resulting info
+ can look like this:
+
+ -- Function: long bfd_canonicalize_reloc
+ (bfd *abfd, asection *sec, arelent **loc, asymbol **syms); Call the
+ back end associated with the open BFD ABFD and translate the
+ external form of the relocation information attached to SEC into
+ the internal canonical form. Place the table into memory at LOC,
+
+ That is, the function prototype runs together with the text in an ugly
+ way. This patch fixes this by introducing a new primitive, so that
+ the generated Texinfo can be a bit nicer. Now this output looks like:
+
+ -- Function: long bfd_canonicalize_reloc (bfd *abfd, asection *sec,
+ arelent **loc, asymbol **syms);
+ Call the back end associated with the open BFD ABFD and translate
+ the external form of the relocation information attached to SEC
+
+ 2023-02-17 Tom Tromey <tom@tromey.com>
+
+ * doc/doc.str (SYNOPSIS): Use collapse_whitespace.
+ * doc/chew.c (collapse_whitespace): New function.
+ (main): Register collapse_whitespace.
+
+2023-02-20 Andreas Schwab <schwab@suse.de>
+
+ opcodes: style m68k disassembler output
+
+2023-02-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: revert one erroneous bool-ification change
+ Commit 42c13555ff88 ("Change value::m_stack to bool") erroneously
+ changed a `0` to `false` in this call to read_value_memory. This
+ parameter is `LONGEST bit_offset`, it should stay `0`.
+
+ Change-Id: I128df6834cf8055ec6a7051e237e379978d3d651
+
+2023-02-20 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: handle Windows drive letter in a noinit test
+ The regexp in "noinit sections (ld -r)" is skipping the file path before
+ the first ":". However, on Windows, a path can start with "C:". Adjust
+ the regexp to allow such cases.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/noinit-sections-2.l: Allow Windows paths
+ (starting with C:).
+
+2023-02-20 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: adjust to Windows path separator.
+ In some tests, the path reported on Windows will have a \ instead of a
+ /. This occurs when a file is concatened with the search path in
+ ldfile.c.: "ld -Ltmpdir -ltext" will result into "tmpdir\libtext.a".
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/retain5.map: Allow \ path separator.
+ * testsuite/ld-plugin/plugin-10.d: Likewise.
+ * testsuite/ld-plugin/plugin-11.d: Likewise.
+ * testsuite/ld-plugin/plugin-18.d: Likewise.
+ * testsuite/ld-plugin/plugin-19.d: Likewise.
+ * testsuite/ld-plugin/plugin-20.d: Likewise.
+ * testsuite/ld-plugin/plugin-22.d: Likewise.
+
+2023-02-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: Consistency fixes for GDB/MI documentation
+ I noticed two inconsistencies in the GDB/MI documentation, which this
+ commit addresses:
+
+ 1. Each MI command is introduced like this:
+
+ @subheading The @code{-command-name} Command
+
+ Except for a few of the tracing command, which just use:
+
+ @subheading -command-name
+
+ In this commit I've updated all these trace commands to use the
+ more common format.
+
+ 2. Each MI command starts with a @subheading, and then the details
+ of that command are split up using multiple @subsubheading
+ entries.
+
+ Except for a few commands which use @subheading for the top-level
+ command, and then continue to use @subheading for each part of
+ the command description.
+
+ In this commit I've updated these to use @subsubheading where
+ appropriate.
+
+2023-02-20 Nick Clifton <nickc@redhat.com>
+
+ So the linker from producing an export data table when run with --exclude-all-symbols.
+ PR 30004 * pe-dll.c (pe_dll_build_sections): Do not build an edata section if all symbols are being excluded.
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Trust epilogue unwind info for unknown or non-gcc producer
+ Currently we only trust epilogue unwind info only for gcc >= 4.5.0.
+
+ This has the effect that we don't trust epilogue unwind info for:
+ - unknown producers (CU without DW_AT_producer attribute)
+ - non-gcc producers (say, clang).
+
+ Instead, only distrust epilogue unwind info only for gcc < 4.5.0.
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Trust epilogue unwind info for unknown producer (-g0 case)
+ For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with
+ .eh_frame section), start using the dwarf2 unwinder instead of the
+ "amd64 epilogue override" unwinder, by returning true in
+ compunit_epilogue_unwind_valid for cust == nullptr.
+
+ This has effect both on the amd64 and i386 targets, but only add amd64
+ test-case gdb.base/unwind-on-each-insn-amd64-2.exp.
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Add amd64/i386 epilogue override unwinders
+ For amd64 the current frame-unwinders are:
+ ...
+ $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386:x86-64".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ python NORMAL_FRAME
+ amd64 epilogue NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ amd64 sigtramp SIGTRAMP_FRAME
+ amd64 prologue NORMAL_FRAME
+ ...
+
+ For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with
+ .eh_frame section), we'd like to start using the dwarf2 unwinder instead of
+ the "amd64 epilogue" unwinder, by returning true in
+ compunit_epilogue_unwind_valid for cust == nullptr.
+
+ But we'd run into the following problem for a -g0
+ -fno-asynchronous-unwind-tables (without .debug_info and .eh_frame section)
+ exec:
+ - the "amd64 epilogue" unwinder would not run
+ (because compunit_epilogue_unwind_valid () == true)
+ - the dwarf2 unwinder would also not run
+ (because there's no .eh_frame info).
+
+ Fix this by:
+ - renaming the "amd64 epilogue" unwinder to "amd64 epilogue override", and
+ - adding a fallback "amd64 epilogue" after the dwarf unwinders,
+ while making sure that only one of the two is active. Likewise for i386. NFC.
+
+ For amd64, this results in this change:
+ ...
+ $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386:x86-64".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ python NORMAL_FRAME
+ -amd64 epilogue NORMAL_FRAME
+ +amd64 epilogue override NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ +amd64 epilogue NORMAL_FRAME
+ amd64 sigtramp SIGTRAMP_FRAME
+ amd64 prologue NORMAL_FRAME
+ ...
+
+ And for i386:
+ ...
+ $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ iline INLINE_FRAME
+ -i386 epilogue NORMAL_FRAME
+ +i386 epilogue override NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ +i386 epilogue NORMAL_FRAME
+ i386 stack tramp NORMAL_FRAME
+ i386 sigtramp SIGTRAMP_FRAME
+ i386 prologue NORMAL_FRAME
+ ...
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix amd64/i386_stack_frame_destroyed_p
+ The use of compunit_epilogue_unwind_valid in both amd64_stack_frame_destroyed_p
+ and i386_stack_frame_destroyed_p is problematic, in the sense that the
+ functions no longer match their documented behaviour.
+
+ Fix this by moving the use of compunit_epilogue_unwind_valid to
+ amd64_epilogue_frame_sniffer and i386_epilogue_frame_sniffer. No functional
+ changes.
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Factor out compunit_epilogue_unwind_valid
+ Factor out compunit_epilogue_unwind_valid from both
+ amd64_stack_frame_destroyed_p and i386_stack_frame_destroyed_p. No functional
+ changes.
+
+ Also add a comment in the new function about the assumption that in absence of
+ producer information, epilogue unwind info is invalid.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail case in gdb.python/py-record-btrace.exp
+ I came across:
+ ...
+ gdb) PASS: gdb.python/py-record-btrace.exp: prepare record: stepi 100
+ python insn = r.instruction_history^M
+ warning: Non-contiguous trace at instruction 1 (offset = 0x3e10).^M
+ (gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: python insn = r.i\
+ nstruction_history
+ ...
+
+ I'm assuming it's the same root cause as for the already present XFAIL.
+
+ Fix this by recognizing above warning in the xfail regexp.
+
+ Tested on x86_64-linux, although sofar I was not able to trigger the warning
+ again.
+
+ Approved-By: Markus T. Metzger <markus.t.metzger@intel.com>
+
+2023-02-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/schedlock.exp for gcc 4.8.5
+ Since commit 9af467b8240 ("[gdb/testsuite] Fix gdb.threads/schedlock.exp on
+ fast cpu"), the test-case fails for gcc 4.8.5.
+
+ The problem is that for gcc 4.8.5, the commit turned a two-line loop:
+ ...
+ (gdb) next
+ 78 while (*myp > 0)
+ (gdb) next
+ 81 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
+ (gdb) next
+ 78 while (*myp > 0)
+ ...
+ into a three-line loop:
+ ...
+ (gdb) next
+ 83 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
+ (gdb) next
+ 84 cnt++;
+ (gdb) next
+ 85 }
+ (gdb) next
+ 83 MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
+ (gdb)
+ ...
+ and the test-case doesn't expect this.
+
+ Fix this by reverting back to the original loop shape as much as possible by:
+ - removing the cnt++ line
+ - replacing "while (1)" with "while (one)", where one is a volatile variable
+ set to 1.
+
+ Tested on x86_64-linux, using compilers:
+ - gcc 4.8.5, 7.5.0, 12.2.1
+ - clang 4.0.1, 13.0.1
+
+2023-02-20 Alan Modra <amodra@gmail.com>
+
+ In-memory nested archives
+ alpha-linuxecoff has compressed archives that are decompressed to a
+ bfd-in-memory. We'd need to handle quite a lot of corner cases to
+ support nesting of such archives, so just stop it before we run into
+ segfaults later.
+
+ * opncls.c (_bfd_new_bfd_contained_in): Prohibit nested
+ archives in memory.
+
+2023-02-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-19 Tom Tromey <tom@tromey.com>
+
+ Convert contained_in to method
+ This converts contained_in to be a method of block.
+
+ Make block members 'private'
+ This changes block to make the data members 'private'.
+
+ Remove allocate_block and allocate_global_block
+ This removes allocate_block and allocate_global_block in favor of
+ simply calling 'new'.
+
+ Have global_block inherit from block
+ This changes global_block to inherit from block, which is what was
+ always intended.
+
+ Use 'new' for block and global_block
+ This changes block and global_block to add initializers, and then to
+ use 'new' for allocation.
+
+2023-02-19 Tom Tromey <tom@tromey.com>
+
+ Fix memory leak in mdebugread.c
+ mdebugread.c allocates blocks on the heap. However, this is a memory
+ leak if the corresponding objfile is ever destroyed.
+
+ This patch changes this code to use allocate_block instead, fixing a
+ FIXME from 2003.
+
+ I don't know how to test this patch.
+
+2023-02-19 Tom Tromey <tom@tromey.com>
+
+ Remove ALL_BLOCK_SYMBOLS
+ This removes ALL_BLOCK_SYMBOLS in favor of foreach.
+
+ Remove ALL_BLOCK_SYMBOLS_WITH_NAME
+ This removes ALL_BLOCK_SYMBOLS_WITH_NAME in favor of foreach.
+
+ Convert explicit iterator uses to foreach
+ This converts most existing explicit uses of block_iterator to use
+ foreach with the range iterator instead.
+
+ Introduce a block iterator wrapper
+ This introduces a C++-style iterator that wraps the existing
+ block_iterator. It also adds a range adapter. These will be used in
+ a later patch.
+
+ Combine both styles of block iterator
+ This merges the two styles of block iterator, having the
+ initialization API decide which to use based on an optional parameter.
+
+ Store 'name' in block_iterator
+ This changes the block_iterator to store the 'name' that is used by
+ block_iter_match_next. This avoids any problem where the name could
+ be passed inconsistently, and also makes the subsequent patches easier
+ to understand.
+
+ Convert block_static_link to method
+ This converts block_static_link to be a method. This was mostly
+ written by script.
+
+ Convert set_block_compunit_symtab to method
+ This converts set_block_compunit_symtab to be a method. This was
+ mostly written by script.
+
+ Convert block_static_block and block_global_block to methods
+ This converts block_static_block and block_global_block to be methods.
+ This was mostly written by script. It was simpler to convert them at
+ the same time because they're often used near each other.
+
+ Convert block_containing_function to method
+ This converts block_containing_function to be a method. This was
+ mostly written by script.
+
+ Convert block_linkage_function to method
+ This converts block_linkage_function to be a method. This was mostly
+ written by script.
+
+ Convert more block functions to methods
+ This converts block_scope, block_set_scope, block_using, and
+ block_set_using to be methods. These are all done at once to make it
+ easier to also convert block_initialize_namespace at the same time.
+ This was mostly written by script.
+
+ Convert block_inlined_p to method
+ This converts block_inlined_p to be a method. This was mostly written
+ by script.
+
+ Convert block_gdbarch to method
+ This converts block_gdbarch to be a method. This was mostly written
+ by script.
+
+ Convert block_objfile to method
+ This converts block_objfile to be a method. This was mostly written
+ by script.
+
+ Don't allow NULL as an argument to block_global_block
+ block_global_block has special behavior when the block is NULL.
+ Remove this and patch up the callers instead.
+
+ Don't allow NULL as an argument to block_static_block
+ block_static_block has special behavior when the block is NULL.
+ Remove this and patch up the callers instead.
+
+ Don't allow NULL as an argument to block_using
+ block_using has special behavior when the block is NULL.
+ Remove this. No caller seems to be affected.
+
+ Don't allow NULL as an argument to block_scope
+ block_scope has special behavior when the block is NULL.
+ Remove this and patch up the callers instead.
+
+ Avoid extra allocations in block
+ block_set_scope and block_set_using unconditionally allocate the block
+ namespace object. However, this isn't truly needed, so arrange to
+ only allocate when it is.
+
+ Rearrange block.c to avoid a forward declaration
+ Moving block_initialize_namespace before its callers lets us avoid a
+ forward declaration.
+
+2023-02-19 Alan Modra <amodra@gmail.com>
+
+ Buffer overflow in evax_bfd_print_eobj
+ * vms-alpha.c (evax_bfd_print_eobj): Rewrite header handling,
+ sanity checking rec_len. Check bfd_malloc return.
+
+2023-02-19 Tom Tromey <tom@tromey.com>
+
+ Avoid memory leak in chew
+ An earlier patch of mine introduced a memory leak in chew. The bug
+ was that the new "variable" word didn't free the following word. This
+ patch fixes it by arranging to transfer ownership of the name to the
+ variable itself.
+
+ * doc/chew.c (add_variable): New function, from
+ add_intrinsic_variable.
+ (add_intrinsic_variable): Call add_variable.
+ (compile): Call add_variable.
+
+2023-02-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-18 Tom Tromey <tom@tromey.com>
+
+ Fix "start" for D, Rust, etc
+ The new DWARF indexer broke "start" for some languages.
+
+ For D, it is broken because, while the code in cooked_index_shard::add
+ specifically excludes Ada, it fails to exclude D. This means that the
+ C "main" will be detected as "main" here -- whereas what is intended
+ is for the code in find_main_name to use d_main_name to find the name.
+
+ The Rust compiler, on the other hand, uses DW_AT_main_subprogram.
+ However, the code in dwarf2_build_psymtabs_hard fails to create a
+ fully-qualified name, so the name always ends up as plain "main".
+
+ For D and Ada, a very simple approach suffices: remove the check
+ against "main" from cooked_index_shard::add. This also has the
+ benefit of slightly speeding up DWARF indexing. I assume this
+ approach will work for Pascal and Modula-2 as well, but I don't have a
+ way to test those at present.
+
+ For Rust, though, this is not sufficient. And, computing the
+ fully-qualified name in dwarf2_build_psymtabs_hard will crash, because
+ cooked_index_entry::full_name uses the canonical name -- and that is
+ not computed until after canonicalization.
+
+ However, we don't want to wait for canonicalization to be done before
+ computing the main name. That would remove any benefit from doing
+ canonicalization is the background.
+
+ This patch solves this dilemma by noticing that languages using
+ DW_AT_main_subprogram are, currently, disjoint from languages
+ requiring canonicalization. Because of this, we can add a parameter
+ to full_name to let us avoid crashes, slowdowns, and races here.
+
+ This is kind of tricky and ugly, so I've tried to comment it
+ sufficiently.
+
+ While doing this, I had to change gdb.dwarf2/main-subprogram.exp. A
+ different possibility here would be to ignore the canonicalization
+ needs of C in this situation, because those only affect certain types.
+ However, I chose this approach because the test case is artificial
+ anyhow.
+
+ A long time ago, in an earlier threading attempt, I changed the global
+ current_language to be a function (hidden behind a macro) to let us
+ attempt lazily computing the current language. Perhaps this approach
+ could still be made to work. However, that also seemed rather tricky,
+ more so than this patch.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116
+
+2023-02-18 Tom Tromey <tom@tromey.com>
+
+ Fix crash in go_symbol_package_name
+ go_symbol_package_name package name asserts that it is only passed a
+ Go symbol, but this is not enforced by one caller. It seems simplest
+ to just check and return early in this case.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17876
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-18 Tom Tromey <tom@tromey.com>
+
+ Avoid manual memory management in go-lang.c
+ I noticed a couple of spots in go-lang.c that could be improved by
+ using unique_ptr.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix regression in gdb.xml/maint_print_struct.exp
+ A regression in gdb.xml/maint_print_struct.exp was introduced with
+ commit:
+
+ commit 81b86eced24f905545b58aa6c27478104c364976
+ Date: Fri Jan 6 09:30:40 2023 -0700
+
+ Do not record a rejected target description
+
+ The test relied on an invalid target description being stored within
+ the tdesc_info of the current inferior, the above commit stopped this
+ behaviour.
+
+ Update the test to check that the invalid architecture is NOT stored,
+ and then check printing the target description directly from the
+ file.
+
+ Approved-By: Tom Tromey <tromey@adacore.com>
+
+2023-02-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix Dwarf reader for DW_TAG_subprogram
+ gprofng/ChangeLog
+ 2023-02-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Dwarf.cc: Skip DW_TAG_subprogram when DW_AT_declaration is 1.
+
+2023-02-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR30036 Build failure on aarch64 w/ glibc: symbol `pwrite64' is already defined
+ gprofng/ChangeLog
+ 2023-02-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30036
+ * libcollector/iotrace.c: Define creat64 and pwrite64 only when
+ __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not defined.
+ * libcollector/mmaptrace.c: Likewise for mmap64.
+
+2023-02-17 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix multi-threaded debugging under AIX
+ Multi-threaded debugging using the libpthdebug debug interface
+ is currently broken due to multiple issues.
+
+ When debugging a single inferior, we were getting assertion
+ failures in get_aix_thread_info as no tp->priv structure was
+ allocated for the main thread.
+
+ We fixed this by switching the main
+ thread from a (pid, 0, 0) ptid_t to a (pid, 0, tid) ptid_t and
+ allocaing the tp->priv structure in sync_threadlists.
+
+ As a result, the switch_to_thread call in pdc_read_data could
+ now fail since the main thread no longer uses (pid, 0, 0).
+
+ So we replaced the call by only switching inferior_ptid, the current
+ inferior, and the current address space (like proc-service.c).
+ Add similar switching to pdc_write_data where it was missing
+ completely.
+
+ When debugging multiple inferiors, an additional set of
+ problems prevented correct multi-threaded debugging:
+
+ First of all, aix-thread.c used to have a number of global
+ variables holding per-inferior information.
+
+ We switched hese
+ to a per-inferior data structure instead.
+
+ Also, sync_threadlists was getting confused as we were
+ comparing the list of threads returned by libpthdebug
+ for *one* process with GDB's list of threads for *all*
+ processes. Now we only use he GDB threads of the current
+ inferior instead.
+
+ We also skip calling pd_activate
+ from pd_enable if that in_initial_library_scan flag is
+ true for the current inferior.
+
+ Finally, the presence of the thread library in any but
+ the first inferior was not correctly detected due to a
+ bug in solib-aix.c, where the BFD file name for shared
+ library members was changed when the library was loaded
+ for the first time, which caused the library to no longer
+ be recognized by name when loaded a second time.
+
+2023-02-17 Tom Tromey <tromey@adacore.com>
+
+ Remove two unnecessary returns in ada-lang.c
+ I found a couple of spots in ada-lang.c where a return follows a call
+ to error. These are unnecessary because error never returns.
+
+2023-02-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Simplify gdb.arch/amd64-disp-step-avx.exp
+ On SLE-11, with glibc 2.11.3, I run into:
+ ...
+ (gdb) PASS: gdb.arch/amd64-disp-step-avx.exp: vex3: \
+ var128 has expected value after
+ continue^M
+ Continuing.^M
+ ^M
+ Program received signal SIGSEGV, Segmentation fault.^M
+ 0x0000000000400283 in _exit (status=0) at \
+ ../sysdeps/unix/sysv/linux/_exit.c:33^M
+ 33 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.^M
+ (gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: \
+ continue until exit at amd64-disp-step-avx
+ ...
+
+ This is not related to gdb, we get the same result by just running the exec.
+
+ The problem is that the test-case:
+ - calls glibc's _exit, and
+ - uses -nostartfiles -static, putting the burden for any necessary
+ initialization for calling glibc's _exit on the test-case itself.
+
+ So, when we get to the second insn in _exit:
+ ...
+ 000000000040acb0 <_exit>:
+ 40acb0: 48 63 d7 movslq %edi,%rdx
+ 40acb3: 64 4c 8b 14 25 00 00 mov %fs:0x0,%r10
+ ...
+ no glibc-related initialization is done, and we run into the segfault.
+
+ Adding this (borrowed from __libc_start_main) in _start in the .S file is
+ sufficient to fix it:
+ ...
+ .rept 200
+ nop
+ + call __pthread_initialize_minimal
+ .endr
+ ...
+ But that already doesn't compile with say glibc 2.31, and regardless I think
+ this sort of fix is too fragile.
+
+ We could of course fix this by simply not running to exit. But ideally we'd
+ have an exec that doesn't segfault when you just run it.
+
+ Alternatively, we could hand-code an _exit syscall and bypass glibc
+ all together. But I'd rather fix this in a way that simplifies the test-case.
+
+ Taking a step back, the -nostartfiles -static was added to address that the
+ xmm registers were not zero at main (which AFAICT is a valid thing to happen).
+
+ [ The change itself silently broke the test-case, needing further fixing by
+ commit 40310f30a51 ("gdb: make gdb.arch/amd64-disp-step-avx.exp actually test
+ displaced stepping"). ]
+
+ Instead, simplify things by reverting to the original situation:
+ - no -nostartfiles -static compilation flags,
+ - no _start in the .S file,
+ - use exit instead of _exit in the .S file,
+ and fix the original problem by setting the xmm registers to zero rather than
+ checking that they're zero.
+
+ Now that we're no longer forcing -static, add nopie to the flags to prevent
+ compilation failure with target board unix/-fPIE/-pie.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30132
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30132
+
+2023-02-17 Alan Modra <amodra@gmail.com>
+
+ ld test asciz and ascii fails
+ Fix these fails:
+ alpha-dec-vms +FAIL: ld-scripts/asciz
+ alpha-dec-vms +FAIL: ld-scripts/ascii
+ i386-go32 +FAIL: ld-scripts/asciz
+ sh-coff +FAIL: ld-scripts/asciz
+
+ It's better to positively select targets for .section support than to
+ try to exclude all targets that don't. Make a new is_coff_format so
+ we can easily select such.
+
+ binutils/
+ * testsuite/lib/binutils-common.exp (is_coff_format): New.
+ ld/
+ * testsuite/ld-scripts/ascii.d: Use is_elf_format and
+ is_coff_format to select targets, exclude ti coff.
+ * testsuite/ld-scripts/asciz.d: Likewise. Accept trailing zeros.
+
+2023-02-17 Alan Modra <amodra@gmail.com>
+
+ Wild pointer reads in _bfd_ecoff_locate_line
+ * ecofflink.c (mk_fdrtab): Sanity check fdr procedure descriptor
+ pointer and isymBase. Set fdrtab_len after possible discards.
+ Use size_t vars and catch possible size overflows.
+
+2023-02-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-16 Alan Modra <amodra@gmail.com>
+
+ PR30046, power cmpi leads to unknown architecture
+ PowerPC ELF always uses bfd_arch_powerpc, so we shouldn't allow the
+ gas -mpwr, -mpwr2 or -mpwrx options to choose bfd_arch_rs6000.
+ Given the possible values of ppc_cpu, I think the as_fatal at the end
+ of ppc_arch will never be reached, so it can be deleted and the code
+ simplified a little.
+
+ PR 30046
+ * config/tc-ppc.c (ppc_arch): Return bfd_arch_powerpc for ELF.
+ Delete dead code.
+
+2023-02-16 Tom Tromey <tromey@adacore.com>
+
+ Rename parameter of create_ada_exception_catchpoint
+ create_ada_exception_catchpoint has a parameter named "disabled", but
+ both its callers and callees use it to mean "enabled". This is
+ confusing, so this patch renames the parameter.
+
+2023-02-16 Tom Tromey <tom@tromey.com>
+
+ Update the 'g' packet documentation
+ The 'g' packet documentation references a macro that no longer exists,
+ and it also claims that the 'x' response for an unavailable register
+ is limited to trace frames. This patch updates the documentation to
+ reflect what I think is currently correct.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Change-Id: I863baa3b9293059cfd4aa3d534602cbcb693ba87
+
+2023-02-16 Nick Clifton <nickc@redhat.com>
+
+ Add support for the ASCII directive inside linker scripts.
+ * ldlex.l: Add ASCII token.
+ * ldgram.y: Add parsing of the ASCII command.
+ * ldlang.c (lang_add_string): Add maximum size parameter. Move escape character handling code into separate function.
+ * ldlang.h (lang_add_string): Update prototype.
+ * NEWS: Mention the new feature.
+ * ld.texi (Output Section Data): Document the new directives.
+ * testsuite/ld-scripts/asciz.t: Adjust to work on more architectures and to test more aspects of the ASCIZ directive.
+ * testsuite/ld-scripts/asciz.d: Adjust to match the changes to the test linker script.
+ * testsuite/ld-scripts/ascii.d: New test driver.
+ * testsuite/ld-scripts/ascii.s: New test assembler source.
+ * testsuite/ld-scripts/ascii.t: New test script.
+ * testsuite/ld-scripts/script.exp: Run the new test.
+
+2023-02-16 Tom Tromey <tromey@adacore.com>
+
+ Constify ada_main_name
+ Unlike the other *_main_name functions, ada_main_name returns a
+ non-const "char *". This is strange, though, because the caller
+ should not in fact modify or free this pointer. This patch changes
+ this function to constify its return type.
+
+ Remove unused declaration from ada-lang.h
+ I stumbled across this declaration in ada-lang.h. I don't know what
+ function did, but it no longer exists, so remove the declaration.
+ Tested by rebuilding.
+
+2023-02-16 Alan Modra <amodra@gmail.com>
+
+ Delete PROGRESS macros
+ I don't see much point in cluttering the source with the PROGRESS
+ macros, which of course do nothing at all with the definitions in
+ progress.h. progress.h is unchanged apart from the copyright comment
+ since commit d4d4c53c68f0 in 1994.
+
+ binutils/
+ * ar.c: Don't include progress.h, or invoke PROGRESS macros.
+ * nm.c: Likewise.
+ * objcopy.c: Likewise.
+ * objdump.c: Likewise.
+ gas/
+ * as.h: Don't include progress.h.
+ * as.c: Don't invoke PROGRESS macros.
+ * write.c: Likewise.
+ include/
+ * progress.h: Delete.
+ ld/
+ * ldmain.c: Don't include progress.h, or invoke PROGRESS macros.
+
+2023-02-16 Alan Modra <amodra@gmail.com>
+
+ gas_init
+ Rename gas_late_init to plain gas_init, to reinforce the idea that
+ this is where the bulk of gas initialisation belongs. Also reorder
+ some initialisation.
+
+ * as.c (gas_init): Rename from gas_late_init. Open output
+ file and arrange for dump_statistics to be called here rather
+ than in main. Create .gasversion. local symbol earlier,
+ because we can.
+
+2023-02-16 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: as_warn() already emits a newline
+ Therefore there shouldn't be any at the end of the format string.
+
+2023-02-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: document MI -remove-inferior command
+ Back in 2010 the -remove-inferior command was added in commit
+ a79b8f6ea8c2, unfortunately this command was never added to the
+ documentation.
+
+ This commit addresses that oversight.
+
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-02-16 Jan Beulich <jbeulich@suse.com>
+
+ x86/gas: replace inappropriate assertion when parsing registers
+ PR gas/30117
+ Once a symbol had its expression evaluated, the "segment" of the symbol
+ may be reg_section if a register is merely involved in the expression,
+ not just when the expression references a "plain" register. Therefore
+ the first of the assertions put in place by 4d1bb7955a8b was too strict.
+ Convert it to an if() to deal with situations like this one found by
+ fuzzing:
+
+ x=s
+ s=%eax+0
+ y=s
+ or $6,x
+
+ In non-debug builds this also avoids potentially silently generating bad
+ code.
+
+2023-02-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Return bool from more value methods
+ There are several more value methods that currently return 'int' but
+ that should return 'bool'. This patch updates these.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Have value::bits_synthetic_pointer return bool
+ This changes value::bits_synthetic_pointer to return bool and fixes up
+ some fallout from this.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Change value::m_stack to bool
+ This changes value::m_stack to be a bool and updates the various uses.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Change value::m_initialized to bool
+ This changes value::m_initialized to be a bool and updates the various
+ uses.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Change value::m_lazy to bool
+ This changes value::m_lazy to be a bool and updates the various uses.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Change value::m_modifiable to bool
+ This changes value::m_modifiable to be a bool and updates the various
+ uses.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ Don't throw quit while handling inferior events, part II
+ I noticed that if Ctrl-C was typed just while GDB is evaluating a
+ breakpoint condition in the background, and GDB ends up reaching out
+ to the Python interpreter, then the breakpoint condition would still
+ fail, like:
+
+ c&
+ Continuing.
+ (gdb) Error in testing breakpoint condition:
+ Quit
+
+ That happens because while evaluating the breakpoint condition, we
+ enter Python, and end up calling PyErr_SetInterrupt (it's called by
+ gdbpy_set_quit_flag, in frame #0):
+
+ (top-gdb) bt
+ #0 gdbpy_set_quit_flag (extlang=0x558c68f81900 <extension_language_python>) at ../../src/gdb/python/python.c:288
+ #1 0x0000558c6845f049 in set_quit_flag () at ../../src/gdb/extension.c:785
+ #2 0x0000558c6845ef98 in set_active_ext_lang (now_active=0x558c68f81900 <extension_language_python>) at ../../src/gdb/extension.c:743
+ #3 0x0000558c686d3e56 in gdbpy_enter::gdbpy_enter (this=0x7fff2b70bb90, gdbarch=0x558c6ab9eac0, language=0x0) at ../../src/gdb/python/python.c:212
+ #4 0x0000558c68695d49 in python_on_memory_change (inferior=0x558c6a830b00, addr=0x555555558014, len=4, data=0x558c6af8a610 "") at ../../src/gdb/python/py-inferior.c:146
+ #5 0x0000558c6823a071 in std::__invoke_impl<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__f=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:61
+ #6 0x0000558c68237591 in std::__invoke_r<void, void (*&)(inferior*, unsigned long, long, unsigned char const*), inferior*, unsigned long, long, unsigned char const*> (__fn=@0x558c6a8ecd98: 0x558c68695d01 <python_on_memory_change(inferior*, CORE_ADDR, ssize_t, bfd_byte const*)>) at /usr/include/c++/11/bits/invoke.h:111
+ #7 0x0000558c68233e64 in std::_Function_handler<void (inferior*, unsigned long, long, unsigned char const*), void (*)(inferior*, unsigned long, long, unsigned char const*)>::_M_invoke(std::_Any_data const&, inferior*&&, unsigned long&&, long&&, unsigned char const*&&) (__functor=..., __args#0=@0x7fff2b70bd40: 0x558c6a830b00, __args#1=@0x7fff2b70bd38: 93824992247828, __args#2=@0x7fff2b70bd30: 4, __args#3=@0x7fff2b70bd28: 0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:290
+ #8 0x0000558c6830a96e in std::function<void (inferior*, unsigned long, long, unsigned char const*)>::operator()(inferior*, unsigned long, long, unsigned char const*) const (this=0x558c6a8ecd98, __args#0=0x558c6a830b00, __args#1=93824992247828, __args#2=4, __args#3=0x558c6af8a610 "") at /usr/include/c++/11/bits/std_function.h:590
+ #9 0x0000558c6830a620 in gdb::observers::observable<inferior*, unsigned long, long, unsigned char const*>::notify (this=0x558c690828c0 <gdb::observers::memory_changed>, args#0=0x558c6a830b00, args#1=93824992247828, args#2=4, args#3=0x558c6af8a610 "") at ../../src/gdb/../gdbsupport/observable.h:166
+ #10 0x0000558c68309d95 in write_memory_with_notification (memaddr=0x555555558014, myaddr=0x558c6af8a610 "", len=4) at ../../src/gdb/corefile.c:363
+ #11 0x0000558c68904224 in value_assign (toval=0x558c6afce910, fromval=0x558c6afba6c0) at ../../src/gdb/valops.c:1190
+ #12 0x0000558c681e3869 in expr::assign_operation::evaluate (this=0x558c6af8e150, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/expop.h:1902
+ #13 0x0000558c68450c89 in expr::logical_or_operation::evaluate (this=0x558c6afab060, expect_type=0x0, exp=0x558c6afcfe60, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:2330
+ #14 0x0000558c6844a896 in expression::evaluate (this=0x558c6afcfe60, expect_type=0x0, noside=EVAL_NORMAL) at ../../src/gdb/eval.c:110
+ #15 0x0000558c6844a95e in evaluate_expression (exp=0x558c6afcfe60, expect_type=0x0) at ../../src/gdb/eval.c:124
+ #16 0x0000558c682061ef in breakpoint_cond_eval (exp=0x558c6afcfe60) at ../../src/gdb/breakpoint.c:4971
+ ...
+
+
+ The fix is to disable cooperative SIGINT handling while handling
+ inferior events, so that SIGINT is saved in the global quit flag, and
+ not in the extension language, while handling an event.
+
+ This commit augments the testcase added by the previous commit to test
+ this scenario as well.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Idf8ab815774ee6f4b45ca2d0caaf30c9b9f127bb
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ GC get_active_ext_lang
+ get_active_ext_lang is not used anywhere. Delete it.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I4c2b6d0d11291103c098e4db1d6ea449875c96b7
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ Don't throw quit while handling inferior events
+ This implements what I suggested here:
+
+ https://inbox.sourceware.org/gdb-patches/ab97c553-f406-b094-cdf3-ba031fdea925@palves.net/
+
+ Here is the current default quit_handler, a function that ends up
+ called by the QUIT macro:
+
+ void
+ default_quit_handler (void)
+ {
+ if (check_quit_flag ())
+ {
+ if (target_terminal::is_ours ())
+ quit ();
+ else
+ target_pass_ctrlc ();
+ }
+ }
+
+ As we can see above, when the inferior is running in the foreground,
+ then a Ctrl-C is translated into a call to target_pass_ctrlc().
+
+ The target_terminal::is_ours() case above is there to handle the
+ scenario where GDB has the terminal, meaning it is handling some
+ command the user typed, like "list", or "p a + b" or some such.
+
+ However, when the inferior is running on the background, say with
+ "c&", GDB also has the terminal. Run control handling is now done in
+ the "background". The CLI is responsive to user commands. If users
+ type Ctrl-C, they're expecting it to interrupt whatever command they
+ next type in the CLI, which again, could be "list", "p a + b", etc.
+ It's as if background run control was handled by a separate thread,
+ and the Ctrl-C is meant to go to the main thread, handling the CLI.
+
+ However, when handling an event, inside fetch_inferior_event &
+ friends, a Ctrl-C _also_ results in a Quit exception, from the same
+ default_quit_handler function shown above. This quit aborts run
+ control handling, breakpoint condition evaluation, etc., and may even
+ leave run control in an inconsistent state.
+
+ The testcase added by this patch illustrates this. The test program
+ just loops a number of times calling the "foo" function.
+
+ The idea is to set a breakpoint in the "foo" function with a condition
+ that sends SIGINT to GDB, and then evaluates to false, which results
+ in the program being re-resumed in the background. The SIGINT-sending
+ emulates pressing Ctrl-C just while GDB was evaluating the breakpoint
+ condition, except, it's more deterministic.
+
+ It looks like this:
+
+ (gdb) p $counter = 0
+ $1 = 0
+ (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
+ Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21.
+ (gdb) c&
+ Continuing.
+ (gdb)
+
+ After that background continue, the breakpoint should be hit 10 times,
+ and we should see 10 "Quit" being printed on the screen. As if the
+ user typed Ctrl-C on the prompt a number of times with no inferior
+ running:
+
+ (gdb) <<< Ctrl-C
+ (gdb) Quit <<< Ctrl-C
+ (gdb) Quit <<< Ctrl-C
+ (gdb)
+
+ However, here's what you see instead:
+
+ (gdb) c&
+ Continuing.
+ (gdb) Quit
+ (gdb)
+
+ Just one Quit, and nothing else. If we look at the thread's state, we see:
+
+ (gdb) info threads
+ Id Target Id Frame
+ * 1 Thread 0x7ffff7d6f740 (LWP 112192) "bg-exec-sigint-" foo () at gdb.base/bg-exec-sigint-bp-cond.c:21
+
+ So the thread stopped, but we didn't report a stop...
+
+ Issuing another continue shows the same immediate-and-silent-stop:
+
+ (gdb) c&
+ Continuing.
+ (gdb) Quit
+ (gdb) p $counter
+ $2 = 2
+
+ As mentioned, since the run control handling, and breakpoint and
+ watchpoint evaluation, etc. are running in the background from the
+ perspective of the CLI, when users type Ctrl-C in this situation,
+ they're thinking of aborting whatever other command they were typing
+ or running at the prompt, not the run control side, not the previous
+ "c&" command.
+
+ So I think that we should install a custom quit_handler while inside
+ fetch_inferior_event, where we already disable pagination and other
+ things for a similar reason. This custom quit handler does nothing if
+ GDB has the terminal, and forwards Ctrl-C to the inferior otherwise.
+
+ With the patch implementing that, and the same testcase, here's what
+ you see instead:
+
+ (gdb) p $counter = 0
+ $1 = 0
+ (gdb) b foo if $counter++ == 10 || $_shell("kill -SIGINT `pidof gdb`") != 0
+ Breakpoint 2 at 0x555555555131: file gdb.base/bg-exec-sigint-bp-cond.c, line 21.
+ (gdb) c&
+ Continuing.
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb) Quit
+ (gdb)
+ Breakpoint 2, foo () at gdb.base/bg-exec-sigint-bp-cond.c:21
+ 21 return 0;
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I1f10d99496a7d67c94b258e45963e83e439e1778
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ Add new "$_shell(CMD)" internal function
+ For testing a following patch, I wanted a way to send a SIGINT to GDB
+ from a breakpoint condition. And I didn't want to do it from a Python
+ breakpoint or Python function, as I wanted to exercise non-Python code
+ paths. So I thought I'd add a new $_shell internal function, that
+ runs a command under the shell, and returns the exit code. With this,
+ I could write:
+
+ (gdb) b foo if $_shell("kill -SIGINT $gdb_pid") != 0 || <other condition>
+
+ I think this is generally useful, hence I'm proposing it here.
+
+ Here's the new function in action:
+
+ (gdb) p $_shell("true")
+ $1 = 0
+ (gdb) p $_shell("false")
+ $2 = 1
+ (gdb) p $_shell("echo hello")
+ hello
+ $3 = 0
+ (gdb) p $_shell("foobar")
+ bash: line 1: foobar: command not found
+ $4 = 127
+ (gdb) help function _shell
+ $_shell - execute a shell command and returns the result.
+ Usage: $_shell (command)
+ Returns the command's exit code: zero on success, non-zero otherwise.
+ (gdb)
+
+ NEWS and manual changes included.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Approved-By: Eli Zaretskii <eliz@gnu.org>
+ Change-Id: I7e36d451ee6b428cbf41fded415ae2d6b4efaa4e
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ Make "ptype INTERNAL_FUNCTION" in Ada print like other languages
+ Currently, printing the type of an internal function in Ada shows
+ double <>s, like:
+
+ (gdb) with language ada -- ptype $_isvoid
+ type = <<internal function>>
+
+ while all other languages print it with a single <>, like:
+
+ (gdb) with language c -- ptype $_isvoid
+ type = <internal function>
+
+ I don't think there's a reason that Ada needs to be different. We
+ currently print the double <>s because we take this path in
+ ada_print_type:
+
+ switch (type->code ())
+ {
+ default:
+ gdb_printf (stream, "<");
+ c_print_type (type, "", stream, show, level, language_ada, flags);
+ gdb_printf (stream, ">");
+ break;
+
+ ... and the type's name already has the <>s.
+
+ Fix this by simply adding an early check for
+ TYPE_CODE_INTERNAL_FUNCTION.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: Ic2b6527b9240a367471431023f6e27e6daed5501
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ Fix "ptype INTERNAL_FUNC" (PR gdb/30105)
+ Currently, looking at the type of an internal function, like below,
+ hits an odd error:
+
+ (gdb) ptype $_isvoid
+ type = <internal function>type not handled in c_type_print_varspec_prefix()
+
+ That is an error thrown from
+ c-typeprint.c:c_type_print_varspec_prefix, where it reads:
+
+ ...
+ case TYPE_CODE_DECFLOAT:
+ case TYPE_CODE_FIXED_POINT:
+ /* These types need no prefix. They are listed here so that
+ gcc -Wall will reveal any types that haven't been handled. */
+ break;
+ default:
+ error (_("type not handled in c_type_print_varspec_prefix()"));
+ break;
+
+ Internal function types have type code TYPE_CODE_INTERNAL_FUNCTION,
+ which is not explicitly handled by that switch.
+
+ That comment quoted above says that gcc -Wall will reveal any types
+ that haven't been handled, but that's not actually true, at least with
+ modern GCCs. You would need to enable -Wswitch-enum for that, which
+ we don't. If I do enable that warning, then I see that we're missing
+ handling for the following type codes:
+
+ TYPE_CODE_INTERNAL_FUNCTION,
+ TYPE_CODE_MODULE,
+ TYPE_CODE_NAMELIST,
+ TYPE_CODE_XMETHOD
+
+ TYPE_CODE_MODULE and TYPE_CODE_NAMELIST and Fortran-specific, so it'd
+ be a little weird to handle them here.
+
+ I tried to reach this code with TYPE_CODE_XMETHOD, but couldn't figure
+ out how to. ptype on an xmethod isn't treated specially, it just
+ complains that the method doesn't exist. I've extended the
+ gdb.python/py-xmethods.exp testcase to make sure of that.
+
+ My thinking is that whatever type code we add next, the most likely
+ scenario is that it won't need any special handling, so we'd just be
+ adding another case to that "do nothing" list. If we do need special
+ casing for whatever type code, I think that tests added at the same
+ time as the feature would uncover it anyhow. If we do miss adding the
+ special casing, then it still looks better to me to print the type
+ somewhat incompletely than to error out and make it harder for users
+ to debug whatever they need. So I think that the best thing to do
+ here is to just remove all those explicit "do nothing" cases, along
+ with the error default case.
+
+ After doing that, I decided to write a testcase that iterates over all
+ supported languages doing "ptype INTERNAL_FUNC". That revealed that
+ Pascal has a similar problem, except the default case hits a
+ gdb_assert instead of an error:
+
+ (gdb) with language pascal -- ptype $_isvoid
+ type =
+ ../../src/gdb/p-typeprint.c:268: internal-error: type_print_varspec_prefix: unexpected type
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+
+ That is fixed by this patch in the same way.
+
+ You'll notice that the new testcase special-cases the Ada expected
+ output:
+
+ } elseif {$lang == "ada"} {
+ gdb_test "ptype \$_isvoid" "<<internal function>>"
+ } else {
+ gdb_test "ptype \$_isvoid" "<internal function>"
+ }
+
+ That will be subject of the following patch.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I81aec03523cceb338b5180a0b4c2e4ad26b4c4db
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30105
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf2: split .debug_names reading code to own file
+ Move everything related to reading .debug_names from read.c to
+ read-debug-names.c. The only entry point exposed by
+ read-debug-names.{c,h} is dwarf2_read_debug_names.
+
+ Change-Id: I18b23f3c7a61b14abc3a46e4bf559bc2d078e8bc
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf2: split .gdb_index reading code to own file
+ Move everything related to reading .gdb_index from read.c to
+ read-gdb-index.c. The only entry point exposed by read-gdb-index.{c,h}
+ is dwarf2_read_gdb_index.
+
+ Change-Id: I1e32c8f0720086538de8d2f612f27545377099bc
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf2: move some things to read.h
+ The following 2 patches move .gdb_index and .debug_names reading code to
+ their own file. Prepare this by exposing some things used by that code
+ to read.h.
+
+ Change-Id: If8ef135758a2ff0ab3b765cc92596da8189f3bbd
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix dealloc function not being called for frame 0
+ Tom de Vries reported [1] a regression in gdb.btrace/record_goto.exp
+ caused by 6d3717d4c4 ("gdb: call frame unwinders' dealloc_cache methods
+ through destroying the frame cache"). This issue is caught by ASan. On
+ a non-ASan build, it may or may not cause a crash or some other issue, I
+ haven't tried.
+
+ I managed to narrow it down to:
+
+ $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.btrace/record_goto/record_goto -ex "start" -ex "record btrace" -ex "next"
+
+ ... and then doing repeatedly "record goto 19" and "record goto 27".
+ Eventually, I get:
+
+ (gdb) record goto 27
+ =================================================================
+ ==1527735==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003392a8 at pc 0x55e4c26eef86 bp 0x7ffd229f24e0 sp 0x7ffd229f24d8
+ READ of size 8 at 0x6210003392a8 thread T0
+ #0 0x55e4c26eef85 in bfcache_eq /home/simark/src/binutils-gdb/gdb/record-btrace.c:1639
+ #1 0x55e4c37cdeff in htab_find_slot_with_hash /home/simark/src/binutils-gdb/libiberty/hashtab.c:659
+ #2 0x55e4c37ce24a in htab_find_slot /home/simark/src/binutils-gdb/libiberty/hashtab.c:703
+ #3 0x55e4c26ef0c6 in bfcache_new /home/simark/src/binutils-gdb/gdb/record-btrace.c:1653
+ #4 0x55e4c26f1242 in record_btrace_frame_sniffer /home/simark/src/binutils-gdb/gdb/record-btrace.c:1820
+ #5 0x55e4c1b926a1 in frame_unwind_try_unwinder /home/simark/src/binutils-gdb/gdb/frame-unwind.c:136
+ #6 0x55e4c1b930d7 in frame_unwind_find_by_frame(frame_info_ptr, void**) /home/simark/src/binutils-gdb/gdb/frame-unwind.c:196
+ #7 0x55e4c1bb867f in get_frame_type(frame_info_ptr) /home/simark/src/binutils-gdb/gdb/frame.c:2925
+ #8 0x55e4c2ae6798 in print_frame_info(frame_print_options const&, frame_info_ptr, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:1049
+ #9 0x55e4c2ade3e1 in print_stack_frame(frame_info_ptr, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:367
+ #10 0x55e4c26fda03 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2779
+ #11 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
+ #12 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
+ #13 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
+ #14 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383
+
+ 0x6210003392a8 is located 424 bytes inside of 4064-byte region [0x621000339100,0x62100033a0e0)
+ freed by thread T0 here:
+ #0 0x7f6ca34a5b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
+ #1 0x55e4c38a4c17 in rpl_free /home/simark/src/binutils-gdb/gnulib/import/free.c:44
+ #2 0x55e4c1bbd378 in xfree<void> /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb-xfree.h:37
+ #3 0x55e4c37d1b63 in call_freefun /home/simark/src/binutils-gdb/libiberty/obstack.c:103
+ #4 0x55e4c37d25a2 in _obstack_free /home/simark/src/binutils-gdb/libiberty/obstack.c:280
+ #5 0x55e4c1bad701 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2112
+ #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564
+ #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573
+ #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772
+ #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
+ #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
+ #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
+ #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383
+
+ previously allocated by thread T0 here:
+ #0 0x7f6ca34a5e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
+ #1 0x55e4c0b55c60 in xmalloc /home/simark/src/binutils-gdb/gdb/alloc.c:57
+ #2 0x55e4c37d1a6d in call_chunkfun /home/simark/src/binutils-gdb/libiberty/obstack.c:94
+ #3 0x55e4c37d1c20 in _obstack_begin_worker /home/simark/src/binutils-gdb/libiberty/obstack.c:141
+ #4 0x55e4c37d1ed7 in _obstack_begin /home/simark/src/binutils-gdb/libiberty/obstack.c:164
+ #5 0x55e4c1bad728 in reinit_frame_cache() /home/simark/src/binutils-gdb/gdb/frame.c:2113
+ #6 0x55e4c27705a3 in registers_changed_ptid(process_stratum_target*, ptid_t) /home/simark/src/binutils-gdb/gdb/regcache.c:564
+ #7 0x55e4c27708c7 in registers_changed_thread(thread_info*) /home/simark/src/binutils-gdb/gdb/regcache.c:573
+ #8 0x55e4c26fd922 in record_btrace_set_replay /home/simark/src/binutils-gdb/gdb/record-btrace.c:2772
+ #9 0x55e4c26fddc3 in record_btrace_target::goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/record-btrace.c:2843
+ #10 0x55e4c2de2bb2 in target_goto_record(unsigned long) /home/simark/src/binutils-gdb/gdb/target.c:4169
+ #11 0x55e4c275ed98 in record_goto(char const*) /home/simark/src/binutils-gdb/gdb/record.c:372
+ #12 0x55e4c275edba in cmd_record_goto /home/simark/src/binutils-gdb/gdb/record.c:383
+
+ The problem is a stale entry in the bfcache hash table (in
+ record-btrace.c), left across a reinit_frame_cache. This entry points
+ to something that used to be allocated on the frame obstack, that has
+ since been wiped by reinit_frame_cache.
+
+ Before the aforementioned, unwinder deallocation functions were called
+ by iterating on the frame chain, starting with the sentinel frame, like
+ so:
+
+ /* Tear down all frame caches. */
+ for (frame_info *fi = sentinel_frame; fi != NULL; fi = fi->prev)
+ {
+ if (fi->prologue_cache && fi->unwind->dealloc_cache)
+ fi->unwind->dealloc_cache (fi, fi->prologue_cache);
+ if (fi->base_cache && fi->base->unwind->dealloc_cache)
+ fi->base->unwind->dealloc_cache (fi, fi->base_cache);
+ }
+
+ After that patch, we relied on the fact that all frames are (supposedly)
+ in the frame_stash. A deletion function was added to the frame_stash
+ hash table, so that dealloc functions would be called when emptying the
+ frame stash. There is one case, however, where a frame_info is not in
+ the frame stash. That is when we create the frame_info for the current
+ frame (level 0, unwound from the sentinel frame), but don't compute its
+ frame id. The computation of the frame id for that frame (and only that
+ frame, AFAIK) is done lazily. And putting a frame_info in the frame stash
+ requires knowing its id. So a frame 0 whose frame id is not computed
+ yet is necessarily not in the frame stash.
+
+ When replaying with btrace, record_btrace_frame_sniffer insert entries
+ corresponding to frames in the "bfcache" hash table. It then relies on
+ record_btrace_frame_dealloc_cache being called for each frame to remove
+ all those entries when the frames get invalidated. If a frame reinit
+ happens while frame 0's id is not computed (and therefore that frame is
+ not in frame_stash), record_btrace_frame_dealloc_cache does not get
+ called for it, and it leaves a stale entry in bfcache. That then leads
+ to a use-after-free when that entry is accessed later, which ASan
+ catches.
+
+ The proposed solution is to explicitly call frame_info_del on frame 0,
+ if it exists, and if its frame id is not computed. If its frame id is
+ computed, it is expected that it will be in the frame stash, so it will
+ be "deleted" through that.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20230130200249.131155-1-simon.marchi@efficios.com/T/#mcf1340ce2906a72ec7ed535ec0c97dba11c3d977
+
+ Reported-By: Tom de Vries <tdevries@suse.de>
+ Tested-By: Tom de Vries <tdevries@suse.de>
+ Change-Id: I2351882dd511f3bbc01e4152e9db13b69b3ba384
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Remove RETURNS from BFD chew comments
+ When reading the BFD manual, I noticed text like this:
+
+ -- Function: bool bfd_close (bfd *abfd);
+ Close a BFD. If the BFD was open for writing, then pending
+ operations are completed and the file written out and closed. If
+ ...
+ *Returns*
+ 'TRUE' is returned if all is ok, otherwise 'FALSE'.
+
+ The *Returns*, like the *Synopsis* in the earlier patch, is
+ un-info-like. It's also used inconsistently.
+
+ This patch removes all the uses of the RETURNS word and removes it
+ entirely from the chew scripts. Now this example reads:
+
+ -- Function: bool bfd_close (bfd *abfd);
+ Close a BFD. If the BFD was open for writing, then pending
+ operations are completed and the file written out and closed. If
+ ...
+ 'TRUE' is returned if all is ok, otherwise 'FALSE'.
+
+ In a few cases I had to slightly reword the comment. There were also
+ a couple of cases where there was redundant text. In these cases I
+ just dropped the RETURNS copy.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * bfd.c, cache.c, compress.c, opncls.c: Remove RETURNS from
+ documentation comments.
+ * doc/doc.str, doc/proto.str (RETURNS): Remove.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Use @deftypefn in chew output
+ When reading the BFD info manual, function definitions looked very
+ strange to me:
+
+ *Synopsis*
+ long bfd_get_mtime (bfd *abfd);
+ *Description*
+ Return the file modification time (as read from the file system, or from
+ the archive header for archive members).
+
+ The *Synopsis* and *Description* text in particular is very un-info-like.
+
+ To fix this, I tried removing the *Synopsis* text and having FUNCTION
+ use @deftypefn instead. However, this ended up requiring some new
+ state, because SYNOPSIS can appear without FUNCTION. This in turn
+ required "catstrif" (I considered adding FORTH-style if-else-then, but
+ in the end decided on an ad hoc approach).
+
+ After this the result looks like:
+
+ -- Function: long bfd_get_mtime (bfd *abfd);
+ Return the file modification time (as read from the file system, or
+ from the archive header for archive members).
+
+ This patch also reorders a few documentation comments to ensure that
+ SYNOPSIS comes before DESCRIPTION. This is the more common style and
+ is also now required by doc.str.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * syms.c (bfd_decode_symclass, bfd_is_undefined_symclass)
+ (bfd_symbol_info): Reorder documentation comment.
+ * doc/doc.str (synopsis_seen): New variable.
+ (SYNOPSIS): Set synopsis_seen. Emit @deftypefn.
+ (DESCRIPTION): Use synopsis_seen.
+ * doc/chew.c (catstrif): New function.
+ (main): Add catstrif intrinsic.
+ (compile): Recognize "variable" command.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Change internalmode to be an intrinsic variable
+ Currently, internalmode is a special word to set an internal state
+ variable. Because this series adds variables anyway, change this to
+ be a variable instead.
+
+ I saw some commits in the history that made sure that chew did not
+ leak memory, so I put some extra effort into trying to handle this for
+ variables as well.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * doc/proto.str (external, internal, ifinternal, ENUMEQ, ENUMDOC):
+ Update.
+ * doc/chew.c (internalmode): Remove.
+ (add_intrinsic_variable): New function.
+ (main): Add internalmode as intrinsic.
+ (internal_mode): Remove global.
+ (maybecatstr): Update.
+ (free_words): Free variables.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Use intptr_t rather than long in chew
+ To implement variables in chew, it's convenient to have a
+ pointer-sized integer on the stack. To this end, use intptr_t rather
+ than long.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * doc/chew.c (pcu) <l>: Now intptr_t.
+ (internal_mode, istack, isp): Likewise.
+ (bang, atsign): Use intptr_t.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Remove the paramstuff word
+ The chew "paramstuff" word has been a no-op since:
+
+ commit c58b95236ce4c9345c4fa76e7ef16762e5229380
+ Author: Alan Modra <amodra@gmail.com>
+ Date: Sun Jun 29 10:06:40 2003 +0000
+
+ Convert to C90 and a few tweaks.
+
+ Remove it and its one use.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * doc/proto.str (SYNOPSIS): Don't use paramstuff.
+ * doc/chew.c (paramstuff): Remove.
+ (main): Don't add paramstuff intrinsic.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Add copyright headers to the .str files
+ The .str script files don't have copyright headers, but I think they
+ should. I used the same dates that chew.c uses, which I think makes
+ sense because these are inputs to chew.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * doc/doc.str, doc/proto.str: Add copyright header.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Simplify @node use in BFD documentation
+ The BFD docs currently specify all the parameters to @node. However,
+ this results in bad navigation in certain nodes -- the "space" command
+ in info doesn't know how to find the next node.
+
+ I think this style of @node is a leftover from ancient times.
+ Makeinfo can figure out the node structure on its own now, so simplify
+ everything to a single-argument @node.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * doc/webassembly.texi (File layout): Remove second argument from
+ @node.
+ * doc/bfd.texi: Use single-argument @node everywhere.
+
+2023-02-15 Tom Tromey <tom@tromey.com>
+
+ Remove H_CFLAGS from doc/local.mk
+ I couldn't see that H_CFLAGS is defined anywhere, so remove it.
+
+ 2023-02-07 Tom Tromey <tom@tromey.com>
+
+ * Makefile.in: Rebuild.
+ * doc/local.mk (%D%/chew.stamp): Don't use H_CFLAGS.
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: store internalvars in an std::map
+ In a test downstream in ROCgdb, we had a test case failing when
+ GDB_REVERSE_INIT_FUNCTIONS was set. The test was assuming a particular
+ order in the output of "show convenience". And the order changes when
+ running with GDB_REVERSE_INIT_FUNCTIONS.
+
+ I think that a nice way to fix it is to make the output of "show
+ convenience" sorted, and therefore stable. Ideally, I think that the
+ the user-visible behavior of GDB should not change when using
+ GDB_REVERSE_INIT_FUNCTIONS. Plus, it makes the output of "show
+ convenience" look nice, not that it's really important.
+
+ Implement this by storing the internal vars in an std::map, which is a
+ sorted container.
+
+ Change-Id: I1fca7e7877cc984a3a3432c7639d45e68d437241
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add constructor to internalvar
+ Add a constructor that takes the name as a parameter. Initialize the
+ next and kind fields inline.
+
+ Change-Id: Ic4db0aba85f1da9f12f3eee0ac62c0e5ef0cfe88
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use std::string for internalvar::name
+ Change internalvar::name to std::string, automating memory management.
+ It becomes necessary to allocate internalvar with new instead of XNEW.
+
+ I didn't find how to trigger the code in complete_internalvar. It is
+ called from condition_completer, so it should be by using the
+ "condition" command, but I never managed to get in the right code path.
+
+ Change-Id: I814d61361663e7becb8f3fb5f58c0180cdc414bc
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Tom Tromey <tromey@adacore.com>
+
+ Do not record a rejected target description
+ When connecting to a certain target, gdb issues a warning about the
+ target description:
+
+ (gdb) target remote localhost:7947
+ Remote debugging using localhost:7947
+ warning: Architecture rejected target-supplied description
+
+ If you then kill the inferior and change the exec-file, this will
+ happen:
+
+ (gdb) file bar
+ Architecture of file not recognized.
+
+ After this, debugging doesn't work very well.
+
+ What happens here is that, despite the warning,
+ target_find_description records the downloaded description in the
+ target_desc_info. Then the "file" command ends up calling
+ set_gdbarch_from_file, which uses that description.
+
+ It seems to me that, because the architecture rejected the
+ description, it should not be used. That is what this patch
+ implements.
+
+2023-02-15 Pedro Alves <pedro@palves.net>
+
+ gdb/manual: Move @findex entries
+ The manual currently has many cases like these:
+
+ @item $_gdb_setting_str (@var{setting})
+ @findex $_gdb_setting_str@r{, convenience function}
+
+ As suggested by Eli, move the @findex entries before @item so that the
+ index records the position of @item, and the Info reader places you
+ there when you use index-search.
+
+ I went over all @findex calls in the manual, and most are like the
+ above. Most either appear before @item, or before @subheading, like:
+
+ @subheading The @code{-break-after} Command
+ @findex -break-after
+
+ I fixed all of them.
+
+ There are findex entries in annotate.texinfo,python.texi, and
+ stabs.texinfo as well, though those all look right to me already.
+
+ Tested by typing "i _isvoid" (@item case) and "i -complete"
+ (@subheading case) in an Info reader, and checking where those took
+ me.
+
+ Change-Id: Idb6903b0bb39ff03f93524628dcef86b5585c97e
+ Suggested-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-02-15 Alan Modra <amodra@gmail.com>
+
+ objdump read_section_stabs
+ This function is used to read sections other than stabs, and there is
+ now another version of it that extracts different info from the bfd
+ section. Rename it and return the bfd section instead of assorted
+ fields of the bfd section.
+
+ * objcopy.c (read_section): Renamed from read_section_stabs.
+ Delete size_ptr and entsize_ptr params, add contents param.
+ Return asection pointer. Don't unnecessarily free contents on
+ failure from bfd_malloc_and_get_section.
+ (find_stabs_section): Use read_section.
+ (dump_ctf, dump_section_sframe): Likewise.
+ (read_section_sframe): Delete.
+
+2023-02-15 Alan Modra <amodra@gmail.com>
+
+ objdump -G memory leak
+ * objdump.c (find_stabs_section): Free stabs.
+
+2023-02-15 Nick Clifton <nickc@redhat.com>
+
+ Fix the linker's merge4 test for the HPPA architecture.
+ PR 30078 * testsuite/ld-elf/merge4b.s: Use .asciz instead of .string in order to avoid the special behaviour of the .string directive on HPPA architectures.
+
+2023-02-15 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, fortran: Fix quad floating-point type for ifort compiler.
+ I fixed this a while ago for ifx, one of the two Intel compilers, in
+ 8d624a9d8050ca96e154215c7858ac5c2d8b0b19.
+
+ Apparently I missed that the older ifort Intel compiler actually emits
+ slightly different debug info again:
+
+ 0x0000007a: DW_TAG_base_type
+ DW_AT_byte_size (0x20)
+ DW_AT_encoding (DW_ATE_complex_float)
+ DW_AT_name ("COMPLEX(16)")
+
+ 0x00000081: DW_TAG_base_type
+ DW_AT_byte_size (0x10)
+ DW_AT_encoding (DW_ATE_float)
+ DW_AT_name ("REAL(16)")
+
+ This fixes two failures in gdb.fortran/complex.exp with ifort.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-15 Jan Beulich <jbeulich@suse.com>
+
+ gas: buffer_and_nest() needs to pass nul-terminated string to temp_ilp()
+ In 7545aa2dd2eb ("gas: improve interaction between read_a_source_file()
+ and s_linefile()") I didn't pay attention to the dual purpose of the
+ nul character previously used. This was to a fair degree because of the
+ open-coding of certain operations. Insert the earlier found line
+ terminator instead of a hard-coded newline, and do so early in this
+ special case (bypassing the later general insertion point). Plus
+ properly use sb_terminate() to mark the end of the string. (Note that
+ saved_eol_char was misnamed: Without calling sb_terminate() there's
+ simply random data at that position in the buffer.)
+
+2023-02-15 Alan Modra <amodra@gmail.com>
+
+ More ecoff sanity checks
+ Change FIX so that unused pointers that escape the UPDATE_RAW_END
+ sanity checks won't result in overflows. Also sanity check the local
+ sym fdr isymBase and csym values.
+
+ * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Define FIX to set
+ pointers into swapped internal data to NULL if count is zero.
+ Sanity check local sym fdr_ptr->isymBase and fdr_ptr->csym.
+
+2023-02-15 Alan Modra <amodra@gmail.com>
+
+ binutils stabs type list
+ Fuzzers have found that specifying a large stab type number results in
+ lots of memory being requested, as the list is extended with a 16
+ element array at a time until we reach the given stab type. It also
+ takes a long time. Of course normal sane stab types use small
+ positive integers, but it's not hard to modify the code to handle type
+ numbers starting anyhere.
+
+ * stabs.c (struct stab_types): Add base_index.
+ (stab_find_slot): Simplify filenum check. Delete type number
+ check. Don't allocate entire array from 0 to type number,
+ allocate a sparse array.
+
+2023-02-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-14 Tom Tromey <tom@tromey.com>
+
+ Remove a use of pagination_enabled
+ I noticed that the TUI temporarily sets pagination_enabled and
+ gdb_stdout in one spot. However, I don't believe these settings are
+ necessary here, as a ui_file is passed to
+ gdbarch_print_registers_info. This patch removes these settings.
+
+2023-02-14 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf2: rename some things, index -> gdb_index
+ This renaming helps make it clearer that these entites (classes,
+ functions) are specific to .gdb_index only, they are not shared with the
+ .debug_names handling.
+
+ Change-Id: I1a3cf3dbf450b62d1a0879d9aedd26397abdfd13
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: cast return value of std::unique_ptr::release to void
+ My editor shows warnings like:
+
+ value.c:2784: warning: The value returned by this function should be used
+ value.c:2784: note: cast the expression to void to silence this warning [bugprone-unused-return-value]
+
+ These warnings come from clangd, so ultimately from one of the clang
+ static analyzers (probably clang-tidy).
+
+ Silence these warnings by casting to void. Add a comment to explain
+ why this unusual thing is done.
+
+ Change-Id: I58323959c0baf9f1b20a8d596e4c58dc77c6809a
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove unnecessary tui directory check in configure
+ I suppose this was possible in the CVS days for the tui directory to be
+ missing, but it's not really possible nowaday. Well, a user could
+ delete the directory from their source tree but... it doesn't make
+ sense. Remove the check for that directory in configure.
+
+ Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-14 Tom Tromey <tromey@adacore.com>
+
+ Do not cast away const in agent_run_command
+ While investigating something else, I noticed some weird code in
+ agent_run_command (use of memcpy rather than strcpy). Then I noticed
+ that 'cmd' is used as both an in and out parameter, despite being
+ const.
+
+ Casting away const like this is bad. This patch removes the const and
+ fixes the memcpy. I also added a static assert to assure myself that
+ the code in gdbserver is correct -- gdbserver is passing its own
+ buffer directly to agent_run_command.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp
+ There's a HW bug affecting Processor Trace on some Intel processors
+ (Ice Lake to Raptor Lake microarchitectures).
+
+ The bug was exposed by linux kernel commit 670638477aed
+ ("perf/x86/intel/pt: Opportunistically use single range output mode"),
+ added in version v5.5.0, and was worked around by commit ce0d998be927
+ ("perf/x86/intel/pt: Fix sampling using single range output") in version
+ 6.1.0.
+
+ The bug manifests (on a Performance-core of an i7-1250U, an Alder Lake cpu) in
+ a single test-case:
+ ...
+ (gdb) python insn = r.instruction_history^M
+ warning: Decode error (-20) at instruction 33 (offset = 0x3d6a, \
+ pc = 0x400501): compressed return without call.^M
+ (gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: \
+ python insn = r.instruction_history
+ ...
+
+ Add a corresponding XFAIL.
+
+ Note that the i7-1250U has both Performance-cores and Efficient-cores, and on
+ an Efficient-Core the test-case runs without any problems, so if the testsuite
+ run is not pinned to a specific cpu, the test may either PASS or XFAIL.
+
+ Tested on x86_64-linux:
+ - openSUSE Leap 15.4 with linux kernel version 5.14.21
+ - openSUSE Tumbleweed with linux kernel version 6.1.8
+
+ PR testsuite/30075
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30075
+
+2023-02-14 Nick Clifton <nickc@redhat.com>
+
+ Mention that the -plugin command line option is used to load plugins.
+
+2023-02-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Factor out proc linux_kernel_version
+ Factor out new proc linux_kernel_version from test-case
+ gdb.arch/i386-pkru.exp.
+
+ Tested on x86_64-linux.
+
+2023-02-14 Ulf Samuelsson <ulf@emagii.com>
+
+ ASCIZ Command for output section
+ Adds a new directive to the linker script syntax: ASCIZ.
+ This inserts a zero-terminated string into the output at the place where it is used.
+
+2023-02-14 Jan Beulich <jbeulich@suse.com>
+
+ gas: correct symbol name comparison in .startof./.sizeof. handling
+ In 162c6aef1f3a ("gas: fold symbol table entries generated for
+ .startof.() / .sizeof.()") I screwed up quite badly, inverting the case
+ sensitive and case insensitive comparison functions.
+
+ x86: {LD,ST}TILECFG use an extension opcode
+ It being zero and happening to work right now doesn't mean the insns
+ shouldn't be spelled out properly.
+
+2023-02-14 Jan Beulich <jbeulich@suse.com>
+
+ gas: improve interaction between read_a_source_file() and s_linefile()
+ read_a_source_file() would bump line numbers only when seeing a newline,
+ whereas is_end_of_line[] indicates further end-of-line characters, in
+ particular the nul character. s_linefile() attempts to compensate for
+ the bump, but was too aggressive with this so far: It should only adjust
+ when a newline ends the line. To facilitate such a check, the check for
+ nothing else on the line needs to move ahead, which luckily is easily
+ possible: The relevant two conditions match, and the function can
+ simply return from the body of that earlier instance of the conditional.
+
+ The more strict treatment in s_linefile() then requires an adjustment
+ to buffer_and_nest()'s invocation of the function: The line terminator
+ now needs to be a newline, not nul.
+
+2023-02-14 Tom Tromey <tom@tromey.com>
+
+ Fix build bug in ppc-linux-nat.c
+ The buildbot pointed out that my value refactoring series introduced a
+ bug in ppc-linux-nat.c:
+
+ ../../binutils-gdb/gdb/ppc-linux-nat.c: In member function ‘int ppc_linux_nat_target::num_memory_accesses(const std::vector<gdb::ref_ptr<value, value_ref_policy> >&)’:
+ ../../binutils-gdb/gdb/ppc-linux-nat.c:2458:44: error: expected unqualified-id before ‘->’ token
+ 2458 | if (VALUE_LVAL (v) == not_lval || v->->deprecated_modifiable () == 0)
+
+ I don't know how that happened, but I am checking in this patch which
+ I think should fix it. It just removes the second "->".
+
+ I can't readily test this, so perhaps there's another bug lurking
+ after this one.
+
+2023-02-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Rely on value_ref_ptr::operator->
+ Simon pointed out some spots were doing val.get()->mumble, where val
+ is a value_ref_ptr. These were introduced by the function-to-method
+ script, replacing older code that passed the result of .get() to a
+ function.
+
+ Now that value.h is using methods, we can instead rely on operator->.
+ This patch replaces all the newly-introduced instances of this.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Remove deprecated_lval_hack
+ This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
+ all uses with a call to value::lval.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Introduce set_lval method on value
+ This introduces the set_lval method on value, one step toward removing
+ deprecated_lval_hack. Ultimately I think the goal should be for some
+ of these set_* methods to be replaced with constructors; but I haven't
+ done this, as the series is already too long. Other 'deprecated'
+ methods can probably be handled the same way.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Make ~value private
+ At the end of this series, I belatedly realized that values should
+ only be destroyed by value_decref. This patch marks the the
+ destructor private to enforce this.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Make struct value data members private
+ This hoists the 'private' in struct value to also encompass the data
+ members.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn record_latest_value into a method
+ record_latest_value now access some internals of struct value, so turn
+ it into a method.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Add value::set_modifiable
+ This introduces a value::set_modifiable and changes a couple of spots
+ to use it.
+
+ I'm not completely sure the comments by deprecated_modifiable are
+ correct any more. Perhaps they should be removed and the method
+ renamed. Like so many before me, though, I've deferred investigation
+ of the issue.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn various value copying-related functions into methods
+ This patch turns a grab bag of value functions to methods of value.
+ These are done together because their implementations are
+ interrelated.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn preserve_one_value into method
+ This changes preserve_one_value to be a method of value. Much of this
+ patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn some xmethod functions into methods
+ This turns value_from_xmethod, result_type_of_xmethod, and
+ call_xmethod to be methods of value. value_from_xmethod is a static
+ "constructor" now.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Change some code to use value methods
+ A few functions in value.c were accessing the internal fields of
+ struct value. However, in these cases it seemed simpler to change
+ them to use the public API rather than convert them to be methods.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn set_value_component_location into method
+ This turns set_value_component_location into a method of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_non_lval and value_force_lval into methods
+ This changes value_non_lval and value_force_lval to be methods of
+ value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn many optimized-out value functions into methods
+ This turns many functions that are related to optimized-out or
+ availability-checking to be methods of value. The static function
+ value_entirely_covered_by_range_vector is also converted to be a
+ private method.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_copy into a method
+ This turns value_copy into a method of value. Much of this was
+ written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Fully qualify calls to copy in value.c
+ A coming patch will add value::copy, so this namespace-qualifies
+ existing calls to 'copy' in value.c, to ensure it will still compile
+ after that change is done.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn remaining value_contents functions into methods
+ This turns the remaining value_contents functions -- value_contents,
+ value_contents_all, value_contents_for_printing, and
+ value_contents_for_printing_const -- into methods of value. It also
+ converts the static functions require_not_optimized_out and
+ require_available to be private methods.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_incref and value_decref into methods
+ This changes value_incref and value_decref to be methods of value.
+ Much of this patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Move value_ref_policy methods out-of-line
+ This moves the value_ref_policy methods to be defined out-of-line.
+ This is a necessary step to change value_incref and value_decref to be
+ methods of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_bits_synthetic_pointer into a method
+ This changes value_bits_synthetic_pointer to be a method of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_contents_eq into a method
+ This changes value_contents_eq to be a method of value. It also
+ converts the static function value_contents_bits_eq into a private
+ method.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn allocate_value_contents into a method
+ This turns the static function allocate_value_contents into a method
+ on value. It is temporarily public, until some users are converted.
+ set_limited_array_length is converted as well.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_fetch_lazy into a method
+ This changes value_fetch_lazy to be a method of value. A few helper
+ functions are converted as well, to avoid problems in later patches
+ when the data members are all made private.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn some value_contents functions into methods
+ This turns value_contents_raw, value_contents_writeable, and
+ value_contents_all_raw into methods on value. The remaining functions
+ will be changed later in the series; they were a bit trickier and so I
+ didn't include them in this patch.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_zero into static "constructor"
+ This turns value_zero into a static "constructor" of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn allocate_optimized_out_value into static "constructor"
+ This turns allocate_optimized_out_value into a static "constructor" of
+ value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn allocate_computed_value into static "constructor"
+ This turns allocate_computed_value into a static "constructor" of
+ value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn allocate_value into a static "constructor"
+ This changes allocate_value to be a static "constructor" of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn allocate_value_lazy into a static "constructor"
+ This changes allocate_value_lazy to be a static "constructor" of
+ struct value.
+
+ I considered trying to change value to use ordinary new/delete, but it
+ seems to me that due to reference counting, we may someday want to
+ change these static constructors to return value_ref_ptr instead.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn more deprecated_* functions into methods
+ This changes deprecated_value_internalvar_hack,
+ deprecated_value_internalvar_hack, and deprecated_value_regnum_hack
+ into methods on value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_address and set_value_address functions into methods
+ This changes the value_address and set_value_address functions to be
+ methods of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_initialized and set_value_initialized functions into methods
+ This changes the value_initialized and set_value_initialized functions
+ to be methods of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Convert value_lval_const and deprecated_lval_hack to methods
+ This converts the value_lval_const and deprecated_lval_hack functions
+ to be methods on value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_computed_closure and value_computed_funcs functions into methods
+ This changes the value_computed_funcs and value_computed_closure
+ functions to be methods of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_stack and set_value_stack functions into methods
+ This changes the value_stack and set_value_stack functions to be
+ methods of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_lazy and set_value_lazy functions into methods
+ This changes the value_lazy and set_value_lazy functions to be methods
+ of value. Much of this patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn some value offset functions into method
+ This changes various offset-related functions to be methods of value.
+ Much of this patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_enclosing_type into method
+ This changes value_enclosing_type to be a method of value. Much of
+ this patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn deprecated_value_modifiable into method
+ This changes deprecated_value_modifiable to be a method of value.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_offset into method
+ This changes value_offset to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_parent into method
+ This changes value_parent to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_bitpos into method
+ This changes value_bitpos to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_bitsize into method
+ This changes value_bitsize to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_arch into method
+ This changes value_arch to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn deprecated_set_value_type into a method
+ This changes deprecated_set_value_type to be a method of value. Much
+ of this patch was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Turn value_type into method
+ This changes value_type to be a method of value. Much of this patch
+ was written by script.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Move struct value to value.h
+ This moves struct value to value.h. For now, all members remain
+ public, but this is a temporary state -- by the end of the series
+ we'll add 'private'.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Move ~value body out-of-line
+ struct value is going to move to value.h, but to avoid having
+ excessive code there, first move the destructor body out-of-line.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Tom Tromey <tom@tromey.com>
+
+ Rename all fields of struct value
+ This renames all the fields of struct value, in preparation for the
+ coming changes.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Michael Matz <matz@suse.de>
+
+ PR30120: fix x87 fucomp misassembled
+ this fixes the entry for 'fucomp' to use the correct Reg value
+ (otherwise it's assembled as 'fucom').
+
+2023-02-13 Tom Tromey <tromey@adacore.com>
+
+ Remove unused imports from gdb's Python code
+ The "sys" import is unused in several Python files. This removes this
+ line from all the places where it is unnecessary.
+
+2023-02-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: don't leak the known_window_types map
+ This commit finishes the task that was started in the previous
+ commit.
+
+ Now that all Python TUI window factories are correctly deleted when
+ the Python interpreter is shut down, we no longer need to dynamically
+ allocate the known_window_types map in tui-layout.c
+
+ This commit changes known_window_types to a statically allocated data
+ structure, removes the dynamic allocation from
+ initialize_known_windows, and then replaces lots of '->' with '.'
+ throughout this file.
+
+ There should be no user visible changes after this commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: deallocate tui window factories at Python shut down
+ The previous commit relied on spotting when a Python defined TUI
+ window factory was deleted. I spotted that the window factories are
+ not deleted when GDB shuts down its Python environment, they are only
+ deleted when one window factory replaces another. Consider this
+ example Python script:
+
+ class TestWindowFactory:
+ def __init__(self, msg):
+ self.msg = msg
+ print("Entering TestWindowFactory.__init__: %s" % self.msg)
+
+ def __call__(self, tui_win):
+ print("Entering TestWindowFactory.__call__: %s" % self.msg)
+ return TestWindow(tui_win, self.msg)
+
+ def __del__(self):
+ print("Entering TestWindowFactory.__del__: %s" % self.msg)
+
+ gdb.register_window_type("test_window", TestWindowFactory("A"))
+ gdb.register_window_type("test_window", TestWindowFactory("B"))
+
+ And this GDB session:
+
+ (gdb) source tui.py
+ Entering TestWindowFactory.__init__: A
+ Entering TestWindowFactory.__init__: B
+ Entering TestWindowFactory.__del__: B
+ (gdb) quit
+
+ Notice that when the 'B' window replaces the 'A' window we see the 'A'
+ object being deleted. But, when Python is shut down (after the
+ 'quit') the 'B' object is never deleted.
+
+ Instead, GDB retains a reference to the window factory object, which
+ forces the Python object to remain live even after the Python
+ interpreter itself has been shut down.
+
+ The references themselves are held in a dynamically allocated
+ std::unordered_map (in tui/tui-layout.c) which is never deallocated,
+ thus the underlying Python references are never decremented to zero,
+ and so GDB never tries to delete these Python objects.
+
+ This commit is the first half of the work to clean up this edge case.
+
+ All gdbpy_tui_window_maker objects (the objects that implement the
+ TUI window factory callback for Python defined TUI windows), are now
+ linked together into a global list using the intrusive list mechanism.
+
+ When GDB shuts down the Python interpreter we can now walk this global
+ list and release the reference that is held to the underlying Python
+ object. By releasing this reference the Python object will now be
+ deleted.
+
+ I've added a new assert in gdbpy_tui_window_maker::operator(), this
+ will catch the case where we somehow end up in here after having
+ reset the reference to the underlying Python object. I don't think
+ this should ever happen though as we only clear the references when
+ shutting down the Python interpreter, and the ::operator() function is
+ only called when trying to apply a new TUI layout - something that
+ shouldn't happen while GDB itself is shutting down.
+
+ This commit does not update the std::unordered_map in tui-layout.c,
+ that will be done in the next commit.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: allow Python TUI windows to be replaced
+ The documentation for gdb.register_window_type says:
+
+ "... It's an error to try to replace one of the built-in windows,
+ but other window types can be replaced. ..."
+
+ I take this to mean that if I imported a Python script like this:
+
+ gdb.register_window_type('my_window', FactoryFunction)
+
+ Then GDB would have a new TUI window 'my_window', which could be
+ created by calling FactoryFunction(). If I then, in the same GDB
+ session imported a script which included:
+
+ gdb.register_window_type('my_window', UpdatedFactoryFunction)
+
+ Then GDB would replace the old 'my_window' factory with my new one,
+ GDB would now call UpdatedFactoryFunction().
+
+ This is pretty useful in practice, as it allows users to iterate on
+ their window implementation within a single GDB session.
+
+ However, right now, this is not how GDB operates. The second call to
+ register_window_type is basically ignored and the old window factory
+ is retained.
+
+ This is because in tui_register_window (tui/tui-layout.c) we use
+ std::unordered_map::emplace to insert the new factory function, and
+ emplace doesn't replace an existing element in an unordered_map.
+
+ In this commit, before the emplace call, I now search for an already
+ existing element, and delete any matching element from the map, the
+ emplace call will then add the new factory function.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-13 Keith Seitz <keiths@redhat.com>
+
+ Fix doc build dependencies for --with-system-readline
+ PR build/30108 concerns building gdb documentation with
+ --with-sytem-readline. If the in-tree readline directory is
+ missing, though, the docs will fail to build:
+
+ make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc'
+ make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop.
+
+ The listed file (and hsuser.texi) are conditionally included by gdb.texinfo.
+ When system readline is used, gdb/configure.ac will leave
+ READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to
+ $BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the
+ inclusion of the missing files. They are not needed or used in this
+ scenario.
+
+ However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies,
+ thus provoking the build error whenever readline/ is missing.
+
+ This patch fixes this by creating (essentially) a conditional setting of the
+ dependencies to be included from readline.
+
+2023-02-13 Michael Matz <matz@suse.de>
+
+ Fix PR30079: abort on mingw
+ the early-out in wild_sort is not enough, it might still be
+ that filenames are equal _and_ the wildcard list doesn't specify
+ a sort order either. Don't call compare_section then.
+
+ Tested on all targets.
+
+2023-02-13 Alan Modra <amodra@gmail.com>
+
+ _bfd_ecoff_slurp_symbol_table buffer overflow
+ Add missing bounds check, and tidy the existing bounds checking.
+
+ * ecoff.c (_bfd_ecoff_slurp_symbol_table): Break overlong lines.
+ Set bfd_error. Bounds check internal_sym.iss.
+
+2023-02-13 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/mips: disassemble unknown micromips instructions as two shorts
+ Before commit:
+
+ commit 2438b771ee07be19d5b01ea55e077dd8b7cef445
+ Date: Wed Nov 2 15:53:43 2022 +0000
+
+ opcodes/mips: use .word/.short for undefined instructions
+
+ unknown 32-bit microMIPS instructions were disassembled as a raw
+ 32-bit number with no '.word' directive. The above commit changed
+ this and added a '.word' directive before the 32-bit number.
+
+ It was pointed out on the mailing list, that for microMIPS it would be
+ better to display such 32-bit instructions using a '.short' directive
+ followed by two 16-bit values.
+
+ This commit updates the mips disassembler to do this, and adds a new
+ test that validates this output.
+
+2023-02-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: handle differences in guile error string output
+ A new guile test added in commit:
+
+ commit 0a9ccb9dd79384f3ba3f8cd75940e8868f3b526f
+ Date: Mon Feb 6 13:04:16 2023 +0000
+
+ gdb: only allow one of thread or task on breakpoints or watchpoints
+
+ fails for some versions of guile. It turns out that some versions of
+ guile emit an error like this:
+
+ (gdb) guile (set-breakpoint-thread! bp 1)
+ ERROR: In procedure set-breakpoint-thread!:
+ In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
+ Error while executing Scheme code.
+
+ while other versions of guile emit the error like this:
+
+ (gdb) guile (set-breakpoint-thread! bp 1)
+ ERROR: In procedure set-breakpoint-thread!:
+ ERROR: In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
+ Error while executing Scheme code.
+
+ notice the extra 'ERROR: ' on the second line of output. This commit
+ updates the test regexp to handle this optional 'ERROR: ' string.
+
+2023-02-13 Alan Modra <amodra@gmail.com>
+
+ stabs.c static state
+ Move all the function local static state variables to file scope,
+ in order to tidy memory on exit and to reinit everything for that
+ annoying oss-fuzz. Also fix a couple memory leaks.
+
+ * read.h (read_begin, read_end): Declare.
+ * read.c (read_begin): Call stabs_begin.
+ (read_end): Call stabs_end.
+ * stabs.c (stabs_begin, stabs_end): New functions.
+ (in_dot_func_p): Delete, use current_function_label instead.
+ (cached_sec): Move from s_stab_generic.
+ (last_asm_file, file_label_count): Move from generate_asm_file.
+ (line_label_count, prev_lineno, prev_line_file): Move from
+ stabs_generate_asm_lineno.
+ (void_emitted_p): Move from stabs_generate_asm_func.
+ (endfunc_label_count): Move from stabs_generate_asm_endfunc.
+ (stabs_generate_asm_lineno): Simplify setting of
+ prev_line_file.
+ (stabs_generate_asm_func): Don't leak current_function_label.
+ (stabs_generate_asm_endfunc): Likewise.
+
+2023-02-13 Alan Modra <amodra@gmail.com>
+
+ Split off gas init to functions
+ With some slight reordering.
+
+ * as.c (gas_early_init, gas_late_init): New functions, split..
+ (main): ..from here.
+
+2023-02-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: look for hipcc in env(ROCM_PATH)
+ If the hipcc compiler cannot be found in dejagnu's tool_root_dir, look
+ for it in $::env(ROCM_PATH) (if set). If hipcc is still not found,
+ fallback to "hipcc" so the compiler will be searched in the PATH. This
+ removes the fallback to the hard-coded "/opt/rocm/bin" prefix.
+
+ This change is done so ROCM tools are searched in a uniform manner.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: allow_hipcc_tests tests the hipcc compiler
+ Update allow_hipcc_tests so all gdb.rocm tests are skipped if we do not
+ have a working hipcc compiler available.
+
+ To achieve this, adjust gdb_simple_compile to ensure that the hip
+ program is saved in a ".cpp" file before calling hipcc otherwise
+ compilation will fail.
+
+ One thing to note is that it is possible to have a hipcc installed with
+ a CUDA backend. Compiling with this back-end will successfully result
+ in an application, but GDB cannot debug it (at least for the offload
+ part). In the context of the gdb.rocm tests, we want to detect such
+ situation where gdb_simple_compile would give a false positive.
+
+ To achieve this, this patch checks that there is at least one AMDGPU
+ device available and that hipcc can compile for this or those targets.
+ Detecting the device is done using the rocm_agent_enumerator tool which
+ is installed with the all ROCm installations (it is used by hipcc to
+ detect identify targets if this is not specified on the comand line).
+
+ This patch also makes the allow_hipcc_tests proc a cached proc.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: require amd-dbgapi support to run rocm tests
+ Update allow_hipcc_tests to check that GDB has the amd-dbgapi support
+ built-in. Without this support, all tests using hipcc and the rocm
+ stack will fail.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: Rename skip_hipcc_tests to allow_hipcc_tests
+ Rename skip_hipcc_tests to allow_hipcc_tests so it can be used as a
+ "require" predicate in tests.
+
+ Use require in gdb.rocm/simple.exp.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: 'show config' shows --with[out]-amd-dbgapi
+ Ensure that the "show configuration" command and the "--configuration"
+ command line switch shows if GDB was built with the AMDGPU support or
+ not.
+
+ This will be used in a later patch in this series.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-13 Alan Modra <amodra@gmail.com>
+
+ objcopy memory leaks
+ This fixes some objcopy memory leaks. commit 450da4bd38ae used
+ xatexit to tidy most of the hash table memory, but of course that's
+ ineffective without a call to xexit. The other major memory leak
+ happens if there is an error of some sort writing the output file, due
+ to not closing the input file and thus not freeing memory attached to
+ the bfd.
+
+ * objcopy.c (copy_file): Don't return when bfd_close of output
+ gives an error, always bfd_close input too.
+ (main): Call xexit.
+
+2023-02-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-12 Tom Tromey <tom@tromey.com>
+
+ Move some code from dwarf2/read.c to die.c
+ This patch introduces a new file, dwarf2/die.c, and moves some
+ DIE-related code out of dwarf2/read.c and into this new file. This is
+ just a small part of the long-term project to split up read.c.
+ (According to 'wc', dwarf2/read.c is the largest file in gdb by around
+ 8000 LOC.)
+
+ Regression tested on x86-64 Fedora 36.
+
+2023-02-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix describe_other_breakpoints for default task being -1
+ Commit:
+
+ commit 2ecee236752932672fb3d6cd63c6976927f747d8
+ CommitDate: Sun Feb 12 05:46:44 2023 +0000
+
+ gdb: use -1 for breakpoint::task default value
+
+ Failed to take account of an earlier commit:
+
+ commit f1f517e81039f6aa673b7d87a66bfbd25a66e3d3
+ CommitDate: Sat Feb 11 17:36:24 2023 +0000
+
+ gdb: show task number in describe_other_breakpoints
+
+ That both of these are my own commits is only more embarrassing.
+
+ This small fix updates describe_other_breakpoints to take account of
+ the default task number now being -1. This fixes regressions in
+ gdb.base/break.exp, gdb.base/break-always.exp, and many other tests.
+
+2023-02-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/c++: fix handling of breakpoints on @plt symbols
+ This commit should fix PR gdb/20091, PR gdb/17201, and PR gdb/17071.
+ Additionally, PR gdb/17199 relates to this area of code, but is more
+ of a request to refactor some parts of GDB, this commit does not
+ address that request, but it is probably worth reading that PR when
+ looking at this commit.
+
+ When the current language is C++, and the user places a breakpoint on
+ a function in a shared library, GDB will currently find two locations
+ for the breakpoint, one location will be within the function itself as
+ we would expect, but the other location will be within the PLT table
+ for the call to the named function. Consider this session:
+
+ $ gdb -q /tmp/breakpoint-shlib-func
+ Reading symbols from /tmp/breakpoint-shlib-func...
+ (gdb) start
+ Temporary breakpoint 1 at 0x40112e: file /tmp/breakpoint-shlib-func.cc, line 20.
+ Starting program: /tmp/breakpoint-shlib-func
+
+ Temporary breakpoint 1, main () at /tmp/breakpoint-shlib-func.cc:20
+ 20 int answer = foo ();
+ (gdb) break foo
+ Breakpoint 2 at 0x401030 (2 locations)
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE>
+ 2.1 y 0x0000000000401030 <foo()@plt>
+ 2.2 y 0x00007ffff7fc50fd in foo() at /tmp/breakpoint-shlib-func-lib.cc:20
+
+ This is not the expected behaviour. If we compile the same test using
+ a C compiler then we see this:
+
+ (gdb) break foo
+ Breakpoint 2 at 0x7ffff7fc50fd: file /tmp/breakpoint-shlib-func-c-lib.c, line 20.
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y 0x00007ffff7fc50fd in foo at /tmp/breakpoint-shlib-func-c-lib.c:20
+
+ Here's what's happening. When GDB parses the symbols in the main
+ executable and the shared library we see a number of different symbols
+ for foo, and use these to create entries in GDB's msymbol table:
+
+ - In the main executable we see a symbol 'foo@plt' that points at
+ the plt entry for foo, from this we add two entries into GDB's
+ msymbol table, one called 'foo@plt' which points at the plt entry
+ and has type mst_text, then we create a second symbol, this time
+ called 'foo' with type mst_solib_trampoline which also points at
+ the plt entry,
+
+ - Then, when the shared library is loaded we see another symbol
+ called 'foo', this one points at the actual implementation in the
+ shared library. This time GDB creates a msymbol called 'foo' with
+ type mst_text that points at the implementation.
+
+ This means that GDB creates 3 msymbols to represent the 2 symbols
+ found in the executable and shared library.
+
+ When the user creates a breakpoint on 'foo' GDB eventually ends up in
+ search_minsyms_for_name (linespec.c), this function then calls
+ iterate_over_minimal_symbols passing in the name we are looking for
+ wrapped in a lookup_name_info object.
+
+ In iterate_over_minimal_symbols we iterate over two hash tables (using
+ the name we're looking for as the hash key), first we walk the hash
+ table of symbol linkage names, then we walk the hash table of
+ demangled symbol names.
+
+ When the language is C++ the symbols for 'foo' will all have been
+ mangled, as a result, in this case, the iteration of the linkage name
+ hash table will find no matching results.
+
+ However, when we walk the demangled hash table we do find some
+ results. In order to match symbol names, GDB obtains a symbol name
+ matching function by calling the get_symbol_name_matcher method on the
+ language_defn class. For C++, in this case, the matching function we
+ use is cp_fq_symbol_name_matches, which delegates the work to
+ strncmp_iw_with_mode with mode strncmp_iw_mode::MATCH_PARAMS and
+ language set to language_cplus.
+
+ The strncmp_iw_mode::MATCH_PARAMS mode means that strncmp_iw_mode will
+ skip any parameters in the demangled symbol name when checking for a
+ match, e.g. 'foo' will match the demangled name 'foo()'. The way this
+ is done is that the strings are matched character by character, but,
+ once the string we are looking for ('foo' here) is exhausted, if we
+ are looking at '(' then we consider the match a success.
+
+ Lets consider the 3 symbols GDB created. If the function declaration
+ is 'void foo ()' then from the main executable we added symbols
+ '_Z3foov@plt' and '_Z3foov', while from the shared library we added
+ another symbol call '_Z3foov'. When these are demangled they become
+ 'foo()@plt', 'foo()', and 'foo()' respectively.
+
+ Now, the '_Z3foov' symbol from the main executable has the type
+ mst_solib_trampoline, and in search_minsyms_for_name, we search for
+ any symbols of type mst_solib_trampoline and filter these out of the
+ results.
+
+ However, the '_Z3foov@plt' symbol (from the main executable), and the
+ '_Z3foov' symbol (from the shared library) both have type mst_text.
+
+ During the demangled name matching, due to the use of MATCH_PARAMS
+ mode, we stop the comparison as soon as we hit a '(' in the demangled
+ name. And so, '_Z3foov@plt', which demangles to 'foo()@plt' matches
+ 'foo', and '_Z3foov', which demangles to 'foo()' also matches 'foo'.
+
+ By contrast, for C, there are no demangled hash table entries to be
+ iterated over (in iterate_over_minimal_symbols), we only consider the
+ linkage name symbols which are 'foo@plt' and 'foo'. The plain 'foo'
+ symbol obviously matches when we are looking for 'foo', but in this
+ case the 'foo@plt' will not match due to the '@plt' suffix.
+
+ And so, when the user asks for a breakpoint in 'foo', and the language
+ is C, search_minsyms_for_name, returns a single msymbol, the mst_text
+ symbol for foo in the shared library, while, when the language is C++,
+ we get two results, '_Z3foov' for the shared library function, and
+ '_Z3foov@plt' for the plt entry in the main executable.
+
+ I propose to fix this in strncmp_iw_with_mode. When the mode is
+ MATCH_PARAMS, instead of stopping at a '(' and assuming the match is a
+ success, GDB will instead search forward for the matching, closing,
+ ')', effectively skipping the parameter list, and then resume
+ matching. Thus, when comparing 'foo' to 'foo()@plt' GDB will
+ effectively compare against 'foo@plt' (skipping the parameter list),
+ and the match will fail, just as it does when the language is C.
+
+ There is one slight complication, which is revealed by the test
+ gdb.linespec/cpcompletion.exp, when searching for the symbol of a
+ const member function, the demangled symbol will have 'const' at the
+ end of its name, e.g.:
+
+ struct_with_const_overload::const_overload_fn() const
+
+ Previously, the matching would stop at the '(' character, but after my
+ change the whole '()' is skipped, and the match resumes. As a result,
+ the 'const' modifier results in a failure to match, when previously
+ GDB would have found a match.
+
+ To work around this issue, in strncmp_iw_with_mode, when mode is
+ MATCH_PARAMS, after skipping the parameter list, if the next character
+ is '@' then we assume we are looking at something like '@plt' and
+ return a value indicating the match failed, otherwise, we return a
+ value indicating the match succeeded, this allows things like 'const'
+ to be skipped.
+
+ With these changes in place I now see GDB correctly setting a
+ breakpoint only at the implementation of 'foo' in the shared library.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20091
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17201
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17071
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17199
+
+ Tested-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use -1 for breakpoint::task default value
+ Within the breakpoint struct we have two fields ::thread and ::task
+ which are used for thread or task specific breakpoints. When a
+ breakpoint doesn't have a specific thread or task then these fields
+ have the values -1 and 0 respectively.
+
+ There's no particular reason (as far as I can tell) why these two
+ "default" values are different, and I find the difference a little
+ confusing. Long term I'd like to potentially fold these two fields
+ into a single field, but that isn't what this commit does.
+
+ What this commit does is switch to using -1 as the "default" value for
+ both fields, this means that the default for breakpoint::task has
+ changed from 0 to -1. I've updated all the code I can find that
+ relied on the value of 0, and I see no test regressions, especially in
+ gdb.ada/tasks.exp, which still fully passes.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: only allow one of thread or task on breakpoints or watchpoints
+ After this mailing list posting:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-February/196607.html
+
+ it seems to me that in practice an Ada task maps 1:1 with a GDB
+ thread, and so it doesn't really make sense to allow uses to give both
+ a thread and a task within a single breakpoint or watchpoint
+ condition.
+
+ This commit updates GDB so that the user will get an error if both
+ are specified.
+
+ I've added new tests to cover the CLI as well as the Python and Guile
+ APIs. For the Python and Guile testing, as far as I can tell, this
+ was the first testing for this corner of the APIs, so I ended up
+ adding more than just a single test.
+
+ For documentation I've added a NEWS entry, but I've not added anything
+ to the docs themselves. Currently we document the commands with a
+ thread-id or task-id as distinct command, e.g.:
+
+ 'break LOCSPEC task TASKNO'
+ 'break LOCSPEC task TASKNO if ...'
+ 'break LOCSPEC thread THREAD-ID'
+ 'break LOCSPEC thread THREAD-ID if ...'
+
+ As such, I don't believe there is any indication that combining 'task'
+ and 'thread' would be expected to work; it seems clear to me in the
+ above that those four options are all distinct commands.
+
+ I think the NEWS entry is enough that if someone is combining these
+ keywords (it's not clear what the expected behaviour would be in this
+ case) then they can figure out that this was a deliberate change in
+ GDB, but for a new user, the manual doesn't suggest combining them is
+ OK, and any future attempt to combine them will give an error.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: show task number in describe_other_breakpoints
+ I noticed that describe_other_breakpoints doesn't show the task
+ number, but does show the thread-id. I can't see any reason why we'd
+ want to not show the task number in this situation, so this commit
+ adds this missing information, and extends gdb.ada/tasks.exp to check
+ this case.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't print global thread-id to CLI in describe_other_breakpoints
+ I noticed that describe_other_breakpoints was printing the global
+ thread-id to the CLI. For CLI output we should be printing the
+ inferior local thread-id (e.g. "2.1"). This can be seen in the
+ following GDB session:
+
+ (gdb) info threads
+ Id Target Id Frame
+ 1.1 Thread 4065742.4065742 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27
+ * 2.1 Thread 4065743.4065743 "bp-thread-speci" main () at /tmp/bp-thread-specific.c:27
+ (gdb) break foo thread 2.1
+ Breakpoint 3 at 0x40110a: foo. (2 locations)
+ (gdb) break foo thread 1.1
+ Note: breakpoint 3 (thread 2) also set at pc 0x40110a.
+ Note: breakpoint 3 (thread 2) also set at pc 0x40110a.
+ Breakpoint 4 at 0x40110a: foo. (2 locations)
+
+ Notice that GDB says:
+
+ Note: breakpoint 3 (thread 2) also set at pc 0x40110a.
+
+ The 'thread 2' in here is using the global thread-id, we should
+ instead say 'thread 2.1' which corresponds to how the user specified
+ the breakpoint.
+
+ This commit fixes this issue and adds a test.
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add test for readline handling very long commands
+ The test added in this commit tests for a long fixed readline issue
+ relating to long command lines. A similar patch has existed in the
+ Fedora GDB tree for several years, but I don't see any reason why this
+ test would not be suitable for inclusion in upstream GDB. I've
+ updated the patch to current testsuite standards.
+
+ The test is checking for an issue that was fixed by this readline
+ patch:
+
+ https://lists.gnu.org/archive/html/bug-readline/2006-11/msg00002.html
+
+ Which was merged into readline 6.0 (released ~2010). The issue was
+ triggered when the user enters a long command line, which wrapped over
+ multiple terminal lines. The crash looks like this:
+
+ free(): invalid pointer
+
+ Fatal signal: Aborted
+ ----- Backtrace -----
+ 0x4fb583 gdb_internal_backtrace_1
+ ../../src/gdb/bt-utils.c:122
+ 0x4fb583 _Z22gdb_internal_backtracev
+ ../../src/gdb/bt-utils.c:168
+ 0x6047b9 handle_fatal_signal
+ ../../src/gdb/event-top.c:964
+ 0x7f26e0cc56af ???
+ 0x7f26e0cc5625 ???
+ 0x7f26e0cae8d8 ???
+ 0x7f26e0d094be ???
+ 0x7f26e0d10aab ???
+ 0x7f26e0d124ab ???
+ 0x7f26e1d32e12 rl_free_undo_list
+ ../../readline-5.2/undo.c:119
+ 0x7f26e1d229eb readline_internal_teardown
+ ../../readline-5.2/readline.c:405
+ 0x7f26e1d3425f rl_callback_read_char
+ ../../readline-5.2/callback.c:197
+ 0x604c0d gdb_rl_callback_read_char_wrapper_noexcept
+ ../../src/gdb/event-top.c:192
+ 0x60581d gdb_rl_callback_read_char_wrapper
+ ../../src/gdb/event-top.c:225
+ 0x60492f stdin_event_handler
+ ../../src/gdb/event-top.c:545
+ 0xa60015 gdb_wait_for_event
+ ../../src/gdbsupport/event-loop.cc:694
+ 0xa6078d gdb_wait_for_event
+ ../../src/gdbsupport/event-loop.cc:593
+ 0xa6078d _Z16gdb_do_one_eventi
+ ../../src/gdbsupport/event-loop.cc:264
+ 0x6fc459 start_event_loop
+ ../../src/gdb/main.c:411
+ 0x6fc459 captured_command_loop
+ ../../src/gdb/main.c:471
+ 0x6fdce4 captured_main
+ ../../src/gdb/main.c:1310
+ 0x6fdce4 _Z8gdb_mainP18captured_main_args
+ ../../src/gdb/main.c:1325
+ 0x44f694 main
+ ../../src/gdb/gdb.c:32
+ ---------------------
+
+ I recreated the above crash by a little light hacking on GDB, and then
+ linking GDB against readline 5.2. The above stack trace was generated
+ from the test included in this patch, and matches the trace that was
+ included in the original bug report.
+
+ It is worth acknowledging that without hacking things GDB has a
+ minimum requirement of readline 7.0. This test is not about checking
+ whether GDB has been built against an older version of readline, it is
+ about checking that readline doesn't regress in this area.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove unnecessary 'dir' commands from gdb-gdb.gdb script
+ While debugging GDB I used 'show directories' and spotted lots of
+ entries that didn't make much sense. Here are all the entries that are
+ in my directories list:
+
+ /tmp/binutils-gdb/build
+ /tmp/binutils-gdb/build/../../src/gdb
+ /tmp/binutils-gdb/build/../../src/gdb/../bfd
+ /tmp/binutils-gdb/build/../../src/gdb/../libiberty
+ $cdir
+ $cwd
+
+ Notice the second, third, and fourth entries in this list, these
+ should really be:
+
+ /tmp/binutils-gdb/build/../src/gdb
+ /tmp/binutils-gdb/build/../src/gdb/../bfd
+ /tmp/binutils-gdb/build/../src/gdb/../libiberty
+
+ The problem is because I generally run everything from the top level
+ build directory, not the gdb/ sub-directory, thus, I start GDB like:
+
+ ./gdb/gdb --data-directory ./gdb/data-directory
+
+ If run GDB under GDB, then I end up loading the gdb/gdb-gdb.gdb
+ script, which contains these lines:
+
+ dir ../../src/gdb/../libiberty
+ dir ../../src/gdb/../bfd
+ dir ../../src/gdb
+ dir .
+
+ These commands only make sense when running within the gdb/
+ sub-directory.
+
+ However, my debugging experience doesn't seem to be degraded at all, I
+ can still see the GDB source code just fine; which is because the
+ directory list still contains $cdir.
+
+ The build/gdb/gdb-gdb.gdb script is created from the
+ src/gdb/gdb-gdb.gdb.in template, which includes the automake @srcdir@
+ markers.
+
+ The 'dir' commands have mostly been around since the sourceware
+ repository was first created, though this commit 67f0714670383a did
+ reorder some of the 'dir' commands, which would seem to indicate these
+ commands were important to some people, at some time.
+
+ One possible fix would be to replace @srcdir@ with @abs_srcdir@, this
+ would ensure that the entries added were all valid, no matter the
+ user's current directory when debugging GDB.
+
+ However... I'd like to propose that we instead remove all the extra
+ directories completely. My hope is that, with more recent tools, the
+ debug information should allow us to correctly find all of the source
+ files without having to add any extra 'dir' entries. Obviously,
+ commit 67f0714670383a does make me a little nervous, but the
+ gdb-gdb.gdb script isn't something a non-maintainer will be using, so
+ I think we can afford to be a little more aggressive here. If it
+ turns out the 'dir' entries are needed then we can add them back, but
+ actually document why they are needed. Plus, when we add them back we
+ will use @abs_srcdir@ instead of @srcdir@.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2023-02-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Don't use i386 unwinder for amd64
+ For i386 we have these unwinders:
+ ...
+ $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ i386 epilogue NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ i386 stack tramp NORMAL_FRAME
+ i386 sigtramp SIGTRAMP_FRAME
+ i386 prologue NORMAL_FRAME
+ ...
+ and for amd64:
+ ...
+ $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386:x86-64".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ python NORMAL_FRAME
+ amd64 epilogue NORMAL_FRAME
+ i386 epilogue NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ amd64 sigtramp SIGTRAMP_FRAME
+ amd64 prologue NORMAL_FRAME
+ i386 stack tramp NORMAL_FRAME
+ i386 sigtramp SIGTRAMP_FRAME
+ i386 prologue NORMAL_FRAME
+ ...
+
+ ISTM me there's no reason for the i386 unwinders to be there for amd64.
+
+ Furthermore, there's a generic need to play around with enabling and disabling
+ unwinders, see PR8434. Currently, that's only available for both the dwarf2
+ unwinders at once using "maint set dwarf unwinders on/off".
+
+ If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue"
+ unwinder becomes active and gives the wrong answer, while I'm actually
+ interested in the result of the dwarf2 unwinder. Of course I can also
+ manually disable the "i386 epilogue", but I take the fact that I have to do
+ that as evidence that on amd64, the "i386 epilogue" is not only unnecessary,
+ but in the way.
+
+ Fix this by only adding the i386 unwinders if
+ "info.bfd_arch_info->bits_per_word == 32".
+
+ Note that the x32 abi (x86_64/-mx32):
+ - has the same unwinder list as amd64 (x86_64/-m64) before this commit,
+ - has info.bfd_arch_info->bits_per_word == 64, the same as amd64, and
+ consequently,
+ - has the same unwinder list as amd64 after this commit.
+
+ Tested on x86_64-linux, -m64 and -m32. Not tested with -mx32.
+
+ Reviewed-By: John Baldwin <jhb@freebsd.org>
+
+ PR tdep/30102
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30102
+
+2023-02-11 Alan Modra <amodra@gmail.com>
+
+ objdump -D of bss sections and -s with -j
+ There is some inconsistency between the behaviour of objdump -D and
+ objdump -s, both supposedly operating on all sections by default.
+ objdump -s ignores bss sections, while objdump -D dissassembles the
+ zeros. Fix this by making objdump -D ignore bss sections too.
+
+ Furthermore, "objdump -s -j .bss" doesn't dump .bss as it should,
+ since the user is specifically asking to look at all those zeros.
+
+ This change does find some tests that used objdump -D with expected
+ output in bss-style sections. I've updated all the msp430 tests that
+ just wanted to find a non-empty section to look at section headers
+ instead, making the tests slightly more stringent. The ppc xcoff and
+ spu tests are fixed by adding -j options to objdump, which makes the
+ tests somewhat more lenient.
+
+ binutils/
+ * objdump.c (disassemble_section): Ignore sections without
+ contents, unless overridden by -j.
+ (dump_section): Allow -j to override the default of not
+ displaying sections without contents.
+ * doc/binutils.texi (objdump options): Update -D, -s and -j
+ description.
+ gas/
+ * testsuite/gas/ppc/xcoff-tls-32.d: Select wanted objdump
+ sections with -j.
+ * testsuite/gas/ppc/xcoff-tls-64.d: Likewise.
+ ld/
+ * testsuite/ld-msp430-elf/main-bss-lower.d,
+ * testsuite/ld-msp430-elf/main-bss-upper.d,
+ * testsuite/ld-msp430-elf/main-const-lower.d,
+ * testsuite/ld-msp430-elf/main-const-upper.d,
+ * testsuite/ld-msp430-elf/main-text-lower.d,
+ * testsuite/ld-msp430-elf/main-text-upper.d,
+ * testsuite/ld-msp430-elf/main-var-lower.d,
+ * testsuite/ld-msp430-elf/main-var-upper.d: Expect -wh output.
+ * testsuite/ld-msp430-elf/msp430-elf.exp: Use objdump -wh
+ rather than objdump -D or objdump -d with tests checking for
+ non-empty given sections.
+ * testsuite/ld-spu/ear.d,
+ * testsuite/ld-spu/icache1.d,
+ * testsuite/ld-spu/ovl.d,
+ * testsuite/ld-spu/ovl2.d: Select wanted objdump sections.
+
+2023-02-11 Alan Modra <amodra@gmail.com>
+
+ .debug sections without contents
+ * dwarf1.c (_bfd_dwarf1_find_nearest_line): Exclude .debug
+ sections without contents.
+
+2023-02-11 Aaron Merey <amerey@redhat.com>
+
+ gdb/source: Fix open_source_file error handling
+ open_source_file relies on errno to communicate the reason for a missing
+ source file.
+
+ open_source_file may also call debuginfod_find_source. It is possible
+ for debuginfod_find_source to set errno to a value unrelated to the
+ reason for a failed download.
+
+ This can result in bogus error messages being reported as the reason for
+ a missing source file. The following error message should instead be
+ "No such file or directory":
+
+ Temporary breakpoint 1, 0x00005555556f4de0 in main ()
+ (gdb) list
+ Downloading source file /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in>
+ 1 /usr/src/debug/glibc-2.36-8.fc37.x86_64/elf/<built-in>: Directory not empty.
+
+ Fix this by having open_source_file return a negative errno if it fails
+ to open a source file. Use this value to generate the error message
+ instead of errno.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29999
+
+2023-02-11 Aaron Merey <amerey@redhat.com>
+
+ Move implementation of perror_with_name to gdbsupport
+ gdbsupport/errors.h declares perror_with_name and leaves the
+ implementation to the clients.
+
+ However gdb and gdbserver's implementations are essentially the
+ same, resulting in unnecessary code duplication.
+
+ Fix this by implementing perror_with_name in gdbsupport. Add an
+ optional parameter for specifying the errno used to generate the
+ error message.
+
+ Also move the implementation of perror_string to gdbsupport since
+ perror_with_name requires it.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-10 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ GDB: Introduce limited array lengths while printing values
+ This commit introduces the idea of loading only part of an array in
+ order to print it, what I call "limited length" arrays.
+
+ The motivation behind this work is to make it possible to print slices
+ of very large arrays, where very large means bigger than
+ `max-value-size'.
+
+ Consider this GDB session with the current GDB:
+
+ (gdb) set max-value-size 100
+ (gdb) p large_1d_array
+ value requires 400 bytes, which is more than max-value-size
+ (gdb) p -elements 10 -- large_1d_array
+ value requires 400 bytes, which is more than max-value-size
+
+ notice that the request to print 10 elements still fails, even though 10
+ elements should be less than the max-value-size. With a patched version
+ of GDB:
+
+ (gdb) p -elements 10 -- large_1d_array
+ $1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
+
+ So now the print has succeeded. It also has loaded `max-value-size'
+ worth of data into value history, so the recorded value can be accessed
+ consistently:
+
+ (gdb) p -elements 10 -- $1
+ $2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
+ (gdb) p $1
+ $3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
+ 20, 21, 22, 23, 24, <unavailable> <repeats 75 times>}
+ (gdb)
+
+ Accesses with other languages work similarly, although for Ada only
+ C-style [] array element/dimension accesses use history. For both Ada
+ and Fortran () array element/dimension accesses go straight to the
+ inferior, bypassing the value history just as with C pointers.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
+
+2023-02-10 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Add `-nonl' option to `gdb_test'
+ Add a `-nonl' option to `gdb_test' making it possible to match output
+ from commands such as `output' that do not produce a new line sequence
+ at the end, e.g.:
+
+ (gdb) output 0
+ 0(gdb)
+
+2023-02-10 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Only make data actually retrieved into value history available
+ While it makes sense to allow accessing out-of-bounds elements in the
+ debuggee and see whatever there might happen to be there in memory (we
+ are a debugger and not a programming rules enforcement facility and we
+ want to make people's life easier in chasing bugs), e.g.:
+
+ (gdb) print one_hundred[-1]
+ $1 = 0
+ (gdb) print one_hundred[100]
+ $2 = 0
+ (gdb)
+
+ we shouldn't really pretend that we have any meaningful data around
+ values recorded in history (what these commands really retrieve are
+ current debuggee memory contents outside the original data accessed,
+ really confusing in my opinion). Mark values recorded in history as
+ such then and verify accesses to be in-range for them:
+
+ (gdb) print one_hundred[-1]
+ $1 = <unavailable>
+ (gdb) print one_hundred[100]
+ $2 = <unavailable>
+
+ Add a suitable test case, which also covers integer overflows in data
+ location calculation.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-10 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Fix the mess with value byte/bit range types
+ Consistently use the LONGEST and ULONGEST types for value byte/bit
+ offsets and lengths respectively, avoiding silent truncation for ranges
+ exceeding the 32-bit span, which may cause incorrect matching. Also
+ report a conversion overflow on byte ranges that cannot be expressed in
+ terms of bits with these data types, e.g.:
+
+ (gdb) print one_hundred[1LL << 58]
+ Integer overflow in data location calculation
+ (gdb) print one_hundred[(-1LL << 58) - 1]
+ Integer overflow in data location calculation
+ (gdb)
+
+ Previously such accesses would be let through with unpredictable results
+ produced.
+
+2023-02-10 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Ignore `max-value-size' setting with value history accesses
+ We have an inconsistency in value history accesses where array element
+ accesses cause an error for entries exceeding the currently selected
+ `max-value-size' setting even where such accesses successfully complete
+ for elements located in the inferior, e.g.:
+
+ (gdb) p/d one
+ $1 = 0
+ (gdb) p/d one_hundred
+ $2 = {0 <repeats 100 times>}
+ (gdb) p/d one_hundred[99]
+ $3 = 0
+ (gdb) set max-value-size 25
+ (gdb) p/d one_hundred
+ value requires 100 bytes, which is more than max-value-size
+ (gdb) p/d one_hundred[99]
+ $7 = 0
+ (gdb) p/d $2
+ value requires 100 bytes, which is more than max-value-size
+ (gdb) p/d $2[99]
+ value requires 100 bytes, which is more than max-value-size
+ (gdb)
+
+ According to our documentation the `max-value-size' setting is a safety
+ guard against allocating an overly large amount of memory. Moreover a
+ statement in documentation says, concerning this setting, that: "Setting
+ this variable does not affect values that have already been allocated
+ within GDB, only future allocations." While in the implementer-speak
+ the sentence may be unambiguous I think the outside user may well infer
+ that the setting does not apply to values previously printed.
+
+ Therefore rather than just fixing this inconsistency it seems reasonable
+ to lift the setting for value history accesses, under an implication
+ that by having been retrieved from the debuggee they have already passed
+ the safety check. Do it then, by suppressing the value size check in
+ `value_copy' -- under an observation that if the original value has been
+ already loaded (i.e. it's not lazy), then it must have previously passed
+ said check -- making the last two commands succeed:
+
+ (gdb) p/d $2
+ $8 = {0 <repeats 100 times>}
+ (gdb) p/d $2 [99]
+ $9 = 0
+ (gdb)
+
+ Expand the testsuite accordingly, covering both value history handling
+ and the use of `value_copy' by `make_cv_value', used by Python code.
+
+2023-02-10 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Switch to using C++ standard integer type limits
+ Use <climits> instead of <limits.h> and ditch local fallback definitions
+ for minimum and maximum value macros provided by C++11. Add LONGEST_MAX
+ and LONGEST_MIN definitions.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-10 Tom Tromey <tromey@adacore.com>
+
+ Ensure all DAP requests are keyword-only
+ Python functions implementing DAP requests should not use positional
+ parameters -- it only makes sense to call them with keyword arguments.
+ This patch changes the few remaining cases to start with the special
+ "*" parameter, following this rule.
+
+2023-02-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix gdb.gdb/selftest.exp for native-extended-gdbserver
+ Following commit 4e2a80ba606 ("gdb/testsuite: expect SIGSEGV from top
+ GDB spawn id"), the next failure I get in gdb.gdb/selftest.exp, using
+ the native-extended-gdbserver, is:
+
+ (gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
+ signal SIGINT
+ Continuing with signal SIGINT.
+ FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout)
+
+ The problem is that in this gdb_test_multiple:
+
+ set description "send SIGINT signal to child process"
+ gdb_test_multiple "signal SIGINT" "$description" {
+ -re "^signal SIGINT\r\nContinuing with signal SIGINT.\r\nQuit\r\n.* $" {
+ pass "$description"
+ }
+ }
+
+ The "Continuing with signal SIGINT" portion is printed by the top GDB,
+ while the Quit portion is printed by the bottom GDB. As the
+ gdb_test_multiple is written, it expects both the the top GDB's spawn
+ id.
+
+ Fix this by splitting the gdb_test_multiple in two. The first one
+ expects the "Continuing with signal SIGINT" from the top GDB. The
+ second one expect "Quit" and the "(xgdb)" prompt from
+ $inferior_spawn_id. When debugging natively, this spawn id will be the
+ same as the top GDB's spawn id, but it's different when debugging with
+ GDBserver.
+
+ Change-Id: I689bd369a041b48f4dc9858d38bf977d09600da2
+
+2023-02-10 Tom Tromey <tom@tromey.com>
+
+ Use std::string in main_info
+ This changes main_info to use std::string. It removes some manual
+ memory management.
+
+2023-02-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp
+ PR testsuite/30103 reports the following failure on aarch64-linux
+ (ubuntu 22.04):
+ ...
+ (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp
+ next
+ warning: Breakpoint address adjusted from 0x83dc305fef755015 to \
+ 0xffdc305fef755015.
+ Warning:
+ Cannot insert breakpoint 0.
+ Cannot access memory at address 0xffdc305fef755015
+
+ __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30
+ 30 }
+ (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
+ (PRMS: next over longjmp)
+ delete breakpoints
+ Delete all breakpoints? (y or n) y
+ (gdb) info breakpoints
+ No breakpoints or watchpoints.
+ (gdb) break 63
+ No line 63 in the current file.
+ Make breakpoint pending on future shared library load? (y or [n]) n
+ (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \
+ at pattern start (got interactive prompt)
+ ...
+
+ The test-case intends to set the breakpoint on line number 63 in
+ gdb.base/longjmp.c.
+
+ It tries to do so by specifying "break 63", which specifies a line in the
+ "current source file".
+
+ Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence
+ of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c.
+
+ Consequently, setting the breakpoint fails.
+
+ Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs.
+
+ I've managed to reproduce the FAIL on x86_64/-m32, by installing the
+ glibc-32bit-debuginfo package. This allowed me to confirm the "current source
+ file" that is used:
+ ...
+ (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
+ (PRMS: next over longjmp)
+ info source^M
+ Current source file is ../setjmp/longjmp.c^M
+ ...
+
+ Tested on x86_64-linux, target boards unix/{-m64,-m32}.
+
+ Reported-By: Luis Machado <luis.machado@arm.com>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+ PR testsuite/30103
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
+
+2023-02-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Add maint info frame-unwinders
+ Add a new command "maint info frame-unwinders":
+ ...
+ (gdb) help maint info frame-unwinders
+ List the frame unwinders currently in effect, starting with the highest \
+ priority.
+ ...
+
+ Output for i386:
+ ...
+ $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ i386 epilogue NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ i386 stack tramp NORMAL_FRAME
+ i386 sigtramp SIGTRAMP_FRAME
+ i386 prologue NORMAL_FRAME
+ ...
+
+ Output for x86_64:
+ ...
+ $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders"
+ The target architecture is set to "i386:x86-64".
+ dummy DUMMY_FRAME
+ dwarf2 tailcall TAILCALL_FRAME
+ inline INLINE_FRAME
+ python NORMAL_FRAME
+ amd64 epilogue NORMAL_FRAME
+ i386 epilogue NORMAL_FRAME
+ dwarf2 NORMAL_FRAME
+ dwarf2 signal SIGTRAMP_FRAME
+ amd64 sigtramp SIGTRAMP_FRAME
+ amd64 prologue NORMAL_FRAME
+ i386 stack tramp NORMAL_FRAME
+ i386 sigtramp SIGTRAMP_FRAME
+ i386 prologue NORMAL_FRAME
+ ...
+
+ Tested on x86_64-linux.
+
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Eli Zaretskii <eliz@gnu.org>
+
+2023-02-10 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Reduce effective linker relaxation passses
+ Commit 43025f01a0c9 ("RISC-V: Improve link time complexity.") reduced the
+ time complexity of the linker relaxation but some code portions did not
+ reflect this change.
+
+ This commit fixes a comment describing each relaxation pass and reduces
+ actual number of passes for the RISC-V linker relaxation from 3 to 2.
+ Though it does not change the functionality, it marginally improves the
+ performance while linking large programs (with many relocations).
+
+ bfd/ChangeLog:
+
+ * elfnn-riscv.c (_bfd_riscv_relax_section): Fix a comment to
+ reflect current roles of each relaxation pass.
+
+ ld/ChangeLog:
+
+ * emultempl/riscvelf.em: Reduce the number of linker relaxation
+ passes from 3 to 2.
+
+2023-02-10 Alan Modra <amodra@gmail.com>
+
+ Fix mmo memory leaks
+ The main one here is the section buffer, which can be quite large.
+ By using alloc rather than malloc we can leave tidying memory to the
+ generic bfd code when the bfd is closed. bfd_check_format also
+ releases memory when object_p fails, so while it wouldn't be wrong
+ to bfd_release at bad_format_free in mmo_object_p, it's a little extra
+ code and work for no gain.
+
+ * mmo.c (mmo_object_p): bfd_alloc rather than bfd_malloc
+ lop_stab_symbol. Don't free/release on error.
+ (mmo_get_spec_section): bfd_zalloc rather than bfd_zmalloc
+ section buffer.
+ (mmo_scan): Free fname on another error path.
+
+2023-02-10 Alan Modra <amodra@gmail.com>
+
+ Local label checks in integer_constant
+ "Local labels are never absolute" says the comment. Except when they
+ are. Testcase
+ .offset
+ 0:
+ a=0b
+ I don't see any particular reason to disallow local labels inside
+ struct definitions, so delete the comment and assertions.
+
+ * expr.c (integer_constant): Delete local label assertions.
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop use of VEX3SOURCES
+ The attribute really specifies that the sum of register and memory
+ operands is 4. Express it like that in most places, while using the 2nd
+ (apart from XOP) CPU feature flags (FMA4) in reversed operand matching
+ logic.
+
+ With the use in build_modrm_byte() gone, part of an assertion there
+ also becomes meaningless - simplify that at the same time.
+
+ With all uses of the opcode modifier field gone, also drop that.
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop use of XOP2SOURCES
+ The few XOP insns which used it wrongly didn't have VexVVVV specified.
+ With that added, the only further missing piece to use more generic code
+ elsewhere is SwapSources - see e.g. the BMI2 insns for similar operand
+ patterns.
+
+ With the only users gone, drop the #define as well as the special case
+ code.
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: limit use of XOP2SOURCES
+ The VPROT* forms with an immediate operand are entirely standard in the
+ way their ModR/M bytes are built. There's no reason to invoke special
+ case code. With that the handling of an immediate there can also be
+ dropped; it was partially bogus anyway, as in its "no memory operands"
+ portion it ignores the possibility of an immediate operand (which was
+ okay only because that case was already handled by more generic code).
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: move (and rename) opcodespace attribute
+ This really isn't a "modifier" and rather ought to live next to the base
+ opcode anyway. Use the bits we presently have available to fit in the
+ field, renaming it to opcode_space. As an intended side effect this
+ helps readability at the use sites, by shortening the references quite a
+ bit.
+
+ In generated code arrange for human readable output, by using the
+ SPACE_* constants there rather than raw numbers. This may aid debugging
+ down the road.
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: simplify a few expressions
+ Fold adjacent comparisons when, by ORing in a certain mask, the same
+ effect can be achieved by a single one. In load_insn_p() this extends
+ to further uses of an already available local variable.
+
+2023-02-10 Jan Beulich <jbeulich@suse.com>
+
+ x86: improve special casing of certain insns
+ Now that we have identifiers for the mnemonic strings we can avoid
+ opcode based comparisons, for (in many cases) being more expensive and
+ (in a few cases) being a little fragile and not self-documenting.
+
+ Note that the MOV optimization can be engaged by the earlier LEA one,
+ and hence LEA also needs checking for there.
+
+2023-02-10 Alan Modra <amodra@gmail.com>
+
+ objcopy of mach-o indirect symbols
+ Anti-fuzzer measure. I'm not sure what the correct fix is for
+ objcopy. Probably the BFD_MACH_O_S_NON_LAZY_SYMBOL_POINTERS,
+ BFD_MACH_O_S_LAZY_SYMBOL_POINTERS and BFD_MACH_O_S_SYMBOL_STUBS
+ contents should be read.
+
+ * mach-o.c (bfd_mach_o_section_get_nbr_indirect): Omit sections
+ with NULL sec->indirect_syms.
+
+2023-02-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-09 Tom Tromey <tromey@adacore.com>
+
+ Add full display feature to dwarf-mode.el
+ I've found that I often use dwarf-mode with relatively small test
+ files. In this situation, it's handy to be able to expand all the
+ DWARF, rather than moving to each "..." separately and using C-u C-m.
+
+ This patch implements this feature. It also makes a couple of other
+ minor changes:
+
+ * I removed a stale FIXME from dwarf-mode. In practice I find I often
+ use "g" to restore the buffer to a pristine state; checking the file
+ mtime would work against this.
+
+ * I tightened the regexp in dwarf-insert-substructure. This prevents
+ the C-m binding from trying to re-read a DIE which has already been
+ expanded.
+
+ * Finally, I've bumped the dwarf-mode version number so that this
+ version can easily be installed using package.el.
+
+ 2023-02-09 Tom Tromey <tromey@adacore.com>
+
+ * dwarf-mode.el: Bump version to 1.8.
+ (dwarf-insert-substructure): Tighten regexp.
+ (dwarf-refresh-all): New defun.
+ (dwarf-mode-map): Bind "A" to dwarf-refresh-all.
+ (dwarf-mode): Remove old FIXME.
+
+2023-02-09 Tom Tromey <tom@tromey.com>
+
+ Fix comment in gdb.rust/fnfield.exp
+ gdb.rust/fnfield.exp has a comment that, I assume, I copied from some
+ other test. This patch fixes it.
+
+2023-02-09 Tom Tromey <tom@tromey.com>
+
+ Trivially simplify rust_language::print_enum
+ rust_language::print_enum computes:
+
+ int nfields = variant_type->num_fields ();
+
+ ... but then does not reuse this in one spot. This patch corrects the
+ oversight.
+
+2023-02-09 Roland McGrath <mcgrathr@google.com>
+
+ [aarch64] Avoid initializers for VLAs
+ Clang doesn't accept initializer syntax for variable-length
+ arrays in C. Just use memset instead.
+
+2023-02-09 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb, testsuite: Remove unnecessary call of "set print pretty on"
+ The command has no effect for the loading of GDB pretty printers and is
+ removed by this patch to avoid confusion.
+
+ Documentation for "set print pretty"
+ "Cause GDB to print structures in an indented format with one member per line"
+
+2023-02-09 Tom Tromey <tromey@adacore.com>
+
+ Increase size of main_type::nfields
+ main_type::nfields is a 'short', and has been for many years. PR
+ c++/29985 points out that 'short' is too narrow for an enum that
+ contains more than 2^15 constants.
+
+ This patch bumps the size of 'nfields'. To verify that the field
+ isn't directly used, it is also renamed. Note that this does not
+ affect the size of main_type on x86-64 Fedora 36. And, if it does
+ have a negative effect somewhere, it's worth considering that types
+ could be shrunk more drastically by using subclasses for the different
+ codes.
+
+ This is v2 of this patch, which has these changes:
+
+ * I changed nfields to 'unsigned', per Simon's request. I looked at
+ changing all the uses, but this quickly fans out into a very large
+ patch. (One additional tweak was needed, though.)
+
+ * I wrote a test case. I discovered that GCC cannot compile a large
+ enough C test case, so I resorted to using the DWARF assembler.
+ This test doesn't reproduce the crash, but it does fail without the
+ patch.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29985
+
+2023-02-09 Tom Tromey <tromey@adacore.com>
+
+ Remove mention of cooked_index_vector
+ I noticed a leftover mention of cooked_index_vector. This updates the
+ text.
+
+2023-02-09 Tom Tromey <tromey@adacore.com>
+
+ Let user C-c when waiting for DWARF index finalization
+ In PR gdb/29854, Simon pointed out that it would be good to be able to
+ use C-c when the DWARF cooked index is waiting for finalization. The
+ idea here is to be able to interrupt a command like "break" -- not to
+ stop the finalization process itself, which runs in a worker thread.
+
+ This patch implements this idea, by changing the index wait functions
+ to, by default, allow a quit. Polling is done, because there doesn't
+ seem to be a better way to interrupt a wait on a std::future.
+
+ For v2, I realized that the thread compatibility code in thread-pool.h
+ also needed an update.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29854
+
+2023-02-09 Alan Modra <amodra@gmail.com>
+
+ coff keep_relocs and keep_contents
+ keep_relocs is set by pe_ILF_save_relocs but not used anywhere in the
+ coff/pe code. It is tested by the xcoff backend but not set.
+
+ keep_contents is only used by the xcoff backend when dealing with
+ the .loader section, and it's easy enough to dispense with it there.
+ keep_contents is set in various places but that's fairly useless when
+ the contents aren't freed anyway until later linker support functions,
+ add_dynamic_symbols and check_dynamic_ar_symbols. There the contents
+ were freed if keep_contents wasn't set. I reckon we can free them
+ unconditionally.
+
+ * coff-bfd.h (struct coff_section_tdata): Delete keep_relocs
+ and keep_contents.
+ * peicode.h (pe_ILF_save_relocs): Don't set keep_relocs.
+ * xcofflink.c (xcoff_get_section_contents): Cache contents.
+ Return the contents. Update callers.
+ (_bfd_xcoff_canonicalize_dynamic_symtab): Don't set
+ keep_contents for .loader.
+ (xcoff_link_add_dynamic_symbols): Free .loader contents
+ unconditionally.
+ (xcoff_link_check_dynamic_ar_symbols): Likewise.
+
+2023-02-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-08 Alan Modra <amodra@gmail.com>
+
+ coff-sh.c keep_relocs, keep_contents and keep_syms
+ keep_relocs and keep_contents are unused nowadays except by
+ xcofflink.c, and I can't see a reason why keep_syms needs to be set.
+ The external syms are read and used by sh_relax_section and used by
+ sh_relax_delete_bytes. There doesn't appear to be any way that
+ freeing them will cause trouble.
+
+ * coff-sh.c (sh_relax_section): Don't set keep_relocs,
+ keep_contents or keep_syms.
+ (sh_relax_delete_bytes): Don't set keep_contents.
+
+2023-02-08 Alan Modra <amodra@gmail.com>
+
+ Memory leak in bfd_init_section_compress_status
+ * compress.c (bfd_init_section_compress_status): Free
+ uncompressed_buffer on error return.
+
+2023-02-08 Alan Modra <amodra@gmail.com>
+
+ Clear cached file size when bfd changed to BFD_IN_MEMORY
+ If file size is calculated by bfd_get_file_size, as it is by
+ _bfd_alloc_and_read calls in coff_object_p, then it is cached and when
+ pe_ILF_build_a_bfd converts an archive entry over to BFD_IN_MEMORY,
+ the file size is no longer valid. Found when attempting objdump -t on
+ a very small (27 bytes) ILF file and hitting the pr24707 fix (commit
+ 781152ec18f5). So, clear file size when setting BFD_IN_MEMORY on bfds
+ that may have been read. (It's not necessary in writable bfds,
+ because caching is ignored by bfd_get_size when bfd_write_p.)
+
+ I also think the PR 24707 fix is no longer neeeded. All of the
+ testcases in that PR and in PR24712 are caught earlier by file size
+ checks when reading the symbols from file. So I'm reverting that fix,
+ which just compared the size of an array of symbol pointers against
+ file size. That's only valid if on-disk symbols are larger than a
+ host pointer, so the test is better done in format-specific code.
+
+ bfd/
+ * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Clear cached
+ file size when making a BFD_IN_MEMORY bfd.
+ * opncls.c (bfd_make_readable): Likewise.
+ * peicode.h (pe_ILF_build_a_bfd): Likewise.
+ binutils/
+ PR 24707
+ * objdump.c (slurp_symtab): Revert PR24707 fix. Tidy.
+ (slurp_dynamic_symtab): Tidy.
+
+2023-02-08 Alan Modra <amodra@gmail.com>
+
+ Internal error at gas/expr.c:1814
+ This is the assertion
+ know (*input_line_pointer != ' ');
+ after calling operand.
+
+ The usual exit from operand calls SKIP_ALL_WHITESPACE.
+
+ * expr.c (operand): Call SKIP_ALL_WHITESPACE after call to expr.
+
+2023-02-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: give sentinel for user frames distinct IDs, register sentinel frames to the frame cache
+ The test gdb.base/frame-view.exp fails like this on AArch64:
+
+ frame^M
+ #0 baz (z1=hahaha, /home/simark/src/binutils-gdb/gdb/value.c:4056: internal-error: value_fetch_lazy_register: Assertion `next_frame != NULL' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame (GDB internal error)
+
+ The sequence of events leading to this is the following:
+
+ - When we create the user frame (the "select-frame view" command), we
+ create a sentinel frame just for our user-created frame, in
+ create_new_frame. This sentinel frame has the same id as the regular
+ sentinel frame.
+
+ - When printing the frame, after doing the "select-frame view" command,
+ the argument's pretty printer is invoked, which does an inferior
+ function call (this is the point of the test). This clears the frame
+ cache, including the "real" sentinel frame, which sets the
+ sentinel_frame global to nullptr.
+
+ - Later in the frame-printing process (when printing the second
+ argument), the auto-reinflation mechanism re-creates the user frame
+ by calling create_new_frame again, creating its own special sentinel
+ frame again. However, note that the "real" sentinel frame, the
+ sentinel_frame global, is still nullptr. If the selected frame had
+ been a regular frame, we would have called get_current_frame at some
+ point during the reinflation, which would have re-created the "real"
+ sentinel frame. But it's not the case when reinflating a user frame.
+
+ - Deep down the stack, something wants to fill in the unwind stop
+ reason for frame 0, which requires trying to unwind frame 1. This
+ leads us to trying to unwind the PC of frame 1:
+
+ #0 gdbarch_unwind_pc (gdbarch=0xffff8d010080, next_frame=...) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:2955
+ #1 0x000000000134569c in dwarf2_tailcall_sniffer_first (this_frame=..., tailcall_cachep=0xffff773fcae0, entry_cfa_sp_offsetp=0xfffff7f7d450)
+ at /home/simark/src/binutils-gdb/gdb/dwarf2/frame-tailcall.c:390
+ #2 0x0000000001355d84 in dwarf2_frame_cache (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1089
+ #3 0x00000000013562b0 in dwarf2_frame_unwind_stop_reason (this_frame=..., this_cache=0xffff773fc928) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1101
+ #4 0x0000000001990f64 in get_prev_frame_always_1 (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2281
+ #5 0x0000000001993034 in get_prev_frame_always (this_frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2376
+ #6 0x000000000199b814 in get_frame_unwind_stop_reason (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:3051
+ #7 0x0000000001359cd8 in dwarf2_frame_cfa (this_frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/frame.c:1356
+ #8 0x000000000132122c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d8883ee "\217\002", op_end=0xffff8d8883ee "\217\002")
+ at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:2110
+ #9 0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d8883ed "\234\217\002", len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239
+ #10 0x000000000131d68c in dwarf_expr_context::execute_stack_op (this=0xfffff7f80170, op_ptr=0xffff8d88840e "", op_end=0xffff8d88840e "") at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1811
+ #11 0x0000000001317b30 in dwarf_expr_context::eval (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1239
+ #12 0x0000000001314c3c in dwarf_expr_context::evaluate (this=0xfffff7f80170, addr=0xffff8d88840c "\221p", len=2, as_lval=true, per_cu=0xffff90b03700, frame=..., addr_info=0x0,
+ type=0xffff8f6c8400, subobj_type=0xffff8f6c8400, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1078
+ #13 0x000000000149f9e0 in dwarf2_evaluate_loc_desc_full (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980,
+ subobj_type=0xffff8f6c8400, subobj_byte_offset=0, as_lval=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1513
+ #14 0x00000000014a0100 in dwarf2_evaluate_loc_desc (type=0xffff8f6c8400, frame=..., data=0xffff8d88840c "\221p", size=2, per_cu=0xffff90b03700, per_objfile=0xffff9070b980, as_lval=true)
+ at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1557
+ #15 0x00000000014aa584 in locexpr_read_variable (symbol=0xffff8f6cd770, frame=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3052
+
+ - AArch64 defines a special "prev register" function,
+ aarch64_dwarf2_prev_register, to handle unwinding the PC. This
+ function does
+
+ frame_unwind_register_unsigned (this_frame, AARCH64_LR_REGNUM);
+
+ - frame_unwind_register_unsigned ultimately creates a lazy register
+ value, saving the frame id of this_frame->next. this_frame is the
+ user-created frame, to this_frame->next is the special sentinel frame
+ we created for it. So the saved ID is the sentinel frame ID.
+
+ - When time comes to un-lazify the value, value_fetch_lazy_register
+ calls frame_find_by_id, to find the frame with the ID we saved.
+
+ - frame_find_by_id sees it's the sentinel frame ID, so returns the
+ sentinel_frame global, which is, if you remember, nullptr.
+
+ - We hit the `gdb_assert (next_frame != NULL)` assertion in
+ value_fetch_lazy_register.
+
+ The issues I see here are:
+
+ - The ID of the sentinel frame created for the user-created frame is
+ not distinguishable from the ID of the regular sentinel frame. So
+ there's no way frame_find_by_id could find the right frame, in
+ value_fetch_lazy_register.
+ - Even if they had distinguishable IDs, sentinel frames created for
+ user frames are not registered anywhere, so there's no easy way
+ frame_find_by_id could find it.
+
+ This patch addresses these two issues:
+
+ - Give sentinel frames created for user frames their own distinct IDs
+ - Register sentinel frames in the frame cache, so they can be found
+ with frame_find_by_id.
+
+ I initially had this split in two patches, but I then found that it was
+ easier to explain as a single patch.
+
+ Rergarding the first part of the change: with this patch, the sentinel
+ frames created for user frames (in create_new_frame) still have
+ stack_status == FID_STACK_SENTINEL, but their code_addr and stack_addr
+ fields are now filled with the addresses used to create the user frame.
+ This ensures this sentinel frame ID is different from the "target"
+ sentinel frame ID, as well as any other "user" sentinel frame ID. If
+ the user tries to create the same frame, with the same addresses,
+ multiple times, create_sentinel_frame just reuses the existing frame.
+ So we won't end up with multiple user sentinels with the same ID.
+
+ Regular "target" sentinel frames remain with code_addr and stack_addr
+ unset.
+
+ The concrete changes for that part are:
+
+ - Remove the sentinel_frame_id constant, since there isn't one
+ "sentinel frame ID" now. Add the frame_id_build_sentinel function
+ for building sentinel frame IDs and a is_sentinel_frame_id function
+ to check if a frame id represents a sentinel frame.
+ - Replace the sentinel_frame_id check in frame_find_by_id with a
+ comparison to `frame_id_build_sentinel (0, 0)`. The sentinel_frame
+ global is meant to contain a reference to the "target" sentinel, so
+ the one with addresses (0, 0).
+ - Add stack and code address parameters to create_sentinel_frame, to be
+ able to create the various types of sentinel frames.
+ - Adjust get_current_frame to create the regular "target" sentinel.
+ - Adjust create_new_frame to create a sentinel with the ID specific to
+ the created user frame.
+ - Adjust sentinel_frame_prev_register to get the sentinel frame ID from
+ the frame_info object, since there isn't a single "sentinel frame ID"
+ now.
+ - Change get_next_frame_sentinel_okay to check for a
+ sentinel-frame-id-like frame ID, rather than for sentinel_frame
+ specifically, since this function could be called with another
+ sentinel frame (and we would want the assert to catch it).
+
+ The rest of the change is about registering the sentinel frame in the
+ frame cache:
+
+ - Change frame_stash_add's assertion to allow sentinel frame levels
+ (-1).
+ - Make create_sentinel_frame add the frame to the frame cache.
+ - Change the "sentinel_frame != NULL" check in reinit_frame_cache for a
+ check that the frame stash is not empty. The idea is that if we only
+ have some user-created frames in the cache when reinit_frame_cache is
+ called, we probably want to emit the frames invalid annotation. The
+ goal of that check is to avoid unnecessary repeated annotations, I
+ suppose, so the "frame cache not empty" check should achieve that.
+
+ After this change, I think we could theoritically get rid of the
+ sentienl_frame global. That sentinel frame could always be found by
+ looking up `frame_id_build_sentinel (0, 0)` in the frame cache.
+ However, I left the global there to avoid slowing the typical case down
+ for nothing. I however, noted in its comment that it is an
+ optimization.
+
+ With this fix applied, the gdb.base/frame-view.exp now passes for me on
+ AArch64. value_of_register_lazy now saves the special sentinel frame ID
+ in the value, and value_fetch_lazy_register is able to find that
+ sentinel frame after the frame cache reinit and after the user-created
+ frame was reinflated.
+
+ Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
+ Tested-By: Luis Machado <luis.machado@arm.com>
+ Change-Id: I8b77b3448822c8aab3e1c3dda76ec434eb62704f
+
+2023-02-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache
+ Currently, some frame resources are deallocated by iterating on the
+ frame chain (starting from the sentinel), calling dealloc_cache. The
+ problem is that user-created frames are not part of that chain, so we
+ never call dealloc_cache for them.
+
+ I propose to make it so the dealloc_cache callbacks are called when the
+ frames are removed from the frame_stash hash table, by registering a
+ deletion function to the hash table. This happens when
+ frame_stash_invalidate is called by reinit_frame_cache. This way, all
+ frames registered in the cache will get their unwinder's dealloc_cache
+ callbacks called.
+
+ Note that at the moment, the sentinel frames are not registered in the
+ cache, so we won't call dealloc_cache for them. However, it's just a
+ theoritical problem, because the sentinel frame unwinder does not
+ provide this callback. Also, a subsequent patch will change things so
+ that sentinel frames are registered to the cache.
+
+ I moved the obstack_free / obstack_init pair below the
+ frame_stash_invalidate call in reinit_frame_cache, because I assumed
+ that some dealloc_cache would need to access some data on that obstack,
+ so it would be better to free it after clearing the hash table.
+
+ Change-Id: If4f9b38266b458c4e2f7eb43e933090177c22190
+
+2023-02-08 Tom Tromey <tom@tromey.com>
+
+ Remove block.h includes from some tdep files
+ A few tdep files include block.h but do not need to. This patch
+ removes the inclusions. I checked that this worked correctly by
+ examining the resulting .Po file to make sure that block.h was not
+ being included by some other route.
+
+ Don't include block.h from expop.h
+ expop.h needs block.h for a single inline function. However, I don't
+ think most of the check_objfile functions need to be defined in the
+ header (just the templates). This patch moves the one offending
+ function and removes the include.
+
+2023-02-08 Pedro Alves <pedro@palves.net>
+
+ Simplify interp::exec / interp_exec - let exceptions propagate
+ This patch implements a simplication that I suggested here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186320.html
+
+ Currently, the interp::exec virtual method interface is such that
+ subclass implementations must catch exceptions and then return them
+ via normal function return.
+
+ However, higher up the in chain, for the CLI we get to
+ interpreter_exec_cmd, which does:
+
+ for (i = 1; i < nrules; i++)
+ {
+ struct gdb_exception e = interp_exec (interp_to_use, prules[i]);
+
+ if (e.reason < 0)
+ {
+ interp_set (old_interp, 0);
+ error (_("error in command: \"%s\"."), prules[i]);
+ }
+ }
+
+ and for MI we get to mi_cmd_interpreter_exec, which has:
+
+ void
+ mi_cmd_interpreter_exec (const char *command, char **argv, int argc)
+ {
+ ...
+ for (i = 1; i < argc; i++)
+ {
+ struct gdb_exception e = interp_exec (interp_to_use, argv[i]);
+
+ if (e.reason < 0)
+ error ("%s", e.what ());
+ }
+ }
+
+ Note that if those errors are reached, we lose the original
+ exception's error code. I can't see why we'd want that.
+
+ And, I can't see why we need to have interp_exec catch the exception
+ and return it via the normal return path. That's normally needed when
+ we need to handle propagating exceptions across C code, like across
+ readline or ncurses, but that's not the case here.
+
+ It seems to me that we can simplify things by removing some
+ try/catch-ing and just letting exceptions propagate normally.
+
+ Note, the "error in command" error shown above, which only exists in
+ the CLI interpreter-exec command, is only ever printed AFAICS if you
+ run "interpreter-exec console" when the top level interpreter is
+ already the console/tui. Like:
+
+ (gdb) interpreter-exec console "foobar"
+ Undefined command: "foobar". Try "help".
+ error in command: "foobar".
+
+ You won't see it with MI's "-interpreter-exec console" from a top
+ level MI interpreter:
+
+ (gdb)
+ -interpreter-exec console "foobar"
+ &"Undefined command: \"foobar\". Try \"help\".\n"
+ ^error,msg="Undefined command: \"foobar\". Try \"help\"."
+ (gdb)
+
+ nor with MI's "-interpreter-exec mi" from a top level MI interpreter:
+
+ (gdb)
+ -interpreter-exec mi "-foobar"
+ ^error,msg="Undefined MI command: foobar",code="undefined-command"
+ ^done
+ (gdb)
+
+ in both these cases because MI's -interpreter-exec just does:
+
+ error ("%s", e.what ());
+
+ You won't see it either when running an MI command with the CLI's
+ "interpreter-exec mi":
+
+ (gdb) interpreter-exec mi "-foobar"
+ ^error,msg="Undefined MI command: foobar",code="undefined-command"
+ (gdb)
+
+ This last case is because MI's interp::exec implementation never
+ returns an error:
+
+ gdb_exception
+ mi_interp::exec (const char *command)
+ {
+ mi_execute_command_wrapper (command);
+ return gdb_exception ();
+ }
+
+ Thus I think that "error in command" error is pretty pointless, and
+ since it simplifies things to not have it, the patch just removes it.
+
+ The patch also ends up addressing an old FIXME.
+
+ Change-Id: I5a6432a80496934ac7127594c53bf5221622e393
+ Approved-By: Tom Tromey <tromey@adacore.com>
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Avoid FAILs in gdb.compile
+ Many gdb.compile C++ tests fail for me on Fedora 36. I think these
+ are largely bugs in the plugin, though I didn't investigate too
+ deeply. Once one failure is seen, this often cascades and sometimes
+ there are many timeouts.
+
+ For example, this can happen:
+
+ (gdb) compile code var = a->get_var ()
+ warning: Could not find symbol "_ZZ9_gdb_exprP10__gdb_regsE1a" for compiled module "/tmp/gdbobj-0xdI6U/out2.o".
+ 1 symbols were missing, cannot continue.
+
+ I think this is probably a plugin bug because, IIRC, in theory these
+ symbols should be exempt from a lookup via gdb.
+
+ This patch arranges to catch any catastrophic failure and then simply
+ exit the entire .exp file.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Don't let .gdb_history file cause failures
+ I had a .gdb_history file in my testsuite directory in the build tree,
+ and this provoked a failure in gdbhistsize-history.exp. It seems
+ simple to prevent this file from causing a failure.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Merge fixup_section and fixup_symbol_section
+ fixup_symbol_section delegates all its work to fixup_section, so merge
+ the two.
+
+ Because there is only a single caller to fixup_symbol_section, we can
+ also remove some of the introductory logic. For example, this will
+ never be called with a NULL objfile any more.
+
+ The LOC_BLOCK case can be removed, because such symbols are handled by
+ the buildsym code now.
+
+ Finally, a symbol can only appear in a SEC_ALLOC section, so the loop
+ is modified to skip sections that do not have this flag set.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Remove most calls to fixup_symbol_section
+ Nearly every call to fixup_symbol_section in gdb is incorrect, and if
+ any such call has an effect, it's purely by happenstance.
+
+ fixup_section has a long comment explaining that the call should only
+ be made before runtime section offsets are applied. And, the loop in
+ this code (the fallback loop -- the minsym lookup code is "ok") is
+ careful to remove these offsets before comparing addresses.
+
+ However, aside from a single call in dwarf2/read.c, every call in gdb
+ is actually done after section offsets have been applied. So, these
+ calls are incorrect.
+
+ Now, these calls could be made when the symbol is created. I
+ considered this approach, but I reasoned that the code has been this
+ way for many years, seemingly without ill effect. So, instead I chose
+ to simply remove the offending calls.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Set section index when setting a symbol's block
+ When a symbol's block is set, the block has the runtime section offset
+ applied. So, it seems to me that the symbol implicitly is in the same
+ section as the block. Therefore, this patch sets the symbol's section
+ index at this same spot.
+
+ Remove compunit_symtab::m_block_line_section
+ The previous patch hard-coded SECT_OFF_TEXT into the buildsym code.
+ After this, it's clear that there is only one caller of
+ compunit_symtab::set_block_line_section, and it always passes
+ SECT_OFF_TEXT. So, remove compunit_symtab::m_block_line_section and
+ use SECT_OFF_TEXT instead.
+
+ Do not pass section index to end_compunit_symtab
+ Right now, the section index passed to end_compunit_symtab is always
+ SECT_OFF_TEXT. Remove this parameter and simply always use
+ SECT_OFF_TEXT.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Set section indices when symbols are made
+ Most places in gdb that create a new symbol will apply a section
+ offset to the address. It seems to me that the choice of offset here
+ is also an implicit choice of the section. This is particularly true
+ if you examine fixup_section, which notes that it must be called
+ before such offsets are applied -- meaning that if any such call has
+ an effect, it's purely by accident.
+
+ This patch cleans up this area by tracking the section index and
+ applying it to a symbol when the address is set. This is done for
+ nearly every case -- the remaining cases will be handled in later
+ patches.
+
+2023-02-08 Tom Tromey <tromey@adacore.com>
+
+ Use default section indexes in fixup_symbol_section
+ If fixup_section does not find a matching section, it arbitrarily
+ chooses the first one. However, it seems better to make this default
+ depend on the type of the symbol -- i.e., default data symbols to
+ .data and text symbols to .text.
+
+ I've also made fixup_section static, as it only has one caller.
+
+2023-02-08 Tom Tromey <tom@tromey.com>
+
+ Simplify checks of cooked_index
+ This changes the cooked_index_functions to avoid an extra null check
+ now that checked_static_cast allows a null argument.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp
+ Test-case gdb.base/longjmp.exp handles both the case that there is a libc
+ longjmp probe, and the case that there isn't.
+
+ However, it only tests one of the two cases.
+
+ Use maint ignore-probes to test both cases, if possible.
+
+ Tested on x86_64-linux.
+
+2023-02-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use maint ignore-probes in gdb.base/solib-corrupted.exp
+ Test-case gdb.base/solib-corrupted.exp only works for a glibc without probes
+ interface, otherwise we run into:
+ ...
+ XFAIL: gdb.base/solib-corrupted.exp: info probes
+ UNTESTED: gdb.base/solib-corrupted.exp: GDB is using probes
+ ...
+
+ Fix this by using maint ignore-probes to simulate the absence of the relevant
+ probes.
+
+ Also, it requires glibc debuginfo, and if not present, it produces an XFAIL:
+ ...
+ XFAIL: gdb.base/solib-corrupted.exp: make solibs looping
+ UNTESTED: gdb.base/solib-corrupted.exp: no _r_debug symbol has been found
+ ...
+ This is incorrect, because an XFAIL indicates a known problem in the
+ environment. In this case, there is no problem: the environment is
+ functioning as expected when glibc debuginfo is not installed.
+
+ Fix this by using UNSUPPORTED instead, and make the message less cryptic:
+ ...
+ UNSUPPORTED: gdb.base/solib-corrupted.exp: make solibs looping \
+ (glibc debuginfo required)
+ ...
+
+ Finally, with glibc debuginfo present, we run into:
+ ...
+ (gdb) PASS: gdb.base/solib-corrupted.exp: make solibs looping
+ info sharedlibrary^M
+ warning: Corrupted shared library list: 0x7ffff7ffe750 != 0x0^M
+ From To Syms Read Shared Object Library^M
+ 0x00007ffff7dd4170 0x00007ffff7df4090 Yes /lib64/ld-linux-x86-64.so.2^M
+ (gdb) FAIL: gdb.base/solib-corrupted.exp: corrupted list \
+ (shared library list corrupted)
+ ...
+ due to commit 44288716537 ("gdb, testsuite: extend gdb_test_multiple checks").
+
+ Fix this by rewriting into gdb_test_multiple and using -early.
+
+ Tested on x86_64-linux, with and without glibc debuginfo installed.
+
+2023-02-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix SIGSEGV when processing unusual dwarf
+ gprofng/ChangeLog
+ 2023-02-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30093
+ * src/Dwarf.cc: add nullptr check.
+ * src/DwarfLib.cc: Likewise.
+
+2023-02-08 Alan Modra <amodra@gmail.com>
+
+ Re: Resetting section vma after _bfd_dwarf2_find_nearest_line
+ f.bfd_ptr is set too early to be a reliable indicator of good debug
+ info.
+
+ * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Correct test for
+ debug info being previously found.
+
+2023-02-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix display of thread condition for multi-location breakpoints
+ This commit addresses the issue in PR gdb/30087.
+
+ If a breakpoint with multiple locations has a thread condition, then
+ the 'info breakpoints' output is a little messed up, here's an example
+ of the current output:
+
+ (gdb) break foo thread 1
+ Breakpoint 2 at 0x401114: foo. (3 locations)
+ (gdb) break bar thread 1
+ Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE> thread 1
+ stop only in thread 1
+ 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1
+ stop only in thread 1
+
+ Notice that, at the end of the location for breakpoint 3, the 'thread
+ 1' condition is printed, but this is then repeated on the next line
+ with 'stop only in thread 1'.
+
+ In contrast, for breakpoint 2, the 'thread 1' appears randomly, in the
+ "What" column, though slightly offset, non of the separate locations
+ have the 'thread 1' information. Additionally for breakpoint 2 we
+ also get a 'stop only in thread 1' line.
+
+ There's two things going on here. First the randomly placed 'thread
+ 1' for breakpoint 2 is due to a bug in print_one_breakpoint_location,
+ where we check the variable part_of_multiple instead of
+ header_of_multiple.
+
+ If I fix this oversight, then the output is now:
+
+ (gdb) break foo thread 1
+ Breakpoint 2 at 0x401114: foo. (3 locations)
+ (gdb) break bar thread 1
+ Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE>
+ stop only in thread 1
+ 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
+ 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
+ 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25 thread 1
+ 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32 thread 1
+ stop only in thread 1
+
+ The 'thread 1' condition is now displayed at the end of each location,
+ which makes the output the same for single location breakpoints and
+ multi-location breakpoints.
+
+ However, there's still some duplication here. Both breakpoints 2 and
+ 3 include a 'stop only in thread 1' line, and it feels like the
+ additional 'thread 1' is redundant. In fact, there's a comment to
+ this very effect in the code:
+
+ /* FIXME: This seems to be redundant and lost here; see the
+ "stop only in" line a little further down. */
+
+ So, lets fix this FIXME. The new plan is to remove all the trailing
+ 'thread 1' markers from the CLI output, we now get this:
+
+ (gdb) break foo thread 1
+ Breakpoint 2 at 0x401114: foo. (3 locations)
+ (gdb) break bar thread 1
+ Breakpoint 3 at 0x40110a: file /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c, line 32.
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE>
+ stop only in thread 1
+ 2.1 y 0x0000000000401114 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 2.2 y 0x0000000000401146 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 2.3 y 0x0000000000401168 in foo at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:25
+ 3 breakpoint keep y 0x000000000040110a in bar at /tmp/src/gdb/testsuite/gdb.base/thread-bp-multi-loc.c:32
+ stop only in thread 1
+
+ All of the above points are also true for the Ada 'task' breakpoint
+ condition, and the changes I've made also update how the task
+ information is printed, though in the case of the Ada task there was
+ no 'stop only in task XXX' line printed, so I've added one of those.
+
+ Obviously it can't be quite that easy. For MI backwards compatibility
+ I've retained the existing code (but now only for MI like outputs),
+ which ensures we should generate backwards compatible output.
+
+ I've extended an Ada test to cover the new task related output, and
+ updated all the tests I could find that checked for the old output.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30087
+
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2023-02-07 Nick Clifton <nickc@redhat.com>
+
+ Fix documentation of the 'n' symbol type displayed by nm.
+ PR 30080 * doc/binutils.texi (nm): Update description of the 'n' symbol type.
+
+2023-02-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve untested message in gdb.ada/finish-var-size.exp
+ I came across:
+ ...
+ UNTESTED: gdb.ada/finish-var-size.exp: GCC too told for this test
+ ...
+ The message only tells us that the compiler version too old, not what compiler
+ version is required.
+
+ Fix this by rewriting using required:
+ ...
+ UNSUPPORTED: gdb.ada/finish-var-size.exp: require failed: \
+ expr [gcc_major_version] >= 12
+ ...
+
+ Tested on x86_64-linux.
+
+2023-02-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: adjust comment on target_desc_info::from_user_p
+ Remove the stale reference to INFO, which is now "this target
+ description info" now.
+
+ Change-Id: I35dbdb089048ed7cfffe730d3134ee391b176abf
+
+2023-02-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: extend the documentation for the 'handle' command
+ The documentation for the 'handle' command does not cover all of the
+ features of the command, and in one case, is just wrong.
+
+ The user can specify 'all' as signal name, the documentation implies
+ that this will change the behaviour of all signals, in reality, this
+ changes all signals except SIGINT and SIGTRAP (the signals used by
+ GDB). I've updated the docs to list this limitation.
+
+ The 'handle' command also allows the user to specify multiple signals
+ for a single command, e.g. 'handle SIGFPE SIGILL nostop pass print',
+ however the documentation doesn't describe this, so I've updated the
+ docs to describe this feature.
+
+2023-02-06 Alan Modra <amodra@gmail.com>
+
+ ppc32 and "LOAD segment with RWX permissions"
+ When using a bss-plt we'll always trigger the RWX warning, which
+ disturbs gcc test results. On the other hand, there may be reason to
+ want the warning when gcc is configured with --enable-secureplt.
+ So turning off the warning entirely for powerpc might not be the best
+ solution. Instead, we'll turn off the warning whenever a bss-plt is
+ generated, unless the user explicitly asked for the warning.
+
+ bfd/
+ * elf32-ppc.c (ppc_elf_select_plt_layout): Set
+ no_warn_rwx_segments on generating a bss plt, unless explicity
+ enabled by the user. Also show the bss-plt warning when
+ --warn-rwx-segments is given without --bss-plt.
+ include/
+ * bfdlink.h (struct bfd_link_info): Add user_warn_rwx_segments.
+ ld/
+ * lexsup.c (parse_args): Set user_warn_rwx_segments.
+ * testsuite/ld-elf/elf.exp: Pass --secure-plt for powerpc to
+ the rwx tests.
+
+2023-02-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/schedlock.exp on fast cpu
+ Occasionally, I run into:
+ ...
+ (gdb) PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
+ set scheduler-locking on
+ continue^M
+ Continuing.^M
+ PASS: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
+ continue (with lock)
+ [Thread 0x7ffff746e700 (LWP 1339) exited]^M
+ No unwaited-for children left.^M
+ (gdb) Quit^M
+ (gdb) FAIL: gdb.threads/schedlock.exp: schedlock=on: cmd=continue: \
+ stop all threads (with lock) (timeout)
+ ...
+
+ What happens is that this loop which is supposed to run "just short of forever":
+ ...
+ /* Don't run forever. Run just short of it :) */
+ while (*myp > 0)
+ {
+ /* schedlock.exp: main loop. */
+ MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
+ }
+ ...
+ finishes after 0x7fffffff iterations (when a signed wrap occurs), which on my
+ system takes only about 1.5 seconds.
+
+ Fix this by:
+ - changing the pointed-at type of myp from signed to unsigned, which makes the
+ wrap defined behaviour (and which also make the loop run twice as long,
+ which is already enough to make it impossible for me to reproduce the FAIL.
+ But let's try to solve this more structurally).
+ - changing the pointed-at type of myp from int to long long, making the wrap
+ unlikely.
+ - making sure the loop runs forever, by setting the loop condition to 1.
+ - making sure the loop still contains different lines (as far as debug info is
+ concerned) by incrementing a volatile counter in the loop.
+ - making sure the program doesn't run forever in case of trouble, by adding an
+ "alarm (30)".
+
+ Tested on x86_64-linux.
+
+ PR testsuite/30074
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30074
+
+2023-02-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: error if 'thread' or 'task' keywords are overused
+ When creating a breakpoint or watchpoint, the 'thread' and 'task'
+ keywords can be used to create a thread or task specific breakpoint or
+ watchpoint.
+
+ Currently, a thread or task specific breakpoint can only apply for a
+ single thread or task, if multiple threads or tasks are specified when
+ creating the breakpoint (or watchpoint), then the last specified id
+ will be used.
+
+ The exception to the above is that when the 'thread' keyword is used
+ during the creation of a watchpoint, GDB will give an error if
+ 'thread' is given more than once.
+
+ In this commit I propose making this behaviour consistent, if the
+ 'thread' or 'task' keywords are used more than once when creating
+ either a breakpoint or watchpoint, then GDB will give an error.
+
+ I haven't updated the manual, we don't explicitly say that these
+ keywords can be repeated, and (to me), given the keyword takes a
+ single id, I don't think it makes much sense to repeat the keyword.
+ As such, I see this more as adding a missing error to GDB, rather than
+ making some big change. However, I have added an entry to the NEWS
+ file as I guess it is possible that some people might hit this new
+ error with an existing (I claim, badly written) GDB script.
+
+ I've added some new tests to check for the new error.
+
+ Just one test needed updating, gdb.linespec/keywords.exp, this test
+ did use the 'thread' keyword twice, and expected the breakpoint to be
+ created. Looking at what this test was for though, it was checking
+ the use of '-force-condition', and I don't think that being able to
+ repeat 'thread' was actually a critical part of this test.
+
+ As such, I've updated this test to expect the error when 'thread' is
+ repeated.
+
+2023-02-06 Alan Modra <amodra@gmail.com>
+
+ Resetting section vma after _bfd_dwarf2_find_nearest_line
+ There are failure paths in _bfd_dwarf2_slurp_debug_info that can
+ result in altered section vmas. Also, when setting ET_REL section
+ vmas it's not too difficult to handle cases where the original vma was
+ non-zero, so do that too.
+
+ This patch was really in response to an addr2line buffer overflow
+ processing a fuzzed mips relocatable object file. The file had a
+ number of .debug_info sections with relocations that included lo16 and
+ hi16 relocs, and in that order. At least one section VMA was
+ non-zero. This resulted in processing of DWARF info twice, once via
+ the call to _bfd_dwarf2_find_nearest_line in
+ _bfd_mips_elf_find_nearest_line, and because that failed leaving VMAs
+ altered, the second via the call in _bfd_elf_find_nearest_line. The
+ first call left entries on mips_hi16_list pointing at buffers
+ allocated during the first call, the second call processed the
+ mips_hi16_list after the buffers had been freed. (At least when
+ running with asan and under valgrind. Under gdb with a non-asan
+ addr2line the second call allocated exactly the same buffer and the
+ bug didn't show.) Now I don't really care too much what happens with
+ fuzzed files, but the logic in _bfd_dwarf2_find_nearest_line is meant
+ to result in only one read of .debug_info, not multiple reads of the
+ same info when there are errors. This patch fixes that problem.
+
+ * dwarf2.c (struct adjusted_section): Add orig_vma.
+ (unset_sections): Reset vma to it.
+ (place_sections): Handle non-zero vma too. Save orig_vma.
+ (_bfd_dwarf2_slurp_debug_info): Tidy. Correct outdated comment.
+ On error returns after calling place_sections, call
+ unset_sections.
+ (_bfd_dwarf2_find_nearest_line_with_alt): Simplify call to
+ unset_sections.
+
+2023-02-06 Romain Geissler <romain.geissler@amadeus.com>
+
+ [PR 30082] Pass $JANSSON_LIBS and $ZSTD_LIBS to ld-bootstrap/bootrap.exp
+
+2023-02-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: don't try to set non-stop mode on a running target
+ The test gdb.threads/thread-specific-bp.exp tries to set non-stop mode
+ on a running target, something which the manual makes clear is not
+ allowed.
+
+ This commit restructures the test a little, we now set the non-stop
+ mode as part of the GDBFLAGS, so the mode will be set before GDB
+ connects to the target. As a consequence I'm able to move the
+ with_test_prefix out of the check_thread_specific_breakpoint proc.
+ The check_thread_specific_breakpoint proc is now called within a loop.
+
+ After this commit the gdb.threads/thread-specific-bp.exp test still
+ has some failures, this is because of an issue GDB currently has
+ printing "Thread ... exited" messages. This problem should be
+ addressed by this patch:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-December/194694.html
+
+ when it is merged.
+
+2023-02-04 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ ld: pru: Add optional section alignments
+ The Texas Instruments SoCs with AARCH64 host processors have stricter
+ alignment requirements than ones with ARM32 host processors. It's not
+ only the requirement for resource_table to be aligned to 8. But also
+ any loadable segment size must be a multiple of 4 [1].
+
+ The current PRU default linker script may output a segment size not
+ aligned to 4, which would cause firmware load failure on AARCH64 hosts.
+
+ Fix this by using COMMONPAGESIZE and MAXPAGESIZE to signify respectively
+ the section memory size requirement and the resource table section's
+ start address alignment. This would avoid penalizing the ARM32 hosts,
+ for which the default values (1 and 1) are sufficient.
+
+ For AARCH64 hosts, the alignments would be overwritten from GCC spec
+ files using the linker command line, e.g.:
+ -z common-page-size=4 -z max-page-size=8
+
+ [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n555
+
+ ld/ChangeLog:
+
+ * scripttempl/pru.sc (_data_end): Remove the alignment.
+ (.data): Align output section size to COMMONPAGESIZE.
+ (.resource_table): Ditto.
+
+2023-02-04 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ ld: pru: Merge the bss input sections into data
+ The popular method to load PRU firmware is through the remoteproc Linux
+ kernel driver. In order to save a few bytes from the firmware, the PRU
+ CRT0 is spared from calling memset for the bss segment [1]. Instead the
+ host loader is supposed to zero out the bss segment. This is important
+ for PRU, which typically has only 8KB for instruction memory.
+
+ The legacy non-mainline PRU host driver relied on the default
+ behaviour of the kernel core remoteproc [2]. That default is to zero
+ out the loadable memory regions not backed by file storage (i.e. the
+ bss sections). This worked for the libgloss' CRT0.
+
+ But the PRU loader merged in mainline Linux explicitly changes the
+ default behaviour [3]. It no longer is zeroing out memory regions.
+ Hence the bss sections are not initialized - neither by CRT0, nor by the
+ host loader.
+
+ This patch fixes the issue by aligning the GNU LD default linker script
+ with the mainline Linux kernel expectation. Since the mainline kernel
+ driver is submitted by the PRU manufacturer itself (Text Instruments),
+ we can consider that as defining the ABI.
+
+ This change has been tested on Beaglebone AI-64 [4]. Static counter
+ variables in the firmware are now always starting from zero, as
+ expected. There was only one new toolchain test failure in orphan3.d,
+ due to reordering of the output sections. I believe this is a harmless
+ issue. I could not rewrite the PASS criteria to ignore the output
+ section ordering, so I have disabled that test case for PRU.
+
+ [1] https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=libgloss/pru/crt0.S;h=b3f0d53a93acc372f461007553e7688ca77753c9;hb=HEAD#l40
+ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/remoteproc_elf_loader.c?h=v6.1#n228
+ [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c?h=v6.1#n641
+ [4] https://beagleboard.org/ai-64
+
+ ld/ChangeLog:
+
+ * scripttempl/pru.sc (.data): Merge .bss input sections into the
+ .data output section.
+ * testsuite/ld-elf/orphan3.d: Disable for PRU.
+
+2023-02-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-03 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ bpf: fix error conversion from long unsigned int to unsigned int [-Werror=overflow]
+ Regenerating BPF target using the maintainer mode emits:
+ .../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
+ 57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
+
+ The use of a narrow size to handle the mask CGEN in instruction format
+ is causing this error. Additionally eBPF `call' instructions
+ constructed by expressions using symbols (BPF_PSEUDO_CALL) emits
+ annotations in `src' field of the instruction, used to identify BPF
+ target endianness.
+
+ cpu/
+ * bpf.cpu (define-call-insn): Remove `src' field from
+ instruction mask.
+
+ include/
+ *opcode/cge.h (CGEN_IFMT): Adjust mask bit width.
+
+ opcodes/
+ * bpf-opc.c: Regenerate.
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make target_desc_info_from_user_p a method of target_desc_info
+ Move the implementation over to target_desc_info. Remove the
+ target_desc_info forward declaration in target-descriptions.h, it's no
+ longer needed.
+
+ Change-Id: Ic95060341685afe0b73af591ca6efe32f5e7e892
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove copy_inferior_target_desc_info
+ This function is now trivial, we can just copy inferior::tdesc_info
+ where needed.
+
+ Change-Id: I25185e2cd4ba1ef24a822d9e0eebec6e611d54d6
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove get_tdesc_info
+ Remove this function, since it's now a trivial access to
+ inferior::tdesc_info.
+
+ Change-Id: I3e88a8214034f1a4163420b434be11f51eef462c
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change inferior::tdesc_info to non-pointer
+ I initially made this field a unique pointer, to have automatic memory
+ management. But I then thought that the field didn't really need to be
+ allocated separately from struct inferior. So make it a regular
+ non-pointer field of inferior.
+
+ Remove target_desc_info_free, as it's no longer needed.
+
+ Change-Id: Ica2b97071226f31c40e86222a2f6922454df1229
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: move target_desc_info to inferior.h
+ In preparation for the following patch, where struct inferior needs to
+ "see" struct target_desc_info, move target_desc_info to the header file.
+
+ I initially moved the structure to target-descriptions.h, and later made
+ inferior.h include target-descriptions.h. This worked, but it then
+ occured to me that target_desc_info is really an inferior property that
+ involves a target description, so I think it makes sense to have it in
+ inferior.h.
+
+ Change-Id: I3e81d04faafcad431e294357389f3d4c601ee83d
+
+2023-02-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use assignment to initialize variable in tdesc_parse_xml
+ Since allocate_target_description returns a target_desc_up, use
+ assignment to initialize the description variable.
+
+ Change-Id: Iab3311642c09b95648984f305936f4a4cde09440
+
+2023-02-03 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop LOCK from XCHG when optimizing
+ Like with segment overrides on LEA, optimize away such a redundant
+ instruction prefix.
+
+ x86-64: respect {nooptimize} when building VEX prefix
+ Swapping operands for commutative insns occurs outside of
+ optimize_encoding() and hence needs explicit checking for a request to
+ avoid any optimizations.
+
+ x86: respect {nooptimize} for LEA
+ Dropping a meaningless segment prefix occurs outside of
+ optimize_encoding() and hence needs explicit checking for a request to
+ avoid any optimizations.
+
+ x86-64: respect MOVABS when choosing alternative encodings
+ The alternative encoding is valid for MOV, but there's no such thing for
+ MOVABS.
+
+ RISC-V: don't disassemble unrecognized insns as .byte
+ Insn width granularity being 16 bits, producing byte granular output
+ isn't very useful. With there being a way to specific otherwise
+ unknown insns to the assembler, use that same representation (to be
+ precise: its <length>,<encoding> flavor) for disassembly.
+
+2023-02-03 Alan Modra <amodra@gmail.com>
+
+ Add ECOFF Symbolic Header sanity checks
+ Anti-fuzzer measures. The checks don't ensure the various elements in
+ the header are distinct, but that isn't important as far as making
+ sure we don't overrun the buffer containing all the elements. Also,
+ we now don't care about offsets where the corresponding count is zero.
+
+ * ecoff.c (_bfd_ecoff_slurp_symbolic_info): Sanity check offsets
+ in debug->symbolic_header.
+
+2023-02-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: initial support for ROCm platform (AMDGPU) debugging
+ This patch adds the foundation for GDB to be able to debug programs
+ offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest
+ public release of the ROCm release at the time of writing is 5.4, so
+ this is what this patch targets.
+
+ The ROCm platform allows host programs to schedule bits of code for
+ execution on GPUs or similar accelerators. The programs running on GPUs
+ are typically referred to as `kernels` (not related to operating system
+ kernels).
+
+ Programs offloaded with the AMD ROCm platform can be written in the HIP
+ language [2], OpenCL and OpenMP, but we're going to focus on HIP here.
+ The HIP language consists of a C++ Runtime API and kernel language.
+ Here's an example of a very simple HIP program:
+
+ #include "hip/hip_runtime.h"
+ #include <cassert>
+
+ __global__ void
+ do_an_addition (int a, int b, int *out)
+ {
+ *out = a + b;
+ }
+
+ int
+ main ()
+ {
+ int *result_ptr, result;
+
+ /* Allocate memory for the device to write the result to. */
+ hipError_t error = hipMalloc (&result_ptr, sizeof (int));
+ assert (error == hipSuccess);
+
+ /* Run `do_an_addition` on one workgroup containing one work item. */
+ do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr);
+
+ /* Copy result from device to host. Note that this acts as a synchronization
+ point, waiting for the kernel dispatch to complete. */
+ error = hipMemcpyDtoH (&result, result_ptr, sizeof (int));
+ assert (error == hipSuccess);
+
+ printf ("result is %d\n", result);
+ assert (result == 3);
+
+ return 0;
+ }
+
+ This program can be compiled with:
+
+ $ hipcc simple.cpp -g -O0 -o simple
+
+ ... where `hipcc` is the HIP compiler, shipped with ROCm releases. This
+ generates an ELF binary for the host architecture, containing another
+ ELF binary with the device code. The ELF for the device can be
+ inspected with:
+
+ $ roc-obj-ls simple
+ 1 host-x86_64-unknown-linux file://simple#offset=8192&size=0
+ 1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216
+ $ roc-obj-extract 'file://simple#offset=8192&size=34216'
+ $ file simple-offset8192-size34216.co
+ simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped
+ ^
+ amcgcn architecture that my `file` doesn't know about ----´
+
+ Running the program gives the very unimpressive result:
+
+ $ ./simple
+ result is 3
+
+ While running, this host program has copied the device program into the
+ GPU's memory and spawned an execution thread on it. The goal of this
+ GDB port is to let the user debug host threads and these GPU threads
+ simultaneously. Here's a sample session using a GDB with this patch
+ applied:
+
+ $ ./gdb -q -nx --data-directory=data-directory ./simple
+ Reading symbols from ./simple...
+ (gdb) break do_an_addition
+ Function "do_an_addition" not defined.
+ Make breakpoint pending on future shared library load? (y or [n]) y
+ Breakpoint 1 (do_an_addition) pending.
+ (gdb) r
+ Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+ [New Thread 0x7ffff5db7640 (LWP 1082911)]
+ [New Thread 0x7ffef53ff640 (LWP 1082913)]
+ [Thread 0x7ffef53ff640 (LWP 1082913) exited]
+ [New Thread 0x7ffdecb53640 (LWP 1083185)]
+ [New Thread 0x7ffff54bf640 (LWP 1083186)]
+ [Thread 0x7ffdecb53640 (LWP 1083185) exited]
+ [Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0]
+
+ Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
+ 24 *out = a + b;
+ (gdb) info inferiors
+ Num Description Connection Executable
+ * 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
+ (gdb) info threads
+ Id Target Id Frame
+ 1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1
+ 2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
+ 5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
+ * 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition (
+ a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
+ (gdb) bt
+ Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1
+ #0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
+ out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
+ (gdb) continue
+ Continuing.
+ result is 3
+ warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208"
+ [Thread 0x7ffff54bf640 (LWP 1083186) exited]
+ [Thread 0x7ffff5db7640 (LWP 1082911) exited]
+ [Inferior 1 (process 1082907) exited normally]
+
+ One thing to notice is the host and GPU threads appearing under
+ the same inferior. This is a design goal for us, as programmers tend to
+ think of the threads running on the GPU as part of the same program as
+ the host threads, so showing them in the same inferior in GDB seems
+ natural. Also, the host and GPU threads share a global memory space,
+ which fits the inferior model.
+
+ Another thing to notice is the error messages when trying to read
+ variables or printing a backtrace. This is expected for the moment,
+ since the AMD GPU compiler produces some DWARF that uses some
+ non-standard extensions:
+
+ https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
+
+ There were already some patches posted by Zoran Zaric earlier to make
+ GDB support these extensions:
+
+ https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/
+
+ We think it's better to get the basic support for AMD GPU in first,
+ which will then give a better justification for GDB to support these
+ extensions.
+
+ GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware
+ thread using the SIMT (single-instruction, multiple-threads) [3]
+ execution model.
+
+ GDB uses the amd-dbgapi library [4], included in the ROCm platform, for
+ a few things related to AMD GPU threads debugging. Different components
+ talk to the library, as show on the following diagram:
+
+ +---------------------------+ +-------------+ +------------------+
+ | GDB | amd-dbgapi target | <-> | AMD | | Linux kernel |
+ | +-------------------+ | Debugger | +--------+ |
+ | | amdgcn gdbarch | <-> | API | <=> | AMDGPU | |
+ | +-------------------+ | | | driver | |
+ | | solib-rocm | <-> | (dbgapi.so) | +--------+---------+
+ +---------------------------+ +-------------+
+
+ - The amd-dbgapi target is a target_ops implementation used to control
+ execution of GPU threads. While the debugging of host threads works
+ by using the ptrace / wait Linux kernel interface (as usual), control
+ of GPU threads is done through a special interface (dubbed `kfd`)
+ exposed by the `amdgpu` Linux kernel module. GDB doesn't interact
+ directly with `kfd`, but instead goes through the amd-dbgapi library
+ (AMD Debugger API on the diagram).
+
+ Since it provides execution control, the amd-dbgapi target should
+ normally be a process_stratum_target, not just a target_ops. More
+ on that later.
+
+ - The amdgcn gdbarch (describing the hardware architecture of the GPU
+ execution units) offloads some requests to the amd-dbgapi library,
+ so that knowledge about the various architectures doesn't need to be
+ duplicated and baked in GDB. This is for example for things like
+ the list of registers.
+
+ - The solib-rocm component is an solib provider that fetches the list of
+ code objects loaded on the device from the amd-dbgapi library, and
+ makes GDB read their symbols. This is very similar to other solib
+ providers that handle shared libraries, except that here the shared
+ libraries are the pieces of code loaded on the device.
+
+ Given that Linux host threads are managed by the linux-nat target, and
+ the GPU threads are managed by the amd-dbgapi target, having all threads
+ appear in the same inferior requires the two targets to be in that
+ inferior's target stack. However, there can only be one
+ process_stratum_target in a given target stack, since there can be only
+ one target per slot. To achieve it, we therefore resort the hack^W
+ solution of placing the amd-dbgapi target in the arch_stratum slot of
+ the target stack, on top of the linux-nat target. Doing so allows the
+ amd-dbgapi target to intercept target calls and handle them if they
+ concern GPU threads, and offload to beneath otherwise. See
+ amd_dbgapi_target::fetch_registers for a simple example:
+
+ void
+ amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno)
+ {
+ if (!ptid_is_gpu (regcache->ptid ()))
+ {
+ beneath ()->fetch_registers (regcache, regno);
+ return;
+ }
+
+ // handle it
+ }
+
+ ptids of GPU threads are crafted with the following pattern:
+
+ (pid, 1, wave id)
+
+ Where pid is the inferior's pid and "wave id" is the wave handle handed
+ to us by the amd-dbgapi library (in practice, a monotonically
+ incrementing integer). The idea is that on Linux systems, the
+ combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always
+ belong to the init process, which would also have pid == 1 (and it's
+ improbable for the init process to offload work to the GPU and much less
+ for the user to debug it). We can therefore differentiate GPU and
+ non-GPU ptids this way. See ptid_is_gpu for more details.
+
+ Note that we believe that this scheme could break down in the context of
+ containers, where the initial process executed in a container has pid 1
+ (in its own pid namespace). For instance, if you were to execute a ROCm
+ program in a container, then spawn a GDB in that container and attach to
+ the process, it will likely not work. This is a known limitation. A
+ workaround for this is to have a dummy process (like a shell) fork and
+ execute the program of interest.
+
+ The amd-dbgapi target watches native inferiors, and "attaches" to them
+ using amd_dbgapi_process_attach, which gives it a notifier fd that is
+ registered in the event loop (see enable_amd_dbgapi). Note that this
+ isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached
+ is a precondition for amd_dbgapi_process_attach to work. When the
+ debugged process enables the ROCm runtime, the amd-dbgapi target gets
+ notified through that fd, and pushes itself on the target stack of the
+ inferior. The amd-dbgapi target is then able to intercept target_ops
+ calls. If the debugged process disables the ROCm runtime, the
+ amd-dbgapi target unpushes itself from the target stack.
+
+ This way, the amd-dbgapi target's footprint stays minimal when debugging
+ a process that doesn't use the AMD ROCm platform, it does not intercept
+ target calls.
+
+ The amd-dbgapi library is found using pkg-config. Since enabling
+ support for the amdgpu architecture (amdgpu-tdep.c) depends on the
+ amd-dbgapi library being present, we have the following logic for
+ the interaction with --target and --enable-targets:
+
+ - if the user explicitly asks for amdgcn support with
+ --target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for
+ the amd-dbgapi and fail if not found
+
+ - if the user uses --enable-targets=all, we probe for amd-dbgapi,
+ enable amdgcn support if found, disable amdgcn support if not found
+
+ - if the user uses --enable-targets=all and --with-amd-dbgapi=yes,
+ we probe for amd-dbgapi, enable amdgcn if found and fail if not found
+
+ - if the user uses --enable-targets=all and --with-amd-dbgapi=no,
+ we do not probe for amd-dbgapi, disable amdgcn support
+
+ - otherwise, amd-dbgapi is not probed for and support for amdgcn is not
+ enabled
+
+ Finally, a simple test is included. It only tests hitting a breakpoint
+ in device code and resuming execution, pretty much like the example
+ shown above.
+
+ [1] https://docs.amd.com/category/ROCm_v5.4
+ [2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4
+ [3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads
+ [4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4
+
+ Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee
+ Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com>
+ Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
+ Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
+ Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2023-02-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make gdb_printing_disassembler::stream public
+ In the ROCm port, we need to access the underlying stream of a
+ gdb_printing_disassembler, so make it public. The reason we need to
+ access it is to know whether it supports style escape code. We then
+ pass that information to a temporary string_file we use while
+ symbolizing addresses.
+
+ Change-Id: Ib95755a4a45b8f6478787993e9f904df60dd8dc1
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/solib-svr4: don't disable probes interface if probe not found
+ In ROCm-GDB, we install an solib provider for the GPU code objects on
+ top of the svr4 provider for the host, in order to add solibs
+ representing the GPU code objects to the solib list containing the host
+ process' shared libraries. We override the target_so_ops::handle_event
+ function pointer with our own, in which we call svr4_so_ops.handle_event
+ (which contains svr4_handle_solib_event) manually. When the host
+ (un)loads a library, the ROCm part of handle_event is a no-op. When the
+ GPU (un)loads a code object, we want the host side (svr4) to be a no-op.
+
+ The problem is that when handle_event is called because of a GPU event,
+ svr4_handle_solib_event gets called while not stopped at an svr4
+ probe. It then assumes this means there's a problem with the probes
+ interface and disables it through the following sequence of events:
+
+ - solib_event_probe_at return nullptr
+ - svr4_handle_solib_event returns early
+ - the make_scope_exit callback calls disable_probes_interface
+
+ We could fix that by making the ROCm handle_event callback check if an
+ svr4 probe is that the stop address, and only call
+ svr4_so_ops.handle_event if so. However, it doesn't feel right to
+ include some svr4 implementation detail in the ROCm event handler.
+
+ Instead, this patch changes svr4_handle_solib_event to not assume it is
+ an error if called while not at an svr4 probe location, and therefore
+ not disable the probes interface. That just means moving the
+ make_scope_exit call below where we lookup the probe by pc.
+
+ Change-Id: Ie8ddf5beffa2e92b8ebfdd016454546252519244
+ Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
+
+2023-02-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add gdbarch_up
+ Add a gdbarch_up unique pointer type, that calls gdbarch_free on
+ deletion. This is used in the ROCm support patch at the end of this
+ series.
+
+ Change-Id: I4b808892d35d69a590ce83180f41afd91705b2c8
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add inferior_pre_detach observable
+ Add an observable notified in target_detach just before calling the
+ detach method on the inferior's target stack. This allows observer to
+ do some work on the inferior while it's still ptrace-attached, in the
+ case of a native Linux inferior. Specifically, the amd-dbgapi target
+ will need it in order to call amd_dbgapi_process_detach before the
+ process gets ptrace-detached.
+
+ Change-Id: I28b6065e251012a4c2db8a600fe13ba31671e3c9
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add type definitions for pid, lwp and tid
+ A following patch will want to declare variables of the same type as
+ some ptid_t components. To make that easy (and avoid harcoding those
+ types everywhere), define some type definitions in the ptid_t struct for
+ each of them. Use them throughout ptid.h.
+
+ I initially used pid_t, lwp_t and tid_t, but there is the risk of some
+ system defining the pid_t type using a macro instead of a typedef, which
+ would break things. So, use the _type suffix instead.
+
+ Change-Id: I820b0bea9dafcb4914f1c9ba4bb96b5c666c8dec
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Pedro Alves <pedro@palves.net>
+
+ gdb: make install_breakpoint return a non-owning reference
+ A following patch will want to install a breakpoint and then keep a
+ non-owning reference to it. Make install_breakpoint return a non-owning
+ reference, to make that easy.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I2e8106a784021ff276ce251e24708cbdccc2d479
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: add supports_arch_info callback to gdbarch_register
+ In the ROCm GDB port, there are some amdgcn architectures known by BFD
+ that we don't actually support in GDB. We don't want
+ gdbarch_printable_names to return these architectures.
+
+ gdbarch_printable_names is used for a few things:
+
+ - completion of the "set architecture" command
+ - the gdb.architecture_names function in Python
+ - foreach-arch selftests
+
+ Add an optional callback to gdbarch_register that is a predicate
+ indicating whether the gdbarch supports the given bfd_arch_info. by
+ default, it is nullptr, meaning that the gdbarch accepts all "mach"s for
+ that architecture known by BFD.
+
+ Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-02-02 Tom de Vries <tdevries@suse.de>
+
+ [gas] Update .loc syntax comment in dwarf2dbg.c
+ I noticed that a comment in gas/dwarf2dbg.c describing .loc syntax was missing
+ the "view VALUE" option.
+
+ Fix this by adding the missing option.
+
+2023-02-02 Enze Li <enze.li@hotmail.com>
+
+ gdb: remove gdb_indent.sh
+ GDB has been converted to a C++ program for many years[1], and the
+ gdb_indent.sh will not be used any more. Therefore, remove the script as
+ obvious.
+
+ [1] https://sourceware.org/gdb/wiki/cxx-conversion
+
+ Approved-By: Simon Marchi <simark@simark.ca>
+
+2023-02-02 Indu Bhagat <indu.bhagat@oracle.com>
+
+ ld/doc: use "stack trace" instead of "unwind" for SFrame
+ SFrame format is meant for generating stack traces only.
+
+ ld/
+ * ld.texi: Replace the use of "unwind" with "stack trace".
+
+2023-02-02 Indu Bhagat <indu.bhagat@oracle.com>
+
+ bfd: use "stack trace" instead of "unwind" for SFrame
+ SFrame format is meant for generating stack traces only.
+
+ bfd/
+ * elf-bfd.h: Replace the use of "unwind" with "stack trace".
+ * elf-sframe.c: Likewise.
+ * elf64-x86-64.c: Likewise.
+ * elfxx-x86.c: Likewise.
+
+ include/
+ * elf/common.h: Likewise.
+
+2023-02-02 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: use "stack trace" instead of "unwind" for SFrame
+ SFrame format is meant for generating stack traces only.
+
+ gas/
+ * as.c: Replace the use of "unwind" with "stack trace".
+ * config/tc-aarch64.c: Likewise.
+ * config/tc-aarch64.h: Likewise.
+ * config/tc-i386.c: Likewise.
+ * config/tc-i386.h: Likewise.
+ * gen-sframe.c: Likewise.
+ * gen-sframe.h: Likewise.
+ * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise.
+ * testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise.
+ * testsuite/gas/cfi-sframe/common-empty-2.s: Likewise.
+ * testsuite/gas/cfi-sframe/common-empty-3.s: Likewise.
+
+2023-02-02 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: use "stack trace" instead of "unwind" for SFrame
+ SFrame format is meant for generating stack traces only.
+
+ include/
+ * sframe.h: Fix comments in the header file.
+
+2023-02-02 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe/doc: use "stack trace" instead of "unwind" for SFrame
+ SFrame format is meant for generating stack traces only.
+
+ libsframe/
+ * doc/sframe-spec.texi: Use "stack trace" instead of "unwind".
+
+2023-02-02 Alan Modra <amodra@gmail.com>
+
+ ld-elf/merge test update
+ The merge test fais on numerous targets because they don't support the
+ necessary pc-relative relocs. This patch removes that part of the
+ merge test, and makes references to the merged strings from .data
+ rather than .text to better support targets that relax text by
+ default.
+
+2023-02-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-02-01 Alan Modra <amodra@gmail.com>
+
+ obj-elf.h BYTES_IN_WORD
+ Don't define this. It is defined just before elf-bfd.h is included,
+ but doesn't have any relevance there. Instead is for aout64.h where
+ the default is 4 anyway.
+
+2023-02-01 Alan Modra <amodra@gmail.com>
+
+ gas obj_end
+ Provide a way for config/obj-* to clean up at end of assembly, and do
+ so for ELF.
+
+ * obj.h (struct format_ops): Add "end".
+ * config/obj-aout.c (aout_format_ops): Init new field.
+ * config/obj-coff.c (coff_format_ops): Likewise.
+ * config/obj-ecoff.c (ecoff_format_ops): Likewise.
+ * config/obj-elf.c (elf_format_ops): Likewise.
+ (elf_begin): Move later in file. Clear some more variables.
+ (comment_section): Make file scope.
+ (free_section_idx): Rewrite.
+ (elf_adjust_symtab): Expand str_htab_create call and use
+ free_section_idx as delete function.
+ (elf_frob_file_after_relocs): Don't clean up groups.indexes here.
+ (elf_end): New function.
+ * config/obj-elf.h (obj_end): Define.
+ * config/obj-multi.h (obj_end): Define.
+ * output-file.c (output_file_close): Call obj_end.
+
+2023-02-01 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap
+ This patch doesn't change gdbserver behaviour, but after later changes are
+ made it avoids a null pointer dereference when HWCAP needs to be obtained
+ for a specific process while current_thread is nullptr.
+
+ Fixing linux_read_auxv, linux_get_hwcap and linux_get_hwcap2 to take a PID
+ parameter seems more correct than setting current_thread in one particular
+ code path.
+
+ Changes are propagated to allow passing the new parameter through the call
+ chain.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-01 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdbserver: Add assert in find_register_by_number
+ It helped me during development, catching bugs closer to when they actually
+ happened.
+
+ Also remove the equivalent gdb_assert in regcache_raw_read_unsigned, since
+ it's checking the same condition a few frames above.
+
+ Suggested-By: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-02-01 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix fetch_src_and_symbols.exp with native-gdbserver board
+ I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp script
+ doesn't work with the native-gdbserver board, I see this error:
+
+ ERROR: tcl error sourcing /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
+ ERROR: gdbserver does not support run without extended-remote
+ while executing
+ "error "gdbserver does not support $command without extended-remote""
+ (procedure "gdb_test_multiple" line 51)
+ invoked from within
+
+ This was introduced with this commit:
+
+ commit 7dd38e31d67c2548b52bea313ab18e40824c05da
+ Date: Fri Jan 6 18:45:27 2023 -0500
+
+ gdb/linespec.c: Fix missing source file during breakpoint re-set
+
+ The problem is that the above commit introduces a direct use of the
+ "run" command, which doesn't work with 'target remote' targets, as
+ exercised by the native-gdbserver board.
+
+ To avoid this, in this commit I switch to using runto_main. However,
+ calling runto_main will, by default, delete all the currently set
+ breakpoints. As the point of the above commit was to check that a
+ breakpoint set before stating an inferior would be correctly re-set,
+ we need to avoid this breakpoint deleting behaviour.
+
+ To do this I make use of with_override, and override the
+ delete_breakpoints proc with a dummy proc which does nothing.
+
+ By reverting the GDB changes in commit 7dd38e31d67c I have confirmed
+ that even after my changes in this commit, the test still fails. But
+ with the fixes in commit 7dd38e31d67c, this test now passed using the
+ unix, native-gdbserver, and native-extended-gdbserver boards.
+
+2023-02-01 Alexandra Hájková <ahajkova@redhat.com>
+
+ gdb: defer warnings when loading separate debug files
+ Currently, when GDB loads debug information from a separate debug
+ file, there are a couple of warnings that could be produced if things
+ go wrong.
+
+ In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
+ warning if the separate debug file doesn't include any actual debug
+ information, and in separate_debug_file_exists (symfile.c) we can warn
+ if the CRC checksum in the separate debug file doesn't match the
+ checksum in the original executable.
+
+ The problem here is that, when looking up debug information, GDB will
+ try several different approaches, lookup by build-id, lookup by
+ debug-link, and then a lookup from debuginfod. GDB can potentially
+ give a warning from an earlier attempt, and then succeed with a later
+ attempt. In the cases I have run into this is primarily a warning
+ about some out of date debug information on my machine, but then GDB
+ finds the correct information using debuginfod. This can be confusing
+ to a user, they will see warnings from GDB when really everything is
+ working just fine.
+
+ For example:
+
+ warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
+ does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
+
+ This diagnostic was printed on Fedora 33 even when the correct
+ debuginfo was downloaded.
+
+ In this patch I propose that we defer any warnings related to looking
+ up debug information from a separate debug file. If any of the
+ approaches are successful then GDB will not print any of the warnings.
+ As far as the user is concerned, everything "just worked". Only if
+ GDB completely fails to find any suitable debug information will the
+ warnings be printed.
+
+ The crc_mismatch test compiles two executables: crc_mismatch and
+ crc_mismatch-2 and then strips them of debuginfo creating separate
+ debug files. The test then replaces crc_mismatch-2.debug with
+ crc_mismatch.debug to trigger "CRC mismatch" warning. A local
+ debuginfod server is setup to supply the correct debug file, now when
+ GDB looks up the debug info no warning is given.
+
+ The build-id-no-debug-warning.exp is similar to the previous test. It
+ triggers the "separate debug info file has no debug info" warning by
+ replacing the build-id based .debug file with the stripped binary and
+ then loading it to GDB. It then also sets up local debuginfod server
+ with the correct debug file to download to make sure no warnings are
+ emitted.
+
+2023-02-01 Nick Clifton <nickc@redhat.com>
+
+ Fix compilation of the assembler with sanitization enabled.
+ * dwarf2dbg.c (emit_inc_line_addr): Use unsigned constants when checking addr_delta.
+
+2023-02-01 Alan Modra <amodra@gmail.com>
+
+ Recursion in as_info_where
+ This function has a gas_assert, ie. possible call to as_abort, which
+ calls as_report_context, which calls as_info_where.
+
+ * messages.c (as_info_where): Don't gas_assert.
+
+2023-02-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf: rename cooked_index_vector to cooked_index
+ See previous patch's commit message for rationale.
+
+ Change-Id: I6b8cdc045dffccc1c01ed690ff258af09f6ff076
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf: rename cooked_index to cooked_index_shard
+ I propose to rename cooked_index_vector and cooked_index such that the
+ "main" object, that is the entry point to the index, is called
+ cooked_index. The fact that the cooked index is implemented as a vector
+ of smaller indexes is an implementation detail.
+
+ This patch renames cooked_index to cooked_index_shard. The following
+ patch renames cooked_index_vector to cooked_index.
+
+ Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-02-01 Tom de Vries <tdevries@suse.de>
+
+ [gas] Emit v2 .debug_line for -gdwarf-2
+ Currently, when using -gdwarf-2, gas emits a v3 .debug_line contribution.
+
+ Fix this by emitting a v2 .debug_line contribution instead.
+
+ gas/ChangeLog:
+
+ 2023-01-31 Tom de Vries <tdevries@suse.de>
+
+ PR 23941
+ * dwarf2dbg.c (DWARF2_LINE_VERSION): Set to 2 for -gdwarf-2.
+ (DWARF2_LINE_OPCODE_BASE): Handle DWARF2_LINE_VERSION == 2.
+ (dwarf2_directive_loc): Bump dwarf_level when encountering
+ v3 .loc options.
+ (out_debug_line): Don't output v3 standard opcodes for v2.
+ * testsuite/gas/i386/debug1.d: Update.
+ * testsuite/gas/i386/dwarf2-line-1.d: Update.
+ * testsuite/gas/i386/dwarf2-line-4.d: Update.
+
+2023-02-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add nullptr check to cooked_index_functions::dump
+ Since commit 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in
+ cooked_index_functions::dump"), we see:
+
+ maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error^M
+ ^M
+ Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 15 minsyms^M
+ ^M
+ Cooked index in use:^M
+ ^M
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb-checked-static-cast.h:58: internal-error: checked_static_cast: Assertion `result != nullptr' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ ----- Backtrace -----^M
+ FAIL: gdb.dwarf2/dw2-error.exp: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error (GDB internal error)
+
+ The problem is that when cooked_index_functions fails to build an index,
+ per_objfile->index_table is nullptr. Therefore, add a nullptr check,
+ like other methods of cooked_index_functions already do.
+
+ Print the "Cooked index in use" message after the nullptr check, such
+ that if the cooked index failed to build, that message is not printed.
+
+ Change-Id: Id67aef592e76c41b1e3bde9838a4e36cef873253
+
+2023-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: allow passing nullptr to checked_static_cast
+ Both static_cast and dynamic_cast handle nullptr (they return nullptr),
+ so I think checked_static_cast should too. This will allow doing a null
+ check after a checked_static_cast:
+
+ cooked_index_vector *table
+ = (gdb::checked_static_cast<cooked_index_vector *>
+ (per_bfd->index_table.get ()));
+ if (table != nullptr)
+ return;
+
+ Change-Id: If5c3134e63696f8e417c87b5f3901240c9f7ea97
+
+2023-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: adjust ensure_gdb_index to cooked_index_functions::dump changes
+ Following 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in
+ cooked_index_functions::dump"), I see some failures like:
+
+ (gdb) mt print objfiles with-mf^M
+ ^M
+ Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/with-mf/with-mf: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 18 minsyms ^M
+ ^M
+ Cooked index in use:^M
+ ^M
+ ...
+ (gdb) FAIL: gdb.base/with-mf.exp: check if index present
+
+ This is because the format of the "Cooked index in use" line changed
+ slightly. Adjust ensure_gdb_index to expect the trailing colon.
+
+ Change-Id: If0a87575c02d8a0bc0d4b8ead540c234c62760f8
+
+2023-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix xfail in gdb.ada/ptype_tagged_param.exp
+ I see:
+
+ ERROR: wrong # args: should be "xfail message"
+ while executing
+ "xfail "no debug info" $gdb_test_name"
+ ("uplevel" body line 3)
+ invoked from within
+ "uplevel {
+ if {!$has_runtime_debug_info} {
+ xfail "no debug info" $gdb_test_name
+ } else {
+ fail $gdb_test_name
+ }
+ }"
+
+ This is because the xfail takes only one argument, fix that.
+
+ Change-Id: I2e304d4fd3aa61067c04b5dac2be2ed34dab3190
+
+2023-01-31 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the binutils sub-directory
+
+2023-01-31 Alan Modra <amodra@gmail.com>
+
+ Re: Another fix for EFI generation with LTO enabled
+ Revert 1c66b8a03989 and instead fix the broken list pointer.
+
+ PR 29998
+ * pe-dll.c (build_filler_bfd): Revert last change.
+ * ldlang.c (lang_process): When rescanning archives for lto,
+ fix file_chain.tail pointer if the insert point happens to be
+ at the end of the list.
+
+2023-01-31 Andrew Burgess <aburgess@redhat.com>
+
+ gas/ppc: Additional tests for DFP instructions
+ I noticed that some of the Power6 DFP instructions were not covered by
+ the assembler tests. I've added a new test file which I believe
+ covers all the DFP Power6 instructions.
+
+ The existing gas/testsuite/gas/ppc/power6.d test is called:
+
+ POWER6 tests (includes DFP and Altivec)
+
+ And does cover some of the DFP instructions. But, given the number of
+ additional instructions I'm adding I opted to add a whole new test
+ file. I've left the original power6.d unchanged, so there is now some
+ overlap, but I don't think that should hurt much.
+
+2023-01-31 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: make C-extension JAL available again for (32-bit) assembly
+ Along with the normal JAL alias, the C-extension one should have been
+ moved as well by 839189bc932e ("RISC-V: re-arrange opcode table for
+ consistent alias handling"), for the assembler to actually be able to
+ use it where/when possible.
+
+ Since neither this nor any other compressed branch insn was being tested
+ so far, take the opportunity and introduce a new testcase covering those.
+
+2023-01-31 Alan Modra <amodra@gmail.com>
+
+ Silence ubsan warning about 1<<31
+ * merge.c (hash_blob): Write 1u << 31.
+
+2023-01-31 Alan Modra <amodra@gmail.com>
+
+ PR 30060, ASAN error in bfd_cache_close
+ After bfd_close nothing should access bfd memory. Now that bfd_close
+ always tidies up even after an error, attempting to tidy the cached
+ bfd list by calling bfd_cache_close is wrong and not needed.
+
+ PR 30060
+ * ar.c (remove_output): Don't call bfd_cache_close.
+ (output_bfd): Delete.
+ * arsup.c (ar_end): Call bfd_close_all_done, not bfd_cache_close.
+
+2023-01-31 Alan Modra <amodra@gmail.com>
+
+ testsuite XPASSes
+ This adjusts the testsuite to get rid of a number of XPASSes that have
+ appeared. Someone might like to look into a better patch for the s390
+ change.
+
+ aarch64-pe XPASS: weak symbols
+ arm-nacl XPASS: rgn-over8
+ mcore-pe XPASS: ld-scripts/provide-8
+ mips64-linux-gnuabi64 XPASS: vers4
+ mips64-linux-gnuabi64 XPASS: vers4b
+ mips-linux-gnu XPASS: vers4
+ mips-linux-gnu XPASS: vers4b
+ s390-linux-gnu XPASS: undefined line
+ sh4-linux-gnu XPASS: --gc-sections with __start_SECTIONNAME
+ sh-coff XPASS: objcopy object (simple copy)
+ sh-coff XPASS: objcopy executable (pr25662)
+
+ binutils/
+ * testsuite/binutils-all/objcopy.exp: Don't xfail "simple
+ copy" and "pr25662" on sh-*-coff. Remove all non-ELF xfails
+ on "ELF unknown section type" test.
+ ld/
+ * testsuite/ld-elfvers/vers.exp (vers4, vers4b): Don't xfail
+ all mips, just xfail mips irix.
+ * testsuite/ld-gc/pr19161.d: Don't xfail sh.
+ * testsuite/ld-scripts/rgn-over8-ok.d: Don't xfail nacl.
+ * testsuite/ld-scripts/weak.exp: Don't xfail aarch64-pe.
+ * testsuite/ld-undefined/undefined.exp: Conditionally xfail
+ "undefined line" depending on gcc version for s390.
+
+2023-01-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-30 Tom Tromey <tom@tromey.com>
+
+ Remove value_next declaration
+ value_next is declared but not defined. It's long obsolete. This
+ patch removes the stray declaration.
+
+2023-01-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix dwarf2/cooked-index.c compilation on 32-bit systems
+ The i386 builder shows:
+
+ ../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’:
+ ../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=]
+ 492 | gdb_printf (" DIE offset: 0x%lx\n",
+ | ~~^
+ | |
+ | long unsigned int
+ | %llx
+ 493 | to_underlying (entry->die_offset));
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ | |
+ | std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int}
+
+ The die_offset's underlying type is uint64, so use PRIx64 in the format
+ string.
+
+ Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323
+
+2023-01-30 Mark Wielaard <mark@klomp.org>
+
+ gdb: Replace memcpy with std::copy to avoid some g++ warnings on sparc
+ For some reason g++ 12.2.1 on sparc produces spurious warnings for
+ stringop-overread and restrict in fbsd-tdep.c for a memcpy call.
+ Use std::copy to avoid the warnings:
+
+ In function ‘void* memcpy(void*, const void*, size_t)’,
+ inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:666:10:
+ /usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified bound 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
+
+ In function ‘void* memcpy(void*, const void*, size_t)’,
+ inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:673:10:
+ /usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744073709551612 bytes at offsets 0 and 0 overlaps 9223372036854775801 bytes at offset -9223372036854775805 [-Werror=restrict]
+
+ gdb/ChangeLog:
+
+ * fbsd-tdep.c (fbsd_make_note_desc): Use std::copy instead
+ of memcpy.
+
+2023-01-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf: dump cooked index contents in cooked_index_functions::dump
+ As I am investigating a crash I see with the cooked index, I thought it
+ would be useful to have a way to dump the index contents. For those not
+ too familiar with it (that includes me), it can help get a feel of what
+ it contains and how it is structured.
+
+ The cooked_index_functions::dump function is called as part of the
+ "maintenance print objfiles" command. I tried to make the output
+ well structured and indented to help readability, as this prints a lot
+ of text.
+
+ The dump function first dumps all cooked index entries, like this:
+
+ [25] ((cooked_index_entry *) 0x621000121220)
+ name: __ioinit
+ canonical: __ioinit
+ DWARF tag: DW_TAG_variable
+ flags: 0x2 [IS_STATIC]
+ DIE offset: 0x21a4
+ parent: ((cooked_index_entry *) 0x6210000f9610) [std]
+
+ Then the information about the main symbol:
+
+ main: ((cooked_index_entry *) 0x621000123b40) [main]
+
+ And finally the address map contents:
+
+ [1] ((addrmap *) 0x6210000f7910)
+
+ [0x0] ((dwarf2_per_cu_data *) 0)
+ [0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00)
+ [0x1cc7] ((dwarf2_per_cu_data *) 0)
+ [0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00)
+ [0x1cdf] ((dwarf2_per_cu_data *) 0)
+ [0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00)
+
+ The display of address maps above could probably be improved, to show it
+ more as ranges, but I think this is a reasonable start.
+
+ Note that this patch depends on Pedro Alves' patch "enum_flags
+ to_string" [1]. If my patch is to be merged before Pedro's series, I
+ will cherry-pick this patch from his series and merge it before mine.
+
+ [1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/
+
+ Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a
+
+2023-01-30 Pedro Alves <pedro@palves.net>
+
+ enum_flags to_string
+ This commit introduces shared infrastructure that can be used to
+ implement enum_flags -> to_string functions. With this, if we want to
+ support converting a given enum_flags specialization to string, we
+ just need to implement a function that provides the enumerator->string
+ mapping, like so:
+
+ enum some_flag
+ {
+ SOME_FLAG1 = 1 << 0,
+ SOME_FLAG2 = 1 << 1,
+ SOME_FLAG3 = 1 << 2,
+ };
+
+ DEF_ENUM_FLAGS_TYPE (some_flag, some_flags);
+
+ static std::string
+ to_string (some_flags flags)
+ {
+ static constexpr some_flags::string_mapping mapping[] = {
+ MAP_ENUM_FLAG (SOME_FLAG1),
+ MAP_ENUM_FLAG (SOME_FLAG2),
+ MAP_ENUM_FLAG (SOME_FLAG3),
+ };
+ return flags.to_string (mapping);
+ }
+
+ .. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like
+ "0x6 [SOME_FLAG2 SOME_FLAG3]".
+
+ If we happen to forget to update the mapping array when we introduce a
+ new enumerator, then the string representation will pretty-print the
+ flags it knows about, and then the leftover flags in hex (one single
+ number). For example, if we had missed mapping SOME_FLAG2 above, we'd
+ end up with:
+
+ to_string(SOME_FLAG2 | SOME_FLAG3) => "0x6 [SOME_FLAG2 0x4]");
+
+ Other than in the unit tests included, no actual usage of the
+ functionality is added in this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I835de43c33d13bc0c95132f42c3f97318b875779
+
+2023-01-30 Tom Tromey <tromey@adacore.com>
+
+ Fix comparator bug in cooked index
+ Simon pointed out that the cooked index template-matching patch
+ introduced a failure in libstdc++ debug mode. In particular, the new
+ code violates the assumption of std::lower_bound and std::upper_bound
+ that the range is sorted with respect to the comparison.
+
+ When I first debugged this, I thought the problem was unfixable as-is
+ and that a second layer of filtering would have to be done. However,
+ on irc, Simon pointed out that it could perhaps be solved if the
+ comparison function were assured that one operand always came from the
+ index, with the other always being the search string.
+
+ This patch implements this idea.
+
+ First, a new mode is introduced: a sorting mode for
+ cooked_index_entry::compare. In this mode, strings are compared
+ case-insensitively, but we're careful to always sort '<' before any
+ other printable character. This way, two names like "func" and
+ "func<param>" will be sorted next to each other -- i.e., "func1" will
+ not be seen between them. This is important when searching.
+
+ Second, the compare function is changed to work in a strcmp-like way.
+ This makes it easier to test and (IMO) understand.
+
+ Third, the compare function is modified so that in non-sorting modes,
+ the index entry is always the first argument. This allows consistency
+ in compares.
+
+ I regression tested this in libstdc++ debug mode on x86-64 Fedora 36.
+ It fixes the crash that Simon saw.
+
+ This is v2. I believe it addresses the review comments, except for
+ the 'enum class' change, as I mentioned in email on the list.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-30 Tom Tromey <tom@tromey.com>
+
+ Clean up lnp_state_machine constructor
+ This changes the lnp_state_machine constructor to initialize members
+ directly; and changes lnp_state_machine itself to initialize members
+ inline when possible.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-01-30 Tom Tromey <tromey@adacore.com>
+
+ Make addrmap const-correct in cooked index
+ After the cooked index is created, the addrmaps should be const.
+
+ Change-Id: I8234520ab346ced40a8dd6e478ba21fc438c2ba2
+
+2023-01-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: provide const-correct versions of addrmap::find and addrmap::foreach
+ Users of addrmap::find and addrmap::foreach that have a const addrmap
+ should ideally receive const pointers to objects, to indicate they
+ should not be modified. However, users that have a non-const addrmap
+ should still receive a non-const pointer.
+
+ To achieve this, without adding more virtual methods, make the existing
+ find and foreach virtual methods private and prefix them with "do_".
+ Add small non-const and const wrappers for find and foreach.
+
+ Obviously, the const can be cast away, but if using static_cast
+ instead of C-style casts, then the compiler won't let you cast
+ the const away. I changed all the callers of addrmap::find and
+ addrmap::foreach I could find to make them use static_cast.
+
+ Change-Id: Ia8e69d022564f80d961413658fe6068edc71a094
+
+2023-01-30 Tom Tromey <tromey@adacore.com>
+
+ Use xfail in ptype_tagged_param.exp
+ Pedro pointed out that ptype_tagged_param.exp used a kfail, but an
+ xfail would be more appropriate as the problem appears to be in gcc,
+ not gdb.
+
+2023-01-30 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb: Remove workaround for the vCont packet
+ The workaround for the vCont packet is no longer required due to the
+ former commit "gdb: Make global feature array a per-remote target array".
+ The vCont packet is now checked once when the connection is started and
+ the supported vCont actions are set to the target's remote state
+ attribute.
+
+2023-01-30 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb: Add per-remote target variables for memory read and write config
+ This patch adds per-remote target variables for the configuration of
+ memory read- and write packet size. It is a further change to commit
+ "gdb: Make global feature array a per-remote target array" to apply the
+ fixme notes described in commit 5b6d1e4 "Multi-target support".
+
+ The former global variables for that configuration are still available
+ to allow the command line configuration for all future remote
+ connections. Similar to the command line configuration of the per-
+ remote target feature array, the commands
+
+ - set remotewritesize (deprecated)
+ - set remote memory-read-packet-size
+ - set remote memory-write-packet-size
+
+ will configure the current target (if available). If no target is
+ available, the default configuration for future remote connections is
+ adapted. The show command will display the current remote target's
+ packet size configuration. If no remote target is selected, the default
+ configuration for future connections will be shown.
+
+ It is required to adapt the test gdb.base/remote.exp which is failing
+ for --target_board=native-extended-gdbserver. With that board GDB
+ connects to gdbserver at gdb start time. Due to this patch two loggings
+ "The target may not be able to.." are shown if the command 'set remote
+ memory-write-packet-size fixed' is executed while a target is connected
+ for the current inferior. To fix this, the clean_restart command is
+ moved to a later time point of the test. It is sufficient to be
+ connected to the server when "runto_main" is executed. Now the
+ connection time is similar to a testrun with
+ --target_board=native-gdbserver.
+
+ To allow the user to distinguish between the packet-size configuration
+ for future remote connections and for the currently selected target, the
+ commands' loggings are adapted.
+
+2023-01-30 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb: Make global feature array a per-remote target array
+ This patch applies the appropriate FIXME notes described in commit 5b6d1e4
+ "Multi-target support".
+
+ "You'll notice that remote.c includes some FIXME notes. These refer to
+ the fact that the global arrays that hold data for the remote packets
+ supported are still globals. For example, if we connect to two
+ different servers/stubs, then each might support different remote
+ protocol features. They might even be different architectures, like
+ e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a
+ host/controller scenario as a single program. That isn't going to
+ work correctly today, because of said globals. I'm leaving fixing
+ that for another pass, since it does not appear to be trivial, and I'd
+ rather land the base work first. It's already useful to be able to
+ debug multiple instances of the same server (e.g., a distributed
+ cluster, where you have full control over the servers installed), so I
+ think as is it's already reasonable incremental progress."
+
+ Using this patch it is possible to configure per-remote targets'
+ feature packets.
+
+ Given the following setup for two gdbservers:
+
+ ~~~~
+ gdbserver --multi :1234
+ gdbserver --disable-packet=vCont --multi :2345
+ ~~~~
+
+ Before this patch configuring of range-stepping was not possible for one
+ of two connected remote targets with different support for the vCont
+ packet. As one of the targets supports vCont, it should be possible to
+ configure "set range-stepping". However, the output of GDB looks like:
+
+ (gdb) target extended-remote :1234
+ Remote debugging using :1234
+ (gdb) add-inferior -no-connection
+ [New inferior 2]
+ Added inferior 2
+ (gdb) inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) target extended-remote :2345
+ Remote debugging using :2345
+ (gdb) set range-stepping on
+ warning: Range stepping is not supported by the current target
+ (gdb) inferior 1
+ [Switching to inferior 1 [<null>] (<noexec>)]
+ (gdb) set range-stepping on
+ warning: Range stepping is not supported by the current target
+ ~~~~
+
+ Two warnings are shown. The warning for inferior 1 should not appear
+ as it is connected to a target supporting the vCont package.
+
+ ~~~~
+ (gdb) target extended-remote :1234
+ Remote debugging using :1234
+ (gdb) add-inferior -no-connection
+ [New inferior 2]
+ Added inferior 2
+ (gdb) inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) target extended-remote :2345
+ Remote debugging using :2345
+ (gdb) set range-stepping on
+ warning: Range stepping is not supported by the current target
+ (gdb) inferior 1
+ [Switching to inferior 1 [<null>] (<noexec>)]
+ (gdb) set range-stepping on
+ (gdb)
+ ~~~~
+
+ Now only one warning is shown for inferior 2, which is connected to
+ a target not supporting vCont.
+
+ The per-remote target feature array is realized by a new class
+ remote_features, which stores the per-remote target array and
+ provides functions to determine supported features of the target.
+ A remote_target object now has a new member of that class.
+
+ Each time a new remote_target object is initialized, a new per-remote
+ target array is constructed based on the global remote_protocol_packets
+ array. The global array is initialized in the function _initialize_remote
+ and can be configured using the command line. Before this patch the
+ command line configuration affected current targets and future remote
+ targets (due to the global feature array used by all remote
+ targets). This behavior is different and the configuration applies as
+ follows:
+
+ - If a target is connected, the command line configuration affects the
+ current connection. All other existing remote targets are not
+ affected.
+
+ - If not connected, the command line configuration affects future
+ connections.
+
+ The show command displays the current remote target's configuration. If no
+ remote target is selected the default configuration for future
+ connections is shown.
+
+ If we have for instance the following setup with inferior 2 being
+ selected:
+ ~~~~
+ (gdb) info inferiors
+ Num Description Connection Executable
+ 1 <null> 1 (extended-remote :1234)
+ * 2 <null> 2 (extended-remote :2345)
+ ~~~~
+
+ Before this patch, if we run 'set remote multiprocess-feature-packet', the
+ following configuration was set:
+ The feature array of all remote targets (in this setup the two connected
+ targets) and all future remote connections are affected.
+
+ After this patch, it will be configured as follows:
+ The feature array of target with port :2345 which is currently selected
+ will be configured. All other existing remote targets are not affected.
+ The show command 'show remote multiprocess-feature-packet' will display
+ the configuration of target with port :2345.
+
+ Due to this configuration change, it is required to adapt the test
+ "gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the
+ multiprocess-feature-packet before the connections are created.
+
+ To inform the gdb user about the new behaviour of the 'show remote
+ PACKET-NAME' commands and the new configuration impact for remote
+ targets using the 'set remote PACKET-NAME' commands the commands'
+ outputs are adapted. Due to this change it is required to adapt each
+ test using the set/show remote 'PACKET-NAME' commands.
+
+2023-01-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-27 Tom Tromey <tromey@adacore.com>
+
+ More const-correctness in cooked indexer
+ I noticed that iterating over the index yields non-const
+ cooked_index_entry objects. However, after finalization, they should
+ not be modified. This patch enforces this by adding const where
+ needed.
+
+ v2 makes the find, all_entries, and wait methods const as well.
+
+2023-01-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp.tcl
+ Recent commit 1d98e564c97 ("[gdb/testsuite] Add
+ gdb.base/unwind-on-each-insn-{amd64,i386}.exp") broke commit eb015bf86b6
+ ("[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp"),
+ in the sense that gdb.base/unwind-on-each-insn.exp no longer uses
+ -fno-asynchronous-unwind-tables, due to trying to concatenate two lists using:
+ ...
+ lappend srcfile2_flags $nodebug_flags
+ ...
+ which should instead be:
+ ...
+ lappend srcfile2_flags {*}$nodebug_flags
+ ...
+
+ Fix this by simplifying gdb.base/unwind-on-each-insn.exp.tcl, completely
+ leaving the responsibility to set srcfile_flags and srcfile2_flags to each
+ includer.
+
+ Tested on x86_64-linux.
+
+2023-01-27 Tom Tromey <tromey@adacore.com>
+
+ Invert test in gdb.ada/ptype_tagged_param.exp
+ Simon pointed out that the kfail check in
+ gdb.ada/ptype_tagged_param.exp is inverted. See:
+
+ https://sourceware.org/pipermail/gdb-patches/2023-January/196296.html
+
+ This patch fixes the problem.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: more debug output
+ Add some additional debug output that I've found really useful while
+ working on the previous set of patches.
+
+ Unless tui debug is turned on, then there should be no user visible
+ changes with this commit.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: avoid extra refresh_window on vertical scroll
+ While working on the previous couple of patches I noticed that when I
+ scroll the src and asm windows vertically, I get two refresh_window
+ calls.
+
+ The two calls can be traced back to
+ tui_source_window_base::update_source_window_as_is, in here we call
+ show_source_content, which calls refresh_window, and then
+ update_exec_info, which also calls refresh_window.
+
+ In this commit I propose making the refresh_window call in
+ update_exec_info optional. In update_source_window_as_is I'll then
+ call update_exec_info before calling show_source_content, and pass a
+ flag to update_exec_info to defer the refresh.
+
+ There are places where update_exec_info is used without any subsequent
+ refresh_window call (e.g. when a breakpoint is updated), so
+ update_exec_info does not to call refresh_window in some cases, which
+ is why I'm using a flag to control the refresh.
+
+ With this changes I'm now only seeing a single refresh_window call for
+ each vertical scroll.
+
+ There should be no user visible changes after this commit.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: avoid extra refresh_window on horizontal scroll
+ While working on the previous patches I noticed that in some cases I
+ was seeing two calls to tui_source_window_base::refresh_window when
+ scrolling the window horizontally.
+
+ The two calls would trigger in for the tui-disasm-long-lines.exp test
+ when the pad needed to be refilled. The two called both come from
+ tui_source_window_base::show_source_content. The first call is nested
+ within check_and_display_highlight_if_needed, while the second call is
+ done directly at the end of show_source_content.
+
+ The check_and_display_highlight_if_needed is being used to draw the
+ window box to the window, this is needed here because
+ show_source_content is what gets called when the window needs
+ updating, e.g. after a resize. We could potentially do the boxing in
+ refresh_window, but then we'd be doing it each time we scroll, even
+ though the box doesn't need changing in this case.
+
+ However, we can move the check_and_display_highlight_if_needed to be
+ the last thing done in show_source_content, this means that we can
+ rely on the refresh_window call within it to be our single refresh
+ call.
+
+ There should be no user visible changes after this commit.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: rewrite of tui_source_window_base to handle very long lines
+ This commit addresses an issue that is exposed by the test script
+ gdb.tui/tui-disasm-long-lines.exp, that is, tui_source_window_base
+ does not handle very long lines.
+
+ The problem can be traced back to the newpad call in
+ tui_source_window_base::show_source_content, this is where we allocate
+ a backing pad to hold the window content.
+
+ Unfortunately, there appears to be a limit to the size of pad that can
+ be allocated, and the gdb.tui/tui-disasm-long-lines.exp test goes
+ beyond this limit. As a consequence the newpad call fails and returns
+ nullptr.
+
+ It just so happens that the reset of the tui_source_window_base code
+ can handle the pad being nullptr (this happens anyway when the window
+ is first created, so we already depend on nullptr handling), so all
+ that happens is the source window displays no content.
+
+ ... well, sort of ... something weird does happen in the command
+ window, we seem to see a whole bunch of blank lines. I've not
+ bothered to track down exactly what's happening there, but it's some
+ consequence of GDB attempting to write content to a WINDOW* that is
+ nullptr.
+
+ Before explaining my solution, I'll outline how things currently work:
+
+ Consider we have the following window content to display:
+
+ aaaaaaaaaa
+ bbbbbbbbbbbbbbbbbbbb
+ ccccccccccccccc
+
+ the longest line here is 20 characters. If our display window is 10
+ characters wide, then we will create a pad that is 20 characters wide,
+ and then copy the lines of content into the pad:
+
+ .--------------------.
+ |aaaaaaaaaa |
+ |bbbbbbbbbbbbbbbbbbbb|
+ |ccccccccccccccc |
+ .--------------------.
+
+ Now we will copy a 10 character wide view into this pad to the
+ display, our display will then see:
+
+ .----------.
+ |aaaaaaaaaa|
+ |bbbbbbbbbb|
+ |cccccccccc|
+ .----------.
+
+ As the user scrolls left and right we adjust m_horizontal_offset and
+ use this to select which part of the pad is copied onto the display.
+
+ The benefit of this is that we only need to copy the content to the
+ pad once, which includes processing the ansi escape sequences, and
+ then the user can scroll left and right as much as they want
+ relatively cheaply.
+
+ The problem then, is that if the longest content line is very long,
+ then we try to allocate a very large pad, which can fail.
+
+ What I propose is that we allow both the pad and the display view to
+ scroll. Once we allow this, then it becomes possible to allocate a
+ pad that is smaller than the longest display line. We then copy part
+ of the content into the pad. As the user scrolls the view left and
+ right GDB will continue to copy content from the pad just as it does
+ right now. But, when the user scrolls to the edge of the pad, GDB
+ will copy a new block of content into the pad, and then update the
+ view as normal. This all works fine so long as the maximum pad size
+ is larger than the current window size - which seems a reasonable
+ restriction, if ncurses can't support a pad of a given size it seems
+ likely it will not support a display window of that size either.
+
+ If we return to our example above, but this time we assume that the
+ maximum pad size is 15 characters, then initially the pad would be
+ loaded like this:
+
+ .---------------.
+ |aaaaaaaaaa |
+ |bbbbbbbbbbbbbbb|
+ |ccccccccccccccc|
+ .---------------.
+
+ Notice that the last 5 characters from the 'b' line are no longer
+ included in the pad. There is still enough content though to fill the
+ 10 character wide display, just as we did before.
+
+ The pad contents remain unchanged until the user scrolls the display
+ right to this point:
+
+ .----------.
+ |aaaaa |
+ |bbbbbbbbbb|
+ |cccccccccc|
+ .----------.
+
+ Now, when the user scrolls right once more GDB spots that the user has
+ reached the end of the pad, and the pad contents are reloaded, like
+ this:
+
+ .---------------.
+ |aaaaa |
+ |bbbbbbbbbbbbbbb|
+ |cccccccccc |
+ .---------------.
+
+ The display can now be updated from the pad again just like normal.
+
+ With this change in place the gdb.tui/tui-disasm-long-lines.exp test
+ now correctly loads the assembler code, and we can scroll around as
+ expected.
+
+ Most of the changes are pretty mundane, just updating to match the
+ above. One interesting change though is the new member function
+ tui_source_window_base::puts_to_pad_with_skip. This replaces direct
+ calls to tui_puts when copying content to the pad.
+
+ The content strings contain ansi escape sequences. When these strings
+ are written to the pad these escape sequences are translated into
+ ncurses attribute setting calls.
+
+ Now however, we sometimes only write a partial string to the pad,
+ skipping some of the leading content. Imagine then that we have a
+ content line like this:
+
+ "\033[31mABCDEFGHIJKLM\033[0m"
+
+ Now the escape sequences in this content mean that the actual
+ content (the 'ABCDEFGHIJKLM') will have a red foreground color.
+
+ If we want to copy this to the pad, but skip the first 3 characters,
+ then what we expect is to have the pad contain 'DEFGHIJKLM', but this
+ text should still have a red foreground color.
+
+ It is this problem that puts_to_pad_with_skip solves. This function
+ skips some number of printable characters, but processes all the
+ escape sequences. This means that when we do start printing the
+ actual content the content will have the expected attributes.
+ /
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: make m_horizontal_offset private
+ I noticed that tui_source_window_base::m_horizontal_offset was
+ protected, but could be made private, so lets do that.
+
+ This makes more sense in the context of a later commit where I plan to
+ add another member variable that is similar to m_horizontal_offset.
+ The new member variable could also be private.
+
+ So I had to choose, place the new member variable next to
+ m_horizontal_offset making it protected, but grouping similar
+ variables together, or make m_horizontal_offset private, and then add
+ the new variable as private too.
+
+ I chose to make m_horizontal_offset private, which is this commit.
+
+ There should be no user visible changes after this commit.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: disable tui mode when an assert triggers
+ When an assert triggers in tui mode the output is not great, the
+ internal backtrace that is generated is printed directly to the file
+ descriptor for gdb_stderr, and, as a result, does not currently format
+ itself correctly - the output uses only '\n' at the end of each line,
+ and so, when the terminal is in raw mode, the cursor does not return
+ to the start of each line after the '\n'.
+
+ This is mostly fixable, we could update bt-utils.c to use '\r\n'
+ instead of just '\n', and this would fix most of the problems. The
+ one we can't easily fix is if/when GDB is built to use execinfo
+ instead of libbacktrace, in this case we use backtrace_symbols_fd to
+ print the symbols, and this function only uses '\n' as the line
+ terminator. Fixing this would require switching to backtrace_symbols,
+ but that API uses malloc, which is something we're trying to
+ avoid (this code is called when GDB hits an error, so ideally we don't
+ want to rely on malloc).
+
+ However, the execinfo code is only used when libbacktrace is not
+ available (or the user specifically disables libbacktrace) so maybe we
+ can ignore that problem...
+
+ ... but there is another problem. When the backtrace is printed in
+ raw mode, it is possible that the backtrace fills the screen. With
+ the terminal in raw mode we don't have the ability to scroll back,
+ which means we loose some of the backtrace, which isn't ideal.
+
+ In this commit I propose that we should disable tui mode whenever we
+ handle a fatal signal, or when we hit the internal error code
+ path (e.g. when an assert triggers). With this done then we don't
+ need to update the bt-utils.c code, and the execinfo version of the
+ code (using backtrace_symbols_fd) works just fine. We also get the
+ ability to scroll back to view the error message and all of the
+ backtrace, assuming the users terminal supports scrolling back.
+
+ The only downside I see with this change is if the tui_disable call
+ itself causes an error for some reason, or, if we handle a single at a
+ time when it is not safe to call tui_disable, in these cases the extra
+ tui_disable call might cause GDB to loose the original error.
+
+ However, I think (just from personal experience) that the above two
+ issues are pretty rare and the benefits from this change far out
+ weighs the possible drawbacks.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: improve errors from tui focus command
+ This commit improves (I think) the errors from the tui focus command.
+ There are a number of errors that can be triggered by the focus
+ command, they include:
+
+ (1) Window name "NAME" is ambiguous
+
+ (2) Unrecognized window name "NAME"
+
+ (3) Window "NAME" cannot be focused
+
+ Error (1) is triggered when the user gives a partial window name, and
+ the name matches multiple windows in the current layout.
+
+ It is worth noting that the ambiguity must be within the current
+ layout; if the partial name matches one window in the current layout,
+ and one or more windows not in the current layout, then this is not
+ ambiguous, and focus will shift to the matching window in the current
+ layout.
+
+ This error was not previous being tested, but in this commit I make
+ use of the Python API to trigger and test this error.
+
+ Error (3) is simple enough, and was already being tested. This is
+ triggered by something like 'focus status'. The named window needs to
+ be present in the current layout, and non-focusable in order to
+ trigger the error.
+
+ Error (2) is what I'd like to improve in this commit. This error
+ triggers if the name the user gives doesn't match any window in the
+ current layout. Even if GDB does know about the window, but the
+ window isn't in the current layout, then GDB will say it doesn't
+ recognize the window name.
+
+ In this commit I propose to to split this error into three different
+ errors. These will be:
+
+ (a) Unrecognized window name "NAME"
+
+ (b) No windows matching "NAME" in the current layout
+
+ (c) Window "NAME" is not in the current layout
+
+ Error (a) is the same as before, but will now only trigger if GDB
+ doesn't know about window NAME at all. If the window is known, but
+ not in the current layout then one of the other errors will trigger.
+
+ Error (b) will trigger if NAME is ambiguous for multiple windows that
+ are not in the current layout. If NAME identifies a single window in
+ the current layout then that window will continue to be selected, just
+ as it currently is. Only in the case where NAME doesn't identify a
+ window in the current layout do we then check all the other known
+ windows, if NAME matches multiple of these, then (b) is triggered.
+
+ Finally, error (c) is used when NAME uniquely identifies a single
+ window that is not in the current layout.
+
+ The hope with these new errors is that the user will have a better
+ understanding of what went wrong. Instead of GDB claiming to not know
+ about a window, the mention of the current layout will hint to the
+ user that they should first switch layouts.
+
+ There are tests included for all the new errors.
+
+2023-01-27 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix line feed scrolling in tuiterm.exp
+ In a following commit I managed to trigger the line feed scrolling
+ case in tuiterm.exp. This case is currently unhandled, and this
+ commit fills in this missing functionality.
+
+ The implementation is pretty simple, just scroll all the content up
+ one line at a time until the cursor is back on the screen (a single
+ line of scroll is all that should be needed).
+
+ This change is untested in this commit, but is required by the next
+ commit.
+
+2023-01-27 Nick Clifton <nickc@redhat.com>
+
+ Another fix for EFI generation with LTO enabled.
+ PR 29998 * pe-dll.c (build_filler_bfd): Initialise the next field of the filler input statement, so that it does not break the file chain.
+
+2023-01-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: move reg_operands adjustment
+ Ideally we'd do away with this somewhat questionable adjustment (leaving
+ i.types[] untouched). That's non-trivial though as it looks, so only
+ - move the logic into process_operands(), putting it closer to related
+ logic and eliminating a conditional for operand-less insns,
+ - make it consistent (i.e. also affect %xmm0), eliminating an ugly
+ special case later in the function.
+
+ x86: drop dead SSE2AVX-related code
+ All (there are just two) SSE2AVX templates with %xmm0 as first operand
+ also specify VEX3SOURCES. Hence there's no need for an "else" to the
+ respective if(), and the if() itself can become an assertion.
+
+ x86: use ModR/M for FPU insns with operands
+ This is the correct way of expressing things; encoding the ModR/M byte
+ directly in base_opcode has always been bogus.
+
+ x86/Intel: improve special casing of certain insns
+ Now that we have identifiers for the mnemonic strings we can avoid
+ opcode based comparisons, for (in many cases) being more expensive and
+ (in a few cases) being a little fragile and not self-documenting.
+
+2023-01-27 Jan Beulich <jbeulich@suse.com>
+
+ opcodes: suppress internationalization on build helper tools
+ While one of the two actually having been instrumented (i386-gen.c) now
+ has that instrumentation dropped, there's still no point in honoring
+ such instrumentation in general (i.e. now for ia64-gen.c only), as that
+ only leads to a waste of resources.
+
+ With CFILES then being merely an alias of LIBOPCODES_CFILES, drop the
+ former variable altogether.
+
+2023-01-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: remove internationalization from i386-gen.c
+ This is a build time helper utility, which doesn't require translation.
+
+2023-01-27 Alan Modra <amodra@gmail.com>
+
+ Call bfd_close_all_done in ld_cleanup
+ This is similar to "Call bfd_close_all_done in output_file_close",
+ but with some code tidying in the pe/pep write_build_id functions.
+ write_build_id is passed the output bfd as its parameter, so there is
+ no need to go looking for the output bfd via link_info (and doing so
+ will no longer work since I clear link_info.output_bfd before calling
+ bfd_close).
+
+ * emultempl/pe.em (write_build_id): Rename t to td. Formatting.
+ Don't access pe_data(link_info.output_bfd), use td instead.
+ (setup_build_id): Rename t to td. Formatting.
+ * emultempl/pep.em: As for pe.em.
+ * ldmain.c (ld_cleanup): Call bfd_close_all_done on linker bfds.
+ (main): Clear link_info.output_bfd when closing.
+
+2023-01-27 Alan Modra <amodra@gmail.com>
+
+ Perform cleanup in bfd_close after errors
+ It seems reasonable to continue after errors in bfd_close_all_done,
+ particularly since bfd_close_all_done is typically called on an output
+ file after we've hit some sort of error elsewhere. The iovec test is
+ necessary if bfd_close_all_done is to work on odd bfd's opened by
+ bfd_create.
+
+ * opncls.c (bfd_close): Call bfd_close_all_done after errors
+ from _bfd_write_contents.
+ (bfd_close_all_done): Call _bfd_delete_bfd after errors.
+ Don't call iovec->bclose when iovec is NULL.
+
+2023-01-27 Alan Modra <amodra@gmail.com>
+
+ Call bfd_close_all_done in output_file_close
+ bfd_cache_close_all is good for closing file descriptors, but doesn't
+ do the cleanup of bfd memory as in bfd_close_all_done.
+
+ PR 13056
+ * output-file.c (output_file_close): Call bfd_close_all_done,
+ not bfd_cache_close_all.
+
+2023-01-27 Alan Modra <amodra@gmail.com>
+
+ gas macro memory leaks
+ This tidies memory allocated for entries in macro_hash. Freeing the
+ macro name requires a little restructuring of the define_macro
+ interface due to the name being used in the error message, and exposed
+ the fact that the name and other fields were not initialised by the
+ iq2000 backend.
+
+ There is also a fix for
+ .macro .macro
+ .endm
+ .macro .macro
+ .endm
+ which prior to this patch reported
+ mac.s:1: Warning: attempt to redefine pseudo-op `.macro' ignored
+ mac.s:3: Error: Macro `.macro' was already defined
+ rather than reporting the attempt to redefine twice.
+
+ * macro.c (macro_del_f): New function.
+ (macro_init): Use it when creating macro_hash.
+ (free_macro): Free macro name too.
+ (define_macro): Return the macro_entry, remove idx, file, line and
+ namep params. Call as_where. Report errors here. Delete macro
+ from macro_hash on attempt to redefined pseudo-op.
+ (delete_macro): Don't call free_macro.
+ * macro.h (define_macro): Update prototype.
+ * read.c (s_macro): Adjust to suit.
+ * config/tc-iq2000.c (iq2000_add_macro): Init all fields of
+ macro_entry.
+
+2023-01-27 Mark Harmstone <mark@harmstone.com>
+
+ gas/testsuite: Add -gcodeview test for aarch64-w64-mingw32
+ This is a copy of the x86 gas -gcodeview test, with changes made for the
+ differing instruction lengths between x86 and aarch64.
+
+ gas: Add CodeView constant for aarch64
+ Adds the correct constant to the S_COMPILE3 CodeView record when
+ assembling aarch64-w64-mingw32 with the -gcodeview flag.
+
+2023-01-27 Tom Tromey <tom@tromey.com>
+
+ Use clean_restart in gdb.base
+ Change gdb.base to use clean_restart more consistently.
+
+ Use clean_restart in gdb.python
+ Change gdb.python to use clean_restart more consistently.
+
+ Use clean_restart in gdb.cp
+ Change gdb.cp to use clean_restart more consistently.
+
+ Use clean_restart in gdb.disasm
+ Change gdb.disasm to use clean_restart more consistently.
+
+ Use clean_restart in gdb.perf
+ Change gdb.perf to use clean_restart more consistently.
+
+ Use clean_restart in gdb.go
+ Change gdb.go to use clean_restart more consistently.
+
+ Use clean_restart in gdb.stabs
+ Change gdb.stabs to use clean_restart more consistently.
+
+ Use clean_restart in gdb.fortran
+ Change gdb.fortran to use clean_restart more consistently.
+
+ Use clean_restart in gdb.ada
+ Change gdb.ada to use clean_restart more consistently.
+
+ Use clean_restart in gdb.dwarf2
+ Change gdb.dwarf2 to use clean_restart more consistently.
+
+ Use clean_restart in gdb.reverse
+ Change gdb.reverse to use clean_restart more consistently.
+
+ Use clean_restart in gdb.arch
+ Change gdb.arch to use clean_restart more consistently.
+
+ Use clean_restart in gdb.guile
+ Change gdb.guile to use clean_restart more consistently.
+
+ Use clean_restart in gdb.threads
+ Change gdb.threads to use clean_restart more consistently.
+
+ Use clean_restart in gdb.objc
+ Change gdb.objc to use clean_restart more consistently.
+
+ Use clean_restart in gdb.trace
+ Change gdb.trace to use clean_restart more consistently.
+
+ Use clean_restart in gdb.opencl
+ Change gdb.opencl to use clean_restart more consistently.
+
+ Use clean_restart in gdb.linespec
+ Change gdb.linespec to use clean_restart more consistently.
+
+ Use clean_restart in gdb.pascal
+ Change gdb.pascal to use clean_restart more consistently.
+
+ Use mi_clean_restart more
+ This changes a number of MI tests to use mi_clean_restart rather than
+ separate calls. This reduces the number of lines, which is nice, and
+ also provides a nicer model to copy for future tests.
+
+ Start gdb after building executable in mi-basics.exp
+ A lot of the MI tests start gdb and only then build the executable.
+ This just seemed weird to me, so I've fixed this up. In this patch,
+ no other cleanups are done, the startup is just moved to a more
+ logical (to me) spot.
+
+ Remove unnecessary call to standard_testfile
+ This test does not build a program and does not need to call
+ standard_testfile.
+
+ Minor "require" fixups
+ I found a couple of spots that could use "require", and one spot where
+ hoisting the "require" closer to the top of the file made it more
+ clear.
+
+2023-01-27 Tom Tromey <tom@tromey.com>
+
+ Remove some dead code in gdb.fortran/info-types.exp
+ An early "return" in this test case prevents a test from running.
+ This seems to have been intentional and has been in place since:
+
+ commit d57cbee932f86df06251498daa93154046dc77c0
+ Author: Andrew Burgess <andrew.burgess@embecosm.com>
+ Date: Tue Dec 3 13:18:43 2019 +0000
+
+ gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+
+
+ This patch removes the dead code.
+
+2023-01-27 Tom Tromey <tom@tromey.com>
+
+ Eliminate spurious returns from the test suite
+ A number of tests end with "return". However, this is unnecessary.
+ This patch removes all of these.
+
+ Use clean_restart in gdb.dlang
+ Change gdb.dlang to use clean_restart more consistently.
+
+ Use ordinary calling convention for clean_restart
+ clean_restart accepts a single optional argument. Rather than using
+ {args} and handling the argument by hand, change it to use Tcl's own
+ argument-checking.
+
+2023-01-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-26 Alan Modra <amodra@gmail.com>
+
+ Free gas/dwarf2dbg.c dirs
+ Entries are allocated with xmemdup0.
+
+ * dwarf2dbg.c (dwarf2_cleanup): Free dirs entries.
+
+2023-01-26 Alan Modra <amodra@gmail.com>
+
+ Sanity check dwarf5 form of .file
+ There's a comment a few lines earlier saying that demand_copy_C_string
+ has already reported an error if it returns NULL. Given the proximity
+ I decided not to duplicate the comment.
+
+ * dwarf2dbg.c (dwarf2_directive_filename): Check return of
+ demand_copy_C_string for file.
+
+2023-01-26 Alan Modra <amodra@gmail.com>
+
+ resolve gas shift expressions with large exponents to zero
+ * expr.c (resolve_expression <O_left_shift, O_right_shift>): Resolve
+ shifts exceeding bits in a valueT to zero.
+
+ segv in coff_aarch64_addr32nb_reloc
+ * coff-aarch64.c (coff_aarch64_addr32nb_reloc): When output_bfd
+ is NULL (which it is for objdump -W) get the output bfd via the
+ input section.
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: initialize "correct" variable in gdb.cp/cpexprs.exp.tcl
+ Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB
+ crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to
+ read the string, at gdb.cp/cpexprs.exp.tcl:725. The "correct" variable
+ doesn't get set, and I then see this TCL error:
+
+ ERROR: can't read "correct": no such variable
+
+ Avoid the TCL error by initializing the "correct" variable to a dummy
+ value.
+
+ Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE
+ Prior to this patch, I get:
+
+ >>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}}
+ Content-Length: 147
+
+ {"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success
+ FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output
+
+ The problem is that the PC to disassemble is taken from the breakpoint
+ insertion response, which happens before running. With a PIE
+ executable, that PC is unrelocated, but the disassembly request happens
+ after relocation.
+
+ I chose to fix this by watching for a breakpoint changed event giving
+ the new breakpoint address, and recording the address from there. I
+ think this is an interesting way to fix it, because it adds a bit of
+ test coverage, I don't think these events are checked right now.
+
+ Other ways to fix it would be:
+
+ - Get the address by doing a breakpoint insertion after the program is
+ started, or some other way.
+ - Do the disassembly by symbol instead of by address.
+ - Do the disassembly before running the program.
+
+ Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: make dap_wait_for_event_and_check return preceding messages
+ In the following patch, I change gdb.dap/basic-dap.exp such that after
+ waiting for some event, it checks if it received another event
+ meanwhile. To help with this, make dap_wait_for_event_and_check and
+ _dap_dap_wait_for_event return a list with everything received before
+ the event of interest. This is similar to what
+ dap_check_request_and_response returns.
+
+ Change-Id: I85c8980203a2dec833937e7552c2196bc137935d
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: rename dap_read_event to dap_wait_for_event_and_check
+ I think that name describes a bit better what the proc does, it is
+ similar to "wait_for" in tuiterm.exp.
+
+ Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: pass around dicts instead of TON objects
+ The DAP helper functions generally return TON objects. However, callers
+ almost all immediately use ton::2dict to convert them to dicts, to
+ access their contents. This commits makes things a bit simpler for them
+ by having function return dicts directly instead.
+
+ The downside is that the TON objects contain type information. For
+ instance, a "2" in a TCL dict could have been the integer 2 or the
+ string "2" in JSON. By converting to TCL dicts, we lose that
+ information. If some tests specifically want to check the types of some
+ fields, I think we can add intermediary functions that return TON
+ objects, without having to complicate other callers who don't care.
+
+ Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: remove catch from dap_read_event
+ This catch didn't cause me any trouble, but for the same reason as the
+ preceding patch, I think it's a bit better to just let any exception
+ propagate, to make for easier debugging.
+
+ Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: make dap_request_and_response not catch / issue test result
+ Following some of my changes, dap_request_and_response was failing and I
+ didn't know why. I think it's better to make it not catch any
+ exception, and just make it do a simple "send request, read response".
+ If an exception is thrown while sending a request or reading a response,
+ things are going really badly, it's not like we'll want to recover from
+ that and continue the test.
+
+ Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: write requests to gdb.log
+ This helps following what happens when reading gdb.log. The downside is
+ that it becomes harder to tell what text is from GDB and what text is
+ going to GDB, but I think that seeing responses without seeing requests
+ is even more confusing. At least, the lines are prefix with >>>, so
+ when you see this, you know that until the end of the line, it's
+ something that was sent to GDB, and not GDB output.
+
+ Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: prefix some procs with _
+ Prefix some procs that are only used internally with an underscore, to
+ make it clear they are internal. If they need to be used by some test
+ later, we can always un-prefix them.
+
+ Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d
+
+2023-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dap: use gdb_assert in gdb.dap/basic-dap.exp
+ Use gdb_assert instead of manual pass/fail.
+
+ Change-Id: I71fbc4e37a0a1ef4783056c7424e932651fa397f
+
+2023-01-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR30043 libgprofng.so.* are installed to a wrong location
+ gprofng/ChangeLog
+ 2023-01-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/30043
+ PR gprofng/28972
+ * src/Makefile.am: Use lib_LTLIBRARIES instead of pkglib_LTLIBRARIES.
+ * src/Makefile.in: Rebuild.
+
+2023-01-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.exp
+ The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in
+ the epilogue was inaccurate.
+
+ In order to work around this in gdb, epilogue unwinders were added with a
+ higher priority than the dwarf unwinders in the amd64 and i386 targets:
+ - amd64_epilogue_frame_unwind, and
+ - i386_epilogue_frame_unwind.
+
+ Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0.
+
+ However, the epilogue unwinders prevented gdb from taking advantage of the
+ fixed epilogue unwind info, so the scope of the epilogue unwinders was
+ limited, bailing out for gcc >= 4.5.0.
+
+ There was no regression test added for this preference scheme, so if we now
+ declare epilogue unwind info from all gcc versions as trusted, no test will
+ start failing.
+
+ Fix this by adding an amd64 and i386 regression test for this.
+
+ I have no gcc 4.4.x lying around, so I fabricated the assembly files by:
+ - commenting out some .cfi directives to break the epilogue unwind info, and
+ - hand-editing the producer info to 4.4.7 to activate the fix.
+
+ Tested on x86_64-linux, target boards unix/{-m64,-m32}.
+
+2023-01-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add and use is_x86_64_m64_target
+ Add new proc is_x86_64_m64_target and use it where appropriate.
+
+ Tested on x86_64-linux.
+
+2023-01-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-25 Mark Harmstone <mark@harmstone.com>
+
+ ld/testsuite: Add missing targets to PDB tests
+
+2023-01-25 Mark Harmstone <mark@harmstone.com>
+
+ ld: Add pdb support to aarch64-w64-mingw32
+ This extends PDB support to the aarch64 PE targets.
+
+ The changes to the test files are just to make it so they can be assembled as
+ either x86, x86_64, or aarch64, mainly by changing the comment style.
+ The only actual code change here is in adding the architecture constants
+ to pdb.c.
+
+2023-01-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Use new dwarf2 function cache
+ This patch resolves the performance issue reported in pr/29738 by
+ caching the values for the stack pointers for the inner frame. By
+ doing so, the impact can be reduced to checking the state and
+ returning the appropriate value.
+
+2023-01-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb: dwarf2 generic implementation for caching function data
+ When there is no dwarf2 data for a register, a function can be called
+ to provide the value of this register. In some situations, it might
+ not be trivial to determine the value to return and it would cause a
+ performance bottleneck to do the computation each time.
+
+ This patch allows the called function to have a "cache" object that it
+ can use to store some metadata between calls to reduce the performance
+ impact of the complex logic.
+
+ The cache object is unique for each function and frame, so if there are
+ more than one function pointer stored in the dwarf2_frame_cache->reg
+ array, then the appropriate pointer will be supplied (the type is not
+ known by the dwarf2 implementation).
+
+ dwarf2_frame_get_fn_data can be used to retrieve the function unique
+ cache object.
+ dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the
+ function unique cache object.
+
+2023-01-25 Tom Tromey <tromey@adacore.com>
+
+ Clean up unusual code in mi-cmd-stack.c
+ I noticed some unusual code in mi-cmd-stack.c. This code is a switch,
+ where one of the cases appears in the middle of another block. It
+ seemed cleaner to me to have the earlier case just conditionally fall
+ through.
+
+2023-01-25 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Pass -Wl,--no-as-needed to compiler as needed
+ Pass -Wl,--no-as-needed to linker tests to fix
+
+ FAIL: Run pr19031
+ FAIL: Run got1
+ FAIL: Undefined weak symbol (-fPIE -no-pie)
+ FAIL: Undefined weak symbol (-fPIE -pie)
+
+ when --as-needed is passed to linker by compiler.
+
+ PR ld/30050
+ * testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
+ as needed.
+
+2023-01-25 Tom Tromey <tom@tromey.com>
+
+ Move target check into allow_altivec_tests
+ Pedro pointed out that only PPC can possibly have altivec, so we can
+ move the target check into allow_altivec_tests.
+
+ Use require with is_remote
+ This changes some tests to use require with 'is_remote', rather than
+ an explicit test. This adds uniformity helps clean up more spots
+ where a test might exit early without any notification.
+
+2023-01-25 Tom Tromey <tom@tromey.com>
+
+ Add unsupported calls where needed
+ A number of tests will exit early without saying why. This patch adds
+ "unsupported" at spots like this that I could readily find.
+
+ There are definitely more of these; for example dw2-ranges.exp fails
+ silently because a compilation fails. I didn't attempt to address
+ these as that is a much larger task.
+
+2023-01-25 Tom Tromey <tom@tromey.com>
+
+ Introduce and use is_any_target
+ A few tests work on two different targets that can't be detected with
+ a single call to istarget -- that proc only accepts globs, not regular
+ expressions.
+
+ This patch introduces a new is_any_target proc and then converts these
+ tests to use it in a 'require'.
+
+2023-01-25 Tom Tromey <tom@tromey.com>
+
+ Use require with istarget
+ This changes many tests to use require when checking 'istarget'. A
+ few of these conversions were already done in earlier patches.
+
+ No change was needed to 'require' to make this work, due to the way it
+ is written. I think the result looks pretty clear, and it has the
+ bonus of helping to ensure that the reason that a test is skipped is
+ always logged.
+
+2023-01-25 Tom Tromey <tom@tromey.com>
+
+ Rename skip_vsx_tests to allow form
+ This renames skip_vsx_tests to allow_vsx_tests and updates it users to
+ use require.
+
+ Rename skip_power_isa_3_1_tests to allow form
+ This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and
+ updates its users to use require.
+
+ Rename skip_float_test to allow form
+ This renames skip_float_test to allow_float_test and updates its users
+ to use require.
+
+ Convert skip_altivec_tests to allow form
+ This renames skip_altivec_tests to allow_altivec_tests and updates its
+ users to use require.
+
+2023-01-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/unwind-on-each-insn.exp for -m32
+ With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I
+ now get:
+ ...
+ # of expected passes 25
+ ...
+ instead of:
+ ...
+ # of expected passes 133
+ ...
+ as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug
+ srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match
+ "rip = " and info frame printing "eip = " instead.
+
+ Fix this by dropping "rip" from the regexp.
+
+ Tested on x86_64-linux, target boards unix/{-m64,-m32}.
+
+2023-01-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.exp
+ Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
+ $srcfile2 without.
+
+ Occasionally, I try both files with debug info:
+ ...
+ - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ + $srcfile $debug_flags $srcfile2 $debug_flags]]} {
+ ...
+
+ This shortcuts the test due to no longer recognizing that stepi still lands
+ in foo.
+
+ Fix this by determining whether still in foo by checking the info frame output.
+
+ Tested on x86_64-linux.
+
+2023-01-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow nodebug srcfile in gdb.base/unwind-on-each-insn.exp
+ Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
+ $srcfile2 without.
+
+ Occasionally, I try both files with debug info:
+ ...
+ - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ + $srcfile $debug_flags $srcfile2 $debug_flags]]} {
+ ...
+ and both files without:
+ ...
+ - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ + $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} {
+ ...
+
+ In the latter case, I run into:
+ ...
+ FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2
+ FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up
+ ...
+ due to a mismatch between the regexp and the different output due to using
+ nodebug.
+
+ Fix this by making the regexp less strict.
+
+ Tested on x86_64-linux.
+
+2023-01-25 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, i386: Update stale comment in i386-tdep.h.
+ The comment seems no longer valid, the functions technically check for
+ non-pseudo registers, like zmmh. Which is a valid use case.
+
+2023-01-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Analyze non-leaf fn in gdb.base/unwind-on-each-insn.exp
+ In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
+ to check various invariants at each insn, in particular hoping to excercise
+ insns that modify stack and frame pointers.
+
+ Function foo is a leaf function, so add a non-leaf function bar, and step
+ through it as well (using nexti instead of stepi).
+
+ With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049:
+ ...
+ FAIL: bar: instruction 5: bt 2
+ FAIL: bar: instruction 5: up
+ FAIL: bar: instruction 5: [string equal $fid $::main_fid]
+ FAIL: bar: instruction 6: bt 2
+ FAIL: bar: instruction 6: up
+ FAIL: bar: instruction 6: [string equal $fid $::main_fid]
+ ...
+
+ Tested on:
+ - x86_64-linux (-m64 and -m32)
+ - s390x-linux (-m64 and -m31)
+ - aarch64-linux
+ - powerpc64le-linux
+
+2023-01-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp
+ In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
+ to check various invariants at each insn, in particular hoping to excercise
+ insns that modify stack and frame pointers.
+
+ For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
+ ...
+ 4004bc: 55 push %rbp
+ 4004bd: 48 89 e5 mov %rsp,%rbp
+ 4004c0: 90 nop
+ 4004c1: 5d pop %rbp
+ 4004c2: c3 ret
+ ...
+ Both stack pointer (%rsp) and frame pointer (%rbp) are modified.
+
+ Also for s390x-linux (and similar for -m31):
+ ...
+ 0000000001000668 <foo>:
+ 1000668: e3 b0 f0 58 00 24 stg %r11,88(%r15)
+ 100066e: b9 04 00 bf lgr %r11,%r15
+ 1000672: e3 b0 b0 58 00 04 lg %r11,88(%r11)
+ 1000678: 07 fe br %r14
+ ...
+ Frame pointer (%r11) is modified.
+
+ Likewise for powerpc64le-linux:
+ ...
+ 00000000100006c8 <foo>:
+ 100006c8: f8 ff e1 fb std r31,-8(r1)
+ 100006cc: d1 ff 21 f8 stdu r1,-48(r1)
+ 100006d0: 78 0b 3f 7c mr r31,r1
+ 100006d4: 00 00 00 60 nop
+ 100006d8: 30 00 3f 38 addi r1,r31,48
+ 100006dc: f8 ff e1 eb ld r31,-8(r1)
+ 100006e0: 20 00 80 4e blr
+ ...
+ Both stack pointer (r1) and frame pointer (r31) are modified.
+
+ But for aarch64-linux, we have:
+ ...
+ 00000000004005fc <foo>:
+ 4005fc: d503201f nop
+ 400600: d65f03c0 ret
+ ...
+ There's no insn that modifies stack or frame pointer.
+
+ Fix this by making foo more complex, adding an (unused) argument:
+ ...
+ 0000000000400604 <foo>:
+ 400604: d10043ff sub sp, sp, #0x10
+ 400608: f90007e0 str x0, [sp, #8]
+ 40060c: d503201f nop
+ 400610: 910043ff add sp, sp, #0x10
+ 400614: d65f03c0 ret
+ ...
+ such that the stack pointer (sp) is modified.
+
+ [ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
+ -mno-omit-leaf-frame-pointer we have instead:
+ ...
+ 0000000000400604 <foo>:
+ 400604: a9be7bfd stp x29, x30, [sp, #-32]!
+ 400608: 910003fd mov x29, sp
+ 40060c: f9000fa0 str x0, [x29, #24]
+ 400610: d503201f nop
+ 400614: a8c27bfd ldp x29, x30, [sp], #32
+ 400618: d65f03c0 ret
+ ...
+ such that also the frame pointer (x29) is modified. ]
+
+ Having made foo more complex, we now run into the following fail on
+ x86_64/-m32:
+ ...
+ FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp
+ ....
+
+ The problem is that the stack pointer has changed inbetween the sampling of
+ main_sp and *foo, in particular by the push insn:
+ ...
+ 804841a: 68 c0 84 04 08 push $0x80484c0
+ 804841f: e8 10 00 00 00 call 8048434 <foo>
+ ...
+
+ Fix this by updating main_sp.
+
+ On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
+ ...
+ FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
+ FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid]
+ ...
+ but I saw the same failure before this commit with gcc 4.8.5.
+
+ Tested on:
+ - x86_64-linux (-m64 and -m32)
+ - s390x-linux (-m64 and -m31)
+ - powerpc64le-linux
+ - aarch64-linux
+
+ Also I've checked that the test-case still functions as regression test for PR
+ record/16678 on x86_64.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: make use of a scoped_restore
+ Make use of a scoped_restore object in tui_mld_read_key instead of
+ doing a manual save/restore.
+
+ I don't think the existing code can throw an exception, so this is
+ just a cleanup rather than a bug fix.
+
+ There should be no user visible changes after this commit.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: better filtering of tab completion results for focus command
+ While working on the previous couple of commits, I noticed that the
+ 'focus' command would happily suggest 'status' as a possible focus
+ completion, even though the 'status' window is non-focusable, and,
+ after the previous couple of commits, trying to focus the status
+ window will result in an error.
+
+ This commit improves the tab-completion results for the focus command
+ so that the status window is not included.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: convert if/error to an assert
+ While working on the previous commit, I realised that there was an
+ error in tui_set_focus_command that could never be triggered.
+
+ Since the big tui rewrite (adding dynamic layouts) it is no longer
+ true that there is a tui_win_info object for every window at all
+ times. We now only create a tui_win_info object for a particular
+ window, when the window is part of the current layout. As a result,
+ if we have a tui_win_info pointer, then the window must be visible
+ inside tui_set_focus_command (this function calls tui_enable as its
+ first action, which makes the current layout visible).
+
+ The gdb.tui/tui-focus.exp test script exercises this area of code, and
+ doesn't trigger the assert, nor do any of our other existing tui
+ tests.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite/tui: more testing of the 'focus' command
+ I noticed that we didn't have many tests of the tui 'focus' command,
+ so I started adding some. This exposed a bug in GDB; we are able to
+ focus windows that should not be focusable, e.g. the 'status' window.
+
+ This is harmless until we then do 'focus next' or 'focus prev', along
+ this code path we assert that the currently focused window is
+ focusable, which obviously, is not always true, so GDB fails with an
+ assertion error.
+
+ The fix is simple; add a check to the tui_set_focus_command function
+ to ensure that the selected window is focusable. If it is not then an
+ error is thrown. The new tests I've added cover this case.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: update gdb.tui/tui-nl-filtered-output.exp
+ Following on from the previous commit, in this commit I am updating
+ the test script gdb.tui/tui-nl-filtered-output.exp to take account of
+ the changes in commit:
+
+ commit 9162a27c5f5828240b53379d735679e2a69a9f41
+ Date: Tue Nov 13 11:59:03 2018 -0700
+
+ Change gdb test suite's TERM setting
+
+ In the above commit the TERM environment variable was changed to be
+ 'dumb' by default, which means that tests, that previously activated
+ tui mode, no longer do unless TERM is set to 'ansi'.
+
+ As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the
+ test stopped working. As the expect patterns in this script were
+ pretty generic no tests actually started failing, and we never
+ noticed.
+
+ In this commit I update the test script to correctly activate our
+ terminal emulator, the test continues to pass after this update, but
+ now we are testing in tui mode.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp
+ Following on from the previous commit, in this commit I am updating
+ the test script gdb.tui/tui-disasm-long-lines.exp to take account of
+ the changes in commit:
+
+ commit 9162a27c5f5828240b53379d735679e2a69a9f41
+ Date: Tue Nov 13 11:59:03 2018 -0700
+
+ Change gdb test suite's TERM setting
+
+ In the above commit the TERM environment variable was changed to be
+ 'dumb' by default, which means that tests, that previously activated
+ tui mode, no longer do unless TERM is set to 'ansi'.
+
+ As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the
+ test stopped working. As the expect patterns in this script were
+ pretty generic no tests actually started failing, and we never
+ noticed.
+
+ In this commit I update the script to use Term::clean_restart, which
+ correctly sets TERM to 'ansi'. I've also added a check that the asm
+ box does appear on the screen, which should indicate that tui mode has
+ correctly activated.
+
+ However, I also notice that GDB doesn't appear to fully work
+ correctly. The test should display the disassembly for the test
+ program, but it doesn't.
+
+ The test is trying to disassemble some code that (deliberately) uses a
+ very long symbol name, this eventually results in GDB entering
+ tui_source_window_base::show_source_content and trying to allocate an
+ ncurses pad in order to hold the current page of disassembler output.
+
+ Unfortunately, due to the very long line, the call to newpad fails,
+ meaning that tui_source_window_base::m_pad is nullptr. Luckily non of
+ the following calls appear to crash when passed a nullptr, however,
+ all the output that is written to the pad is lost, which is why we
+ don't see any assembly code written to the screen.
+
+ As the test history indicates that the script was originally checking
+ for a crash in GDB when the long identifier was encountered, I think
+ there is value in just leaving the test as it is for now, I have a fix
+ for the issue of the newpad call failing, which I'll post in a follow
+ up commit later.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: extend gdb.tui/tui-layout.exp test script
+ In passing I noticed that the gdb.tui/tui-layout.exp test script was a
+ little strange, it tests the layout command multiple times, but never
+ sets up our ANSI terminal emulator, so every layout command fails with
+ a message about the terminal lacking the required abilities.
+
+ It turns out that this was caused by this commit:
+
+ commit 9162a27c5f5828240b53379d735679e2a69a9f41
+ Date: Tue Nov 13 11:59:03 2018 -0700
+
+ Change gdb test suite's TERM setting
+
+ This was when we changed the testsuite to set the TERM environment
+ variable to "dumb" by default.
+
+ After this, any tui test that didn't set the terminal mode back to
+ 'ansi' would fail to activate tui mode.
+
+ For the tui-layout.exp test it just so happens that the test patterns
+ are generic enough that the test continued to pass, even after this
+ change.
+
+ In this commit I have updated the test so we now check the layout
+ command both with a 'dumb' terminal and with the 'ansi' terminal.
+ When testing with the 'ansi' terminal, I have some limited validation
+ that GDB correctly entered tui mode.
+
+ I figured that it is probably worth having at least one test in the
+ test suite that deliberately tries to enter tui mode in a dumb
+ terminal, it would be sad if we one day managed to break GDB such that
+ this caused a crash, and never noticed.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: rename test source file to match test script
+ The previous commit touched the source file for the test script
+ gdb.cp/cpcompletion.exp. This source file is called pr9594.cc. The
+ source file is only used by the one test script.
+
+ This commit renames the source file to cpcompletion.cc to match the
+ test script, this is more inline with how we name source files these
+ days.
+
+2023-01-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: use test_gdb_complete_unique more in C++ tests
+ Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of
+ gdb_test with test_gdb_complete_unique, this will extend the
+ completion testing to check tab-completion as well as completion using
+ the 'complete' command in some additional cases.
+
+2023-01-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-24 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR29521 [docs] man pages are not in the release tarball
+ gprofng/ChangeLog
+ 2023-01-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29521
+ * configure.ac: Check if $MAKEINFO and $HELP2MAN are missing.
+ * Makefile.am: Build doc if $MAKEINFO exists.
+ * doc/gprofng.texi: Update documentation for gprofng.
+ * doc/Makefile.am: Build gprofng.1.
+ * src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am.
+ * configure: Rebuild.
+ * Makefile.in: Rebuild.
+ * doc/Makefile.in: Rebuild.
+ * src/Makefile.in: Rebuild.
+
+2023-01-24 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe/doc: fix some warnings
+ 'make pdf' in libsframe shows some warnings, some of which (especially
+ the Overfull warnings) are causing undesirable effects on the rendered
+ output. Few examples of the warnings:
+
+ Underfull \hbox (badness 10000) in paragraph at lines 406--407
+ @texttt pauth_
+
+ Underfull \hbox (badness 10000) in paragraph at lines 407--410
+ @textrm Specify which key is used for signing the return
+
+ ...
+
+ Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413
+ @texttt fdetype[]|
+
+ ...
+
+ Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447
+ @textrm SFRAME[]FDE[]TYPE[]PCMASK|
+
+ ...
+
+ This patch adjusts column widths of the affected cells to fix a subset
+ of these warnings. For the rest of the warnings, use explicit newline
+ command to fix them.
+
+ libsframe/
+ * doc/sframe-spec.texi: Fix various underfull and overfull
+ warnings.
+
+2023-01-24 Nick Clifton <nickc@redhat.com>
+
+ Fix seg-fault when generating an empty DLL with LTO enabled.
+ ld PR 29998
+ * pe-dll.c (generate_reloc): Handle sections
+ with no assigned output section.
+ Terminate early of there are no relocs to put
+ in the .reloc section.
+ (pe_exe_fill_sections): Do not emit an empty
+ .reloc section.
+
+ bfd * cofflink.c (_bfd_coff_generic_relocate_section):
+ Add an assertion that the output section is set
+ for defined, global symbols.
+
+2023-01-24 Enze Li <enze.li@hotmail.com>
+
+ gdb: some int to bool conversion
+ When building GDB with clang 16, I got this,
+
+ CXX maint.o
+ maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ m_space_enabled = 1;
+ ^ ~
+ maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ m_time_enabled = 1;
+ ^ ~
+ maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
+ m_symtab_enabled = 1;
+ ^ ~
+ 3 errors generated.
+
+ Work around this by using bool bitfields instead.
+
+ Tested by rebuilding on x86_64-linux with clang 16 and gcc 12.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-01-24 Mark Harmstone <mark@harmstone.com>
+
+ ld: Avoid magic numbers for subsystems in pe.em and pep.em
+
+2023-01-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-23 Mark Harmstone <mark@harmstone.com>
+
+ ld: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI
+ This fixes the test failures introduced by 87a5cf5c, by changing the
+ default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to
+ 2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other
+ PE targets.
+
+ As far as I can tell there's no working modern Windows CE toolchain
+ knocking about anyway, so this change shouldn't inconvenience anyone.
+
+2023-01-23 Mark Harmstone <mark@harmstone.com>
+
+ Add support for secidx relocations to aarch64-w64-mingw32
+ This patch adds support for the .secidx directive and its corresponding
+ relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE
+ integer which gets filled in with the 1-based index of the output
+ section that a symbol ends up in.
+
+ This is needed for PDBs, which represent addresses as a .secrel32,
+ .secidx pair.
+
+ The test is substantially the same as for amd64, but with changes made
+ for padding and alignment.
+
+2023-01-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep, aarch64] Fix frame address of last insn
+ Consider the test-case test.c, compiled without debug info:
+ ...
+ void
+ foo (const char *s)
+ {
+ }
+
+ int
+ main (void)
+ {
+ foo ("foo");
+ return 0;
+ }
+ ...
+
+ Disassembly of foo:
+ ...
+ 0000000000400564 <foo>:
+ 400564: d10043ff sub sp, sp, #0x10
+ 400568: f90007e0 str x0, [sp, #8]
+ 40056c: d503201f nop
+ 400570: 910043ff add sp, sp, #0x10
+ 400574: d65f03c0 ret
+ ...
+
+ Now, let's do "info frame" at each insn in foo, as well as printing $sp
+ and $x29 (and strip the output of info frame to the first line, for brevity):
+ ...
+ $ gdb -q a.out
+ Reading symbols from a.out...
+ (gdb) b *foo
+ Breakpoint 1 at 0x400564
+ (gdb) r
+ Starting program: a.out
+
+ Breakpoint 1, 0x0000000000400564 in foo ()
+ (gdb) display /x $sp
+ 1: /x $sp = 0xfffffffff3a0
+ (gdb) display /x $x29
+ 2: /x $x29 = 0xfffffffff3a0
+ (gdb) info frame
+ Stack level 0, frame at 0xfffffffff3a0:
+ (gdb) si
+ 0x0000000000400568 in foo ()
+ 1: /x $sp = 0xfffffffff390
+ 2: /x $x29 = 0xfffffffff3a0
+ (gdb) info frame
+ Stack level 0, frame at 0xfffffffff3a0:
+ (gdb) si
+ 0x000000000040056c in foo ()
+ 1: /x $sp = 0xfffffffff390
+ 2: /x $x29 = 0xfffffffff3a0
+ (gdb) info frame
+ Stack level 0, frame at 0xfffffffff3a0:
+ (gdb) si
+ 0x0000000000400570 in foo ()
+ 1: /x $sp = 0xfffffffff390
+ 2: /x $x29 = 0xfffffffff3a0
+ (gdb) info frame
+ Stack level 0, frame at 0xfffffffff3a0:
+ (gdb) si
+ 0x0000000000400574 in foo ()
+ 1: /x $sp = 0xfffffffff3a0
+ 2: /x $x29 = 0xfffffffff3a0
+ (gdb) info frame
+ Stack level 0, frame at 0xfffffffff3b0:
+ pc = 0x400574 in foo; saved pc = 0x40058c
+ (gdb) si
+ 0x000000000040058c in main ()
+ 1: /x $sp = 0xfffffffff3a0
+ 2: /x $x29 = 0xfffffffff3a0
+ ...
+
+ The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
+ lists 0xfffffffff3b0.
+
+ The frame address is calculated here in aarch64_make_prologue_cache_1:
+ ...
+ unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
+ if (unwound_fp == 0)
+ return;
+
+ cache->prev_sp = unwound_fp + cache->framesize;
+ ...
+
+ For insns after the prologue, we have cache->framereg == sp and
+ cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
+ answer once sp has been restored to entry value by the before-last insn.
+
+ Fix this by detecting the situation that the sp has been restored.
+
+ This fixes PRs tdep/30010 and tdep/30011.
+
+ This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
+ gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.
+
+ Tested on aarch64-linux.
+ PR tdep/30010
+ PR tdep/30011
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011
+
+2023-01-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp
+ One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
+ architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
+ compiled with nodebug, to prevent the dwarf unwinders from taking effect.
+
+ For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
+ default, generating an .eh_frame section contribution which might enable the
+ dwarf unwinders and bypass the architecture-specific unwinders.
+
+ Currently, that happens to be not the case due to the current implementation
+ of epilogue_unwind_valid, which assumes that in absence of debug info proving
+ that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.
+
+ That may change though, see PR30028, in which case
+ gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
+ 49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").
+
+ Fix this by making sure that we don't use .eh_frame info regardless of
+ epilogue_unwind_valid, simply by not generating it using
+ -fno-asynchronous-unwind-tables.
+
+ Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
+ gcc 7.5.0 and clang 13.0.1.
+
+2023-01-23 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the binutils sub-directory
+
+2023-01-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp
+ In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
+ disassembled insn in function foo.
+
+ This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
+ fix for gdb.base/unwind-on-each-insn.exp").
+
+ The use of the last disassembled insn in the test-case is to stop stepping in
+ foo once reaching it.
+
+ However, the intent is to stop stepping just before returning to main.
+
+ There is no guarantee that the last disassembled insn:
+ - is actually executed
+ - is executed just before returning to main
+ - is executed only once.
+
+ Fix this by simplying the test-case to continue stepping till stepping out of
+ foo.
+
+ Tested on x86_64-linux.
+
+2023-01-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix untested in gdb.base/frame-view.exp
+ When running test-case gdb.base/frame-view.exp, I see:
+ ...
+ gdb compile failed, ld: frame-view0.o: in function `main':
+ frame-view.c:73: undefined reference to `pthread_create'
+ ld: frame-view.c:76: undefined reference to `pthread_join'
+ collect2: error: ld returned 1 exit status
+ UNTESTED: gdb.base/frame-view.exp: failed to prepare
+ ...
+
+ Fix this by adding pthreads to the compilation flags.
+
+ Tested on x86_64-linux.
+
+2023-01-23 Vladislav Khmelevsky <och95@yandex.ru>
+
+ Fix objdump --reloc for specific symbol
+ If objdump is used with both --disassemble=symbol and --reloc options
+ skip relocations that have addresses before the symbol, so that they
+ are not displayed.
+
+2023-01-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-22 Tom Tromey <tom@tromey.com>
+
+ Remove path name from test
+ The test suite reports several path names in tests. I couldn't find
+ most of these, and I suspect they are false reports, but I did manage
+ to locate one. This one is probably harmless, as I think the path
+ does not vary; but it's also easy to fix and suppress one warning.
+
+ Minor cleanup in gdb.btrace/enable.exp
+ I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
+ left over from an earlier change. This patch moves the "!" inside the
+ braces, where it belongs.
+
+ Minor fixup in allow_aarch64_sve_tests
+ An earlier patch failed to update a string in allow_aarch64_sve_tests.
+
+2023-01-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make frame_info_ptr auto-reinflatable
+ This is the second step of making frame_info_ptr automatic, reinflate on
+ demand whenever trying to obtain the wrapper frame_info pointer, either
+ through the get method or operator->. Make the reinflate method
+ private, it is used as a convenience method in those two.
+
+ Add an "is_null" method, because it is often needed to know whether the
+ frame_info_ptr wraps an frame_info or is empty.
+
+ Make m_ptr mutable, so that it's possible to reinflate const
+ frame_info_ptr objects. Whether m_ptr is nullptr or not does not change
+ the logical state of the object, because we re-create it on demand. I
+ believe this is the right use case for mutable.
+
+ Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make frame_info_ptr grab frame level and id on construction
+ This is the first step of making frame_info_ptr automatic. Remove the
+ frame_info_ptr::prepare_reinflate method, move that code to the
+ constructor.
+
+ Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make user-created frames reinflatable
+ This patch teaches frame_info_ptr to reinflate user-created frames
+ (frames created through create_new_frame, with the "select-frame view"
+ command).
+
+ Before this patch, frame_info_ptr doesn't support reinflating
+ user-created frames, because it currently reinflates by getting the
+ current target frame (for frame 0) or frame_find_by_id (for other
+ frames). To reinflate a user-created frame, we need to call
+ create_new_frame, to make it lookup an existing user-created frame, or
+ otherwise create one.
+
+ So, in prepare_reinflate, get the frame id even if the frame has level
+ 0, if it is user-created. In reinflate, if the saved frame id is user
+ create it, call create_new_frame.
+
+ In order to test this, I initially enhanced the gdb.base/frame-view.exp
+ test added by the previous patch by setting a pretty-printer for the
+ type of the function parameters, in which we do an inferior call. This
+ causes print_frame_args to not reinflate its frame (which is a
+ user-created one) properly. On one machine (my Arch Linux one), it
+ properly catches the bug, as the frame is not correctly restored after
+ printing the first parameter, so it messes up the second parameter:
+
+ frame
+ #0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
+ 40 return z1.m + z2.n;
+ (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
+ frame
+ #0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
+ 40 return z1.m + z2.n;
+ (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again
+
+ However, on another machine (my Ubuntu 22.04 one), it just passes fine,
+ without the appropriate fix. I then thought about writing a selftest
+ for that, it's more reliable. I left the gdb.base/frame-view.exp pretty
+ printer test there, it's already written, and we never know, it might
+ catch some unrelated issue some day.
+
+ Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make it possible to restore selected user-created frames
+ I would like to improve frame_info_ptr to automatically grab the
+ information needed to reinflate a frame, and automatically reinflate it
+ as needed. One thing that is in the way is the fact that some frames
+ can be created out of thin air by the create_new_frame function. These
+ frames are not the fruit of unwinding from the target's current frame.
+ These frames are created by the "select-frame view" command.
+
+ These frames are not correctly handled by the frame save/restore
+ functions, save_selected_frame, restore_selected_frame and
+ lookup_selected_frame. This can be observed here, using the test
+ included in this patch:
+
+ $ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view
+ Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view...
+ (gdb) break thread_func
+ Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42.
+ (gdb) run
+ Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view
+
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+ [New Thread 0x7ffff7cc46c0 (LWP 4171134)]
+ [Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)]
+
+ Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
+ 42 foo (11);
+ (gdb) info frame
+ Stack level 0, frame at 0x7ffff7cc3ee0:
+ rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd
+ called by frame at 0x7ffff7cc3f80
+ source language c.
+ Arglist at 0x7ffff7cc3ed0, args: p=0x0
+ Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0
+ Saved registers:
+ rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8
+ (gdb) thread 1
+ [Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))]
+ #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
+
+ Here, we create a custom frame for thread 1 (using the stack from thread
+ 2, for convenience):
+
+ (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
+
+ The first calls to "frame" looks good:
+
+ (gdb) frame
+ #0 thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
+ 42 foo (11);
+
+ But not the second one:
+
+ (gdb) frame
+ #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
+
+ This second "frame" command shows the current target frame instead of
+ the user-created frame.
+
+ It's not totally clear how the "select-frame view" feature is expected
+ to behave, especially since it's not tested. I heard accounts that it
+ used to be possible to select a frame like this and do "up" and "down"
+ to navigate the backtrace starting from that frame. The fact that
+ create_new_frame calls frame_unwind_find_by_frame to install the right
+ unwinder suggest that it used to be possible. But that doesn't work
+ today:
+
+ (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
+ (gdb) up
+ Initial frame selected; you cannot go up.
+ (gdb) down
+ Bottom (innermost) frame selected; you cannot go down.
+
+ and "backtrace" always shows the actual thread's backtrace, it ignores
+ the user-created frame:
+
+ (gdb) bt
+ #0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
+ #1 0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6
+ #2 0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56
+
+ I don't want to address all the `select-frame view` issues , but I think
+ we can agree that the "frame" command changing the selected frame, as
+ shown above, is a bug. I would expect that command to show the
+ currently selected frame and not change it.
+
+ This happens because of the scoped_restore_selected_frame object in
+ print_frame_args. The frame information is saved in the constructor
+ (the backtrace below), and restored in the destructor.
+
+ #0 save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682
+ #1 0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324
+ #2 0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755
+ #3 0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401
+ #4 0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126
+ #5 0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368
+ #6 0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346
+ #7 0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993
+ #8 0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871
+ #9 0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976
+
+ Since the user-created frame has level 0 (identified by the saved level
+ -1), lookup_selected_frame just reselects the target's current frame,
+ and the user-created frame is lost.
+
+ My goal here is to fix this particular problem.
+
+ Currently, select_frame does not set selected_frame_id and
+ selected_frame_level for frames with level 0. It leaves them at
+ null_frame_id / -1, indicating to restore_selected_frame to use the
+ target's current frame. User-created frames also have level 0, so add a
+ special case them such that select_frame saves their selected id and
+ level.
+
+ save_selected_frame does not need any change.
+
+ Change the assertion in restore_selected_frame that checks `frame_level
+ != 0` to account for the fact that we can restore user-created frames,
+ which have level 0.
+
+ Finally, change lookup_selected_frame to make it able to re-create
+ user-created frame_info objects from selected_frame_level and
+ selected_frame_id.
+
+ Add a minimal test case for the case described above, that is the
+ "select-frame view" command followed by the "frame" command twice. In
+ order to have a known stack frame to switch to, the test spawns a second
+ thread, and tells the first thread to use the other thread's top frame.
+
+ Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add create_new_frame(frame_id) overload
+ The subsequent patches will need to call create_new_frame with an
+ existing frame_id representing a user created frame. They could call
+ the existing create_new_frame, passing both addresses, but it seems
+ nicer to have a version of the function that takes a frame_id directly.
+
+ Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add user-created frames to stash
+ A subsequent patch makes it possible for frame_info_ptr to reinflate
+ user-created frames. If two frame_info_ptr objects wrapping the same
+ user-created frame_info need to do reinflation, we want them to end up
+ pointing to the same frame_info instance, and not create two separate
+ frame_infos. Otherwise, GDB gets confused down the line, as the state
+ kept in one frame_info object starts differing from the other
+ frame_info.
+
+ Achieve this by making create_new_frame place the user-created frames in
+ the frame stash. This way, when the second frame_info_ptr does
+ reinflation, it will find the existing frame_info object, created by the
+ other frame_info_ptr, in the frame stash.
+
+ To make the frame stash differentiate between regular and user-created
+ frame infos which would otherwise be equal, change frame_addr_hash and
+ frame_id::operator== to account for frame_id::user_created_p.
+
+ I made create_new_frame look up existing frames in the stash, and only
+ create one if it doesn't find one. The goal is to avoid the
+ "select-frame view"/"info frame view"/"frame view" commands from
+ overriding existing entries into the stash, should the user specify the
+ same frame more than once. This will also help in the subsequent patch
+ that makes frame_info_ptr capable of reinflating user-created frames.
+ It will be able to just call create_new_frame and it will do the right
+ thing.
+
+ Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add frame_id::user_created_p
+ Later in this series, we'll need to differentiate frame ids for regular
+ frames (obtained from the target state and unwinding from it) vs frame
+ ids for user-created frames (created with create_new_frame). Add the
+ frame_id::user_created_p field to indicate a frame is user-created, and
+ set it in create_new_frame.
+
+ The field is otherwise not used yet, so not changes in behavior are
+ expected.
+
+ Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: move frame_info_ptr to frame.{c,h}
+ A patch later in this series will make frame_info_ptr access some
+ fields internal to frame_info, which we don't want to expose outside of
+ frame.c. Move the frame_info_ptr class to frame.h, and the definitions
+ to frame.c. Remove frame-info.c and frame-info.h.
+
+ Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move call site types to call-site.h
+ I hesitated between putting the file in the dwarf2 directory (as
+ gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
+ The concept of call site is not DWARF-specific, another debug info
+ reader could provide this information. But as it is, the implementation
+ is a bit DWARF-specific, as one form it can take is a DWARF expression
+ and parameters can be defined using a DWARF register number. So I ended up
+ choosing to put it under dwarf2/. If another debug info reader ever
+ wants to provide call site information, we can introduce a layer of
+ abstraction between the "common" call site and the "dwarf2" call site.
+
+ The copyright start year comes from the date `struct call_site` was
+ introduced.
+
+ Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move sect_offset and cu_offset to dwarf2/types.h
+ I want to move the call_site stuff out of gdbtypes.h, to a new header
+ file, to break some cyclic include problem. The call_site stuff uses
+ cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move
+ somewhere else (otherwise, call-site.h will need to include gdbtypes.h,
+ and we are back to square 1). I could move cu_offset to the future new
+ file dwarf2/call-site.h, but it doesn't sound like a good place for it,
+ at cu_offset is not specific to call sites, it's used throughout
+ dwarf2/. So, move it to its own file, dwarf2/types.h. For now,
+ gdbtypes.h includes dwarf2/types.h, but that will be removed once the
+ call site stuff is moved to its own file.
+
+ Move sect_offset with it too. sect_offset is not a DWARF-specific
+ concept, but for the moment it is only used in dwarf2/.
+
+ Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove language.h include from frame.h
+ This helps resolve some cyclic include problem later in the series.
+ The only language-related thing frame.h needs is enum language, and that
+ is in defs.h.
+
+ Doing so reveals that a bunch of files were relying on frame.h to
+ include language.h, so fix the fallouts here and there.
+
+ Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move compile_instance to compile/compile.h
+ struct compile_instance needs to be visible to users, since we use
+ std::unique<compile_instance>. language.c and c-lang.c currently
+ includes compile-internal.h for this reason, which kind of defeats the
+ purpose of having an "internal" header file.
+
+ Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move type_map_instance to compile/compile.c
+ It's only used in compile/compile.c, it doesn't need to be in a header.
+
+ Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-20 Indu Bhagat <indu.bhagat@oracle.com>
+
+ Upload SFrame spec files as well
+ binutils/
+ * README-how-to-make-a-release: Include sframe-spec html and pdf
+ files.
+
+2023-01-20 Tom Tromey <tom@tromey.com>
+
+ Use bool in pc_in_* functions
+ I noticed that pc_in_unmapped_range had a weird return type -- it was
+ returning a CORE_ADDR but intending to return a bool. This patch
+ changes all the pc_in_* functions to return bool instead.
+
+2023-01-20 Tom Tromey <tromey@adacore.com>
+
+ Constify notif_client
+ It seems to me that a notif_client is read-only, so this patch changes
+ the code to use "const" everywhere.
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove struct trad_frame forward declaration
+ I found this forward declaration for a struct that doesn't exist, remove
+ it.
+
+ Change-Id: Ib9473435a949452160598035e5e0fe19fcdc4d20
+
+2023-01-20 Tom Tromey <tromey@adacore.com>
+
+ Make gdb.ada/ptype_tagged_param.exp pass
+ gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
+ However, it's actually generating the correct output -- it is just
+ that the test thinks that the "ptype" will not work because I do not
+ have the GNAT debuginfo installed.
+
+ This patch changes the code to accept either result, and then to issue
+ a kfail as appropriate.
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf: fix UBsan crash in read_subrange_type
+ When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the
+ `gnat-11` package installed (not `gnat`), with UBSan activated, I get:
+
+ (gdb) break foo.adb:40
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int'
+
+ The problematic DIEs are:
+
+ 0x00001460: DW_TAG_subrange_type
+ DW_AT_lower_bound [DW_FORM_data1] (0x00)
+ DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000)
+ DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423")
+ DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned")
+ DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e)
+ DW_AT_artificial [DW_FORM_flag_present] (true)
+
+ 0x0000153f: DW_TAG_base_type
+ DW_AT_byte_size [DW_FORM_data1] (0x10)
+ DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned)
+ DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned")
+ DW_AT_artificial [DW_FORM_flag_present] (true)
+
+ When processed by this code:
+
+ negative_mask =
+ -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
+ if (low.kind () == PROP_CONST
+ && !base_type->is_unsigned () && (low.const_val () & negative_mask))
+ low.set_const_val (low.const_val () | negative_mask);
+
+ When the base type's length (16 bytes in this case) is larger than a
+ ULONGEST (typically 8 bytes), the bit shift is too large.
+
+ My obvious fix is just to skip the fixup for base types larger than a
+ ULONGEST (8 bytes). I don't think we really handle constant attribute
+ values larger than 8 bytes anyway, so this is part of a much larger
+ problem.
+
+ Add a test that replicates this situation, but uses bounds that fit in a
+ signed 64 bit, so we get a sensible result.
+
+ Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386
+
+2023-01-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: add test for negative subrange bounds with unsigned form
+ I am looking at this code [1]:
+
+ /* Normally, the DWARF producers are expected to use a signed
+ constant form (Eg. DW_FORM_sdata) to express negative bounds.
+ But this is unfortunately not always the case, as witnessed
+ with GCC, for instance, where the ambiguous DW_FORM_dataN form
+ is used instead. To work around that ambiguity, we treat
+ the bounds as signed, and thus sign-extend their values, when
+ the base type is signed. */
+ negative_mask =
+ -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
+ if (low.kind () == PROP_CONST
+ && !base_type->is_unsigned () && (low.const_val () & negative_mask))
+ low.set_const_val (low.const_val () | negative_mask);
+ if (high.kind () == PROP_CONST
+ && !base_type->is_unsigned () && (high.const_val () & negative_mask))
+ high.set_const_val (high.const_val () | negative_mask);
+
+ Nothing in the testsuite seems to exercise it, as when I remove it, all
+ of gdb.dwarf2 still passes. And tests in other directories would be
+ compiler-dependent, so would rely on having a buggy compiler.
+
+ Update gdb.dwarf2/subrange.exp to have a test for it. When removing the
+ code above, the new test fails with:
+
+ ptype array_with_buggy_negative_bounds_type^M
+ type = array [240..244] of signed_byte^M
+ (gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
+
+ instead of the expected:
+
+ ptype array_with_buggy_negative_bounds_type^M
+ type = array [-16..-12] of signed_byte^M
+ (gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
+
+ [1] https://gitlab.com/gnutools/binutils-gdb/-/blob/5ea14aa4e53fa37f4ba4517497ed2c1e4c60dee2/gdb/dwarf2/read.c#L17681-17695
+
+ Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2
+
+2023-01-20 Michael Matz <matz@suse.de>
+
+ Add testcase ld-elf/merge4
+ to check a situation that once failed with the new section merging
+ when it mishandled offsets pointing into alignment padding in mergable
+ string sections (i.e. pointing to zeros). It made bootstrap.exp fail
+ but that depends on many factors to actually go wrong so this is a more
+ explicit variant of it.
+
+2023-01-20 Michael Matz <matz@suse.de>
+
+ arm32: Fix rodata-merge-map
+ the test expects a second, but useless, $d mapping symbol for
+ the partially merged section, and specifically disallows one
+ for the completely merged section. The new merging algorithm
+ makes it so that also the partially merged sections are conceptually
+ SEC_EXCLUDED, except the first merge section (e.g. as if the very
+ first object file already contains all strings). So that second mapping
+ symbol is now missing. It never was needed anyway.
+
+ So, adjust the test.
+
+2023-01-20 Michael Matz <matz@suse.de>
+
+ Faster string merging
+ * use power-of-two hash table
+ * use better hash function (hashing 32bits at once and with better
+ mixing characteristics)
+ * use input-offset-to-entry maps instead of retaining full input
+ contents for lookup time
+ * don't reread SEC_MERGE section multiple times
+ * care for cache behaviour for the hot lookup routine
+
+ The overall effect is less usage in libz and much faster string merging
+ itself. On a debug-info-enabled cc1 the effect at the time of this
+ writing on the machine I used was going from 14400 perf samples to 9300
+ perf samples or from 3.7 seconds to 2.4 seconds, i.e. about 33% .
+
+2023-01-20 Frederic Cambus <fred@statdns.com>
+
+ Add OpenBSD ARM GAS support.
+
+2023-01-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: split i386-gen's opcode hash entry struct
+ All glibc malloc() implementations I've checked have a smallest
+ allocation size worth of 3 pointers, with an increment worth of 2
+ pointers. Hence mnemonics with multiple templates can be stored more
+ efficiently when maintaining the shared "name" field only in the actual
+ hash entry. (To express the shared nature, also convert "name" to by
+ pointer-to-const.)
+
+ While doing the conversation also pull out common code from the involved
+ if/else construct in expand_templates().
+
+2023-01-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: embed register and alike names in disassembler
+ Register names are (including their nul terminators) on average almost 4
+ bytes long. Otoh no register name is longer than 8 bytes. Hence even for
+ 32-bit builds using a pointer is only slightly more space efficient than
+ embedding the strings. A level of indirection can be also avoided by
+ embedding the names as an array of 8 characters directly in the arrays,
+ and the number of base relocations in libopcodes.so (or PIE builds of
+ statically linked executables) goes down as well.
+
+ To amortize for the otherwise reduced folding of string literals by the
+ linker, use att_names_seg[] in place of string literals in append_seg()
+ and OP_ESreg().
+
+2023-01-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: embed register names in reg_entry
+ Register names are (including their nul terminators) on average almost 4
+ bytes long. Otoh no register name is longer than 7 bytes. Hence even for
+ 32-bit builds using a pointer is only slightly more space efficient than
+ embedding the strings. A level of indirection can be also avoided by
+ embedding the names as an array of 8 characters directly in the struct,
+ and the number of base relocations in PIE builds of gas goes down as
+ well.
+
+ x86: avoid strcmp() in a few places
+ Now that we have identifiers for the mnemonic strings we can avoid
+ strcmp() in a number of places, comparing the offsets into the mnemonic
+ string table instead. While doing this also
+ - convert a leftover strncmp() to startswith() (apparently an oversight
+ when rebasing the original patch introducing the startswith() uses),
+ - use the new shorthand for current_templates->start also elsewhere in
+ md_assemble() (valid up to the point where match_template() is
+ called).
+
+ x86: absorb allocation in i386-gen
+ When generating the mnemonic string table we already set up an
+ identifier for the following entry in a number of cases. Re-use that on
+ the next loop iteration rather than re-doing allocation and conversion.
+
+ x86: re-use insn mnemonic strings as much as possible
+ Compact the mnemonic string table such that the tails of longer
+ mnemonics are re-used for shorter ones, going beyond what compilers
+ would typically do, but matching what ELF linkers may do when processing
+ SHF_MERGE|SHF_STRINGS sections. This reduces table size by about 12.5%.
+
+2023-01-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: move insn mnemonics to a separate table
+ Using full pointers to reference the insn mnemonic strings is not very
+ efficient. With overall string size presently just slightly over 20k,
+ even a 16-bit value would suffice. Use "unsigned int" for now, as
+ there's no good use we could presently make of the otherwise saved 16
+ bits.
+
+ For 64-bit builds this reduces table size by 6.25% (prior to the recent
+ ISA extension additions it would have been 12.5%), with a similar effect
+ on cache occupation of table entries accessed. For PIE builds of gas
+ this also reduces the number of base relocations quite a bit (obviously
+ independent of bitness).
+
+2023-01-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: abstract out obtaining of a template's mnemonic
+ In preparation for changing the representation of the "name" field
+ introduce a wrapper function. This keeps the mechanical change separate
+ from the functional one.
+
+2023-01-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-19 Tom Tromey <tromey@adacore.com>
+
+ Use "maint ignore-probes" in no-libstdcxx-probe.exp
+ While looking at some test output, I saw that no-libstdcxx-probe.exp
+ was not being run. However, it occurred to me that Tom de Vries' new
+ "maint ignore-probes" command could be used to enable this test
+ unconditionally.
+
+ Reviewed-by: Tom de Vries <tdevries@suse.de>
+
+2023-01-19 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ i386: Don't emit unsupported TLS relocs on Solaris
+ Emit R_386_TLS_LE and R_386_TLS_IE, instead of R_386_TLS_LE_32 and
+ R_386_TLS_IE_32, on Solaris.
+
+ PR ld/13671
+ * elf32-i386.c (elf_i386_tls_transition): Only emit R_386_TLS_LE,
+ R_386_TLS_IE on Solaris.
+ (elf_i386_relocate_section): Only use R_386_TLS_GD->R_386_TLS_LE
+ transition on Solaris.
+
+ Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
+
+2023-01-19 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ GDB/testsuite: Expand for character string limiting options
+ Modify test cases that verify the operation of the array element limit
+ with character strings such that they are executed twice, once with the
+ `set print characters' option set to `elements' and the limit controlled
+ with the `set print elements' option, and then again with the limit
+ controlled with the `set print characters' option instead. Similarly
+ with the `-elements' and `-characters' options for the `print' command.
+ Additionally verify that said `print' command options combined yield the
+ expected result.
+
+ Verify correct $_gdb_setting and $_gdb_setting_str values for the `print
+ characters' setting, in particular the `void' value for the `elements'
+ default, which has no corresponding integer value exposed.
+
+ Add Guile and Python coverage for the `print characters' GDB setting.
+
+ There are new tests for Ada and Pascal, as the string printing code for
+ these languages is different than the generic string printing code used
+ by other languages. Modula2 also has different string printing code,
+ but (a) this is similar to Pascal, and (b) there are no existing modula2
+ tests written in Modula2, so I'm not sure how I'd even test the Modula2
+ string printing.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-19 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ GDB: Add a character string limiting option
+ This commit splits the `set/show print elements' option into two. We
+ retain `set/show print elements' for controlling how many elements of an
+ array we print, but a new `set/show print characters' setting is added
+ which is used for controlling how many characters of a string are
+ printed.
+
+ The motivation behind this change is to allow users a finer level of
+ control over how data is printed, reflecting that, although strings can
+ be thought of as arrays of characters, users often want to treat these
+ two things differently.
+
+ For compatibility reasons by default the `set/show print characters'
+ option is set to `elements', which makes the limit for character strings
+ follow the setting of the `set/show print elements' option, as it used
+ to. Using `set print characters' with any other value makes the limit
+ independent from the `set/show print elements' setting, however it can
+ be restored to the default with the `set print characters elements'
+ command at any time.
+
+ A corresponding `-characters' option for the `print' command is added,
+ with the same semantics, i.e. one can use `elements' to make a given
+ `print' invocation follow the limit of elements, be it set with the
+ `-elements' option also given with the same invocation or taken from the
+ `set/show print elements' setting, for characters as well regardless of
+ the current setting of the `set/show print characters' option.
+
+ The GDB changes are all pretty straightforward, just changing references
+ to the old 'print_max' to use a new `get_print_max_chars' helper which
+ figures out which of the two of `print_max' and `print_max_chars' values
+ to use.
+
+ Likewise, the documentation is just updated to reference the new setting
+ where appropriate.
+
+ To make people's life easier the message shown by `show print elements'
+ now indicates if the setting also applies to character strings:
+
+ (gdb) set print characters elements
+ (gdb) show print elements
+ Limit on string chars or array elements to print is 200.
+ (gdb) set print characters unlimited
+ (gdb) show print elements
+ Limit on array elements to print is 200.
+ (gdb)
+
+ and the help text shows the dependency as well:
+
+ (gdb) help set print elements
+ Set limit on array elements to print.
+ "unlimited" causes there to be no limit.
+ This setting also applies to string chars when "print characters"
+ is set to "elements".
+ (gdb)
+
+ In the testsuite there are two minor updates, one to add `-characters'
+ to the list of completions now shown for the `print' command, and a bare
+ minimum pair of checks for the right handling of `set print characters'
+ and `show print characters', copied from the corresponding checks for
+ `set print elements' and `show print elements' respectively.
+
+ Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-19 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Allow arbitrary keywords in integer set commands
+ Rather than just `unlimited' allow the integer set commands (or command
+ options) to define arbitrary keywords for the user to use, removing
+ hardcoded arrangements for the `unlimited' keyword.
+
+ Remove the confusingly named `var_zinteger', `var_zuinteger' and
+ `var_zuinteger_unlimited' `set'/`show' command variable types redefining
+ them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
+ have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
+
+ Following existing practice `var_pinteger' allows extra negative values
+ to be used, however unlike `var_zuinteger_unlimited' any number of such
+ values can be defined rather than just `-1'.
+
+ The "p" in `var_pinteger' stands for "positive", for the lack of a more
+ appropriate unambiguous letter, even though 0 obviously is not positive;
+ "n" would be confusing as to whether it stands for "non-negative" or
+ "negative".
+
+ Add a new structure, `literal_def', the entries of which define extra
+ keywords allowed for a command and numerical values they correspond to.
+ Those values are not verified against the basic range supported by the
+ underlying variable type, allowing extra values to be allowed outside
+ that range, which may or may not be individually made visible to the
+ user. An optional value translation is possible with the structure to
+ follow the existing practice for some commands where user-entered 0 is
+ internally translated to UINT_MAX or INT_MAX. Such translation can now
+ be arbitrary. Literals defined by this structure are automatically used
+ for completion as necessary.
+
+ So for example:
+
+ const literal_def integer_unlimited_literals[] =
+ {
+ { "unlimited", INT_MAX, 0 },
+ { nullptr }
+ };
+
+ defines an extra `unlimited' keyword and a user-visible 0 value, both of
+ which get translated to INT_MAX for the setting to be used with.
+
+ Similarly:
+
+ const literal_def zuinteger_unlimited_literals[] =
+ {
+ { "unlimited", -1, -1 },
+ { nullptr }
+ };
+
+ defines the same keyword and a corresponding user-visible -1 value that
+ is used for the requested setting. If the last member were omitted (or
+ set to `{}') here, then only the keyword would be allowed for the user
+ to enter and while -1 would still be used internally trying to enter it
+ as a part of a command would result in an "integer -1 out of range"
+ error.
+
+ Use said error message in all cases (citing the invalid value requested)
+ replacing "only -1 is allowed to set as unlimited" previously used for
+ `var_zuinteger_unlimited' settings only rather than propagating it to
+ `var_pinteger' type. It could only be used for the specific case where
+ a single extra `unlimited' keyword was defined standing for -1 and the
+ use of numeric equivalents is discouraged anyway as it is for historical
+ reasons only that they expose GDB internals, confusingly different
+ across variable types. Similarly update the "must be >= -1" Guile error
+ message.
+
+ Redefine Guile and Python parameter types in terms of the new variable
+ types and interpret extra keywords as Scheme keywords and Python strings
+ used to communicate corresponding parameter values. Do not add a new
+ PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
+ variable type now, permitting existing parameters defined by GDB proper,
+ such as `listsize', to be accessed from Scheme code.
+
+ With these changes in place it should be trivial for a Scheme or Python
+ programmer to expand the syntax of the `make-parameter' command and the
+ `gdb.Parameter' class initializer to have arbitrary extra literals along
+ with their internal representation supplied.
+
+ Update the testsuite accordingly.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: Use AM_SILENT_RULES macro in configure.ac
+ Silence 'make' by default.
+
+ libsframe/
+ * configure.ac: Use AM_SILENT_RULES.
+ * configure: Regenerate.
+
+2023-01-19 Tom Tromey <tom@tromey.com>
+
+ Remove some unused includes
+ I noticed a few spots that include gnu-stabs.h but that do not need
+ to. This patch removes these unnecessary includes. Tested by
+ rebuilding.
+
+2023-01-19 Tom de Vries <tdevries@space.suse.cz>
+
+ [gdb/tdep, aarch64] Remove fp and sp reg aliases, add x31 reg alias
+ In aarch64-tdep.c we find these register aliases:
+ ...
+ {
+ /* 64-bit register names. */
+ {"fp", AARCH64_FP_REGNUM},
+ {"lr", AARCH64_LR_REGNUM},
+ {"sp", AARCH64_SP_REGNUM},
+ ...
+
+ The sp alias is superfluous, because the canonical name of x31 is already sp.
+
+ The fp alias is superfluous, because it's already taken by the default meaning
+ of fp, assigned here in _initialize_frame_reg:
+ ...
+ user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
+ ...
+
+ Fix this by removing the fp and sp aliases.
+
+ While we're at it, add an x31 alias for sp.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+ Tested on aarch64-linux.
+ PR tdep/30012
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012
+
+2023-01-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian
+ On s390x-linux, I run into:
+ ...
+ (gdb) python print(u[u_fields[0]])^M
+ 99^M
+ (gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field
+ python print(u[u_fields[1]])^M
+ 0 '\000'^M
+ (gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field
+ ...
+
+ There's a var u of this type:
+ ...
+ union U {
+ int a;
+ char c;
+ };
+ ...
+ and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which
+ it does on x86_64), but instead it contains 0.
+
+ Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both
+ little and big endian.
+
+ Tested on x86_64-linux and s390x-linux.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ Reinitialise macro_nest
+ * input-scrub.c (input_scrub_begin): Init macro_nest.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ PR 30022, concurrent builds can fail
+ So let's not copy .libs/libbfd.a to libbfd.a now that nothing in the
+ binutils-gdb source tries to link against it.
+
+ PR 30022
+ * Makefile.am (noinst_LIBRARIES, libbfd_a_SOURCES, stamp-lib),
+ (libbfd.a): Delete rules.
+ (CLEANFILES): Adjust to suit.
+
+2023-01-19 Indu Bhagat <indu.bhagat@oracle.com>
+
+ toplevel: Makefile.def: add install-strip dependency on libsframe
+ As noted in PR libsframe/30014 - FTBFS: install-strip fails because
+ bfdlib relinks and fails to find libsframe, the install time
+ dependencies of libbfd need to be updated.
+
+ PR libsframe/30014
+ * Makefile.def: Reflect that libsframe needs to installed before
+ libbfd. Reorder a bit to better track libsframe dependencies.
+ * Makefile.in: Regenerate.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ The fuzzers have found the reloc special functions in coff-aarch64.c
+ All of them need a bfd_reloc_offset_in_range check before accessing
+ data + reloc_entry->address. This patch adds the missing checks and
+ sanity checks reloc offsets in coff_pe_aarch64_relocate_section too.
+
+ All of them also need changing to support objdump -W calls to
+ bfd_simple_get_relocated_section_contents. At least, secrel_reloc
+ needs the support, the others might not be present in dwarf debug
+ sections.
+
+ * coff-aarch64.c (coff_aarch64_rel21_reloc): Range check
+ reloc offset. Support final-linking.
+ (coff_aarch64_po12l_reloc): Likewise.
+ (coff_aarch64_addr32nb_reloc): Likewise.
+ (coff_aarch64_secrel_reloc): Likewise.
+ (coff_pe_aarch64_relocate_section): Range check reloc offset.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ Correct coff-aarch64 howtos and delete unnecessary special functions
+ The remaining special functions are still broken except when called
+ by gas bfd_install_relocation.
+
+ * coff-aarch64.c (coff_aarch64_addr64_reloc),
+ (coff_aarch64_addr32_reloc, coff_aarch64_branch26_reloc),
+ (coff_aarch64_branch19_reloc, coff_aarch64_branch14_reloc),
+ (coff_aarch64_po12a_reloc): Delete.
+ (HOWTO_INSTALL_ADDEND): Define as 1.
+ (HOW): Remove pcrel_off. Correct all the howtos.
+ (CALC_ADDEND): Define.
+ (coff_aarch64_rtype_to_howto): New function.
+ (coff_rtype_to_howto): Define.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ coff-aarch64.c howtos
+ This is just a patch to fix overlong lines. Wrapping the HOWTO macro
+ in a new HOW macro helps in this. No functional changes here.
+
+ * coff-aarch64.c (HOW): Define and use for reloc howtos.
+
+2023-01-19 Alan Modra <amodra@gmail.com>
+
+ howto install_addend
+ This adds a new flag to the reloc howtos that can be used to
+ incrementally change targets over to simple bfd_install_relocation
+ that just installs the addend without any weird adjustments.
+ I've made a few other changes to bfd_install_relocation, removing dead
+ code and comments that are really only applicable to
+ bfd_perform_relocation.
+
+ There is also a reloc offset bounds check change. I've moved the
+ check to where data is accessed, as it seems reasonable to me to not
+ perform the check unless it is needed. There is precedence for this;
+ Relocations against absolute symbols already avoided the check.
+
+ I also tried always performing the reloc offset check, and ran into
+ testsuite failures due to _NONE and _ALIGN relocs at the end of
+ sections. These likely would be fixed if all such reloc howtos had
+ size set to zero, but I would rather not edit lots of files when it
+ involves checking that target code does not use the size.
+
+ * reloc.c (struct reloc_howto_struct): Add install_addend.
+ (HOWTO_INSTALL_ADDEND): Define.
+ (HOWTO): Init new field with HOWTO_INSTALL_ADDEND.
+ (bfd_install_relocation): Remove comments copied from
+ bfd_perform_relocation that aren't applicable here. Remove
+ code dealing with output_offset and output_section. Just set
+ relocation to addend if install_addend. Move reloc offset
+ bounds check to just before section data is accessed, avoiding
+ the check when data is not accessed.
+ * bfd-in2.h: Regenerate.
+
+2023-01-19 Mike Frysinger <vapier@gentoo.org>
+
+ sim: info: convert verbose field to a bool
+ The verbose argument has always been an int treated as a bool, so
+ convert it to an explicit bool. Further, update the API docs to
+ match the reality that the verbose value is actually used by some
+ of the internal modules.
+
+ sim: unify sim-signal.o building
+ Now that sim-main.h has been reduced significantly, we can remove it
+ from sim-signal.c and unify it across all boards since it compiles to
+ the same code.
+
+ sim: v850: reduce extra header inclusion to igen files
+ Limit these extra header includes to only when specific igen files
+ include us until we can move the includes to the igen fils directly.
+
+ sim: v850: drop redundant define
+ This is already in v850/local.mk, so we can drop it from sim-main.h.
+
+2023-01-19 Mark Wielaard <mark@klomp.org>
+
+ sim: mn10300: minimize mn10300-sim.h include in sim-main.h
+ sim-main.h is special since it is one of the files automatically
+ included in igen generated files. But this means anything including
+ sim-main.h might get everything included just for the igen files.
+
+ To prevent clashing symbols/defines only include sim-fpu.h,
+ sim-signal.h, mn10300-sim.h from sim-main.h if it is included
+ from one of the generated igen C files. Add explicit includes
+ of mn10300-sim.h, sim-fpu.h and/or sim-signal.h to dv-mn103cpu.c,
+ interp.c and op_utils.c.
+
+2023-01-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-18 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Add references to erased args in cli-decode.c
+ Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within
+ cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter
+ callbacks for settings") and update inline documentation accordingly for
+ `add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the
+ `args' parameter and removing references to `var', `set_setting_func'
+ and `get_setting_func'.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-18 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Add missing inline documentation for `add_setshow_cmd_full'
+ Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct
+ within cmd_list_element") and add missing description for
+ `add_setshow_cmd_full'.
+
+ GDB: Correct inline documentation for `add_setshow_cmd_full_erased'
+ Use proper English in the description of SET_LIST and SHOW_LIST.
+
+2023-01-18 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Fix documentation for `theclass' parameters in cli-decode.c
+ Rename CLASS to THECLASS in the documentation for `theclass' parameters
+ throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword
+ cleanliness, mostly auto-generated").
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-18 Tom Tromey <tom@tromey.com>
+
+ Fix 'make TAGS' in gdbserver
+ PR build/29003 points out that "make TAGS" is broken in gdbserver.
+ This patch fixes the problem that is pointed out there, plus another
+ one I noticed while working on that -- namely that the "sed" computes
+ the wrong names for some source files. Finally, a couple of obsolete
+ variable references are removed.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29003
+
+2023-01-18 Carl Love <cel@us.ibm.com>
+
+ Revert "X86: reverse-finish fix"
+ This reverts commit b22548ddb30bfb167708e82d3bb932461c1b703a.
+
+ This patch is being reverted since the patch series is causing regressions.
+
+2023-01-18 Carl Love <cel@us.ibm.com>
+
+ Revert "PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp"
+ This reverts commit 92e07580db6a5572573d5177ca23933064158f89.
+
+ Reverting patch as the patch series is causing regressions.
+
+2023-01-18 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: care for dynamic objfiles in build_id_bfd_get ()
+ Accessing gdb.Objfile.build_id caused GDB to crash when objfile is
+ dynamic, that is created by JIT reader API.
+
+ The issue was NULL-pointer dereferencing in build_id_bfd_get () because
+ dynamic objfiles have no underlaying BFD structure. This commit fixes
+ the problem by a NULL-check in build_id_bfd_get ().
+
+2023-01-18 Nick Clifton <nickc@redhat.com>
+
+ Speed up objcopy's note merging.
+ PR 29993
+ * objcopy.c (merge_gnu_build_notes): Remember the last non-deleted note in order to speed up the scan for matching notes.
+
+2023-01-18 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: drop local psim link
+ This has never been installed, and it's not clear anyone cares about
+ it in the local build dir (when the main program is sim/ppc/run), so
+ drop all the logic to simplify.
+
+2023-01-18 Mark Harmstone <mark@harmstone.com>
+
+ Use subsystem to distinguish between pei-arm-little and pei-arm-wince-little
+ Running objdump against a 32-bit ARM PE file currently needs
+ disambiguation, as it gets picked up by both pei-arm-little and
+ pei-arm-wince-little.
+
+ This adds a check in pe_bfd_object_p so that the subsystem in the PE
+ header is used to do the disambiguation for us, so that WinCE images get
+ assigned to pei-arm-wince-little, and everything else to pei-arm-little.
+
+2023-01-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Revert "gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'"
+ This reverts commit c2a5d74050ea9d7897b4122ef57c627d395683b3.
+
+2023-01-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-17 Tom Tromey <tromey@adacore.com>
+
+ Remove two unused fields from gdbarch
+ When I converted gdbarch to use the registry, I forgot to remove the
+ two fields that were used to implement the previous approach. This
+ patch removes them. Tested by rebuilding.
+
+ Use require in paramless.exp
+ The new paramless.exp test was not converted to the new "require"
+ approach. This patch fixes the problem.
+
+2023-01-17 Carl Love <cel@us.ibm.com>
+
+ PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
+ PR record/29927 - reverse-finish requires two reverse next instructions to
+ reach previous source line
+
+ PowerPC uses two entry points called the local entry point (LEP) and the
+ global entry point (GEP). Normally the LEP is used when calling a
+ function. However, if the table of contents (TOC) value in register 2 is
+ not valid the GEP is called to setup the TOC before execution continues at
+ the LEP. When executing in reverse, the function finish_backward sets the
+ break point at the alternate entry point (GEP). However if the forward
+ execution enters via the normal entry point (LEP), the reverse execution
+ never sees the break point at the GEP of the function. Reverse execution
+ continues until the next break point is encountered or the end of the
+ recorded log is reached causing gdb to stop at the wrong place.
+
+ This patch adds a new address to struct execution_control_state to hold the
+ address of the alternate function start address, known as the GEP on
+ PowerPC. The finish_backwards function is updated. If the stopping point
+ is between the two entry points (the LEP and GEP on PowerPC), the stepping
+ range is set to execute back to the alternate entry point (GEP on PowerPC).
+ Otherwise, a breakpoint is inserted at the normal entry point (LEP on
+ PowerPC).
+
+ Function process_event_stop_test checks uses a stepping range to stop
+ execution in the caller at the first instruction of the source code line.
+ Note, on systems that only support one entry point, the address of the two
+ entry points are the same.
+
+ Test finish-reverse-next.exp is updated to include tests for the
+ reverse-finish command when the function is entered via the normal entry
+ point (i.e. the LEP) and the alternate entry point (i.e. the GEP).
+
+ The patch has been tested on X86 and PowerPC with no regressions.
+
+2023-01-17 Carl Love <cel@us.ibm.com>
+
+ X86: reverse-finish fix
+ PR record/29927 - reverse-finish requires two reverse next instructions to
+ reach previous source line
+
+ Currently on X86, when executing the finish command in reverse, gdb does a
+ single step from the first instruction in the callee to get back to the
+ caller. GDB stops on the last instruction in the source code line where
+ the call was made. When stopped at the last instruction of the source code
+ line, a reverse next or step command will stop at the first instruction
+ of the same source code line thus requiring two step/next commands to
+ reach the previous source code line. It should only require one step/next
+ command to reach the previous source code line.
+
+ By contrast, a reverse next or step command from the first line in a
+ function stops at the first instruction in the source code line where the
+ call was made.
+
+ This patch fixes the reverse finish command so it will stop at the first
+ instruction of the source line where the function call was made. The
+ behavior on X86 for the reverse-finish command now matches doing a
+ reverse-next from the beginning of the function.
+
+ The proceed_to_finish flag in struct thread_control_state is no longer
+ used. This patch removes the declaration, initialization and setting of
+ the flag.
+
+ This patch requires a number of regression tests to be updated. Test
+ gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
+ previous line. The gdb output for tests gdb.reverse/until-precsave.exp
+ and gdb.reverse/until-reverse.exp changed slightly. The expected result in
+ tests gdb.reverse/amd64-failcall-reverse.exp and
+ gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
+ result.
+
+ This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
+ reverse-finish command when returning from the entry point and from the
+ body of the function.
+
+ The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
+ was moved to lib/gdb.exp and renamed cmd_until.
+
+ The patch has been tested on X86 and PowerPC to verify no additional
+ regression failures occured.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927
+
+2023-01-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: expect SIGSEGV from top GDB spawn id
+ When testing with the native-extended-gdbserver, I get:
+
+ Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.
+ 0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1
+ (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
+
+ This is because the -re that is supposed to match this SIGSEGV is after
+ `-i $inferior_spawn_id`. On native, the top and bottom GDB are on the
+ same spawn id, so it ends up working. But with a gdbserver board,
+ that's not the case. Move the SIGSEGV -re before the `-i
+ $inferior_spawn_id` line, such that it matches what the top GDB outputs.
+
+ Do the same fix in gdb.gdb/python-helper.exp.
+
+ Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-01-17 Tom Tromey <tromey@adacore.com>
+
+ Fix parameter-less template regression in new DWARF reader
+ PR c++/29896 points out a regression in the new DWARF reader. It does
+ not properly handle a case like "break fn", where "fn" is a template
+ function.
+
+ This happens because the new index uses strncasecmp to compare.
+ However, to make this work correctly, we need a custom function that
+ ignores template parameters.
+
+ This patch adds a custom comparison function and fixes the bug. A new
+ test case is included.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896
+
+2023-01-17 Tom Tromey <tromey@adacore.com>
+
+ Move hash_entry and eq_entry into cooked_index::do_finalize
+ I was briefly confused by the hash_entry and eq_entry functions in the
+ cooked index. They are only needed in a single method, and that
+ method already has a couple of local lambdas for a different hash
+ table. So, it seemed cleaner to move these there as well.
+
+ Don't erase empty indices in DWARF reader
+ The DWARF reader has some code to remove empty indices. However, I
+ think this code has been obsolete since some earlier changes to
+ parallel_for_each. This patch removes this code.
+
+ Avoid submitting empty tasks in parallel_for_each
+ I found that parallel_for_each would submit empty tasks to the thread
+ pool. For example, this can happen if the number of tasks is smaller
+ than the number of available threads. In the DWARF reader, this
+ resulted in the cooked index containing empty sub-indices. This patch
+ arranges to instead shrink the result vector and process the trailing
+ entries in the calling thread.
+
+2023-01-17 Stam Markianos-Wright <stam.markianos-wright@arm.com>
+
+ gas: arm: Change warning message to not reference specific A-class architecture revision
+ We noticed that a warning message about the use of scalar fp16
+ instructions being UNPREDICTABLE when conditionalized in an IT
+ block referenced the specific A-class architecture revision
+ ARMv8.2-A.
+ Many of these instructions are now also part of ARMv8.1-M, so
+ the warning message had become misleading. Here we just change
+ the message to not specify an architecture revision at all and
+ update all testing accordingly. This was done with a simple
+ find-n-replace within the binutils sources. No tests have
+ regressed for the arm target.
+
+ gas/ChangeLog:
+
+ * config/tc-arm.c (do_scalar_fp16_v82_encode): Remove
+ ARMv8.2-A from the warning message.
+ (do_neon_movhf): Likewise
+ * testsuite/gas/arm/armv8-2-fp16-scalar-bad.l: Likewise
+ * testsuite/gas/arm/mve-vaddsub-it-bad.l: Likewise
+ * testsuite/gas/arm/mve-vcvtne-it-bad.l: Likewise
+ * testsuite/gas/arm/mve-vcvtne-it.d: Likewise
+
+2023-01-17 Stam Markianos-Wright <stam.markianos-wright@arm.com>
+
+ gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn
+ Previously we had experienced issues with assembling a "VCVTNE" instruction
+ in the presence of the MVE architecture extension, because it could be
+ interpreted both as:
+
+ * The base instruction VCVT + NE for IT predication when inside an IT block.
+ * The MVE instruction VCVTN + E in the Else of a VPT block.
+
+ Given a C reproducer of:
+ ```
+ int test_function(float value)
+ {
+ int ret_val = 10;
+ if (value != 0.0)
+ {
+ ret_val = (int) value;
+ }
+ return ret_val;
+ }
+ ```
+ GCC generates a VCVTNE instruction based on the `truncsisf2_vfp`
+ pattern, which will look like:
+ `vcvtne.s32.f32 s-reg, s-reg`
+ This still triggers an error due to being misidentified as "vcvtn+e"
+ Similar errors were found with other type combinations and instruction
+ patterns (these have all been added to the testing of this patch).
+
+ This class of errors was previously worked around by:
+ https://sourceware.org/pipermail/binutils/2020-August/112728.html
+ which addressed this by looking at the operand types, however,
+ that isn't adequate to cover all the extra cases that have been
+ found. Instead, we add some special-casing logic earlier when
+ the instructions are parsed that is conditional on whether we are
+ in a VPT block or not, when the instruction is parsed.
+
+ gas/ChangeLog:
+
+ * config/tc-arm.c (opcode_lookup): Add special vcvtn handling.
+ * testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.
+ * testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.
+ * testsuite/gas/arm/mve-vcvtne-it.d: Likewise.
+ * testsuite/gas/arm/mve-vcvtne-it.s: Likewise.
+
+2023-01-17 Nick Clifton <nickc@redhat.com>
+
+ Fix snafu in previous delta for elf32-csky.c
+
+2023-01-17 Xianmiao Qu <cooper.qu@linux.alibaba.com>
+
+ C-SKY: Fix machine flag.
+ * elf32-csky.c (elf32_csky_merge_attributes): Don't save and restore the ARCH attribute, it will actually clear the ARCH attribute. (csky_elf_merge_private_bfd_data): Store the machine flag correctly.
+
+2023-01-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-16 Enze Li <enze.li@hotmail.com>
+
+ libctf: update regexp to allow makeinfo to build document
+ While trying to build gdb on latest openSUSE Tumbleweed, I noticed the
+ following warning,
+
+ checking for makeinfo... makeinfo --split-size=5000000
+ configure: WARNING:
+ *** Makeinfo is too old. Info documentation will not be built.
+
+ then I checked the version of makeinfo, it said,
+ ======
+ $ makeinfo --version
+ texi2any (GNU texinfo) 7.0.1
+
+ Copyright (C) 2022 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law.
+ ======
+
+ After digging a little bit, it became quite obvious that a dot is
+ missing in regexp that makes it impossible to match versions higher than
+ 7.0, and here's the solution:
+
+ - | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9][0-9])' >/dev/null 2>&1; then
+ + | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9]\.[0-9])' >/dev/null 2>&1; then
+
+ However, Eli pointed out that the solution above has another problem: it
+ will stop working when Texinfo 10.1 will be released. Meanwhile, he
+ suggested to solve this problem permanently. That is, we don't care
+ about the minor version for Texinfo > 6.9, we only care about the major
+ version.
+
+ In this way, the problem will be resolved permanently, thanks to Eli.
+
+ libctf/ChangeLog:
+
+ * configure: Regenerated.
+ * configure.ac: Update regexp to match versions higher than 7.0.
+
+2023-01-16 Alan Modra <amodra@gmail.com>
+
+ Correct ld-pe/aarch64.d test output
+ "foo" is at 0x2010. This corrects the expected output for .long and
+ .word referencing foo, showing a problem with relocation handling.
+
+ * testsuite/ld-pe/aarch64.d: Correct expected output.
+
+2023-01-16 Alan Modra <amodra@gmail.com>
+
+ Tidy gas/expr.c static state
+ * expr.c (seen, nr_seen): Make file scope.
+ (expr_begin): Clear seen, nr_seen, and expr_symbol_lines.
+ (expr_end): New function.
+ * expr.h (expr_end): Declare.
+ * output-file.c (output_file_close): Call expr_end.
+ * config/tc-hppa.c (expr_end): Rename to expr_parse_end.
+ * config/tc-mips.c: Likewise.
+ * config/tc-riscv.c: Likewise.
+ * config/tc-sparc.c: Likewise.
+
+ Leftover hack from i960-coff
+ * reloc.c (bfd_perform_relocation, bfd_install_relocation): Remove
+ i960-coff target hack.
+
+2023-01-16 Alan Modra <amodra@gmail.com>
+
+ COFF CALC_ADDEND comment
+ Old COFF (and AOUT) targets have unusual relocation addends.
+
+ * coffcode.h (<Reading relocations>): Describe COFF addends.
+
+2023-01-16 Alan Modra <amodra@gmail.com>
+
+ PR29991, MicroMIPS flag erased after align directives
+ PR 29991
+ * config/tc-mips.c (s_align): Call file_mips_check_options and
+ mips_mark_labels.
+ * testsuite/gas/mips/align-after-label.s,
+ * testsuite/gas/mips/mips-align-after-label.d,
+ * testsuite/gas/mips/micromips-align-after-label.d: New test.
+ * testsuite/gas/mips/mips.exp: Run it.
+
+2023-01-16 Nick Clifton <nickc@redhat.com>
+
+ Update release making howto
+
+ Updated translations for the gas and binutils sub-directories
+
+2023-01-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: assume sys/stat.h always exists (via gnulib)
+ We have many uses of sys/stat.h that are unprotected by HAVE_SYS_STAT_H,
+ so this is more formalizing the reality that we require this header.
+ Since we switched to gnulib, it guarantees that a sys/stat.h exists
+ for us to include, so we're doubly OK.
+
+ sim: formally assume unistd.h always exists (via gnulib)
+ We have many uses of unistd.h that are unprotected by HAVE_UNISTD_H,
+ so this is more formalizing the reality that we require this header.
+ Since we switched to gnulib, it guarantees that a unistd.h exists
+ for us to include, so we're doubly OK.
+
+ sim: build: stop probing system extensions (ourselves)
+ This logic was added in order to expose the strsignal prototype for
+ nrun.c. Since then, we've migrated to gnulib as our portability layer,
+ and it takes care of probing system extensions for us, so there's no
+ need to duplicate the work.
+
+2023-01-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: modules.c: fix generation after recent refactors
+ Add explicit arch-specific modules.c rules to keep the build from
+ generating an incorrect common/modules.c. Otherwise the pattern
+ rules would cascade such that it'd look for $arch/modules.o which
+ turned into common/modules.c which triggered the gen rule.
+
+ My local testing of this code didn't catch this bug because of how
+ Automake manages .Po (dependency files) in incremental builds -- it
+ was adding extra rules that override the pattern rules which caused
+ the build to generate correct modules.c files. But when building
+ from a cold cache, the pattern rules would force common/modules.c to
+ be used leading to crashes at runtime.
+
+2023-01-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-15 Mark Wielaard <mark@klomp.org>
+
+ sim: microblaze, mn10300: remove signal.h include in interp.c
+ signal.h isn't needed in microblaze and mn10300 interp.c
+ so don't include it.
+
+2023-01-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: fix typos in stamp depends
+ Copying & pasting the first rule missed updating the dep to the right
+ stamp file.
+
+ sim: igen: simplify build logic a little
+ Now that all ports (that use igen) build in the top-level and depend
+ on igen, we can move the conditional logic out of configure. We also
+ switch from noinst_LIBRARIES to EXTRA_LIBRARIES so that the library
+ is only built when needed (i.e. the igen tool is used).
+
+ sim: build: drop depdir subdir hack
+ Now that all the ports compile some C files in their arch dirs, Automake
+ guarantees creating the depdir for us, so we can drop our configure hack.
+
+ sim: common: simplify modules.c deps
+ Now that all ports (other than ppc) build in the top-level, we don't
+ need to expand all the modules.c targets as a recursive dep. Each
+ port depends on their respective file now, and the ppc port doesn't
+ use it at all.
+
+ sim: common: move modules.c to source tracking
+ This makes sure the arch-specific modules.c wildcard is matched and
+ not the common/%.c so that we compile it correctly. It also makes
+ sure each subdir has depdir logic enabled.
+
+ sim: common: move libcommon.a dep to ppc code
+ Rather than force this to be built ahead of time for all targets,
+ move the dep to the ppc code since it's the only user of it now.
+
+ sim: build: drop most recursive build deps
+ Now that we build these objects in the top dir & generate modules.c
+ there, we don't need to generate them all first -- we can let the
+ normal dependency graph take care of building things in parallel.
+
+ sim: common: move libcommon.a objects to sources
+ This simplifies the build logic and avoids an Automake bug where the
+ common_libcommon_a_OBJECTS variable isn't set in the arch libsim.a
+ DEPENDENCIES for targets that, alphabetically, come before "common".
+ We aren't affected by that bug with the current code, but as we move
+ things out of SIM_ALL_RECURSIVE_DEPS and rely on finer dependencies,
+ we will trip over it.
+
+ sim: igen: simplify build dep
+ Now that all ports (other than ppc) build in the top-level, we don't
+ need to mark the igen tool as a recursive dep. Each port depends on
+ the tool if it actually uses it, and ppc doesn't use it at all.
+
+ sim: common: simplify hw-config.h deps
+ Now that all ports (other than ppc) build in the top-level, we don't
+ need to expand all the hw-config.h targets as a recursive dep. Each
+ port depends on their respective header now, and the ppc port doesn't
+ use it at all.
+
+ sim: build: drop AM_MAKEFLAGS settings
+ We don't have any recursive builds anymore, so we can drop this logic.
+
+2023-01-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-14 Tom Tromey <tom@tromey.com>
+
+ Pass internal gdb flags to --configuration invocations
+ The test suite uses the --configuration flag to feature-test gdb.
+ However, when I added this, I neglected to pass the internal gdbflags
+ to this, causing an error, which then caused failures in the test
+ suite (which would not be seen if you'd ever run "make install").
+
+ This patch fixes the bug. Tested by removing my install tree first,
+ to verify that I could reproduce the failure.
+
+2023-01-14 Nick Clifton <nickc@redhat.com>
+
+ Update how-to-make-a-release file now that the 2.40 release is out
+
+2023-01-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-13 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: delete Make-common.in logic
+ Now that all (other than ppc) build in the top-level, this logic is
+ unused, so punt it all.
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Rename to allow_tui_tests
+ This changes skip_tui_tests to invert the sense, and renames it to
+ allow_tui_tests. It also rewrites this function to use the output of
+ "gdb --configuration", and it adds a note about the state of the TUI
+ to that output.
+
+ Rename to allow_guile_tests
+ This changes skip_guile_tests to invert the sense, and renames it to
+ allow_guile_tests. It also rewrites this proc to check the output of
+ "gdb --configuration", as was done for Python. Then it changes the
+ code to use "require" where possible.
+
+ Rename to allow_hw_breakpoint_tests
+ This changes skip_hw_breakpoint_tests to invert the sense, and renames
+ it to allow_hw_breakpoint_tests. This also converts some tests to use
+ "require" -- I missed this particular check in the first series.
+
+ Rename to allow_tsx_tests
+ This changes skip_tsx_tests to invert the sense, and renames it to
+ allow_tsx_tests.
+
+ Rename to allow_shlib_tests
+ This changes skip_shlib_tests to invert the sense, and renames it to
+ allow_shlib_tests.
+
+ Rename to allow_rust_tests
+ This changes skip_rust_tests to invert the sense, and renames it to
+ allow_rust_tests.
+
+ Rename to allow_python_tests
+ This changes skip_python_tests to invert the sense, and renames it to
+ allow_python_tests.
+
+ Rename to allow_perf_tests
+ This changes skip_perf_tests to invert the sense, and renames it to
+ allow_perf_tests.
+
+ Rename to allow_opencl_tests
+ This changes skip_opencl_tests to invert the sense, and renames it to
+ allow_opencl_tests.
+
+ Rename to allow_ifunc_tests
+ This changes skip_ifunc_tests to invert the sense, and renames it to
+ allow_ifunc_tests.
+
+ Rename to allow_hw_watchpoint_tests
+ This changes skip_hw_watchpoint_tests to invert the sense, and renames
+ it to allow_hw_watchpoint_tests.
+
+ Rename to allow_hw_watchpoint_multi_tests
+ This changes skip_hw_watchpoint_multi_tests to invert the sense, and
+ renames it to allow_hw_watchpoint_multi_tests.
+
+ Rename to allow_hw_watchpoint_access_tests
+ This changes skip_hw_watchpoint_access_tests to invert the sense, and
+ renames it to allow_hw_watchpoint_access_tests.
+
+ Rename to allow_go_tests
+ This changes skip_go_tests to invert the sense, and renames it to
+ allow_go_tests.
+
+ Rename to allow_gdbserver_tests
+ This changes skip_gdbserver_tests to invert the sense, and renames it
+ to allow_gdbserver_tests.
+
+ Rename to allow_fortran_tests
+ This changes skip_fortran_tests to invert the sense, and renames it to
+ allow_fortran_tests.
+
+ Rename to allow_d_tests
+ This changes skip_d_tests to invert the sense, and renames it to
+ allow_d_tests.
+
+ Rename to allow_dlmopen_tests
+ This changes skip_dlmopen_tests to invert the sense, and renames it to
+ allow_dlmopen_tests.
+
+ Rename to allow_debuginfod_tests
+ This changes skip_debuginfod_tests to invert the sense, and renames it
+ to allow_debuginfod_tests.
+
+ Rename to allow_ctf_tests
+ This changes skip_ctf_tests to invert the sense, and renames it to
+ allow_ctf_tests.
+
+ Rename to allow_cplus_tests and allow_stl_tests
+ This changes skip_cplus_tests to invert the sense, and renames it to
+ allow_cplus_tests. This one also converts skip_stl_tests to
+ allow_stl_tests, as that was convenient to do at the same time.
+
+ Rename to allow_btrace_tests
+ This changes skip_btrace_tests to invert the sense, and renames it to
+ allow_btrace_tests.
+
+ Rename to allow_btrace_pt_tests
+ This changes skip_btrace_pt_tests to invert the sense, and renames it
+ to allow_btrace_pt_tests.
+
+ Rename to allow_avx512fp16_tests
+ This changes skip_avx512fp16_tests to invert the sense, and renames it
+ to allow_avx512fp16_tests.
+
+ Rename to allow_avx512bf16_tests
+ This changes skip_avx512bf16_tests to invert the sense, and renames it
+ to allow_avx512bf16_tests.
+
+ Rename to allow_ada_tests
+ This changes skip_ada_tests to invert the sense, and renames it to
+ allow_ada_tests.
+
+ Rename to allow_aarch64_sve_tests
+ This changes skip_aarch64_sve_tests to invert the sense, and renames
+ it to allow_aarch64_sve_tests.
+
+ Rename to allow_xml_test
+ This changes gdb_skip_xml_test to invert the sense, and renames it to
+ allow_xml_test.
+
+ Use "require" for Python tests
+ This changes various tests to use "require" for the Python feature.
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Fix latent bug in default_prompt_gdb_start
+ default_prompt_gdb_start mimics default_gdb_start, but does not set
+ the use_gdb_stub global. This caused one Python test to work only
+ because it used the ordinary gdb_start before later using
+ default_prompt_gdb_start.
+
+ This patch updates default_prompt_gdb_start to set this global as
+ well.
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Remove mi_skip_python_tests
+ mi_skip_python_tests was necessary because skip_python_tests used the
+ running gdb, and so needed to know what prompt to expect. Now that
+ skip_python_tests has been rewritten, mi_skip_python_tests is no
+ longer needed.
+
+ Rewrite skip_python_tests
+ This rewrites skip_python_tests to examine the output of
+ "gdb --configuration". This is a bit nicer because it
+ does not require an already-running gdb.
+
+ Use require gnat_runtime_has_debug_info
+ This changes some tests to use "require gnat_runtime_has_debug_info".
+
+ Use require !skip_debuginfod_tests
+ This changes some tests to use "require !skip_debuginfod_tests".
+
+ Use require using_fission
+ This changes some tests to use "require using_fission".
+
+ Use require target_can_use_run_cmd
+ This changes some tests to use "require target_can_use_run_cmd".
+
+ Use require !skip_opencl_tests
+ This changes some tests to use "require !skip_opencl_tests".
+
+ Use require !skip_perf_tests
+ This changes some tests to use "require !skip_perf_tests".
+
+ Use require gdb_trace_common_supports_arch
+ This changes some tests to use "require gdb_trace_common_supports_arch".
+
+ Use require gdb_skip_xml_test
+ This changes some tests to use "require gdb_skip_xml_test".
+
+ Use require !gdb_debug_enabled
+ This changes some tests to use "require !gdb_debug_enabled".
+
+ Use require is_c_compiler_gcc
+ This changes some tests to use "require is_c_compiler_gcc".
+
+ Use require !skip_shlib_tests
+ This changes some tests to use "require !skip_shlib_tests". This patch
+ cleans up a few spots that were missed in the earlier patch.
+
+ Use require !skip_gdbserver_tests
+ This changes some tests to use "require !skip_gdbserver_tests".
+
+ Use require isnative
+ This changes some tests to use "require isnative".
+
+ Use require can_spawn_for_attach
+ This changes some tests to use "require can_spawn_for_attach".
+
+ Use require !use_gdb_stub
+ This changes some tests to use "require !use_gdb_stub".
+
+ Use require support_go_compile
+ This changes some tests to use "require support_go_compile".
+
+ Use require supports_get_siginfo_type
+ This changes some tests to use "require supports_get_siginfo_type".
+
+ Use require can_single_step_to_signal_handler
+ This changes some tests to use "require can_single_step_to_signal_handler".
+
+ Use require is_elf_target
+ This changes some tests to use "require is_elf_target".
+
+ Use require is_amd64_regs_target
+ This changes some tests to use "require is_amd64_regs_target".
+
+ Use require is_aarch32_target
+ This changes some tests to use "require is_aarch32_target".
+
+ Use require is_aarch64_target
+ This changes some tests to use "require is_aarch64_target".
+
+ Use require support_displaced_stepping
+ This changes some tests to use "require support_displaced_stepping".
+
+ Use require !skip_avx_*
+ This changes some tests to use "require" with !skip_avx_*.
+
+ Use require !skip_btrace_tests
+ This changes some tests to use "require !skip_btrace_tests".
+
+ Use require !skip_btrace_pt_tests
+ This changes some tests to use "require !skip_btrace_pt_tests" and
+ "require !skip_tsx_tests".
+
+ Use require !skip_aarch64_sve_tests
+ This changes some tests to use "require !skip_aarch64_sve_tests".
+
+ Use require !skip_ifunc_tests
+ This changes some tests to use "require !skip_ifunc_tests".
+
+ Use require !skip_hw_watchpoint_tests
+ This changes some tests to use "require !skip_hw_watchpoint_tests".
+
+ Use require !skip_ctf_tests
+ This changes some tests to use "require !skip_ctf_tests".
+
+ Use require !skip_d_tests
+ This changes some tests to use "require !skip_d_tests".
+
+ Use require !skip_go_tests
+ This changes some tests to use "require !skip_go_tests".
+
+ Use require !skip_ada_tests
+ This changes some tests to use "require !skip_ada_tests".
+
+ Use require !skip_fortran_tests
+ This changes some tests to use "require !skip_fortran_tests".
+
+ Use require !skip_rust_tests
+ This changes some tests to use "require !skip_rust_tests".
+
+ Use require !skip_stl_tests
+ This changes some tests to use "require !skip_stl_tests".
+
+ Use require !skip_dlmopen_tests
+ This changes some tests to use "require !skip_dlmopen_tests".
+
+ Use require !skip_shlib_tests
+ This changes some tests to use "require !skip_shlib_tests".
+
+ Use require !skip_cplus_tests
+ This changes some tests to use "require !skip_cplus_tests".
+
+ Use require is_x86_like_target
+ This changes some tests to use "require is_x86_like_target".
+
+ Use require dwarf2_support
+ This changes some tests to use "require dwarf2_support".
+
+ Use require supports_process_record
+ This changes some tests to use "require supports_process_record".
+
+ Use require supports_reverse
+ This changes some tests to use "require supports_reverse".
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Use unsupported in 'require'
+ This changes 'require' to use 'unsupported' rather than 'untested'.
+ The latter doesn't really seem to be correct according to the DejaGNU
+ documentation:
+
+ Declares a test was not run. `untested' writes in the log file a
+ message beginning with _UNTESTED_, appending the `message' argument.
+ For example, you might use this in a dummy test whose only role is to
+ record that a test does not yet exist for some feature.
+
+ The example there, and some text elsewhere, is what makes me think
+ this isn't a great fit. On the other hand, 'unsupported' says:
+
+ Declares that a test case depends on some facility that does not exist
+ in the testing environment.
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Change 'require' to accept a list of predicates
+ This changes 'require' to accept a list of simple predicates. For
+ now, each predicate is just the name of a proc, optionally prefixed
+ with "!" to indicate that the result should be inverted.
+
+ It's possible to make this fancier, but so far I haven't done so. One
+ idea I had is to allow a predicate to have associated text to display
+ on failure. Another is to convert the predicates that need a running
+ gdb (e.g., skip_python_tests) to start their own gdb, and then
+ 'require' could enforce the rule that gdb not be running when it is
+ called.
+
+2023-01-13 Tom Tromey <tom@tromey.com>
+
+ Don't use ensure_gdb_index with require
+ This series changes 'require' to take a list of simple predicates.
+ This patch backs out the one use of 'require' that doesn't conform to
+ this -- calling ensure_gdb_index.
+
+2023-01-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'
+ gprofng/ChangeLog
+ 2023-01-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29987
+ * configure.ac: Remove dependencies on libbfd and libiberty.
+ * gprofng/src/Makefile.am: Likewise.
+ * configure: Rebuild.
+ * Makefile.in: Rebuild.
+ * src/Makefile.in: Rebuild.
+ * doc/Makefile.in: Rebuild.
+ * gp-display-html/Makefile.in: Rebuild.
+
+2023-01-13 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: replace an strncat with strcat
+ Calling strncat with the size of the src string is not so meaningful.
+ The length argument to strncat should specify the remaining bytes
+ bytes in the destination; although in this case, it appears to be
+ unncessary altogether to use strncat in the first place.
+
+ libsframe/
+ * sframe-dump.c (dump_sframe_func_with_fres): Use of strcat is
+ just as fine.
+
+2023-01-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdbserver: add comments to read_inferior_memory function
+ Just adding some comments to the gdbserver read_inferior_memory
+ function. No actual code changes.
+
+ gdb/infrun: add debug print in print_signal_received_reason
+ It would have helped me to see an infrun debug line being printed from
+ print_signal_received_reason, so I'm adding one.
+
+2023-01-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: int to bool conversion for normal_stop
+ Change the return type of normal_stop (infrun.c) from int to bool.
+ Update callers.
+
+ I've also converted the (void) to () in the function declaration and
+ definition, given I was changing those lines anyway.
+
+ There should be no user visible changes after this commit.
+
+2023-01-13 Nick Clifton <nickc@redhat.com>
+
+ Updated Romainian translation for the bfd sub-directory
+
+2023-01-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-12 Tom Tromey <tromey@adacore.com>
+
+ Disable ptype/o for dynamic types
+ A user pointed out that "ptype/o" of a certain Ada type -- while in C
+ mode -- caused gdb to crash.
+
+ The bug here is that dynamic types can't really be printed this way.
+ This patch avoids the bug by disabling the "/o" feature in this case.
+
+ Note that using "ptype/o" in this way makes sense for the time being,
+ because the Ada code doesn't support the "/o" feature (yet); and in
+ any case gdb should not crash.
+
+2023-01-12 Hans-Peter Nilsson <hp@axis.com>
+
+ ARM: Fix ld bloat introduced between binutils-2.38 and 2.39
+ Since commit 9833b7757d24, "PR28824, relro security issues",
+ ELF_MAXPAGESIZE matters much more, with regards to layout of
+ the linked file. That commit fixed an actual bug, but also
+ exposes a problem for targets were that value is too high.
+
+ For example, for ARM(32, a.k.a. "Aarch32") specifically
+ bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU)
+ targets pay an extra amount of up to 60 KiB of bloat in
+ DSO:s and executables. This matters when there are many
+ such files, and where storage is expensive.
+
+ It's *mostly* bloat when using a Linux kernel, as ARM(32) is
+ a good example of an target where ELF_MAXPAGESIZE is set to
+ an extreme value for an obscure corner-case. The ARM
+ (32-bit) kernel has 4 KiB pages, has had that value forever,
+ and can't be configured to any other value. The use-case is
+ IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but
+ not just that, but a setup where the Linux page-size is
+ configured to something other than the *default* 4 KiB. Not
+ sure there actually any such systems in use, again with
+ both Aarch32 compatibility support and a non-4KiB pagesize,
+ with all the warnings in the kernel config and requiring the
+ "EXPERT" level set on.
+
+ So, let's do like x86-64 in a2267dbfc9e1 "x86-64: Use only
+ one default max-page-size" and set ELF_MAXPAGESIZE to 4096.
+
+ bfd:
+ * elf32-arm.c (ELF_MAXPAGESIZE): Always set to 0x1000.
+
+2023-01-12 Hans-Peter Nilsson <hp@axis.com>
+
+ ld/testsuite: Adjust for ELF_MAXPAGESIZE 0x1000
+ Many tests reflect a setting of ELF_MAXPAGESIZE to 64 KiB.
+ With ELF_MAXPAGESIZE changed to 4 KiB, layout is sometimes
+ different and symbols end up in other places. Avoid churn
+ and regexpification of old test patterns by passing the
+ max-page-size setting active at the time.
+
+ ld/testsuite:
+
+ * testsuite/ld-arm/arm-elf.exp,
+ testsuite/ld-arm/non-contiguous-arm2.d,
+ testsuite/ld-arm/non-contiguous-arm3.d,
+ testsuite/ld-arm/non-contiguous-arm5.d,
+ testsuite/ld-arm/non-contiguous-arm6.d,
+ testsuite/ld-arm/thumb-plt-got.d, testsuite/ld-arm/thumb-plt.d:
+ Pass -z max-page-size=0x10000 explicitly to test that rely on
+ that value in output-matching patterns.
+
+2023-01-12 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: ctf-link outdated input check faulty
+ This check has a pair of faults which, combined, can lead to memory
+ corruption. Firstly, it assumes that the values of the ctf_link_inputs
+ hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much
+ shorter structure. So the flags check which is the core of this is
+ faulty (but happens, by chance, to give the right output on most
+ architectures, since usually we happen to get a 0 here, so the test that
+ checks this usually passes). Worse, the warning that is emitted when
+ the test fails is added to the wrong dict -- it's added to the input
+ dict, whose warning list is never consumed, rendering the whole check
+ useless. But the dict it adds to is still the wrong type, so we end up
+ overwriting something deep in memory (or, much more likely,
+ dereferencing a garbage pointer and crashing).
+
+ Fixing both reveals another problem: the link input is an *archive*
+ consisting of multiple members, so we have to consider whether to check
+ all of them for the outdated-func-info thing we are checking here.
+ However, no compiler exists that emits a mixture of members with this
+ flag on and members with it off, and the linker always reserializes (and
+ upgrades) such things when it sees them: so all members in a given
+ archive must have the same value of the flag, so we only need to check
+ one member per input archive.
+
+ libctf/
+ PR libctf/29983
+ * ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of
+ members of ctf_link_inputs right, fixing a possible spurious
+ tesst failure / wild pointer deref / overwrite. Emit the
+ warning message into the right dict.
+
+2023-01-12 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: skip the testsuite from inside dejagnu
+ The libctf testsuite uses Tcl try/catch to trap run_output errors. This
+ is only supported in reasonably recent Tcls, so we detect the lack of
+ try/catch and suppress the testsuite via an Automake conditional in its
+ absence.
+
+ But this turns out not to work: Automake produces a check-DEJAGNU target
+ regardless of the value of this conditional and sticks it in an
+ unconditionally-executed part of the makefile, so the testsuite gets
+ executed anyway, and fails with a nasty-looking syntax error. We can't
+ disable it by taking "dejagnu" out of AUTOMAKE_OPTIONS, because if you
+ do that Automake stops you using RUNTEST, RUNTESTFLAGS and other
+ variables users would expect to work.
+
+ So move to disabling the testsuite from inside the testsuite itself,
+ importing the value of the former Automake conditional as a Tcl variable
+ and exiting very early in default.exp if it's false.
+
+ * configure.ac (TCL_TRY): No longer an Automake conditional.
+ Rename to...
+ (HAVE_TCL_TRY): ... this.
+ * Makefile.am: Drop TCL_TRY.
+ (development.exp): Set have_tcl_try.
+ * testsuite/config/default.exp: Exit if have_tcl_try is false.
+
+ * configure: Regenerated.
+ * Makefile.in: Likewise.
+
+2023-01-12 Nick Alcock <nick.alcock@oracle.com>
+
+ ctf: fix various dreadful typos in the ctf_archive format comments
+ When defining a format it helps to a) get the endianness right when you
+ explicitly state what it is and b) define things in terms of fields that
+ exist rather than fields that don't.
+
+ (A bunch of changes of names during implementation were not reflected in
+ these comments...)
+
+ Thanks to Jose "Eye of the Eagle" Marchesi for spotting these.
+
+ include/
+ * ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of
+ this is in little-endian byte order, not network byte order.
+ (struct ctf_archive_modent): This is positioned right after the
+ end fo the struct ctf_archive, not at the offset of a
+ nonexistent field. The number of elements in the array depends
+ on ctfa_ndicts, not another nonexistent field.
+
+2023-01-12 Nick Clifton <nickc@redhat.com>
+
+ Ensure that libbacktrace/allocfail.sh is not deleted when creating release tarballs.
+ * Makefile.am (CLEANFILES): Import patch from upstream to prevent
+ allocafail.sh from being removed when running 'make clean'.
+
+2023-01-12 Alan Modra <amodra@gmail.com>
+
+ Use __func__ rather than __FUNCTION__
+ We already use C99's __func__ in places, use it more generally. This
+ patch doesn't change uses in the testsuite. I've also left one in
+ gold.h that is protected by GCC_VERSION < 4003. If any of the
+ remaining uses bothers anyone I invite patches.
+
+ bfd/
+ * bfd-in.h: Replace __FUNCTION__ with __func__.
+ * elf32-bfin.c: Likewise.
+ * elfnn-aarch64.c: Likewise.
+ * elfxx-sparc.c: Likewise.
+ * bfd-in2.h: Regenerate.
+ gas/
+ * config/tc-cris.c: Replace __FUNCTION__ with __func__.
+ * config/tc-m68hc11.c: Likewise.
+ * config/tc-msp430.c: Likewise.
+ gold/
+ * dwp.h: Replace __FUNCTION__ with __func__.
+ * gold.h: Likewise, except for use inside GCC_VERSION < 4003.
+ ld/
+ * emultempl/pe.em: Replace __FUNCTION__ with __func__.
+ * emultempl/pep.em: Likewise.
+ * pe-dll.c: Likewise.
+
+2023-01-12 Alan Modra <amodra@gmail.com>
+
+ Remove myself as hppa32 maintainer
+ Reflects the reality that I haven't done much on hppa32 for years.
+
+2023-01-12 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: drop subdir Makefile.in files
+ These aren't used anymore, so punt them all.
+
+2023-01-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/doc: fix install-html with Texinfo 7
+ Starting with Texinfo 7 (this commit [1]), the output directory for the
+ HTML doc format is gdb/doc/gdb_html, rather than gdb/doc/gdb previously.
+ This breaks the install-html target, which expects the HTML doc to be in
+ gdb/doc/gdb:
+
+ $ make install-html MAKEINFO=makeinfo DESTDIR=/tmp/install
+ make[1]: Entering directory '/home/simark/build/binutils-gdb/gdb'
+ make[2]: Entering directory '/home/simark/build/binutils-gdb/gdb/doc'
+ makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc/../../readline/readline/doc -I /home/simark/src/binutils-gdb/gdb/doc/../mi -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/gdb.texinfo
+ makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/stabs.texinfo
+ makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/annotate.texinfo
+ test -z "/usr/local/share/doc/gdb" || /bin/sh /home/simark/src/binutils-gdb/gdb/doc/../../mkinstalldirs "/tmp/install/usr/local/share/doc/gdb"
+ /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/gdb' '/tmp/install/usr/local/share/doc/gdb/gdb'
+ /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/gdb': No such file or directory
+ /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/stabs' '/tmp/install/usr/local/share/doc/gdb/stabs'
+ /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/stabs': No such file or directory
+ /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/annotate' '/tmp/install/usr/local/share/doc/gdb/annotate'
+ /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/annotate': No such file or directory
+ make[2]: *** [Makefile:278: install-html] Error 1
+ make[2]: Leaving directory '/home/simark/build/binutils-gdb/gdb/doc'
+ make[1]: *** [Makefile:2240: subdir_do] Error 1
+ make[1]: Leaving directory '/home/simark/build/binutils-gdb/gdb'
+ make: *** [Makefile:2006: install-html] Error 2
+
+ Fix this by adding -o switches to the HTML targets, to force the output
+ directories.
+
+ [1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a868421baf9c44227c43490687f8d6b8d6c95414
+
+ Change-Id: Ie147dc7b4a52eb2348005b8dc006a41b0784621f
+
+2023-01-11 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb: Update gdbarch.py with latest changes in gdbarch.c
+ Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep")
+ changed gdbarch.c without updating gdbarch.py. As a result, running
+ gdbarch.py reverts those changes and causes the build to fail.
+
+ So change gdbarch.py to generate the current version of gdbarch.c.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-11 Tom Tromey <tromey@adacore.com>
+
+ Set _WIN32_WINNT in common.m4 configure check
+ GCC recently added support for the Windows thread model, enabling
+ libstdc++ to support Windows natively. However, this supporrt
+ requires a version of Windows later than the minimum version that is
+ supported by GDB.
+
+ PR build/29966 points out that the GDB configure test for std::thread
+ does not work in this situation, because _WIN32_WINNT is not defined
+ in test program, and so <thread> seems to be fine.
+
+ This patch is an attempt to fix the problem, by using the same setting
+ for _WIN32_WINNT at configure time as is used at build time.
+
+ I don't have access to one of the older systems so I don't think I can
+ truly test this. I did do a mingw cross build, though. I'm going to
+ ask the bug reporter to test it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966
+
+2023-01-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ [gdb/testsuite] Fix regexp in gdb.threads/dlopen-libpthread.exp
+ Fix regexp in gdb.threads/dlopen-libpthread.exp:
+ 'libpthread\\.so' -> '/libpthread\\.so'.
+
+ Tested on x86_64-linux.
+
+2023-01-11 Alan Modra <amodra@gmail.com>
+
+ Fix XPASS weak symbols on x86_64-mingw32
+ Fixes commit 16fea92ccd99.
+
+ * testsuite/ld-scripts/weak.exp: Don't xfail x86_64 PE targets.
+ Do xfail other PE OS triplets by moving code setting xfails.
+
+2023-01-11 Nick Clifton <nickc@redhat.com>
+
+ Fix a potential illegal memory access in the BFD library when parsing a corrupt DWARF file.
+ PR 29988
+ * dwarf2.c (read_indexed_address): Fix check for an out of range
+ offset.
+
+2023-01-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, again
+ On an x86_64 laptop running ubuntu 22.04.1 with unity desktop:
+ ...
+ $ echo $XDG_CURRENT_DESKTOP
+ Unity:Unity7:ubuntu
+ ...
+ I have:
+ ...
+ $ echo $LD_PRELOAD
+ libgtk3-nocsd.so.0
+ ...
+ due to package gtk3-nocsd, a package recommended by unity-session.
+
+ Consequently, for each exec these dependencies are pulled in, including
+ libpthread.so.0:
+ ...
+ $ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
+ libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none)
+ libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
+ libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
+ libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
+ ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+ ...
+
+ So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok:
+ ...
+ # of expected passes 12
+ # of unsupported tests 1
+ ...
+ with LD_PRELOAD="" we have instead:
+ ...
+ (gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify
+ info sharedlibrary^M
+ From To Syms Read Shared Object Library^M
+ $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
+ $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
+ $hex $hex Yes dlopen-libpthread.so^M
+ (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
+ ...
+
+ The problem is that libpthread is expected as dependency of
+ dlopen-libpthread.so, but it's missing:
+ ...
+ $ lddtree dlopen-libpthread.so
+ dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none)
+ libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6
+ ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+ ...
+ due to having glibc 2.35, which has libpthread integrated into libc.
+
+ Fix this by:
+ - adding a proc has_dependency
+ - using [has_dependency $exec libpthread.so] as hint that libpthread
+ may be preloaded
+ - using ![has_dependency $shlib libpthread.so] to detect that
+ the libpthread.so dependency is missing.
+
+ Also add a missing return after untested "no matching probes".
+
+ Tested on x86_64-linux, with and without LD_PRELOAD="".
+
+2023-01-11 Jan Beulich <jbeulich@suse.com>
+
+ gas/RISC-V: adjust assembler for opcode table re-ordering
+ PR gas/29940
+
+ With the single-operand JAL entry now sitting ahead of the two-operand
+ one, the parsing of a two-operand insn would first try to parse an 'a'-
+ style operand, resulting in the insertion of bogus (and otherwise
+ unused) undefined symbols in the symbol table, having register names.
+ Since 'a' is used as 1st operand only with J and JAL, and since JAL is
+ the only insn _also_ allowing for a register as 1st operand (and then
+ there being a 2nd one), special case this parsing aspect right there.
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2023-01-11 Alan Modra <amodra@gmail.com>
+
+ Tidy some global bfd state used by gas
+ * subsegs.c (subsegs_end): Clear abs and und userdata.
+
+2023-01-11 Alan Modra <amodra@gmail.com>
+
+ now_seg after closing output file
+ now_seg, a pointer into the output file sections, isn't valid after
+ the output file is closed. gas doesn't and shouldn't use now_seg
+ after this point of course, but let's be safe.
+
+ * output-file.c (output_file_close): Clear now_seg and now_subseg.
+
+2023-01-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-10 Tom Tromey <tom@tromey.com>
+
+ Fix bug in 'say_where' transform
+ The patch to change say_where into a method introduced a bug. This
+ patch fixes it.
+
+2023-01-10 Mark Harmstone <mark@harmstone.com>
+
+ gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64
+ Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to
+ make sure that DWARF offsets are encoded correctly (they're secrels in
+ COFF). There were remnants of this there before, but they were removed
+ by Jedidiah's original patch - presumably because we didn't yet have
+ .secrel32.
+
+2023-01-10 Mark Harmstone <mark@harmstone.com>
+
+ Add aarch64-w64-mingw32 target
+ This adds a mingw target for aarch64, including windres and dlltool.
+
+ Note that the old value of jmp_aarch64_bytes was wrong, and this does
+ the same thing as MSVC does.
+
+2023-01-10 Mark Harmstone <mark@harmstone.com>
+
+ Add .secrel32 for pe-aarch64
+ Adds the .secrel32 pseudo-directive and its corresponding relocation.
+
+ Add pe-aarch64 relocations
+ This adds the remaining pe-aarch64 relocations, and gets them working.
+ It also brings in the constant directives from ELF, as otherwise .word
+ would be 2 rather than 4 bytes, and .xword and .dword wouldn't be
+ defined.
+
+2023-01-10 Mark Harmstone <mark@harmstone.com>
+
+ Fix size of external_reloc for pe-aarch64
+ This patch series finishes off the work by Jedidiah Thompson, and adds
+ support for creating aarch64 PE images.
+
+ This should be essentially complete: I've used this to create a "hello
+ world" Windows program in asm, and (with GCC patches) a UEFI program in
+ C. I think the only things missing are the .secidx relocation, which is
+ needed for PDBs, and the SEH pseudos used for C++ exceptions.
+
+ This first patch fixes the size of RELSZ; I'm not sure why it was 14 in
+ the first place. This is the size of the "Base Relocation Block" in
+ https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and
+ AFAIK should be 10 for everything.
+
+2023-01-10 Rohr, Stephan <stephan.rohr@intel.com>
+
+ gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.
+ The 'rw_pieced_value' function is executed when fetching a (lazy)
+ variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The
+ function checks the 'type' and 'enclosing_type' fields of the value
+ for identity.
+
+ * The 'type' field describes the type of a value.
+ * In most cases, the 'enclosing_type' field is identical to the
+ 'type' field.
+ * Scenarios where the 'type' and 'enclosing_type' of an object
+ differ are described in 'gdb/value.c'. Possible cases are:
+ * If a value represents a C++ object, then the 'type' field
+ gives the object's compile-time type. If the object actually
+ belongs to some class derived from `type', perhaps with other
+ base classes and additional members, then `type' is just a
+ subobject of the real thing, and the full object is probably
+ larger than `type' would suggest.
+ * If 'type' is a dynamic class (i.e. one with a vtable), then GDB
+ can actually determine the object's run-time type by looking at
+ the run-time type information in the vtable. GDB may then elect
+ to read the entire object.
+ * If the user casts a variable to a different type
+ (e.g. 'print (<type> []) <variable>'), the value's type is
+ updated before reading the value.
+
+ If a lazy value is fetched, GDB allocates space based on the enclosing
+ type's length and typically reads the 'full' object. This is not
+ implemented for pieced values and causes an internal error if 'type'
+ and 'enclosing_type' of a value are not identical.
+
+ However, GDB can read the value based on its type. Thus, this patch
+ fixes the previously mentioned cases by removing the check for identity.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605
+
+ gdb/ChangeLog:
+ 2022-04-13 Stephan Rohr <stephan.rohr@intel.com>
+
+ * dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and
+ 'enlcosing_type' when reading pieced value 'v'.
+
+ gdb/testsuite/ChangeLog:
+ 2022-04-13 Stephan Rohr <stephan.rohr@intel.com>
+
+ * gdb.dwarf2/shortpiece.exp: Added test cases.
+
+2023-01-10 Tom Tromey <tromey@adacore.com>
+
+ Convert say_where to method on code_breakpoint
+ 'say_where' is only useful (and only called for) code breakpoints, so
+ convert it to be a protected method on code_breakpoint.
+
+2023-01-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/doc: use @value{GDBP} in some spots
+ Examples are supposed to use @value{GDBP} instead of the literal "(gdb)"
+ (many of them already do). Update a bunch of spots where it wasn't the
+ case.
+
+ Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d
+
+2023-01-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/doc: use @value{GDBN} in some spots
+ Change some spots to use "@value{GDBN}" instead of just "GDB".
+
+ Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e
+
+2023-01-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/doc: some whitespace fixes
+ For consistency, replace tabs with spaces in all gdb.texinfo menus.
+
+ Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce
+
+2023-01-10 Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>
+
+ IBM zSystems: Fix offset relative to static TLS
+ For local exec TLS relocations of the form foo@NTPOFF+x the addend was
+ ignored.
+
+ bfd/ChangeLog:
+
+ * elf32-s390.c (elf_s390_relocate_section): Honor addend for
+ R_390_TLS_LE32.
+ * elf64-s390.c (elf_s390_relocate_section): Honor addend for
+ R_390_TLS_LE64.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-s390/reloctlsle-1.d: New test.
+ * testsuite/ld-s390/reloctlsle-1.s: New test.
+
+2023-01-10 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi>
+
+ PR 29981 references to init.texi
+
+2023-01-10 Alan Modra <amodra@gmail.com>
+
+ Re: Move bfd_init to bfd.c
+ Commit b1c95bc4dd73 resulted in
+ ...bfd.texi:246: @include: could not find init.texi
+ which went unnoticed due to not building in a clean directory.
+
+ This fixes the problem by moving bfd_init earlier, giving it a
+ doc node, and stitching the nodes back together.
+
+ * bfd.c (bfd_init): Move earlier. Give it a doc inode.
+ Adjust other inodes to suit.
+ * doc/bfd.texi: Don't include init.texi. Adjust nodes to suit.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: disable recursive make in (most) subdirs
+ Now that all (other than ppc) build in the top-level, we can disable
+ the recursive make calls to them. This speeds things up nicely.
+
+ sim: common: move test-hw-events to top-level build
+ This is an internal developer target that isn't normally compiled,
+ but it can still be occasionally useful. Move it to the top-level
+ build so we can kill off common/Make-common.in.
+
+ sim: move arch-specific file compilation of common/ files to top-level
+
+ sim: v850: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: sh: move arch-specific file compilation to top-level
+
+ sim: rx: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: rl78: move arch-specific file compilation to top-level
+
+ sim: riscv: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: pru: move arch-specific file compilation to top-level
+
+ sim: or1k: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: msp430: move arch-specific file compilation to top-level
+
+ sim: moxie: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: mn10300: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: mips: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: microblaze: move arch-specific file compilation to top-level
+
+ sim: mcore: move arch-specific file compilation to top-level
+
+ sim: m68hc11: move arch-specific file compilation to top-level
+ The arch-specific compiler flags are duplicated, but they'll be cleaned
+ up once we move all subdir compiles to the top-level.
+
+ sim: m32r: move arch-specific file compilation to top-level
+
+ sim: m32c: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: lm32: move arch-specific file compilation to top-level
+
+ sim: iq2000: move arch-specific file compilation to top-level
+
+ sim: h8300: move arch-specific file compilation to top-level
+
+ sim: ft32: move arch-specific file compilation to top-level
+
+ sim: frv: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: example-synacor: move arch-specific file compilation to top-level
+
+ sim: erc32: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: d10v: move arch-specific file compilation to top-level
+
+ sim: cris: move arch-specific file compilation to top-level
+
+ sim: cr16: move arch-specific file compilation to top-level
+
+ sim: bfin: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: bpf: move arch-specific file compilation to top-level
+ We can drop the arch-specific rules from the subdir as they're no
+ longer used.
+
+ sim: avr: move arch-specific file compilation to top-level
+
+ sim: arm: move arch-specific file compilation to top-level
+ The arch-specific flags are only used by the arch-specific modules,
+ not the common/ files, so we can delete them too.
+
+ sim: aarch64: move arch-specific file compilation to top-level
+
+ sim: build: add basic framework for compiling arch objects in top-level
+ The code so far has been assuming that we only compile common/ objects.
+ Now that we're ready to compile arch-specific objects, refactor some of
+ the flags & checks a bit to support both.
+
+ sim: modules.c: move generation to top-level
+ Now that all arches create libsim.a from the top-level, we have full
+ access to their inputs, and can move the actual generation from the
+ subdir up to the top-level. This avoids recursive makes and will
+ help simplify state passing between the two.
+
+ sim: build: drop common/nrun.o subdir hack
+ Now that all the subdirs handle their own builds, we can drop this
+ common rule as it's unused, and we don't want to use it anymore.
+
+ sim: build: drop support for creating libsim.a in subdirs
+ Now that all ports have moved to creating libsim.a in the top-level,
+ drop all the support code to create it in a subdir.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: rx: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: rl78: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: riscv: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: pru: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: or1k: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: msp430: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: moxie: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mn10300: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+ The mips code is a little more tricky than others because, for multi-run
+ targets, it generates the list of sources & objects on the fly in the
+ configure script.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: microblaze: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mcore: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m68hc11: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32c: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: lm32: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: iq2000: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: h8300: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ft32: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: frv: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: example-synacor: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: erc32: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: d10v: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cr16: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bpf: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bfin: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: avr: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: arm: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: aarch64: move libsim.a creation to top-level
+ The objects are still compiled in the subdir, but the creation of the
+ archive itself is in the top-level. This is a required step before we
+ can move compilation itself up, and makes it easier to review.
+
+ The downside is that each object compile is a recursive make instead of
+ a single one. On my 4 core system, it adds ~100msec to the build per
+ port, so it's not great, but it shouldn't be a big deal. This will go
+ away of course once the top-level compiles objects.
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: drop support for subdir extra deps
+ Nothing uses this hook anymore, so punt it. It was largely used to
+ track generated files (which we do in the top-level now) and extra
+ header files (which we use automake depgen for now).
+
+2023-01-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: modules: trigger generation from top-level
+ Add rules for tracking generated subdir modules.c files. This doesn't
+ actually generate the file from the top-level, but allows us to add
+ rules that need to be ordered wrt it. Once those changes land, we can
+ rework this to actually generate from the top-level.
+
+ This currently builds off of the objects that go into the libsim.a as
+ we don't build those from the top-level either. Once we migrate that
+ up, we can switch this to the source files directly. It's a bit hacky
+ overall, but makes it easier to migrate things in smaller chunks, and
+ we aren't going to keep this logic long term.
+
+2023-01-10 Aaron Merey <amerey@redhat.com>
+
+ gdb/linespec.c: Fix missing source file during breakpoint re-set
+ During breakpoint re-setting, the source_filename of an
+ explicit_location_spec is used to lookup the symtabs associated with
+ the breakpoint being re-set. This source_filename is compared with each
+ known symtab filename in order to retrieve the breakpoint's symtabs.
+
+ However the source_filename may have been originally copied from a
+ symtab's fullname (the path where GDB found the source file) when the
+ breakpoint was first created. If a breakpoint symtab's filename and
+ fullname differ and there is no substitute-path rule that converts the
+ fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
+ during re-setting.
+
+ Fix this by using a symtab's filename to set the explicit_location_spec
+ source_filename instead of the symtab's fullname.
+
+2023-01-10 Aaron Merey <amerey@redhat.com>
+
+ gdb/linespec.c: Fix -Wmaybe-uninitialized warning
+ Although the bool want_start_sal isn't actually used without being assigned
+ a value, initialize it to be false in order to prevent the following
+ -Wmaybe-uninitialized warning:
+
+ linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
+ linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
+ 4150 | if (is_function && want_start_sal)
+
+2023-01-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-09 Alan Modra <amodra@gmail.com>
+
+ Set dwarf2 stash pointer earlier
+ This fixes a memory leak in the vanishingly rare cases (found by
+ fuzzers of course) when something goes wrong in the save_section_vma,
+ htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
+ If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
+ to free that memory.
+
+ * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
+ on setting up stash.
+
+2023-01-09 Alan Modra <amodra@gmail.com>
+
+ peXXigen.c sanity checks
+ Also fix a memory leak, and make some style changes. I tend to read
+ (sizeof * x) as a multiplication of two variables, which I would not
+ do if binutils followed the gcc coding conventions consistently (see
+ https://gcc.gnu.org/codingconventions.html#Expressions). (sizeof *x)
+ looks a lot better to me, or even (sizeof (*x)) which I've used here.
+
+ * peXXigen.c (get_contents_sanity_check): New function.
+ (pe_print_idata): Use it here..
+ (pe_print_edata): ..and here. Free data on error return.
+ (rsrc_parse_entry): Check entry size read from file.
+ (rsrc_parse_entries): Style fixes.
+ (rsrc_process_section): Use bfd_malloc_and_get_section.
+ (_bfd_XXi_final_link_postscript): Likewise.
+
+2023-01-09 Alan Modra <amodra@gmail.com>
+
+ Move mips_refhi_list to bfd tdata
+ Similar to commit c799eddb3512, but for mips-ecoff. mips-ecoff is
+ marked obsolete, but we still allow reading of these object files in
+ a number of mips targets.
+
+ * coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
+ (mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
+ in ecoff_data.
+ * ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
+ * libecoff.h (struct mips_hi): Moved from coff-mips.c.
+ (struct ecoff_tdata): Add mips_refhi_list.
+ (_bfd_ecoff_close_and_cleanup): Declare.
+
+2023-01-09 Alan Modra <amodra@gmail.com>
+
+ Move bfd_init to bfd.c
+ init.c contains just one function that doesn't do much. Move it to
+ bfd.c and give it something to do, initialising static state. So far
+ the only initialisation is for bfd.c static variables.
+
+ The idea behind reinitialising state is to see whether some set of
+ flaky oss-fuzz crashes go away. oss-fuzz stresses binutils in ways
+ that can't occur in reality, feeding multiple testcases into the
+ internals of binutils. So one testcase may affect the result of the
+ next testcase.
+
+ * init.c: Delete file. Move bfd_init to..
+ * bfd.c (bfd_init): ..here. Init static variables.
+ * Makefile.am (BFD32_LIBS): Remove init.lo.
+ (BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c.
+ * doc/local.mk: Remove mention of init.texi and init.c.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Regenerate.
+ * po/SRC-POTFILES.in: Regenerate.
+
+2023-01-09 Tom Tromey <tom@tromey.com>
+
+ Fix crash with C++ qualified names
+ PR c++/29503 points out that something like "b->Base::member" will
+ crash when 'b' does not have pointer type. This seems to be a simple
+ oversight in eval_op_member.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-09 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/doc: fix @code{GDBN} -> @value{GDBN}
+ Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e
+
+2023-01-09 Christophe Lyon <christophe.lyon@arm.com>
+
+ Skip ld/pr23169 test on arm.
+ The test is already skipped on several targets (including AArch64)
+ because it's invalid.
+
+ * testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.
+
+2023-01-09 Christophe Lyon <christophe.lyon@arm.com>
+
+ Fix PR18841 ifunc relocation ordering
+ In order to get the ifunc relocs properly sorted the correct class
+ needs to be returned. The code mimics what has been done for AArch64.
+
+ Fixes:
+ FAIL: Run pr18841 with libpr18841b.so
+ FAIL: Run pr18841 with libpr18841c.so
+ FAIL: Run pr18841 with libpr18841bn.so (-z now)
+ FAIL: Run pr18841 with libpr18841cn.so (-z now)
+
+ bfd/
+ PR ld/18841
+ * elf32-arm.c (elf32_arm_reloc_type_class): Return
+ reloc_class_ifunc for ifunc symbols.
+
+ ld/testsuite/
+ * ld-arm/ifunc-12.rd: Update relocations order.
+ * ld-arm/ifunc-3.rd: Likewise.
+ * ld-arm/ifunc-4.rd: Likewise.
+
+2023-01-09 Nick Clifton <nickc@redhat.com>
+
+ Updated transaltions for the gprof and binutils sub-directories
+
+2023-01-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ testsuite: add -O0 to Intel compilers if no 'optimize' option is given
+ icpx/icx give the following warning if '-g' is used without '-O'.
+
+ icpx: remark: Note that use of '-g' without any optimization-level
+ option will turn off most compiler optimizations similar to use of
+ '-O0'; use '-Rno-debug-disables-optimization' to disable this
+ remark [-Rdebug-disables-optimization]
+
+ The warning makes dejagnu think that compilation has failed. E.g.:
+
+ $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
+ ...
+ gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]
+
+ === gdb Summary ===
+
+ # of untested testcases 1
+
+ Furthermore, if no -O flag is passed, icx/icc optimize
+ the code by default. This breaks assumptions in many GDB tests
+ that the code is unoptimized by default. E.g.:
+
+ $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
+ ...
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
+ FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()
+
+ === gdb Summary ===
+
+ # of expected passes 1
+ # of unexpected failures 9
+
+ To fix both problems, pass the -O0 flag explicitly, if no optimization
+ option is given.
+
+ With this patch we get, e.g.:
+
+ $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
+ ...
+ === gdb Summary ===
+
+ # of expected passes 19
+ # of known failures 1
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-01-09 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite: handle icc and icpc deprecated remarks
+ Starting with icc/icpc version 2021.7.0 and higher both compilers emit a
+ deprecation remark when used. E.g.
+
+ >> icc --version
+ icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
+ deprecated and will be removed from product release in the second half
+ of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended
+ compiler moving forward. Please transition to use this compiler. Use
+ '-diag-disable=10441' to disable this message.
+ icc (ICC) 2021.7.0 20220713
+ Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
+
+ >> icpc --version
+ icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
+ deprecated ...
+ icpc (ICC) 2021.7.0 20220720
+ Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
+
+ As the testsuite compile fails when unexpected output by the compiler is
+ seen this change in the compiler breaks all existing icc and icpc tests.
+ This patch makes the gdb testsuite more forgiving by a) allowing the
+ output of the remark when trying to figure out the compiler version
+ and by b) adding '-diag-disable=10441' to the compile command whenever
+ gdb_compile is called without the intention to detect the compiler.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2023-01-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-08 Alan Modra <amodra@gmail.com>
+
+ PR29972, inconsistent format specification in singular form
+ PR 29972
+ * readelf.c (process_dynamic_section): Correct format string.
+
+2023-01-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants
+ An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT
+ constants. These constants are used (by gas and libsframe) to pick an
+ SFrame FRE type based on the function size. Those constants, however,
+ were buggy, causing the generated SFrame sections to be bloated as
+ SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than
+ necessary.
+
+ gas/
+ * sframe-opt.c (sframe_estimate_size_before_relax): Use
+ typecast.
+ (sframe_convert_frag): Likewise.
+
+ libsframe/
+ * sframe.c (sframe_calc_fre_type): Use a more appropriate type
+ for argument. Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT
+ to keep it warning-free but meaningful.
+
+ include/
+ * sframe-api.h (sframe_calc_fre_type): Use a more appropriate
+ type for the argument.
+ * sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant.
+ (SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
+ (SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.
+
+2023-01-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: adjust an incorrect check in flip_sframe
+ When sframe_encoder_write needs to flip the buffer containing the SFrame
+ section before writing, it is not necessary that the SFrame FDES are in
+ the order of their sfde_func_start_fre_off. On the contrary, SFrame
+ FDEs will be sorted in the order of their start address. So, remove
+ this incorrect assumption which is basically assuming that the last
+ sfde_func_start_fre_off seen will help determine the end of the flipped
+ buffer.
+
+ The function now keeps track of the bytes_flipped and then compares it with
+ the expected value. Also, added two more checks at appropriate places:
+ - check that the SFrame FDE read is within bounds
+ - check that the SFrame FRE read is within bounds
+
+ libsframe/
+
+ * sframe.c (flip_sframe): Adjust an incorrect check.
+ Add other checks to ensure reads are within the buffer size.
+
+2023-01-06 Jan Beulich <jbeulich@suse.com>
+
+ ld: yet another PDB build fix (or workaround)
+ Older bash looks to improperly deal with backslashes in here-documents,
+ leaving them in place on the escaped double quotes inside the parameter
+ expansion. Convert to a model without using such a construct, by simply
+ splitting the here-documents into three ones.
+
+2023-01-06 Nick Clifton <nickc@redhat.com>
+
+ Updated Bulgarian and Russian translations for LD and BFD respectively
+
+2023-01-06 Alan Modra <amodra@gmail.com>
+
+ Fix an aout memory leak
+ * aoutx.h (aout_bfd_free_cached_info): Free line_buf.
+
+ Tidy pe flag in coff_data
+ Make it a bool, use obj_pe accessor everywhere.
+
+2023-01-06 Alan Modra <amodra@gmail.com>
+
+ Make coff backend data read-only
+ The bfd_coff_backend_data struct should be read-only, the only thing
+ preventing this is that objcopy writes to one of the fields,
+ _bfd_coff_long_section_names. This patch creates a copy of the field
+ in bfd coff_obj_tdata, which makes more sense anyway. When enabling
+ long section names the intent is to do so for a particular bfd, not
+ for all bfds that might happen to be using the target xvec.
+
+ bfd/
+ * coffcode.h: Update coff long section name comment.
+ (bfd_coff_set_long_section_names_allowed): Use macro accessor
+ to set flag.
+ (bfd_coff_set_long_section_names_disallowed): Tidy.
+ (coff_backend_info): Return a const pointer.
+ (bfd_coff_std_swap_table, ticoff0_swap_table, ticoff1_swap_table),
+ (bigobj_swap_table): Make const.
+ (bfd_coff_long_section_names): Use tdata copy.
+ (coff_mkobject): Set long_section_names from coff_backend_info.
+ * coff-go32.c (_bfd_go32_mkobject): Likewise.
+ * peicode.h (pe_mkobject): Likewise.
+ * coff-sh.c (bfd_coff_small_swap_table): Make const.
+ * libcoff-in.h (struct coff_tdata): Add long_section_names,
+ reorder fields.
+ * libcoff.h: Regenerate.
+ binutils/
+ * objcopy.c (set_long_section_mode): Move earlier in file.
+ (copy_object): Call set_long_section_mode here, after setting
+ output format.
+ (copy_file): Don't call set_long_section_mode.
+
+2023-01-06 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/c++: Detect ambiguous variables in imported namespaces
+ When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB
+ to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB
+ will print M::x, and using clang 16.0.0 prints N::x. Not only is this
+ behavior confusing to users, it is also not consistent with compiler
+ behaviors, which would warn that using x is ambiguous at this point.
+
+ This commit makes GDB behavior consistent with compilers. it achieves
+ this by making it so instead of exiting early when finding any symbol
+ with the correct name, GDB continues searching through all include
+ directives, storing all matching symbols in a relational map betwen the
+ mangled name and the found symbols.
+
+ If the resulting map has more than one entry, GDB says that the
+ reference is ambiguous and lists all possibilities. Otherwise it returns
+ the block_symbol structure for the desired symbol, or an empty struct if
+ nothing was found.
+
+ The commit also changes gdb.cp/nsusing.exp to test the ambiguous
+ detection.
+
+2023-01-06 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/mi: add no-history stop reason
+ When executing in reverse and runs out of recorded history, GDB prints
+ a warning to the user, but does not add a reason in the stopped record,
+ for example:
+
+ *stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"
+
+ This problem was reported as record/29260.
+
+ This commit adds the reason no-history to the record, making it easier
+ for interfaces using the mi interpreter to report the result. It also
+ changes the test gdb.mi/mi-reverse.exp to test that the reason shows up
+ correctly.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260
+
+2023-01-06 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clang
+ When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99
+ unexpected failures. They all fail to produce a complete list of
+ completion options for a function, either overload2_function,
+ overload3_function or anon_ns_function. This happens because clang is
+ optimizing them away, since they are never used.
+
+ Fix this by adding __attribute__((used)) to all declarations to the
+ aforementioned functions.
+
+2023-01-06 Clément Chigot <chigot@adacore.com>
+
+ configure: remove dependencies on gmp and mpfr when gdb is disabled
+ Since 991180627851801f1999d1ebbc0e569a17e47c74, the configure checks
+ about GMP and MPFR for gdb builds have been moved to the toplevel
+ configure.
+ However, it doesn't take into account the --disable-gdb option. Meaning
+ that a build without gdb will require these libraries even if not
+ needed.
+
+ ChangeLog:
+
+ * configure.ac: Skip GMP and MPFR when --disable-gdb is
+ provided.
+ * configure: Regenerate.
+
+2023-01-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: fix scoped_debug_start_end's move constructor
+ I spotted a problem with scoped_debug_start_end's move constructor.
+ When constructing a scoped_debug_start_end through it, it doesn't
+ disable the moved-from object, meaning there are now two objects that
+ will do the side-effects of decrementing the debug_print_depth global
+ and printing the "end" message. Decrementing the debug_print_depth
+ global twice is actually problematic, because the increments and
+ decrements get out of sync, meaning we should hit this assertion, in
+ theory:
+
+ gdb_assert (debug_print_depth > 0);
+
+ However, in practice, we don't see that. This is because despite the
+ move constructor being required for this to compile:
+
+ template<typename PT>
+ static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7)
+ make_scoped_debug_start_end (PT &&pred, const char *module, const char *func,
+ const char *start_prefix,
+ const char *end_prefix, const char *fmt, ...)
+ {
+ va_list args;
+ va_start (args, fmt);
+ auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix,
+ end_prefix, fmt, args);
+ va_end (args);
+
+ return res;
+ }
+
+ ... it is never actually called, because compilers elide the move
+ constructors all the way (the scoped_debug_start_end gets constructed
+ directly in the instance of the top-level caller). To confirm this, I
+ built GDB with -fno-elide-constructors, and now I see it:
+
+ /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed.
+
+ #9 0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58
+ #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147
+ #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235
+
+ Fix this by adding an m_disabled field to scoped_debug_start_end, and
+ setting it in the move constructor.
+
+ Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f
+
+2023-01-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add gdb::string_view_hash
+ Add the string_view_hash type, which will be useful to be able to use
+ gdb::string_view as std::unordered_map keys.
+
+ Use it in gdb/symtab.c, to exercise it.
+
+ Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-01-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: move fast_hash to gdbsupport/common-utils.h
+ The following patch adds a hash type for gdb::string_view in gdbsupport,
+ which will use the fast_hash function. Move the latter to gdbsupport.
+
+ Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-01-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: move libxxhash configure check to gdbsupport
+ The following patch moves the fast_hash function, which uses libxxhash,
+ to gdbsupport. Move the libxxhash configure check to gdbsupport (and
+ transitively to gdbserver).
+
+ Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-01-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make gdbarch_alloc take ownership of the tdep
+ It's currently not clear how the ownership of gdbarch_tdep objects
+ works. In fact, nothing ever takes ownership of it. This is mostly
+ fine because we never free gdbarch objects, and thus we never free
+ gdbarch_tdep objects. There is an exception to that however: when
+ initialization fails, we do free the gdbarch object that is not going to
+ be used, and we free the tdep too. Currently, i386 and s390 do it.
+
+ To make things clearer, change gdbarch_alloc so that it takes ownership
+ of the tdep. The tdep is thus automatically freed if the gdbarch is
+ freed.
+
+ Change all gdbarch initialization functions to pass a new gdbarch_tdep
+ object to gdbarch_alloc and then retrieve a non-owning reference from
+ the gdbarch object.
+
+ Before this patch, the xtensa architecture had a single global instance
+ of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated
+ gdbarch_tdep_base instance to gdbarch_alloc, remove this global
+ instance, and dynamically allocate one as needed, like we do for all
+ other architectures. Make the `rmap` array externally visible and
+ rename it to the less collision-prone `xtensa_rmap` name.
+
+ Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2023-01-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: add back needed -re clause in gdb_breakpoint
+ Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused,
+ amongst others:
+
+ (gdb) break 1^M
+ No line 1 in the current file.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1
+ FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set
+
+ This is because it removed one empty -re clause (matching just the
+ prompt) that is necessary after replying "n" to the pending breakpoint
+ question. Add this clause back.
+
+ Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2023-01-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Avoid queue.SimpleQueue for python 3.6
+ On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case
+ fails as follows:
+ ...
+ ERROR: eof reading json header
+ while executing
+ "error "eof reading json header""
+ invoked from within
+ "expect {
+ -i exp19 -timeout 10
+ -re "^Content-Length: (\[0-9\]+)\r\n" {
+ set length $expect_out(1,string)
+ exp_continue
+ }
+ -re "^(\[^\r\n\]+)..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE eof reading json header
+ UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize
+ ...
+
+ Investigation using a "catch throw" shows that:
+ ...
+ (gdb)
+ at gdb/python/py-utils.c:396
+ 396 error (_("Error occurred in Python: %s"), msg.get ());
+ (gdb) p msg.get ()
+ $1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'"
+ ...
+
+ The python class queue.SimpleQueue was introduced in python 3.7.
+
+ Fix this by falling back to queue.Queue for python <= 3.6.
+
+ Tested on x86_64-linux, by successfully running the test-case:
+ ...
+ # of expected passes 47
+ ...
+
+2023-01-05 Tom Tromey <tromey@adacore.com>
+
+ Add type to expression dump of symbol
+ I recently had cause to dump some expressions from gdb. I got output
+ like this:
+
+ Operation: BINOP_GTR
+ Operation: OP_VAR_VALUE
+ Block symbol:
+ Symbol: small_value
+ Block: 0x39b4c20
+ Operation: OP_LONG
+ Operation: OP_LONG
+ Type: int
+ Constant: 0x0000000000000014
+
+ This is ok, but it would have been handy to see the type of the
+ symbol. This patch adds this information.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2023-01-05 Nick Clifton <nickc@redhat.com>
+
+ Remove Stephen Casner as the PDP11 maintainer.
+
+ Add an extra emulation called arm64pe to the aarch64pe emulation.
+
+2023-01-05 Andreas K. Huettel <dilfridge@gentoo.org>
+
+ Un xfail the PR19719 test for the AArch64 architecture
+
+2023-01-05 Nick Clifton <nickc@redhat.com>
+
+ Updated Bulgarian and Russian translations for the gprof subdirectory
+
+2023-01-05 Paul Koning <paulkoning@comcast.net>
+
+ PR29963, PDP11 link produces spurious relocation truncated messages
+ PDP11 is a 16-bit processor with 16-bit logical addresses. Therefore
+ wrapping should be allowed on the 16-bit relocs, and may as well be
+ allowed for the 32-bit reloc too.
+
+ PR 29963
+ * pdp11.c (howto_table_pdp11): Use complain_overflow_dont.
+
+2023-01-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: add multi source to built sources
+ The multirun generation mode is a bit of a mess as generated run files
+ depend on generate igen files, all with unknown names ahead of time.
+ In the multirun mode, be lazy and declare all of these generated source
+ files as built sources so they'll be created early on.
+
+2023-01-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Move getopt checking inside SIM_AC_PLATFORM
+ This commit moves getopt declaration checker originally in sim/
+ configure.ac; added in commit 340aa4f6872c ("sim: Check known getopt
+ definition existence") to sim/m4/sim_ac_platform.m4 (inside the
+ SIM_AC_PLATFORM macro).
+
+ It also regenerates configuration files using the maintainer mode.
+
+2023-01-05 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ sim: bpf: fix testsuite due to linker warnings [PR sim/29954]
+ On a bpf-*-* testsuite fails:
+ ./ld/ld-new: warning: test has a LOAD segment with RWX permissions
+
+ Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes.
+
+ Tested on bpf-*-*:
+
+ Bug: https://sourceware.org/PR29954
+
+ sim/testsuite:
+ * bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags.
+
+2023-01-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-04 Indu Bhagat <indu.bhagat@oracle.com>
+
+ MAINTAINERS: add myself as maintainer of libsframe
+ binutils/
+ * MAINTAINERS: Add myself as maintainer of libsframe.
+
+2023-01-04 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Remove duplicated I386_PCREL_TYPE_P/X86_64_PCREL_TYPE_P
+ I386_PCREL_TYPE_P and X86_64_PCREL_TYPE_P are defined twice. Remove
+ the duplications.
+
+ * elfxx-x86.h (I386_PCREL_TYPE_P): Remove duplication.
+ (X86_64_PCREL_TYPE_P): Likewise.
+
+2023-01-04 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: ensure test_name is initialized in gdb_breakpoint
+ A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in
+ gdb_breakpoint) left the $test_name variable undefined.
+
+ This patch fixes this.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2023-01-04 Tom Tromey <tromey@adacore.com>
+
+ Use first_opcode in another spot
+ I found one place that could use expression::first_opcode.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-01-04 Tom Tromey <tromey@adacore.com>
+
+ Convert exp_uses_objfile to a method of expression
+ This changes the exp_uses_objfile function to be a method of
+ 'expression'.
+
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-01-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use gdb_test_multiple in gdb_breakpoint
+ When running the testsuite in a non-optimized build on a slow machine, I
+ sometimes get:
+
+ UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase.
+
+ do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor
+ 10`, to account for the fact that reading the debug info of the gdb
+ binary (especially in a non-optimized GDB) can take time. But then it
+ ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded
+ timeout of 30 seconds.
+
+ Fix this by making gdb_breakpoint use gdb_test_multiple, which is a
+ desired change anyway for this kind of simple command / expected
+ output case.
+
+ Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75
+ Reviewed-By: Lancelot Six <lancelot.six@amd.com>
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ Re: Avoid unaligned pointer reads in PEP .idata section
+ Fix testsuite fallout.
+
+ * testsuite/ld-pe/cfi.d: Adjust for changed .idata padding.
+ * testsuite/ld-pe/secidx_64.d: Likewise.
+ * testsuite/ld-pe/secrel_64.d: Likewise.
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ objcopy fuzzed pe out of memory
+ This occurs when attempting to read back a section from the output
+ file in _bfd_XX_bfd_copy_private_bfd_data_common. The copy of the
+ section failed size sanity checking, thus it won't be written.
+
+ * objcopy.c (copy_object): Return false if copy_section or
+ copy_relocations_in_section fails.
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ fuzzed file timeout
+ objcopy of archive, element containing an object with a fuzzed section
+ size far exceeding the element size. copy_section detects this, but
+ the temp file is laid out for the large section. It can take a long
+ time to write terabytes of sparse file, a waste of time when it will
+ be deleted.
+
+ * objcopy.c (copy_archive): Don't write element contents after
+ bad status result from copy_object.
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ asan: segv in parse_module
+ * vms-alpha.c (parse_module): Ignore DST__K_SRC_SETFILE data
+ if out of range.
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ addr2line out of memory on fuzzed file
+ Another case of fuzzers finding the section size sanity checks are
+ avoided with SHT_NOBITS sections.
+
+ * dwarf2.c (read_section): Check that the DWARF section being
+ read has contents.
+
+2023-01-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix some #ifdef logic in bt-utils.h
+ In passing I spotted some incorrect #ifdef logic in bt-utils.h. The
+ logic in question has existed since the file was originally added in
+ commit:
+
+ commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
+ Date: Wed Aug 11 13:24:33 2021 +0100
+
+ gdb: use libbacktrace to create a better backtrace for fatal signals
+
+ The code is trying to select between using libbacktrace or using the
+ execinfo supplied backtrace API.
+
+ First we check to see if we can use libbacktrace. If we can then we
+ include some header files, and then set some defines to indicate that
+ libbacktrace is being used.
+
+ Then we check if execinfo is available, if it is then we include
+ <execinfo.h> and set some alternative defines.
+
+ In theory the second block of logic should not trigger if the first
+ block (that uses libbacktrace) has also triggered, but we incorrectly
+ check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking
+ for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second
+ block triggers more than it should. The
+ 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this
+ was a mistake in the original commit.
+
+ In reality this is harmless, we include <execinfo.h> when we don't
+ need too, but in by-utils.c the libbacktrace define is always checked
+ for before the execinfo define, so we never actually end up using the
+ execinfo path (when libbacktrace is available). But I figure its
+ still worth cleaning this up.
+
+ I've tested GDB in a "default" build where libbacktrace is used, and
+ when configuring with --disable-libbacktrace which causes the execinfo
+ backtrace API to be used instead, both still appear to work fine.
+
+ There should be no user visible changes after this commit.
+
+2023-01-04 Bruno Larsen <blarsen@redhat.com>
+
+ gdb: add 'maintenance print record-instruction' command
+ While chasing some reverse debugging bugs, I found myself wondering what
+ was recorded by GDB to undo and redo a certain instruction. This commit
+ implements a simple way of printing that information.
+
+ If there isn't enough history to print the desired instruction (such as
+ when the user hasn't started recording yet or when they request 2
+ instructions back but only 1 was recorded), GDB warns the user like so:
+
+ (gdb) maint print record-instruction
+ Not enough recorded history
+
+ If there is enough, GDB prints the instruction like so:
+
+ (gdb) maint print record-instruction
+ 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00
+ Register eflags changed: [ IF ]
+ Register rip changed: (void (*)()) 0x401115 <main+15>
+
+ Approved-by: Eli Zaretskii <eliz@gnu.org>
+ Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com>
+ Reviewed-by: Lancelot Six <lsix@lancelotsix.com>
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2023-01-04 Andreas K. Huettel <dilfridge@gentoo.org>
+
+ Fix AArch64 linker testsuite failures trigeered by differences in build environments.
+ PR 29843
+ * testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow
+ for differences in build environments.
+ * testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise.
+
+2023-01-04 Mark Harmstone <mark@harmstone.com>
+
+ Avoid unaligned pointer reads in PEP .idata section
+ This is something I discovered when working on aarch64, though it's
+ relevant to x86_64 too.
+
+ The PE32+ imports are located in the .idata section, which starts off
+ with a 20-byte structure for each DLL, containing offsets into the rest
+ of the section. This is the Import Directory Table in
+ https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, which
+ is a concatenation of the .idata$2 sections. This is then followed by an
+ 20 zero bytes generated by the linker script, which calls this .idata$3.
+
+ After this comes the .idata$4 entries for each function, which the
+ loader overwrites with the function pointers. Because there's no padding
+ between .idata$3 and .idata$4, this means that if there's an even number
+ of DLLs, the function pointers won't be aligned on an 8-byte boundary.
+
+ Misaligned reads are slower on x86_64, but this is more important on
+ aarch64, as the e.g. `ldr x0, [x0, :lo12:__imp__func]` the compiler
+ might generate requires __imp__func (the .idata$4 entry) to be aligned
+ to 8 bytes. Without this you get IMAGE_REL_ARM64_PAGEOFFSET_12L overflow
+ errors.
+
+2023-01-04 Alan Modra <amodra@gmail.com>
+
+ Merge config/picflag.m4 from gcc
+ and regen libiberty/configure
+
+2023-01-04 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Regenerate using the maintainer mode
+ Those files have changed by regenerating using the maintainer mode.
+ The first line of sim/ppc/pk.h have changed by an effect of the commit
+ 319e41e83a40 ("sim: ppc: inline the sim-packages option").
+
+2023-01-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-03 Max Filippov <jcmvbkbc@gmail.com>
+
+ opcodes: xtensa: fix jump visualization for FLIX
+ opcodes/
+ * xtensa-dis.c (print_insn_xtensa): Add local variables
+ insn_type, target and imm_pcrel to track control flow across
+ multiple slots.
+
+ opcodes: xtensa: implement styled disassembly
+ opcodes/
+ * xtensa-dis.c (print_xtensa_operand)
+ (print_insn_xtensa): Replace fprintf_func with
+ fprintf_styled_func.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Add test case for "finish" with variably-sized types
+ This adds a test case for "finish" with variably-sized types, and for
+ inferior calls as well. This also extends the "runto" proc to handle
+ temporary breakpoints.
+
+ Use value_at_non_lval in get_call_return_value
+ get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION,
+ because the call is completely managed by gdb. However, it does not
+ handle variably-sized types correctly. The simplest way to fix this
+ is to use value_at_non_lval, which does type resolution.
+
+ Fix inferior calls with variably-sized return type
+ This patch updates the gdbarch_return_value_as_value implementations
+ to work correctly with variably-sized return types.
+
+ Convert selected architectures to gdbarch_return_value_as_value
+ This converts a few selected architectures to use
+ gdbarch_return_value_as_value rather than gdbarch_return_value. The
+ architectures are just the ones that I am able to test. This patch
+ should not introduce any behavior changes.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Don't let property evaluation affect the current language
+ On PPC, we saw that calling an inferior function could sometimes
+ change the current language, because gdb would select the call dummy
+ frame -- associated with _start.
+
+ This patch changes gdb so that the current language is never affected
+ by DWARF property evaluation.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Introduce value_at_non_lval
+ In some cases, while a value might be read from memory, gdb should not
+ record the value as being equivalent to that memory.
+
+ In Ada, the inferior call code will call ada_convert_actual -- and
+ here, if the argument is already in memory, that address will simply
+ be reused. However, for a call like "f(g())", the result of "g" might
+ be on the stack and thus overwritten by the call to "f".
+
+ This patch introduces a new function that is like value_at but that
+ ensures that the result is non-lvalue.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Don't emit gdbarch_return_value
+ The previous patch introduced a new overload of gdbarch_return_value.
+ The intent here is that this new overload always be called by the core
+ of gdb -- the previous implementation is effectively deprecated,
+ because a call to the old-style method will not work with any
+ converted architectures (whereas calling the new-style method is will
+ delegate when needed).
+
+ This patch changes gdbarch.py so that the old gdbarch_return_value
+ wrapper function can be omitted. This will prevent any errors from
+ creeping in.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Add new overload of gdbarch_return_value
+ The gdbarch "return_value" can't correctly handle variably-sized
+ types. The problem here is that the TYPE_LENGTH of such a type is 0,
+ until the type is resolved, which requires reading memory. However,
+ gdbarch_return_value only accepts a buffer as an out parameter.
+
+ Fixing this requires letting the implementation of the gdbarch method
+ resolve the type and return a value -- that is, both the contents and
+ the new type.
+
+ After an attempt at this, I realized I wouldn't be able to correctly
+ update all implementations (there are ~80) of this method. So,
+ instead, this patch adds a new method that falls back to the current
+ method, and it updates gdb to only call the new method. This way it's
+ possible to incrementally convert the architectures that I am able to
+ test.
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in amd64-tdep.c
+ amd64-tdep.c could crash when 'finish'ing from a function whose return
+ type had variable length. In this situation, the value will be passed
+ by reference, and this patch avoids the crash.
+
+ (Note that this does not fully fix the bug reported, but it does fix
+ the crash, so it seems worthwhile to land independently.)
+
+2023-01-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail in gdb.arch/i386-pkru.exp
+ On a x86_64-linux machine with pkru register, I run into:
+ ...
+ (gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
+ info register pkru^M
+ pkru 0x12345678 305419896^M
+ (gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
+ ...
+
+ This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
+ onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356
+ ("x86/fpu: Allow PKRU to be (once again) written by ptrace.").
+
+ The regression occurs for kernel versions v5.14-rc1 (the first tag containing
+ the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).
+
+ Fix this by adding an xfail for the appropriate kernel versions.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/29790
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790
+
+2023-01-03 Tom Tromey <tromey@adacore.com>
+
+ Do not use PyObject_CallNoArgs
+ PyObject_CallNoArgs was introduced in Python 3.9, so avoid it in favor
+ of PyObject_CallObject.
+
+2023-01-03 Himal <himalr@proton.me>
+
+ Fix a potential problem in the BFD library when accessing the Windows' nul device driver.
+ PR 29947
+ * bfdio.c (_bfd_real_fopen): Do not add a prefix to the Windows'
+ nul device filename.
+
+2023-01-03 Nick Clifton <nickc@redhat.com>
+
+ Fix a translation problem in the x86 assembler.
+ PR 29952
+ * config/tc-i386.c (md_assemble): Avoid constructing translatable
+ strings.
+
+ Updated translations for various languages and sub-directories
+
+2023-01-03 Luis Machado <luis.machado@arm.com>
+
+ Add new NT_ARM_ZA and NT_ARM_SSVE register set constants.
+
+2023-01-03 Andrew Burgess <aburgess@redhat.com>
+
+ [gdb] Fix segfault during inferior call to ifunc
+ With a simple test-case:
+ ...
+ $ cat test.c
+ char *p = "a";
+ int main (void) {
+ return strlen (p);
+ }
+ $ gcc -g test.c
+ ...
+ we run into this segfault:
+ ...
+ $ gdb -q -batch a.out -ex start -ex "p strlen (p)"
+ Temporary breakpoint 1 at 0x1151: file test.c, line 4.
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ Temporary breakpoint 1, main () at test.c:4
+ 4 return strlen (p);
+
+ Fatal signal: Segmentation fault
+ ...
+
+ The strlen is an ifunc, and consequently during the call to
+ call_function_by_hand_dummy for "p strlen (p)" another call
+ to call_function_by_hand_dummy is used to resolve the ifunc.
+
+ This invalidates the get_current_frame () result in the outer call.
+
+ Fix this by using prepare_reinflate and reinflate.
+
+ Note that this series (
+ https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ )
+ should address this problem, but this patch is a simpler fix which is easy to
+ backport.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+ PR gdb/29941
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941
+
+2023-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: move some generated source files to built sources
+ This should have been part of the previous commit 80636a54bcfa2bca3dc8f
+ ("sim: build: move generated headers to built sources"), but they were
+ missed because they're .c files effectively treated as .h files.
+
+ sim: build: add var for tracking sim enable directly
+ Rather than rely on SIM_SUBDIRS being set, add a dedicated variable
+ to track whether to enable the sim. While the current code works
+ fine, it won't work as we remove the recursive make logic (i.e. the
+ SIM_SUBDIRS variable).
+
+ sim: common: drop libcommon.a linkage
+ All of these objects should be in libsim.a already, so don't link to
+ it too. In practice it never gets used, but no point in listing it.
+
+2023-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: move generated headers to built sources
+ Automake's automatic header deptracking has a bootstrap problem where
+ it can't detect generated headers when compiling. We've been handling
+ that by adding a custom SIM_ALL_RECURSIVE_DEPS variable, but that only
+ works when building objects recursively in subdirs. As we move those
+ out to the top-level, we don't have any recursive steps anymore. The
+ Automake approach is to declare those headers in BUILT_SOURCES.
+
+ This isn't completely foolproof as the Automake manual documents: it
+ only activates for `make all`, not `make foo.o`, but that shouldn't be
+ a huge limitation as it only affects the initial compile. After that,
+ rebuilds should work fine.
+
+2023-01-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: drop common subdir build rules
+ Now that everything has been hoisted to the top-level, we can delete
+ this unused logic.
+
+ sim: or1k: hoist cgen rules to top-level
+
+ sim: m32r: hoist cgen rules to top-level
+
+ sim: lm32: hoist cgen rules to top-level
+
+ sim: iq2000: hoist cgen rules to top-level
+
+ sim: frv: hoist cgen rules to top-level
+
+ sim: cris: hoist cgen rules to top-level
+
+ sim: bpf: hoist cgen rules to top-level
+
+ sim: cgen: hoist rules to the top-level build
+ The rules seem to generate the same output as existing subdir cgen
+ rules with cgen ports, so hopefully this should be correct. These
+ are the last set of codegen rules that we run in subdirs, so this
+ will help unblock killing off subdir builds entirely.
+
+ sim: build: use Automake include vars
+ Rather than define our own hack for emitting an include statement,
+ use the existing Automake include variables. These have the nice
+ side-effect of being more portable.
+
+2023-01-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-02 Tom Tromey <tromey@adacore.com>
+
+ Simplify debug_exp
+ debug_exp should call expression::dump rather than using the 'op'
+ member.
+
+2023-01-02 Tom Tromey <tromey@adacore.com>
+
+ Initial implementation of Debugger Adapter Protocol
+ The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
+ to communicate with debuggers. You can find more information here:
+
+ https://microsoft.github.io/debug-adapter-protocol/
+
+ Frequently this is implemented as a shim, but it seemed to me that GDB
+ could implement it directly, via the Python API. This patch is the
+ initial implementation.
+
+ DAP is implemented as a new "interp". This is slightly weird, because
+ it doesn't act like an ordinary interpreter -- for example it doesn't
+ implement a command syntax, and doesn't use GDB's ordinary event loop.
+ However, this seemed like the best approach overall.
+
+ To run GDB in this mode, use:
+
+ gdb -i=dap
+
+ The DAP code will accept JSON-RPC messages on stdin and print
+ responses to stdout. GDB redirects the inferior's stdout to a new
+ pipe so that output can be encapsulated by the protocol.
+
+ The Python code uses multiple threads to do its work. Separate
+ threads are used for reading JSON from the client and for writing JSON
+ to the client. All GDB work is done in the main thread. (The first
+ implementation used asyncio, but this had some limitations, and so I
+ rewrote it to use threads instead.)
+
+ This is not a complete implementation of the protocol, but it does
+ implement enough to demonstrate that the overall approach works.
+
+ There is a rudimentary test suite. It uses a JSON parser written in
+ pure Tcl. This parser is under the same license as Tcl itself, so I
+ felt it was acceptable to simply import it into the tree.
+
+ There is also a bit of documentation -- just documenting the new
+ interpreter name.
+
+2023-01-02 Jonas Hoerberg <JHorberg@danfoss.com>
+
+ Fix target remote pipe command for MinGW
+ The cced7cacecad104fff0 ("gdb: preserve `|` in connection details string")
+ commit added '|' detection and removal to ser-pipe.c, but missed to add it
+ to ser-mingw.c.
+
+ This results in the error message below for MinGW hosts:
+ error starting child process '| <executable> <args>': CreateProcess: No such file or directory
+
+ This commit add the missing '|' detection and removal to ser-mingw.c.
+
+2023-01-02 Tom Tromey <tromey@adacore.com>
+
+ Remove target: prefix from gdb_sysroot in find_separate_debug_file
+ I noticed that, when using gdbserver, gdb might print:
+
+ Reading /usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
+ Reading target:/usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
+
+ The second line has the "target:" prefix, but from the code it's clear
+ that this string is being passed verbatim to gdbserver -- which seems
+ wrong.
+
+ I filed PR remote/29929 for this.
+
+ The problem here is that find_separate_debug_file uses gdb_sysroot
+ without checking to see if it starts with the "target:" prefix. This
+ patch changes this code to be a little more careful.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29929
+
+2023-01-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-breakpoint.exp with libstdc++ debug info
+ On x86_64-linux, I run into:
+ ...
+ (gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M
+ Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M
+ (gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \
+ Set hardware breakpoint
+ ...
+ due to libstdc++ debug info:
+ ...
+ $ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \
+ -ex start \
+ -ex "b add" \
+ -ex "info break"
+ Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50.
+
+ Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50
+ 50 int foo = 5;
+ Breakpoint 2 at 0x40072e: add. (7 locations)
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE>
+ 2.1 y 0x000000000040072e in add(int) at \
+ py-breakpoint.c:39
+ 2.2 y 0x00007ffff7b131de in \
+ (anonymous namespace)::fast_float::bigint::add at \
+ ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
+ ...
+ 2.7 y 0x00007ffff7b137e4 in \
+ (anonymous namespace)::fast_float::bigint::add at \
+ ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
+ ...
+
+ Fix this by using qualified=True.
+
+ Tested on x86_64-linux.
+ PR testsuite/29910
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910
+
+2023-01-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: replace -I$srcroot/bfd include with -I$srcroot
+ Clean up includes a bit by making ports include bfd/ headers
+ explicitly. This matches other projects, and makes it more clear
+ where these headers are coming from.
+
+ sim: replace -I$srcroot/opcodes include with -I$srcroot
+ Clean up includes a bit by making ports include opcodes/ headers
+ explicitly. This matches other projects, and makes it more clear
+ where these headers are coming from.
+
+2023-01-02 Alan Modra <amodra@gmail.com>
+
+ obsolete target tidy
+ Delete a few files only used for obsolete targets, and tidy config,
+ xfails and other pieces of support specific to those targets. And
+ since I was editing target triplets in test files, fix the nm
+ alpha-linuxecoff fails.
+
+2023-01-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2023-01-01 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: drop unused SIM_EXTRA_LIBS
+ Now that all run binaries are linked in the topdir, this subdir libs
+ variable isn't used anywhere, so punt it.
+
+ sim: erc32: drop -I$(srcroot)
+ Since the port doesn't actually use this include, drop it.
+ No other port is doing this either.
+
+ sim: drop mention of & support for subdir configure
+ Now that no ports use these common configure APIs, delete the logic
+ and remove it from the documentation.
+
+ sim: refresh copyright dates a bit
+ Update a few files that were missed, and revert the generated Automake
+ output that uses dates from Automake itself.
+
+ sim: or1k: drop unused rules
+ These rules are the same as the common ones, so drop them to simplify.
+
+ sim: iq2000: drop unused cpu define logic
+ These defines seem to have been added in anticipation of adding another
+ cpu port (IQ10BF?), but that was over 20 years ago, and that port has
+ yet to materialize. So drop these compile flags since they don't do
+ anything to the generated code. If another port ever shows up, it's
+ easy enough to readd things as needed.
+
+2023-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ manual copyright year range of various GDB files to add 2023
+ This commit updates the following file...
+
+ gdb/doc/gdb.texinfo
+ gdb/doc/refcard.tex
+ gdb/syscalls/update-netbsd.sh
+
+ ... by hand as instructed by the gdb/copyright.py script.
+ The update by hand is needed because the copyright headers
+ to update are actually nested inside those files, rather
+ than located at the start of the file.
+
+2023-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Update copyright year range in header of all files managed by GDB
+ This commit is the result of running the gdb/copyright.py script,
+ which automated the update of the copyright year range for all
+ source files managed by the GDB project to be updated to include
+ year 2023.
+
+2023-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...
+ ... to sim/ppc/powerpc.igen
+
+ This file is in the NOT_FSF_LIST because this file has a copyright
+ which is not assigned to the FSF. Since the file got renamed,
+ the corresponding entry in NOT_FSF_LIST needs to be renamed as well.
+
+2023-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Update copyright year in help message of gdb, gdbserver, gdbreplay
+ This commit updates the copyright year displayed by gdb, gdbserver
+ and gdbreplay's help message from 2022 to 2023, as per our Start
+ of New Year procedure. The corresponding source files' copyright
+ header are also updated accordingly.
+
+2023-01-01 Alan Modra <amodra@gmail.com>
+
+ Update year range in gprofng copyright notices
+ This adds 'Innovative Computing Labs' as an external author to
+ update-copyright.py, to cover the copyright notice in
+ gprofng/common/opteron_pcbe.c, and uses that plus another external
+ author 'Oracle and' to update gprofng copyright dates. I'm not going
+ to commit 'Oracle and' as an accepted author, but that covers the
+ string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All
+ rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog
+ files.
+
+ Update year range in copyright notice of binutils files
+ The newer update-copyright.py fixes file encoding too, removing cr/lf
+ on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
+ embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
+
+2023-01-01 Alan Modra <amodra@gmail.com>
+
+ Update etc/update-copyright.py
+ This picks up some improvements from gcc/contrib. exceptions must
+ derive from BaseException, port to python3, retain original file mode,
+ fix name of script in examples.
+
+ Adds libsframe to list of default dirs. I would have added gprofng
+ too but there are some files claiming copyright by authors other than
+ the Free Software Foundation.
+
+2023-01-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-31 Nick Clifton <nickc@redhat.com>
+
+ Update version numbers in howto-make-a-release document
+
+ Update version number and regenerate files
+
+ Add markers for 2.40 branch
+
+ sync libiberty sources with gcc mainline
+
+2022-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Add maintenance ignore-probes
+ There's a command "disable probes", but SystemTap probes, for instance
+ libc:longjmp cannot be disabled:
+ ...
+ $ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
+ ...
+ Probe libc:longjmp cannot be disabled.
+ Probe libc:longjmp cannot be disabled.
+ Probe libc:longjmp cannot be disabled.
+ ...
+
+ Add a command "maintenance ignore-probes" that ignores probes during
+ get_probes, such that we can easily pretend to use a libc without the
+ libc:longjmp probe:
+ ...
+ (gdb) maint ignore-probes -verbose libc ^longjmp$
+ ignore-probes filter has been set to:
+ PROVIDER: 'libc'
+ PROBE_NAME: '^longjmp$'
+ OBJNAME: ''
+ (gdb) start ^M
+ ...
+ Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
+ Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
+ Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
+ ...
+
+ The "Ignoring ..." messages can be suppressed by not using -verbose.
+
+ Note that as with "disable probes", running simply "maint ignore-probes"
+ ignores all probes.
+
+ The ignore-probes filter can be reset by using:
+ ...
+ (gdb) maint ignore-probes -reset
+ ignore-probes filter has been reset
+ ...
+
+ For now, the command is only supported for SystemTap probes.
+
+ PR cli/27159
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159
+
+2022-12-31 Mark Harmstone <mark@harmstone.com>
+
+ ld/testsuite: Don't add index to sizes in pdb.exp
+
+ ld: Handle LF_VFTABLE types in PDBs
+
+2022-12-31 Mark Harmstone <mark@harmstone.com>
+
+ ld: Handle extended-length data structures in PDB types
+ A few fixes to minor issues I've discovered in my PDB patches.
+
+ * If sizes or offsets are greater than 0x8000, they get encoded as
+ extended values in the same way as for enum values - e.g. a LF_ULONG
+ .short followed by a .long.
+
+ * I've managed to coax MSVC to produce another type, LF_VFTABLE, which
+ is seen when dealing with COM. I don't think LLVM emits this. Note that
+ we can't just implement everything in Microsoft's header files, as most
+ of it is obsolete.
+
+ * Fixes a stupid bug in the test program, where I was adding an index to
+ a size. The index was hard-coded to 0, so this didn't cause any actual
+ issues.
+
+2022-12-31 Nick Clifton <nickc@redhat.com>
+
+ Updated Romanian translation for the binutils sub-directory
+
+2022-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32
+ [ Partial resubmission of an earlier submission by Andrew (
+ https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
+ listing him as co-author. ]
+
+ With x86_64-linux and target board unix/-m32, we have:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ Exception #10^M
+ ^M
+ Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
+ 23 throw new int (e);^M
+ (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
+ check FinishBreakpoint in catch()
+ ...
+
+ The following scenario happens:
+ - set breakpoint in throw_exception_1, a function that throws an exception
+ - continue
+ - hit breakpoint, with call stack main.c:38 -> throw_exception_1
+ - set a finish breakpoint
+ - continue
+ - hit the breakpoint again, with call stack main.c:48 -> throw_exception
+ -> throw_exception_1
+
+ Due to the exception, the function call did not properly terminate, and the
+ finish breakpoint didn't trigger. This is expected behaviour.
+
+ However, the intention is that gdb detects this situation at the next stop
+ and calls the out_of_scope callback, which would result here in this test-case
+ in a rather confusing "exception did not finish" message. So the problem is
+ that this message doesn't show up, in other words, the out_of_scope callback
+ is not called.
+
+ [ Note that the fact that the situation is detected only at the next stop
+ (wherever that happens to be) could be improved upon, and the earlier
+ submission did that by setting a longjmp breakpoint. But I'm considering this
+ problem out-of-scope for this patch. ]
+
+ Note that the message does show up later, at thread exit:
+ ...
+ [Inferior 1 (process 20046) exited with code 0236]^M
+ exception did not finish ...^M
+ ...
+
+ The decision on whether to call the out_of_scope call back is taken in
+ bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
+ ...
+ if (b->pspace == current_inferior ()->pspace
+ && (!target_has_registers ()
+ || frame_find_by_id (b->frame_id) == NULL))
+ bpfinishpy_out_of_scope (finish_bp);
+ ...
+
+ In the case of the thread exit, the callback triggers because
+ target_has_registers () == 0.
+
+ So why doesn't the callback trigger in the case of the breakpoint?
+
+ Well, the b->frame_id is the frame_id of the frame of main (the frame
+ in which the finish breakpoint is supposed to trigger), so AFAIU
+ frame_find_by_id (b->frame_id) == NULL will only be true once we've
+ left main, at which point I guess we don't stop till thread exit.
+
+ Fix this by saving the frame in which the finish breakpoint was created, and
+ using frame_find_by_id () == NULL on that frame instead, such that we have:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ Exception #10^M
+ ^M
+ Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
+ 23 throw new int (e);^M
+ exception did not finish ...^M
+ (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
+ check FinishBreakpoint in catch()
+ ...
+
+ Still, the test-case is failing because it's setup to match the behaviour that
+ we get on x86_64-linux with target board unix/-m64:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ Exception #10^M
+ stopped at ExceptionFinishBreakpoint^M
+ (gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
+ check FinishBreakpoint in catch()
+ ...
+
+ So what happens here? Again, due to the exception, the function call did not
+ properly terminate, but the finish breakpoint still triggers. This is somewhat
+ unexpected. This happens because it just so happens to be that the frame
+ return address at which the breakpoint is set, is also the first instruction
+ after the exception has been handled. This is a know problem, filed as
+ PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
+ callback.
+
+ Also add a breakpoint after setting the finish breakpoint but before throwing
+ the exception, to check that we don't call the out_of_scope callback too early.
+
+ Tested on x86_64-linux, with target boards unix/-m32.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ PR python/27247
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
+
+2022-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1
+ On ubuntu 22.04.1 x86_64, I run into:
+ ...
+ (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
+ set print symbol-loading off
+ sharedlibrary .*^M
+ Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
+ Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
+ (gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
+ ...
+
+ The test-case expects the libc.so line, but not the libpthread.so line.
+
+ However, we have:
+ ...
+ $ ldd /lib/x86_64-linux-gnu/libc.so.6
+ linux-vdso.so.1 (0x00007ffd7f7e7000)
+ libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
+ /lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
+ libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
+ libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
+ ...
+ so it's not unexpected that libpthread.so is loaded if libc.so is loaded.
+
+ Fix this by accepting the libpthread.so line.
+
+ Tested on x86_64-linux.
+
+ PR testsuite/29919
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919
+
+2022-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Replace deprecated pthread_yield in gdb.threads/watchpoint-fork.exp
+ On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
+ ...
+ watchpoint-fork-mt.c: In function 'start':^M
+ watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
+ pthread_yield is deprecated, use sched_yield instead \
+ [-Wdeprecated-declarations]^M
+ 67 | i = pthread_yield ();^M
+ | ^^M
+ ...
+
+ Fix this as suggested, by using sched_yield instead.
+
+ Tested on x86_64-linux.
+
+2022-12-31 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35
+ On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
+ ...
+ (gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
+ bt^M
+ #0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
+ #1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
+ #2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
+ #3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
+ #4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
+ #5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
+ #6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
+ #7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
+ (gdb) PASS: gdb.base/corefile.exp: backtrace
+ up^M
+ #1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
+ 78 in ./nptl/pthread_kill.c^M
+ (gdb) FAIL: gdb.base/corefile.exp: up
+ ...
+
+ The problem is that the regexp used here:
+ ...
+ gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
+ ...
+ does not fit the __pthread_kill_internal line which lacks the instruction
+ address due to inlining.
+
+ Fix this by making the regexp less strict.
+
+ Tested on x86_64-linux.
+
+2022-12-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc
+ On ubuntu 22.04.1 x86_64, I run into:
+ ...
+ (gdb) info probes all rtld rtld_map_complete^M
+ No probes matched.^M
+ (gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
+ UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
+ ...
+ This has been filed as PR testsuite/17016.
+
+ The problem is that the name rtld_map_complete is used, which was only
+ available in Fedora 17, and upstream the name map_complete was used.
+
+ In the email thread discussing a proposed patch (
+ https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
+ suggested to make the test-case handle both names.
+
+ So, handle both names: map_complete and rtld_map_complete.
+
+ This exposes the following FAIL:
+ ...
+ (gdb) info sharedlibrary^M
+ From To Syms Read Shared Object Library^M
+ $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
+ $hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
+ $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
+ $hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
+ $hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
+ (*): Shared library is missing debugging information.^M
+ (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
+ ...
+ due to using a glibc (v2.35) that has libpthread integrated into libc.
+
+ Fix this by changing the FAIL into UNSUPPORTED.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016
+
+2022-12-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with -fcf-protection
+ On Ubuntu 22.04.1 x86_64, I run into:
+ ...
+ gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
+ gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
+ '-fcf-protection' are not compatible^M
+ 22 | { /* inc.1 */^M
+ | ^^M
+ ...
+
+ Fix this by forcing -fcf-protection=none, if supported.
+
+ Tested on x86_64-linux.
+
+2022-12-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protection
+ On Ubuntu 22.04.1 x86_64, I run into:
+ ...
+ (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
+ next^M
+ 51 if (t != NULL^M
+ (gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
+ ...
+
+ This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
+ ...
+ 0000000000001180 <_Z13get_alias_setP4tree>:
+ 1180: f3 0f 1e fa endbr64
+ 1184: 48 85 ff test %rdi,%rdi
+ ...
+ so the extra insn gets an is-stmt line number entry:
+ ...
+ INDEX LINE ADDRESS IS-STMT PROLOGUE-END
+ ...
+ 11 50 0x0000000000001180 Y
+ 12 50 0x0000000000001180
+ 13 51 0x0000000000001184 Y
+ 14 54 0x0000000000001184
+ ...
+ and when stepping into get_alias_set we step to line 50:
+ ...
+ (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
+ step^M
+ get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
+ 50 {^M
+ ...
+
+ In contrast, with -fcf-protection=none, we get:
+ ...
+ 0000000000001170 <_Z13get_alias_setP4tree>:
+ 1170: 48 85 ff test %rdi,%rdi
+ ...
+ and:
+ ...
+ INDEX LINE ADDRESS IS-STMT PROLOGUE-END
+ ...
+ 11 50 0x0000000000001170 Y
+ 12 51 0x0000000000001170 Y
+ 13 54 0x0000000000001170
+ ...
+ so when stepping into get_alias_set we step to line 51:
+ ...
+ (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
+ step^M
+ get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
+ 51 if (t != NULL^M
+ ...
+
+ Fix this by rewriting the gdb_test issuing the step command to check which
+ line the step lands on, and issuing an extra next if needed.
+
+ Tested on x86_64-linux, both with and without -fcf-protection=none.
+
+ PR testsuite/29920
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920
+
+2022-12-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Make comp_unit_head.length private
+ Make comp_unit_head.length private, to enforce using accessor functions.
+
+ Replace accessor function get_length with get_length_with_initial and
+ get_length_without_initial, to make it explicit which variant we're using.
+
+ Tested on x86_64-linux.
+
+ PR symtab/29343
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
+
+2022-12-30 Alan Modra <amodra@gmail.com>
+
+ PR29948, heap-buffer-overflow in display_debug_lines_decoded
+ This fixes a couple of places in display_debug_lines_decoded that were
+ off by one in checking DWARF5 .debug_line directory indices. It also
+ displays the DWARF5 entry 0 for the program current directory rather
+ than "." as is done for pre-DWARF5. I decided against displaying
+ DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf
+ to minimally interpret debug info.
+
+ binutils/
+ PR 29948
+ * dwarf.c (display_debug_lines_decoded): Display the given
+ directory entry 0 for DWARF5. Properly check directory index
+ against number of entries in the table. Revert to using
+ unsigned int for n_directories and associated variables.
+ Correct warning messages.
+ gas/
+ * testsuite/gas/elf/dwarf-5-loc0.d: Update.
+
+2022-12-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Simplify riscv_csr_address logic on state enable extensions
+ This commit makes CSR class handling for 'Smstateen' and 'Ssstateen'
+ extensions simpler using fall-throughs (as used in CSR_CLASS_I{,_32}).
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_csr_address): Simplify the logic for
+ 'Smstateen' and 'Ssstateen' extensions.
+
+2022-12-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-28 Tom Tromey <tom@tromey.com>
+
+ Use $decimal in timestamp.exp
+ This patch fixes a review comment by Tom de Vries. He pointed out
+ that the new timestamp.exp should use the $decimal convenience regexp.
+
+2022-12-28 Tom Tromey <tom@tromey.com>
+
+ Fix "set debug timestamp"
+ PR cli/29945 points out that "set debug timestamp 1" stopped working
+ -- this is a regression due to commit b8043d27 ("Remove a ui-related
+ memory leak").
+
+ This patch fixes the bug and adds a regression test.
+
+ I think this should probably be backported to the gdb 13 branch.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945
+
+2022-12-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-27 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Allocate input section memory if needed
+ When --no-keep-memory is used, the input section memory may not be cached.
+ Allocate input section memory for -z pack-relative-relocs if needed.
+
+ bfd/
+
+ PR ld/29939
+ * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Allocate
+ input section memory if needed.
+
+ ld/
+
+ PR ld/29939
+ * testsuite/ld-elf/dt-relr-2i.d: New test.
+
+2022-12-27 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Fix T-Head Fmv vendor extension encoding
+ A recent change in the XTheadFmv spec fixed an encoding bug in the
+ document. This patch changes the code to follow this bugfix.
+
+ Spec patch can be found here:
+ https://github.com/T-head-Semi/thead-extension-spec/pull/11
+
+2022-12-27 Tom Tromey <tromey@adacore.com>
+
+ Handle SIGSEGV in gdb selftests
+ The gdb.gdb self-tests were timing out for me, which turned out to be
+ PR testsuite/29325. Looking into it, the problem is that the version
+ of the Boehm GC that is used by Guile on my machine causes a SEGV
+ during stack probing. This unexpected stop confuses the tests and
+ causes repeated timeouts.
+
+ This patch adapts the two failing tests. This makes them work for me,
+ and reduces the running time of gdb.gdb from 20 minutes to about 11
+ seconds.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
+
+2022-12-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: clean up unused codegen logic
+ Now that all igen ports are in the top-level makefile, we don't need
+ this logic in any subdirs anymore, so clean it up.
+
+ sim: mips: hoist "multi" igen rules up to common builds
+ Since these are the last mips igen rules, we can clean up a number of
+ bits in the local Makefile.in.
+
+ sim: mips: hoist "m16" igen rules up to common builds
+
+ sim: mips: hoist "single" igen rules up to common builds
+
+ sim: mips: rename "igen" generation mode to "single"
+ The naming in here has grown organically and is confusing to follow.
+ Originally there was only one set of rules for generating code from
+ the igen sources, so calling it "tmp-igen" and such made sense. But
+ when other multigen modes were added ("m16" & "multi") which also
+ used igen, it's not clear what's common igen and what's specific to
+ this generation mode. So rename the set of rules from "igen" to
+ "single" so it's easier to follow.
+
+ sim: mips: hoist itable igen rules up to common builds
+ Since this rule is pretty simple, hoist it up to the common build.
+
+2022-12-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: unify itable generation (a bit)
+ The m16 & multi targets generate itable once even when all the other
+ modules are generated multiple times. The default igen target will
+ generate itable with everything else out of convenience. This means
+ flags are passed which don't affect the generated itable there.
+
+ We can unify the itable generation by making sure the right -F/-M
+ filter variables are passed down. Since there's already a dedicated
+ rule & variable in the multi build mode, generalize that and switch
+ the m16 & igen builds over too.
+
+ I spent a lot of time staring at this code, building for diff mips
+ targets, and exploring all the shell code paths. I think this is
+ safe, but only time (and users) will really tell.
+
+2022-12-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: rename multi_flags to igen_itable_flags
+ This variable is only used to generate the itable files. In preparation
+ for merging the itable logic among all ports, rename "multi_flags" to a
+ more appropriate "igen_itable_flags" variable. There should be no real
+ chagnes here otherwise.
+
+ sim: mips: drop unused micromips igen logic
+ This code appears to be unused since it was first merged. When
+ micromips was enabled, it was via the "MULTI" config, not the
+ "MICROMIPS" config, and the multi configs have sep vars. Since
+ nothing sets SIM_MIPS_GEN=MICROMIPS in the config, all of this
+ should be unreachable, so punt it to simplify. Further, the
+ SIM_MIPS_MICROMIPS16_FLAGS & SIM_MIPS_MICROMIPS_FLAGS settings
+ rely on sim_mips_micromips{,16}_{filter,machine} variables that
+ are never set in the configure script.
+
+2022-12-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-26 Tom Tromey <tom@tromey.com>
+
+ Add initializers to comp_unit_head
+ PR symtab/29343 points out that it would be beneficial if
+ comp_unit_head had a constructor and used initializers. This patch
+ implements this. I'm unsure if this is sufficient to close the bug,
+ but at least it's a step.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
+
+2022-12-26 Alan Modra <amodra@gmail.com>
+
+ bfd/dwarf2.c: allow use of DWARF5 directory entry 0
+ I think the test for table->files[file].dir being non-zero is wrong
+ for DWARF5 where index zero is allowed and is the current directory of
+ the compilation. Most times this will be covered by the use of
+ table->comp_dir (from DW_AT_comp_dir) in concat_filename but the point
+ of putting the current dir in .debug_line was so the section could
+ stand alone without .debug_info.
+
+ Also, there is no need to check for table->dirs non-NULL, the
+ table->num_dirs test is sufficient.
+
+ * dwarf2.c (concat_filename): Correct and simplify tests of
+ directory index.
+
+2022-12-26 Flavio Cruz <flaviocruz@gmail.com>
+
+ Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd
+
+2022-12-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-25 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: drop support for subdir distclean
+ All ports that need to clean things up at distclean time have moved
+ to the top-level build, so we can drop support for this hook.
+
+ sim: mips: move distclean settings to common build
+ This was missed when mips/configure was merged into the top-level.
+
+2022-12-25 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: write out SFrame FRE start address correctly
+ The following test was failing on ppc64 and s390x:
+ "FAIL: encode-1: Encode buffer match"
+
+ The offending stub was how we memcpy the FRE start address to the buffer
+ (on-disk format). When the host is big-endian, the address of the
+ source buffer for the memcpy needs to point to the uint8_t/uint16_t sized
+ value of the FRE start addr, not uint32_t sized value; we intend to copy
+ out only the fre_start_addr_sz number of bytes.
+
+ ChangeLog:
+
+ * libsframe/sframe.c (sframe_encoder_write_fre_start_addr): New
+ function.
+ (sframe_encoder_write_fre): Use it instead of memcpy.
+
+2022-12-25 Mike Frysinger <vapier@gentoo.org>
+
+ sim: smp: plumb igen flag down to all users
+ While mips has respected sim_igen_smp at configure time (which was
+ always empty since it defaulted smp to off), no other igen port did.
+ Move this to a makefile variable and plumb it through the common
+ IGEN_RUN variable instead so everyone gets it by default. We also
+ clean up some redundant -N0 setting with multirun mips.
+
+ sim: smp: make option available again
+ At some point we want this to work, but it's not easy to test if
+ the configure option isn't available. Restore it, but keep the
+ default off.
+
+ sim: cpu: change default init to handle all cpus
+ All the runtimes were only initializing a single CPU. When SMP is
+ enabled, things quickly crash as none of the other CPU structs are
+ setup. Change the default from 0 to the compile time value.
+
+ sim: msp430: add basic SMP cpu init
+ There's no need to assert there's only 1 CPU when setting them all
+ up here is trivial.
+
+ sim: m32r: fix iterator typo when setting up cpus
+ This code loops over available cpus with "c", but then looks up the
+ cpu with "i". Fix the typo so the code works correctly with smp.
+
+ sim: v850: fix SMP compile
+ The igen tool sets up the SD & CPU defines for code fragments to use,
+ but v850 was expecting "sd". Change all the igen related code to use
+ SD so it actually compiles, and fix a few places to use "CPU" instead
+ of hardcoding cpu0.
+
+ sim: or1k: fix iterator typo when setting up cpus
+ This code loops over available cpus with "c", but then looks up the
+ cpu with "i". Fix the typo so the code works correctly with smp.
+
+ sim: mn10300: fix SMP compile
+ The igen tool sets up the SD define for code fragments to use, but
+ mn10300 was expecting "sd". Change all the igen related code to use
+ SD so it actually compiles.
+
+ sim: cpu: fix SMP msg prefix helper
+ This code fails to compile when SMP is enabled due to some obvious
+ errors. Fix those and change the logic to avoid CPP to prevent any
+ future rot from creeping back in.
+
+ sim: mips: clean up a bit after mips/configure removal
+ Now that there is no subdir configure script, we can clean up some
+ logic that was spread between the files.
+
+ sim: mips: move igen settings to top-level configure
+ This is the last bit of logic that exists in the mips configure
+ script, so move it to the top-level configure to kill it off.
+ We still have to move the Makefile.in igen logic to local.mk,
+ but this is a required first step for that.
+
+ sim: mips: namespace igen configure vars
+ To prepare moving this logic to the top-level configure, the vars
+ need to be namespaced. Do that here to make it easier to review.
+ Basically sim_xxx -> SIM_MIPS_XXX when a var is exported from the
+ configure script to the Makefile, and sim_xxx -> sim_mips_xxx when
+ the var is internal in the configure script.
+
+ sim: mips: add igen recursive dep
+ Make sure the igen tool exists before trying to compile the mips
+ subdir. This happens to work when mips has a subconfigure, but
+ hits a race condition when that is removed.
+
+ sim: mips: drop unused ENGINE_ISSUE_POSTFIX_HOOK
+ Nothing defines this, and it isn't called in all the engine runtimes,
+ so drop it entirely to avoid confusion.
+
+ sim: igen: drop move-if-changed usage
+ Now that igen itself has this logic, drop these custom build rules
+ to greatly simplify.
+
+ sim: igen: support in-place updates ourself
+ Every file that igen outputs is then processed with the move-if-changed
+ shell script. This creates a lot of boilerplate in the build and not an
+ insignificant amount of build-time overhead. Move the simple "is the file
+ changed" logic into igen itself.
+
+ sim: igen: constify itable data structures
+ These are const data arrays of strings and numbers. We don't want
+ or need them to be writable, so mark them all const.
+
+2022-12-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix buffer overflow in gdb.base/signed-builtin-types.exp
+ In commit:
+
+ commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12
+ Date: Wed Dec 7 15:55:25 2022 +0000
+
+ gdb/testsuite: new test for recent dwarf reader issue
+
+ A new test (gdb.base/signed-builtin-types.exp) was added that made use
+ of 'info sources' to figure out if the debug information for a
+ particular object file had been fully expanded or not. Unfortunately
+ some lines of the 'info sources' output can be very long, this was
+ observed on some systems where the debug information for the
+ dynamic-linker was installed, in this case, the list of source files
+ associated with the dynamic linker was so long it would cause expect's
+ internal buffer to overflow.
+
+ This commit switches from using 'info sources' to 'maint print
+ objfile', the output from the latter command is more compact, but
+ also, can be restricted to a single named object file.
+
+ With this change in place I am no longer seeing buffer overflow errors
+ from expect when running gdb.base/signed-builtin-types.exp.
+
+2022-12-24 Mike Frysinger <vapier@gentoo.org>
+
+ sim: or1k: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to the existing or1k-sim.h.
+ Unfortunately, we can't yet drop the or1k-sim.h include from sim-main.h
+ as many of the generated CGEN files refer only to sim-main.h. We'll
+ have to improve the CGEN interface before we can make more progress,
+ but this is at least a minor improvement.
+
+2022-12-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-23 Tom Tromey <tom@tromey.com>
+
+ Use bool for dwarf2_has_info
+ This changes dwarf2_has_info to return bool.
+
+2022-12-23 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: testsuite: fix memory leaks in testcases
+ ChangeLog:
+
+ * libsframe/testsuite/libsframe.decode/be-flipping.c: Free
+ SFrame buffer.
+ * libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise.
+ * libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise.
+
+2022-12-23 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: fix a memory leak in sframe_decode
+ sframe_decode () needs to malloc a temporary buffer of the same size as
+ the input buffer (containing the SFrame section bytes) when endian
+ flipping is needed. The decoder keeps the endian flipped contents in
+ this buffer for its usage. This code is necessary when the target
+ endianneess is not the same as host endianness.
+
+ The malloc'd buffer needs to be kept track of, so that it can freed up in
+ sframe_decoder_free () later.
+
+ ChangeLog:
+
+ * libsframe/sframe-impl.h (struct sframe_decoder_ctx): Add new
+ member to keep track of the internally malloc'd buffer.
+ * libsframe/sframe.c (sframe_decoder_free): Free it up.
+ (sframe_decode): Update the reference to the buffer.
+
+2022-12-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: remove MPFR detection in gdb.base/float128.exp
+ I see this fail since commit 991180627851 ("Use toplevel configure for
+ GMP and MPFR for gdb"):
+
+ FAIL: gdb.base/float128.exp: show configuration
+
+ The test fails to find --with-mpfr or --without-mpfr in the "show
+ configuration" output. Since MPFR has become mandatory, we can just
+ remove that check and simplify the test to assume MPFR support is there.
+
+ Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to the existing m32r-sim.h.
+ Unfortunately, we can't yet drop the m32r-sim.h include from sim-main.h
+ as many of the generated CGEN files refer only to sim-main.h. We'll
+ have to improve the CGEN interface before we can make more progress,
+ but this is at least a minor improvement.
+
+ sim: bfin: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the bfin.h include and move the remaining
+ bfin-specific settings into it.
+
+ sim: m68hc11: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: sh: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: mcore: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: h8300: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: pru: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the pru.h include and move the remaining
+ pru-specific settings into it.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mn10300: standardize the arch-specific settings a little
+ Rename mn10300_sim.h to mn10300-sim.h to match other ports, and move most
+ of the arch-specific content out of sim-main.h to it. This isn't a big
+ win though as we still have to include the header in sim-main.h due to the
+ igen interface: it hardcodes including sim-main.h in its files. So until
+ we can fix that, we have to keep bleeding these settings into the common
+ codes.
+
+ Also take the opportunity to purge a lot of unused headers from these.
+ The local modules should already include the right headers, so there's
+ no need to force everyone to pull them in. A lot of this is a hold over
+ from the pre-igen days of this port.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: microblaze: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: example-synacor: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ sim: moxie: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: riscv: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ We can also move the machs.h include out since the model logic was all
+ generalized from compile-time to runtime last year.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: standardize the arch-specific settings a little
+ Rename v850_sim.h to v850-sim.h to match other ports, and move most
+ of the arch-specific content out of sim-main.h to it. This isn't a
+ big win though as we still have to include the header in sim-main.h
+ due to the igen interface: it hardcodes including sim-main.h in its
+ files. So until we can fix that, we have to keep bleeding these
+ settings into the common codes.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: msp430: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the msp430-sim.h include and move it to
+ the few files that actually need it.
+
+ While we're here, drop redundant includes from sim-main.h:
+ * sim-config.h & sim-types.h included by sim-basics.h already
+ * sim-engine.h included by sim-base.h already
+ And move sim-options.h to the one file that needs it.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ft32: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the ft32-sim.h include and move it to
+ the few files that actually need it.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: d10v: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the d10v_sim.h include and move it to
+ the few files that actually need it.
+
+ Also rename the file to standardize it a bit better with other ports.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cr16: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so drop the cr16_sim.h include and move it to
+ the few files that actually need it.
+
+ Also rename the file to standardize it a bit better with other ports.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: arm: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ The BIT override would be better in the place where it's redefined, so
+ move it to armdefs.h instead.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: aarch64: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+ While we're here, drop redundant includes from sim-main.h:
+ * sim-types.h is included by sim-base.h already
+ * sim-base.h is included twice
+ * sim-io.h is included by sim-base.h already
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: avr: move arch-specific settings to internal header
+ There's no need for these settings to be in sim-main.h which is shared
+ with common/ sim code, so move it all out to a new header which only
+ this port will include.
+
+2022-12-23 Nick Clifton <nickc@redhat.com>
+
+ Fix illegal memory access parsing corrupt DWARF information.
+ PR 29936
+ * dwarf2.c (concat_filename): Fix check for a directory index off
+ the end of the directory table.
+
+2022-12-23 Eli Zaretskii <eliz@gnu.org>
+
+ Fix MinGW build using mingw.org's MinGW
+ This allows to build GDB even though the default value of
+ _WIN32_WINNT is lower than the one needed to expose some
+ new APIs used here, and leave the test for their actual
+ support to run time.
+ * gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if
+ not defined.
+ (create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list'
+ instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined
+ at compile time). This fixes compilation error using mingw.org's
+ MinGW.
+
+2022-12-23 Mark Harmstone <mark@harmstone.com>
+
+ ld: Write linker symbols in PDB
+
+ ld: Copy other symbols into PDB file
+
+ ld: Write globals stream in PDB
+
+ ld: Parse LF_UDT_SRC_LINE records when creating PDB file
+
+ ld: Write types into IPI stream of PDB
+
+ ld: Write types into TPI stream of PDB
+
+ ld: Write DEBUG_S_LINES entries in PDB file
+
+ ld: Fix segfault in populate_publics_stream
+
+ ld: Write DEBUG_S_FILECHKSMS entries in PDBs
+
+ ld: Generate PDB string table
+
+2022-12-23 Alan Modra <amodra@gmail.com>
+
+ pdb build fixes
+ Enable compilation of ld/pdb.c just for x86, as is done for bfd/pdb.c.
+ This reduces the size of ld and is necessary with the following
+ patches that call a COFF-only bfd function from ld/pdb.c. Without it
+ we'd break every non-COFF target build.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: lm32/m32r: drop redundant opcode/cgen.h include
+ The xxx-desc.h header file already includes this, and it's how the
+ other cgen ports are getting it, so drop it from these two.
+
+ sim: ppc: drop unused types from sim-main.h
+ The common sim headers should define these for us already, so there's
+ no need for the ppc header to set them up.
+
+ sim: cgen: move symcat.h include to where it's used
+ Move this out of the global sim-main.h and to the few files that
+ actually use functions from it. Only the cgen ports were pulling
+ this, so this makes cgen & non-cgen behave more the same.
+
+ sim: cgen: move cgen-types.h include to cgen-defs.h
+ The cgen-types.h header sets up types that are needed by cgen-defs.h,
+ so move the include out of sim-main.h and to that header. It might
+ be needed in other specific modules, but for now let's kick it out of
+ sim-main.h to make some progress. Things still build with just this.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ Revert "sim: mn10300: drop unused sim-main.c"
+ This reverts commit 681a422b855e4b20086554b170dae051361f00c7.
+
+ I missed that this was included via common/sim-inline.c. I thought
+ I had grepped the top of the tree, but I must have only done mn10300.
+
+ Add a comment to make it clear where/how this file is used.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mn10300: drop unused sim-main.c
+ Nothing compiles or references this, so punt it.
+
+ sim: endian: move bfd.h from header to source
+ The bfd APIs are used only by sim-n-endian.h which is only included by
+ sim-endian.c, so move the bfd.h include there and out of sim-endian.h
+ which is included by many other modules.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: move bfd.h include out of sim-main.h
+ Not all arches include this in sim-main.h, and the ones that do don't
+ actually use bfd defines in the sim-main.h header. Prune it to make
+ sim-main.h simpler so we can kill it off entirely in the future.
+
+ We add the include to the files that utilize e.g. bfd_vma though.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mcore: replace custom "word" type with int32_t
+ This is a 32-bit architecture with 32-bit registers, so replace the
+ custom "word" long int typedef with an explicit int32_t. This is
+ a correctness fix since long will be 64-bits on most 64-bit hosts.
+
+ sim: moxie: replace custom "word" type with int32_t
+ This is a 32-bit architecture with 32-bit registers, so replace the
+ custom "word" int typedef with an explicit int32_t. Practically
+ speaking, this produces the same code, but it should hopefully make
+ it easier to merge common code in the future.
+
+ sim: cr16/d10v/mcore/moxie: clean up unused word & uword types
+ Nothing actually uses these, so punt them. Some of the ports are
+ using local "word" types, but we'll clean those up in a follow up.
+
+ sim: mips: trim redundant igen settings
+ These variables are setting the same value as the defaults. Trim
+ this redundant logic to make it easier to see the real differences
+ so we can try to keep unifying cases.
+
+ sim: mips: merge mips64* with existing multi-run build
+ Change the default (unhandled) mips64* targets to use the existing
+ mips64 multi-run build. It already handles the formats, we just
+ have to list the mips8000 bfd for it.
+
+ sim: mips: merge mips64vr5000 with existing multi-run build
+ The existing mips64vr-* multi-run build already handles mips5000
+ targets, so reuse that for mips64vr5* targets too. This moves
+ more logic from build-time to runtime so we can have a single
+ binary that supports many targets.
+
+2022-12-23 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Relax the order checking for the architecture string
+ * riscv-toolchain-conventions,
+ PR, https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14
+ Issue, https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/11
+
+ * Refer to the commit afc41ffb,
+ RISC-V: Reorder the prefixed extensions which are out of order.
+
+ In the past we only allow to reorder the prefixed extensions. But according
+ to the PR 14 in the riscv-toolchain-convention, we can also relax the order
+ checking to allow the whole extensions be written out of orders, including
+ the single standard extensions and the prefixed multi-letter extensions.
+ Just that we still need to follow the following rules as usual,
+
+ 1. prefixed extensions need to be seperated with `_'.
+ 2. prefixed extensions need complete <major>.<minor> version if set.
+
+ Please see the details in the march-ok-reorder gas testcase.
+
+ Passed the riscv-gnu-toolchain regressions.
+
+ bfd/
+ * elfxx-riscv.c (enum riscv_prefix_ext_class): Changed RV_ISA_CLASS_UNKNOWN
+ to RV_ISA_CLASS_SINGLE, since everything that does not belong to the
+ multi-keyword will possible be a single extension for the current parser.
+ (parse_config): Likewise.
+ (riscv_get_prefix_class): Likewise.
+ (riscv_compare_subsets): Likewise.
+ (riscv_parse_std_ext): Removed, and merged with riscv_parse_prefixed_ext
+ into riscv_parse_extensions.
+ (riscv_parse_prefixed_ext): Likewise.
+ (riscv_parse_subset): Only need to call riscv_parse_extensions to parse
+ both single standard and prefixed extensions.
+ gas/
+ * testsuite/gas/riscv/march-fail-order-std.d: Removed since the relaxed
+ order checking.
+ * testsuite/gas/riscv/march-fail-order-std.l: Likewise.
+ * testsuite/gas/riscv/march-fail-order-x-std.d: Likewise.
+ * testsuite/gas/riscv/march-fail-order-z-std.d: Likewise.
+ * testsuite/gas/riscv/march-fail-order-zx-std.l: Likewise.
+ * testsuite/gas/riscv/march-fail-unknown-std.l: Updated.
+ * testsuite/gas/riscv/march-ok-reorder.d: New testcase.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: drop unused SIM_ADDR type [PR sim/7504]
+ Now that sim APIs either use 64-bit addresses all the time, or more
+ appropriate target-specific types, drop this now-unused 32-bit-only
+ address type.
+
+ Bug: https://sourceware.org/PR7504
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: switch from SIM_ADDR to address_word
+ The latter type matches the address size configured for this sim.
+
+ Also take the opportunity to simplify printf logic by leveraging
+ PRI* macros.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: switch from SIM_ADDR to address_word
+ The latter type matches the address size configured for this sim.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: switch sim_{read,write} APIs to 64-bit all the time [PR sim/7504]
+ We've been using SIM_ADDR which has always been 32-bit. This means
+ the upper 32-bit address range in 64-bit sims is inaccessible. Use
+ 64-bit addresses all the time since we want the APIs to be stable
+ regardless of the active arch backend (which can be 32 or 64-bit).
+
+ The length is also 64-bit because it's completely feasible to have
+ a program that is larger than 4 GiB in size/image/runtime. Forcing
+ the caller to manually chunk those accesses up into 4 GiB at a time
+ doesn't seem useful to anyone.
+
+ Bug: https://sourceware.org/PR7504
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: use bfd_vma when reading start addr from bfd info
+ Since SIM_ADDR is always 32-bit, it might truncate the address with
+ 64-bit ELFs. Since we load that addr from the bfd, use the bfd_vma
+ type which matches the bfd_get_start_address API.
+
+ sim: m32r: include sim-hw.h for sim_hw_parse
+
+2022-12-23 Alan Modra <amodra@gmail.com>
+
+ COFF build-id writes uninitialised data to file
+ 1) The first write in write_build_id wrote rubbish past the struct
+ external_IMAGE_DEBUG_DIRECTORY, which was later overwritten with
+ correct data. No user visible problem there, except that tools like
+ valgrind complain.
+ 2) The size for the pdb name was incorrectly calculated.
+
+ * emultempl/pe.em (write_build_id): Write the debug directory,
+ not the entire section contents.
+ (setup_build_id): Add size for the base name of pdb_name, not
+ the full path.
+ * emultempl/pep.em: Likewise.
+ * testsuite/ld-pe/pdb2-section-contrib.d: Update.
+
+2022-12-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: merge mips64vr4300 with existing multi-run build
+ The existing mips64vr-* multi-run build already handles mips4300
+ targets, so reuse that for mips64vr43* targets too. This moves
+ more logic from build-time to runtime so we can have a single
+ binary that supports many targets.
+
+2022-12-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: doc: update documentation for pauth key in SFrame FDE
+ ChangeLog:
+
+ * libsframe/doc/sframe-spec.texi
+
+2022-12-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: testsuite: add testcase for .cfi_b_key_frame
+ This is actually a composite test that checks SFrame unwind information
+ generation for both the .cfi_negate_ra_state and .cfi_b_key_frame
+ directives on aarch64.
+
+ ChangeLog:
+
+ * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d:
+ New test.
+ * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.s:
+ Likewise.
+ * testsuite/gas/cfi-sframe/cfi-sframe.exp: Run new test.
+
+2022-12-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ objdump/readelf: sframe: emit marker for SFrame FDE with B key
+ ChangeLog:
+
+ * libsframe/sframe-dump.c (is_sframe_abi_arch_aarch64): New
+ definition.
+ (dump_sframe_func_with_fres): Emit a string if B key is used.
+
+2022-12-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: add support for .cfi_b_key_frame
+ Gather the information from the DWARF FDE on whether frame's return
+ addresses are signed using the B key or A key. Reflect the information in
+ the SFrame counterpart data structure, the SFrame FDE.
+
+ ChangeLog:
+
+ * gas/gen-sframe.c (get_dw_fde_pauth_b_key_p): New definition.
+ (sframe_v1_set_func_info): Add new argument for pauth_key.
+ (sframe_set_func_info): Likewise.
+ (output_sframe_funcdesc): Likewise.
+ * gas/gen-sframe.h (struct sframe_version_ops): Add new argument
+ to the function pointer declaration.
+ * gas/sframe-opt.c (sframe_convert_frag): Handle pauth_key.
+
+2022-12-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe.h: add support for .cfi_b_key_frame
+ ARM 8.3 provides five separate keys that can be used to authenticate
+ pointers. There are two key for executable (instruction) pointers. The
+ enum pointer_auth_key in gas/config/tc-aarch64.h currently holds two keys:
+ enum pointer_auth_key {
+ AARCH64_PAUTH_KEY_A,
+ AARCH64_PAUTH_KEY_B
+ };
+
+ Analogous to the above, in SFrame format V1, a bit is reserved in the SFrame
+ FDE to indicate which key is used for signing the frame's return addresses:
+ - SFRAME_AARCH64_PAUTH_KEY_A has a value of 0
+ - SFRAME_AARCH64_PAUTH_KEY_B has a value of 1
+
+ Note that the information in this bit will always be used along with the
+ mangled_ra_p bit, the latter indicates whether the return addresses are
+ mangled/contain PAC auth bits.
+
+ include/ChangeLog:
+
+ * sframe.h (SFRAME_AARCH64_PAUTH_KEY_A): New definition.
+ (SFRAME_AARCH64_PAUTH_KEY_B): Likewise.
+ (SFRAME_V1_FUNC_INFO): Adjust to accommodate pauth_key.
+ (SFRAME_V1_FUNC_PAUTH_KEY): New macro.
+ (SFRAME_V1_FUNC_INFO_UPDATE_PAUTH_KEY): Likewise.
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ gas: re-arrange listing output for .irp and alike
+ It is kind of odd to have the expansions of such constructs ahead of
+ their definition in listings with macro expansion enabled. Adjust this
+ by pulling ahead the output of the definition lines, taking care to
+ avoid producing a listing line for (non-existing) line 0 when the source
+ is stdin.
+
+ Note that with the code movement the conditional operator isn't
+ necessary anymore - list->line now match up.
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct/improve TSX controls
+ TSXLDTRK takes RTM as a prereq. Additionally introduce an umbrella "tsx"
+ extension option covering both RTM and HLE, paralleling the "abm" one we
+ already have.
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: add dependencies on SVME
+ SEV-ES is an extension to SVME. SNP in turn is an extension to SEV-ES,
+ and yet in turn RMPQUERY is a SNP extension.
+
+ Note that cpu_arch[] has no SNP entry, so CPU_ANY_SNP_FLAGS remains
+ unused (just like CPU_SNP_FLAGS already is).
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: add dependencies on VMX
+ Both EPT and VMFUNC are extensions to VMX.
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct XSAVE* dependencies
+ Like various other features AMX-TILE takes XSAVE as a prereq.
+
+ XSAVES, unconditionally using compacted format, in turn effectively
+ takes XSAVEC as a prereq (an SDM clarification to this effect is in the
+ works).
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct dependencies of a few AVX512 sub-features
+ Like AVX512-FP16, several other extensions require wider than 16-bit
+ mask registers. As a result they take AVX512BW as a prereq, not (just)
+ AVX512F. Which in turn points out wrong expectations in the noavx512-1
+ testcase.
+
+ x86: rework noavx512-1 testcase
+ So far the set of ".noavx512*" has been accumulating, which isn't ideal.
+ In particular this hides issues with dependencies between features.
+ Switch back to the default ISA before disabling a particular subset.
+ Furthermore limit redundancy by wrapping the repeated block of insns in
+ an .irp.
+
+ x86: add dependencies on AVX2
+ Like AVX-VNNI both VAES and VPCLMUL take AVX2 as a prereq, for operating
+ on up to 256-bit packed integer vectors.
+
+ x86: correct SSE dependencies
+ SSE itself takes FXSR as a prereq. Like AES, PCLMUL, and SHA both GFNI
+ and KL take SSE2 as a prereq, for operating on packed integers. And
+ while correcting KL also record it as a prereq to WIDEKL.
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct what gets disabled by certain ".arch .no*"
+ Features with prereqs as well as features with dependents cannot re-use
+ CPU_*_MASK for the 3rd argument of SUBARCH() - they need to use
+ CPU_ANY_*_MASK in order to avoid disabling too many (when there are
+ prereqs) and/or too few (when there are dependents) features.
+
+ Generally any CPU_ANY_*_MASK which exist should not remain unused.
+ Exceptions are
+ - FISTTP which has no corresponding entry in cpu_arch[],
+ - IAMCU which is a base architecture and hence uses ARCH(), not
+ SUBARCH() (only extensions can be disabled, but unlike for Cpu*86 it
+ would be a little more clumsy to suppress generating of the #define).
+
+2022-12-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-work ISA extension dependency handling
+ Getting both forward and reverse ISA dependencies right / consistent has
+ been a permanent source of mistakes. Reduce what needs specifying
+ manually to just the direct forward dependencies. Transitive forward
+ dependencies as well as reverse ones are now derived and hence cannot go
+ out of sync anymore (at least in the vast majority of cases; there are a
+ few special cases to still take care of manually). In the course of this
+ several CPU_ANY_*_FLAGS disappear, requiring adjustment to the
+ assembler's cpu_arch[].
+
+ Note that to retain the correct reverse dependency of AVX512F wrt
+ AVX512-VP2INTERSECT, the latter has the previously missing AVX512F
+ prereq added.
+
+ Note further that to avoid adding the following undue prereqs:
+ * ATHLON, K8, and AMDFAM10 gain CMOV and FXSR,
+ * IAMCU gains 387,
+ auxiliary table entries (including a colon-separated modifier) are
+ introduced in addition to the ones representing from converting the old
+ table.
+
+ To maintain forward-only dependencies between AVX (XOP) and SSE* (SSE4a)
+ (i.e. "nosse" not disabling AVX), reverse dependency tracking is
+ artifically suppressed.
+
+ As a side effect disabling of SSE or SSE2 will now also disable AES,
+ PCLMUL, and SHA (respective elements were missing from
+ CPU_ANY_SSE2_FLAGS).
+
+2022-12-22 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: match target on cpu settings
+ We don't need to enforce larger target settings when the only thing
+ the sim should care about is the CPU target. So reduce most of the
+ target matches to only check the CPU.
+
+ sim: mips: move fpu bitsize defines to top-level configure
+ This drops support for the --enable-sim-float configure option,
+ but it's not clear anyone ever actually used that. Eventually
+ we'll want this to be a runtime option anyways.
+
+ sim: mips: move bitsize defines to top-level configure
+ Since the msb value is always defined as the wordsize-1, stop
+ hardcoding that value directly, and use a CPP value instead.
+
+ sim: mips: move subtarget defines to top-level configure
+ We want to kill off mips/configure entirely. Move this small part
+ out now to get started.
+
+ sim: mips: always resolve active bfd mach dynamically
+ Don't assume that the default bfd that we configured for is the one
+ that is always active when running a program. We already have access
+ to the real runtime value, so use it directly. This simplifies the
+ code quite a bit, and will make it easier to support multiple mach's
+ in a single binary.
+
+ sim: hw-config.h: move generation to top-level
+ In order to compile arch objects from the top-level, we need to
+ generate the hw-config.h header, so move that logic up to the top
+ level first.
+
+ sim: build: hoist lists of hw devices up
+ We need these in the top-level to generate libsim.a, but also in the
+ subdirs to generate hw-config.h. Move it to the local.mk, and pass
+ it down when running recursive make. This avoids duplication, and
+ makes it available to both. We can simplify this once we move the
+ various steps up to the top-level too.
+
+ sim: build: hoist lists of common objects up
+ In order to create libsim.a in the common dir, we need the list of
+ objects for each target. To avoid duplicating the list with the
+ recursive make in each port, pass it down as a variable. This is
+ a temporary hack until the top-level creates libsim.a for ports.
+
+2022-12-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-21 Alan Modra <amodra@gmail.com>
+
+ PR29925, Memory leak in find_abstract_instance
+ The testcase in the PR had a variable with both DW_AT_decl_file and
+ DW_AT_specification, where the DW_AT_specification also specified
+ DW_AT_decl_file. This leads to a memory leak as the file name is
+ malloced and duplicates are not expected.
+
+ I've also changed find_abstract_instance to not use a temp for "name",
+ because that can result in a change in behaviour from the usual last
+ of duplicate attributes wins.
+
+ PR 29925
+ * dwarf2.c (find_abstract_instance): Delete "name" variable.
+ Free *filename_ptr before assigning new file name.
+ (scan_unit_for_symbols): Similarly free func->file and
+ var->file before assigning.
+
+2022-12-21 Andrew Pinski <apinski@marvell.com>
+
+ Fix compiling of top.c
+ When I moved my last patch forward, somehow I missed removing
+ the #endif for the HAVE_LIBMPFR case.
+
+ Committed as obvious after a quick build.
+
+ gdb/ChangeLog:
+ * top.c: Remove the extra #endif which was missed.
+
+2022-12-21 Andrew Pinski <apinski@marvell.com>
+
+ Use toplevel configure for GMP and MPFR for gdb
+ This patch uses the toplevel configure parts for GMP/MPFR for
+ gdb. The only thing is that gdb now requires MPFR for building.
+ Before it was a recommended but not required library.
+ Also this allows building of GMP and MPFR with the toplevel
+ directory just like how it is done for GCC.
+ We now error out in the toplevel configure of the version
+ of GMP and MPFR that is wrong.
+
+ OK after GDB 13 branches? Build gdb 3 ways:
+ with GMP and MPFR in the toplevel (static library used at that point for both)
+ With only MPFR in the toplevel (GMP distro library used and MPFR built from source)
+ With neither GMP and MPFR in the toplevel (distro libraries used)
+
+ Changes from v1:
+ * Updated gdb/README and gdb/doc/gdb.texinfo.
+ * Regenerated using unmodified autoconf-2.69
+
+ Thanks,
+ Andrew Pinski
+
+ ChangeLog:
+ * Makefile.def: Add configure-gdb dependencies
+ on all-gmp and all-mpfr.
+ * configure.ac: Split out MPC checking from MPFR.
+ Require GMP and MPFR if the gdb directory exist.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+ gdb/ChangeLog:
+
+ PR bug/28500
+ * configure.ac: Remove AC_LIB_HAVE_LINKFLAGS
+ for gmp and mpfr.
+ Use GMPLIBS and GMPINC which is provided by the
+ toplevel configure.
+ * Makefile.in (LIBGMP, LIBMPFR): Remove.
+ (GMPLIBS, GMPINC): Add definition.
+ (INTERNAL_CFLAGS_BASE): Add GMPINC.
+ (CLIBS): Exchange LIBMPFR and LIBGMP
+ for GMPLIBS.
+ * target-float.c: Make the code conditional on
+ HAVE_LIBMPFR unconditional.
+ * top.c: Remove code checking HAVE_LIBMPFR.
+ * configure: Regenerate.
+ * config.in: Regenerate.
+ * README: Update GMP/MPFR section of the config
+ options.
+ * doc/gdb.texinfo: Likewise.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
+
+2022-12-21 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/c++: validate 'using' directives based on the current line
+ When asking GDB to print a variable from an imported namespace, we only
+ want to see variables imported in lines that the inferior has already
+ gone through, as is being tested last in gdb.cp/nsusing.exp. However
+ with the proposed change to gdb.cp/nsusing.exp, we get the following
+ failures:
+
+ (gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop
+ print x
+ $9 = 911
+ (gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement
+ next
+ 15 y += x;
+ (gdb) PASS: gdb.cp/nsusing.exp: using namespace M
+ print x
+ $10 = 911
+ (gdb) PASS: gdb.cp/nsusing.exp: print x, only using M
+
+ Showing that the feature wasn't functioning properly, it just so
+ happened that gcc ordered the namespaces in a convenient way.
+ This happens because GDB doesn't take into account the line where the
+ "using namespace" directive is written. So long as it shows up in the
+ current scope, we assume it is valid.
+
+ To fix this, add a new member to struct using_direct, that stores the
+ line where the directive was written, and a new function that informs if
+ the using directive is valid already.
+
+ Unfortunately, due to a GCC bug, the failure still shows up. Compilers
+ that set the declaration line of the using directive correctly (such as
+ Clang) do not show such a bug, so the test includes an XFAIL for gcc
+ code.
+
+ Finally, because the final test of gdb.cp/nsusing.exp has turned into
+ multiple that all would need XFAILs for older GCCs (<= 4.3), and that
+ GCC is very old, if it is detected, the test just exits early.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-12-21 Nick Clifton <nickc@redhat.com>
+
+ Updated Romanian translation for the BFD sub-directory.
+
+ Fix an attempt to allocate an unreasonably large amount of memory when parsing a corrupt ELF file.
+ PR 29924
+ * objdump.c (load_specific_debug_section): Check for excessively
+ large sections.
+
+ Keep the .drectve section when performing a relocateable link.
+ PR 29900
+ * scripttempl/pe.sc: Keep the .drectve section when performing a
+ relocateable link.
+ * scripttempl/pep.sc: Likewise.
+
+2022-12-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: rename CheckRegSize to CheckOperandSize
+ While originally indeed used for register size checking only, the
+ attribute has been used for memory operand size checking as well already
+ for quite a while, with more such uses recently having been added.
+
+ gprofng/testsuite: restrict testing to native configurations
+ The binaries involved in testing gprofng are native ones, and hence a
+ cross build of binutils won't really test intended functionality. Since
+ this testing takes quite a bit of time (typically more than running all
+ of binutils, gas, and ld testsuites together), restrict the testing to
+ native configurations only.
+
+2022-12-21 Alan Modra <amodra@gmail.com>
+
+ enable-non-contiguous-regions warnings
+ The warning about discarded sections in elf_link_input_bfd doesn't
+ belong there since the code is dealing with symbols. Multiple symbols
+ in a discarded section will result in multiple identical warnings
+ about the section. Move the warning to a new function in ldlang.c.
+
+ The patch also tidies the warning quoting of section and file names,
+ consistently using `%pA' and `%pB'. I'm no stickler for one style of
+ section and file name quoting, but they ought to be consistent within
+ a warning, eg. see the first one fixed in ldlang.c, and when a warning
+ is emitted for multiple targets they all ought to use exactly the same
+ format string to reduce translation work. elf64-ppc.c loses the
+ build_one_stub errors since we won't get there before hitting the
+ fatal errors in size_one_stub.
+
+ bfd/
+ * elflink.c (elf_link_input_bfd): Don't warn here about
+ discarded sections.
+ * elf32-arm.c (arm_build_one_stub): Use consistent style in
+ --enable-non-contiguous-regions error.
+ * elf32-csky.c (csky_build_one_stub): Likewise.
+ * elf32-hppa.c (hppa_build_one_stub): Likewise.
+ * elf32-m68hc11.c (m68hc11_elf_build_one_stub): Likewise.
+ * elf32-m68hc12.c (m68hc12_elf_build_one_stub): Likewise.
+ * elf32-metag.c (metag_build_one_stub): Likewise.
+ * elf32-nios2.c (nios2_build_one_stub): Likewise.
+ * elfnn-aarch64.c (aarch64_build_one_stub): Likewise.
+ * xcofflink.c (xcoff_build_one_stub): Likewise.
+ * elf64-ppc.c (ppc_size_one_stub): Likewise.
+ (ppc_build_one_stub): Delete dead code.
+ ld/
+ * ldlang.c (lang_add_section): Use consistent style in
+ --enable-non-contiguous-regions warnings.
+ (size_input_section): Likewise.
+ (warn_non_contiguous_discards): New function.
+ (lang_process): Call it.
+ * testsuite/ld-arm/non-contiguous-arm.d: Update.
+ * testsuite/ld-arm/non-contiguous-arm4.d: Update.
+ * testsuite/ld-arm/non-contiguous-arm7.d: Add
+ --enable-non-contiguous-regions-warnings.
+ * testsuite/ld-arm/non-contiguous-arm7.err: New.
+ * testsuite/ld-powerpc/non-contiguous-powerpc.d: Update.
+ * testsuite/ld-powerpc/non-contiguous-powerpc64.d: Update.
+
+2022-12-21 Alan Modra <amodra@gmail.com>
+
+ PR29922, SHT_NOBITS section avoids section size sanity check
+ PR 29922
+ * dwarf2.c (find_debug_info): Ignore sections without
+ SEC_HAS_CONTENTS.
+
+2022-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: fully merge sim_cpu_base into sim_cpu
+ Now that all ports have migrated to the new framework, drop support
+ for the old sim_cpu_base layout. There's a lot of noise here, so
+ it's been split into a dedicated commit.
+
+ sim: enable common sim_cpu usage everywhere
+ All ports should be migrated now. Drop the SIM_HAVE_COMMON_SIM_CPU
+ knob and require it be used everywhere now.
+
+ sim: or1k: invert sim_cpu storage
+ The cpu.h change is in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: m32r: invert sim_cpu storage
+ The cpu*.h changes are in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: lm32: invert sim_cpu storage
+ The cpu.h change is in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: iq2000: invert sim_cpu storage
+ The cpu.h change is in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: frv: invert sim_cpu storage
+ The cpu.h change is in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: cris: invert sim_cpu storage
+ The cpu*.h changes are in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: bpf: invert sim_cpu storage
+ The cpu.h change is in generated cgen code, but that has been sent
+ upstream too, so the next regen should include it automatically.
+
+ sim: cgen: prep for inverting sim_cpu storage
+ Some common cgen code changes to allow cgen ports to invert their
+ sim_cpu storage one-by-one.
+
+ sim: riscv: invert sim_cpu storage
+
+ sim: pru: invert sim_cpu storage
+
+ sim: example-synacor: invert sim_cpu storage
+
+ sim: h8300: invert sim_cpu storage
+
+ sim: m68hc11: invert sim_cpu storage
+
+ sim: mips: invert sim_cpu storage
+
+ sim: v850: invert sim_cpu storage
+
+ sim: mcore: invert sim_cpu storage
+
+ sim: aarch64: invert sim_cpu storage
+
+ sim: microblaze: invert sim_cpu storage
+
+ sim: avr: invert sim_cpu storage
+
+ sim: moxie: invert sim_cpu storage
+
+ sim: msp430: invert sim_cpu storage
+
+ sim: ft32: invert sim_cpu storage
+
+ sim: bfin: invert sim_cpu storage
+
+2022-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sim_cpu: invert sim_cpu storage
+ Currently all ports have to declare sim_cpu themselves in their
+ sim-main.h and then embed the common sim_cpu_base in it. This
+ dynamic makes it impossible to share common object code among
+ multiple ports because the core data structure is always different.
+
+ Let's invert this relationship: common code declares sim_cpu, and
+ the port uses the new arch_data field for its per-cpu state.
+
+ This is the first in a series of changes: it adds a define to select
+ between the old & new layouts, then converts all the ports that don't
+ need custom state over to the new layout. This includes mn10300 that,
+ while it defines custom fields in its cpu struct, never uses them.
+
+2022-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: move register headers into sim/ namespace [PR sim/29869]
+ These headers define the register numbers for each port to implement
+ the sim_fetch_register & sim_store_register interfaces. While gdb
+ uses these, the APIs are part of the sim, not gdb. Move the headers
+ out of the gdb/ include namespace and into sim/ instead.
+
+ sim: ppc: drop old dgen.c generator
+ The spreg.[ch] files live in the source tree now and are created
+ with the dgen.py script, so we don't need this old tool anymore.
+
+2022-12-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: move spreg.[ch] files to the source tree
+ Simplify the build by moving the generation of these files from
+ build-time (via dgen.c that we have to compile & execute on the
+ build system) to maintainer/release mode (via spreg-gen.py that
+ we only ever execute when the spreg table actually changes). It
+ speeds up the build process and makes it easier for us to reason
+ about & review changes to the code generator.
+
+ The tool is renamed from "dgen" because it's hardcoded to only
+ generated spreg files. It isn't a generalized tool for creating
+ lookup tables.
+
+2022-12-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-20 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix install-strip target
+ The libtool patch broke install-strip of gdb:
+
+ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb
+ transformed_name=`t='s,y,y,'; \
+ echo gdb | sed -e "$t"` ; \
+ if test "x$transformed_name" = x; then \
+ transformed_name=gdb ; \
+ else \
+ true ; \
+ fi ; \
+ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \
+ /bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \
+ gdb \
+ /src/gdb/inst/bin/$transformed_name ; \
+ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \
+ /usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h
+ libtool: install: `/src/gdb/inst/bin/gdb' is not a directory
+ libtool: install: Try `libtool --help --mode=install' for more information.
+
+ Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the
+ gdb executable is not installed with install-strip.
+
+2022-12-20 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ bfd: Discard symbol regardless of warning flag
+ The discard of symbols should be performed whether the warning for
+ the discard is enabled or not.
+ Without this patch, ld would segfault in bfd_section_removed_from_list,
+ called in the if-statement right after this block, as the argument
+ isec->output_section can be NULL.
+
+ Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>
+
+2022-12-20 Alan Modra <amodra@gmail.com>
+
+ PR29915, bfdio.c does not compile with mingw.org's MinGW
+ PR 29915
+ * configure.ac: Add AC_CHECK_DECLS test ___lc_codepage_func.
+ * configure: Regenerate.
+ * config.in: Regenerate.
+ * bfdio.c (___lc_codepage_func): Move declaration to..
+ (_bfd_real_fopen): ..here, and use !HAVE_DECL____LC_CODEPAGE_FUNC.
+
+ Re: x86: remove i386-opc.c
+ Regen opcodes/po/POTFILES.in
+
+2022-12-20 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: change spreg switch table generation to compile-time
+ Simplify the generator by always outputting the switch tables, and
+ leave the choice of whether to use them to the compiler via a -D
+ flag.
+
+2022-12-20 Mike Frysinger <vapier@gentoo.org>
+
+ sim: dv-core: add hw_detach_address method [PR sim/25211]
+ The core device has an attach address method as the root of the tree
+ which calls out to the sim API. But it doesn't have a corresponding
+ detach method which means we just crash if anything tries to detach
+ itself from the core. In practice, the m68hc11 is the only model
+ that actually tries to detach itself on the fly, so no one noticed
+ earlier.
+
+ With this in place, we can delete the existing detach code from the
+ m68hc11 model since it defaults to "passthru" callback which will in
+ turn call the dv-core detach, and they have the same behavior -- call
+ the sim core API to detach from the address space.
+
+ Bug: https://sourceware.org/PR25211
+
+2022-12-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: PR29646 Various warnings
+ gprofng/ChangeLog
+ 2022-12-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29646
+ * common/core_pcbe.c: Fix missingReturn warning.
+ * libcollector/iolib.c: Fix -Waddress warnings.
+ * src/Settings.cc: Likewise.
+ * src/checks.cc: Likewise.
+ * libcollector/linetrace.c: Likewise.
+ * libcollector/iotrace.c: Fix va_end_missing error.
+ * libcollector/libcol_util.c: Fix uninitvar warning.
+ * src/Command.cc: Fix arrayIndexOutOfBounds error.
+ * src/Function.cc: Fix uninitStructMember warning.
+ * src/ipc.cc: Fix -Wwrite-strings warnings.
+
+2022-12-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-19 Tom Tromey <tromey@adacore.com>
+
+ Avoid compiler warning in dwarf-do-refresh
+ The Emacs 28 compiler warns about dwarf-mode.el:
+
+ Warning (comp): dwarf-mode.el:180:32: Warning: Unused lexical argument `ignore'
+
+ This is easily fixed by prepending "_" to the parameter's name.
+
+ binutils/ChangeLog
+ 2022-12-19 Tom Tromey <tromey@adacore.com>
+
+ * dwarf-mode.el (dwarf-do-refresh): Avoid compiler warning.
+
+2022-12-19 Tom Tromey <tom@tromey.com>
+
+ Use bool in bpstat
+ This changes bpstat to use 'bool' rather than 'char', and updates the
+ uses.
+
+ Use bool constants for value_print_options
+ This changes the uses of value_print_options to use 'true' and 'false'
+ rather than integers.
+
+ Remove quick_symbol_functions::relocated
+ quick_symbol_functions::relocated is only needed for psymtabs, and
+ there it is only needed for Rust. However, because we've switched the
+ DWARF reader away from psymtabs, this means there's no longer a need
+ for this method at all.
+
+2022-12-19 Tom Tromey <tom@tromey.com>
+
+ Remove MI version 1
+ MI version 1 is long since obsolete. Several years ago, I filed
+ PR mi/23170 for this. I think it's finally time to remove this.
+ Any users of MI 1 can and should upgrade to a newer version.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
+
+2022-12-19 Tom Tromey <tom@tromey.com>
+
+ Remove vestiges of MI version 0
+ I found a few vestiges of MI version 0 in the test suite. This patch
+ removes them.
+
+2022-12-19 Alan Modra <amodra@gmail.com>
+
+ Tidy PR29893 and PR29908 fix
+ PR 29893
+ PR 29908
+ * dwarf.c (display_debug_addr): Combine dwarf5 unit_length checks.
+ Delete dead code.
+
+2022-12-19 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: fix command lookup in execute_command ()
+ Commit b5661ff2 ("gdb: fix possible use-after-free when
+ executing commands") used lookup_cmd_exact () to lookup
+ command again after its execution to avoid possible
+ use-after-free error.
+
+ However this change broke test gdb.base/define.exp which
+ defines a post-hook for subcommand ("target testsuite").
+ In this case, lookup_cmd_exact () returned NULL because
+ there's no command 'testsuite' in top-level commands.
+
+ This commit fixes this case by looking up the command again
+ using the original command line via lookup_cmd ().
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-19 Nick Clifton <nickc@redhat.com>
+
+ Fix potential illegal memory accesses when parsing corrupt DWARF data.
+ PR 29914
+ * dwarf.c (fetch_indexed_value): Fail if the section is not big
+ enough to contain a header size field.
+ (display_debug_addr): Fail if the computed address size is too big
+ or too small.
+
+ New Romainian translation for the GOLD subdirectory.
+
+2022-12-19 Jan Beulich <jbeulich@suse.com>
+
+ gprofng/testsuite: skip Java test without JDK
+ There's no point in even trying the Java test when gprofng was built
+ without Java support, and when the building of the constituents of the
+ testcase also would fail. On such systems this converts the respective
+ tests from "unresolved" to "unsupported", making the overall testsuite
+ run no longer report failure just because of this.
+
+ gprofng/testsuite: eliminate bogus casts
+ Casting pointers to unsigned int is generally problematic and hence
+ compilers tend to warn about such. While here they're used only in
+ fprintf(), it still seems better to omit such casts, even if only to
+ avoid setting bad precedents.
+
+ gprofng/testsuite: correct line continuation in endcases.c
+ A backslash used to indicate line continuation (in a macro definition
+ here) is not supposed to be followed by blanks or other white space; the
+ end-of-line indicator is to follow immediately.
+
+ gprofng/testsuite: correct names for signal handling tests
+ The signal handling tests spend most of their time in the signal
+ handlers, and hence for profile output to match anything in program
+ output, the respective name fields need to hold the handler function
+ names. This converts both respective tests from "unresolved" to actually
+ succeeding.
+
+ gprofng/testsuite: adjust linking of synprog
+ In order for so_syn.so and so_syx.so to be able to access the main
+ program's "testtime" variable, that variable needs exposing in the
+ dynamic symbol table. Since this is a test program only, do it the brute
+ force way and simply expose all global symbols.
+
+ Arm: break gas dependency on libopcodes
+ gas doesn't use anything from libopcodes (anymore?) - suppress linking
+ in that library.
+
+ x86: omit Cpu prefixes from opcode table
+ These enumerators can be used in only one specific field, and hence the
+ Cpu prefix isn't needed ther for disambiguation / name space separation.
+
+2022-12-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-18 Alan Modra <amodra@gmail.com>
+
+ Comment bfd_get_section_limit_octets and bfd_get_section_alloc_size
+ * bfd.c (bfd_get_section_limit_octets): Add comment.
+ (bfd_get_section_alloc_size): Likewise.
+ * libbfd.c (_bfd_generic_get_section_contents): Use
+ bfd_get_section_limit_octets.
+ * section.c (bfd_get_section_contents): Likewise.
+ * bfd-in2.h: Regenerate.
+
+2022-12-18 Alan Modra <amodra@gmail.com>
+
+ ld bootstrap test in build dir with path containing symlinks
+ This allows the bootstrap test to run if you have a symlink somewhere
+ in the build path directory. $ld depends on $base_dir which is set
+ via tcl [pwd], collapsing the symlink like /usr/bin/pwd, while $objdir
+ contains the symlink.
+
+ * testsuite/ld-bootstrap/bootstrap.exp: Normalize paths when
+ checking for ld build directory.
+
+2022-12-18 Joel Brobecker <brobecker@adacore.com>
+
+ Update gdb/NEWS after GDB 13 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.
+
+2022-12-18 Joel Brobecker <brobecker@adacore.com>
+
+ Bump version to 14.0.50.DATE-git.
+ Now that the GDB 13 branch has been created,
+ this commit bumps the version number in gdb/version.in to
+ 14.0.50.DATE-git
+
+ For the record, the GDB 13 branch was created
+ from commit 71c90666e601c511a5f495827ca9ba545e4cb463.
+
+ 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 14.
+
+2022-12-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-17 Alan Modra <amodra@gmail.com>
+
+ bfd_get_relocated_section_contents allow NULL data buffer
+ This patch removes the bfd_malloc in default_indirect_link_order and
+ bfd_simple_get_relocated_section_contents, pushing the allocation down
+ to bfd_get_relocated_section_contents. The idea is to make use of the
+ allocation done with sanity checking in bfd_get_full_section_contents,
+ which is called by bfd_generic_get_relocated_section_contents.
+
+ Doing this exposed a bug in bfd_get_full_section_contents. With
+ relaxation it is possible that an input section rawsize is different
+ to the section size. In that case we want to use the larger of
+ rawsize (the on-disk size for input sections) and size.
+
+ * reloc.c (bfd_generic_get_relocated_section_contents),
+ * reloc16.c (bfd_coff_reloc16_get_relocated_section_contents),
+ * coff-alpha.c (alpha_ecoff_get_relocated_section_contents),
+ * coff-sh.c (sh_coff_get_relocated_section_contents),
+ * elf-m10200.c (mn10200_elf_get_relocated_section_contents),
+ * elf-m10300.c (mn10300_elf_get_relocated_section_contents),
+ * elf32-avr.c (elf32_avr_get_relocated_section_contents),
+ * elf32-cr16.c (elf32_cr16_get_relocated_section_contents),
+ * elf32-crx.c (elf32_crx_get_relocated_section_contents),
+ * elf32-h8300.c (elf32_h8_get_relocated_section_contents),
+ * elf32-nds32.c (nds32_elf_get_relocated_section_contents),
+ * elf32-sh.c (sh_elf_get_relocated_section_contents),
+ * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents):
+ Handle NULL data buffer.
+ * bfd.c (bfd_get_section_alloc_size): New function.
+ * bfd-in2.h: Regenerate.
+ * compress.c (bfd_get_full_section_contents): Correct section
+ malloc size.
+ * linker.c (default_indirect_link_order): Don't malloc memory
+ here before calling bfd_get_relocated_section_contents.
+ * simple.c (bfd_simple_get_relocated_section_contents): Likewise.
+
+2022-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: elf.c:12621:18: applying zero offset to null pointer
+ That's this line in elf_parse_notes:
+ while (p < buf + size)
+
+ * elf.c (_bfd_elf_make_section_from_shdr): Don't call
+ elf_parse_notes when sh_size is zero.
+
+2022-12-17 Alan Modra <amodra@gmail.com>
+
+ Re: The problem with warning in elf_object_p
+ Commit 5aa0f10c424e added a per_xvec_warn array to provide support for
+ warnings from elf_object_p (and a later patch for warnings from
+ pe_bfd_object_p) to be cached and then only printed if the target
+ matches. It was quite limited in the style of message supported, only
+ one message could be printed, and didn't really meet the stated aim of
+ only warning when a target matches: There are many other errors and
+ warnings that can be emitted by functions called from elf_object_p.
+
+ So this patch extends the error handler functions to support printing
+ to a string buffer, extends per_xvec_warn to support multiple errors/
+ warnings, and hooks this all into bfd_check_format_matches. If
+ bfd_check_format_matches succeeds then any errors/warnings are printed
+ for the matching target. If bfd_check_format_matches fails either due
+ to no match or to multiple matches and only one target vector produced
+ errors, then those errors are printed.
+
+ * bfd.c (MAX_ARGS): Define, use throughout.
+ (print_func): New typedef.
+ (_bfd_doprnt): Add new print param. Replace calls to fprintf
+ with print.
+ (PRINT_TYPE): Similarly.
+ (error_handler_fprintf): Renamed from error_handler_internal.
+ Use _bfd_get_error_program_name. Add fprintf arg. Move code
+ setting up args..
+ (_bfd_doprnt_scan): ..to here. Add ap param.
+ (struct buf_stream): New.
+ (err_sprintf): New function.
+ (error_handler_bfd): New static variable.
+ (error_handler_sprintf): New function.
+ (_bfd_set_error_handler_caching): New function.
+ (_bfd_get_error_program_name): New function.
+ * elfcode.h (elf_swap_shdr_in): Use _bfd_error_handler in
+ warning messages.
+ (elf_object_p): Likewise.
+ * format.c (print_warnmsg): New function.
+ (clear_warnmsg): Rewrite.
+ (null_error_handler): New function.
+ (bfd_check_format_matches): Ignore warnings from recursive calls
+ checking first element of an archive. Use caching error handler
+ otherwise. Print warnings on successful match, or when only one
+ target has emitted warnings/errors.
+ * peicode.h (pe_bfd_object_p): Use _bfd_error_handler in
+ warning messages.
+ * targets.c (per_xvec_warn): Change type of array elements.
+ (struct per_xvec_message): New.
+ (_bfd_per_xvec_warn): Rewrite.
+ * Makefile.am (LIBBFD_H_FILES): Add bfd.c.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Regenerate.
+ * libbfd.h: Regenerate.
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: doc: update spec for the mangled-RA bit in FRE
+ ChangeLog:
+
+ * libsframe/doc/sframe-spec.texi
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: testsuite: add testcase for .cfi_negate_ra_state
+ Add a new test to check that .cfi_negate_ra_state on aarch64 is handled
+ well (a non-empty SFrame section with valid SFrame FREs is generated).
+
+ ChangeLog:
+
+ * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.d: New test.
+ * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise.
+ * testsuite/gas/cfi-sframe/cfi-sframe.exp: Adjust the list
+ accordingly.
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ objdump/readelf: sframe: emit marker for FREs with mangled RA
+ In the textual dump of the SFrame section, when an SFrame FRE recovers a
+ mangled RA, use string "[s]" in the output to indicate that the return
+ address is a signed (mangled) one.
+
+ ChangeLog:
+
+ * libsframe/sframe-dump.c (dump_sframe_func_with_fres): Postfix
+ with "[s]" if RA is signed with authorization code.
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: provide new access API for mangled RA bit
+ include/ChangeLog:
+
+ * sframe-api.h (sframe_fre_get_ra_mangled_p): New declaration.
+
+ ChangeLog:
+
+ * libsframe/sframe.c (sframe_get_fre_ra_mangled_p): New
+ definition.
+ (sframe_fre_get_ra_mangled_p): New static function.
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: add support for .cfi_negate_ra_state
+ DW_CFA_AARCH64_negate_ra_state in aarch64 is multiplexed with
+ DW_CFA_GNU_window_save in the DWARF format.
+
+ Remove the common-empty-4 testcase because the generated SFrame section
+ will not be be empty anymore. A relevant test will be added in a later
+ commit.
+
+ ChangeLog:
+
+ * gas/gen-sframe.c (sframe_v1_set_fre_info): Add new argument
+ for mangled_ra_p.
+ (sframe_set_fre_info): Likewise.
+ (output_sframe_row_entry): Handle mangled_ra_p.
+ (sframe_row_entry_new): Reset mangled_ra_p.
+ (sframe_row_entry_initialize): Initialize mangled_ra_p.
+ (sframe_xlate_do_gnu_window_save): New definition.
+ (sframe_do_cfi_insn): Handle DW_CFA_GNU_window_save.
+ * gas/gen-sframe.h (struct sframe_row_entry): New member.
+ (struct sframe_version_ops): Add a new argument for
+ mangled_ra_p.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Remove test.
+ * gas/testsuite/gas/cfi-sframe/common-empty-4.d: Removed.
+ * gas/testsuite/gas/cfi-sframe/common-empty-4.s: Removed.
+
+2022-12-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe.h: add support for .cfi_negate_ra_state
+ Use the last remaining bit in the 'SFrame FRE info' word to store whether
+ the RA is signed/unsigned with PAC authorization code: this bit is named
+ as the "mangled RA" bit. This bit is still unused for x86-64.
+
+ The behaviour of the mangled-RA info bit in SFrame format closely
+ follows the behaviour of DW_CFA_AARCH64_negate_ra_state in DWARF. During
+ unwinding, whenever an SFrame FRE with non-zero "mangled RA" bit is
+ encountered, it means the upper bits of the return address contain Pointer
+ Authentication code. The unwinder, hence, must use appropriate means to
+ restore LR correctly in such cases.
+
+ include/ChangeLog:
+
+ * sframe.h (SFRAME_V1_FRE_INFO_UPDATE_MANGLED_RA_P): New macro.
+ (SFRAME_V1_FRE_MANGLED_RA_P): Likewise.
+
+2022-12-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-16 Pedro Alves <pedro@palves.net>
+
+ Delay checking whether /proc/pid/mem is writable (PR gdb/29907)
+ As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is
+ writable"), GDB checks if /proc/pid/mem is writable. This is done
+ early at GDB startup, in order to get a consistent warning, instead of
+ a warning that depends on whenever GDB writes to inferior memory.
+
+ PR gdb/29907 points out that some build systems (like QEMU's,
+ apparently) may call 'gdb --version' to check GDB's presence & its
+ version on the system, and that Gentoo's build process has sandboxing
+ which blocks the /proc/pid/mem access and thus GDB warns, which
+ results in build fails.
+
+ To help with that, this patch delays the /proc/pid/mem check until we
+ start or attach to an inferior. Ends up potentially emiting a warning
+ close where we already emit other ptrace- and /proc- related warnings,
+ which just Feels Right.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907
+ Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763
+
+2022-12-16 Nick Clifton <nickc@redhat.com>
+
+ Fix previous delta to allow for compilation on 32-bit systems
+
+2022-12-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix race in gdb.threads/detach-step-over.exp
+ Once in a while I run into:
+ ...
+ FAIL: gdb.threads/detach-step-over.exp: \
+ breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \
+ displaced=off: iter 1: all threads running
+ ...
+
+ In can easily reproduce this by doing:
+ ...
+ # Wait a bit, to give time for the threads to hit the
+ # breakpoint.
+ - sleep 1
+
+ return true
+ ...
+
+ Fix this by counting the running threads in a loop, effectively allowing 10
+ seconds (instead of 1) for the threads to start running, but only sleeping if
+ needed.
+
+ Reduces total execution time from 1m27s to 56s.
+
+ Tested on x86_64-linux.
+
+2022-12-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix crash when getting the value of a label symbol
+ When the source program contains a goto label, it turns out it's
+ actually pretty hard for a user to find out more about that label.
+ For example:
+
+ (gdb) p some_label
+ No symbol "some_label" in current context.
+ (gdb) disassemble some_label
+ No symbol "some_label" in current context.
+ (gdb) x/10i some_label
+ No symbol "some_label" in current context.
+ (gdb) break some_label
+ Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.
+
+ In all cases, some_label is a goto label within the current frame.
+ Only placing a breakpoint on the label worked.
+
+ This all seems a little strange to me, it feels like asking about a
+ goto label would not be an unreasonable thing for a user to do.
+
+ This commit doesn't fix any of the above issues, I mention them just
+ to provide a little context for why the following issue has probably
+ not been seen before.
+
+ It turns out there is one way a user can access the symbol for a goto
+ label, through the Python API:
+
+ python frame = gdb.selected_frame()
+ python frame_pc = frame.pc()
+ python block = gdb.current_progspace().block_for_pc(frame_pc)
+ python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
+ python print(str(symbol.value()))
+ ../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.
+
+ The problem is that label symbols are created using the
+ builtin_core_addr type, which is a pure integer type.
+
+ When GDB tries to fetch the value of a label symbol then we end up in
+ findvar.c, in the function language_defn::read_var_value, in the
+ LOC_LABEL case. From here store_typed_address is called to store the
+ address of the label into a value object with builtin_core_addr type.
+
+ The problem is that store_typed_address requires that the destination
+ type be a pointer or reference, which the builtin_core_addr type is
+ not.
+
+ Now it's not clear what type a goto label address should have, but
+ GCC has an extension that allows users to take the address of a goto
+ label (using &&), in that case the result is of type 'void *'.
+
+ I propose that when we convert the CORE_ADDR value to a GDB value
+ object, we use builtin_func_ptr type instead of builtin_core_addr,
+ this means the result will be of type 'void (*) ()'. The benefit of
+ this approach is that when gdbarch_address_to_pointer is called the
+ target type will be correctly identified as a pointer to code, which
+ should mean any architecture specific adjustments are done correctly.
+
+ We can then cast the new value to 'void *' type with a call to
+ value_cast_pointer, this should not change the values bit
+ representation, but will just update the type.
+
+ After this asking for the value of a label symbol works just fine:
+
+ (gdb) python print(str(symbol.value()))
+ 0x401135 <main+35>
+
+ And the type is maybe what we'd expect:
+
+ (gdb) python print(str(symbol.value().type))
+ void *
+
+2022-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: convert linux-osdata.c from buffer to std::string
+ Replace the use of struct buffer in linux-osdata.c with std::string.
+ There is no change in the logic, so there should be no user-visible
+ change.
+
+ Change-Id: I27f53165d401650bbd0bebe8ed88221e25545b3f
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2022-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: add string_xml_appendf
+ Add a version of buffer_xml_printf (defined in gdbsupport/buffer.{c,h})
+ that appends to an std::string, rather than a struct buffer. Call it
+ "string" rather than "buffer" since it operates on an std::string rather
+ than a buffer. And call it "appendf" rather than "printf", since it
+ appends to and does not replace the string's content. This mirrors
+ string_appendf.
+
+ Place the new version in gdbsupport/xml-utils.h.
+
+ The code is a direct copy of buffer_xml_printf. The old version is
+ going to disappear at some point, which is why I didn't do any effort to
+ share code.
+
+ Change-Id: I30e030627ab4970fd0b9eba3b7e8cec78fa561ba
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2022-12-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: clean up some inefficient std::string usage
+ This commit:
+
+ commit 53cf95c3389a3ecd97276d322e4a60fe3396a201
+ Date: Wed Dec 14 14:17:44 2022 +0000
+
+ gdb: make more use of make_target_connection_string
+
+ Introduced a couple of inefficient uses of std::string, both of which
+ are fixed in this commit.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-16 Nick Clifton <nickc@redhat.com>
+
+ Fix a potential illegal memory access when parsing corrupt DWARF information.
+ PR 29908
+ * dwarf.c (display_debug_addr): Check for corrupt header lengths.
+
+2022-12-16 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/testsuite: add test for Python commands redefining itself
+ This commit adds a test that creates a Python command that redefines
+ itself during its execution. This is to test use-after-free in
+ execute_command ().
+
+ This test needs run with ASan enabled in order to fail when it
+ should.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-16 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] Fix removal of non-address bits for PAuth
+ PR gdb/28947
+
+ The address_significant gdbarch setting was introduced as a way to remove
+ non-address bits from pointers, and it is specified by a constant. This
+ constant represents the number of address bits in a pointer.
+
+ Right now AArch64 is the only architecture that uses it, and 56 was a
+ correct option so far.
+
+ But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
+ from the address space to store the required information. We could also have
+ cases where we're using both PAuth and MTE.
+
+ We could adjust the constant to 48 to cover those cases, but this doesn't
+ cover the case where GDB needs to sign-extend kernel addresses after removal
+ of the non-address bits.
+
+ This has worked so far because bit 55 is used to select between kernel-space
+ and user-space addresses. But trying to clear a range of bits crossing the
+ bit 55 boundary requires the hook to be smarter.
+
+ The following patch renames the gdbarch hook from significant_addr_bit to
+ remove_non_address_bits and passes a pointer as opposed to the number of
+ bits. The hook is now responsible for removing the required non-address bits
+ and sign-extending the address if needed.
+
+ While at it, make GDB and GDBServer share some more code for aarch64 and add a
+ new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
+
+ Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-16 Jan Beulich <jbeulich@suse.com>
+
+ gas: restore Dwarf info generation after macro diagnostic adjustments
+ While 6fdb723799e2 ("gas: re-work line number tracking for macros and
+ their expansions") was meant to leave generated Dwarf as is, it really
+ didn't (and the testcase intended to catch that wasn't covering the case
+ which broke). Its adjustment to buffer_and_nest() didn't go far enough,
+ leading to the "linefile" directive inserted at the top to also be
+ processed later in the PR gas/16908 workaround (which clearly isn't
+ intended - it's being put there for processing during macro expansion
+ only). That unnoticed flaw in turn led me to work around it by a
+ (suspicious to me already at the time) conditional in as_where().
+
+ x86: change representation of extension opcode
+ Having a "None" field in the vast majority of entries is needlessly
+ cluttering the overall table. Instead of this being a separate field,
+ use a representation matching that of Intel SDM and AMD PM for the main
+ use of the field: Append the value after a / as the separator.
+
+2022-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: change xml_escape_text_append's parameter from pointer to reference
+ The passed in string can't be nullptr, it makes more sense to pass in a
+ reference.
+
+ Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3
+
+2022-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove static buffer in command_line_input
+ [I sent this earlier today, but I don't see it in the archives.
+ Resending it through a different computer / SMTP.]
+
+ The use of the static buffer in command_line_input is becoming
+ problematic, as explained here [1]. In short, with this patch [2] that
+ attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
+ hit a case where we read a "define" command line from a script file
+ using command_command_line_input. The command line is stored in
+ command_line_input's static buffer. Inside the define command's
+ execution, we read the lines inside the define using command_line_input,
+ which overwrites the define command, in command_line_input's static
+ buffer. After the execution of the define command, execute_command does
+ a command look up to see if a post-hook is registered. For that, it
+ uses a now stale pointer that used to point to the define command, in
+ the static buffer, causing a use-after-free. Note that the pointer in
+ execute_command points to the dynamically-allocated buffer help by the
+ static buffer in command_line_input, not to the static object itself,
+ hence why we see a use-after-free.
+
+ Fix that by removing the static buffer. I initially changed
+ command_line_input and other related functions to return an std::string,
+ which is the obvious but naive solution. The thing is that some callees
+ don't need to return an allocated string, so this this an unnecessary
+ pessimization. I changed it to passing in a reference to an std::string
+ buffer, which the callee can use if it needs to return
+ dynamically-allocated content. It fills the buffer and returns a
+ pointers to the C string inside. The callees that don't need to return
+ dynamically-allocated content simply don't use it.
+
+ So, it started with modifying command_line_input as described above, all
+ the other changes derive directly from that.
+
+ One slightly shady thing is in handle_line_of_input, where we now pass a
+ pointer to an std::string's internal buffer to readline's history_value
+ function, which takes a `char *`. I'm pretty sure that this function
+ does not modify the input string, because I was able to change it (with
+ enough massaging) to take a `const char *`.
+
+ A subtle change is that we now clear a UI's line buffer using a
+ SCOPE_EXIT in command_line_handler, after executing the command.
+ This was previously done by this line in handle_line_of_input:
+
+ /* We have a complete command line now. Prepare for the next
+ command, but leave ownership of memory to the buffer . */
+ cmd_line_buffer->used_size = 0;
+
+ I think the new way is clearer.
+
+ [1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
+ [2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/
+
+ Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2022-12-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe asan: avoid generating misaligned loads
+ There are two places where unaligned loads were seen on aarch64:
+ - #1. access to the SFrame FRE stack offsets in the in-memory
+ representation/abstraction provided by libsframe.
+ - #2. access to the SFrame FRE start address in the on-disk representation
+ of the frame row entry.
+
+ For #1, we can fix this by reordering the struct members of
+ sframe_frame_row_entry in libsframe/sframe-api.h.
+
+ For #2, we need to default to using memcpy instead, and copy out the bytes
+ to a location for output.
+
+ SFrame format is an unaligned on-disk format. As such, there are other blobs
+ of memory in the on-disk SFrame FRE that are on not on their natural
+ boundaries. But that does not pose further problems yet, because the users
+ are provided access to the on-disk SFrame FRE data via libsframe's
+ sframe_frame_row_entry, the latter has its' struct members aligned on their
+ respective natural boundaries (and initialized using memcpy).
+
+ PR 29856 libsframe asan: load misaligned at sframe.c:516
+
+ ChangeLog:
+
+ PR libsframe/29856
+ * bfd/elf64-x86-64.c: Adjust as the struct members have been
+ reordered.
+ * libsframe/sframe.c (sframe_decode_fre_start_address): Use
+ memcpy to perform 16-bit/32-bit reads.
+ * libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the
+ struct members have been reordered.
+
+ include/ChangeLog:
+
+ PR libsframe/29856
+ * sframe-api.h: Reorder fre_offsets for natural alignment.
+
+2022-12-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: don't delete command files in gdb.base/commands.exp
+ Don't delete the runtime-generated command files. This makes it easier
+ to reproduce tests by hand.
+
+ Change-Id: I4e53484eea216512f1c5d7dfcb5c464b36950946
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-12-15 Tom Tromey <tromey@adacore.com>
+
+ Move streq and compare_cstrings to gdbsupport
+ It seems to me that streq and compare_cstrings belong near the other
+ string utility functions in common-utils.h; and furthermore that streq
+ ought to be inlined. This patch makes this change.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-15 Tom Tromey <tromey@adacore.com>
+
+ Remove subset_compare
+ I stumbled across subset_compare today, and after looking at the
+ callers I realized it could be removed and replaced with calls to
+ startswith.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use gdb_assert not internal_error
+ Spotted a couple of places in findvar.c where we use:
+
+ if ( ! CONDITION )
+ internal_error ("...");
+
+ this commit changes these to be:
+
+ gdb_assert ( CONDITION );
+
+ which I think is better.
+
+ Unless we happen to hit the internal_error calls (which was bad) there
+ should be no user visible changes after this commit.
+
+2022-12-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: some int to bool conversion in remote-sim.c
+ Some obvious int to bool conversion in remote-sim.c, there should be
+ no user visible changes after this commit.
+
+2022-12-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make more use of make_target_connection_string
+ I noticed that we have a function make_target_connection_string which
+ wraps all the logic for creating a string that describes a target
+ connection - but in some places we are not calling this function,
+ instead we duplicate the function's logic.
+
+ This commit cleans this up, and calls make_target_connection_string
+ where possible.
+
+ There should be no user visible changes after this commit.
+
+2022-12-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: int to bool conversion in tracefile.c
+ Some obvious int to bool conversion in tracefile.c.
+
+ Should be no user visible changes after this commit.
+
+2022-12-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp with gcc 4.8.5
+ With gcc 4.8.5, I run into:
+ ...
+ Running gdb.base/condbreak-multi-context.exp ...
+ gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
+ data member initializers only available with -std=c++11 or -std=gnu++11 \
+ [enabled by default]
+ int b = 20;
+ ^
+ ...
+
+ Fix this by making it a static const.
+
+ Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.
+
+2022-12-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/maint: add core file name to 'maint info program-spaces' output
+ Each program space can have an associated core file. Include this
+ information in the output of 'maint info program-spaces'.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: ensure all targets are popped before an inferior is destructed
+ Now that the inferiors target_stack automatically manages target
+ reference counts, we might think that we don't need to unpush targets
+ when an inferior is deleted...
+
+ ...unfortunately that is not the case. The inferior::unpush function
+ can do some work depending on the type of target, so it is important
+ that we still pass through this function.
+
+ To ensure that this is the case, in this commit I've added an assert
+ to inferior::~inferior that ensures the inferior's target_stack is
+ empty (except for the ever present dummy_target).
+
+ I've then added a pop_all_targets call to delete_inferior, otherwise
+ the new assert will fire in, e.g. the gdb.python/py-inferior.exp test.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove the pop_all_targets (and friends) global functions
+ This commit removes the global functions pop_all_targets,
+ pop_all_targets_above, and pop_all_targets_at_and_above, and makes
+ them methods on the inferior class.
+
+ As the pop_all_targets functions will unpush each target, which
+ decrements the targets reference count, it is possible that the target
+ might be closed.
+
+ Right now, closing a target, in some cases, depends on the current
+ inferior being set correctly, that is, to the inferior from which the
+ target was popped.
+
+ To facilitate this I have used switch_to_inferior_no_thread within the
+ new methods. Previously it was the responsibility of the caller to
+ ensure that the correct inferior was selected.
+
+ In a couple of places (event-top.c and top.c) I have been able to
+ remove a previous switch_to_inferior_no_thread call.
+
+ In remote_unpush_target (remote.c) I have left the
+ switch_to_inferior_no_thread call as it is required for the
+ generic_mourn_inferior call.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove decref_target
+ The decref_target function is not really needed. Calling
+ target_ops::decref will just redirect to decref_target anyway, so why
+ not just rename decref_target to target_ops::decref?
+
+ That's what this commit does.
+
+ It's not exactly renaming to target_ops::decref, because the decref
+ functionality is handled by a policy class, so the new name is now
+ target_ops_ref_policy::decref.
+
+ There should be no user visible change after this commit.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have target_stack automate reference count handling
+ This commit changes the target_stack class from using a C style array
+ of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The
+ benefit of this change is that some of the reference counting of
+ target_ops objects is now done automatically.
+
+ This commit fixes a crash in gdb.python/py-inferior.exp where GDB
+ crashes at exit, leaving a core file behind.
+
+ The crash occurs in connpy_connection_dealloc, and is actually
+ triggered by this assert:
+
+ gdb_assert (conn_obj->target == nullptr);
+
+ Now a little aside...
+
+ ... the assert is never actually printed, instead GDB crashes due
+ to calling a pure virtual function. The backtrace at the point of
+ crash looks like this:
+
+ #7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
+ #8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
+ #9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
+ #10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
+ #11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
+ #12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
+ #13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
+ #14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>
+
+ Notice in frame #12 we called target_ops::supports_terminal_ours,
+ however, this is the_dummy_target, which is of type dummy_target,
+ and so we should have called dummy_target::supports_terminal_ours.
+ I believe the reason we ended up in the wrong implementation of
+ supports_terminal_ours (which is a virtual function) is because we
+ made the call during GDB's shut-down, and, I suspect, the vtables
+ were in a weird state.
+
+ Anyway, the point of this patch is not to fix GDB's ability to
+ print an assert during exit, but to address the root cause of the
+ assert. With that aside out of the way, we can return to the main
+ story...
+
+ Connections are represented in Python with gdb.TargetConnection
+ objects (or its sub-classes). The assert in question confirms that
+ when a gdb.TargetConnection is deallocated, the underlying GDB
+ connection has itself been removed from GDB. If this is not true then
+ we risk creating multiple different gdb.TargetConnection objects for
+ the same connection, which would be bad.
+
+ To ensure that we have one gdb.TargetConnection object for each
+ connection, the all_connection_objects map exists, this maps the
+ process_stratum_target object (the connection) to the
+ gdb.TargetConnection object that represents the connection.
+
+ When a connection is removed in GDB the connection_removed observer
+ fires, which we catch with connpy_connection_removed, this function
+ then sets conn_obj->target to nullptr, and removes the corresponding
+ entry from the all_connection_objects map.
+
+ The first issue here is that connpy_connection_dealloc is being called
+ as part of GDB's exit code, which is run after the Python interpreter
+ has been shut down. The connpy_connection_dealloc function is used to
+ deallocate the gdb.TargetConnection Python object. Surely it is
+ wrong for us to be deallocating Python objects after the interpreter
+ has been shut down.
+
+ The reason why connpy_connection_dealloc is called during GDB's exit
+ is that the global all_connection_objects map is still holding a
+ reference to the gdb.TargetConnection object. When the map is
+ destroyed during GDB's exit, the gdb.TargetConnection objects within
+ the map can finally be deallocated.
+
+ The reason why all_connection_objects has contents when GDB exits, and
+ the reason the assert fires, is that, when GDB exits, there are still
+ some connections that have not yet been removed from GDB, that is,
+ they have a non-zero reference count.
+
+ If we take a look at quit_force (top.c) you can see that, for each
+ inferior, we call pop_all_targets before we (later in the function)
+ call do_final_cleanups. It is the do_final_cleanups call that is
+ responsible for shutting down the Python interpreter. The
+ pop_all_targets calls should, in theory, cause all the connections to
+ be removed from GDB.
+
+ That this isn't working indicates that some targets have a non-zero
+ reference count even after this final pop_all_targets call, and
+ indeed, when I debug GDB, that is what I see.
+
+ I tracked the problem down to delete_inferior where we do some house
+ keeping, and then delete the inferior object, which calls
+ inferior::~inferior.
+
+ In neither delete_inferior or inferior::~inferior do we call
+ pop_all_targets, and it is this missing call that means we leak some
+ references to the target_ops objects on the inferior's target_stack.
+
+ In this commit I will provide a partial fix for the problem. I say
+ partial fix, but this will actually be enough to resolve the crash.
+ In a later commit I will provide the final part of the fix.
+
+ As mentioned at the start of the commit message, this commit changes
+ the m_stack in target_stack to hold target_ops_ref objects. This
+ means that when inferior::~inferior is called, and m_stack is
+ released, we automatically decrement the target_ops reference count.
+ With this change in place we no longer leak any references, and now,
+ in quit_force the final pop_all_targets calls will release the final
+ references. This means that the targets will be correctly closed at
+ this point, which means the connections will be removed from GDB and
+ the Python objects deallocated before the Python interpreter shuts
+ down.
+
+ There's a slight oddity in target_stack::unpush, where we std::move
+ the reference out of m_stack like this:
+
+ auto ref = std::move (m_stack[stratum]);
+
+ the `ref' isn't used explicitly, but it serves to hold the
+ target_ops_ref until the end of the scope while allowing the m_stack
+ entry to be reset back to nullptr. The alternative would be to
+ directly set the m_stack entry to nullptr, like this:
+
+ m_stack[stratum] = nullptr;
+
+ The problem here is that when we set the m_stack entry to nullptr we
+ first decrement the target_ops reference count, and then set the array
+ entry to nullptr.
+
+ If the decrement means that the target_ops object reaches a zero
+ reference count then the target_ops object will be closed by calling
+ target_close. In target_close we ensure that the target being closed
+ is not in any inferiors target_stack.
+
+ As we decrement before clearing, then this check in target_close will
+ fail, and an assert will trigger.
+
+ By using std::move to move the reference out of m_stack, this clears
+ the m_stack entry, meaning the inferior no longer contains the
+ target_ops in its target_stack. Now when the REF object goes out of
+ scope and the reference count is decremented, target_close can run
+ successfully.
+
+ I've made use of the Python connection_removed listener API to add a
+ test for this issue. The test installs a listener and then causes
+ delete_inferior to be called, we can then see that the connection is
+ then correctly removed (because the listener triggers).
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/remote: remove some manual reference count handling
+ While working on some other target_ops reference count related code, I
+ spotted that in remote.c we do some manual reference count handling,
+ i.e. we call target_ops::incref and decref_target (which wraps
+ target_ops::decref).
+
+ I think it would be better to make use of gdb::ref_ptr to automate the
+ reference count management.
+
+ So, this commit updates scoped_mark_target_starting in two ways,
+ first, I use gdb::ref_ptr to handle the reference counts. Then,
+ instead of using the scoped_mark_target_starting constructor and
+ destructor to set and reset the starting_up flag, I now use a
+ scoped_restore_tmpl object to set and restore the flag.
+
+ The above changes mean that the scoped_mark_target_starting destructor
+ can be completely removed, and the constructor body is now empty.
+
+ I've also fixed a typo in the class comment.
+
+ The only change in behaviour after this commit is that previously we
+ didn't care what the value of starting_up was, we just set it to true
+ in the constructor and false in the destructor.
+
+ Now, I assert that the flag is initially false, then set the flag true
+ when the scoped_mark_target_starting is created.
+
+ As the starting_up flag is initialized to false then, for the assert
+ to fire, we would need to recursively enter
+ remote_target::start_remote_1, which I don't think is something we
+ should be doing, so I think the new assert is an improvement.
+
+2022-12-14 Alan Modra <amodra@gmail.com>
+
+ Re: ld, gold: remove support for -z bndplt (MPX prefix)
+ Don't attempt to run gold tests with -z bndplt
+
+ * testsuite/Makefile.am (exception_x86_64_bnd_test, bnd_plt_1.sh),
+ (bnd_ifunc_1.sh, bnd_ifunc_2.sh): Delete rules.
+ * testsuite/Makefile.in: Regenerate.
+ * testsuite/bnd_ifunc_1.s: Delete.
+ * testsuite/bnd_ifunc_1.sh: Delete.
+ * testsuite/bnd_ifunc_2.s: Delete.
+ * testsuite/bnd_ifunc_2.sh: Delete.
+ * testsuite/bnd_plt_1.s: Delete.
+ * testsuite/bnd_plt_1.sh: Delete.
+
+2022-12-14 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflow in sh_reloc
+ * coff-sh.c (sh_reloc): Use bfd_reloc_offset_in_range.
+
+2022-12-14 Alan Modra <amodra@gmail.com>
+
+ Fix haiku ld dependencies
+ I noticed after commit 8ad93045ed, "ld, gold: remove support for -z
+ bndplt (MPX prefix)", that some of my builds were failing with
+
+ eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params'
+ params.bndplt = true;
+ ~~~~~~ ^
+
+ * emulparams/aarch64haiku.sh: Use "source_sh" rather than ".".
+ * emulparams/armelf_haiku.sh: Likewise.
+ * emulparams/elf32ppchaiku.sh: Likewise.
+ * emulparams/elf_mipsel_haiku.sh: Likewise.
+ * emulparams/elf_x86_64_haiku.sh: Likewise.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT
+ After the previous commit converted symbol-lookup debug to use the new
+ debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT.
+
+ The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT
+ because symbol-lookup debug is controlled by an 'unsigned int' rather
+ than a 'bool' control variable, we use the numeric value to offer
+ different levels of verbosity for symbol-lookup debug.
+
+ The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing
+ a reference to the bool control variable, and evaluating the variable
+ both on entry, and at exit, this is done in the scoped_debug_start_end
+ class (see gdbsupport/common-debug.h).
+
+ This commit templates scoped_debug_start_end so that the class can
+ accept either a 'bool &' or an invokable object, e.g. a lambda
+ function, or a function pointer.
+
+ The existing scoped_debug_start_end and scoped_debug_enter_exit macros
+ in common-debug.h are updated to support scoped_debug_enter_exit being
+ templated, however, nothing outside of common-debug.h needs to change.
+
+ I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and
+ added a couple of token uses in symtab.c. I didn't want to add too
+ much in this first commit, this is really about updating
+ common-debug.h to support this new functionality.
+
+ Within symtab.h I created a couple of global functions that can be
+ used to query the status of the symbol_lookup_debug control variable,
+ these functions are then used within the two existing macros:
+
+ symbol_lookup_debug_printf
+ symbol_lookup_debug_printf_v
+
+ and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: convert 'set debug symbol-lookup' to new debug printing scheme
+ Convert the implementation of 'set debug symbol-lookup' to the new
+ debug printing scheme.
+
+ In a few places I've updated the debug output to remove places where
+ the printed debug message included the function name, the new debug
+ scheme already adds that, but I haven't done all the possible updates.
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: new test for recent dwarf reader issue
+ This commit provides a test for this commit:
+
+ commit 55fc1623f942fba10362cb199f9356d75ca5835b
+ Date: Thu Nov 3 13:49:17 2022 -0600
+
+ Add name canonicalization for C
+
+ Which resolves PR gdb/29105. My reason for writing this test was a
+ desire to better understand the above commit, my process was to study
+ the commit until I thought I understood it, then write a test to
+ expose the issue. As the original commit didn't have a test, I
+ thought it wouldn't hurt to commit this upstream.
+
+ The problem tested for here is already described in the above commit,
+ but I'll give a brief description here. This description describes
+ GDB prior to the above commit:
+
+ - Builtin types are added to GDB using their canonical name,
+ e.g. "short", not "signed short",
+
+ - When the user does something like 'p sizeof(short)', then this is
+ handled in c-exp.y, and results in a call to lookup_signed_type
+ for the name "int". The "int" here is actually being looked up as
+ the type for the result of the 'sizeof' expression,
+
+ - In lookup_signed_type GDB first adds a 'signed' and looks for that
+ type, so in this case 'signed int', and, if that lookup fails, GDB
+ then looks up 'int',
+
+ - The problem is that 'signed int' is not the canonical name for a
+ signed int, so no builtin type with that name will be found, GDB
+ will then go to each object file in turn looking for a matching
+ type,
+
+ - When checking each object file, GDB will first check the partial
+ symtab to see if the full symtab should be expanded or not.
+ Remember, at this point GDB is looking for 'signed int', there
+ will be no partial symbols with that name, so GDB will not expand
+ anything,
+
+ - However, GDB checks each partial symbol using multiple languages,
+ not just the current language (C in this case), so, when GDB
+ checks using the C++ language, the symbol name is first
+ canonicalized (the code that does this can be found
+ lookup_name_info::language_lookup_name). As the canonical form of
+ 'signed int' is just 'int', GDB then looks for any symbols with
+ the name 'int', most partial symtabs will contain such a symbol,
+ so GDB ends up expanding pretty much every symtab.
+
+ The above commit fixes this by avoiding the use of non-canonical names
+ with C, now the initial builtin type lookup will succeed, and GDB
+ never even considers whether to expand any additional symtabs.
+
+ The test case creates a library that includes char, short, int, and
+ long types, and a test program that links against the library.
+
+ In the test script we start the inferior, but don't allow it to
+ progress far enough that the debug information for the library has
+ been fully expanded yet.
+
+ Then we evaluate some 'sizeof(TYPE)' expressions.
+
+ In the buggy version of GDB this would cause the debug information
+ for the library to be fully expanded, while in the fixed version of
+ GDB this will not be the case.
+
+ We use 'info sources' to determine if the debug information has been
+ fully expanded or not.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
+
+2022-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix readnow detection
+ The following commit broke the readnow detection in the testsuite:
+
+ commit dfaa040b440084dd73ebd359326752d5f44fc02c
+ Date: Mon Mar 29 18:31:31 2021 -0600
+
+ Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
+
+ The testsuite checks if GDB was started with the -readnow flag by
+ using the 'maintenance print objfiles' command, and looking for the
+ string 'faked for "readnow"' in the output. This is implemented in
+ two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
+
+ The following tests all currently depend on this detection:
+
+ gdb.base/maint.exp
+ gdb.cp/nsalias.exp
+ gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
+ gdb.dwarf2/dw2-stack-boundary.exp
+ gdb.dwarf2/dw2-zero-range.exp
+ gdb.dwarf2/gdb-index-nodebug.exp
+ gdb.mi/mi-info-sources.exp
+ gdb.python/py-symbol.exp
+ gdb.rust/traits.exp
+
+ The following test also includes detection of 'readnow', but does the
+ detection itself by checking $::GDBFLAGS for the readnow flag:
+
+ gdb.opt/break-on-_exit.exp
+
+ The above commit removed from GDB the code that produced the 'faked
+ for "readnow"' string, as a consequence the testsuite can no longer
+ correctly spot when readnow is in use, and many of the above tests
+ will fail (at least partially).
+
+ When looking at the above tests, I noticed that gdb.rust/traits.exp
+ does call `readnow`, but doesn't actually use the result, so I've
+ removed the readnow call, this simplifies the next part of this patch
+ as gdb.rust/traits.exp was the only place an extra regexp was passed
+ to the readnow call.
+
+ Next I have rewritten `readnow` to check the $GDBFLAGS for the
+ -readnow flag, and removed the `maintenance print objfiles` check. At
+ least for all the tests above, when using the readnow board, this is
+ good enough to get everything passing again.
+
+ For the `mi_readnow` proc, I changed this to just call `readnow` from
+ gdb.exp, I left the mi_readnow name in place - in the future it might
+ be the case that we want to do some different checks here.
+
+ Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
+ proc.
+
+ With these changes, all of the tests listed above now pass correctly
+ when using the readnow board.
+
+2022-12-14 Li Xu <xuli1@eswincomputing.com>
+
+ RISC-V: Add string length check for operands in AS
+ The current AS accepts invalid operands due to miss of operands length check.
+ For example, "e6" is an invalid operand in (vsetvli a0, a1, e6, mf8, tu, ma),
+ but it's still accepted by assembler. In detail, the condition check "strncmp
+ (array[i], *s, len) == 0" in arg_lookup function passes with "strncmp ("e64",
+ "e6", 2)" in the case above. So the generated encoding is same as that of
+ (vsetvli a0, a1, e64, mf8, tu, ma).
+
+ This patch fixes issue above by prompting an error in such case and also adds
+ a new testcase.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (arg_lookup): Add string length check for operands.
+ * testsuite/gas/riscv/vector-insns-fail-vsew.d: New testcase for an illegal vsew.
+ * testsuite/gas/riscv/vector-insns-fail-vsew.l: Likewise.
+ * testsuite/gas/riscv/vector-insns-fail-vsew.s: Likewise.
+
+2022-12-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: adjust type checking constructs
+ As Alan points out, ASAN takes issue with these constructs, for
+ current_templates being NULL. Wrap them in sizeof(), so the expressions
+ aren't actually evaluated.
+
+2022-12-14 Martin Liska <mliska@suse.cz>
+
+ ld, gold: remove support for -z bndplt (MPX prefix)
+ bfd/ChangeLog:
+
+ * elf-linker-x86.h (struct elf_linker_x86_params): Remove
+ bndplt.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Ignore
+ R_X86_64_PLT32_BND.
+ (elf_x86_64_relocate_section): Similarly here.
+ (elf_x86_64_link_setup_gnu_properties): Ignore bndplt.
+ * elfxx-x86.c: Likewise.
+ * elfxx-x86.h: Likewise.
+
+ gold/ChangeLog:
+
+ * NEWS: Document -z bndplt.
+ * options.h (class General_options): Remove bndplt option.
+ * x86_64.cc (class Output_data_plt_x86_64_bnd): Remove.
+ (Target_x86_64::do_make_data_plt): Do not use
+ Output_data_plt_x86_64_bnd.
+ (Target_x86_64::Scan::get_reference_flags): Likewise.
+ (Target_x86_64::Scan::check_non_pic): Likewise.
+ (Target_x86_64::Scan::local): Likewise.
+ (Target_x86_64::Scan::global): Likewise.
+
+ ld/ChangeLog:
+
+ * NEWS: Document -z bndplt.
+ * emulparams/elf_x86_64.sh: Remove bndplt option.
+ * ld.texi: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp:
+ * testsuite/ld-x86-64/bnd-branch-1-now.d: Removed.
+ * testsuite/ld-x86-64/bnd-branch-1.d: Removed.
+ * testsuite/ld-x86-64/bnd-branch-1.s: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-1-now.d: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-1.d: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-1.s: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-2-now.d: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-2.d: Removed.
+ * testsuite/ld-x86-64/bnd-ifunc-2.s: Removed.
+ * testsuite/ld-x86-64/bnd-plt-1-now.d: Removed.
+ * testsuite/ld-x86-64/bnd-plt-1.d: Removed.
+ * testsuite/ld-x86-64/mpx.exp: Removed.
+ * testsuite/ld-x86-64/mpx1.out: Removed.
+ * testsuite/ld-x86-64/mpx1a.c: Removed.
+ * testsuite/ld-x86-64/mpx1a.rd: Removed.
+ * testsuite/ld-x86-64/mpx1b.c: Removed.
+ * testsuite/ld-x86-64/mpx1c.c: Removed.
+ * testsuite/ld-x86-64/mpx1c.rd: Removed.
+ * testsuite/ld-x86-64/mpx2.out: Removed.
+ * testsuite/ld-x86-64/mpx2a.c: Removed.
+ * testsuite/ld-x86-64/mpx2a.rd: Removed.
+ * testsuite/ld-x86-64/mpx2b.c: Removed.
+ * testsuite/ld-x86-64/mpx2c.c: Removed.
+ * testsuite/ld-x86-64/mpx2c.rd: Removed.
+ * testsuite/ld-x86-64/mpx3.dd: Removed.
+ * testsuite/ld-x86-64/mpx3a.s: Removed.
+ * testsuite/ld-x86-64/mpx3b.s: Removed.
+ * testsuite/ld-x86-64/mpx3n.dd: Removed.
+ * testsuite/ld-x86-64/mpx4.dd: Removed.
+ * testsuite/ld-x86-64/mpx4a.s: Removed.
+ * testsuite/ld-x86-64/mpx4b.s: Removed.
+ * testsuite/ld-x86-64/mpx4n.dd: Removed.
+ * testsuite/ld-x86-64/pr20800a.S: Removed.
+ * testsuite/ld-x86-64/pr20800b.S: Removed.
+ * testsuite/ld-x86-64/pr21038a-now.d: Removed.
+ * testsuite/ld-x86-64/pr21038a.d: Removed.
+ * testsuite/ld-x86-64/pr21038a.s: Removed.
+ * testsuite/ld-x86-64/pr21038b-now.d: Removed.
+ * testsuite/ld-x86-64/pr21038b.d: Removed.
+ * testsuite/ld-x86-64/pr21038b.s: Removed.
+ * testsuite/ld-x86-64/pr21038c-now.d: Removed.
+ * testsuite/ld-x86-64/pr21038c.d: Removed.
+ * testsuite/ld-x86-64/pr21038c.s: Removed.
+
+2022-12-14 Alan Modra <amodra@gmail.com>
+
+ asan: signed integer overflow in display_debug_frames
+ * dwarf.c (struct Frame_Chunk): Make col_offset an int64_t.
+ Adjust all places allocating col_offset and col_type to use
+ the size of the array element rather than the size of a type.
+ (frame_display_row): Adjust printing of col_offset.
+ (display_debug_frames): Factor out multiplication by
+ code_factor and data_factor. Avoid signed overflow. Use
+ 64-bit variables.
+
+2022-12-14 Alan Modra <amodra@gmail.com>
+
+ Don't access freed memory printing objcopy warning
+ abfd->filename will be freed if bfd_close gets far enough to delete
+ the bfd. It's possible to have an error from fclose at this point.
+
+ * objcopy.c (copy_archive): Dup filename before closing bfd for
+ potential use in bfd_nonfatal_message.
+
+2022-12-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-13 Tom Tromey <tromey@adacore.com>
+
+ Fix control-c handling on Windows
+ As Hannes pointed out, the Windows target-async patches broke C-c
+ handling there. Looking into this, I found a few oddities, fixed
+ here.
+
+ First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent.
+ I think this event can be ignored by the inferior, so it's not a great
+ way to interrupt. Instead, using DebugBreakProcess (or a more
+ complicated thing for Wow64) seems better.
+
+ Second, windows_nat_target did not implement the pass_ctrlc method.
+ Implementing this lets us remove the special code to call
+ SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c
+ handling. I believe that this should also fix the race that's
+ described in the comment that's being removed.
+
+ Initially, I thought a simpler version of this patch would work.
+ However, I think what happens is that some other library (I'm not sure
+ what) calls SetConsoleCtrlHandler while gdb is running, and this
+ intercepts and handles C-c -- so that the gdb SIGINT handler is not
+ called. C-break continues to work, presumably because whatever
+ handler is installed ignores it.
+
+ This patch works around this issue by ensuring that the gdb handler
+ always comes first.
+
+2022-12-13 Tom Tromey <tromey@adacore.com>
+
+ Refactor code to check for terminal sharing
+ This refactors the code to check for terminal sharing.
+ is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed,
+ slightly refactored, and moved to posix-hdep.c. A new
+ Windows-specific implementation of this function is added to
+ mingw-hdep.c.
+
+ MSDN has a warning about GetConsoleProcessList
+
+ This API is not recommended and does not have a virtual terminal
+ equivalent. [...] Applications remoting via cross-platform
+ utilities and transports like SSH may not work as expected if
+ using this API.
+
+ However, we believe this isn't likely to be an issue for gdb.
+
+2022-12-13 Tom Tromey <tromey@adacore.com>
+
+ Use gdb::optional for sigint_ours
+ sigint_ours (and sigquit_ours) can be used without being set. Avoid
+ this problem by changing them to gdb::optional and checking that they
+ are in fact set before using the value.
+
+ Rename install_sigint_handler
+ A subsequent patch will introduce a global 'install_sigint_handler'
+ function, so first rename the static one in extension.c.
+
+2022-12-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix s390_linux_nat_target::stopped_by_watchpoint
+ On s390x-linux, I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \
+ Assertion `!target_stopped_by_watchpoint ()' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \
+ breakpoint after the first fork (GDB internal error)
+ ...
+
+ What happens is the follow:
+ - a watchpoint event triggers
+ - the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and
+ it returns true, as expected
+ - the watchpoint event is reported by gdb, and gdb stops
+ - we issue a continue command
+ - a fork event triggers
+ - the event is processed, and during processing that event
+ s390_linux_nat_target::stopped_by_watchpoint is called again, and returns
+ true
+ - the assertion fails, because the function is expected to return false
+
+ The function s390_linux_nat_target::stopped_by_watchpoint returns true the
+ second time, because it looks at the exact same data that was looked at when
+ it was called the first time, and that data hasn't changed.
+
+ There's code in the same function that intends to prevent that from happening:
+ ...
+ /* Do not report this watchpoint again. */
+ memset (&per_lowcore, 0, sizeof (per_lowcore));
+ if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0)
+ perror_with_name (_("Couldn't clear watchpoint status"));
+ ...
+ and that probably used to work for older kernels, but no longer does since
+ linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup").
+
+ Fix this by copying this:
+ ...
+ siginfo_t siginfo;
+ if (!linux_nat_get_siginfo (inferior_ptid, &siginfo))
+ return false;
+ if (siginfo.si_signo != SIGTRAP
+ || (siginfo.si_code & 0xffff) != TRAP_HWBKPT)
+ return false;
+ ...
+ from aarch64_linux_nat_target::stopped_data_address and remove the
+ obsolete watchpoint status clearing code.
+
+ Tested on s390x-linux.
+
+ Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
+
+2022-12-13 H.J. Lu <hjl.tools@gmail.com>
+
+ gold: Remove BND from 64-bit x86-64 IBT PLT
+ Since MPX support has been removed from x86-64 psABI, remove BND from
+ 64-bit IBT PLT by using 32-bit IBT PLT.
+
+ PR gold/29851
+ * x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry):
+ Renamed to ...
+ (Output_data_plt_x86_64_ibt<size>::first_plt_entry): This.
+ (Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed.
+ (Output_data_plt_x86_64_ibt<size>::do_fill_first_plt_entry):
+ Drop the size == 32 check.
+ (Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ...
+ (Output_data_plt_x86_64_ibt<size>::plt_entry): This.
+ (Output_data_plt_x86_64_ibt<64>::plt_entry): Removed.
+ (Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ...
+ (Output_data_plt_x86_64_ibt<size>::aplt_entry): This.
+ (Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed.
+ (Output_data_plt_x86_64_ibt<size>::do_fill_plt_entry): Drop the
+ size == 32 check.
+ (Output_data_plt_x86_64_ibt<size>::fill_aplt_entry): Likewise.
+
+2022-12-13 Tom Tromey <tromey@adacore.com>
+
+ Remove two unnecessary casts
+ A couple of calls to parse_probe_linespec had an unnecessary cast. I
+ suspect this cast was never needed, but once commands were changed to
+ take a 'const' argument, they became completely obsolete. Tested by
+ rebuilding.
+
+2022-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: avoid creating temp file in gdb/testsuite/ directory
+ After this commit:
+
+ commit 33c1395cf5e9deec7733691ba32c450e5c27f757
+ Date: Fri Nov 11 15:26:46 2022 +0000
+
+ gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang
+
+ The gdb.trace/unavailable-dwarf-piece.exp test script was creating a
+ temporary file in the build/gdb/testsuite/ directory, instead of in
+ the expected place in the outputs directory.
+
+ Fix this by adding a call to standard_output_file.
+
+2022-12-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-disasm.exp on s390x
+ On s390x-linux, I run into:
+ ...
+ (gdb) disassemble test^M
+ Dump of assembler code for function test:^M
+ 0x0000000001000638 <+0>: stg %r11,88(%r15)^M
+ 0x000000000100063e <+6>: lgr %r11,%r15^M
+ 0x0000000001000642 <+10>: nop 0^M
+ => 0x0000000001000646 <+14>: nop 0^M
+ 0x000000000100064a <+18>: nop 0^M
+ 0x000000000100064e <+22>: lhi %r1,0^M
+ 0x0000000001000652 <+26>: lgfr %r1,%r1^M
+ 0x0000000001000656 <+30>: lgr %r2,%r1^M
+ 0x000000000100065a <+34>: lg %r11,88(%r11)^M
+ 0x0000000001000660 <+40>: br %r14^M
+ End of assembler dump.^M
+ (gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
+ ...
+
+ The problem is that the test-case expects "nop" but on s390x we have instead
+ "nop\t0".
+
+ Fix this by allowing the insn.
+
+ Tested on s390x-linux and x86_64-linux.
+
+2022-12-13 Jan Beulich <jbeulich@suse.com>
+
+ gas: re-work line number tracking for macros and their expansions
+ The PR gas/16908 workaround aimed at uniformly reporting line numbers
+ to reference macro invocation sites. As mentioned in a comment this may
+ be desirable for small macros, but often isn't for larger ones. As a
+ first step improve diagnostics to report both locations, while aiming at
+ leaving generated debug info unaltered.
+
+ Note that macro invocation context is lost for any diagnostics issued
+ only after all input was processed (or more generally for any use of
+ as_*_where(), as the functions can't know whether the passed in location
+ is related to [part of] the present stack of locations). To maintain the
+ intended workaround behavior for PR gas/16908, a new as_where() is
+ introduced to "look through" macro invocations, while the existing
+ as_where() is renamed (and used in only very few places for now). Down
+ the road as_where() will likely want to return a list of (file,line)
+ pairs.
+
+2022-12-13 Jan Beulich <jbeulich@suse.com>
+
+ Arm: avoid unhelpful uses of .macro in testsuite
+ Macros with just a single use site are a little pointless to have, and
+ even in further cases .irp is more suitable for the purpose. Expand such
+ inline, avoiding the need to touch the testcases when diagnostics are
+ changed for code resulting from macro expansion.
+
+ While there also make what was "iter_mla" in sp-usage-thumb2-relax cover
+ smlatt as well, rather than testing smlabt twice.
+
+2022-12-13 Tom Tromey <tom@tromey.com>
+
+ Fix crash in is_nocall_function
+ is_nocall_function anticipates only being called for a function or a
+ method. However, PR gdb/29871 points out a situation where an unusual
+ expression -- but one that parses to a valid, if extremely weird,
+ function call -- breaks this assumption.
+
+ This patch changes is_nocall_function to remove this assert and
+ instead simply return 'false' in this case.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
+
+2022-12-13 Johnson Sun <j3.soon777@gmail.com>
+
+ Replace gdbpy_should_stop with gdbpy_breakpoint_cond_says_stop
+ In 2014, the function `gdbpy_should_stop' has been replaced with
+ `gdbpy_breakpoint_cond_says_stop'
+
+ This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the
+ comments.
+
+ Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014':
+
+ * python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
+ from gdbpy_should_stop. Change result type to enum scr_bp_stop.
+
+ Change-Id: I0ef3491ce5e057c5e75ef8b569803b30a5838575
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-13 Alan Modra <amodra@gmail.com>
+
+ asan: mips_hi16_list segfault in bfd_get_section_limit_octets
+ static variables like mips_hi16_list are nasty for applications using
+ bfd. It is possible when opening and closing bfds with mis-matched
+ hi/lo relocs to leave a stale section pointer on the list. That can
+ cause a segfault if multiple bfds are being processed.
+
+ Tidying the list when closing is sufficient to stop this happening
+ (and fixes small memory leaks). This patch goes further and moves
+ mips_hi16_list to where it belongs in the bfd tdata.
+
+ * elf32-mips.c (bfd_elf32_close_and_cleanup(: Define.
+ * elf64-mips.c (bfd_elf64_close_and_cleanup): Define.
+ * elfn32-mips.c (bfd_elf32_close_and_cleanup(: Define.
+ * elfxx-mips.c (struct mips_hi16): Move earlier.
+ (mips_hi16_list): Move to..
+ (struct mips_elf_obj_tdata): ..here.
+ (_bfd_mips_elf_close_and_cleanup): New function.
+ (_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc),
+ (_bfd_elf_mips_get_relocated_section_contents): Adjust uses of
+ mips_hi16_list.
+ * elfxx-mips.h (_bfd_mips_elf_close_and_cleanup): Declare.
+
+2022-12-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-12 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libctf: remove unnecessary zstd constructs
+ This patch is essentially a revert of
+ commit-id: 8818c80cbd4116ef5af171ec47c61167179e225c
+ (libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true)
+
+ As the specific configure check now uses libtool, this explicit mention of the
+ dependency $ZSTD_LIBS is not needed anymore.
+
+ ChangeLog:
+
+ * libctf/Makefile.in: Regenerated.
+ * libctf/aclocal.m4: Likewise.
+ * libctf/config.h.in: Likewise.
+ * libctf/configure: Likewise.
+ * libctf/configure.ac: Remove ZSTD_LIBS from LIBS. Cleanup
+ unused AC_ZSTD.
+
+2022-12-12 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libctf: remove AC_CONFIG_MACRO_DIR
+ ACLOCAL_AMFLAGS is being set already. So using AC_CONFIG_MACRO_DIR is
+ unnecessary.
+
+ ChangeLog:
+
+ * libctf/configure: Regenerated.
+ * libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage.
+
+2022-12-12 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libctf: remove unnecessary zlib constructs
+ This dependency is managed via libtool. So explicit addition to LDFLAGS
+ and LIBS is not necessary anymore.
+
+ ChangeLog:
+
+ * libctf/configure: Regenerated.
+ * libctf/configure.ac: remove zlib from LDFLAGS and LIBS.
+
+2022-12-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp
+ On s390x-linux, I run into:
+ ...
+ (gdb) print {unsigned char}{65}^M
+ $749 = 0 '\000'^M
+ (gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
+ ...
+
+ In contrast, on x86_64-linux, we have:
+ ...
+ (gdb) print {unsigned char}{65}^M
+ $749 = 65 'A'^M
+ (gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
+ ...
+
+ The first problem here is that the test is supposed to be a regression test
+ for PR20630, which can be reproduced (for an unfixed gdb) like this:
+ ...
+ (gdb) p {unsigned char[]}{0x17}
+ gdbtypes.c:4641: internal-error: copy_type: \
+ Assertion `TYPE_OBJFILE_OWNED (type)' failed.
+ ...
+ but it's not due to insufficient quoting (note the dropped '[]').
+
+ That's easy to fix, but after that we have on s390 (big endian):
+ ...
+ (gdb) print {unsigned char[]}{65}^M
+ $749 = ""^M
+ ...
+ and on x86_64 (little endian):
+ ...
+ (gdb) print {unsigned char[]}{65}^M
+ $749 = "A"^M
+ ...
+
+ Fix this by using 0xffffffff, such that in both cases we have:
+ ...
+ (gdb) print {unsigned char[]}{0xffffffff}^M
+ $749 = "\377\377\377\377"^M
+ ...
+
+ Tested on x86_64-linux and s390x-linux.
+
+2022-12-12 Alan Modra <amodra@gmail.com>
+
+ PR29893, buffer overflow in display_debug_addr
+ PR 29893
+ * dwarf.c (display_debug_addr): Sanity check dwarf5 unit_length
+ field. Don't read past end.
+
+2022-12-12 Tom Tromey <tom@tromey.com>
+
+ Another Rust operator precedence bug
+ My earlier patch to fix PR rust/29859 introduced a new operator
+ precedence bug in the Rust parser. Assignment operators are
+ right-associative in Rust. And, while this doesn't often matter, as
+ Rust assignments always have the value (), still as a matter of
+ principle we should get this correct.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859
+
+2022-12-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/write_mem.exp for big endian
+ On s390x-linux (big endian), I run into:
+ ...
+ (gdb) x /xh main^M
+ 0x1000638 <main>: 0x0000^M
+ (gdb) FAIL: gdb.base/write_mem.exp: x /xh main
+ ...
+
+ In contrast, on x86_64-linux (little endian), we have the expected:
+ ...
+ (gdb) x /xh main^M
+ 0x4004a7 <main>: 0x4242^M
+ (gdb) PASS: gdb.base/write_mem.exp: x /xh main
+ ...
+
+ The problem is that the test-case hard-codes expectations about endiannes by
+ writing an int-sized value (4 bytes in this case) and then printing only a
+ halfword by using "/h" (so, two bytes).
+
+ If we print 4 bytes, we have for s390x:
+ ...
+ 0x1000638 <main>: 0x00004242^M
+ ...
+ and for x86_64:
+ ...
+ 0x4004a7 <main>: 0x00004242^M
+ ...
+
+ Fix this by removing the "/h".
+
+ Tested on x86_64-linux and s390x-linux.
+
+2022-12-12 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: fix possible use-after-free when executing commands
+ In principle, `execute_command()` does following:
+
+ struct cmd_list_element *c;
+ c = lookup_cmd ( ... );
+ ...
+ /* If this command has been pre-hooked, run the hook first. */
+ execute_cmd_pre_hook (c);
+ ...
+ /* ...execute the command `c` ...*/
+ ...
+ execute_cmd_post_hook (c);
+
+ This may lead into use-after-free error. Imagine the command
+ being executed is a user-defined Python command that redefines
+ itself. In that case, struct `cmd_list_element` pointed to by
+ `c` is deallocated during its execution so it is no longer valid
+ when post hook is executed.
+
+ To fix this case, this commit looks up the command once again
+ after it is executed to get pointer to (possibly newly allocated)
+ `cmd_list_element`.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: further re-work insn/suffix recognition to also cover MOVSX
+ PR gas/29524
+
+ Having templates with a suffix explicitly present has always been
+ quirky. After prior adjustment all that's left to also eliminate the
+ anomaly from move-with-sign-extend is to consolidate the insn templates
+ and to make may_need_pass2() cope (plus extend testsuite coverage).
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop (now) stray IsString
+ The need for them on the operand-less string insns has gone away with
+ the removal of maybe_adjust_templates() and associated logic. Since
+ i386_index_check() needs adjustment then anyway, take the opportunity
+ and also simplify it, possible again as a result of said removal (plus
+ the opcode template adjustments done here).
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: move bad-use-of-TLS-reloc check
+ Having it in match_template() is unhelpful. Neither does looking for the
+ next template to possibly match make any sense in that case, nor is the
+ resulting diagnostic making clear what the problem is.
+
+ While moving the check, also generalize it to include all SIMD and VEX-
+ encoded insns. This way an existing conditional can be re-used in
+ md_assemble(). Note though that this still leaves a lof of insns which
+ are also wrong to use with these relocations.
+
+ Further fold the remaining check (BFD_RELOC_386_GOT32) with the XRELEASE
+ related one a few lines down. This again allows re-using an existing
+ conditional.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: allow HLE store of accumulator to absolute 32-bit address
+ In commit 1212781b35c9 ("ix86: allow HLE store of accumulator to
+ absolute address") I was wrong to exclude 64-bit code. Dropping the
+ check also leads to better diagnostics in 64-bit code ("MOV", after
+ all, isn't invalid with "XRELEASE").
+
+ While there also limit the amount of further checks done: The operand
+ type checks that were there were effectively redundant with other ones
+ anyway, plus it's quite fine to also have "xrelease mov <disp>, %eax"
+ look for the next MOV template (in fact again also improving
+ diagnostics).
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ ix86: don't recognize/derive Q suffix in the common case
+ Have its use, except where actually legitimate, result in the same "only
+ supported in 64-bit mode" diagnostic as emitted for other 64-bit only
+ insns. Also suppress deriving of the suffix in Intel mode except in the
+ legitimate cases. This in exchange allows dropping the respective code
+ from match_template().
+
+ To maintain reasonable diagnostics (in particular to avoid "`mov' is
+ only supported in 64-bit mode" on the SIMD forms of MOVQ) we need to
+ defer parse_insn()'s emitting of errors unrelated to prefix parsing.
+ Utilize i.error just like match_template() does.
+
+ Oddly enough despite gcc's preference towards FILDQ and FIST{,T}Q we
+ had no testcase whatsoever for these. Therefore such tests are being
+ added. Note that the removed line in the x86-64-lfence-load testcase
+ was redundant with the exact same one a few lines up.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-work insn/suffix recognition
+ Having templates with a suffix explicitly present has always been
+ quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
+ a suitable template _and_ didn't itself already need to trim off a
+ suffix to find a match at all. This requires error reporting adjustments
+ (albeit luckily fewer than I was afraid might be necessary), as errors
+ previously reported during matching now need deferring until after the
+ 2nd pass (because, obviously, we must not emit any error if the 2nd pass
+ succeeds). While also related to PR gas/29524, it was requested that
+ move-with-sign-extend be left as broken as it always was.
+
+ PR gas/29525
+ Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
+ templates taking operands, mixed IsString/non-IsString template groups
+ (with memory operands) cannot occur anymore. With that
+ maybe_adjust_templates() becomes unnecessary (and is hence being
+ removed).
+
+ PR gas/29526
+ Note further that while the additions to the intel16 testcase aren't
+ really proper Intel syntax, we've been permitting all of those except
+ for the MOVD variant. The test therefore is to avoid re-introducing such
+ an inconsistency.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: constify parse_insn()'s input
+ The function doesn't alter its input buffer: Reflect this in its
+ prototype. To avoid using any kind of cast, simply calculate the update
+ of "line" from the function's input and output.
+
+ x86: revert disassembler parts of "x86: Allow 16-bit register source for LAR and LSL"
+ This reverts the disassembler parts of 859aa2c86dc9 ("x86: Allow 16-bit
+ register source for LAR and LSL"), adjusting testcases as necessary.
+ That change was itself a partial revert of c9f5b96bdab0 ("x86: correct
+ handling of LAR and LSL"), without actually saying so. While the earlier
+ commit was properly agreed upon, the partial revert was not, and hence
+ should not have been committed. This is even more so that the revert
+ part of that change wasn't even necessary to address PR gas/29844.
+
+2022-12-12 Alan Modra <amodra@gmail.com>
+
+ PR29892, Field file_table of struct module is uninitialized
+ PR 29892
+ * vms-alphs.c (new_module): Use bfd_zmalloc to alloc file_table.
+ (parse_module): Rewrite file_table reallocation code and clear.
+
+ Lack of bounds checking in vms-alpha.c parse_module
+ PR 29873
+ PR 29874
+ PR 29875
+ PR 29876
+ PR 29877
+ PR 29878
+ PR 29879
+ PR 29880
+ PR 29881
+ PR 29882
+ PR 29883
+ PR 29884
+ PR 29885
+ PR 29886
+ PR 29887
+ PR 29888
+ PR 29889
+ PR 29890
+ PR 29891
+ * vms-alpha.c (parse_module): Make length param bfd_size_type.
+ Delete length == -1 checks. Sanity check record_length.
+ Sanity check DST__K_MODBEG, DST__K_RTNBEG, DST__K_RTNEND lengths.
+ Sanity check DST__K_SOURCE and DST__K_LINE_NUM elements
+ before accessing.
+ (build_module_list): Pass dst_section size to parse_module.
+
+2022-12-12 Alan Modra <amodra@gmail.com>
+
+ PR29872, uninitialised value in display_debug_lines_decoded dwarf.c:5413
+ Plus segvs if the C-library doesn't handle printf %s of NULL.
+
+ PR 29872
+ * dwarf.c (null_name): New function.
+ (process_debug_info): Use it here..
+ (display_debug_lines_raw): ..and here..
+ (display_debug_lines_decoded): ..and here. xcalloc directory_table.
+ Simplify xcalloc of file_table.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ gas/codeview: avoid "shadowing" of glibc function name
+ While not "index" this time, old enough glibc also has an (unguarded)
+ declaration of fileno() in stdio.h, which triggers a "shadows a global
+ declaration" warning with our choice of warning level and with at least
+ some gcc versions.
+
+ x86: generate template sets data at build time
+ Speed up gas startup by avoiding runtime allocation of the instances of
+ type "templates". At the same time cut the memory requirement to just
+ very little over half (not even accounting for any overhead
+ notes_alloc() may incur) by reusing the "end" slot of a preceding entry
+ for the "start" slot of the subsequent one.
+
+ x86: drop sentinel from i386_optab[]
+ Now that the table is local to gas, ARRAY_SIZE() can be used to
+ determine the end of the table. Re-arrange the processing loop in
+ md_begin() accordingly, at the same time folding the two calls to
+ notes_alloc() into just one.
+
+ x86: add generated tables dependency check to gas
+ As requested by H.J., just for the sake of people potentially building
+ in gas/ alone, add a check that the generated files in opcodes/ are
+ actually up-to-date. Personally I think this should at best be a
+ warning, but I can see how this may not be easily noticable among other
+ make output (depending in particular on the verbosity level).
+
+ x86: break gas dependency on libopcodes
+ gas doesn't use anything from libopcodes anymore - suppress linking in
+ that library.
+
+ x86: remove i386-opc.c
+ Remove the now empty i386-opc.c. To compensate, tie table generation in
+ opcodes/ to the building of i386-dis.o, despite the file not really
+ depending on the generated data.
+
+2022-12-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: instantiate i386_{op,reg}tab[] in gas instead of in libopcodes
+ Unlike many other architectures, x86 does not share an opcode table
+ between assembly and disassembly. Any consumer of libopcodes would only
+ ever access one of the two. Since gas is the only consumer of the
+ assembly data, move it there. While doing so mark respective entities
+ "static" in i386-gen (we may want to do away with i386_regtab_size
+ altogether).
+
+ This also shrinks the number of relocations to be processed for
+ libopcodes.so by about 30%.
+
+2022-12-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-11 Alan Modra <amodra@gmail.com>
+
+ PR29870, objdump SEGV in display_debug_lines_decoded dwarf.c:5524
+ DWARF5 directory and file table allow more opportunity for fuzzers
+ to break things. There are likely other places in dwarf.c that should
+ be fixed too.
+
+ PR 29870
+ * dwarf.c (display_debug_lines_decoded): Handle NULL file_table
+ name entry.
+
+2022-12-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix larl handling in s390_displaced_step_fixup
+ On s390x-linux with target board unix/-m31, I run into:
+ ...
+ (gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length
+ print ptr^M
+ $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
+ (gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr
+ ...
+
+ A minimal example is:
+ ...
+ $ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+ +file scm-lazy-string
+ +break main
+ Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23.
+ +run
+
+ Breakpoint 1, main () at scm-lazy-string.c:23
+ 23 const char *ptr = "pointer";
+ +step
+ 24 const char array[] = "array";
+ +print ptr
+ $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
+ ...
+
+ If we delete the breakpoint after running to it, we have instead the expected:
+ ...
+ +delete
+ +step
+ 24 const char array[] = "array";
+ +print ptr
+ $1 = 0x4006b0 "pointer"
+ ...
+
+ The problem is in displaced stepping, forced by the presence of the breakpoint,
+ when stepping over this insn:
+ ...
+ 0x4005d2 <main+10> larl %r1,0x4006b0
+ ...
+
+ With normal stepping we have:
+ ...
+ (gdb) p /x $r1
+ $2 = 0x3ff004006b0
+ ...
+ but with displaced stepping we have instead (note the 0x80000000 difference):
+ ...
+ (gdb) p /x $r1
+ $1 = 0x3ff804006b0
+ (gdb)
+ ...
+
+ The difference comes from this code in s390_displaced_step_fixup:
+ ...
+ /* Handle LOAD ADDRESS RELATIVE LONG. */
+ else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2))
+ {
+ /* Update PC. */
+ regcache_write_pc (regs, from + insnlen);
+ /* Recompute output address in R1. */
+ regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
+ amode | (from + i2 * 2));
+ }
+ ...
+ where the "amode |" adds the 0x80000000.
+
+ Fix this by removing the "amode |".
+
+ Tested on s390-linux, with native and target board unix/-m31.
+
+ Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
+
+2022-12-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ objdump: sframe: fix memory leaks
+ ChangeLog:
+
+ * binutils/objdump.c (dump_section_sframe): free up contents and
+ SFrame decoder context on exit.
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: rename API sframe_fde_func_info to sframe_fde_create_func_info
+ The new name better reflects the purpose of the function.
+
+ ChangeLog:
+
+ * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use new
+ name.
+ * libsframe/sframe.c (sframe_fde_create_func_info): Rename
+ sframe_fde_func_info to this.
+ * libsframe/testsuite/libsframe.encode/encode-1.c: Use new name.
+
+ include/ChangeLog:
+
+ * sframe-api.h (sframe_fde_create_func_info): Rename
+ sframe_fde_func_info to this.
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: sframe: fine tune the fragment fixup for SFrame func info
+ SFrame function info is an unsigned 8-bit field comprising of the following
+ (from LSB to MSB):
+ - 4-bits: FRE type
+ - 1-bit: FRE start address encoding
+ - 3-bits: Unused
+
+ At the moment, the most-significat 4-bits are zero (The FRE start
+ address encoding of SFRAME_FDE_TYPE_PCINC has a value of zero, and the upper
+ 3-bits are unused). So the current implementation works without this patch.
+
+ To be precise, however, the fragment fixup logic is meant to fixup only the
+ least-significant 4-bits (i.e., only the FRE type needs to be updated
+ according to the function size).
+
+ This patch makes the gas implementation a bit more resilient: In the
+ future, when the format does evolve to make use of the currently unused
+ 3-bits in various ways, the values in those 3-bits can be propagated
+ unchanged while the fragment fixup continues to update the lowermost
+ 4-bits to indicate the selected FRE type.
+
+ ChangeLog:
+
+ * gas/gen-sframe.c (create_func_info_exp): New definition.
+ (output_sframe_funcdesc): Call create_func_info_exp.
+ * gas/sframe-opt.c (sframe_estimate_size_before_relax): The
+ associated fragment uses O_modulus now.
+ (sframe_convert_frag): Adjust the fragment fixup code according
+ to the new composite exp.
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: gas: libsframe: define constants and remove magic numbers
+ Define constants in sframe.h for the various limits associated with the
+ range of offsets that can be encoded in the start address of an SFrame
+ FRE. E.g., sframe_frame_row_entry_addr1 is used when start address
+ offset can be encoded as 1-byte unsigned value.
+
+ Update the code in gas to use these defined constants as it checks for
+ these limits, and remove the usage of magic numbers.
+
+ ChangeLog:
+
+ * gas/sframe-opt.c (sframe_estimate_size_before_relax):
+ (sframe_convert_frag): Do not use magic numbers.
+ * libsframe/sframe.c (sframe_calc_fre_type): Likewise.
+
+ include/ChangeLog:
+
+ * sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): New constant.
+ (SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
+ (SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe.h: make some macros more precise
+ include/ChangeLog:
+
+ * sframe.h (SFRAME_V1_FUNC_INFO): Use specific bits only.
+ (SFRAME_V1_FRE_INFO): Likewise.
+
+2022-12-09 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libsframe: minor formatting nits
+ ChangeLog:
+
+ * libsframe/sframe.c: Fix formatting nits.
+
+2022-12-09 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] Add TPIDR2 register support for Linux
+ With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
+ it will be added to the existing NT_ARM_TLS register set. Kernel patches are
+ being reviewed here:
+
+ https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
+
+ From GDB's perspective, we handle it in a similar way to the existing TPIDR
+ register. But we need to consider cases of systems that only have TPIDR and
+ systems that have both TPIDR and TPIDR2.
+
+ With that in mind, the following patch adds the required code to support
+ TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
+ dynamically-generated target description as opposed to a static target
+ description containing only TPIDR.
+
+ That means we can remove the gdb/features/aarch64-tls.xml file and replace the
+ existing gdb/features/aarch64-tls.c auto-generated file with a new file that
+ dynamically generates the target description containing either TPIDR alone or
+ TPIDR and TPIDR2.
+
+ In the future, when *BSD's start to support this register, they can just
+ enable it as is being done for the AArch64 Linux target.
+
+ The core file read/write code has been updated to support TPIDR2 as well.
+
+ On GDBserver's side, there is a small change to the find_regno function to
+ expose a non-throwing version of it.
+
+ It always seemed strange to me how find_regno causes the whole operation to
+ abort if it doesn't find a particular register name. The patch moves code
+ from find_regno into find_regno_no_throw and makes find_regno call
+ find_regno_no_throw instead.
+
+ This allows us to do register name lookups to find a particular register
+ number without risking erroring out if nothing is found.
+
+ The patch also adjusts the feature detection code for aarch64-fbsd, since
+ the infrastructure is shared amongst all aarch64 targets. I haven't added
+ code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
+ that will happen.
+
+2022-12-09 Alan Modra <amodra@gmail.com>
+
+ PR28306, segfault in _bfd_mips_elf_reloc_unshuffle
+ Access to section data during relocation processing should be bounds
+ checked, as it is in bfd_perform_relocation. bfd_perform_relocation
+ does these checks after any special_function is called. So a reloc
+ special_function needs to do its own bounds checking before accessing
+ section data. This patch adds many such checks to the mips backend.
+
+ Checking mips relocs is not without some difficulty. See the comment
+ in _bfd_mips_reloc_offset_in_range. In a multitple reloc sequence
+ applied to the same location, relocs that may appear somewhere other
+ than the last one of the sequence need to be treated specially since
+ they apply to the addend for the next relocation rather than the
+ section contents. If the addend is in the section then it needs to be
+ checked but not when the addend is in the reloc. check_inplace
+ handles this situation. _bfd_mips_reloc_offset_in_range with
+ check_shuffle handles the case where contents are shuffled before
+ applying the relocation.
+
+ PR 28306
+ * elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Check reloc
+ address using _bfd_mips_reloc_offset_in_range.
+ (gprel32_with_gp, mips16_gprel_reloc): Likewise.
+ * elf64-mips.c (mips_elf64_gprel32_reloc): Likewise.
+ (mips16_gprel_reloc): Likewise.
+ * elfn32-mips.c (mips16_gprel_reloc): Likewise.
+ (gprel32_with_gp): Check reloc address using
+ bfd_reloc_offset_in_range.
+ * elfxx-mips.h (enum reloc_check): Define.
+ (_bfd_mips_reloc_offset_in_range): Declare.
+ * elfxx-mips.c (needs_shuffle): New function.
+ (_bfd_mips_elf_reloc_unshuffle, _bfd_mips_elf_reloc_shuffle): Use it.
+ (_bfd_mips_reloc_offset_in_range): New function.
+ (_bfd_mips_elf_gprel16_with_gp): Move reloc address checks to
+ partial_inplace handling. Use bfd_reloc_offset_in_range.
+ (_bfd_mips_elf_lo16_reloc): Check reloc address using
+ bfd_reloc_offset_in_range.
+ (_bfd_mips_elf_generic_reloc): Check reloc address using
+ _bfd_mips_reloc_offset_in_range.
+ (mips_elf_calculate_relocation): Check reloc address before calling
+ mips_elf_nullify_got_load.
+ (_bfd_mips_elf_check_relocs): Likewise.
+ (mips_elf_read_rel_addend): Add sec param, check reloc address
+ before reading. Adjust callers.
+ (mips_elf_add_lo16_rel_addend): Add sec param, adjust callers.
+
+2022-12-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-symtab.exp for ppc64le
+ On powerpc64le-linux, I run into:
+ ...
+ (gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2
+ guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M
+ = #f^M
+ (gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
+ ...
+
+ The problem is as follows: the instructions for the call to func2 are:
+ ...
+ 1000070c: 39 00 00 48 bl 10000744 <func1>
+ 10000710: 00 00 00 60 nop
+ 10000714: 59 00 00 48 bl 1000076c <func2>
+ 10000718: 00 00 00 60 nop
+ 1000071c: 00 00 20 39 li r9,0
+ ...
+ and the corresponding line number info is:
+ ...
+ scm-symtab.c:
+ File name Line number Starting address View Stmt
+ scm-symtab.c 42 0x1000070c x
+ scm-symtab.c 43 0x10000714 x
+ scm-symtab.c 44 0x1000071c x
+ ...
+
+ The test-case looks at the line numbers for two insns:
+ - the insn of the call to func2 (0x10000714), and
+ - the insn after that (0x10000718),
+ and expects the line number of the latter to be greater than the line number
+ of the former.
+
+ However, both insns have the same line number: 43.
+
+ Fix this by replacing ">" with ">=".
+
+ Tested on x86_64-linux and powerpc64le-linux.
+
+2022-12-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-08 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Remove BND from 64-bit IBT PLT
+ Since MPX support has been removed from x86-64 psABI, remove BND from
+ 64-bit IBT PLT by using x32 IBT PLT.
+
+ bfd/
+
+ PR ld/29851
+ * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Also check
+ x32 IBT PLT for 64-bit.
+ (elf_x86_64_link_setup_gnu_properties): Always use x32 IBT PLT.
+
+ ld/
+
+ PR ld/29851
+ * testsuite/ld-x86-64/ibt-plt-1.d: Updated.
+ * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2b.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2c.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2d.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3b.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3c.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3d.d: Likewise.
+ * testsuite/ld-x86-64/plt-main-ibt-x32.dd: Moved to ...
+ * testsuite/ld-x86-64/plt-main-ibt.dd: This.
+ * testsuite/ld-x86-64/x86-64.exp: Don't use plt-main-ibt-x32.dd.
+
+2022-12-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require debug info for gdb.tui/tui-layout-asm-short-prog.exp
+ When running test-case gdb.tui/tui-layout-asm-short-prog.exp on SLE-12-SP3
+ aarch64, I run into:
+ ...
+ FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
+ FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents again
+ ...
+ due to:
+ ...
+ (gdb) file tui-layout-asm-short-prog^M
+ Reading symbols from tui-layout-asm-short-prog...^M
+ (No debugging symbols found in tui-layout-asm-short-prog)^M
+ ...
+
+ I managed to reproduce the same behaviour on openSUSE Leap 15.4 x86_64, by
+ removing the debug option.
+
+ Fix this by making the test-case unsupported if no debug info is found.
+
+ Tested on x86_64-linux.
+
+2022-12-08 Enze Li <enze.li@hotmail.com>
+
+ gdb/testsuite: update a pattern in gdb_file_cmd
+ When building GDB with the following CFLAGS and CXXFLAGS as part of
+ configure line:
+
+ CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11
+
+ Then run the selftest.exp, I see:
+
+ ======
+ Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
+ ...
+ FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
+ WARNING: Couldn't test self
+
+ === gdb Summary ===
+
+ # of unexpected failures 1
+ /home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
+ -iex "set height 0" -iex "set width 0" -data-directory
+ /home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
+ ======
+
+ It is the fact that when I use the previously mentioned CFLAGS and
+ CXXFLAGS as part of the configuration line, the default value (-O2 -g)
+ is overridden, then GDB has no debug information. When there's no debug
+ information, GDB should not run the testcase in selftest.exp.
+
+ The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
+ get the right value ("nodebug") during the gdb_file_cmd procedure.
+
+ That's because in this commit,
+
+ commit 3453e7e409f44a79ac6695589836edb8a49bfb08
+ Date: Sat May 19 11:25:20 2018 -0600
+
+ Clean up "Reading symbols" output
+
+ It changed "no debugging..." to "No debugging..." which causes the above
+ problem. This patch only updates the corresponding pattern to fix this
+ issue.
+
+ With this patch applied, I see:
+
+ ======
+ Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
+ ...
+
+ === gdb Summary ===
+
+ # of untested testcases 1
+ /home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
+ -iex "set height 0" -iex "set width 0" -data-directory
+ /home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
+ ======
+
+ Tested on x86_64-linux.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-08 Nick Clifton <nickc@redhat.com>
+
+ Update the description of the linker script's TYPE directive.
+ PR 29861
+ * ld.texi (Output Section Type): Note that setting the output
+ section type only works if the section contains untyped data.
+
+2022-12-08 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: skip objfiles with no BFD in DWARF unwinder
+ While playing with JIT reader I experienced GDB to crash on null-pointer
+ dereference when stepping through non-jitted code.
+
+ The problem was that dwarf2_frame_find_fde () assumed that all objfiles
+ have BFD but that's not always true. To address this problem, this
+ commit skips such objfiles.
+
+ To test the fix we put breakpoint in jit_function_add (). The JIT reader
+ does not know how unwind this function so unwinding eventually falls
+ back to DWARF unwinder which in turn iterates over objfiles. Since the
+ the code is jitted, it is guaranteed it would eventually process JIT
+ objfile.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-08 Alan Modra <amodra@gmail.com>
+
+ libctf: avoid potential double free
+ * ctf-link.c (ctf_link_add_cu_mapping): Set t NULL after free.
+
+2022-12-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-07 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Add support for RFC02655 - Saturating Subtract Instruction
+ opcodes/
+ * ppc-opc.c (XOL): New define.
+ (XOL_MASK): Likewise.
+ (powerpc_opcodes): Add subfus, subfus., subwus, subwus., subdus, subdus.
+
+ gas/
+ * testsuite/gas/ppc/rfc02655.s: New test.
+ * testsuite/gas/ppc/rfc02655.d: Likewise
+ * testsuite/gas/ppc/future-raw.s: Likewise.
+ * testsuite/gas/ppc/future-raw.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run them.
+
+2022-12-07 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Add support for RFC02656 - Enhanced Load Store with Length Instructions
+ opcodes/
+ * ppc-opc.c (PPCVSXF): New define.
+ (powerpc_opcodes): Add lxvrl, lxvrll, lxvprl, lxvprll, stxvrl,
+ stxvrll, stxvprl, stxvprl.
+
+ gas/
+ * testsuite/gas/ppc/rfc02656.s: New test.
+ * testsuite/gas/ppc/rfc02656.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+2022-12-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add invalidate_selected_frame function
+ Instead of using `select_frame (nullptr)` to invalidate the selected
+ frame, introduce a function to do that. There is no change in behavior,
+ but it makes the intent a bit clearer. It also allows adding an assert
+ in select_frame that fi is not nullptr, so it avoids passing nullptr by
+ mistake.
+
+ Change-Id: I61643f46bc8eca428334513ebdaadab63997bdd0
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp
+ Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering
+ various ways that gdb is unable to recover the longjmp target if the libc
+ probe is not supported.
+
+ Tested on x86_64-linux.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-07 Tom Tromey <tromey@adacore.com>
+
+ Remove unnecessary xstrdup from bppy_init
+ I saw that bppy_init used a non-const "char *". Fixing this revealed
+ that the xstrdup here was also unnecessary, so this patch removes it.
+
+2022-12-07 Alan Modra <amodra@gmail.com>
+
+ coff make_a_section_from_file tidy
+ Also support compressing a few more sections.
+
+ * coffgen.c (make_a_section_from_file): Rename return_section
+ to newsect. Don't try to be clever matching section name.
+ Compress .gnu.debuglto_.debug_ and .gnu.linkonce.wi. too.
+ Only rename debug sections when decompressing for linker.
+
+2022-12-07 Alan Modra <amodra@gmail.com>
+
+ gas compress_debug tidy
+ * write.c (compress_debug): Don't set up "ob" until after
+ seginfo NULL check. Simplify SEC_CONTENTS test. Localise
+ variables. Use bfd_debug_name_to_zdebug.
+
+ _bfd_elf_slurp_secondary_reloc_section sanity check
+ * elf.c (_bfd_elf_slurp_secondary_reloc_section): Sanity check
+ section header against file size. Avoid overflow in
+ reloc_count.
+
+ bfd_compress_section_contents access to elf_section_data
+ * compress.c (bfd_compress_section_contents): Don't access
+ elf_section_data for non-ELF.
+
+2022-12-07 Alan Modra <amodra@gmail.com>
+
+ Compression tidy and fixes
+ Tidies:
+ - Move stuff from bfd-in.h and libbfd.c to compress.c
+ - Delete COMPRESS_DEBUG from enum compressed_debug_section_type
+ - Move compress_debug field out of link_info to ld_config.
+ Fixes:
+ - Correct test in bfd_convert_section_setup to use obfd flags,
+ not ibfd.
+ - Apply bfd_applicable_file_flags to compression bfd flags added
+ by gas and ld to the output bfd.
+
+ bfd/
+ * bfd-in.h (enum compressed_debug_section_type),
+ (struct compressed_type_tuple),
+ (bfd_get_compression_algorithm),
+ (bfd_get_compression_algorithm_name),
+ * libbfd.c (compressed_debug_section_names),
+ (bfd_get_compression_algorithm),
+ (bfd_get_compression_algorithm_name): Move..
+ * compress.c: ..to here, deleting COMPRESS_DEBUG from
+ enum compressed_debug_section_type.
+ (bfd_convert_section_setup): Test obfd flags not ibfd for
+ compression flags.
+ * elf.c (elf_fake_sections): Replace link_info->compress_debug
+ test with abfd->flags test.
+ * bfd-in2.h: Regenerate.
+ binutils/
+ * objcopy.c (copy_file): Tidy setting of bfd compress flags.
+ Expand comment.
+ gas/
+ * write.c (compress_debug): Test bfd compress flags rather than
+ flag_compress_debug.
+ (write_object_file): Apply bfd_applicable_file_flags to compress
+ debug flags added to output bfd.
+ include/
+ * bfdlink.h (struct bfd_link_info): Delete compress_debug.
+ ld/
+ * ld.h (ld_config_type): Add compress_debug.
+ * emultempl/elf.em: Replace references to link_info.compress_debug
+ with config.compress_debug.
+ * lexsup.c (elf_static_list_options): Likewise.
+ * ldmain.c (main): Likewise. Apply bfd_applicable_file_flags
+ to compress debug flags added to output bfd.
+
+2022-12-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-06 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Avoid signed overflow for new_size adjustment
+ When bfd_size_type is unsigned 64-bit integer and sizeof is unsigned
+ 32-bit integer, subtraction in
+
+ *new_size += sizeof (Elf32_External_Chdr) - sizeof (Elf64_External_Chdr);
+
+ will overflow. Use
+
+ *new_size -= sizeof (Elf64_External_Chdr) - sizeof (Elf32_External_Chdr);
+
+ to avoid overflow.
+
+ PR binutils/29860
+ * compress.c (bfd_convert_section_setup): Avoid signed overflow
+ for new_size adjustment.
+
+2022-12-06 Tom Tromey <tromey@adacore.com>
+
+ Cosmetic fix in ppc-sysv-tdep.c
+ This is just a couple of cosmetic fixes in ppc-sysv-tdep.c: fixing
+ some formatting and correcting a typo.
+
+ Fix operator precedence bug in Rust parser
+ PR rust/29859 points out an operator precedence bug in the Rust
+ parser. This patch fixes it and adds a regression test.
+
+2022-12-06 Nick Clifton <nickc@redhat.com>
+
+ Fix a dereference of NULL when scanning the symbol hashes array in the ARM linker.
+ PR 29852
+ * elf32-arm.c (cmse_scan): Check for NULL entries in the
+ sym_hashes array.
+ (elf32_arm_gc_mark_extra_sections): Likewise.
+
+2022-12-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix test names in gdb.base/longjmp.exp
+ When running test-case gdb.base/longjmp.exp, we have:
+ ...
+ PASS: gdb.base/longjmp.exp: next over setjmp (1)
+ ...
+ PASS: gdb.base/longjmp.exp: next over setjmp (2)
+ ...
+
+ The trailing " (1)" and " (2)" are interpreted as comments rather than parts
+ of the test name, and therefore this is a duplicate, which is currently not
+ detected by our duplicate detection mechanism (PR testsuite/29772).
+
+ Fix the duplicate by using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2022-12-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make gdb.base/longjmp.exp FAIL more stable across archs
+ When running test-case gdb.base/longjmp.exp on x86_64-linux, the master
+ longjmp breakpoint is set using probes and the test-case passes:
+ ...
+ (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
+ next^M
+ 0x00000000004005cc 49 if (setjmp (env) == 0) /* patt1 */^M
+ (gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1)
+ next^M
+ 56 resumes++;^M
+ (gdb) PASS: gdb.base/longjmp.exp: next into else block (1)
+ ...
+
+ However, if I disable
+ create_longjmp_master_breakpoint_probe, we have instead:
+ ...
+ (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
+ next^M
+ 56 resumes++;^M
+ (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
+ ...
+
+ At first glance, the failure mode doesn't look too bad: we stop
+ a few insns later than the passing scenario.
+
+ For contrast, if we do the same on powerpc64le, the failure mode is:
+ ...
+ (gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
+ next^M
+ ^M
+ Breakpoint 3, main () at longjmp.c:59^M
+ 59 i = 1; /* miss_step_1 */^M
+ (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
+ ...
+ Here we only stop because of running into the safety net breakpoint at
+ miss_step_1.
+
+ So, how does this happen on x86_64? Let's look at the code:
+ ...
+ 4005c7: e8 94 fe ff ff call 400460 <_setjmp@plt>
+ 4005cc: 85 c0 test %eax,%eax
+ 4005ce: 75 1e jne 4005ee <main+0x3b>
+ 4005d0: 8b 05 8e 0a 20 00 mov 0x200a8e(%rip),%eax # 601064 <longjmps>
+ 4005d6: 83 c0 01 add $0x1,%eax
+ 4005d9: 89 05 85 0a 20 00 mov %eax,0x200a85(%rip) # 601064 <longjmps>
+ 4005df: be 01 00 00 00 mov $0x1,%esi
+ 4005e4: bf 80 10 60 00 mov $0x601080,%edi
+ 4005e9: e8 82 fe ff ff call 400470 <longjmp@plt>
+ 4005ee: 8b 05 74 0a 20 00 mov 0x200a74(%rip),%eax # 601068 <resumes>
+ ...
+ The next over the longjmp call at 4005e9 is supposed to stop at the longjmp
+ target at 4005cc, but instead we stop at 4005ee, where we have the step-resume
+ breakpoint inserted by the next. In other words, we accidentally "return"
+ from the longjmp call to the insn immediately after it (even though
+ a longjmp is a noreturn function).
+
+ Try to avoid this accident and make the failure mode on x86_64 the same as on
+ powerpc64le, by switching the then and else branch.
+
+ Tested on x86_64-linux.
+
+2022-12-06 Xiao Zeng <zengxiao@eswincomputing.com>
+
+ gdb/riscv: correct dwarf to gdb register number mapping
+ According to the riscv psabi, the mapping relationship between the
+ DWARF registers and the machine registers is as follows:
+
+ DWARF Number | Register Name | Description
+ 0 - 31 | x0 - x31 | Integer Registers
+ 32 - 63 | f0 - f31 | Floating-point Registers
+
+ This is not modelled quite right in riscv_dwarf_reg_to_regnum, the
+ DWARF register numbers 31 and 63 are not handled correctly due to a
+ use of '<' instead of '<='. This commit fixes this issue.
+
+2022-12-06 Haochen Jiang <haochen.jiang@intel.com>
+
+ x86: Remove unnecessary vex.w check for xh_mode in disassembler
+ For all the xh_mode usage in table, they are all using %XH, which will
+ print "{bad}" while EVEX.W=1. This makes this vex.w check unnecessary.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (OP_E_memory): Remove vex.w check for xh_mode.
+
+2022-12-06 Alan Modra <amodra@gmail.com>
+
+ Get rid of SEC_ELF_COMPRESS
+ This flag also isn't needed, except for some sanity checks which we
+ can omit.
+
+ * elf.c (elf_fake_sections): Don't set SEC_ELF_COMPRESS for
+ compressed debug sections, just leave sh_name as -1.
+ (assign_file_positions_for_non_load_sections),
+ (assign_file_positions_except_relocs): Decide whether a section
+ needs compressing and thus should not have its file offset set
+ by looking at sh_name.
+ (_bfd_elf_assign_file_positions_for_non_load): Similarly decide
+ which sections need compressing.
+ * elflink.c (bfd_elf_final_link): Don't test SEC_ELF_COMPRESS.
+ * merge.c (_bfd_write_merged_section): Likewise.
+ * section.c (SEC_ELF_COMPRESS): Don't define.
+ (SEC_ELF_PURECODE): Renumber.
+ * bfd-in2.h: Regenerate.
+
+2022-12-06 Alan Modra <amodra@gmail.com>
+
+ Get rid of SEC_ELF_RENAME
+ SEC_ELF_RENAME is a flag used to effect section name changes when
+ compressing/decompressing zlib-gnu debug sections. This can be
+ accomplished more directly in one of the objcopy specific bfd
+ functions. Renaming for ld input is simplified too. Ld input object
+ files always have BFD_DECOMPRESS set.
+
+ bfd/
+ * compress.c (bfd_convert_section_size): Rename to..
+ (bfd_convert_section_setup): ..this. Handle objcopy renaming
+ of compressed/decompressed debug sections.
+ * elf.c (_bfd_elf_make_section_from_shdr): Only rename zdebug
+ input for linker.
+ (elf_fake_sections): Don't handle renaming of debug sections for
+ objcopy here.
+ * section.c (SEC_ELF_RENAME): Delete.
+ * bfd-in2.h: Regenerate.
+ binutils/
+ * objcopy.c (setup_section): Call bfd_convert_section_setup.
+ Don't call bfd_convert_section_size.
+
+2022-12-06 Alan Modra <amodra@gmail.com>
+
+ Compression header enum
+ Define an enum instead of using ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD
+ in bfd and binutils, and move some functions from bfd.c to compress.c.
+ When looking at the COFF/PE debug compression support, I wondered
+ about extending it to support zstd. I likely won't do that, but
+ the compression header ch_type field isn't just ELF specific if these
+ headers are to be used in COFF/PE too.
+
+ bfd/
+ * bfd.c (bfd_update_compression_header),
+ (bfd_check_compression_header, bfd_get_compression_header_size),
+ (bfd_convert_section_size, bfd_convert_section_contents): Move to..
+ * compress.c: ..here.
+ (enum compression_type): New. Use it throughout file.
+ * elf.c (_bfd_elf_make_section_from_shdr): Replace uses of
+ ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD with ch_compress_zlib and
+ ch_compress_zstd.
+ * bfd-in2.h: Regenerate.
+ binutils/
+ * readelf.c (process_section_headers, dump_section_as_strings),
+ (dump_section_as_bytes, load_specific_debug_section): Replace
+ uses of ELFCOMPRESS_ZLIB and ELFCOMPRESS_ZSTD with
+ ch_compress_zlib and ch_compress_zstd.
+
+2022-12-06 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: Fix dynamic reloc not generated bug in some cases.
+ bfd/ChangeLog:
+
+ * elfnn-loongarch.c (loongarch_elf_relocate_section): Likewise.
+
+2022-12-06 Alan Modra <amodra@gmail.com>
+
+ PR29855, ch_type in bfd_init_section_decompress_status can be uninitialized
+ PR 29855
+ * compress.c (bfd_init_section_decompress_status): Set ch_type
+ to zero for zlib-gnu case.
+
+2022-12-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: add ptid parameter to linux_xfer_siginfo
+ Make the inferior_ptid bubble up to linux_nat_target::xfer_partial.
+
+ Change-Id: I62dbc5734c26648bb465f449c2003c73751cd812
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: use l linux_nat_get_siginfo in linux_xfer_siginfo
+ I noticed we could reduce duplication a bit here.
+
+ Change-Id: If24e54d1dac71b46f7c1f68a18a073d4c084b644
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: check ptrace return value in linux_nat_get_siginfo
+ Not a big deal, but it seems strange to check errno instead of the
+ ptrace return value to know whether it succeeded.
+
+ Change-Id: If0a6d0280ab0e5ecb077e546af0d6fe489c5b9fd
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: don't memset siginfo on failure in linux_nat_get_siginfo
+ No caller cares about the value of *SIGINFO on failure. It's also
+ documented in the function doc that *SIGINFO is uninitialized (I
+ understand "untouched") on failure.
+
+ Change-Id: I5ef38a5f58e3635e109b919ddf6f827f38f1225a
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: bool-ify linux_nat_get_siginfo
+ Change return type to bool.
+
+ Change-Id: I1bf0360bfdd1b5994cd0f96c268d806f96fe51a4
+
+2022-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: use get_ptrace_pid in two spots
+ No behavior change expected.
+
+ Change-Id: Ifaa64ecd619483646b024fd7c62e571e92a8eedb
+
+2022-12-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: remove perror calls when failing to run
+ I noticed that when running these two tests in sequence:
+
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
+ ERROR: GDB process no longer exists
+ ERROR: Couldn't run foo-all
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
+
+ The results in gdb.sum are:
+
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
+ PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb
+ ERROR: GDB process no longer exists
+ UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof)
+ ERROR: Couldn't run foo-all
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
+ UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
+ PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
+
+ The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test,
+ while trying to run to main. However, the UNRESOLVED in assign_1.exp
+ doesn't make sense, GDB behaves as expected in that test:
+
+ (gdb) set lang ada^M
+ (gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
+ print $xxx := 1^M
+ $1 = 1^M
+ (gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
+
+ The problem is that arrayptr.exp calls perror when failing to run to
+ main, then returns. perror makes it so that the next test (as in
+ pass/fail) will be recorded as UNRESOLVED. However, here, the next test
+ (as in pass/fail) is in the next test (as in .exp). Hence the spurious
+ UNRESOLVED in assign_1.exp.
+
+ These perror when failing to run to X are not really useful, especially
+ since runto records a FAIL on error, by default. Remove all the
+ perrors on runto failure I could find.
+
+ When there wasn't one already, add a return statement when failing to
+ run, to avoid running the test of the test unnecessarily.
+
+ I thought of adding a check ran between test (in gdb_finish
+ probably) where we would emit a warning if errcnt > 0, meaning a test
+ quit and left a perror "active". However, reading that variable would
+ poke into the DejaGNU internals, not sure it's a good idea.
+
+ Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
+
+2022-12-05 Luis Machado <luis.machado@arm.com>
+
+ Add missing newline to gdbarch_tdep debugging output
+ The missing newline causes testsuite issues because the gdb prompt gets output
+ to an unexpected location.
+
+2022-12-05 Nick Clifton <nickc@redhat.com>
+
+ Prevent an illegal memory access when comparing the prefix of a section name regexp.
+ PR 29849
+ * ldlang.c (spec_match): Check that there is sufficient length in
+ the target name to match the spec's prefix.
+
+2022-12-05 Martin Liska <mliska@suse.cz>
+
+ testsuite: support mold linker
+ Mold linker demotes symbols like main to be local and the patch
+ adjusts expected output from nm.
+
+ Moreover, simplify the regex patterns.
+
+2022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdbarch.py: Fix indentation in the generated set_gdbarch_* definitions
+ Use as many tabs as possible for indentation and pad with spaces to keep
+ the argument aligned to the opening parenthesis in the line above.
+
+ Co-developed-by: Simon Marchi <simon.marchi@efficios.com>
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdbarch.py: Fix indentation in the generated gdbarch_dump function
+ Use tab for the first eight spaces of indentation, and align the gdb_printf
+ arguments to the open parenthesis of the function call.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-05 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ gdb: Update my email address in MAINTAINERS
+
+2022-12-05 Jan Beulich <jbeulich@suse.com>
+
+ gas: add Dwarf line number test for .macro expansions
+ Before fiddling with the code let's put in place a test covering what
+ PR/gas 16908 aimed at.
+
+ gas: squash (some) .linefile from listings
+ Not so long ago we started to insert these artificially when expanding
+ certain macro-like constructs; zap them as cluttering what actually
+ results from user input.
+
+2022-12-05 Jan Beulich <jbeulich@suse.com>
+
+ gas: avoid inserting extra newline in buffer_and_nest()
+ In "-alm" listings I've noticed an odd blank line following the inserted
+ .linefile one. This results from the explicit NL inserted being
+ redundant with the one left in place from the original input line by all
+ respective callers. Note that we need to compensate for the removed line
+ by bumping the directive argument (which in turn is decremented again in
+ s_linefile() before calling new_logical_line_flags(), and I have to
+ confess that when putting together the original change I was a little
+ puzzled by the imbalance of increments/decrements, but then I forgot to
+ actually go look for the cause).
+
+ While there also switch to sb_add_string() instead of effectively open-
+ coding it to some degree.
+
+2022-12-05 Jan Beulich <jbeulich@suse.com>
+
+ Arm: .noinit and .persistent are not supported for Linux targets
+ Respective tests being run means guaranteed failures.
+
+2022-12-05 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access when parsing a corrupt VMS Alpha file.
+ PR 29848
+ * vms-alpha.c (parse_module): Fix potential out of bounds memory
+ access.
+
+2022-12-05 Andrew Burgess <aburgess@redhat.com>
+
+ libopcodes/mips: add support for disassembler styling
+ This commit adds disassembler styling support for MIPS. After this
+ commit objdump and GDB will style disassembler output.
+
+ This is a pretty straight forward change, we switch to use the
+ disassemble_info::fprintf_styled_func callback, and pass an
+ appropriate style through as needed. No additional tricks were
+ needed (compared to say i386, or ARM).
+
+ Tested by running all of the objdump commands used by the gas
+ testsuite and manually inspecting the styled output, everything looks
+ reasonable, though I'm not a MIPS expert, so it is possible that I've
+ missed some corner cases. Worst case though is that something will be
+ styled incorrectly, the actual content should be unchanged.
+
+ All the gas, ld, and binutils tests still pass for me.
+
+2022-12-05 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/mips: use .word/.short for undefined instructions
+ While working on disassembler styling for MIPS, I noticed that
+ undefined instructions are printed by the disassembler as raw number
+ with no assembler directive prefix (e.g. without .word or .short).
+
+ I think adding something like .word, or .short, helps to make it
+ clearer the size of the value that is being displayed, and is inline
+ with what many of the other libopcode disassemblers do.
+
+ In this commit I've added the .word and .short directives, and updated
+ all the tests that I spotted that failed as a result.
+
+2022-12-05 Alan Modra <amodra@gmail.com>
+
+ Re: Renaming .debug to .zdebug and vice versa
+ * compress.c (bfd_debug_name_to_zdebug): Fix C++ compile error.
+ (bfd_zdebug_name_to_debug): Likewise.
+ * bfd-in2.h: Regenerate.
+
+2022-12-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-04 Alan Modra <amodra@gmail.com>
+
+ PR29846, segmentation fault in objdump.c compare_symbols
+ Fixes a fuzzed object file problem where plt relocs were manipulated
+ in such a way that two synthetic symbols were generated at the same
+ plt location. Won't occur in real object files.
+
+ PR 29846
+ PR 20337
+ * objdump.c (compare_symbols): Test symbol flags to exclude
+ section and synthetic symbols before attempting to check flavour.
+
+2022-12-04 Alan Modra <amodra@gmail.com>
+
+ COFF compressed debug support
+ Since commit 4bea06d73c04 COFF support for compressed debug sections
+ has been broken due to the "flags" variable not getting SEC_HAS_CONTENTS.
+
+ * coffgen.c (make_a_section_from_file): Correct section flags
+ handling. Delete extraneous condition. Update error messages
+ to be the same as in elf.c.
+
+2022-12-04 Alan Modra <amodra@gmail.com>
+
+ Renaming .debug to .zdebug and vice versa
+ Move a couple of elf.c functions to compress.c.
+
+ * compress.c (bfd_debug_name_to_zdebug): New inline function.
+ (bfd_zdebug_name_to_debug): Likewise.
+ * elf.c (convert_debug_to_zdebug, convert_zdebug_to_debug): Delete.
+ (_bfd_elf_make_section_from_shdr, elf_fake_sections),
+ (_bfd_elf_assign_file_positions_for_non_load): Adjust to suit.
+ * coffgen.c (make_a_section_from_file): Use new inlines here.
+
+2022-12-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-03 H.J. Lu <hjl.tools@gmail.com>
+
+ Revert "ld: Add .note.GNU-stack to ld-plugin/dummy.s"
+ This reverts commit 44e59b5a7d8a874f6546a1471b8a003911853aa0.
+
+ It works only for ELF targets.
+
+2022-12-03 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add .note.GNU-stack to ld-plugin/dummy.s
+ * testsuite/ld-plugin/dummy.s: Add .note.GNU-stack.
+
+2022-12-03 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Allow 16-bit register source for LAR and LSL
+ Since LAR and LSL only access 16 bits of the source operand, regardless
+ of operand size, allow 16-bit register source for LAR and LSL, and always
+ disassemble LAR and LSL with 16-bit source operand.
+
+ gas/
+
+ PR gas/29844
+ * testsuite/gas/i386/i386.s: Add tests for LAR and LSL.
+ * testsuite/gas/i386/x86_64.s: Likewise.
+ * testsuite/gas/i386/intelbad.s: Remove "lar/lsl eax, ax".
+ * testsuite/gas/i386/i386-intel.d: Updated.
+ * testsuite/gas/i386/i386.d: Likewise.
+ * testsuite/gas/i386/intel-intel.d: Likewise.
+ * testsuite/gas/i386/intel.d: Likewise.
+ * testsuite/gas/i386/intelbad.l: Likewise.
+ * testsuite/gas/i386/x86_64-intel.d: Likewise.
+ * testsuite/gas/i386/x86_64.d: Likewise.
+
+ opcodes/
+
+ PR gas/29844
+ * i386-dis.c (MOD_0F02): Removed.
+ (MOD_0F03): Likewise.
+ (dis386_twobyte): Restore larS and lslS.
+ (mod_table): Remove MOD_0F02 and MOD_0F03.
+ * i386-opc.tbl: Allow 16-bit register source for LAR and LSL.
+ * i386-tbl.h: Regenerated.
+
+2022-12-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: add pid parameter to linux_proc_xfer_memory_partial
+ Add a pid parameter to linux_proc_xfer_memory_partial, making the
+ inferior_ptid reference bubble up close to the target_ops::xfer_partial
+ boundary. No behavior change expected.
+
+ Change-Id: I58171b00ee1bba1ea22efdbb5dcab8b1ab3aac4c
+
+2022-12-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add some debug statements to solib-svr4.c
+ Add a few debug statements that were useful to me when debugging why the
+ glibc probes interface wasn't getting used.
+
+ Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
+
+2022-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: merge solib-frv aix-solib debug options into "set/show debug solib"
+ solib implementations are typically used one at a time. So it will be
+ rare that you will want to enable debug for one solib kind, and
+ absolutely want to keep the others disabled. To make things simpler,
+ instead of adding separate variables / macros / commands for each solib
+ implementation, merge the existing ones (frv and aix) into a unified
+ "set/show debug solib", with the solib_debug_printf macro.
+
+ Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
+
+2022-12-02 Nick Clifton <nickc@redhat.com>
+
+ Add Jan Beulich as an x86_64 maintainer.
+
+2022-12-02 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop most OPERAND_TYPE_* (and rework the rest)
+ With the general use of C99 there's no need anymore to have i386-gen
+ produce these. For more frequently used ones introduce local #define-s,
+ while others are simply spelled out directly. While doing this move
+ some static constants into more narrow scopes.
+
+ Note that as a "side effect" this corrects type_names[]'es imm8s entry.
+
+2022-12-02 Jan Beulich <jbeulich@suse.com>
+
+ x86: simplify and slightly correct XCHG vs NOP checking
+ For one, because of CheckRegSize, there's no need to check the size of
+ both (register) operands. And then in process_suffix() check opcode
+ space rather than the (potentially ambiguous) extension opcode.
+
+ x86: also use D for XCHG and TEST
+ Leverage the C (commutative) attribute to also reduce the number of XCHG
+ and TEST templates we have. This way the reg <-> r/m (and reg <-> reg for
+ XCHG) forms can also be folded into a single template each, utilizing D.
+
+2022-12-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Prevent timeout in gdb.ada/float-bits.exp
+ Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
+ for powerpc64le") started using command "maint print architecture", which
+ produces ~275 lines.
+
+ Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
+ timeouts on slower test setups.
+
+ Note that this doesn't fix a timeout in the test-case on aarch64 due to:
+ ...
+ gdbarch_dump: read_core_file_mappings = <0x817438>
+ (gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
+ ...
+
+ Tested on x86_64-linux.
+
+2022-12-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-12-01 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp
+ The tests set a break point with the command break *func. This sets a
+ breakpoint on the first instruction of the function. PowerPC uses
+ Global Entry Points (GEP) and Local Entry Points (LEP). The first
+ instruction in the function is the GEP. The GEP sets up register
+ r2 before reaching the LEP. When the function is called with func() the
+ function is entered via the LEP and the test fails because GDB does not
+ see the breakpoint on the GEP. However, if the function is called via a
+ function pointer, execution begins at the GEP as the test expects.
+
+ Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and
+ next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new
+ source file was created for tests finish-reverse-bkpt.exp and
+ next-reverse-bkpt-over-sr.exp. The new files use the new function
+ pointer method to call the functions so the tests will work correctly on
+ both PowerPC with a GEP and LEP as well as on other systems. The GEP is
+ the same as the LEP on non PowerPC systems.
+
+ The expect files were changed to use the new source files and to set the
+ initial break point for the rest of the test on the function pointer call
+ for the function.
+
+ This patch fixes two PowerPC test failures in each of the tests
+ gdb.reverse/finish-reverse-bkpt.exp and
+ gdb.reverse/next-reverse-bkpt-over-sr.exp.
+
+ Patch tested on PowerPC and Intel X86-64 with no regressions.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Remove call to registers_changed from windows-nat.c
+ I noticed that windows_nat_target::interrupt calls registers_changed.
+ However, I don't think there's any reason to do this, because this
+ will happen automatically when the inferior stop is processed.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Remove the_windows_nat_target global
+ I belatedly realized that the "the_windows_nat_target" global isn't
+ really necessary. It's only used in one place, where 'this' would be
+ simpler and clearer. This patch removes the global entirely.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-12-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make frame_register static
+ It is only used inside frame.c.
+
+ Change-Id: I44eb46a5992412f8f8b4954b2284b0ef3b549504
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Add name canonicalization for C
+ PR symtab/29105 shows a number of situations where symbol lookup can
+ result in the expansion of too many CUs.
+
+ What happens is that lookup_signed_typename will try to look up a type
+ like "signed int". In cooked_index_functions::expand_symtabs_matching,
+ when looping over languages, the C++ case will canonicalize this type
+ name to be "int" instead. Then this method will proceed to expand
+ every CU that has an entry for "int" -- i.e., nearly all of them. A
+ crucial component of this is that the caller, objfile::lookup_symbol,
+ does not do this canonicalization, so when it tries to find the symbol
+ for "signed int", it fails -- causing the loop to continue.
+
+ This patch fixes the problem by introducing name canonicalization for
+ C. The idea here is that, by making C and C++ agree on the canonical
+ name when a symbol name can have multiple spellings, we avoid the bad
+ behavior in objfile::lookup_symbol (and any other such code -- I don't
+ know if there is any).
+
+ Unlike C++, C only has a few situations where canonicalization is
+ needed. And, in particular, due to the lack of overloading (thus
+ avoiding any issues in linespec) and due to the way c-exp.y works, I
+ think that no canonicalization is needed during symbol lookup -- only
+ during symtab construction. This explains why lookup_name_info is not
+ touched.
+
+ The stabs reader is modified on a "best effort" basis.
+
+ The DWARF reader needed one small tweak in dwarf2_name to avoid a
+ regression in dw2-unusual-field-names.exp. I think this is adequately
+ explained by the comment, but basically this is a scenario that should
+ not occur in real code, only the gdb test suite.
+
+ lookup_signed_typename is simplified. It used to search for two
+ different type names, but now gdb can search just for the canonical
+ form.
+
+ gdb.dwarf2/enum-type.exp needed a small tweak, because the
+ canonicalizer turns "unsigned integer" into "unsigned int integer".
+ It seems better here to use the correct C type name.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
+ Tested-by: Simon Marchi <simark@simark.ca>
+ Reviewed-by: Andrew Burgess <aburgess@redhat.com>
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Refactor cooked_index::do_finalize
+ This refactors cooked_index::do_finalize, reordering an 'if' to make
+ it a little less redundant. This change makes a subsequent patch
+ easier to read.
+
+ Reviewed-by: Andrew Burgess <aburgess@redhat.com>
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Remove language check from dwarf2_compute_name
+ dwarf2_compute_name has a redundant check of the CU's language -- this
+ is also checked in dwarf2_canonicalize_name. Removing this slightly
+ simplifies a future patch.
+
+ Reviewed-by: Andrew Burgess <aburgess@redhat.com>
+
+2022-12-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf: add some QUIT macros
+ While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way
+ out of GDB expanding many symtabs. GDB was busy in a loop in
+ cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I
+ also happened to see a spot in
+ cooked_index_functions::expand_matching_symbols where a QUIT would be
+ useful too, since we iterate over a potentially big number of index
+ entries and expand CUs in the loop. Add one there too.
+
+ Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-12-01 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove prune_threads in thread_db_target::update_thread_list
+ Pedro mentioned that this prune_threads call in
+ thread_db_target::update_thread_list was not needed, and it was probably
+ an oversight to leave it there in the work following commit e8032dde10b
+ ("Push pruning old threads down to the target"). That commit changed
+ the "find new threads" target operation to "update thread list", making
+ the target responsible of adding new threads and removing exited
+ threads, rather than just adding new threads. Commit e8032dde10b moved
+ the prune_threads calls previously done in common code into each
+ target's update_thread_list method, in order to keep the existing
+ behavior, which is why this prune_threads call ended up there.
+
+ In the mean time, the linux-nat target was taught to update_thread_list,
+ and thread_db_target::update_thread_list defers to that for any live
+ inferior, so the prune_threads call is not needed there. Otherwise, the
+ thread_db_target::update_thread_list implementation based on
+ td_ta_thr_iter_p only knows how to add new threads, not how to delete
+ exited threads, but that is only used for non-live inferiors, where
+ threads can't exit anyway. So the prune_threads call is not needed for
+ that case either.
+
+ Change-Id: I127fd4f84c25086f97853dadf34c5cec6816840d
+ Approved-By: Pedro Alves <pedro@palves.net>
+
+2022-12-01 H.J. Lu <hjl.tools@gmail.com>
+
+ opcodes: Remove i386-init.h and i386-tbl.h from HFILES
+ i386-init.h and i386-tbl.h are generated files. There is nothing to
+ translate. Remove them from HFILES (POTFILES).
+
+ * Makefile.am (HFILES): Remove i386-init.h and i386-tbl.h.
+ * Makefile.in: Regenerated.
+ * po/POTFILES.in: Likewise.
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Avoid timeouts in gdb.compile
+ PR compile/29541 points out that some of the C++ tests in gdb.compile
+ will time out when the glibc debuginfo is installed. This was
+ interfering with my hacking on gdb by making test runs extremely long,
+ so I looked into it.
+
+ Internally the bug seems to be that gdb tries to convert multiple
+ symbols named "var" via the compiler interface; one such symbol (I
+ didn't track it down too far) causes the C++ compiler plugin to crash.
+
+ Unfortunately, the crash is reported as a timeout, as the gdb side of
+ the plugin simply hangs. This seems like a bug in the plugin RPC
+ mechanism and, worse, apparently when I wrote this stuff I didn't
+ really consider error reporting very much at all, so gdb can't really
+ detect failures in the first place.
+
+ Anyway... this patch works around the timeout by compiling a simple
+ test that should provoke this bug, and then using "untested" if it
+ notices a GCC crash.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
+
+2022-12-01 Tom Tromey <tromey@adacore.com>
+
+ Remove obsolete check from skip_compile_feature_tests
+ skip_compile_feature_tests checks for "Command not supported on this
+ host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
+ gnulib module, fix mingw build"). This patch removes the obsolete
+ test.
+
+ Remove one copy of skip_compile_feature_tests
+ I noticed that there are two identical copies of
+ skip_compile_feature_tests in the test suite. This removes one from
+ gdb.exp, in favor of the one in compile-support.exp.
+
+2022-12-01 Clément Chigot <chigot@adacore.com>
+
+ binutils: improve holes detection in .debug_loclists.
+ The previous warnings about holes in .debug_loclists sections don't
+ take into account the headers of each CU and could include the locviews
+ if they precede the loclist.
+
+ The following warning can be triggered between two CU.
+ ... <previous CU views> ...
+ 0000001d <End of list>
+
+ 0000002a v000000000000000 v000000000000000 location view pair
+ 0000002c v000000000000000 v000000000000000 location view pair
+
+ readelf: Warning: There is a hole [0x1e - 0x2e] in .debug_loclists section.
+ 0000002e v000000000000000 v000000000000000 views at 0000002a for:
+ ...
+
+ But [0x1e - 0x2a] corresponds to the CU header and [0x2a - 0x2e] are
+ the locviews. Thus there is no hole here.
+
+ binutils/ChangeLog:
+
+ * dwarf.c (display_debug_loc): Adjust holes detections for
+ headers and locviews.
+
+2022-12-01 Nick Clifton <nickc@redhat.com>
+
+ Fix verilog output when the width is > 1.
+ PR 25202
+ bfd * bfd.c (VerilogDataEndianness): New variable.
+ (verilog_write_record): Use VerilogDataEndianness, if set, to
+ choose the endianness of the output.
+ (verilog_write_section): Adjust the address by the data width.
+
+ binutils* objcopy.c (copy_object): Set VerilogDataEndianness to the
+ endianness of the input file.
+ (copy_main): Verifiy the value set by the --verilog-data-width
+ option.
+ * testsuite/binutils-all/objcopy.exp: Add tests of the new behaviour.
+ * testsuite/binutils-all/verilog-I4.hex: New file.
+
+2022-12-01 Jan Beulich <jbeulich@suse.com>
+
+ x86: rework of match_template()'s suffix checking
+ (Ab)using i386_opcode_modifier for this has been overkill, as the logic
+ doesn't really require the full structure. With the removal of
+ LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf there's no good reason at all
+ anymore to pull out such a loop invariant: We're dealing a check of a
+ bit in the loop for a simple comparison. Do the original compares inside
+ the loop, thus also making it easier to understand what is actually
+ being checked.
+
+ x86: drop No_ldSuf
+ With LONG_DOUBLE_MNEM_SUFFIX gone there'salso no use for No_ldSuf
+ anymore.
+
+ x86/Intel: drop LONG_DOUBLE_MNEM_SUFFIX
+ With the removal of its use for FPU insns the suffix is now finally
+ properly misnamed. Drop its use altogether, replacing it by a separate
+ boolean instead.
+
+ x86/Intel: restrict use of LONG_DOUBLE_MNEM_SUFFIX
+ As a comment near the top of match_template() already says: We really
+ only need this pseudo-suffix for far branch handling. Stop "deriving" it
+ for floating point insns. (Don't bother renaming the now properly
+ misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
+ to disappear anyway.)
+
+2022-12-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Wait longer for core generation
+ When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
+ file system, I run into timeouts due to core generation, like for instance:
+ ...
+ (gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
+ FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
+ ...
+
+ Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
+
+ Tested on powerpc64le-linux.
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-12-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le
+ On powerpc64le-linux, I run into:
+ ...
+ (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M
+ $9 = <invalid float value>^M
+ (gdb) FAIL: gdb.ada/float-bits.exp: print \
+ 16llf#4000921fb54442d18469898cc51701b8#
+ ...
+
+ The problem is that we're using a hex string for the 128-bit IEEE quad long
+ double format, but the actual long double float format is:
+ ...
+ gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
+ ...
+
+ Fix this by using the hex string obtained by compiling test.c:
+ ...
+ long double a = 5.0e+25L;
+ ...
+ like so:
+ ...
+ $ gcc -mlittle test.c -c -g
+ ...
+ and running gdb:
+ ...
+ $ gdb -q -batch test.o -ex "p /x a"
+ $1 = 0xc1e1c000000000004544adf4b7320335
+ ...
+ and likewise for -mbig:
+ ...
+ $ gdb -q -batch test.o -ex "p /x a"
+ $1 = 0x4544adf4b7320335c1e1c00000000000
+ ...
+
+ Tested on powerpc64le-linux.
+
+ I excercised the case of floatformat_ibm_long_double_big by
+ using "set endian big" in the test-case.
+
+ Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
+ Improve printing of float formats") is required.
+
+ PR testsuite/29816
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-12-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATEs in s390-multiarch.exp
+ On s390x-linux, I run into:
+ ...
+ DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
+ DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
+ DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
+ ...
+
+ Fix this by using with_test_prefix.
+
+ Tested on s390x-linux.
+
+2022-11-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Enable gdb.arch/s390-disassembler-options.exp for --enable-targets=all
+ On s390x-linux, I run into:
+ ...
+ DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
+ show disassembler-options esa
+ ...
+
+ First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
+ the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
+ "set architecture" "s390"'.
+
+ Fix the DUPLICATE by using with_test_prefix.
+
+ Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
+
+ Tested on x86_64-linux.
+
+2022-11-30 Michael Matz <matz@suse.de>
+
+ section-select: Fix exclude-file-3
+ this testcase wasn't correctly testing everything, it passed, even
+ though sections from an excluded file were included. Fixing this
+ reveals a problem in the new section selector. This fixes that as
+ well.
+
+ section-select: Remove unused code
+ walk_wild_file, hence walk_wild_section and walk_wild_section_handler
+ aren't called with the prefix tree. Hence initialization of the latter
+ and all potential special cases for it aren't used anymore. That also
+ removes the need to handler_data[] and some associated helper functions.
+ So, remove all of that.
+
+2022-11-30 Michael Matz <matz@suse.de>
+
+ section-select: Implement a prefix-tree
+ Now that we have a list of potentially matching sections per wild
+ statement we can actually pre-fill that one by going once over all input
+ sections and match their names against a prefix-tree that points to the
+ potentially matching wild statements.
+
+ So instead of looking at all sections names for each glob for each wild
+ statement we now look at the sections only once and then only check
+ against those globs that have a possibility of a match at all (usually
+ only one or two).
+
+ This pushes the whole section selection off the profiles.
+
+2022-11-30 Michael Matz <matz@suse.de>
+
+ section-select: Completely rebuild matches
+ The check_relocs callback (and others) might have created new
+ section behind our back and some of them (e.g. on powerpc the
+ "linker stubs" .got) need to come in front of all others, despite
+ being created late (a symptom would be "TOC opt*" failing on powerpc).
+
+ This resets all section matches before updating for newly created
+ sections (i.e. completely rebuilds the matches).
+
+2022-11-30 Michael Matz <matz@suse.de>
+
+ section-select: Lazily resolve section matches
+ and remember the results. Before this the order of section matching
+ is basically:
+
+ foreach script-wild-stmt S
+ foreach pattern P of S
+ foreach inputfile I
+ foreach section S of I
+ match S against P
+ if match: do action for S
+
+ And this process is done three or four times: for each top-level call to
+ walk_wild() or wild(), that is: check_input_sections, lang_gc_sections,
+ lang_find_relro_sections and of course map_input_to_output_sections.
+
+ So we iterate over all sections of all files many many times (for each
+ glob). Reality is a bit more complicated (some special glob types don't
+ need the full iteration over all sections, only over all files), but
+ that's the gist of it.
+
+ For future work this shuffles the whole ordering a bit by lazily doing
+ the matching process and memoizing results, trading a little memory for
+ a 75% speedup of the overall section selection process.
+
+ This lazy resolution introduces a problem with sections added late
+ that's corrected in the next patch.
+
+2022-11-30 Tom Tromey <tromey@adacore.com>
+
+ Bounds check access to Ada task state names
+ While looking into Ada tasking a little, I noticed that no bounds
+ checking is done on accesses to the Ada task state names arrays. This
+ isn't a problem currently, but if the runtime ever added numbers -- or
+ if there was some kind of runtime corruption -- it could cause a gdb
+ crash.
+
+ This patch adds range checking. It also adds a missing _() call when
+ printing from the 'task_states' array.
+
+2022-11-30 Tom Tromey <tromey@adacore.com>
+
+ Use ui_file_up in mi_interp
+ This changes mi_interp to use ui_file_up rather than explicit
+ management.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-30 Tom Tromey <tromey@adacore.com>
+
+ Rename fields of cli_interp_base::saved_output_files
+ This renames the fields of cli_interp_base::saved_output_files, as
+ requested by Simon. I tried to choose names that more obviously
+ reflect what the field is used for. I also added a couple of
+ comments.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Improve printing of float formats
+ Currently, on x86_64, a little endian target, I get:
+ ...
+ $ gdb -q -batch -ex "maint print architecture" | grep " = floatformat"
+ gdbarch_dump: bfloat16_format = floatformat_bfloat16_big
+ gdbarch_dump: double_format = floatformat_ieee_double_big
+ gdbarch_dump: float_format = floatformat_ieee_single_big
+ gdbarch_dump: half_format = floatformat_ieee_half_big
+ gdbarch_dump: long_double_format = floatformat_i387_ext
+ ...
+ which suggests big endian.
+
+ This is due to this bit of code in pformat:
+ ...
+ /* Just print out one of them - this is only for diagnostics. */
+ return format[0]->name;
+ ...
+
+ Fix this by using gdbarch_byte_order to pick the appropriate index, such that
+ we have the more accurate:
+ ...
+ gdbarch_dump: bfloat16_format = floatformat_bfloat16_little
+ gdbarch_dump: half_format = floatformat_ieee_half_little
+ gdbarch_dump: float_format = floatformat_ieee_single_little
+ gdbarch_dump: double_format = floatformat_ieee_double_little
+ gdbarch_dump: long_double_format = floatformat_i387_ext
+ ...
+
+ Tested on x86_64-linux.
+
+2022-11-30 Alan Modra <amodra@gmail.com>
+
+ Correct ordering problem in comm-data.exp
+ * testsuite/ld-elf/comm-data.exp: Build libcomm-data.so before
+ attempting to read it to set ELF64.
+
+ regen SRC-POTFILES.in
+
+2022-11-30 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: adjustment to restricted suffix derivation
+ In "x86/Intel: restrict suffix derivation" I think I screwed up
+ slightly, bringing a piece of code out of sync with its comment, and
+ resulting in a suffix potentially being derived when one isn't needed.
+
+2022-11-30 Jan Beulich <jbeulich@suse.com>
+
+ x86: clean up after removal of support for gcc <= 2.8.1
+ At the very least a comment in process_operands() is stale. Beyond that
+ there are effectively two options:
+ 1) It is possible that FADDP and FMULP were mistakenly not marked as
+ being in need of dealing with the compiler anomaly, and hence the
+ respective templates weren't removed at the time when they should
+ have been.
+ 2) It is also possible that there are indeed uses known beyond compiler
+ generated output for these two commutative opcodes, and hence the
+ templates need to stay.
+ To be on the safe side assume 2: Update the comment and fold the
+ templates into their "normal" ones (utilizing D), adjusting consuming
+ code accordingly.
+
+ For FMULP also add a comment paralleling a similar one FADDP has.
+
+2022-11-30 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop FloatR
+ There are just 4 templates using it, which can be easily identified by
+ other means, as D is set only on a very limited number of FPU templates.
+ Also move the respective conditional out of the code path taken by all
+ "reverse match" insns (it probably should have been this way already
+ before, to avoid the one conditional in the common case).
+
+ With this the templates which had FloatR dropped no longer differ from
+ their AT&T syntax + mnemonic counterparts - the only difference is now
+ which of the two would be recognized. For this, however, we don't need
+ two templates - we can simply arrange the condition for setting
+ Opcode_FloatR accordingly.
+
+2022-11-30 Jan Beulich <jbeulich@suse.com>
+
+ x86: extend FPU test coverage for AT&T / Intel mnemonic differences
+ Before touching the templates, let's ensure we actually cover things:
+ For one FSUB{,R} and FDIV{,R} would better be tested with operands in
+ both possible orders. And then -mmnemonic=intel wasn't tested at all.
+
+2022-11-30 Joel Brobecker <brobecker@adacore.com>
+
+ src-release.sh: Fix gdb source tarball build failure due to libsframe
+ This script was recently changed as follow:
+
+ | commit e619dddb3a45780ae66d762756882a3b896b617d
+ | Date: Tue Nov 15 15:07:13 2022 -0800
+ | Subject: src-release.sh: Add libsframe
+ |
+ | Add libsframe to the list of top level directories that will be included
+ | in a release.
+
+ Since then, the gdb source tarball has been failing with the error
+ below during the "make configure-host configure-target" phase:
+
+ | make[3]: *** No rule to make target '../libsframe/libsframe.la',
+ | needed by 'libbfd.la'. Stop.
+ | make[3]: Leaving directory '/tmp/gdb-public/bfd'
+
+ This patch fixes the issue by adding libsframe to the list of
+ GDB_SUPPORT_DIRS, similar to what was done for BINUTILS.
+
+ ChangeLog:
+
+ * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
+
+2022-11-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/vla-optimized-out.exp for ppc64le
+ On powerpc64le-linux, I run into:
+ ...
+ (gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla
+ p sizeof (a)^M
+ $2 = <optimized out>^M
+ (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \
+ printed size of optimized out vla
+ ...
+
+ The problem happens as follows.
+
+ In order to find the size of the optimized out vla, gdb needs to evaluate:
+ ...
+ <155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \
+ (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1;
+ DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
+ DW_OP_minus)
+ ...
+
+ When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site
+ matching the pc, but doesn't find it:
+ ...
+ $ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \
+ -ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)"
+ Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34.
+
+ Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34
+ 34 }
+ DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main
+ $1 = <optimized out>
+ ....
+
+ The call site lookup fails because the call site label .LVL4:
+ ...
+ bl f1 # 11 *call_value_nonlocal_aixdi [length = 8]
+ nop
+ .LVL4:
+ ...
+ is not placed directly after the bl insn. This is gcc PR target/107909.
+
+ However, after manually fixing the .s file we have instead:
+ ...
+ Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main
+ $1 = <optimized out>
+ ...
+ due to the fact that the call site has no call site parameters.
+
+ The call site does have a reference to the corresponding function f1, with
+ parameter i, for which we find location list entries:
+ ...
+ 0037 1000067c 10000680 (DW_OP_reg3 (r3))
+ 004a 10000680 10000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3));
+ DW_OP_stack_value)
+ ...
+ and we could use the fact that the current pc is in the 1000067c-10000680
+ range, and that that the range starts at the start of the function, to deduce
+ that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3).
+ But that's a non-trivial enhancement, filed as enhancement PR symtab/29836.
+
+ Fix this by allowing <optimized out> for target powerpc and the gcc compiler.
+
+ Reviewed-By: Carl Love <cel@us.ibm.com>
+ Tested-By: Carl Love <cel@us.ibm.com>
+ PR testsuite/29813
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813
+
+2022-11-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: make gdb_unload use gdb_test_multiple
+ In the failure seen by Philippe here:
+
+ https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
+
+ gdb_unload crashed GDB, leaving no trace in the test results. Change it
+ to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
+ think it is good practice anyway.
+
+ Make it return the result of gdb_test_multiple directly, change
+ gdb.python/py-objfile.exp accordingly.
+
+ Change gdb.base/endian.exp as well to avoid duplicate test names.
+
+ Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
+ since gdb_unload does it already now.
+
+ Change-Id: I59a1e4947691330797e6ce23277942547c437a48
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2022-11-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: make gdb_test_multiple return immediately if send_gdb fails
+ In the failure seen by Philippe here:
+
+ https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
+
+ ... the testsuite only outputs PASSes, and an ERROR, resulting from an
+ uncaught exception. This is a bit sneaky, because ERRORs are not
+ reported in the test summary. In certain circumstances, it can be easy
+ to miss.
+
+ Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
+ this is only if it manages to send the command, and it's that command
+ that crashes GDB. Here, the ERROR is due to the fact that GDB had
+ already crashed by the time we entered gdb_test_multiple and tried to
+ send a command. GDB was crashed by the previous "file" command, sent by
+ gdb_unload. Because gdb_unload uses bare expect, it didn't record a
+ test failure when crashing GDB (this will be addressed separately).
+
+ In this patch, I propose to make gdb_test_multiple call unresolved
+ directly and return -1 send_gdb fails. This way, if GDB is already
+ crashed by the time we enter gdb_test_multiple, it will leave a trace in
+ the test results in the form of an UNRESOLVED. It will also spare us
+ the not-so-useful-in-my-opinion TCL backtrace.
+
+ Before, it looks like:
+
+ ERROR: Couldn't send python print(objfile.filename) to GDB.
+ ERROR: : spawn id exp9 not open
+ while executing
+ "expect {
+ -i exp9 -timeout 10
+ -re ".*A problem internal to GDB has been detected" {
+ fail "$message (GDB internal error)"
+ gdb_internal_error..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE : spawn id exp9 not open
+
+ And after:
+
+ Couldn't send python print(objfile.filename) to GDB.
+ UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
+
+ Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2022-11-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: remove unused gprofng/src/DbeSession.cc.1
+
+2022-11-29 Max Filippov <jcmvbkbc@gmail.com>
+
+ xtensa: allow dynamic configuration
+ Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
+ of a structure returned from the xtensa_get_config_v<x> function call.
+ Define that structure and fill it with default parameter values
+ specified in the include/xtensa-config.h.
+ Define reusable function xtensa_load_config that tries to load
+ configuration and return an address of an exported object from it.
+ Define functions xtensa_get_config_v{1,2} that use xtensa_load_config
+ to get structures xtensa_config_v{1,2}, either dynamically configured
+ or the default.
+
+ bfd/
+ * Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Append
+ xtensa-dynconfig.c.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * configure.ac (xtensa_elf32_be_vec, xtensa_elf32_le_vec): Add
+ xtensa-dynconfig.lo to the tb.
+ * elf32-xtensa.c (xtensa-config.h): Replace #include with
+ xtensa-dynconfig.h.
+ (XSHAL_ABI, XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove
+ definitions.
+ * xtensa-dynconfig.c: New file.
+ * xtensa-isa.c (xtensa-dynconfig.h): New #include.
+ (xtensa_get_modules): New function.
+ (xtensa_isa_init): Call xtensa_get_modules instead of taking
+ address of global xtensa_modules.
+
+ gas/
+ * config/tc-xtensa.c (xtensa-config.h): Replace #include with
+ xtensa-dynconfig.h.
+ (XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0, XTENSA_MARCH_EARLIEST):
+ Remove definitions.
+ * config/tc-xtensa.h (xtensa-config.h): Replace #include with
+ xtensa-dynconfig.h.
+ * config/xtensa-relax.c (xtensa-config.h): Replace #include with
+ xtensa-dynconfig.h.
+ (XCHAL_HAVE_WIDE_BRANCHES): Remove definition.
+
+ include/
+ * xtensa-dynconfig.h: New file.
+
+ ld/
+ * emultempl/xtensaelf.em (xtensa-config.h): Replace #include
+ with xtensa-dynconfig.h.
+ (XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove definitions.
+
+2022-11-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from library files
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the testsuite
+ library files (in boards/, config/, and lib/). Previous commits have
+ removed all uses of the 'then' keyword from the test script files,
+ this commit just cleans up the library files.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.*/*.exp scripts
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the remaining
+ gdb.*/*.exp scripts. Previous commits have done the bulk of this
+ removal, this commit just handles the remaining directories that each
+ contain a low number of instances.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.multi/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.multi/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.fortran/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.fortran/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.disasm/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.disasm/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.reverse/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.reverse/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.trace/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.trace/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.threads/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.threads/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.python/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.python/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.cp/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.cp/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.arch/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.arch/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.base/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.base/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove use of then keyword from gdb.ada/*.exp
+ The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
+ still a bunch of places in the testsuite where we make use of the
+ 'then' keyword, and sometimes these get copies into new tests, which
+ just spreads poor practice.
+
+ This commit removes all use of the 'then' keyword from the gdb.ada/
+ test script directory.
+
+ There should be no changes in what is tested after this commit.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove DOS line endings from a test script
+ The gdb.fortran/nested-funcs.exp test script has DOS line endings. I
+ can see no reason why this script needs DOS line endings.
+
+ Convert to UNIX line endings.
+
+ There should be no change in what is tested after this commit.
+
+2022-11-28 Tom Tromey <tromey@adacore.com>
+
+ Don't let gdb_stdlog use pager
+ When using the "set logging" commands, cli_interp_base::set_logging
+ will send gdb_stdlog output (among others) to the tee it makes for
+ gdb_stdout. However, this has the side effect of also causing logging
+ to use the pager. This is PR gdb/29787.
+
+ This patch fixes the problem by keeping stderr and stdlog separate
+ from stdout, preserving the rule that only gdb_stdout should page.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29787
+
+2022-11-28 Tom Tromey <tromey@adacore.com>
+
+ Don't let tee_file own a stream
+ Right now, tee_file owns the second stream it writes to. This is done
+ for the convenience of the users. In a subsequent patch, this will no
+ longer be convenient, so this patch moves the responsibility for
+ ownership to the users of tee_file.
+
+ Remove 'saved_output' global
+ CLI redirect uses a global variable, 'saved_output'. However, globals
+ are generally bad, and there is no need for this one -- it can be a
+ member of cli_interp_base. This patch makes this change.
+
+2022-11-28 Hannes Domani <ssbssa@yahoo.de>
+
+ Remove no longer used jump label
+ The out label is unused since wait_for_debug_event is in a different thread.
+
+ Actually set m_is_async to current async mode
+ Looks like this was missed in the async mode implementation.
+
+2022-11-28 Hannes Domani <ssbssa@yahoo.de>
+
+ Don't use auto for lambda parameter
+ Older gcc versions (here 4.9.2) can't handle auto for a lambda parameter:
+
+ ../../gdb/windows-nat.c: In member function 'void windows_nat_target::delete_thread(ptid_t, DWORD, bool)':
+ ../../gdb/windows-nat.c:629:12: error: use of 'auto' in lambda parameter declaration only available with -std=c++1y or -std=gnu++1y [-Werror]
+ [=] (auto &th)
+ ^
+
+2022-11-28 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix calling convention of thread entry point
+ For i686 the CreateThread entry point function needs the WINAPI (stdcall)
+ calling convention:
+
+ ../../gdb/windows-nat.c: In constructor 'windows_nat_target::windows_nat_target()':
+ ../../gdb/windows-nat.c:450:56: error: invalid user-defined conversion from 'windows_nat_target::windows_nat_target()::<lambda(LPVOID)>' to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} [-fpermissive]
+ 450 | HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr);
+ | ^~
+ ../../gdb/windows-nat.c:444:13: note: candidate is: 'constexpr windows_nat_target::windows_nat_target()::<lambda(LPVOID)>::operator DWORD (*)(LPVOID)() const' (near match)
+ 444 | auto fn = [] (LPVOID self) -> DWORD
+ | ^
+ ../../gdb/windows-nat.c:444:13: note: no known conversion from 'DWORD (*)(LPVOID)' {aka 'long unsigned int (*)(void*)'} to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'}
+
+ Since it's not possible to change the calling convention of a lambda, I've
+ moved it to a separate function.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: mark disassembler function callback types as noexcept
+ In disasm.h we define a set of types that are used by the various
+ disassembler classes to hold callback functions before passing the
+ callbacks into libopcodes.
+
+ Because libopcodes is C code, and on some (many?) targets, C code is
+ compiled without exception support, it is important that GDB not try
+ to throw an exception over libopcode code.
+
+ In the previous commit all the existing callbacks were marked as
+ noexcept, however, this doesn't protect us from a future change to GDB
+ either adding a new callback that is not noexcept, or removing the
+ noexcept keyword from an existing callback.
+
+ In this commit I mark all the callback types as noexcept. This means
+ that GDB's disassembler classes will no longer compile if we try to
+ pass a callback that is not marked as noexcept.
+
+ At least, that's the idea. Unfortunately, it's not that easy.
+
+ Before C++17, the noexcept keyword on a function typedef would be
+ ignored, thus:
+
+ using func_type = void (*) (void) noexcept;
+
+ void
+ a_func ()
+ {
+ throw 123;
+ }
+
+ void
+ some_func (func_type f)
+ {
+ f ();
+ }
+
+ int
+ main ()
+ {
+ some_func (a_func);
+ return 0;
+ }
+
+ Will compile just fine for C++11 and C++14 with GCC. Clang on the
+ other hand complains that 'noexcept' should not appear on function
+ types, but then does appear to correctly complain that passing a_func
+ is a mismatch in the set of exceptions that could be thrown.
+
+ Switching to C++17 and both GCC and Clang correctly point out that
+ passing a_func is an invalid conversion relating to the noexcept
+ keyword. Changing a_func to:
+
+ void
+ a_func () noexcept
+ { /* Nothing. */ }
+
+ And for C++17 both GCC and Clang compile this just fine.
+
+ My conclusion then is that adding the noexcept keyword to the function
+ types is pointless while GDB is not compiled as C++17, and silencing
+ the warnings would require us to jump through a bunch of hoops.
+
+ And so, in this commit, I define a macro LIBOPCODE_CALLBACK_NOEXCEPT,
+ this macro expands to noexcept when compiling for C++17, but otherwise
+ expands to nothing. I then add this macro to the function types.
+
+ I've compiled GDB as the default C++11 and also forced the compile to
+ C++17. When compiling as C++17 I spotted a few additional places
+ where callbacks needed to be marked noexcept (these fixes were merged
+ into the previous commit, but this confirmed to be that the macro is
+ working as expected).
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/disasm: mark functions passed to the disassembler noexcept
+ While working on another patch, Simon pointed out that GDB could be
+ improved by marking the functions passed to the disassembler as
+ noexcept.
+
+ https://sourceware.org/pipermail/gdb-patches/2022-October/193084.html
+
+ The reason this is important is the on some hosts, libopcodes, being C
+ code, will not be compiled with support for handling exceptions. As
+ such, an attempt to throw an exception over libopcodes code will cause
+ GDB to terminate.
+
+ See bug gdb/29712 for an example of when this happened.
+
+ In this commit all the functions that are passed to the disassembler,
+ and which might be used as callbacks by libopcodes are marked
+ noexcept.
+
+ Ideally, I would have liked to change these typedefs:
+
+ using read_memory_ftype = decltype (disassemble_info::read_memory_func);
+ using memory_error_ftype = decltype (disassemble_info::memory_error_func);
+ using print_address_ftype = decltype (disassemble_info::print_address_func);
+ using fprintf_ftype = decltype (disassemble_info::fprintf_func);
+ using fprintf_styled_ftype = decltype (disassemble_info::fprintf_styled_func);
+
+ which are declared in disasm.h, as including the noexcept keyword.
+ However, when I tried this, I ran into this warning/error:
+
+ In file included from ../../src/gdb/disasm.c:25:
+ ../../src/gdb/disasm.h: In constructor ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’:
+ ../../src/gdb/disasm.h:116:3: error: mangled name for ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
+ 116 | gdb_printing_disassembler (struct gdbarch *gdbarch,
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~
+
+ So I've left that change out. This does mean that if somebody adds a
+ new use of the disassembler classes in the future, and forgets to mark
+ the callbacks as noexcept, this will compile fine. We'll just have to
+ manually check for that during review.
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: avoid throwing an exception over libopcodes code
+ Bug gdb/29712 identifies a problem with the Python disassembler API.
+ In some cases GDB will try to throw an exception through the
+ libopcodes disassembler code, however, not all targets include
+ exception unwind information when compiling C code, for targets that
+ don't include this information GDB will terminate when trying to pass
+ the exception through libopcodes.
+
+ To explain what GDB is trying to do, consider the following trivial
+ use of the Python disassembler API:
+
+ class ExampleDisassembler(gdb.disassembler.Disassembler):
+
+ class MyInfo(gdb.disassembler.DisassembleInfo):
+ def __init__(self, info):
+ super().__init__(info)
+
+ def read_memory(self, length, offset):
+ return super().read_memory(length, offset)
+
+ def __init__(self):
+ super().__init__("ExampleDisassembler")
+
+ def __call__(self, info):
+ info = self.MyInfo(info)
+ return gdb.disassembler.builtin_disassemble(info)
+
+ This disassembler doesn't add any value, it defers back to GDB to do
+ all the actual work, but it serves to allow us to discuss the problem.
+
+ The problem occurs when a Python exception is raised by the
+ MyInfo.read_memory method. The MyInfo.read_memory method is called
+ from the C++ function gdbpy_disassembler::read_memory_func. The C++
+ stack at the point this function is called looks like this:
+
+ #0 gdbpy_disassembler::read_memory_func (memaddr=4198805, buff=0x7fff9ab9d2a8 "\220ӹ\232\377\177", len=1, info=0x7fff9ab9d558) at ../../src/gdb/python/py-disasm.c:510
+ #1 0x000000000104ba06 in fetch_data (info=0x7fff9ab9d558, addr=0x7fff9ab9d2a9 "ӹ\232\377\177") at ../../src/opcodes/i386-dis.c:305
+ #2 0x000000000104badb in ckprefix (ins=0x7fff9ab9d100) at ../../src/opcodes/i386-dis.c:8571
+ #3 0x000000000104e28e in print_insn (pc=4198805, info=0x7fff9ab9d558, intel_syntax=-1) at ../../src/opcodes/i386-dis.c:9548
+ #4 0x000000000104f4d4 in print_insn_i386 (pc=4198805, info=0x7fff9ab9d558) at ../../src/opcodes/i386-dis.c:9949
+ #5 0x00000000004fa7ea in default_print_insn (memaddr=4198805, info=0x7fff9ab9d558) at ../../src/gdb/arch-utils.c:1033
+ #6 0x000000000094fe5e in i386_print_insn (pc=4198805, info=0x7fff9ab9d558) at ../../src/gdb/i386-tdep.c:4072
+ #7 0x0000000000503d49 in gdbarch_print_insn (gdbarch=0x5335560, vma=4198805, info=0x7fff9ab9d558) at ../../src/gdb/gdbarch.c:3351
+ #8 0x0000000000bcc8c6 in disasmpy_builtin_disassemble (self=0x7f2ab07f54d0, args=0x7f2ab0789790, kw=0x0) at ../../src/gdb/python/py-disasm.c:324
+
+ ### ... snip lots of frames as we pass through Python itself ...
+
+ #22 0x0000000000bcd860 in gdbpy_print_insn (gdbarch=0x5335560, memaddr=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/python/py-disasm.c:783
+ #23 0x00000000008995a5 in ext_lang_print_insn (gdbarch=0x5335560, address=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/extension.c:939
+ #24 0x0000000000741aaa in gdb_print_insn_1 (gdbarch=0x5335560, vma=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/disasm.c:1078
+ #25 0x0000000000741bab in gdb_disassembler::print_insn (this=0x7fff9ab9e3c0, memaddr=0x401195, branch_delay_insns=0x0) at ../../src/gdb/disasm.c:1101
+
+ So gdbpy_disassembler::read_memory_func is called from the libopcodes
+ disassembler to read memory, this C++ function then calls into user
+ supplied Python code to do the work.
+
+ If the user supplied Python code raises an gdb.MemoryError exception
+ indicating the memory read failed, this is fine. The C++ code
+ converts this exception back into a return value that libopcodes can
+ understand, and returns to libopcodes.
+
+ However, if the user supplied Python code raises some other exception,
+ what we want is for this exception to propagate through GDB and appear
+ as if raised by the call to gdb.disassembler.builtin_disassemble. To
+ achieve this, when gdbpy_disassembler::read_memory_func spots an
+ unknown Python exception, we must pass the information about this
+ exception from frame #0 to frame #8 in the above backtrace. Frame #8
+ is the C++ implementation of gdb.disassembler.builtin_disassemble, and
+ so it is this function that we want to re-raise the unknown Python
+ exception, so the user can, if they want, catch the exception in their
+ code.
+
+ The previous mechanism by which the exception was passed was to pack
+ the details of the Python exception into a C++ exception, then throw
+ the exception from frame #0, and catch the exception in frame #8,
+ unpack the details of the Python exception, and re-raise it.
+
+ However, this relies on the exception passing through frames #1 to #7,
+ some of which are in libopcodes, which is C code, and so, might not be
+ compiled with exception support.
+
+ This commit proposes an alternative solution that does not rely on
+ throwing a C++ exception.
+
+ When we spot an unhandled Python exception in frame #0, we will store
+ the details of this exception within the gdbpy_disassembler object
+ currently in use. Then we return to libopcodes a value indicating
+ that the memory_read failed.
+
+ libopcodes will now continue to disassemble as though that memory read
+ failed (with one special case described below), then, when we
+ eventually return to disasmpy_builtin_disassemble we check to see if
+ there is an exception stored in the gdbpy_disassembler object. If
+ there is then this exception can immediately be installed, and then we
+ return back to Python, when the user will be able to catch the
+ exception.
+
+ There is one extra change in gdbpy_disassembler::read_memory_func.
+ After the first call that results in an exception being stored on the
+ gdbpy_disassembler object, any future calls to the ::read_memory_func
+ function will immediately return as if the read failed. This avoids
+ any additional calls into user supplied Python code.
+
+ My thinking here is that should the first call fail with some unknown
+ error, GDB should not keep trying with any additional calls. This
+ maintains the illusion that the exception raised from
+ MyInfo.read_memory is immediately raised by
+ gdb.disassembler.builtin_disassemble. I have no tests for this change
+ though - to trigger this issue would rely on a libopcodes disassembler
+ that will try to read further memory even after the first failed
+ read. I'm not aware of any such disassembler that currently does
+ this, but that doesn't mean such a disassembler couldn't exist in the
+ future.
+
+ With this change in place the gdb.python/py-disasm.exp test should now
+ pass on AArch64.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29712
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-28 Tom Tromey <tom@tromey.com>
+
+ Remove reset_ecs and execution_control_state::reset
+ I noticed that execution_control_state has a 'reset' method, and
+ there's also a 'reset_ecs' function that calls it. This patch cleans
+ this area up a little by adding a parameter to the constructor and (a
+ change Simon suggested) removing the reset method. Some extraneous
+ variables are also removed, like:
+
+ - struct execution_control_state ecss;
+ - struct execution_control_state *ecs = &ecss;
+
+ Here 'ecs' is never changed, so this patch removes it entirely in
+ favor of just using the object everywhere.
+
+ Regression tested on x86-64 Fedora 34.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: relax requirement for the map_failed stap probe to be present
+ From glibc 2.35 and later, the "map_failed" stap probe is no longer
+ included in glibc. The removal of the probe looks like an accident,
+ but it was caused by a glibc commit which meant that the "map_failed"
+ probe could no longer be reached; the compiler then helpfully
+ optimised out the probe.
+
+ In GDB, in solib-svr4.c, we have a list of probes that we look for
+ related to the shared library loading detection. If any of these
+ probes are missing then GDB will fall back to the non-probe based
+ mechanism for detecting shared library loading. The "map_failed"
+ probe is include in the list of required probes.
+
+ This means that on glibc 2.35 (or later) systems, GDB is going to
+ always fall back to the non-probes based mechanism for detecting
+ shared library loading.
+
+ I raised a glibc bug to discuss this issue:
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=29818
+
+ But, whatever the ultimate decision from the glibc team, given there
+ are version of glibc in the wild without the "map_failed" probe, we
+ probably should update GDB to handle this situation.
+
+ The "map_failed" probe is already a little strange, very early
+ versions of glibc didn't include this probe, so, in some cases, if
+ this probe is missing GDB is happy to ignore it. This is fine, the
+ action associated with this probe inside GDB is DO_NOTHING, this means
+ the probe isn't actually required in order for GDB to correctly detect
+ the loading of shared libraries.
+
+ In this commit I propose changing the rules so that any probe whose
+ action is DO_NOTHING, is optional.
+
+ There is one possible downside to this change, and that concerns 'set
+ stop-on-solib-events on'. If a probe is removed from glibc, but the
+ old style breakpoint based mechanism is still in place within glibc
+ for that same event, then GDB will stop when using the old style
+ non-probe based mechanism, but not when using the probes based
+ mechanism.
+
+ For the map_failed case this is not a problem, both the map_failed
+ probe, and the call to the old style breakpoint location were
+ optimised out, and so neither event (probes based, or breakpoint
+ based) will trigger. This would only become an issue if glibc removed
+ a probe, but left the breakpoint in place (this would almost certainly
+ be a bug in glibc).
+
+ For now, I'm proposing that we just don't worry about this. Because
+ some probes have actions that are not DO_NOTHING, then we know the
+ user will always seem _some_ stops when a shared library is
+ loaded/unloaded, and (I'm guessing), in most cases, that's all they
+ care about. I figure when someone complains then we can figure out
+ what the right solution is then.
+
+ With this commit in place, then, when using a glibc 2.35 or later
+ system, GDB will once again use the stap probes for shared library
+ detection.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require hw watchpoint in gdb.ada/task_watch.exp
+ On powerpc64le-linux I run into:
+ ...
+ (gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
+ watch -location value task 3^M
+ Watchpoint 2: -location value^M
+ (gdb) PASS: gdb.ada/task_watch.exp: watch -location value task 3
+ continue^M
+ Continuing.^M
+ [Thread 0x7ffff7ccf170 (LWP 65550) exited]^M
+ [Thread 0x7ffff7abf170 (LWP 65551) exited]^M
+ FAIL: gdb.ada/task_watch.exp: continue to watchpoint (timeout)
+ ...
+
+ On x86_64-linux (where the test-case passes), a hardware watchpoint is used:
+ ...
+ (gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
+ watch -location value task 3^M
+ Hardware watchpoint 2: -location value^M
+ ...
+ and after forcing "set can-use-hw-watchpoints 0" we can intermittently
+ reproduce the same failure.
+
+ In the gdb documentation related to watchpoints in multi-threaded programs, we
+ read:
+ ...
+ Warning: In multi-threaded programs, software watchpoints have only limited
+ usefulness. If GDB creates a software watchpoint, it can only watch the value
+ of an expression in a single thread. If you are confident that the expression
+ can only change due to the current thread’s activity (and if you are also
+ confident that no other thread can become current), then you can use software
+ watchpoints as usual. However, GDB may not notice when a non-current thread’s
+ activity changes the expression. (Hardware watchpoints, in contrast, watch an
+ expression in all threads.)
+ ...
+
+ Since the ada task construct is mapped onto threads, it seems that the
+ same limitation holds for tasks.
+
+ Fix this by using skip_hw_watchpoint_tests.
+
+ Tested on powerpc64-linux.
+ Tested-By: Carl Love <cel@us.ibm.com>
+
+2022-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp for ppc64le
+ On powerpc64le-linux, with test-case gdb.ada/out_of_line_in_inlined.exp I run
+ into:
+ ...
+ (gdb) run ^M
+ Starting program: foo_o224_021-all ^M
+ ^M
+ Breakpoint 1, 0x0000000010002f48 in foo_o224_021.child1.child2 (s=...) at \
+ foo_o224_021.adb:24^M
+ 24 function Child2 (S : String) return Boolean is -- STOP^M
+ (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
+ run to foo_o224_021.child1.child2
+ ...
+
+ The breakpoint is correctly set at the local entry point, and given that the
+ local entry point doesn't correspond to a line number entry, the instruction
+ address of the breakpoint is shown.
+
+ The problem is that test-case doesn't expect the breakpoint address.
+
+ Fix this by allowing the breakpoint address to occur.
+
+ Tested on powerpc64le-linux.
+
+2022-11-28 Michael Matz <matz@suse.de>
+
+ Only use wild_sort_fast
+ there's no reason why the tree-based variant can't always be used
+ when sorting is required, it merely needs to also support filename
+ sorting and have a fast path for insertion at end (aka rightmost tree
+ leaf).
+
+ The filename sorting isn't tested anywhere and the only scripttempl
+ that uses it is avr (for 'SORT(*)(.ctors)'), and I believe even there it
+ was a mistake. Either way, this adds a testcase for filename sorting as
+ well.
+
+ Then the non-BST based sorting can be simplified to only support
+ the fast case of no sorting required at all (at the same time renaming
+ the two variants to _sort and _nosort).
+
+2022-11-28 Michael Matz <matz@suse.de>
+
+ Special case more simple patterns
+ fnmatch is slow, so avoiding it in more cases is good. This implements
+ a more generic version of match_simple_wild which needs some
+ pre-processing of patterns. In particular it supports patterns of the
+ form PREFIX*SUFFIX (where all parts are optional), i.e. a super set of
+ what's handled now. Most section matchers of this form and hence don't
+ need any calls to fnmatch anymore.
+
+ We retain the implementation of match_simple_wild for the filename
+ matchers (they aren't called often enough to matter).
+
+2022-11-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fail if gdb_start_cmd fails
+ I broke gdb.ada/start.exp, and did not notice it, because it outputs an
+ UNTESTED if gdb_start_cmd fails. I don't really see when start would
+ fail and it's not a problem that should be looked at. Change all spots
+ that call untested after a gdb_start_cmd failure, use fail instead.
+
+ Doing so caused some failures with the native-gdbserver board. Some
+ tests that use "start" were relying on the fact that start would fail
+ with that board to just return with "untested". Change them to add an
+ early return if use_gdb_stub returns true.
+
+ Some gdb.pascal tests also failed with native-gdbserver, because they
+ did use gdb_start_cmd to start the inferior, for no good reason.
+ Convert them to use runto_main instead, which does the right thing if
+ the target is a stub.
+
+ A further refactoring could be to make gdb_start_cmd match the expected
+ breakpoint hit and the prompt, which it doesn't do currently (it leaves
+ that to the callers, but not all of them do).
+
+ Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-11-28 Tom Tromey <tromey@adacore.com>
+
+ Fix range type signed-ness heuristic
+ The code to create a range type has a heuristic to decide whether the
+ range is unsigned. However, this heuristic can fail if the upper
+ bound of the range has its high bit set, because the test is done
+ using LONGEST.
+
+ With this patch, if the underlying type of a range is unsigned, then
+ the range will always be unsigned. A new test is included.
+
+ Regression tested on x86-64 Fedora 34. We've also been using this
+ internally at AdaCore for a while.
+
+2022-11-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: disable commit resumed in target_kill
+ New in this version:
+
+ - Better comment in target_kill
+ - Uncomment line in test to avoid hanging when exiting, when testing on
+ native-extended-gdbserver
+
+ PR 28275 shows that doing a sequence of:
+
+ - Run inferior in background (run &)
+ - kill that inferior
+ - Run again
+
+ We get into this assertion:
+
+ /home/smarchi/src/binutils-gdb/gdb/target.c:2590: internal-error: target_wait: Assertion `!proc_target->commit_resumed_state' failed.
+
+ #0 internal_error_loc (file=0x5606b344e740 "/home/smarchi/src/binutils-gdb/gdb/target.c", line=2590, fmt=0x5606b344d6a0 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:54
+ #1 0x00005606b6296475 in target_wait (ptid=..., status=0x7fffb9390630, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2590
+ #2 0x00005606b5767a98 in startup_inferior (proc_target=0x5606bfccb2a0 <the_amd64_linux_nat_target>, pid=3884857, ntraps=1, last_waitstatus=0x0, last_ptid=0x0) at /home/smarchi/src/binutils-gdb/gdb/nat/fork-inferior.c:482
+ #3 0x00005606b4e6c9c5 in gdb_startup_inferior (pid=3884857, num_traps=1) at /home/smarchi/src/binutils-gdb/gdb/fork-child.c:132
+ #4 0x00005606b50f14a5 in inf_ptrace_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
+ at /home/smarchi/src/binutils-gdb/gdb/inf-ptrace.c:105
+ #5 0x00005606b53b6d23 in linux_nat_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
+ at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:978
+ #6 0x00005606b512b79b in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:468
+ #7 0x00005606b512c236 in run_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:526
+
+ When running the kill command, commit_resumed_state for the
+ process_stratum_target (linux-nat, here) is true. After the kill, when
+ there are no more threads, commit_resumed_state is still true, as
+ nothing touches this flag during the kill operation. During the
+ subsequent run command, run_command_1 does:
+
+ scoped_disable_commit_resumed disable_commit_resumed ("running");
+
+ We would think that this would clear the commit_resumed_state flag of
+ our native target, but that's not the case, because
+ scoped_disable_commit_resumed iterates on non-exited inferiors in order
+ to find active process targets. And after the kill, the inferior is
+ exited, and the native target was unpushed from it anyway. So
+ scoped_disable_commit_resumed doesn't touch the commit_resumed_state
+ flag of the native target, it stays true. When reaching target_wait, in
+ startup_inferior (to consume the initial expect stop events while the
+ inferior is starting up and working its way through the shell),
+ commit_resumed_state is true, breaking the contract saying that
+ commit_resumed_state is always false when calling the targets' wait
+ method.
+
+ (note: to be correct, I think that startup_inferior should toggle
+ commit_resumed between the target_wait and target_resume calls, but I'll
+ ignore that for now)
+
+ I can see multiple ways to fix this. In the end, we need
+ commit_resumed_state to be cleared by the time we get to that
+ target_wait. It could be done at the end of the kill command, or at the
+ beginning of the run command.
+
+ To keep things in a coherent state, I'd like to make it so that after
+ the kill command, when the target is left with no threads, its
+ commit_resumed_state flag is left to false. This way, we can keep
+ working with the assumption that a target with no threads (and therefore
+ no running threads) has commit_resumed_state == false.
+
+ Do this by adding a scoped_disable_commit_resumed in target_kill. It
+ clears the target's commit_resumed_state on entry, and leaves it false
+ if the target does not have any resumed thread on exit. That means,
+ even if the target has another inferior with stopped threads,
+ commit_resumed_state will be left to false, which makes sense.
+
+ Add a test that tries to cover various combinations of actions done
+ while an inferior is running (and therefore while commit_resumed_state
+ is true on the process target).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
+ Change-Id: I8e6fe6dc1f475055921520e58cab68024039a1e9
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-11-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver: switch to right process in find_one_thread
+ New in this version: add a dedicated test.
+
+ When I do this:
+
+ $ ./gdb -nx --data-directory=data-directory -q \
+ /bin/sleep \
+ -ex "maint set target-non-stop on" \
+ -ex "tar ext :1234" \
+ -ex "set remote exec-file /bin/sleep" \
+ -ex "run 1231 &" \
+ -ex add-inferior \
+ -ex "inferior 2"
+ Reading symbols from /bin/sleep...
+ (No debugging symbols found in /bin/sleep)
+ Remote debugging using :1234
+ Starting program: /bin/sleep 1231
+ Reading /lib64/ld-linux-x86-64.so.2 from remote target...
+ warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+ Reading /lib64/ld-linux-x86-64.so.2 from remote target...
+ Reading /usr/lib/debug/.build-id/a6/7a1408f18db3576757eea210d07ba3fc560dff.debug from remote target...
+ [New inferior 2]
+ Added inferior 2 on connection 1 (extended-remote :1234)
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
+ attach 3659848
+ Attaching to process 3659848
+ /home/smarchi/src/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
+
+ Note the "attach" command just above. When doing it on the command-line
+ with a -ex switch, the bug doesn't trigger.
+
+ The internal error of GDB is actually caused by GDBserver crashing, and
+ the error recovery of GDB is not on point. This patch aims to fix just
+ the GDBserver crash, not the GDB problem.
+
+ GDBserver crashes with a segfault here:
+
+ (gdb) bt
+ #0 0x00005555557fb3f4 in find_one_thread (ptid=...) at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:177
+ #1 0x00005555557fd5cf in thread_db_thread_handle (ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400, handle_len=0x7fffffffc3f0)
+ at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:461
+ #2 0x000055555578a0b6 in linux_process_target::thread_handle (this=0x5555558a64c0 <the_x86_target>, ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400,
+ handle_len=0x7fffffffc3f0) at /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:6905
+ #3 0x00005555556dfcc6 in handle_qxfer_threads_worker (thread=0x60b000000510, buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1645
+ #4 0x00005555556e00e6 in operator() (__closure=0x7fffffffc5e0, thread=0x60b000000510) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1696
+ #5 0x00005555556f54be in for_each_thread<handle_qxfer_threads_proper(buffer*)::<lambda(thread_info*)> >(struct {...}) (func=...) at /home/smarchi/src/binutils-gdb/gdbserver/gdbthread.h:159
+ #6 0x00005555556e0242 in handle_qxfer_threads_proper (buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1694
+ #7 0x00005555556e04ba in handle_qxfer_threads (annex=0x629000000213 "", readbuf=0x621000019100 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4097)
+ at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1732
+ #8 0x00005555556e1989 in handle_qxfer (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2045
+ #9 0x00005555556e720a in handle_query (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2685
+ #10 0x00005555556f1a01 in process_serial_event () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4176
+ #11 0x00005555556f4457 in handle_serial_event (err=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4514
+ #12 0x0000555555820f56 in handle_file_event (file_ptr=0x607000000250, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
+ #13 0x0000555555821895 in gdb_wait_for_event (block=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
+ #14 0x000055555581f533 in gdb_do_one_event (mstimeout=-1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
+ #15 0x00005555556ec9fb in start_event_loop () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3512
+ #16 0x00005555556f0769 in captured_main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3992
+ #17 0x00005555556f0e3f in main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4078
+
+ The reason is a wrong current process when find_one_thread is called.
+ The current process is the 2nd one, which was just attached. It does
+ not yet have thread_db data (proc->priv->thread_db is nullptr). As we
+ iterate on all threads of all process to fulfull the qxfer:threads:read
+ request, we get to a thread of process 1 for which we haven't read
+ thread_db information yet (lwp_info::thread_known is false), so we get
+ into find_one_thread. find_one_thread uses
+ `current_process ()->priv->thread_db`, assuming the current process
+ matches the ptid passed as a parameter, which is wrong. A segfault
+ happens when trying to dereference that thread_db pointer.
+
+ Fix this by making find_one_thread not assume what the current process /
+ current thread is. If it needs to call into libthread_db, which we know
+ will try to read memory from the current process, then temporarily set
+ the current process.
+
+ In the case where the thread is already know and we return early, we
+ don't need to switch process.
+
+ Add a test to reproduce this specific situation.
+
+ Change-Id: I09b00883e8b73b7e5f89d0f47cb4e9c0f3d6caaa
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-11-28 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in "document" command
+ PR cli/29800 points out that "document" will now crash when the
+ argument is an undefined command. This is a regression due to the
+ "document user-defined aliases" patch.
+
+ Approved-By: Joel Brobecker <brobecker@adacore.com>
+ Reviewed-By: Philippe Waroquiers <philippe.waroquiers@skynet.be>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29800
+
+2022-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le
+ On powerpc64le-linux, I run into:
+ ...
+ (gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
+ step^M
+ 28 { /* first-retry */^M
+ (gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
+ ...
+
+ It's a bit easier to understand what happens if we do a full stepping session:
+ ...
+ Temporary breakpoint 1, main ()
+ at solib-intra-step-main.c:23
+ 23 shlib_first ();
+ (gdb) step
+ shlib_first () at solib-intra-step-lib.c:29
+ 29 shlib_second (0); /* first-hit */
+ (gdb) step
+ 28 { /* first-retry */
+ (gdb) step
+ 29 shlib_second (0); /* first-hit */
+ (gdb) step
+ shlib_second (dummy=0)
+ at solib-intra-step-lib.c:23
+ 23 abort (); /* second-hit */
+ ...
+ and compare that to the line info:
+ ...
+ CU: solib-intra-step-lib.c:
+ File name Line number Starting address View Stmt
+ solib-intra-step-lib.c 22 0x710 x
+ solib-intra-step-lib.c 23 0x724 x
+ solib-intra-step-lib.c 28 0x740 x
+ solib-intra-step-lib.c 29 0x74c x
+ solib-intra-step-lib.c 28 0x750 x
+ solib-intra-step-lib.c 29 0x758 x
+ solib-intra-step-lib.c 30 0x760 x
+ solib-intra-step-lib.c - 0x77c
+ ...
+
+ So we step from line 29 to line 28, and back to line 29, which is behaviour
+ that matches the line table. The peculiar order is due to using optimization.
+ The problem is that the test-case doesn't expect this order.
+
+ Fix this by allowing this order in the test-case.
+
+ Tested on powerpc64le-linux.
+
+ PR testsuite/29792
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29792
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix assert when quitting GDB while a thread is stepping
+ This commit addresses one of the issues identified in PR gdb/28275.
+
+ Bug gdb/28275 identifies a number of situations in which this assert:
+
+ Assertion `!proc_target->commit_resumed_state' failed.
+
+ could be triggered. There's actually a number of similar places where
+ this assert is found in GDB, the two of interest in gdb/28275 are in
+ target_wait and target_stop.
+
+ In one of the comments:
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1
+
+ steps to trigger the assertion within target_stop were identified when
+ using a modified version of the gdb.threads/detach-step-over.exp test
+ script.
+
+ In the gdb.threads/detach-step-over.exp test, we attach to a
+ multi-threaded inferior, and continue the inferior in asynchronous
+ (background) mode. Each thread is continuously hitting a conditional
+ breakpoint where the condition is always false. While the inferior is
+ running we detach. The goal is that we detach while GDB is performing a
+ step-over for the conditional breakpoint in at least one thread.
+
+ While detaching, if a step-over is in progress, then GDB has to
+ complete the step over before we can detach. This involves calling
+ target_stop and target_wait (see prepare_for_detach).
+
+ As far as gdb/28275 is concerned, the interesting part here, is the
+ the process_stratum_target::commit_resumed_state variable must be
+ false when target_stop and target_wait are called.
+
+ This is currently ensured because, in detach_command (infrun.c), we
+ create an instance of scoped_disable_commit_resumed, this ensures that
+ when target_detach is called, ::commit_resumed_state will be false.
+
+ The modification to the test that I propose here, and which exposed
+ the bug, is that, instead of using "detach" to detach from the
+ inferior, we instead use "quit". Quitting GDB after attaching to an
+ inferior will cause GDB to first detach, and then exit.
+
+ When we quit GDB we end up calling target_detach via a different code
+ path, the stack looks like:
+
+ #0 target_detach
+ #1 kill_or_detach
+ #2 quit_force
+ #3 quit_command
+
+ Along this path there is no scoped_disable_commit_resumed created.
+ ::commit_resumed_state can be true when we reach prepare_for_detach,
+ which calls target_wait and target_stop, so the assertion will trigger.
+
+ In this commit, I propose fixing this by adding the creation of a
+ scoped_disable_commit_resumed into target_detach. This will ensure
+ that ::commit_resumed_state is false when calling prepare_for_detach
+ from within target_detach.
+
+ I did consider placing the scoped_disable_commit_resumed in
+ prepare_for_detach, however, placing it in target_detach ensures that
+ the target's commit_resumed_state flag is left to false if the detached
+ inferior was the last one for that target. It's the same rationale as
+ for patch "gdb: disable commit resumed in target_kill" that comes later
+ in this series, but for detach instead of kill.
+
+ detach_command still includes a scoped_disable_commit_resumed too, but I
+ think it is still relevant to cover the resumption at the end of the
+ function.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
+ Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f
+
+2022-11-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: refactor gdb.threads/detach-step-over.exp
+ Factor out some bits of gdb.threads/detach-step-over.exp to procs in
+ preparation to adding some new variations of the test. Rename the
+ existing "test" proc and make it use proc_with_prefix.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189
+
+2022-11-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: remove global declarations in gdb.threads/detach-step-over.exp
+ Before doing further changes to this file, change to use the :: notation
+ instead of declaring global variables with the `global` keyword.
+
+ Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5
+ On powerpc64le-linux, using gcc 4.8.5, I run into:
+ ...
+ (gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
+ next^M
+ 11 c = vec_add (a, b);^M
+ (gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
+ print/x a^M
+ $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
+ (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
+ ...
+
+ Looking at the disassembly and the debug info, it's clear why there's
+ a FAIL.
+
+ The debug info says that the variable can be found at some stack location, but
+ the instructions don't seem to be writing there.
+
+ We can work around this by marking variable a volatile. Likewise for b.
+
+ Note that marking the variables as volatile doesn't change the location
+ information.
+
+ Tested on power64le-linux.
+
+2022-11-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix gdb.base/msym-bp-shl.exp for ppc64le
+ With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into:
+ ...
+ (gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
+ info breakpoint^M
+ Num Type Disp Enb Address What^M
+ 1 breakpoint keep y <MULTIPLE> ^M
+ 1.1 y 0x00000000000008d4 <foo+12>^M
+ 1.2 y 0x0000000000000a34 crti.S:88^M
+ (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
+ ...
+
+ The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34:
+ ...
+ 0000000000000a28 <foo@plt>:
+ a28: c0 ff ff 4b b 9e8 <__glink_PLTresolve>
+
+ Disassembly of section .fini:
+
+ 0000000000000a2c <_fini>:
+ a2c: 02 00 4c 3c addis r2,r12,2
+ a30: d4 74 42 38 addi r2,r2,29908
+ a34: a6 02 08 7c mflr r0
+ ...
+
+ This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as
+ having a local entry point, due to incorrectly accessing an asymbol struct
+ using a (larger) elf_symbol_type.
+
+ Fix this by simply ignoring artificial symbols in
+ ppc_elfv2_elf_make_msymbol_special.
+
+ Tested on powerpc64le.
+
+ Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
+ Reviewed-By: Carl Love <cel@us.ibm.com>
+ Tested-By: Carl Love <cel@us.ibm.com>
+ PR tdep/29814
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814
+
+2022-11-28 Alan Modra <amodra@gmail.com>
+
+ PR10368, ISO 8859 mentioned as 7bit encoding in strings documentation
+ PR 10368
+ * doc/binutils.texi (strings): Delete example of 7-bit encoding.
+
+ Use bfd_rename_section in msp430.em
+ * emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use
+ bfd_rename_section.
+ * testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data
+ and bss input sections.
+
+ asan: pef: buffer overflow
+ * pef.c (bfd_pef_parse_traceback_table): Correct size moved when
+ stripping leading dot.
+
+ regen gas/Makefile.in
+
+2022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Allow merging 'H' extension
+ Because riscv_merge_std_ext function did not merge the 'H' extension, linked
+ executables lacked 'H' extension when multiple objects are merged.
+
+ This issue is found while building OpenSBI with 'H' extension (resulting
+ ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked
+ object files contained it).
+
+ This commit adds 'h' to standard_exts variable to merge 'H' extension.
+
+ bfd/ChangeLog:
+
+ * elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging.
+
+2022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Better support for long instructions (tests)
+ This commit tests both (assembler and disassembler) fixes of "Better support
+ for long instructions".
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/insn.s: Add testcases such that big number
+ handling is required and should be disassembled as long ".byte"
+ sequence with correct instruction bits.
+ * testsuite/gas/riscv/insn.d: Likewise.
+ * testsuite/gas/riscv/insn-na.d: Likewise.
+ * testsuite/gas/riscv/insn-dwarf.d: Likewise.
+
+2022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Better support for long instructions (assembler)
+ Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
+ instructions with .insn") tried to start supporting long instructions but
+ it was insufficient.
+
+ 1. It heavily depended on the bignum internals (radix of 2^16),
+ 2. It generates "value conflicts with instruction length" even if a big
+ number instruction encoding does not exceed its expected length and
+ 3. Because long opcode was handled separately (from struct riscv_cl_insn),
+ some information like DWARF line number correspondence was missing.
+
+ To resolve these problems, this commit:
+
+ 1. Handles bignum (and its encodings) precisely and
+ 2. Incorporates long opcode handling into regular instruction handling.
+
+ This commit will be tested on the separate commit.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field.
+ (create_insn) Clear long opcode marker.
+ (install_insn) Install longer opcode as well.
+ (s_riscv_insn) Likewise.
+ (riscv_ip_hardcode): Make big number handling stricter. Length and
+ the value conflicts only if the bignum size exceeds the expected
+ maximum length.
+
+2022-11-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Better support for long instructions (disassembler)
+ Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
+ instructions with .insn") tried to start supporting long instructions but
+ it was insufficient.
+
+ On the disassembler, correct ".byte" output was limited to the first 64-bits
+ of an instruction. After that, zeroes are incorrectly printed.
+
+ Note that, it only happens on ".byte" output (instruction part) and not on
+ hexdump (data) part. For example, before this commit, hexdump and ".byte"
+ produces different values:
+
+ Assembly:
+ .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
+ objdump output example (before the fix):
+ 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+ 18: 89ab 4567 0123 3210
+ 20: 7654 ba98 fedc
+
+ Note that, after 0xcd (after first 64-bits of the target instruction), all
+ ".byte" values are incorrectly printed as zero while hexdump prints correct
+ instruction bits.
+
+ To resolve this, this commit adds "packet" argument to support dumping
+ instructions longer than 64-bits (to print correct instruction bits on
+ ".byte"). This commit will be tested on the separate commit.
+
+ Assembly:
+ .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
+ objdump output example (after the fix):
+ 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
+ 18: 89ab 4567 0123 3210
+ 20: 7654 ba98 fedc
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_insn): Print unknown instruction
+ using the new argument packet.
+ (riscv_disassemble_data): Add unused argument packet.
+ (print_insn_riscv): Pass packet to the disassemble function.
+
+2022-11-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Fix leak in the dwarf reader
+ Valgrind reports a leak in the dwarf reader (see details below).
+ The function dw2_get_file_names_reader is interning in the per_objfile
+ all the file names it finds, except the name of 'fnd file name and directory'.
+ Instead, it was xstrdup-ing the name.
+ Fix the leaks by also interning the name.
+
+ This was validated running the tests natively, and under valgrind.
+ Leaks have decreased as mentionned below.
+ Valgrind detected no error such as double free or use after free.
+
+ Stack trace of the leak:
+ ==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074
+ ==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393)
+ ==4113266== by 0x25A454: xmalloc (alloc.c:57)
+ ==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34)
+ ==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825)
+ ==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851)
+ ==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149)
+ ==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688)
+ ==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207)
+ ==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633)
+ ==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712)
+ ==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726)
+ ==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329)
+ ==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388)
+ ==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104)
+ ==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149)
+ ...
+
+ Without the fix, the top 10 leaks are:
+ ./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks
+ ./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks
+ ./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks
+ ./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks
+ ./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks
+ ./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks
+ ./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks
+ ./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks
+ ./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks
+ ./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks
+
+ With the fix:
+ ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks
+ ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks
+ ./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks
+ ./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks
+ ./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks
+ ./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks
+ ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks
+ ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks
+ ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks
+ ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ fix leak in gdb_environ
+ valgrind reports a leak when assigning a gdb_environ to another gdb_environ.
+ The memory allocated for the target gdb_environ env variables is not released.
+ The gdb_environ selftest reproduces the leak (see below).
+ Fix the leak by clearing the target gdb_environ before std::move-ing the
+ members.
+
+ Tested natively and re-running all tests under valgrind.
+
+ ==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839
+ ==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393)
+ ==3261873== by 0x25A454: xmalloc (alloc.c:57)
+ ==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34)
+ ==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56)
+ ==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78)
+ ==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285)
+ ==3261873== by 0x7EFC43: operator() (std_function.h:622)
+ =
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Use false/true for some inferior class members instead of 0/1
+ Some class members were changed to bool, but there was
+ still some assignments or comparisons using 0/1.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/server] Emit warning for SIGINT failure
+ Consider the executable from test-case gdb.base/interrupt-daemon.exp.
+
+ When starting it using gdbserver:
+ ...
+ $ ./build/gdbserver/gdbserver localhost:2345 \
+ ./outputs/gdb.base/interrupt-daemon/interrupt-daemon
+ ...
+ and connecting to it using gdb:
+ ...
+ $ gdb -q -ex "target remote localhost:2345" \
+ -ex "set follow-fork-mode child" \
+ -ex "break daemon_main" -ex cont
+ ...
+ we are setup to do the same as in the test-case: interrupt a running inferior
+ using ^C.
+
+ So let's try:
+ ...
+ (gdb) continue
+ Continuing.
+ ^C
+ ...
+ After pressing ^C, nothing happens. This a known problem, filed as
+ PR remote/18772.
+
+ The problem is that in linux_process_target::request_interrupt, a kill is used
+ to send a SIGINT, but it fails. And it fails silently.
+
+ Make the failure verbose by adding a warning, such that the gdbserver output
+ becomes more helpful:
+ ...
+ Process interrupt-daemon created; pid = 15068
+ Listening on port 2345
+ Remote debugging from host ::1, port 35148
+ Detaching from process 15068
+ Detaching from process 15085
+ gdbserver: Sending SIGINT to process group of pid 15068 failed: \
+ No such process
+ ...
+
+ Note that the failure can easily be reproduced using the test-case and target
+ board native-gdbserver:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ PASS: gdb.base/interrupt-daemon.exp: fg: continue
+ ^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
+ ...
+ as reported in PR server/23382.
+
+ Tested on x86_64-linux.
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp
+ When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
+ noticed:
+ ...
+ FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
+ ...
+
+ The timeout is 10 seconds, but generating the core file takes more than a
+ minute, probably due to slow NFS.
+
+ I managed to reproduce this behaviour independently of gdb, by compiling
+ "int main (void) { __builtin_abort (); }" and running it, which took 1.5
+ seconds for a core file 50 times smaller than the one for gdb.
+
+ Fix this by preventing the core file from being generated, using a wrapper
+ around gdb that does "ulimit -c 0".
+
+ Tested on x86_64-linux.
+
+2022-11-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle failure to open .gnu_debugaltlink file
+ If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
+ dwz has created it, with test-case
+ gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
+ we run into:
+ ...
+ (gdb) file access-mem-running-thread-exit^M
+ Reading symbols from access-mem-running-thread-exit...^M
+ could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
+ ...
+ followed a bit later by:
+ ...
+ (gdb) file access-mem-running-thread-exit^M
+ Reading symbols from access-mem-running-thread-exit...^M
+ gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
+ Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
+ ...
+
+ The problem is that create_units does not catch the error thrown by
+ dwarf2_get_dwz_file.
+
+ Fix this by catching the error and performing the necessary cleanup, getting
+ the same result for the first and second file command.
+
+ PR symtab/29805
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
+
+2022-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.
+ Valgrind reports a "jump on unitialised bit error" when running
+ e.g. gdb.base/macro-source-path.exp (see details below).
+
+ Fix this by initializing producer_is_clang member variable of dwarf2_cu.
+
+ Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp
+ under valgrind.
+
+ ==2140965== Conditional jump or move depends on uninitialised value(s)
+ ==2140965== at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676)
+ ==2140965== by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967)
+ ==2140965== by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379)
+ ==2140965== by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687)
+ ==2140965== by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660)
+ ==2140965== by 0x5569C7: process_full_comp_unit (read.c:8429)
+ ==2140965== by 0x5569C7: process_queue (read.c:7675)
+ ==2140965== by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063)
+ ==2140965== by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
+ ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
+ ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
+ ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
+ ....
+ ==2140965== Uninitialised value was created by a heap allocation
+ ==2140965== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434)
+ ==2140965== by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264)
+ ==2140965== by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729)
+ ==2140965== by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021)
+ ==2140965== by 0x55634C: dw2_do_instantiate_symtab (read.c:2048)
+ ==2140965== by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
+ ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
+ ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
+ ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
+ ....
+
+2022-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ remove the declared but undefined/unused method find_partial_die
+ The method
+ struct partial_die_info *find_partial_die (sect_offset sect_off);
+ in cu.h is defined, but is used nowhere and not implemented.
+
+2022-11-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-25 Martin Liska <mliska@suse.cz>
+
+ Revert "readelf: Do not require EI_OSABI for IFUNC."
+ This reverts commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801.
+
+2022-11-25 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ riscv: Add AIA extension support (Smaia, Ssaia)
+ This commit adds the AIA extensions (Smaia and Ssaia) CSRs.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: Add 'smaia' and 'ssaia' to the list
+ of known standard extensions.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class):
+ (riscv_csr_address): Add CSR classes for Smaia/Ssaia.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Add new CSRs.
+ * testsuite/gas/riscv/csr-dw-regnums.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: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+ * testsuite/gas/riscv/csr.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (CSR_MISELECT): New CSR macro.
+ (CSR_MIREG): Likewise.
+ (CSR_MTOPEI): Likewise.
+ (CSR_MTOPI): Likewise.
+ (CSR_MVIEN): Likewise.
+ (CSR_MVIP): Likewise.
+ (CSR_MIDELEGH): Likewise.
+ (CSR_MIEH): Likewise.
+ (CSR_MVIENH): Likewise.
+ (CSR_MVIPH): Likewise.
+ (CSR_MIPH): Likewise.
+ (CSR_SISELECT): Likewise.
+ (CSR_SIREG): Likewise.
+ (CSR_STOPEI): Likewise.
+ (CSR_STOPI): Likewise.
+ (CSR_SIEH): Likewise.
+ (CSR_SIPH): Likewise.
+ (CSR_HVIEN): Likewise.
+ (CSR_HVICTL): Likewise.
+ (CSR_HVIPRIO1): Likewise.
+ (CSR_HVIPRIO2): Likewise.
+ (CSR_VSISELECT): Likewise.
+ (CSR_VSIREG): Likewise.
+ (CSR_VSTOPEI): Likewise.
+ (CSR_VSTOPI): Likewise.
+ (CSR_HIDELEGH): Likewise.
+ (CSR_HVIENH): Likewise.
+ (CSR_HVIPH): Likewise.
+ (CSR_HVIPRIO1H): Likewise.
+ (CSR_HVIPRIO2H): Likewise.
+ (CSR_VSIEH): Likewise.
+ (CSR_VSIPH): Likewise.
+ (DECLARE_CSR): Add CSRs for Smaia and Ssaia.
+
+ Changes for v3:
+ - Imply ssaia for smaia
+ - Imply zicsr for ssaia (and transitively smaia)
+ - Move hypervisor CSRs to Ssaia+H
+ - Rebase on upstream/master
+
+ Changes for v2:
+ - Add hypervisor and VS CSRs
+ - Fix whitespace issue
+
+2022-11-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-24 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe/doc: remove usage of xrefautomaticsectiontitle
+ xrefautomaticsectiontitle appears to be available from texinfo 5.0 or
+ greater. As such, it is not worthwhile to add requirement for a minimum
+ necessary makeinfo version. So remove the usage of it.
+
+ Also align node name with section title where possible.
+
+ ChangeLog:
+
+ * libsframe/doc/sframe-spec.texi: Remove usage of
+ xrefautomaticsectiontitle.
+
+2022-11-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix typo in debug output message
+ Spotted a minor type, a missing ')', in a debug message.
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break
+ Move all the remaining tests to a single test_break proc. It's a bit
+ big, but all of these are kind of tied together. The procs starts by
+ setting breakpoints, checks that we can see them in "info breakpoints",
+ and tries stopping on them.
+
+ Move all the "set bp_locationX" calls together at the top.
+
+ Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_tbreak
+ Leave setting bp_location11 in the global scope, so that it's accessible
+ to other procs.
+
+ Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_no_break_on_catchpoint
+ Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_nonexistent_line
+ Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_default
+ One special thing here is that the part just above this one, that sets
+ catchpoints and verifies they are not hit, requires that we resume
+ execution to verify that the catchpoints are indeed not hit. I guess
+ it was previously achieved by the until command, but it doesn't happen
+ now that the until is moved into test_break_default. Add a
+ gdb_continue_to_end after setting the catchpoints. If any catchpoint
+ were to be hit, it would catch the problem.
+
+ Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_silent_and_more
+ This one is a bit tricky. The clear tests seem to depend on the various
+ breakpoints that have been set before, starting with the "silent"
+ breakpoints. So, move all this in a single chunk, it can always be
+ split later if needed.
+
+ Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_line_convenience_var
+ Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_user_call
+ Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_finish_arguments
+ Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: use proc_with_prefix for test_next_with_recursion
+ This one is already in a proc, just make the proc use proc_with_prefix,
+ for consistency.
+
+ Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_optimized_prologue
+ Change-Id: Ibf17033c8ce72aa5cfe1b739be2902e84a5e945d
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_rbreak_shlib
+ Change-Id: I130e8914c2713095aab03e84aba1481b4c7af978
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_file_line_convenience_var
+ Change-Id: I0c31b037669b2917e062bf431372fb6531f8f53c
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+ gdb/testsuite/gdb.base/break.exp: split test_break_commands_clear
+ Change-Id: Ia58f90117d52fc419fc494836d9b4ed5d902fe9b
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-24 Nick Clifton <nickc@redhat.com>
+
+ Impport libiberty commit: 885b6660c17f from gcc mainline. Fix gas's acinclude.m4 to stop a potwntial configure time warning message.
+
+2022-11-24 Martin Liska <mliska@suse.cz>
+
+ readelf: Do not require EI_OSABI for IFUNC.
+ PR 29718
+
+ binutils/ChangeLog:
+
+ * readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as
+ reserved name.
+
+2022-11-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: widen applicability and use of CheckRegSize
+ First of all make operand_type_register_match() apply to all sized
+ operands, i.e. in Intel Syntax also to respective memory ones. This
+ addresses gas wrongly accepting certain SIMD insns where register and
+ memory operand sizes should match but don't. This apparently has
+ affected all templates with one memory-only operand and one or more
+ register ones, both permitting at least two sizes, due to CheckRegSize
+ not taking effect.
+
+ Then also add CheckRegSize to a couple of non-SIMD templates matching
+ that same pattern of memory-only vs register operands. This replaces
+ bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when
+ none was used at all) by "type mismatch" ones, just like already emitted
+ for insns where the template allows a register operand alongside a
+ memory one at any particular position.
+
+ This also is a prereq to limiting (ideally eliminating in the long run)
+ suffix "derivation" in Intel Syntax mode.
+
+ While making the code adjustment also flip order of checks to do the
+ cheaper one first in both cases.
+
+2022-11-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: add missing CheckRegSize
+ To properly and predictably determine operand size encoding (operand
+ size or REX.W prefixes), consistent operand sizes need to be specified.
+ Add CheckRegSize where this was previously missing.
+
+ x86: correct handling of LAR and LSL
+ Both uniformly only ever take 16-bit memory operands while at the same
+ time requiring matching (in size) register operands, which then also
+ should disassemble that way. This in particular requires splitting each
+ of the templates for the assembler and separating decode of the
+ register and memory forms in the disassembler.
+
+2022-11-24 Alan Modra <amodra@gmail.com>
+
+ Tidy objdump printing of section size
+ * objdump.c (load_specific_debug_section): Use PRIx64 format.
+
+ Constify nm format array
+ * nm.c (formats, format): Make const.
+
+2022-11-24 Alan Modra <amodra@gmail.com>
+
+ PR16995, m68k coldfire emac immediate to macsr incorrect disassembly
+ Mode/reg bits for these insns are 000 Dy, 001 Ay, and 111 100 for the
+ move immediate.
+
+ * m68k-opc.c (m68k_opcodes): Only accept 000 and 001 as mode
+ for move reg to macsr/mask insns.
+
+2022-11-24 Mark Harmstone <mark@harmstone.com>
+
+ gas: Disable --gcodeview on PE targets with no O_secrel
+
+2022-11-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-23 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Include FType bit in EXC_RETURN pattern on v8m
+ For v8m, the EXC_RETURN pattern, without security extension, consists of
+ FType, Mode and SPSEL. These are the same bits that are used in v7m.
+ This patch extends the list of patterns to include also the FType bit
+ and not just Mode and SPSEL bits for v8m targets without security
+ extension.
+
+2022-11-23 Alan Modra <amodra@gmail.com>
+
+ regen POTFILES.in
+
+2022-11-23 Alan Modra <amodra@gmail.com>
+
+ PR22509 - Null pointer dereference on coff_slurp_reloc_table
+ This extends the commit 4581a1c7d304 fix to more targets, which
+ hardens BFD a little. I think the real underlying problem was the
+ bfd_canonicalize_reloc call in load_specific_debug_section which
+ passed a NULL for "symbols". Fix that too.
+
+ PR 22509
+ bfd/
+ * aoutx.h (swap_ext_reloc_out): Gracefully handle NULL symbols.
+ * i386lynx.c (swap_ext_reloc_out): Likewise.
+ * pdp11.c (pdp11_aout_swap_reloc_out): Likewise.
+ * coff-tic30.c (reloc_processing): Likewise.
+ * coff-tic4x.c (tic4x_reloc_processing): Likewise.
+ * coff-tic54x.c (tic54x_reloc_processing): Likewise.
+ * coff-z80.c (reloc_processing): Likewise.
+ * coff-z8k.c (reloc_processing): Likewise.
+ * ecoff.c (ecoff_slurp_reloc_table): Likewise.
+ * som.c (som_set_reloc_info): Likewise.
+ binutils/
+ * objdump.c (load_specific_debug_section): Pass syms to
+ bfd_canonicalize_reloc.
+
+2022-11-23 Alan Modra <amodra@gmail.com>
+
+ asan: NULL deref in filter_symbols
+ If tdata->symbols is NULL, make tdata->symcount zero too. This makes
+ wasm_get_symtab_upper_bound return the proper result and stops
+ cascading errors.
+
+ * wasm-module.c (wasm_scan_name_function_section): Clear
+ tdata->symcount on error.
+
+2022-11-23 Luis Machado <luis.machado@arm.com>
+
+ Document the memory_tagged argument for memory region callbacks
+ There were no comments in some instances (gdb/defs.h, gdb/core.c and
+ gdb/linux-tdep.c), so address that by adding comments where those are missing.
+
+2022-11-23 Tom de Vries <tdevries@loganberry-1.arch.suse.de>
+
+ Fix gdb.cp/gdb2495.exp on powerpc64le
+ On powerpc64le-linux I ran into this FAIL:
+ ...
+ (gdb) p exceptions.throw_function()^M
+ terminate called after throwing an instance of 'int'^M
+ ^M
+ Program received signal SIGABRT, Aborted.^M
+ 0x00007ffff7979838 in raise () from /lib64/libc.so.6^M
+ The program being debugged was signaled while in a function called from GDB.^M
+ GDB remains in the frame where the signal was received.^M
+ To change this behavior use "set unwindonsignal on".^M
+ Evaluation of the expression containing the function^M
+ (SimpleException::throw_function()) will be abandoned.^M
+ When the function is done executing, GDB will silently stop.^M
+ (gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception \
+ without a handler.
+ ...
+
+ The following happens:
+ - we start an inferior call
+ - an internal breakpoint is set on the global entry point of std::terminate
+ - the inferior call uses the local entry point
+ - the breakpoint is not triggered
+ - we run into std::terminate
+
+ We can fix this by simply adding the missing gdbarch_skip_entrypoint call in
+ create_std_terminate_master_breakpoint, but we try to do this a bit more
+ generic, by:
+ - adding a variant of function create_internal_breakpoint which takes a
+ minimal symbol instead of an address as argument
+ - in the new function:
+ - using both gdbarch_convert_from_func_ptr_addr and gdbarch_skip_entrypoint
+ - documenting why we don't need to use gdbarch_addr_bits_remove
+ - adding a note about possibly
+ needing gdbarch_deprecated_function_start_offset.
+ - using the new function in:
+ - create_std_terminate_master_breakpoint
+ - create_exception_master_breakpoint_hook, which currently uses only
+ gdbarch_convert_from_func_ptr_addr.
+
+ Note: we could use the new function in more locations in breakpoint.c, but
+ as we're not aware of any related failures, we declare this out of scope for
+ this patch.
+
+ Tested on x86_64-linux, powerpc64le-linux.
+
+ Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
+ Tested-by: Carl Love <cel@us.ibm.com>
+ PR tdep/29793
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29793
+
+2022-11-23 Xiao Zeng <zengxiao@eswincomputing.com>
+
+ RISC-V: Make R_RISCV_SUB6 conforms to riscv ABI standard
+ According to the riscv psabi, R_RISCV_SUB6 only allows 6 least significant
+ bits are valid, but since binutils implementation, we usually get 8 bits
+ field for it. That means, the high 2 bits could be other field and have
+ different purpose. Therefore, we should filter the 8 bits to 6 bits before
+ calculate, and then only encode the valid 6 bits back. By the way, we also
+ need the out-of-range check for R_RISCV_SUB6, and the overflow checks for
+ all R_RISCV_ADD/SUB/SET relocations, but we can add them in the future patches.
+
+ Passing riscv-gnu-toolchain regressions.
+
+ bfd/ChangeLog:
+
+ * elfnn-riscv.c (riscv_elf_relocate_section): Take the R_RISCV_SUB6
+ lower 6 bits as the significant bit.
+ * elfxx-riscv.c (riscv_elf_add_sub_reloc): Likewise.
+
+2022-11-23 Mark Harmstone <mark@harmstone.com>
+
+ gas: Add --gcodeview option
+
+ ld: Add section contributions substream to PDB files
+
+2022-11-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-22 John Baldwin <jhb@FreeBSD.org>
+
+ aarch64-fbsd: Use a static regset for the TLS register set.
+ This uses custom collect/supply regset handlers which pass the TLS
+ register number from the gdbarch_tdep as the base register number.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-22 John Baldwin <jhb@FreeBSD.org>
+
+ arm-fbsd: Use a static regset for the TLS register set.
+ This uses custom collect/supply regset handlers which pass the TLS
+ register number from the gdbarch_tdep as the base register number.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Pass an optional register base to the register set helpers.
+ This is needed to permit using the helpers for register sets with a
+ variable base. In particular regnum needs to be converted into a
+ relative register number before passed to regcache_map_supplies.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Use regset supply/collect methods.
+ fbsd-nat includes various helper routines for fetching and storing
+ register sets via ptrace where the register set is described by a
+ regset. These helper routines directly invoke the
+ supply/collect_regset regcache methods which doesn't permit a regset
+ to provide custom logic when fetching or storing a register set.
+ Instead, just use the function pointers from the struct regset
+ directly.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-22 John Baldwin <jhb@FreeBSD.org>
+
+ regcache: Add collect/supply_regset variants that accept a register base.
+ Some register sets described by an array of regcache_map_entry
+ structures do not have fixed register numbers in their associated
+ architecture but do describe a block of registers whose numbers are at
+ fixed offsets relative to some base register value. An example of
+ this are the TLS register sets for the ARM and AArch64 architectures.
+
+ Currently OS-specific architectures create register maps and register
+ sets dynamically using the register base number. However, this
+ requires duplicating the code to create the register map and register
+ set. To reduce duplication, add variants of the collect_regset and
+ supply_regset regcache methods which accept a base register number.
+ For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this
+ base register number to the value from the map entry to determine the
+ final register number.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-22 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Don't define _TLS_MODULE_BASE_ for ld -r
+ bfd/
+
+ PR ld/29820
+ * elfxx-x86.c (_bfd_x86_elf_always_size_sections): Don't define
+ _TLS_MODULE_BASE_ for ld -r.
+
+ ld/
+
+ PR ld/29820
+ * testsuite/ld-x86-64/pr29820.d: New file.
+ * testsuite/ld-x86-64/pr29820.s: Likewise.
+ * testsuite/ld-x86-64/x86-64.ex: Run pr29820.
+
+2022-11-22 Alan Modra <amodra@gmail.com>
+
+ Don't use "long" in readelf for file offsets
+ The aim here is to improve readelf handling of large 64-bit object
+ files on LLP64 hosts (Windows) where long is only 32 bits. The patch
+ changes more than just file offsets. Addresses and sizes are also
+ changed to avoid "long". Most places get to use uint64_t even where
+ size_t may be more appropriate, because that allows some overflow
+ checks to be implemented easily (*alloc changes).
+
+ * dwarf.c (cmalloc, xcmalloc, xcrealloc, xcalloc2): Make nmemb
+ parameter uint64_t.
+ * dwarf.h: Update prototypes.
+ (struct dwarf_section): Make num_relocs uint64_t.
+ * elfcomm.c (setup_archive): Update error format.
+ * elfcomm.h (struct archive_info): Make sym_size, longnames_size,
+ nested_member_origin, next_arhdr_offset uint64_t.
+ * readelf.c (struct filedata): Make archive_file_offset,
+ archive_file_size, string_table_length, dynamic_addr,
+ dynamic_nent, dynamic_strings_length, num_dynamic_syms,
+ dynamic_syminfo_offset uint64_t.
+ (many functions): Replace uses of "unsigned long" with
+ "uint64_t" or "size_t".
+
+2022-11-22 Alan Modra <amodra@gmail.com>
+
+ Re: readelf: use fseeko64 or fseeko if possible
+ Replace the macros with a small wrapper function that verifies the fseek
+ offset arg isn't overlarge.
+
+ * readelf.c (FSEEK_FUNC): Delete, replace uses with..
+ (fseek64): ..this new function.
+ (process_program_headers): Don't cast p_offset to long.
+
+2022-11-22 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Fix obvious typo in b0b23e06c3a
+ As part of the rebase of the patch, I managed to loose the local
+ changes I had for the comments from Tomas in
+ https://sourceware.org/pipermail/gdb-patches/2022-November/193413.html
+ This patch corrects the obvious two typos.
+
+2022-11-22 Michael Matz <matz@suse.de>
+
+ binutils/configure.ac: integrate last change
+ Integrate back checks for fseeko{,64} into configure.ac, so
+ that regeneration works.
+
+ binutils/
+ * configure.ac: Add fseeko, fseeko64 checks.
+ * configure: Regenerate.
+
+2022-11-22 Shahab Vahedi <shahab@synopsys.com>
+
+ opcodes: Correct address for ARC's "isa_config" aux reg
+ This patch changes the address for "isa_config" auxiliary register
+ from 0xC2 to the correct value 0xC1. Moreover, it only exists in
+ arc700+ and not all ARCs.
+
+ opcodes/ChangeLog:
+
+ * arc-regs.h: Change isa_config address to 0xc1.
+ isa_config exists for ARC700 and ARCV2 and not ARCALL.
+
+2022-11-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: remove gcc restriction from gdb.dwarf2/clang-cli-macro.exp
+ With the recent changes to the dwarf assembler, there is no longer a
+ need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as
+ untested. This commit removes that logic.
+
+2022-11-22 Jan Beulich <jbeulich@suse.com>
+
+ gas/sframe: avoid "shadowing" of glibc function name
+ Once again: Old enough glibc has an (unguarded) declaration of index()
+ in string.h, which triggers a "shadows a global declaration" warning
+ with our choice of wanring level and with at least some gcc versions.
+
+2022-11-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-21 Brett Werling <bwerl.dev@gmail.com>
+
+ readelf: use fseeko64 or fseeko if possible
+ Changes readelf to make use first of fseeko64 and then fseeko,
+ depending on which of those is available. If neither is available,
+ reverts to the previous behavior of using fseek.
+
+ This is necessary when building readelf for LLP64 systems, where a
+ long will only be 32 bits wide. If the elf file in question is >= 2 GiB,
+ that is greater than the max long value and therefore fseek will fail
+ indicating that the offset is negative. On such systems, making use of
+ fseeko64 or fseeko will result in the ability so seek past the 2 GiB
+ max long boundary.
+
+ Note that large archive handling in readelf remains to be fixed.
+
+2022-11-21 Alan Modra <amodra@gmail.com>
+
+ PR29807, SIGSEGV when linking fuzzed PE object
+ PR 29807
+ * cofflink.c (_bfd_coff_generic_relocate_section): Skip relocs
+ against symbols with a NULL section.
+
+2022-11-21 Alan Modra <amodra@gmail.com>
+
+ Re: ld: Always output local symbol for relocatable link
+ Remove this code dating back to commit 98790d3a95fc entirely, what it
+ was trying to do is done elsewhere.
+
+ PR ld/29761
+ * elflink.c (elf_link_output_symstrtab): Don't handle symbols
+ in SEC_EXCLUDE sections here.
+
+2022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ When getting the locno of a bpstat, handle the case of bp with null locations.
+ The test py-objfile.exp unloads the current file while debugging the process.
+ This results in bpstat bs->b->loc to become nullptr.
+ Handle this case in breakpoint.c:bpstat_locno.
+
+ Note: GDB crashes on this problem with an internal error,
+ but the end of gdb summary shows:
+ ...
+ === gdb Summary ===
+
+ # of expected passes 36
+
+ The output also does not contain a 'FAIL:'.
+ After the fix, the nr of expected passes increased.
+
+ In the gdb.log output, one can see:
+ ...
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ 0x55698905c5b9 gdb_internal_backtrace_1
+ ../../binutils-gdb/gdb/bt-utils.c:122
+ 0x55698905c5b9 _Z22gdb_internal_backtracev
+ ...
+
+ ERROR: Couldn't send python print(objfile.filename) to GDB.
+ ERROR: : spawn id exp9 not open
+ while executing
+ "expect {
+ -i exp9 -timeout 10
+ -re ".*A problem internal to GDB has been detected" {
+ fail "$message (GDB internal error)"
+ gdb_internal_error..."
+ ("uplevel" body line 1)
+ invoked from within
+ ....
+
+ Wondering if it might be possible to improve gdb_test to have
+ gdb_test "python print(objfile.filename)" "None" \
+ "objfile.filename after objfile is unloaded"
+ reporting a failed result instead of just producing the internal error.
+
+2022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Fix use after free introduced by $_hit_bpnum/$_hit_locno variables.
+ If the commands of the bpstat bs contain commands such as step or next or
+ continue, the BS and its commands are freed by execute_control_command.
+
+ So, we cannot remember the BS that was printed. Instead, remember
+ the bpnum and locno.
+
+ Regtested on debian/amd64 and re-run a few tests under valgrind.
+
+2022-11-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Fix step-over-syscall.exp matching regexp for $bpnum.$locno matching
+ step-over-syscall.exp has some specific tests for gdbserver.
+ The regexp matching breakpoint hit must take the added locno into account.
+
+ Test re-run in 3 modes (normal, native-gdbserver and native-extended-gdbserver).
+
+2022-11-21 Nick Clifton <nickc@redhat.com>
+
+ Fix ARM and AArch64 assembler tests to work in a multi-arch environment.
+ PR 29764
+ gas * testsuite/gas/arm/cpu-cortex-a76ae.d: Add arm prefix to the -m
+ option passed to objdump.
+ * testsuite/gas/arm/cpu-cortex-a77.d: Likewise.
+ * testsuite/gas/aarch64/cpu-cortex-a76ae.d: Add aarch64 prefix to
+ the -m option passed to objdump.
+ * testsuite/gas/aarch64/cpu-cortex-a77.d: Likewise.
+
+ bfd * cpu-arm.c (scan): Accept machine names prefixed with "arm:".
+ * cpu-aarch64.c (scan): Accept machine names prefixed with "aarch64:".
+
+ bin * doc/binutils.texi (objdump): Note that the -m option supports
+ the <architecture>:<machine> syntax.
+
+2022-11-21 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Ensure that stack pointers are in sync
+ For targets with secext, msp and psp can be seen as an alias for one
+ of msp_s, msp_ns, psp_s or psp_ns.
+ Without this patch, sp might be secure, but msp or psp is non-secure
+ (this state can not happen in the hardware).
+
+ gdb/arm: Update active msp/psp when switching stack
+ For targets with secext, msp and psp can be seen as an alias for one
+ of msp_s, msp_ns, psp_s or psp_ns. When switching active sp, the
+ corresponding msp/psp needs to be switched too.
+
+2022-11-21 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky just return type from csky_vector_type() for vector resgisters
+ Some gdb stubs may not describe the type for vector registers in the
+ tdesc-xml and only send bitsize="128", gdb can't deal with a reg
+ with default type int with bitsize==128. So Just return csky_vector_type()
+ for vector resgisters.
+
+ gdb/csky return type int32 for float and vector pseudo regs
+ When reg_nr is one of the float and vector pseudo registers,
+ return builtin_type (gdbarch)->builtin_int32 for it.
+
+2022-11-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-20 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ [PR build/29791] gnulib: Disable _GL_ATTRIBUTE_DEALLOC on Solaris
+ gdbsupport compilation badly fails with GCC 12 on Solaris, with errors
+ like
+
+ ../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
+ 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
+ | ^
+ ../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate
+
+ We've not yet been able to determine where the ambiguity actually lies,
+ so this patch works around the issue by disabling _GL_ATTRIBUTE_DEALLOC
+ on Solaris, at least as a workaround for GDB 13.
+
+ As Tom suggested in the PR, this is done using our infrastructure for
+ local gnulib patches.
+
+ Tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and
+ x86_64-pc-linux-gnu.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-20 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Fix sol-thread.c compilation on 32-bit Solaris
+ sol-thread.c fails to compile on 32-bit Solaris: there are several
+ instances of
+
+ In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203,
+ from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28,
+ from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51:
+ /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’:
+ /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=]
+ 416 | warning (_("Specified thread %ld seems to have terminated"),
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29:
+ note: in definition of macro ‘_’
+ 28 | # define _(String) gettext (String)
+ | ^~~~~~
+ /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format
+ string is defined here
+ 416 | warning (_("Specified thread %ld seems to have terminated"),
+ | ~~^
+ | |
+ | long int
+ | %lld
+
+ Fixed by using pulongest () instead.
+
+ Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11,
+ sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with
+ Simon's patch for PR build/29798).
+
+2022-11-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Add missing gdb_prompt in ctxobj.exp to avoid random failure, fix typo.
+ ctxobj.exp fails randomly when computer is loaded.
+ With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
+ I could not make it fail anymore.
+
+ Also fixed a typo in a comment.
+
+2022-11-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum $_hit_locno PR breakpoints/12464
+ This implements the request given in PR breakpoints/12464.
+
+ Before this patch, when a breakpoint that has multiple locations is reached,
+ GDB printed:
+ Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
+
+ This patch changes the message so that bkpt_print_id prints the precise
+ encountered breakpoint:
+ Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
+
+ In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
+ locno is printed when the breakpoint hit has more than one location.
+ Note that according to the GDB user manual node 'GDB/MI Development and Front
+ Ends', it is ok to add new fields without changing the MI version.
+
+ Also, when a breakpoint is reached, the convenience variables
+ $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
+ and location number.
+
+ $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
+ breakpoint, to disable the specific encountered breakpoint, e.g.
+ disable $_hit_bpnum.$_hit_locno
+
+ In case the breakpoint has only one location, $_hit_locno is set to
+ the value 1, so as to allow a command such as:
+ disable $_hit_bpnum.$_hit_locno
+ to disable the breakpoint even when the breakpoint has only one location.
+
+ This also fixes a strange behaviour: when a breakpoint X has only
+ one location,
+ enable|disable X.1
+ is accepted but transforms the breakpoint in a multiple locations
+ breakpoint having only one location.
+
+ The changes in RFA v4 handle the comments of Tom Tromey:
+ - Changed convenience var names from $bkptno/$locno to
+ $_hit_bpnum/$_hit_locno.
+ - updated the tests and user manual accordingly.
+ User manual also explictly describes that $_hit_locno is set to 1
+ for a breakpoint with a single location.
+ - The variable values are now set in bpstat_do_actions_1 so that
+ they are set for silent breakpoints, and when several breakpoints
+ are hit at the same time, that the variables are set to the printed
+ breakpoint.
+
+ The changes in RFA v3 handle the additional comments of Eli:
+ GDB/NEW:
+ - Use max 80-column
+ - Use 'code location' instead of 'location'.
+ - Fix typo $bkpno
+ - Ensure that disable $bkptno and disable $bkptno.$locno have
+ each their explanation inthe example
+ - Reworded the 'breakpoint-hit' paragraph.
+ gdb.texinfo:
+ - Use 'code location' instead of 'location'.
+ - Add a note to clarify the distinction between $bkptno and $bpnum.
+ - Use @kbd instead of examples with only one command.
+
+ Compared to RFA v1, the changes in v2 handle the comments given by
+ Keith Seitz and Eli Zaretskii:
+ - Use %s for the result of paddress
+ - Use bkptno_numopt_re instead of 2 different -re cases
+ - use C@t{++}
+ - Add index entries for $bkptno and $locno
+ - Added an example for "locno" in the mi interface
+ - Added examples in the Break command manual.
+
+2022-11-19 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Ssstateen' extension and its CSRs
+ This commit adds 'Ssstateen' extension, which is a supervisor-visible view
+ of the 'Smstateen' extension. It means, this extension implements sstateen*
+ and hstateen* CSRs of the 'Smstateen' extension.
+
+ Note that 'Smstateen' extension itself is unchanged but due to
+ implementation simplicity, it is implemented so that 'Smstateen' implies
+ 'Ssstateen' (just like 'M' implies 'Zmmul').
+
+ This is based on the latest version of RISC-V Profiles
+ (version 0.9-draft, Frozen):
+ <https://github.com/riscv/riscv-profiles/commit/226b7f643067b29abc6723fac60d5f6d3f9eb901>
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Update implication rules.
+ (riscv_supported_std_s_ext) Add 'Ssstateen' extension.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Rename
+ CSR_CLASS_SMSTATEEN_AND_H{,_32} to CSR_CLASS_SSSTATEEN_...
+ Add CSR_CLASS_SSSTATEEN.
+ (riscv_csr_address): Support new/renamed CSR classes.
+ * testsuite/gas/riscv/csr.s: Add 'Ssstateen' extension to comment.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Reflect changes to
+ error messages.
+ * testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+ * testsuite/gas/riscv/ssstateen-csr.s: Test for 'Ssstateen' CSRs.
+ * testsuite/gas/riscv/ssstateen-csr.d: Likewise.
+ * testsuite/gas/riscv/smstateen-csr-s.d: Test to make sure that
+ supervisor/hypervisor part of 'Smstateen' CSRs are accessible from
+ 'RV32IH_Smstateen', not just from 'RV32IH_Ssstateen' that is tested
+ in ssstateen-csr.d.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h: Update DECLARE_CSR declarations with
+ new CSR classes.
+
+2022-11-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver/linux-x86: move lwp declaration out of __x86_64__ region
+ Commit 4855cbdc3d8f ("gdbserver/linux-x86: make is_64bit_tdesc accept
+ thread as a parameter") caused this when building in 32 bits / i386
+ mode:
+
+ CXX linux-x86-low.o
+ In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24:
+ /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’:
+ /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope
+ 357 | struct thread_info *thr = get_lwp_thread (lwp);
+ | ^~~
+ /home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’
+ 709 | #define get_lwp_thread(lwp) ((lwp)->thread)
+ | ^~~
+
+ This is because it moved the lwp variable declaration inside the
+ __x86_64__ guard, making it unavailable when building in 32 bits mode.
+ Move the lwp variable outside of the __x86_64__ region.
+
+ Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05
+
+2022-11-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver: use current_process in ps_getpid
+ The following patch ("gdbserver: switch to right process in
+ find_one_thread") makes it so find_one_thread calls into libthread_db
+ with a current process but no current thread. This tripped on ps_getpid
+ using current_thread in order to get the process' pid. Get the pid from
+ `current_process ()` instead, which removes the need to have a current
+ thread. Eventually, it would be good to get it from the
+ gdb_ps_prochandle_t structure, to avoid the need for a current process
+ as well.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I9d2fae266419199a2fbc2fde0a5104c6e0dbd2d5
+
+2022-11-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver/linux-x86: make is_64bit_tdesc accept thread as a parameter
+ ps_get_thread_area receives as a parameter the lwpid it must work on.
+ It then calls is_64bit_tdesc, which uses the current_thread as the
+ thread to work on. However, it is not said that both are the same.
+
+ This became a problem when working in a following patch that makes
+ find_one_thread switch to a process but to no thread (current_thread ==
+ nullptr). When libthread_db needed to get the thread area,
+ is_64bit_tdesc would try to get the regcache of a nullptr thread.
+
+ Fix that by making is_64bit_tdesc accept the thread to work on as a
+ parameter. Find the right thread from the context, when possible (when
+ we know the lwpid to work on). Otherwise, pass "current_thread", to
+ retain the existing behavior.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007
+
+2022-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver/linux: take condition out of callback in find_lwp_pid
+ Just a small optimization, it's not necessary to recompute lwp at each
+ iteration.
+
+ While at it, change the variable type to long, as ptid_t::lwp returns a
+ long.
+
+ Reviewed-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105
+
+2022-11-18 Johnson Sun <j3.soon777@gmail.com>
+
+ Fix deletion of FinishBreakpoints
+ Currently, FinishBreakpoints are set at the return address of a frame based on
+ the `finish' command, and are meant to be temporary breakpoints. However, they
+ are not being cleaned up after use, as reported in PR python/18655. This was
+ happening because the disposition of the breakpoint was not being set
+ correctly.
+
+ This commit fixes this issue by correctly setting the disposition in the
+ post-stop hook of the breakpoint. It also adds a test to ensure this feature
+ isn't regressed in the future.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655
+
+2022-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix symtab.c build on 32 bit targets
+ When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get:
+
+ CXX symtab.o
+ /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function ‘std::vector<symbol_search> global_symbol_searcher::search() const’:
+ /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
+ 4961 | sprintf (tmp, "operator%.*s%s", fix, " ", opname);
+ | ^
+ In file included from /usr/include/stdio.h:894,
+ from ../gnulib/import/stdio.h:43,
+ from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86,
+ from /home/smarchi/src/binutils-gdb/gdb/defs.h:28,
+ from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20:
+ In function ‘int sprintf(char*, const char*, ...)’,
+ inlined from ‘std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16:
+ /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647
+ 38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 39 | __glibc_objsize (__s), __fmt,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 40 | __va_arg_pack ());
+ | ~~~~~~~~~~~~~~~~~
+
+ PR build/29798 shows a similar error message but on Solaris.
+
+ Work around that by using string_printf. It is a good thing to get rid
+ of the alloca anyway.
+
+ Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assembler
+ Convert the gdb.cp/call-method-register.exp test to make use of the
+ DWARF assembler.
+
+ The existing gdb.cp/call-method-register.exp test relies on a GCC
+ extension - forcing a local variable into a particular named register.
+
+ This means that the test will only work with Clang, and, as we have to
+ name the register into which the variable will be placed, will only
+ work for those targets where we've selected a suitable register,
+ currently this is x86-64, i386, and ppc64.
+
+ By switching to the DWARF assembler, the test will work with gcc and
+ clang, and should work on most, if not all, architectures.
+
+ The test creates a small structure, something that can fit within a
+ register, and then tries to call a method on the structure from within
+ GDB. This should fail because GDB can't take the address of the in
+ register structure (for the `this` pointer).
+
+ As the test is for a failure case, then we don't really care _which_
+ register the structure is in, and I take advantage of this for the
+ DWARF assembler test, I just declare that the variable is in
+ DW_OP_reg0, whatever that might be. I've tested the new test on
+ x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all
+ these architectures, which is already more than we used to cover.
+
+ Additionally, on x86-64, I've tested with Clang and gcc, and the test
+ runs and passed with both compilers.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with Clang
+ The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single
+ failure when run with some older versions of Clang, e.g. 9.0.1.
+
+ The problem appears to be with Clang's generated line table. The test
+ source looks like this:
+
+ int
+ main()
+ {
+ asm ("main_label: .globl main_label");
+ return 0;
+ }
+
+ In GDB, when we 'start', we expect to stop at the 'return 0;' line.
+ This is the behaviour when the compiler is gcc, or later versions of
+ Clang.
+
+ However, with Clang 9.0.2, I see GDB stop on the 'asm' line.
+
+ In this commit I'll fix this issue by placing a breakpoint on the
+ return line, and then using gdb_continue_to_breakpoint to ensure we
+ have stopped in the correct place.
+
+ Of course, using gdb_continue_to_breakpoint will only work if we are
+ not already stopped at the breakpoint location, so I've added some
+ filler work before the 'return 0;' line. With this done we can use
+ gdb_continue_to_breakpoint in all cases.
+
+ As a result of adding the new filler work, one of the later tests,
+ that used the 'list' command, no longer see the correct expected
+ output (the top line of the source file is no longer included in the
+ output). I've fixed this by listing a known specific line, the test
+ is checking that GDB managed to find the source file, it doesn't
+ matter which source line we list, as long as we can list something.
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: rename source file gdb.debuginfod/main.c
+ The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file
+ named main.c. I can't see any particular reason why the file is named
+ as such.
+
+ Usually test source files are named after the test script.
+
+ This commit just renames the source file inline with the test script,
+ and updates the call to standard_testfile (removing the reference to
+ main.c).
+
+ There's no particular reason for this change other than seeing the
+ file named main.c made me thing that the source file must be shared
+ with some other test (it isn't).
+
+ There should be no change in what is tested after this commit.
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add (and use) a new build-id compile option
+ I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was
+ failing when run with Clang as the compiler.
+
+ This test relies on the compiled binaries having a build-id within
+ them. For GCC, really GNU ld, the default is to always include a
+ build-id.
+
+ When compiling with Clang though, the default is for no build-id.
+
+ I did consider *always* turning on the build-id feature when the
+ compiler is Clang, but that felt a little weird.
+
+ Instead, I propose that we add a new 'build-id' compiler option to
+ gdb_compile, this flag indicates that the test _requires_ a build-id.
+ In gcc_compile we can then add the required flags if the compiler is
+ Clang so that we do get a build-id.
+
+ With this change the gdb.debuginfod/fetch_src_and_symbols.exp test
+ now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with
+ gcc. The 'mostly' part is an unrelated issue, and will be addressed
+ in a later commit in this series.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.compile/compile-ops.exp with clang
+ I noticed that the gdb.compile/compile-ops.exp test was failing when
+ run with Clang as the compiler.
+
+ This test makes use of the DWARF assembler, and, it turns out, uses
+ a technique which is not portable to Clang. This problem is
+ described in the comment on the function_range proc in lib/dwarf.exp,
+ the explanation is:
+
+ # If the compiler is gcc, we can do the following to get function start
+ # and end address too:
+ #
+ # asm ("func_start: .globl func_start");
+ # static void func (void) {}
+ # asm ("func_end: .globl func_end");
+ #
+ # however, this isn't portable, because other compilers, such as clang,
+ # may not guarantee the order of global asms and function. The code
+ # becomes:
+ #
+ # asm ("func_start: .globl func_start");
+ # asm ("func_end: .globl func_end");
+ # static void func (void) {}
+
+ These start/end labels are used for computing the function start, end,
+ and length. The portable solution is to place a label within the
+ function, like this:
+
+ # int main (void)
+ # {
+ # asm ("main_label: .globl main_label");
+ # return 0;
+ # }
+
+ And make use of 'proc function_range' (from lib/dwarf.exp).
+
+ So, that's what I do in this commit.
+
+ One consequence of this change is that we need to compile the source
+ file, and have it loaded into a GDB session, before calling
+ function_range, so I've added an early call to prepare_for_testing.
+
+ Additionally, this test script was generating the DWARF assembler into
+ a file called gdbjit-ops.S, I suspect a copy and paste issue there, so
+ I've switched this to use compile-ops-dbg.S instead, which is more
+ inline with what other DWARF assembler tests do.
+
+ The only other change, which might be a problem, is that I also
+ deleted these two lines from the source file:
+
+ asm (".section \".text\"");
+ asm (".balign 8");
+
+ These lines were setting the alignment of the .text section. What I
+ don't know is whether this was significant or not. If it is
+ significant, then I can't see why.
+
+ On x86-64, the test still passes fine without these lines, but that
+ doesn't mean the test wont start failing on some other architecture.
+
+ Still, I figure, lets remove them, then, if/when we find a test that
+ starts failing, we can add the lines back, along with an explanation
+ for why the extra alignment is required.
+
+ But, if people would prefer to be more conservative, then I'm happy to
+ just add the lines back.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang
+ I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was
+ failing when run with Clang. Or rather, the test was not running as
+ the test executable failed to compile.
+
+ The problem is that Clang was emitting this warning:
+
+ warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
+
+ This warning is emitted when compiling the assembler file generated
+ by the DWARF assembler.
+
+ Most DWARF assembler tests generate the assembler file into a file
+ with the '.S' extension. However, this particular test uses a '.s'
+ extension.
+
+ Now a .S file will be passed through the preprocessor, while a .s will
+ be sent straight to the assembler. My guess is that Clang doesn't
+ support the -fdiagnostics-color=never option for the assembler, but
+ does for the preprocessor.
+
+ That's a little annoying, but easily worked around. We don't care if
+ our assembler file is passed through the preprocessor, so, in this
+ commit, I just change the file extension from .s to .S, and the
+ problem is fixed.
+
+ Currently, the unavailable-dwarf-piece.exp script names the assembler
+ file using standard_output_file, in this commit I've switched to make
+ use of standard_testfile, as that seems to be the more common way of
+ doing this sort of thing.
+
+ With these changes the test now passes with Clang 9.0.1 and 15.0.2,
+ and also still passes with gcc.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: don't avoid DWARF assembler tests with Clang
+ Two tests make the claim that the DWARF assembler requires gcc,
+ however, this isn't true. I think at one point, when the DWARF
+ assembler was first added, we did use some techniques that were not
+ portable (see the comments in lib/dwarf.exp on function_range for
+ details), however, I think most DWARF assembler tests will now work
+ fine with Clang.
+
+ The two tests that I modify in this commit both work fine with Clang,
+ at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any
+ problems, so I'm removing the early return logic that stops these
+ tests from running with Clang.
+
+ Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
+
+2022-11-18 Zac Walker <zac.walker@linaro.org>
+
+ GAS fix alignment for aarch64-pe
+ Fixes issue where various values of '.align' causes writing of COFF files to fail.
+ Specific to the aarch64-pe target.
+
+2022-11-18 Alan Modra <amodra@gmail.com>
+
+ PR29799 heap buffer overflow in display_gdb_index dwarf.c:10548
+ PR 29799
+ * dwarf.c (display_gdb_index): Typo fix.
+
+ go32 sanity check
+ * coff-stgo32 (go32exe_check_format): Sanity check stubsize against
+ filesize before malloc.
+
+ Regen potfiles for sframe
+
+2022-11-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-17 Indu Bhagat <indu.bhagat@oracle.com>
+
+ [gas, aarch64]: fix build breakage for aarch64-pe
+ SFrame is supported for ELF only. Keep the definitions and declarations
+ guarded with OBJ_ELF consistently.
+
+ ChangeLog:
+
+ * gas/config/tc-aarch64.h: Guard SFrame related definitions
+ with OBJ_ELF.
+
+2022-11-17 Tom Tromey <tromey@adacore.com>
+
+ Fix static initialization order problem in windows-nat.c
+ This patch fixes a static initialization order problem in
+ windows-nat.c that was pointed out by Jon Turney. The underlying
+ problem is that the windows_nat_target constructor relies on
+ serial_logfile already being constructed, but this is not enforced by
+ C++ rules. This patch fixes the problem by initializing the global
+ windows_nat_target later.
+
+2022-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ opcodes: Define NoSuf in i386-opc.tbl
+ Use NoSuf to replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf
+ and add the explicit NoSuf to AddrPrefixOpReg in templates.
+
+ * i386-opc.tbl (NoSuf): New macro.
+ (AddrPrefixOpReg): Remove No_?Suf.
+ Replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf with
+ NoSuf in templates.
+ Add NoSuf to AddrPrefixOpReg in templates.
+
+2022-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Move i386_seg_prefixes to gas
+ gas/
+
+ * config/tc-i386.c (i386_seg_prefixes): New. Moved from opcodes.
+
+ opcodes/
+
+ * i386-opc.c (i386_seg_prefixes): Removed.
+ * i386-opc.h (i386_seg_prefixes): Likewise.
+
+2022-11-17 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix gdb.base/retval-large-struct.exp
+ Support for printining non-trivial return values was recently added in
+ commit:
+
+ commit a0eda3df5b750ae32576a9be092b361281a41787
+ Author: Carl Love <cel@us.ibm.com>
+ Date: Mon Nov 14 16:22:37 2022 -0500
+
+ PowerPC, fix support for printing the function return value for non-trivial values.
+
+ The functionality can now be used to fix gdb.base/retval-large-struct.exp.
+ The test just needs to be compiled with -fvar-tracking to enable GDB to
+ determine the address off the return buffer when the function is called.
+
+ The current output from the test:
+
+ 34 return big_struct;
+ (gdb) PASS: gdb.base/retval-large-struct.exp: continue to breakpoint: Break in print_large_struct
+ finish
+ warning: Cannot determine the function return value.
+ Try compiling with -fvar-tracking.
+ Run till exit from #0 return_large_struct () at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:34
+ main (argc=1, argv=0x7fffffffcd58) at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:44
+ 44 return 0;
+ Value returned has type: struct big_struct_t. Cannot determine contents
+ (gdb) FAIL: gdb.base/retval-large-struct.exp: finish from return_large_struct
+ testcase binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.exp completed in 1 seconds
+
+ This patch adds the command line argument -fvar-tracking to enable gdb to
+ determine the return vaule and thus fixing the test.
+
+ Patch tested on Power 10 with no regressions.
+
+2022-11-17 Tom Tromey <tromey@adacore.com>
+
+ Use boolean literals for pagination_enabled
+ I noticed a couple of spots that used '0' rather than 'false' when
+ modifying pagination_enabled. This patch cleans these up.
+
+2022-11-17 Carl Love <cel@us.ibm.com>
+
+ Change NULL to nullptr in gdb/infcmd.c and gdb/infrun.c
+ The GDB coding standard specifies that nullptr should be used instead of
+ NULL. There are numerous uses of NULL and nullptr in files infcmd.c and
+ infrun.c. This patch replaces the various uses of NULL with nullptr in
+ the source files. The use of NULL in the comments was not changed.
+
+ The patch does not introduce any functional changes.
+
+ The patch has been tested on PowerPC and Intel X86_64 with no new unexpected
+ test failures, unresolved tests, new core files etc.
+
+2022-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Always call elf_backend_output_arch_local_syms
+ Always call elf_backend_output_arch_local_syms since only the backend
+ knows if elf_backend_output_arch_local_syms is needed when all symbols
+ are striped. elf_backend_output_arch_local_syms is defined only for
+ x86, ARM and AARCH64. On x86, elf_backend_output_arch_local_syms must
+ be called to handle local IFUNC symbols even if all symbols are striped.
+ Update ARM and AARCH64 to skip elf_backend_output_arch_local_syms when
+ symbols aren't needed.
+
+ bfd/
+
+ PR ld/29797
+ * elf32-arm.c (elf32_arm_output_arch_local_syms): Skip if symbols
+ aren't needed.
+ * elfnn-aarch64.c (elfNN_aarch64_output_arch_local_syms):
+ Likewise.
+ * elflink.c (bfd_elf_final_link): Always call
+ elf_backend_output_arch_local_syms if available.
+
+ ld/
+
+ PR ld/29797
+ * testsuite/ld-elf/linux-x86.exp: Run PR ld/29797 test.
+ * testsuite/ld-elf/pr29797.c: New file.
+
+2022-11-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: new $_inferior_thread_count convenience variable
+ Add a new convenience variable $_inferior_thread_count that contains
+ the number of live (non-exited) threads in the current inferior. This
+ can be used in command scripts, or breakpoint conditions, etc to
+ adjust the behaviour for multi-threaded inferiors.
+
+ This value is only stable in all-stop mode. In non-stop mode, where
+ new threads can be started, and existing threads exit, at any time,
+ this convenience variable can give a different value each time it is
+ evaluated.
+
+2022-11-17 Tom Tromey <tromey@adacore.com>
+
+ Remove two obsolete declarations
+ I happened to find a couple of obsolete declarations in cli-interp.h.
+ This patch removes them. Tested by rebuilding.
+
+2022-11-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix failure in gdb.python/py-send-packet.exp
+ While working on another patch I noticed that, when run on an AArch64
+ target, the test gdb.python/py-send-packet.exp was failing:
+
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
+ line 106, in run_auxv_send_packet_test
+ assert string == expected_result
+ AssertionError
+ Error while executing Python code.
+ (gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function
+
+ The test uses 'maint packet ...' to send a packet to gdbserver, and
+ then captures the output in TCL. This output is then passed through
+ to a Python function, which performs some actions using the Python
+ API, and compares the results from the Python API to the results
+ captured in TCL from 'maint packet ...'.
+
+ The problem is that the output captured in TCL contains lots of things
+ like '\x000', when this is passed through to Python the '\x' causes
+ this to be treated as an escape code, which isn't what we want - we
+ want the actual string "\x000".
+
+ So, in the TCL part of the test we were expanding '\x' to '\\x', this
+ seemed to work fine for my testing on x86-64.
+
+ However, on AArch64 what I see is that the results from 'maint packet
+ ...' contain a literal '\' character followed by a literal 'x'
+ character. When GDB prints this in the 'maint packet' output, GDB
+ escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.
+
+ However, now our TCL test script kicks in and tries to "fix" the '\x',
+ this means we now have '\\\x', which isn't correct.
+
+ The problem is that in the TCL script we are too restrictive, we
+ expand '\x' to '\\x', but really, we should be expanding all '\'
+ characters, regardless of what follows them. This is what this patch
+ does.
+
+ After this the gdb.python/py-send-packet.exp test passes on AArch64
+ for me.
+
+2022-11-17 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix call functions command bug in 64 bits programs for AIX
+ In AIX for 64 bit programs we need to zero extend variables
+ of integer or enum or char data type.
+
+ Otherwise a zero will get dumped in the register as we memset
+ our word to 0 and we copy non zero extended contents to the cache.
+
+2022-11-17 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/fortran/testsuite: print values and types of string variables
+ While looking through the Fortran tests, I couldn't find a test of GDB
+ printing the value and type of a Fortran string defined using the
+ 'character*SIZE' notation.
+
+ This works fine in GDB right now, but I thought it wouldn't hurt to
+ have a test for this, so this commit adds such a test.
+
+ The test also includes printing a string that includes some embedded
+ special characters: \n \r \t \000 - that's right, as Fortran strings
+ are stored as an address and length, it is fine to include an embedded
+ null, so this test includes an example of that.
+
+ Standard Fortran doesn't support backslash escape sequences within
+ strings, the special characters must be generated using the `achar`
+ function. However, when GDB prints the strings we currently print
+ using the standard C like backslash sequences.
+
+ I'm not currently proposing to change that behaviour, the backslash
+ sequences are more compact than the standard Fortran way of doing
+ things, and are so widely used that I suspect most Fortran programmers
+ will understand them.
+
+2022-11-17 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Fix various procfs.c compilation errors
+ procfs.c has accumulated several compilation errors lately (some of them
+ new with GCC 12), which are fixed by this patch:
+
+ * auxv_parse gets:
+
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error: \91int
+ procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)\92
+ marked \91override\92, but does not override
+ 144 | int auxv_parse (gdb_byte **readptr,
+ | ^~~~~~~~~~
+
+ Obviouly, procfs.c was missed in the auxv_parse constification.
+
+ * dead_procinfo has:
+
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function \91void
+ dead_procinfo(procinfo*, const char*, int)\92:
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address
+ of \91procinfo::pathname\92 will never be NULL [-Waddress]
+ 563 | if (pi->pathname)
+ | ~~~~^~~~~~~~
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note:
+ \91procinfo::pathname\92 declared here
+ 238 | char pathname[MAX_PROC_NAME_SIZE]; /* Pathname to /proc entry */
+ | ^~~~~~~~
+
+ The warning is correct, so the code can lose support for the NULL
+ pathname case.
+
+ * create_inferior has this ugly warning:
+
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function \91virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)\92:
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: \91char* std::strncpy(char*, const char*, size_t)\92 output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
+ 2815 | strncpy (tryname, p, len);
+ | ~~~~~~~~^~~~~~~~~~~~~~~~~
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed here
+ 2814 | len = strlen (p);
+ | ~~~~~~~^~~
+
+ It seems that this is another case of GCC PR middle-end/88059, which
+ Martin Sebor refuses to fix. So I'm using the hack suggested in the
+ PR to use memcpy instead of strncpy.
+
+ * find_memory_regions_callback fails with
+
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function \91int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)\92:
+ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few arguments to function
+ 3167 | return (*func) ((CORE_ADDR) map->pr_vaddr,
+ | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 3168 | map->pr_size,
+ | ~~~~~~~~~~~~~
+ 3169 | (map->pr_mflags & MA_READ) != 0,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 3170 | (map->pr_mflags & MA_WRITE) != 0,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 3171 | (map->pr_mflags & MA_EXEC) != 0,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 3172 | 1, /* MODIFIED is unknown, pass it as true. */
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 3173 | data);
+ | ~~~~~
+
+ Again, procfs.c was overlooked when adding the new memory_tagged arg.
+ Unfortunately, it wasn't even documented in gdb/defs.h when it was
+ added in
+
+ commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
+ Author: Luis Machado <luis.machado@arm.com>
+ Date: Thu Mar 31 11:42:35 2022 +0100
+
+ [AArch64] MTE corefile support
+
+ With those changes, procfs.c compiles again. Together with the hack
+ from the Solaris gdbsupport breakage reported in PR build/29791, I was
+ able to build and test gdb on both amd64-pc-solaris2.11 and
+ sparcv9-sun-solaris2.11.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-17 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head Int vendor extension
+ This patch adds the XTheadInt extension, which provides interrupt
+ stack management instructions.
+
+ The XTheadFmv extension is documented in the RISC-V toolchain
+ contentions:
+ https://github.com/riscv-non-isa/riscv-toolchain-conventions
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-11-17 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head Fmv vendor extension
+ This patch adds the XTheadFmv extension, which allows to access the
+ upper 32 bits of a double-precision floating-point register in RV32.
+
+ The XTheadFmv extension is documented in the RISC-V toolchain
+ contentions:
+ https://github.com/riscv-non-isa/riscv-toolchain-conventions
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-11-17 Tom de Vries <tdevries@jostaberry-8.arch.suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.arch/ppc-fp.exp
+ I noticed:
+ ...
+ DUPLICATE: gdb.arch/ppc-fp.exp: next
+ ...
+
+ Fix this by adding unique test names.
+
+ Tested on powerpc64le-linux.
+
+2022-11-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-16 Kévin Le Gouguec <legouguec@adacore.com>
+
+ Add myself to the gdb/MAINTAINERS write-after-approval list
+
+2022-11-16 Kévin Le Gouguec <legouguec@adacore.com>
+
+ Guard against frame.c destructors running before frame-info.c's
+ On x86_64-windows, since 04e2ac7b2a7, we observe this internal error:
+
+ [...]/gdbsupport/intrusive_list.h:458: internal-error: erase_element:
+ Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed.
+
+ Breaking in the destructors for intrusive_list and frame_info_ptr shows that
+ in this configuration, the destructors for frame.c's statically-stored
+ objects are run before frame-info.c's:
+
+ Thread 1 hit Breakpoint 7, intrusive_list<frame_info_ptr,
+ intrusive_base_node<frame_info_ptr> >::~intrusive_list (this=0x7ff69c418c90
+ <frame_info_ptr::frame_list>, __in_chrg=<optimized out>)
+ [...]/../gdbsupport/intrusive_list.h:250
+ 250 clear ();
+ (gdb) bt
+ #0 intrusive_list<frame_info_ptr, intrusive_base_node<frame_info_ptr> >
+ ::~intrusive_list (this=0x7ff69c418c90 <frame_info_ptr::frame_list>,
+ __in_chrg=<optimized out>) [...]/../gdbsupport/intrusive_list.h:250
+ #1 0x00007ff69b78edba in __tcf_1 () [...]/frame-info.c:27
+ #2 0x00007ff9c457aa9f in msvcrt!_initterm_e ()
+ from C:\Windows\System32\msvcrt.dll
+ #3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
+ [...]/main.c:1111
+ #4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
+ #5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
+ #6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32
+ (gdb) c
+ Continuing.
+
+ Thread 1 hit Breakpoint 8, frame_info_ptr::~frame_info_ptr
+ (this=0x7ff69c418e20 <selected_frame>, __in_chrg=<optimized out>)
+ [...]/frame-info.h:74
+ 74 if (is_linked ())
+ (gdb) bt
+ #0 frame_info_ptr::~frame_info_ptr (this=0x7ff69c418e20 <selected_frame>,
+ __in_chrg=<optimized out>) [...]/frame-info.h:74
+ #1 0x00007ff69b79a643 in __tcf_1 () [...]/frame.c:1675
+ #2 0x00007ff9c457aa9f in msvcrt!_initterm_e () from
+ C:\Windows\System32\msvcrt.dll
+ #3 0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
+ [...]/main.c:1111
+ #4 0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
+ #5 0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
+ #6 0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR29788, gprofng cannot display Java's generated assembly code
+ gprofng/ChangeLog
+ 2022-11-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29788
+ * src/Experiment.h: Declare dyntext_name.
+ * src/Experiment.cc: Use dyntext_name to initialize img_fname.
+
+2022-11-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use gdb_gcore_cmd in gdb.threads/gcore-thread.exp
+ I noticed a plain gcore command in test-case gdb.threads/gcore-thread.exp:
+ ...
+ gdb_test "gcore $core0file" "Saved corefile .*" \
+ "save a zeroed-threads corefile"
+ ...
+
+ Use gdb_gcore_cmd instead.
+
+ Tested on x86_64-linux.
+
+2022-11-16 Carl Love <cel@us.ibm.com>
+
+ Bug fix in commit for printing the function return value for non-trivial values
+ The recent commit:
+
+ commit a0eda3df5b750ae32576a9be092b361281a41787
+ Author: Carl Love <cel@us.ibm.com>
+ Date: Mon Nov 14 16:22:37 2022 -0500
+
+ PowerPC, fix support for printing the function return value for non-trivial values.
+
+ Is generating a segmentation fault on x86_64-linux.
+
+ segfault:
+ ...
+ PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
+ ERROR: GDB process no longer exists
+ UNRESOLVED: gdb.asm/asm-source.exp: finish from foo3
+ ...
+
+ Reproduced on command line:
+ ...
+ $ gdb -q -batch -x outputs/gdb.asm/asm-source/gdb.in.1
+ ...
+
+ The problem seems to be that:
+ ...
+ Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
+ 0x000000000043de7a in symbol::type (this=0x0) at
+ .../gdb_versions/devel/src/gdb/symtab.h:1287
+ 1287 return m_type;
+ ...
+ because:
+ ...
+ (gdb) up
+ #1 0x0000000000852d94 in finish_command (arg=0x0, from_tty=0)
+ at .../gdb_versions/devel/src/gdb/infcmd.c:1887
+ 1887 = check_typedef (sm->function->type ()->target_type ());
+ (gdb) p sm->function
+ $1 = (symbol *) 0x0
+
+ The code is not checking if sm->function is NULL. If sm->function is NULL
+ the check for the return buffer should be skipped.
+
+2022-11-16 Tom Tromey <tromey@adacore.com>
+
+ Update Ada tasks documentation
+ My co-worker Kévin noticed that the Ada tasks documentation is
+ slightly out of date -- it does not document all the states that can
+ be reported by ada-tasks.c.
+
+ This patch adds the missing states to the appropriate node, and
+ updates one state to reflect a change made some time ago.
+
+2022-11-16 Pedro Alves <palves@redhat.com>
+
+ gdb: add "set style tui-current-position on|off", default to off
+ As discussed at:
+
+ https://sourceware.org/pipermail/gdb-patches/2020-June/169519.html
+
+ this patch disables source and assembly code highlighting for the
+ text highlighted by the TUI's current position indicator, and adds a
+ command to enable it back.
+
+2022-11-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Modernize gdb.arch/i386-biarch-core.exp
+ I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the
+ completion limit for "complete set gnutarget":
+ ...
+ set gnutarget vms-libtxt^M
+ set gnutarget *** List may be truncated, max-completions reached. ***^M
+ (gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget
+ ...
+
+ Fix this by using get_set_option_choices.
+
+ Also use get_set_option_choices for "complete set architecture i386", which
+ required extending get_set_option_choices to accept a second argument, such
+ that we can do:
+ ...
+ set archs [get_set_option_choices "set architecture" "i386"]
+ ...
+ because this returns an empty list:
+ ...
+ set archs [get_set_option_choices "set architecture i386"]
+ ...
+ because it does "complete set architecture i386 ".
+
+ Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead.
+
+ Tested on x86_64-linux.
+
+2022-11-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/ppc64-symtab-cordic.exp without bzip2
+ After de-installing bzip2, I run into:
+ ...
+ Running ppc64-symtab-cordic.exp ...
+ sh: bzip2: command not found
+ PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \
+ src/gdb/testsuite/gdb.arch/cordic.ko.bz2
+ ...
+
+ Fix these by:
+ - using remote_exec instead of catch system, and
+ - using file tail in the untested message.
+
+ I've tried making output redirection work with remote_exec, but that seems to
+ be broken, so we now:
+ - copy the file $f.bz2 into the desired location $dir/$f.bz2, and
+ - decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file
+ $dir/$f.
+
+ Factor out new function decompress_bz2 to make the test-case less verbose, and
+ also use it in gdb.arch/i386-biarch-core.exp.
+
+ Tested on x86_64-linux, without and with bzip2 installed.
+
+2022-11-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ doc: add SFrame spec file
+ ChangeLog:
+
+ * libsframe/Makefile.am: Add info-in-builddir to
+ AUTOMAKE_OPTIONS. Include doc/local.mk.
+ * libsframe/Makefile.in: Regenerated.
+ * libsframe/configure: Likewise.
+ * libsframe/configure.ac: Check for makeinfo and set BUILD_INFO.
+ * libsframe/doc/local.mk: New file.
+ * libsframe/doc/sframe-spec.texi: Likewise.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas/NEWS: add text about new command line option and SFrame support
+ ChangeLog:
+
+ * gas/NEWS: Add SFrame related news.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ binutils/NEWS: add text for SFrame support
+ ChangeLog:
+
+ * binutils/NEWS: Add item for SFrame support.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ src-release.sh: Add libsframe
+ Add libsframe to the list of top level directories that will be included
+ in a release.
+
+ ChangeLog:
+
+ * src-release.sh: Add libsframe
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ readelf/objdump: support for SFrame section
+ This patch adds support for SFrame in readelf and objdump. The arguments
+ of --sframe are optional for both readelf and objdump.
+
+ include/ChangeLog:
+
+ * sframe-api.h (dump_sframe): New function declaration.
+
+ ChangeLog:
+
+ * binutils/Makefile.am: Add dependency on libsframe for
+ readelf and objdump.
+ * binutils/Makefile.in: Regenerate.
+ * binutils/doc/binutils.texi: Document --sframe=[section].
+ * binutils/doc/sframe.options.texi: New file.
+ * binutils/objdump.c: Add support for SFrame format.
+ * binutils/readelf.c: Likewise.
+ * include/sframe-api.h: Add new API for dumping .sframe
+ section.
+ * libsframe/Makefile.am: Add sframe-dump.c.
+ * libsframe/Makefile.in: Regenerate.
+ * libsframe/sframe-dump.c: New file.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ bfd: linker: merge .sframe sections
+ The linker merges all the input .sframe sections. When merging, the
+ linker verifies that all the input .sframe sections have the same
+ abi/arch.
+
+ The linker uses libsframe library to perform key actions on the
+ .sframe sections - decode, read, and create output data. This
+ implies buildsystem changes to make and install libsframe before
+ libbfd.
+
+ The linker places the output .sframe section in a new segment of its
+ own: PT_GNU_SFRAME. A new segment is not added, however, if the
+ generated .sframe section is empty.
+
+ When a section is discarded from the final link, the corresponding
+ entries in the .sframe section for those functions are also deleted.
+
+ The linker sorts the SFrame FDEs on start address by default and sets
+ the SFRAME_F_FDE_SORTED flag in the .sframe section.
+
+ This patch also adds support for generation of SFrame unwind
+ information for the .plt* sections on x86_64. SFrame unwind info is
+ generated for IBT enabled PLT, lazy/non-lazy PLT.
+
+ The existing linker option --no-ld-generated-unwind-info has been
+ adapted to include the control of whether .sframe unwind information
+ will be generated for the linker generated sections like PLT.
+
+ Changes to the linker script have been made as necessary.
+
+ ChangeLog:
+
+ * Makefile.def: Add install dependency on libsframe for libbfd.
+ * Makefile.in: Regenerated.
+ * bfd/Makefile.am: Add elf-sframe.c
+ * bfd/Makefile.in: Regenerated.
+ * bfd/bfd-in2.h (SEC_INFO_TYPE_SFRAME): Regenerated.
+ * bfd/configure: Regenerate.
+ * bfd/configure.ac: Add elf-sframe.lo.
+ * bfd/elf-bfd.h (struct sframe_func_bfdinfo): New struct.
+ (struct sframe_dec_info): Likewise.
+ (struct sframe_enc_info): Likewise.
+ (struct elf_link_hash_table): New member for encoded .sframe
+ object.
+ (struct output_elf_obj_tdata): New member.
+ (elf_sframe): New access macro.
+ (_bfd_elf_set_section_sframe): New declaration.
+ * bfd/elf.c (get_segment_type): Handle new segment
+ PT_GNU_SFRAME.
+ (bfd_section_from_phdr): Likewise.
+ (get_program_header_size): Likewise.
+ (_bfd_elf_map_sections_to_segments): Likewise.
+ * bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): Add
+ contents to the .sframe sections or .plt* entries.
+ * bfd/elflink.c (elf_section_ignore_discarded_relocs): Handle
+ SEC_INFO_TYPE_SFRAME.
+ (_bfd_elf_default_action_discarded): Handle .sframe section.
+ (elf_link_input_bfd): Merge .sframe section.
+ (bfd_elf_final_link): Write the output .sframe section.
+ (bfd_elf_discard_info): Handle discarding .sframe section.
+ * bfd/elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Create
+ .sframe section for .plt and .plt.sec.
+ (_bfd_x86_elf_finish_dynamic_sections): Handle .sframe from
+ .plt* sections.
+ * bfd/elfxx-x86.h (PLT_SFRAME_FDE_START_OFFSET): New
+ definition.
+ (SFRAME_PLT0_MAX_NUM_FRES): Likewise.
+ (SFRAME_PLTN_MAX_NUM_FRES): Likewise.
+ (struct elf_x86_sframe_plt): New structure.
+ (struct elf_x86_link_hash_table): New member.
+ (struct elf_x86_init_table): New members for .sframe
+ creation.
+ * bfd/section.c: Add new definition SEC_INFO_TYPE_SFRAME.
+ * binutils/readelf.c (get_segment_type): Handle new segment
+ PT_GNU_SFRAME.
+ * ld/ld.texi: Update documentation for
+ --no-ld-generated-unwind-info.
+ * ld/scripttempl/elf.sc: Support .sframe sections.
+ * ld/Makefile.am (TESTSFRAMELIB): Use it.
+ (check-DEJAGNU): Likewise.
+ * ld/Makefile.in: Regenerated.
+ * ld/configure.ac (TESTSFRAMELIB): Set to the .so or .a like TESTBFDLIB.
+ * ld/configure: Regenerated.
+ * bfd/elf-sframe.c: New file.
+
+ include/ChangeLog:
+
+ * elf/common.h (PT_GNU_SFRAME): New definition.
+ * elf/internal.h (struct elf_segment_map): Handle new segment
+ type PT_GNU_SFRAME.
+
+ ld/testsuite/ChangeLog:
+
+ * ld/testsuite/ld-bootstrap/bootstrap.exp: Add SFRAMELIB.
+ * ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test
+ sframe-simple-1.
+ * ld/testsuite/ld-aarch64/sframe-bar.s: New file.
+ * ld/testsuite/ld-aarch64/sframe-foo.s: Likewise.
+ * ld/testsuite/ld-aarch64/sframe-simple-1.d: Likewise.
+ * ld/testsuite/ld-sframe/sframe-empty.d: New test.
+ * ld/testsuite/ld-sframe/sframe-empty.s: New file.
+ * ld/testsuite/ld-sframe/sframe.exp: New testsuite.
+ * ld/testsuite/ld-x86-64/sframe-bar.s: New file.
+ * ld/testsuite/ld-x86-64/sframe-foo.s: Likewise.
+ * ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
+ * ld/testsuite/ld-x86-64/sframe-plt-1.d: Likewise.
+ * ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
+ * ld/testsuite/ld-x86-64/x86-64.exp: Add new tests -
+ sframe-simple-1, sframe-plt-1.
+ * ld/testsuite/lib/ld-lib.exp: Add new proc to check if
+ assembler supports SFrame section.
+ * ld/testsuite/ld-sframe/discard.d: New file.
+ * ld/testsuite/ld-sframe/discard.ld: Likewise.
+ * ld/testsuite/ld-sframe/discard.s: Likewise.
+
+2022-11-15 Weimin Pan <weimin.pan@oracle.com>
+
+ libsframe: add the SFrame library
+ libsframe is a library that allows you to:
+ - decode a .sframe section
+ - probe and inspect a .sframe section
+ - encode (and eventually write) a .sframe section.
+
+ This library is currently being used by the linker, readelf, objdump.
+ This library will also be used by the SFrame unwinder which is still
+ to be upstream'd.
+
+ The file include/sframe-api.h defines the user-facing APIs for decoding,
+ encoding and probing .sframe sections. A set of error codes together
+ with their error message strings are also defined.
+
+ Endian flipping is performed automatically at read and write time, if
+ cross-endianness is detected.
+
+ ChangeLog:
+
+ * Makefile.def: Add libsframe as new module with its
+ dependencies.
+ * Makefile.in: Regenerated.
+ * binutils/Makefile.am: Add libsframe.
+ * binutils/Makefile.in: Regenerated.
+ * configure: Regenerated
+ * configure.ac: Add libsframe to host_libs.
+ * libsframe/Makefile.am: New file.
+ * libsframe/Makefile.in: New file.
+ * libsframe/aclocal.m4: New file.
+ * libsframe/config.h.in: New file.
+ * libsframe/configure: New file.
+ * libsframe/configure.ac: New file.
+ * libsframe/sframe-error.c: New file.
+ * libsframe/sframe-impl.h: New file.
+ * libsframe/sframe.c: New file.
+
+ include/ChangeLog:
+
+ * sframe-api.h: New file.
+
+ testsuite/ChangeLog:
+
+ * libsframe/testsuite/Makefile.am: New file.
+ * libsframe/testsuite/Makefile.in: Regenerated.
+ * libsframe/testsuite/libsframe.decode/Makefile.am: New
+ file.
+ * libsframe/testsuite/libsframe.decode/Makefile.in:
+ Regenerated.
+ * libsframe/testsuite/libsframe.decode/decode.exp: New file.
+ * libsframe/testsuite/libsframe.encode/Makefile.am:
+ Likewise.
+ * libsframe/testsuite/libsframe.encode/Makefile.in:
+ Regenerated.
+ * libsframe/testsuite/libsframe.encode/encode.exp: New file.
+ * libsframe/testsuite/libsframe.encode/encode-1.c: Likewise.
+ * libsframe/testsuite/libsframe.decode/be-flipping.c: Likewise.
+ * libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise.
+ * libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise.
+ * libsframe/testsuite/libsframe.decode/DATA-BE: New file.
+ * libsframe/testsuite/libsframe.decode/DATA1: Likewise.
+ * libsframe/testsuite/libsframe.decode/DATA2: Likewise.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: testsuite: add new tests for SFrame unwind info
+ Earlier these tests were in the same commit as previous which adds the
+ support in GNU assembler to generate .sframe section from CFI
+ directives. Splitting this out here for ease of applying and testing.
+
+ ChangeLog:
+
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.d: New file.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-1.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-1.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-2.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-2.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-3.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-3.s: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-4.d: Likewise.
+ * gas/testsuite/gas/cfi-sframe/common-empty-4.s: Likewise.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: generate .sframe from CFI directives
+ Currently supported for x86_64 and aarch64 only.
+
+ [PS: Currently, the compiler has not been adapted to generate
+ ".cfi_sections" with ".sframe" in it. The newly added command line
+ option of --gsframe provides an easy way to try out .sframe support
+ in the toolchain.]
+
+ gas interprets the CFI directives to generate DWARF-based .eh_frame
+ info. These internal DWARF structures are now consumed by
+ gen-sframe.[ch] sub-system to, in turn, create the SFrame unwind
+ information. These internal DWARF structures are read-only for the
+ purpose of SFrame unwind info generation.
+
+ SFrame unwind info generation does not impact .eh_frame unwind info
+ generation. Both .eh_frame and .sframe can co-exist in an ELF file,
+ if so desired by the user.
+
+ Recall that SFrame unwind information only contains the minimal
+ necessary information to generate backtraces and does not provide
+ information to recover all callee-saved registers. The reason being
+ that callee-saved registers other than FP are not needed for stack
+ unwinding, and hence are not included in the .sframe section.
+
+ Consequently, gen-sframe.[ch] only needs to interpret a subset of
+ DWARF opcodes in gas. More details follow.
+
+ [Set 1, Interpreted] The following opcodes are interpreted:
+ - DW_CFA_advance_loc
+ - DW_CFA_def_cfa
+ - DW_CFA_def_cfa_register
+ - DW_CFA_def_cfa_offset
+ - DW_CFA_offset
+ - DW_CFA_remember_state
+ - DW_CFA_restore_state
+ - DW_CFA_restore
+
+ [Set 2, Bypassed] The following opcodes are acknowledged but are not
+ necessary for generating SFrame unwind info:
+ - DW_CFA_undefined
+ - DW_CFA_same_value
+
+ Anything else apart from the two above-mentioned sets is skipped
+ altogether. This means that any function containing a CFI directive not
+ in Set 1 or Set 2 above, will not have any SFrame unwind information
+ generated for them. Holes in instructions covered by FREs of a single
+ FDE are not representable in the SFrame unwind format.
+
+ As few examples, following opcodes are not processed for .sframe
+ generation, and are skipped:
+ - .cfi_personality*
+ - .cfi_*lsda
+ - .cfi_escape
+ - .cfi_negate_ra_state
+ - ...
+
+ Not processing .cfi_escape, .cfi_negate_ra_state will cause SFrame
+ unwind information to be absent for SFrame FDEs that contain these CFI
+ directives, hence affecting the asynchronicity.
+
+ x86-64 and aarch64 backends need to have a few new definitions and
+ functions for .sframe generation. These provide gas with architecture
+ specific information like the SP/FP/RA register numbers and an
+ SFrame-specific ABI marker.
+
+ Lastly, the patch also implements an optimization for size, where
+ specific fragments containing SFrame FRE start address and SFrame FDE
+ function are fixed up. This is similar to other similar optimizations
+ in gas, where fragments are sized and fixed up when the associated
+ symbols can be resolved. This optimization is controlled by a #define
+ SFRAME_FRE_TYPE_SELECTION_OPT and should be easy to turn off if needed.
+ The optimization is on by default for both x86_64 and aarch64.
+
+ ChangeLog:
+
+ * gas/Makefile.am: Include gen-sframe.c and sframe-opt.c.
+ * gas/Makefile.in: Regenerated.
+ * gas/as.h (enum _relax_state): Add new state rs_sframe.
+ (sframe_estimate_size_before_relax): New function.
+ (sframe_relax_frag): Likewise.
+ (sframe_convert_frag): Likewise.
+ * gas/config/tc-aarch64.c (aarch64_support_sframe_p): New
+ definition.
+ (aarch64_sframe_ra_tracking_p): Likewise.
+ (aarch64_sframe_cfa_ra_offset): Likewise.
+ (aarch64_sframe_get_abi_arch): Likewise.
+ (md_begin): Set values of sp/fp/ra registers.
+ * gas/config/tc-aarch64.h (aarch64_support_sframe_p): New
+ declaration.
+ (support_sframe_p): Likewise.
+ (SFRAME_CFA_SP_REG): Likewise.
+ (SFRAME_CFA_FP_REG): Likewise.
+ (SFRAME_CFA_RA_REG): Likewise.
+ (aarch64_sframe_ra_tracking_p): Likewise.
+ (sframe_ra_tracking_p): Likewise.
+ (aarch64_sframe_cfa_ra_offset): Likewise.
+ (sframe_cfa_ra_offset): Likewise.
+ (aarch64_sframe_get_abi_arch): Likewise.
+ (sframe_get_abi_arch): Likewise.
+ * gas/config/tc-i386.c (x86_support_sframe_p): New definition.
+ (x86_sframe_ra_tracking_p): Likewise.
+ (x86_sframe_cfa_ra_offset): Likewise.
+ (x86_sframe_get_abi_arch): Likewise.
+ * gas/config/tc-i386.h (x86_support_sframe_p): New declaration.
+ (support_sframe_p): Likewise.
+ (SFRAME_CFA_SP_REG): Likewise.
+ (SFRAME_CFA_FP_REG): Likewise.
+ (x86_sframe_ra_tracking_p): Likewise.
+ (sframe_ra_tracking_p): Likewise.
+ (x86_sframe_cfa_ra_offset): Likewise.
+ (sframe_cfa_ra_offset): Likewise.
+ (x86_sframe_get_abi_arch): Likewise.
+ (sframe_get_abi_arch): Likewise.
+ * gas/config/tc-xtensa.c (unrelaxed_frag_max_size): Add case for
+ rs_sframe.
+ * gas/doc/as.texi: Add .sframe to the documentation for
+ .cfi_sections.
+ * gas/dw2gencfi.c (cfi_finish): Create a .sframe section.
+ * gas/dw2gencfi.h (CFI_EMIT_sframe): New definition.
+ * gas/write.c (cvt_frag_to_fill): Handle rs_sframe.
+ (relax_segment): Likewise.
+ * gas/gen-sframe.c: New file.
+ * gas/gen-sframe.h: New file.
+ * gas/sframe-opt.c: New file.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ gas: add new command line option --gsframe
+ When --gsframe is specified, the assembler will generate a .sframe
+ section from the CFI directives in the assembly.
+
+ ChangeLog:
+
+ * gas/as.c (parse_args): Parse args and set flag_gen_sframe.
+ * gas/as.h: Introduce skeleton for --gsframe.
+ * gas/doc/as.texi: document --gsframe.
+
+2022-11-15 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe.h: Add SFrame format definition
+ The header sframe.h defines the SFrame format.
+
+ The SFrame format is the Simple Frame format. It can be used to
+ represent the minimal necessary unwind information required for
+ backtracing. The current version supports AMD64 and AARCH64.
+
+ More details of the SFrame format are included in the documentation
+ of the header file in this patch.
+
+ include/ChangeLog:
+ * sframe.h: New file.
+
+2022-11-15 Alan Modra <amodra@gmail.com>
+
+ Re: [gas] arm: Add support for new unwinder directive ".pacspval".
+ * testsuite/gas/arm/ehabi-pacbti-m.d: Limit test to ELF.
+
+2022-11-15 Alan Modra <amodra@gmail.com>
+
+ aarch64-pe can't fill 16 bytes in section .text
+ Without commit b66e671854, this:
+ .p2align 4
+ nop
+ .p2align 3
+ nop
+ results in an error when coff_frob_section attempts to pad out the
+ section to a 16-byte boundary. Due to miscalculating the pad pattern
+ repeat count, write.c:write_contents attempts to shove 16 bytes of
+ padding into the remaining 4 bytes of the .text section.
+
+ * config/obj-coff.c (coff_frob_section): Correct fill count.
+ Don't pad after errors.
+
+2022-11-15 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gdb/configure: regenerate
+ The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an
+ incorrect thunk for the `configure' script. This patch regenerates
+ configure by calling autoreconf.
+
+2022-11-15 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gdb: use libtool in GDB_AC_CHECK_BFD
+ The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the
+ AC_LINK_IFELSE autoconf macro in order to link a simple program to
+ check features of libbfd.
+
+ If libbfd's link dependencies change, it was necessary to reflect them
+ either in the definition of the macro, or as a consequence of checking
+ for them with an autoconf macro resulting in an addition to LIBS.
+
+ This patch modifies the definition of the GDB_CHECK_BFD macro in order
+ to use libtool to perform the test link. This makes it possible to
+ not have to list dependencies of libbfd (which are indirect to GDB) at
+ all.
+
+ After this patch:
+
+ configure:28553: checking for ELF support in BFD
+ configure:28573: ./libtool --quiet --mode=link gcc -o conftest \
+ -I../../gdb/../include -I../bfd \
+ -I../../gdb/../bfd -g -O2 \
+ -L../bfd -L../libiberty conftest.c -lbfd -liberty \
+ -lncursesw -lm -ldl >&5
+ configure:28573: $? = 0
+ configure:28583: result: yes
+
+ Tests performed:
+
+ - Configure --with-system-zlib and --without-system-zlib.
+ - Check link dependencies of installed GDB with both --enable-shared
+ and --disable-shared.
+ - Run installed GDB in both cases.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-15 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in ada_print_type
+ The "varstring" paramter to ada_print_type can be null, but one spot
+ failed to check this. This could cause a crash in some situations.
+
+ As this is Ada-specific, and we've been using it internally at AdaCore
+ for a while, I am going to push it.
+
+2022-11-15 Tejas Joshi <TejasSanjay.Joshi@amd.com>
+
+ Add AMD znver4 processor support
+ 2022-09-28 Tejas Joshi <TejasSanjay.Joshi@amd.com>
+
+ gas/
+
+ * config/tc-i386.c (cpu_arch): Add znver4 ARCH and rmpquery SUBARCH.
+ (md_assemble): Expand comment before swap_operands() with rmpquery.
+ * doc/c-i386.texi: Add znver4.
+ * testsuite/gas/i386/arch-14-1.d: New.
+ * testsuite/gas/i386/arch-14-1.s: New.
+ * testsuite/gas/i386/arch-14-znver4.d: New.
+ * testsuite/gas/i386/i386.exp: Add new znver4 test cases.
+ * testsuite/gas/i386/rmpquery.d: New.
+ * testsuite/gas/i386/rmpquery.s: New.
+ * testsuite/gas/i386/x86-64-arch-4-1.d: New.
+ * testsuite/gas/i386/x86-64-arch-4-1.s: New.
+ * testsuite/gas/i386/x86-64-arch-4-znver4.d: New.
+
+ opcodes/
+
+ * i386-dis.c (x86_64_table): Add rmpquery.
+ * i386-gen.c (cpu_flag_init): Add CPU_ZNVER4_FLAGS and
+ CPU_RMPQUERY_FLAGS.
+ (cpu_flags): Add CpuRMPQUERY.
+ * i386-opc.h (enum): Add CpuRMPQUERY.
+ (i386_cpu_flags): Add cpurmpquery.
+ * i386-opc.tbl: Add rmpquery insn.
+ * i386-init.h: Re-generated.
+ * i386-tbl.h: Re-generated.
+
+2022-11-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: get_set_option_choices: expect \r\n after each item
+ I get some random failures since commit 8d45c3a82a0e ("[gdb/testsuite]
+ Set completions to unlimited in get_set_option_choices"), which can be
+ reproduced with:
+
+ $ make check-read1 TESTS="gdb.base/parse_number.exp"
+
+ For instance:
+
+ set architecture A^M
+ Ambiguous item "A".^M
+ (gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A
+
+ The problem is the regexp in get_set_option_choices, it is possible that
+ is only matches part of a completion result. With check-read1, that is
+ always one letter.
+
+ Fix this by expecting the \r\n at the end of the line, so we only match
+ entire results. Use ^ in match patterns to ensure we don't miss any
+ output.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+ Change-Id: Ib1733737feab7dde0f7095866e089081a891054e
+
+2022-11-15 Andre Vieira <andre.simoesdiasvieira@arm.com>
+
+ aarch64, testsuite: Fixed recently added cssc.d
+ Fixed wrong paste in cssc.d.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/aarch64/cssc.d: Removed duplicate head.
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Normalize gdbserver path name
+ Currently for the target board remote-gdbserver-on-localhost we use the
+ gdbserver file on build, using a file name which includes "/../".
+
+ Fix this by using a normalized file name instead.
+
+ This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
+ can access:
+ ...
+ - remote_exec build "chmod go-rx $objdir/outputs"
+ + remote_exec build "chmod go-rx $objdir"
+ ...
+
+ Tested on x86_64-linux.
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target
+ With test-case gdb.base/jit-elf-so.exp and target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by:
+ - setting jit_libname with the name as returned by gdb_load_shlib
+ - allowing the libraries to be prefixed with the remote target directory.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target
+ With test-case gdb.base/jit-reader-exec.exp and target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix this by adding the missing gdb_remote_download.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/info-shared.exp for remote target
+ With test-case gdb.base/info-shared.exp and target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by adding the missing gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target
+ When running test-case gdb.base/solib-vanish.exp with target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by adding the missing gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target
+ When running test-case gdb.base/infcall-exec.exp with target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into:
+ ...
+ (gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \
+ "$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M
+ $1 = -1^M
+ (gdb) FAIL: gdb.base/infcall-exec.exp: call execlp
+ ...
+
+ Fix this by using just:
+ ...
+ (gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M
+ ...
+ and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2
+ if it's available alongside.
+
+ Also fix the exec name in the test-case, such that we can successfully
+ run the test-case:
+ ...
+ $ ./outputs/gdb.base/infcall-exec/infcall-exec
+ PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec'
+ $
+ ...
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target
+ When running test-case gdb.base/print-file-var.exp with target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by using the name of a shared lib as returned by gdb_load_shlib.
+
+ This required splitting up the gdb_load_shlib functionality, which is now
+ defined as:
+ ...
+ proc gdb_load_shlib { file } {
+ set dest [gdb_download_shlib $file]
+ gdb_locate_shlib $file
+ return $dest
+ }
+ ...
+ such that we can do gdb_download_shlib before gdb is started.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp
+ As reported here
+ ( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
+ number of test-cases fails with a remote target setup, for instance test-case
+ gdb.base/print-file-var.exp.
+
+ So, why don't we see these fails with our remote target boards in
+ gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?
+
+ The problem is that the target board uses the same machine and user for
+ both (by-definition-local) build and remote target, and when using absolute
+ pathnames to refer to files on build, we can access those files on target,
+ which in a real remote target setup wouldn't be the case: we'd have to
+ download them to target first, and then the filename would also be different.
+
+ For aforementioned test-case, this happens when the name of a shared library is
+ passed as absolute file name to gcc:
+ ...
+ gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
+ print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
+ ...
+
+ Make these problems visible with remote-gdbserver-on-localhost.exp by
+ adding an option to specify a test account (still on the same machine)
+ using REMOTE_TARGET_USERNAME.
+
+ We make sure by restricting file permissions, that the test account cannot see
+ the build files on the $USER account, and that the $USER account cannot see
+ the target files on the test account.
+
+ And so we can reproduce the reported fails:
+ ...
+ $ cd build/gdb
+ $ tc="gdb.base/print-file-var.exp"
+ $ tb="--target_board remote-gdbserver-on-localhost"
+ $ tbu="REMOTE_TARGET_USERNAME=remote-target"
+ $ make check RUNTESTFLAGS="$tb $tbu $tc"
+ ...
+ FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
+ version_id_main=0: continue to STOP marker
+ ...
+
+ Tested on x86_64-linux.
+
+ Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target
+ With test-case gdb.base/info_sources_2.exp and target board
+ remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
+ failures.
+
+ Fix these by adding the missing gdb_load_shlib.
+
+ Tested on x86_64-linux.
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target
+ When running test-case gdb.base/foll-exec.exp with target board
+ remote-gdbserver-on-localhost.exp, I run into:
+ ...
+ (gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint
+ continue^M
+ Continuing.^M
+ [Inferior 1 (process 4476) exited normally]^M
+ (gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\
+ xited)
+ ...
+
+ The problem is that the foll-exec executable expects the exec-ed executable
+ execd-prog alongside it, but it's missing.
+
+ Fix this by adding the missing gdb_remote_download.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2022-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml support
+ On aarch64-linux, with a gdb build without libexpat, so without xml support, I
+ run into:
+ ...
+ (gdb) builtin_spawn attach-no-multi-process^M
+ attach 26808^M
+ Attaching to Remote target^M
+ warning: Can not parse XML target description; XML support was disabled at \
+ compile time^M
+ Reading symbols from attach-no-multi-process...^M
+ Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
+ ...
+
+ The test-case checks for skip_gdbserver_tests and that one contains a check
+ for xml support:
+ ...
+ # If GDB is lack of XML support, and targets, like arm, have
+ # multiple target descriptions, GDB doesn't know which target
+ # description GDBserver uses, and may fail to parse 'g' packet
+ # after connection.
+ if { [gdb_skip_xml_test]
+ && ([istarget "arm*-*-linux*"]
+ || [istarget "mips*-*-linux*"]
+ || [istarget "powerpc*-*-linux*"]
+ || [istarget "s390*-*-linux*"]
+ || [istarget "x86_64-*-linux*"]
+ || [istarget "i\[34567\]86-*-linux*"]) } {
+ return 1
+ }
+ ...
+ but it doesn't trigger because aarch64 is missing.
+
+ Fix this by adding istarget "aarch64*-*-linux*".
+
+ Tested on aarch64-linux.
+
+ Approved-By: Luis Machado <luis.machado@arm.com>
+
+2022-11-15 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Enable multi-process debugging for AIX
+ This patch adds multi-process debugging feature in AIX.
+
+ Till now AIX supported debugging only one inferior at a time,
+ now we can be able to debug multi process. Users can use set
+ follow fork mode in child or parent and set detach on fork on
+ or off to enable/disable simultaneous debugging of parent/child.
+
+2022-11-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-14 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix support for printing the function return value for non-trivial values.
+ Currently, a non-trivial return value from a function cannot currently be
+ reliably determined on PowerPC. This is due to the fact that the PowerPC
+ ABI uses register r3 to store the address of the buffer containing the
+ non-trivial return value when the function is called. The PowerPC ABI
+ does not guarantee the value in register r3 is not modified in the
+ function. Thus the value in r3 cannot be reliably used to obtain the
+ return addreses on exit from the function.
+
+ This patch adds a new gdbarch method to allow PowerPC to access the value
+ of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
+ to use the DW_OP_entry_value for the DWARF entries, when exiting the
+ function, to determine the value of r3 on entry to the function. This
+ requires the use of the -fvar-tracking compiler option to compile the
+ user application thus generating the DW_OP_entry_value in the binary. The
+ DW_OP_entry_value entries in the binary file allows GDB to resolve the
+ DW_TAG_call_site entries. This new gdbarch method is used to get the
+ return buffer address, in the case of a function returning a nontrivial
+ data type, on exit from the function. The GDB function should_stop checks
+ to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to
+ zero by the new gdbarch method call for all architectures except PowerPC.
+ The get_return_value function will be used to obtain the return value on
+ all other architectures as is currently being done if RETURN_BUF is zero.
+ On PowerPC, the new gdbarch method will return a nonzero address in
+ RETURN_BUF if the value can be determined. The value_at function uses the
+ return buffer address to get the return value.
+
+ This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
+ The correct function return values are now reported.
+
+ Note this patch is dependent on patch: "PowerPC, function
+ ppc64_sysv_abi_return_value add missing return value convention".
+
+ This patch has been tested on Power 10 and x86-64 with no regressions.
+
+2022-11-14 Carl Love <cel@us.ibm.com>
+
+ PowerPC, function ppc64_sysv_abi_return_value add missing return value convention
+ This patch address five testcase failures in gdb.cp/non-trivial-retval.exp.
+ The following commit resulted in the five testcases failures on PowerPC.
+ The value returned by the function is being reported incorrectly.
+
+ commit b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608
+ Author: Andrew Burgess <aburgess@redhat.com>
+ Date: Mon Dec 13 16:56:16 2021 +0000
+
+ gdb: on x86-64 non-trivial C++ objects are returned in memory
+
+ Fixes PR gdb/28681. It was observed that after using the `finish`
+ command an incorrect value was displayed in some cases. Specifically,
+ this behaviour was observed on an x86-64 target.
+
+ The function:
+
+ enum return_value_convention
+ ppc64_sysv_abi_return_value (struct gdbarch *gdbarch, struct value *function,
+ struct type *valtype, struct regcache *regcache,
+ gdb_byte *readbuf, const gdb_byte *writebuf)
+
+ should return RETURN_VALUE_STRUCT_CONVENTION if the valtype->code() is
+ TYPE_CODE_STRUCT and if the language_pass_by_reference is not
+ trivially_copyable.
+
+ This patch adds the needed code to return the value
+ RETURN_VALUE_STRUCT_CONVENTION in this case.
+
+ With this patch, the five test cases still fail but with the message "Value
+ returned has type: A. Cannot determine contents". The PowerPC ABI stores
+ the address of the buffer containing the function return value in register
+ r3 on entry to the function. However, the PowerPC ABI does not guarentee
+ that r3 will not be modified in the function. So when the function returns,
+ the return buffer address cannot be reliably obtained from register r3.
+ Thus the message "Cannot determine contents" is appropriate in this case.
+
+2022-11-14 Tom Tromey <tromey@adacore.com>
+
+ Remove dump_prefix_expression
+ Since the expression rewrite, dump_prefix_expression has been
+ misnamed. This patch cleans this up by removing the function, turning
+ it into a method on struct expression.
+
+2022-11-14 Andre Vieira <andre.simoesdiasvieira@arm.com>
+
+ aarch64: Add support for Common Short Sequence Compression extension
+ This patch adds support for the CSSC extension and its corresponding
+ instructions: ABS, CNT, CTZ, SMAX, UMAX, SMIN, UMIN.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_operands): Handle new operand types.
+ * doc/c-aarch64.texi: Document new extension.
+ * testsuite/gas/aarch64/cssc.d: New test.
+ * testsuite/gas/aarch64/cssc.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (AARCH64_FEATURE_CSSC): New feature Macro.
+ (enum aarch64_opnd): New operand types.
+ (enum aarch64_insn_class): New instruction class.
+
+ opcodes/ChangeLog:
+
+ * aarch64-asm-2.c: Regenerate.
+ * aarch64-dis-2.c: Regenerate.
+ * aarch64-opc-2.c: Regenerate.
+ * aarch64-opc.c (operand_general_constraint_met_p): Update for new
+ operand types.
+ (aarch64_print_operand): Likewise.
+ * aarch64-opc.h (enum aarch64_field_kind): Declare FLD_CSSC_imm8 field.
+ * aarch64-tbl.h (aarch64_feature_cssc): Define new feature set.
+ (CSSC): Define new feature set Macro.
+ (CSSC_INSN): Define new instruction type.
+ (aarch64_opcode_table): Add new instructions.
+
+2022-11-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold special-operand insn attributes into a single enum
+ Attributes which aren't used together in any single insn template can be
+ converted from individual booleans to a single enum, as was done for a few
+ other attributes before. This is more space efficient. Collect together
+ all attributes which express special operand constraints (and which fit
+ the criteria for folding).
+
+2022-11-14 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ pru: bfd: Correct default to no execstack
+ Data and instruction memories are strictly separated, so it is not
+ possible to execute instructions from the stack memory on PRU.
+
+ I don't see any difference in testsuite results with or without this
+ change.
+
+ bfd/ChangeLog:
+
+ * elf32-pru.c (elf_backend_default_execstack): Define as 0.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack):
+ Return 0 for pru.
+
+2022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ [gas] arm: Add support for new unwinder directive ".pacspval".
+ This patch adds the assembler support for the new unwinder
+ directive ".pacspval" and encodes this directives with opcode
+ "0xb5". This opcode indicates the unwinder to use effective
+ vsp as modifier for PAC validation.
+
+ gas/ChangeLog:
+
+ 2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ * doc/c-arm.texi: Document directive.
+ * config/tc-arm.c (s_arm_unwind_pacspval): Define function.
+ (md_pseudo_table): Add entry for pacspval directive.
+ * testsuite/gas/arm/ehabi-pacbti-m.d: New test.
+ * testsuite/gas/arm/ehabi-pacbti-m.s: Likewise.
+
+2022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ [readelf] arm: Support for new pacbti unwind opcode 0xb5.
+ This patch adds readelf support for decoding the exception
+ table opcode "0xb5", which indicates to use effective vsp
+ as modifier for PAC validation as defined by EHABI
+ (https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf
+ Section 10.3).
+
+ binutils/ChangeLog:
+
+ 2022-11-07 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ * readelf.c (decode_arm_unwind_bytecode): Add entry to decode opcode 0xb5.
+
+2022-11-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdb/unittests: PR28413, suppress warnings generated by Gnulib
+ Gnulib generates a warning if the system version of certain functions
+ are used (to redirect the developer to use Gnulib version). It caused a
+ compiler error when...
+
+ - Compiled with Clang
+ - -Werror is specified (by default)
+ - C++ standard used by Clang is before C++17 (by default as of 15.0.0)
+ when this unit test is activated.
+
+ This issue is raised as PR28413.
+
+ However, previous proposal to fix this issue (a "fix" to Gnulib):
+ <https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00003.html>
+ was rejected because it ruins the intent of Gnulib warnings.
+
+ So, we need a Binutils/GDB-side solution.
+
+ This commit tries to address this issue on the GDB side. We have
+ "include/diagnostics.h" to disable certain warnings only when necessary.
+
+ This commit suppresses the Gnulib warnings by surrounding entire #include
+ block with DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS to disable Gnulib-
+ generated warnings on all standard C++ header files.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28413
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: Ieeb5a31a6902808d4c7263a2868ae19a35e0ccaa
+
+2022-11-14 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ arm: Add support for Cortex-X1C CPU.
+ This patch adds support for Cortex-X1C CPU in Arm.
+
+ bfd/ChangeLog:
+
+ 2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ * cpu-arm.c (processors): Add Cortex-X1C CPU entry.
+
+ gas/ChangeLog:
+
+ 2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ * NEWS: Update docs.
+ * config/tc-arm.c (arm_cpus): Add cortex-x1c to -mcpu.
+ * doc/c-arm.texi: Update docs.
+ * testsuite/gas/arm/cpu-cortex-x1c.d: New test.
+
+2022-11-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=all
+ While looking at test-case gdb.arch/ppc64-symtab-cordic.exp I realized that
+ the test-case is too restrictive here:
+ ...
+ if {![istarget "powerpc*"] || ![is_lp64_target]} {
+ verbose "Skipping powerpc64 separate debug file symtab test."
+ return
+ }
+ ...
+ and can also be run on x86_64-linux, if "set arch powerpc:common64" is
+ supported, which is the case if we've build gdb with --enable-targets=all.
+
+ Fix this by instead checking if powerpc:common64 is in the completion list for
+ "set arch".
+
+ This allows us to remove the 'untested "powerpc:common64 is not supported"'.
+
+ While we're at it, clean up the test-case by using clean_restart.
+
+ Tested on x86_64-linux.
+
+2022-11-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle with_set arch
+ I realized that the more irregular output of show arch:
+ ...
+ (gdb) show arch^M
+ The target architecture is set to "auto" (currently "i386").^M
+ ...
+ would be a problem for something like:
+ ...
+ with_set arch powerpc:common64 {}
+ ...
+ and indeed:
+ ...
+ (gdb) set arch powerpc:common64^M
+ The target architecture is set to "powerpc:common64".^M
+ (gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
+ ...
+ and:
+ ...
+ (gdb) set arch set to "auto" (currently "i386")^M
+ Undefined item: "set".^M
+ ...
+
+ Fix this in with_set by handling this type of output.
+
+ Tested on x86_64-linux.
+
+2022-11-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Set completions to unlimited in get_set_option_choices
+ In some test-case I tried to use get_set_option_choices "set architecture" and
+ ran into max-completions:
+ ...
+ set architecture simple^M
+ set architecture tomcat^M
+ set architecture xscale^M
+ set architecture *** List may be truncated, max-completions reached. ***^M
+ (gdb) PASS: gdb.base/foo.exp: complete set architecture
+ ...
+
+ There's only one test-case using this currently: gdb.base/parse_number.exp,
+ and it locally sets max-completions to unlimited.
+
+ Fix this by:
+ - factoring out a new proc with_set out of proc with_complaints, and
+ - using it to temporarily set max-completions to unlimited in
+ get_set_option_choice.
+
+ Tested on x86_64-linux, by running test-cases that excercise
+ get_set_option_choice and with_complaints.
+
+2022-11-14 Alan Modra <amodra@gmail.com>
+
+ Re: objcopy renaming section with explicit flags
+ For now, xfail the new test. Some header/aux-header rewriting is
+ required at the very least.
+
+ * testsuite/binutils-all/rename-section-01.d: xfail xcoff.
+
+2022-11-14 Alan Modra <amodra@gmail.com>
+
+ objcopy renaming section with explicit flags
+ This tidies SEC_RELOC handling in bfd, in the process fixing a bug
+ with objcopy when renaming sections.
+
+ bfd/
+ * reloc.c (_bfd_generic_set_reloc): Set/clear SEC_RELOC depending
+ on reloc count.
+ * elf64-sparc.c (elf64_sparc_set_reloc): Likewise.
+ binutils/
+ * objcopy.c (copy_relocations_in_section): Remove now unnecessary
+ clearing of SEC_RELOC.
+ * testsuite/binutils-all/rename-section-01.d: New test.
+ * testsuite/binutils-all/objcopy.exp: Run it.
+ gas/
+ * write.c (size_seg): Remove unneccesary twiddle of SEC_RELOC.
+ (write_relocs): Likewise. Always call bfd_set_reloc.
+
+2022-11-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-13 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Fix Cygwin build after 02d04eac
+ Commit 02d04eac "Use strwinerror in gdb/windows-nat.c" also moves
+ strwinerror() under the USE_WIN32API conditional, which is not defined
+ for Cygwin (and looks like it shouldn't be, as appears to imply
+ non-POSIX and MiNGW and WinSock...)
+
+ Also enable the declaration and definition of strwinerror() when
+ __CYGWIN__ is defined.
+
+2022-11-13 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Drop apparently unneeded include of winsock2.h
+ Commit d08bae3d ("Implement target async for Windows") unconditionally
+ includes winsock2.h. We don't want to do that on Cygwin, since
+ including both winsock2.h and sys/select.h causes incompatible
+ redefinition problems.
+
+ Since that include is apparently unneeded, just drop it.
+
+ Fixes: d08bae3d
+
+2022-11-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-12 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ sim: pru: Fix behaviour when loop count is zero
+ If the counter for LOOP instruction is provided by a register with
+ value zero, then the instruction must cause a PC jump directly to the
+ loop end. But in that particular case simulator must not initialize
+ its internal loop variables, because loop body will not be executed.
+ Instead, simulator must obtain the loop's end address directly from
+ the LOOP instruction.
+
+2022-11-12 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 paddi -Mraw
+ On a testcase like
+ pla 8,foo@pcrel
+ disassembled with -Mpower10 results in
+ 0: 00 00 10 06 pla r8,0 # 0
+ 4: 00 00 00 39
+ 0: R_PPC64_PCREL34 foo
+ but with -Mpower10 -Mraw
+ 0: 00 00 10 06 .long 0x6100000
+ 0: R_PPC64_PCREL34 foo
+ 4: 00 00 00 39 addi r8,0,0
+
+ The instruction is unrecognised due to the hack we have in
+ extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as
+ pla. I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the
+ condition in extract_pcrel0 under which *invalid is set, but went for
+ this larger patch that reorders the extended insn pla to the more
+ usual place before its underlying machine insn. (la is after addi
+ because we never disassemble to la.)
+
+ gas/
+ * testsuite/gas/ppc/raw.d,
+ * testsuite/gas/ppc/raw.s: Add pla.
+ opcodes/
+ * ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and
+ invert *invalid logic.
+ (PCREL1): Rename from PCREL0.
+ (prefix_opcodes): Sort pla before paddi, adjusting R operand
+ for pla, paddi and psubi.
+
+2022-11-12 Indu Bhagat <indu.bhagat@oracle.com>
+
+ libctf: use libtool for link test in configure
+ The configure check for ELF support in BFD uses the AC_TRY_LINK. If
+ libbfd's dependencies change, this macro will need to be updated
+ manually with explicit additions to LDFLAGS and LIBS.
+
+ This patch updates the check to use libtool instead.
+
+ ChangeLog:
+
+ * libctf/configure.ac: Use libtool instead.
+ * libctf/configure: Regenerated.
+
+2022-11-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix start breakpoint expression not working in some languages
+ Commit 0be837be9fb4 ("gdb: make "start" breakpoint inferior-specific")
+ regresses gdb.ada/start.exp:
+
+ (gdb) start
+ Error in expression, near `1'.
+ (gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right procedure
+
+ This is because in Ada, the equality operator is =, not ==.
+
+ I checked the other languages supported by GDB, these other languages
+ use = for equality:
+
+ - Pascal: tests like gdb.pascal/hello.exp are affected too
+ - Modula-2: I tried building a Modula-2 hello world using gm2, but it
+ seems like the generated DWARF doesn't specify the Modula-2 language
+ in the CUs, it's C++ and C, so the selected language isn't
+ "modula-2". But if I manually do "set language modula-2" on a dummy
+ program and then "start", I get the same error.
+
+ Other languages all use ==.
+
+ So, a short term fix would be to use = or == in the expression, based on
+ the current language. If this was meant to be permanent, I would
+ suggest adding something like an "equality_operator" method to
+ language_defn, that returns the right equality operator for the
+ language. But the goal is to replace all this with proper
+ inferior-specific breakpoints, so I hope all this is temporary.
+
+ Approved-By: Tom de Vries <tdevries@suse.de>
+ Change-Id: Id4d38e14a80e6bbbb1ad2b2277f974dd55192969
+
+2022-11-11 Mike Frysinger <vapier@gentoo.org>
+
+ sim: igen: cleanup archaic pointer-to-long printf casts
+ Use proper %p to printf a pointer instead of casting it to long and
+ using 0x%lx. It's cleaner, more correct, and doesn't break on LLP64.
+
+2022-11-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Don't timeout on prompt in gdb_start_cmd
+ We're currently running into a timeout at:
+ ...
+ (gdb) start ^M
+ Error in expression, near `1'.^M
+ (gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \
+ procedure
+ ...
+ due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to
+ the start command.
+
+ Fix this by handling the prompt. Reduces execution time of the test-case from
+ 1m1s to 1s.
+
+ Tested on x86_64-linux.
+
+2022-11-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Better error checking in has_hw_wp_support
+ With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support
+ usage, which was already fixed on trunk by commits:
+ - 13f72372413 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and
+ - 01a32ee0b8c ("PowerPC, fix gdb.base/watchpoint.exp on Power 9")
+
+ While looking into these ERRORs and the commits that fix them, it occurred to
+ me that while the commits fix the root cause, the failure mode is not great.
+
+ The test-cases expect a running instance of gdb upon return, which is not
+ there, so there's an long stream of ERRORs generated as a result.
+
+ Fix this at the start of has_hw_wp_support, by (instead of accomodating a
+ running gdb instance by calling gdb_exit), checking whether it's called
+ without a running gdb instance, and erroring out otherwise. This way, there's
+ just one error.
+
+ I also noticed that in case we do an early exit due to !runto_main, we don't
+ clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from
+ the regular exit.
+
+ Tested on x86_64-linux, using has_hw_wp_support for x86_64 in
+ skip_hw_watchpoint_tests.
+
+2022-11-11 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/py-inferior: Keep inferior threads in a map
+ The python code maintains a list of threads for each inferior. This
+ list is implemented as a linked list. When the number of threads grows
+ high, this implementation can begin to be a performance bottleneck as
+ finding a particular thread_object in the list has a complexity of O(N).
+
+ We see this in ROCgdb[1], a downstream port of GDB for AMDGUP. On
+ AMDGPU devices, the number of threads can get significantly higher than
+ on usual GDB workloads.
+
+ In some situations, we can reach the end of the inferior process with
+ GDB still having a substantial list of known threads. While running
+ target_mourn_inferior, we end up in inferior::clear_thread_list which
+ iterates over all remaining threads and marks each thread exited. This
+ fires the gdb::observers::thread_exit observer and eventually
+ py-inferior.c:set_thread_exited gets called. This function searches in
+ the linked list with poor performances.
+
+ This patch proposes to change the linked list that keeps the per
+ inferior_object list of thread_objects into a std::unordered_map. This
+ allows to have the search operation complexity be O(1) on average
+ instead of O(N).
+
+ With this patch, we can complete clear_thread_list in about 2.5 seconds
+ compared to 10 minutes without it.
+
+ Except for the performance change, no user visible change is expected.
+
+ Regression tested on Ubuntu-22.04 x86_64.
+
+ [1] https://github.com/ROCm-Developer-Tools/ROCgdb
+
+2022-11-11 Luis Machado <luis.machado@arm.com>
+
+ Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr
+ PR gdb/29272
+
+ Investigating PR29272, it was mentioned a particular test used to work on
+ GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
+ some displaced stepping improvements on commit
+ 187b041e2514827b9d86190ed2471c4c7a352874.
+
+ In particular, one of the corner cases using copy_insn_closure_by_addr got
+ silently broken. It is hard to spot because it doesn't have any good tests
+ for it, and the situation is quite specific to the Arm target.
+
+ Essentially, the change from the displaced stepping improvements made it so
+ we could still invoke copy_insn_closure_by_addr correctly to return the
+ pointer to a copy_insn_closure, but it always returned nullptr due to
+ the order of the statements in displaced_step_buffer::prepare.
+
+ The way it is now, we first write the address of the displaced step buffer
+ to PC and then save the copy_insn_closure pointer.
+
+ The problem is that writing to PC for the Arm target requires figuring
+ out if the new PC is thumb mode or not.
+
+ With no copy_insn_closure data, the logic to determine the thumb mode
+ during displaced stepping doesn't work, and gives random results that
+ are difficult to track (SIGILL, SIGSEGV etc).
+
+ Fix this by reordering the PC write in displaced_step_buffer::prepare
+ and, for safety, add an assertion to
+ displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
+ when it sees this invalid situation. If this gets broken again in the
+ future, it will be easier to spot.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-11 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, btrace: Fix rn-dl-bind.exp for new icx remark.
+ When running the test with the latest Intel compiler:
+
+ Running gdb/gdb/testsuite/gdb.btrace/rn-dl-bind.exp ...
+ gdb compile failed, icpx: warning: treating 'c' input as 'c++' when
+ in C++ mode, this behavior is deprecated [-Wdeprecated]
+
+ The test doesn't seem to test something specifically for C++,
+ so I removed the C++ compilation option. Alternatively we could rename
+ rn-dl-bind.exp.c to rn-dl-bind.exp.cc.
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: disable gdb.cp/call-method-register.exp when not using gcc
+ The test gdb.cp/call-method-register.exp assumes that the class will be
+ placed on a register. However, this keyword has been deprecated since
+ C++11, and Clang, for instance, does not feel the need to follow it.
+ Since this test is not usable without this working, this commit marks
+ this test as untested.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp
+ gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
+ for old gcc versions. However, Clang does not fail in this test,
+ turning into XPASSes and slighty annoying when comparing between
+ compilers. To change this, make the xfails only happen if we using gcc.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using Clang
+ Since Clang chooses to not add any debug information for base types,
+ expecting it to be included with libraries' informations, gdb.cp/typeid.exp
+ will always fail if the program hasn't started. This commit fixes that by
+ making it so when using Clang, the base type variables aren't tested.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang
+ When Clang compiles anonymous structures, it does not add linkage names in
+ their dwarf representations. This is compounded by Clang not adding linkage
+ names to subprograms of those anonymous structs (for instance, the
+ constructor). With these 2 things together, GDB is unable to refer to
+ any of them, so there is no way to pass any of the tests of
+ gdb.cp/anon-struct.exp
+
+ Since this isn't a bug on Clang or GDB according to the DWARF
+ specifications as DW_AT_name is optional for all DIEs, the test was marked
+ as untested.
+
+ Since I was already touching the file, I also added a comment at the top
+ of the file explaining what it is testing for.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: allow for Clang style destructors on gdb.cp/m-static.exp
+ when running gdb.cp/m-static.exp using Clang, we get the following
+ failures:
+
+ print test1.~gnu_obj_1^M
+ $6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
+ (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
+ ptype test1.~gnu_obj_1^M
+ type = void (gnu_obj_1 * const)^M
+ (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor
+ print test1.'~gnu_obj_1'^M
+ $7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
+ (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor
+
+ This is because the test is expecting an extra integer parameter on the
+ destructor. Looking at the debuginfo, it seems that there is nothing
+ actually wrong with this output, so these tests were changed to test
+ multiple possible regexps.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang
+ When running gdb.cp/derivation.exp using Clang, we get an unexpected
+ failure when printing the type of a class with an internal typedef. This
+ happens because Clang doesn't add accessibility information for typedefs
+ inside classes (see https://github.com/llvm/llvm-project/issues/57608
+ for more info). To help with Clang testing, an XFAIL was added to this
+ test.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: account for clang's nested destructor calls on gdb.cp/mb-ctor.exp
+ When compiling virtual classes's destructors, two versions are compiled,
+ one with a single parameter (this) and the other with 2 parameters (this
+ and vtt).
+
+ GCC's compilation makes it so either the version with 1
+ parameter or the one with 2 parameters is called, depending on whether
+ the destructor is being called by the class itself or by an inherited
+ class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint
+ set at the destructor will be hit 4 times.
+
+ Clang, on the other hand, makes the single-parameter version call the 2
+ parameter version, probably in an attempt to reduce the size of the
+ resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6
+ breakpoints before finishing, and is the reason why this test was
+ failing. To make this test stop failing, a compiler check is added and
+ another "continue" instruction is issued to account for this difference.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: enable running gdb.cp/classes.exp with clang
+ When attempting to run the gdb.cp/classes.exp test using Clang++, the
+ test fails to prepare with -Wnon-c-typedef-for-linkage like the
+ previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5
+ unexpected failures. One such failures is:
+
+ ptype/r class class_with_public_typedef
+ type = class class_with_public_typedef {
+ private:
+ int a;
+ public:
+ class_with_public_typedef::INT b;
+
+ private:
+ typedef int INT;
+ }
+ (gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private
+
+ While g++ provided the following output:
+
+ ptype/r class class_with_public_typedef
+ type = class class_with_public_typedef {
+ private:
+ int a;
+ public:
+ class_with_public_typedef::INT b;
+
+ typedef int INT;
+ }
+ (gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef
+
+ This error happens because Clang does not add DW_AT_accessibility to
+ typedefs inside classes, and without this information GDB defaults to
+ assuming the typedef is private. Since there is nothing that GDB can do
+ about this, these tests have been set as xfails, and Clang bug 57608 has
+ been filed.
+
+ Bug: https://github.com/llvm/llvm-project/issues/57608
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp
+ When attempting to test gdb.cp/class2.exp using Clang, it fails to
+ prepare with the following error:
+
+ Executing on host: clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc (timeout = 300)
+ builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc
+ /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
+ typedef class {
+ ^
+ Dbase
+ /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
+ public:
+ ^~~~~~~
+ /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
+ } Dbase;
+ ^
+ 1 warning generated.
+ gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
+ typedef class {
+ ^
+ Dbase
+ /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
+ public:
+ ^~~~~~~
+ /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
+ } Dbase;
+ ^
+ 1 warning generated.
+ UNTESTED: gdb.cp/class2.exp: failed to prepare
+
+ This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang
+ 11 or later. The test shows no failures with this change.
+
+ Approved-by: Tom Tromey <tom@tromey.com>
+
+2022-11-11 Jan Beulich <jbeulich@suse.com>
+
+ gas: accept custom ".linefile <n> ."
+ While .linefile is generally intended for gas internal use only, its use
+ in a source file would better not result in an internal error. Give use
+ of it outside of any macro(-like) construct the meaning of restoring the
+ original (physical) input file name.
+
+ x86: drop stray IsString from PadLock insns
+ The need for IsString on the PadLock insns went away with the
+ introduction of RepPrefixOk. Drop these leftovers.
+
+ x86: drop duplicate sse4a entry from cpu_arch[]
+ Of the two instances the first is correct in using ANY_SSE4A as 3rd
+ argument to SUBARCH(), so drop the wrong/redundant/dead 2nd one.
+
+2022-11-11 Alan Modra <amodra@gmail.com>
+
+ PR28834, PR26946 sanity checking section size
+ This patch provides a new function to sanity check section sizes.
+ It's mostly extracted from what we had in bfd_get_full_section_contents
+ but also handles compressed debug sections.
+ Improvements are:
+ - section file offset is taken into account,
+ - added checks that a compressed section can be read from file.
+
+ The function is then used when handling multiple .debug_* sections
+ that need to be read into a single buffer, to sanity check sizes
+ before allocating the buffer.
+
+ PR 26946, PR 28834
+ * Makefile.am (LIBBFD_H_FILES): Add section.c.
+ * compress.c (bfd_get_full_section_contents): Move section size
+ sanity checks..
+ * section.c (_bfd_section_size_insane): ..to here. New function.
+ * dwarf2.c (read_section): Use _bfd_section_size_insane.
+ (_bfd_dwarf2_slurp_debug_info): Likewise.
+ * Makefile.in: Regenerate.
+ * libbfd.h: Regenerate.
+
+2022-11-11 Alan Modra <amodra@gmail.com>
+
+ Sanity check SHT_MIPS_OPTIONS size
+ * elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Use
+ bfd_malloc_and_get_section to read contents of .MIPS.options.
+
+ Re: gold: add --compress-debug-sections=zstd [PR 29641]
+ Fix the following:
+ compressed_output.cc:86:8: error: assignment of read-only variable ‘size’
+ 86 | size = ZSTD_compress(*compressed_data + header_size, size, uncompressed_data,
+
+2022-11-11 Fangrui Song <maskray@google.com>
+
+ gold: add --compress-debug-sections=zstd [PR 29641]
+ This option compresses output debug sections with zstd and sets ch_type
+ to ELFCOMPRESS_ZSTD. Latest gdb and lldb support ELFCOMPRESS_ZSTD.
+
+ There will be an error if zstd is not enabled at configure time.
+
+ error: --compress-debug-sections=zstd: gold is not built with zstd support
+
+2022-11-11 Fangrui Song <maskray@google.com>
+
+ gold, dwp: support zstd compressed input debug sections [PR 29641]
+ This feature is enabled if config/zstd.m4 uses zstd.
+
+2022-11-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix typo in configure.ac
+ gprofng/ChangeLog
+ 2022-11-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * configure.ac: Fix typo in redirect operator.
+ * configure: Rebuild.
+
+2022-11-11 Vladislav Khmelevsky <och95@yandex.ru>
+
+ Fix adrp distance check
+ gold/
+ * aarch64.cc (aarch64_valid_for_adrp_p): Shift offset
+ as a signed number.
+
+2022-11-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: rename v850.dc to align with other ports
+ Other arches use the .dc extension for the instruction decode table.
+
+ sim: igen: fix hang when decoding boolean rule constants
+ The parser for boolean rules fails to skip over the , separator in
+ the options which makes it hang forever. No dc files in the tree
+ use boolean rules atm which is why no one noticed.
+
+ sim: igen: mark error func as noreturn since it exits
+
+ sim: igen: mark output funcs with printf attribute
+ ... and fix the legitimate bug that it catches.
+
+ sim: igen: constify various func arguments
+
+ sim: ppc: rename ppc-instructions to powerpc.igen
+ To make it clear this is an input to the igen tool, rename it with an
+ igen extension. This matches the other files in the ppc dir (altivec
+ & e500 igen files), and the other igen ports (mips, mn10300, v850).
+
+2022-11-10 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Check invalid (%dx) usage
+ (%dx) isn't a valid memory address in any modes. It is used as a special
+ memory operand for input/output port address in AT&T syntax and should
+ only be used with input/output instructions. Update i386_att_operand to
+ set i.input_output_operand to true for (%dx) and issue an error if (%dx)
+ is used with non-input/output instructions.
+
+ PR gas/29751
+ * config/tc-i386.c (_i386_insn): Add input_output_operand.
+ (md_assemble): Issue an error if input/output memory operand is
+ used with non-input/output instructions.
+ (i386_att_operand): Set i.input_output_operand to true for
+ (%dx).
+ * testsuite/gas/i386/inval.l: Updated.
+ * testsuite/gas/i386/x86-64-inval.l: Likewise.
+ * testsuite/gas/i386/inval.s: Add tests for invalid (%dx) usage.
+ * testsuite/gas/i386/x86-64-inval.s: Likewise.
+
+2022-11-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make "start" breakpoint inferior-specific
+ I saw this failure on a CI:
+
+ (gdb) add-inferior
+ [New inferior 2]
+ Added inferior 2
+ (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior
+ inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2
+ kill
+ The program is not being run.
+ (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
+ Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep...
+ (gdb) run &
+ Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
+ (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2
+ inferior 1
+ [Switching to inferior 1 [<null>] (<noexec>)]
+ (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1
+ kill
+ The program is not being run.
+ (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
+ Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior...
+ (gdb) break should_break_here
+ Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25.
+ (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+ start
+ Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations)
+ Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23
+ 23 sleep (30);
+ (gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1
+
+ What happens is:
+
+ 1. We start inferior 2 with "run&", it runs very slowly, takes time to
+ get to main
+ 2. We switch to inferior 1, and run "start"
+ 3. The temporary breakpoint inserted by "start" applies to all inferiors
+ 4. Inferior 2 hits that breakpoint and GDB reports that hit
+
+ To avoid this, breakpoints inserted by "start" should be
+ inferior-specific. However, we don't have a nice way to make
+ inferior-specific breakpoints yet. It's possible to make
+ pspace-specific breakpoints (for example how the internal_breakpoint
+ constructor does) by creating a symtab_and_line manually. However,
+ inferiors can share program spaces (usually on particular embedded
+ targets), so we could have a situation where two inferiors run the same
+ code in the same program space. In that case, it would just not be
+ possible to insert a breakpoint in one inferior but not the other.
+
+ A simple solution that should work all the time is to add a condition to
+ the breakpoint inserted by "start", to check the inferior reporting the
+ hit is the expected one. This is what this patch implements.
+
+ Add a test that does:
+
+ - start in background inferior 1 that sleeps before reaching its main
+ function (using a sleep in a global C++ object's constructor)
+ - start inferior 2 with the "start" command, which also sleeps before
+ reaching its main function
+ - validate that we hit the breakpoint in inferior 2
+
+ Without the fix, we hit the breakpoint in inferior 1 pretty much all the
+ time. There could be some unfortunate scheduling causing the test not
+ to catch the bug, for instance if the scheduler decides not to schedule
+ inferior 1 for a long time, but it would be really rare. If the bug is
+ re-introduced, the test will catch it much more often than not, so it
+ will be noticed.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-By: Pedro Alves <pedro@palves.net>
+ Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a
+
+2022-11-10 Bruno Larsen <blarsen@redhat.com>
+
+ gdb: Fix regressions caused by 041de3d73aa121f2ff0c077213598963bfb34b79
+ Commit 041de3d73aa changed the output format of all error messages when
+ GDB couldn't determine a compatible overload for a given function, but
+ it was only supposed to change if the failure happened due to incomplete
+ types. This commit removes the stray . that was added
+
+2022-11-10 Aaron Merey <amerey@redhat.com>
+
+ gdb/debuginfod: Improve progress updates
+ If the download size is known, a progress bar is displayed along with
+ the percentage of completion and the total download size.
+
+ Downloading separate debug info for /lib/libxyz.so
+ [############ ] 25% (10.01 M)
+
+ If the download size is not known, a progress indicator is displayed
+ with a ticker ("###") that moves across the screen at a rate of 1 tick
+ every 0.5 seconds.
+
+ Downloading separate debug info for /lib/libxyz.so
+ [ ### ]
+
+ If the output stream is not a tty, batch mode is enabled, the screen is
+ too narrow or width has been set to 'unlimited', then only a static
+ description of the download is printed. No bar or ticker is displayed.
+
+ Downloading separate debug info for /lib/libxyz.so...
+
+ In any case, if the size of the download is known at the time the
+ description is printed then it will be included in the description.
+
+ Downloading 10.01 MB separate debug info for /lib/libxyz.so...
+
+2022-11-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add special handling for frame level 0 in frame_info_ptr
+ I noticed this problem while preparing the initial submission for the
+ ROCm GDB port. One particularity of this patch set is that it does not
+ support unwinding frames, that requires support of some DWARF extensions
+ that will come later. It was still possible to run to a breakpoint and
+ print frame #0, though.
+
+ When rebasing on top of the frame_info_ptr work, GDB started tripping on
+ a prepare_reinflate call, making it not possible anymore to event print
+ the frame when stopping on a breakpoint. One thing to know about frame
+ 0 is that its id is lazily computed when something requests it through
+ get_frame_id. See:
+
+ https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L2070-2080
+
+ So, up to that prepare_reinflate call, frame 0's id was not computed,
+ and prepare_reinflate, calling get_frame_id, forces it to be computed.
+ Computing the frame id generally requires unwinding the previous frame,
+ which with my ROCm GDB patch fails. An exception is thrown and the
+ printing of the frame is simply abandonned.
+
+ Regardless of this ROCm GDB problem (which is admittedly temporary, it
+ will be possible to unwind with subsequent patches), we want to avoid
+ prepare_reinflate to force the computing of the frame id, for the same
+ reasons we lazily compute it in the first place.
+
+ In addition, frame 0's id is subject to change across a frame cache
+ reset. This is why save_selected_frame and restore_selected_frame have
+ special handling for frame 0:
+
+ https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L1841-1863
+
+ For this last reason, we also need to handle frame 0 specially in
+ prepare_reinflate / reinflate. Because the frame id of frame 0 can
+ change across a frame cache reset, we must not rely on the frame id from
+ that frame to reinflate it. We should instead just re-fetch the current
+ frame at that point.
+
+ This patch adds a frame_info_ptr::m_cached_level field, set in
+ frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0.
+ There are cases where a frame_info_ptr object wraps a sentinel frame,
+ for which frame_relative_level returns -1, so I have chosen the value -2
+ to represent "invalid frame level", for when the frame_info_ptr object
+ is empty.
+
+ In frame_info_ptr::prepare_reinflate, only cache the frame id if the
+ frame level is not 0. It's fine to cache the frame id for the sentinel
+ frame, it will be properly handled by frame_find_by_id later.
+
+ In frame_info_ptr::reinflate, if the frame level is 0, call
+ get_current_frame to get the target's current frame. Otherwise, use
+ frame_find_by_id just as before.
+
+ This patch should not have user-visible changes with upstream GDB. But
+ it will avoid forcing the computation of frame 0's when calling
+ prepare_reinflate. And, well, it fixes the upcoming ROCm GDB patch
+ series.
+
+ Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-11-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add missing prepare_reinflate call in print_frame_info
+ print_frame_info calls frame_info_ptr::reinflate, but not
+ frame_info_ptr::prepare_reinflate, add the call to prepare_reinflate.
+ It works right now, because all callers of print_frame_info that could
+ possibly lead to the pretty printers being called, and the frame_info
+ objects being invalidated, do call prepare_reinflate themselves. And
+ since the cached frame id is copied when passing a frame_info_ptr by
+ value, print_frame_info does have a cached frame id on entry. So
+ technically, this change isn't needed. But I don't think it's good for
+ a function to rely on its callers to have called prepare_reinflate, if
+ it intends to call reinflate.
+
+ Change-Id: Ie332b2d5479aef46f83fdc1120c7c83f4e84d1b0
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-11-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use frame_id_p instead of comparing to null_frame_id in frame_info_ptr::reinflate
+ The assertion
+
+ gdb_assert (m_cached_id != null_frame_id);
+
+ is always true, as comparing equal to null_frame_id is always false
+ (it's the first case in frame_id::operator==, not sure why it's not this
+ way, but that's what it is).
+
+ Replace the comparison with a call to frame_id_p.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb
+
+2022-11-10 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove manual frame_info reinflation code in backtrace_command_1
+ With the following patch applied (gdb: use frame_id_p instead of
+ comparing to null_frame_id in frame_info_ptr::reinflate), I would get:
+
+ $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full"
+ Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame...
+ Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22.
+ Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
+ 22 }
+ #0 breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
+ No locals.
+ /home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed.
+
+ This is because the code in backtrace_command_1 to manually reinflate
+ `fi` steps overs frame_info_ptr's toes.
+
+ When calling
+
+ fi.prepare_reinflate ();
+
+ `fi` gets properly filled with the cached frame id. But when this
+ happens:
+
+ fi = frame_find_by_id (frame_id);
+
+ `fi` gets replaced by a brand new frame_info_ptr that doesn't have a
+ cached frame id. Then this is called without a cached frame id:
+
+ fi.reinflate ();
+
+ That doesn't cause any problem currently, since
+
+ - the gdb_assert in the reinflate method doesn't actually do anything
+ (the following patch fixes that)
+ - `fi.m_ptr` will always be non-nullptr, since we just got it from
+ frame_find_by_id, so reinflate will not do anything, it won't try to
+ use m_cached_id
+
+ Fix that by removing the code to manually re-fetch the frame. That
+ should be taken care of by frame_info_ptr::reinflate.
+
+ Note that the old code checked if we successfully re-inflated the frame
+ or not, and if not it did emit a warning. The equivalent in
+ frame_info_ptr::reinflate asserts that the frame has been successfully
+ re-inflated. It's not clear if / when this can happen, but if it can
+ happen, we'll need to find a solution to this problem globally
+ (everywhere a frame_info_ptr can be re-inflated), not just here. So I
+ propose to leave it like this, until it does become a problem.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Change-Id: I07b783d94e2853e0a2d058fe7deaf04eddf24835
+
+2022-11-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: move frame_info_ptr method implementations to frame-info.c
+ I don't see any particular reason why the implementations of the
+ frame_info_ptr object are in the header file. It only seems to add some
+ complexity. Since we can't include frame.h in frame-info.h, we have to
+ add declarations of functions defined in frame.c, in frame-info.h. By
+ moving the implementations to a new frame-info.c, we can avoid that.
+
+ Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Reviewed-By: Tom Tromey <tom@tromey.com>
+
+2022-11-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add prepare_reinflate/reinflate around print_frame_args in info_frame_command_core
+ I noticed this crash:
+
+ $ ./gdb --data-directory=data-directory -nx -q \
+ testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \
+ -x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \
+ -ex "b g" -ex r
+ (gdb) info frame
+ Stack level 0, frame at 0x7fffffffdd80:
+ rip = 0x555555555160 in g
+ (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3
+ called by frame at 0x7fffffffdda0
+ source language c.
+ Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world",
+ depth=10
+
+ Fatal signal: Segmentation fault
+
+ This is another case of frame_info being invalidated under a function's
+ feet. The stack trace when the frame_info get invalidated looks like:
+
+ ... many frames to pretty print the arg, that eventually invalidate the frame_infos ...
+ #35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489
+ #36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300)
+ at /home/simark/src/binutils-gdb/gdb/stack.c:898
+ #37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682
+
+ print_frame_args knows that print_frame_arg can invalidate frame_info
+ objects, and therefore calls prepare_reinflate/reinflate. However,
+ info_frame_command_core has a separate frame_info_ptr instance (it is
+ passed by value / copy). So info_frame_command_core needs to know that
+ print_frame_args can invalidate frame_info objects, and therefore needs
+ to prepare_reinflate/reinflate as well. Add those calls, and enhance
+ the gdb.python/pretty-print-call-by-hand.exp test to test that command.
+
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Change-Id: I9edaae06d62e97ffdb30938d364437737238a960
+
+2022-11-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: clear other.m_cached_id in frame_info_ptr's move ctor
+ We do it in the move assignment operator, so I think it makes sense to
+ do it here too for consistency. I don't think it's absolutely necessary
+ to clear the other object's fields (in other words, copy constructor and
+ move constructor could be the same), as there is no exclusive resource
+ being transfered. The important thing is to leave the moved-from object
+ in an unknown, but valid state. But still, I think that clearing the
+ fields of the moved-from object is not a bad idea, it helps ensure we
+ don't rely on the moved-from object after.
+
+ Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-11-10 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/c++: Improve error messages in overload resolution
+ When resolving overloaded functions, GDB relies on knowing relationships
+ between types, i.e. if a type inherits from another. However, some
+ compilers may not add complete information for given types as a way to
+ reduce unnecessary debug information. In these cases, GDB would just say
+ that it couldn't resolve the method or function, with no extra
+ information.
+
+ The problem is that sometimes the user may not know that the type
+ information is incomplete, and may just assume that there is a bug in
+ GDB. To improve the user experience, we attempt to detect if the
+ overload match failed because of an incomplete type, and warn the user
+ of this.
+
+ This commit also adds a testcase confirming that the message is only
+ triggered in the correct scenario. This test was not developed as an
+ expansion of gdb.cp/overload.cc because it needed the dwarf assembler,
+ and porting all of overload.cc seemed unnecessary.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-11-10 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: allowed for function_range to deal with mangled functions
+ When calling get_func_info inside a test case, it would cause failures
+ if the function was printed using a C++ style mangled name. The current
+ patch fixes this by allowing for mangled names along with the current
+ rules.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-11-10 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: skip ld-size when -shared is not supported
+ ld/ChangeLog:
+
+ * testsuite/ld-size/size.exp: Skip when -shared is not
+ supported.
+
+2022-11-10 Alan Modra <amodra@gmail.com>
+
+ mach-o reloc size overflow
+ * mach-o.c (bfd_mach_o_canonicalize_reloc): Set bfd_error on
+ multiply overflow.
+
+2022-11-10 Alan Modra <amodra@gmail.com>
+
+ Sanity check reloc count in get_reloc_upper_bound
+ The idea here is the stop tools from allocating up to 32G per section
+ for the arelent pointer array, only to find a little later that the
+ section reloc count was fuzzed. This usually doesn't hurt much (on
+ systems that allow malloc overcommit) except when compiled with asan.
+
+ We already do this for ELF targets, and while fixing the logic
+ recently I decided other targets ought to do the same.
+
+ * elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Sanity check
+ section reloc count against file size.
+ * mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
+ * aoutx.h (get_reloc_upper_bound): Likewise, and don't duplicate
+ check done in bfd_get_reloc_upper_bound.
+ * pdp11.c (get_reloc_upper_bound): Likewise.
+ * coffgen.c (coff_get_reloc_upper_bound): Likewise.
+
+2022-11-10 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: Fix rtld-step-nodebugsym.exp
+ The test case introduced in bafcc335266 (Fix stepping in rtld without
+ debug symbol) fails on some systems as reported by PR/29768. This can
+ be seen if the system does not have debug info for the libc:
+
+ (gdb) step^M
+ Single stepping until exit from function main,^M
+ which has no line number information.^M
+ hello world[Inferior 1 (process 48203) exited normally]^M
+ (gdb) PASS: gdb.base/rtld-step-nodebugsym.exp: step
+ continue^M
+ The program is not being run.^M
+ (gdb) FAIL: gdb.base/rtld-step-nodebugsym.exp: continue until exit (the program is no longer running)
+
+ Without glibc debug info, GDB steps until the program finishes, and
+ then "gdb_continue_to_end" fails.
+
+ As this test was designed to check that GDB does not crash in the "step"
+ command, the continue does not carry real meaning to the test.
+
+ Replace it by "print 0" so we still check that after the step command
+ GDB is still alive, which is what we care about.
+
+ Tested on Ubuntu-22.04 x86_64, with and without libc6-dbg.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29768
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: drop old makefile fragment
+ Support for these files was dropped almost 30 years ago, but the ppc
+ arch was missed. Clean that up now too.
+
+ sim: ppc: drop support for dgen -L option
+ Nothing passes this to dgen, and even if it did, nothing would happen
+ because the generated spreg.[ch] files don't include any references
+ back to the original data table. So drop it to simplify.
+
+ sim: ppc: collapse is_readonly & length switch tables heavily
+ Since we know we'll return 0 by default, we don't have to output case
+ statements for readonly or length fields whose values are also zero.
+ This is the most common case by far and thus generates a much smaller
+ switch table in the end.
+
+2022-11-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: collapse is_valid switch table more
+ Instead of writing:
+ case 1:
+ return 1;
+ case 2:
+ return 1;
+ ...etc...
+
+ Output a single return so we get:
+ case 1:
+ case 2:
+ case ...
+ return 1;
+
+ This saves ~100 lines of code. Hopefully the compiler was already
+ smart enough to optimize to the same code, but if not, this probably
+ helps there too :).
+
+2022-11-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: pull default switch return out
+ This saves a single line for the same result. By itself, it's not
+ interesting, but we can further optimize the generated output and
+ completely omit the switch table in some cases. Which we'll do in
+ follow up commits.
+
+ sim: ppc: constify spreg table
+ This internal table is only ever read, so constify it.
+
+2022-11-10 Mark Harmstone <mark@harmstone.com>
+
+ ld: Add module information substream to PDB files
+
+2022-11-10 Luis Machado <luis.machado@arm.com>
+
+ [opcodes/arm] Fix potential null pointer dereferences
+ PR tdep/29598
+
+ As pointed out in the bug ticket, we have a couple potential null pointer
+ dereferencing situations. Harden those.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29598
+
+2022-11-10 Luis Machado <luis.machado@arm.com>
+
+ [gdb/aarch64] Use safer memory read routines
+ PR tdep/28796
+
+ As reported, we are using some memory read routines that don't handle read
+ errors gracefully. Convert those to use the safe_* versions if available.
+
+ This allows the code to handle those read errors in a more sensible way.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28796
+
+2022-11-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-09 Lancelot SIX <lancelot.six@amd.com>
+
+ Fix stepping in rtld without debug symbol
+ Commit be6276e0aed "Allow debugging of runtime loader / dynamic linker"
+ introduced a small regression when stepping into the runtime loader /
+ dynamic linker from function we do not have debug information for. This
+ is reported in PR/29747.
+
+ This can be shown by the following example (given by Simon Marchi in
+ buzilla bug report):
+
+ $ cat test.c
+ #include <stdio.h>
+
+ int main()
+ {
+ printf("Hi\n");
+ return 0;
+ }
+ $ gcc test.c -O0 -o test
+ $ ./gdb -q -nx --data-directory=data-directory test -ex start -ex s
+ Reading symbols from test...
+ (No debugging symbols found in test)
+ Temporary breakpoint 1 at 0x1151
+ Starting program: .../binutils-gdb/gdb/test
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ Temporary breakpoint 1, 0x0000555555555151 in main ()
+ Single stepping until exit from function main,
+ which has no line number information.
+ /home/smarchi/src/binutils-gdb/gdb/infrun.c:6960:64: runtime error: member call on null pointer of type 'struct symbol'
+
+ The crash happens here:
+
+ #0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
+ #1 0x00007ffff5dd7128 in __ubsan::__ubsan_handle_type_mismatch_v1_abort (Data=<optimized out>, Pointer=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:148
+ #2 0x000055556183e1a7 in process_event_stop_test (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6960
+ #3 0x0000555561838ea4 in handle_signal_stop (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6615
+ #4 0x000055556182f77b in handle_inferior_event (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:5866
+
+ When evaluating:
+
+ 6956 if (execution_direction != EXEC_REVERSE
+ 6957 && ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
+ 6958 && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ())
+ 6959 && !in_solib_dynsym_resolve_code (
+ 6961 ecs->event_thread->control.step_start_function->value_block ()
+ 6962 ->entry_pc ()))
+
+ we dereference, ecs->event_thread->control.step_start_function which is
+ nullptr.
+
+ This patch changes this condition so it evaluates to true if
+ ecs->event_thread->control.step_start_function is nullptr since this
+ matches the behaviour before be6276e0aed.
+
+ Tested on ubuntu-22.04 x86_64.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29747
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-By: Kevin Buettner <kevinb@redhat.com>
+
+2022-11-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: igen: add missing newline to various error messages
+ The error() function expects a trailing newline in its message.
+ Most callers do this already, so adding it to the few that don't.
+
+ sim: restore lstat & mkdir func checks
+ When merging ppc configure checks into the top-level, these 2 funcs
+ were accidentally dropped (probably due to incorrect resolution of
+ conflicts). Restore them since the ppc code utilizes them both.
+
+ sim: ppc: drop obsolete USE_WIN32API check
+ This controls only one thing: how to call mkdir(). The gnulib code
+ already has a mkdir module that provides this exact logic for us, so
+ punt the code entirely.
+
+2022-11-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbserver: do not report btrace support if target does not announce it
+ Gdbserver unconditionally reports support for btrace packets. Do not
+ report the support, if the underlying target does not say it supports
+ it. Otherwise GDB would query the server with btrace-related packets
+ unnecessarily.
+
+2022-11-09 Tom Tromey <tromey@adacore.com>
+
+ Allow 'ptype/o' for assembly
+ PR exp/28359 points out that 'ptype/o' does not work when the current
+ language is "asm".
+
+ I tracked this down to a hard-coded list of languages in typeprint.c.
+ This patch replaces this list with a method on 'language_defn'
+ instead. If all languages are ever updated to have this feature, the
+ method could be removed; but in the meantime this lets each language
+ control what happens.
+
+ I looked at having each print_type method simply modify the flags
+ itself, but this doesn't work very well with the feature that disables
+ method-printing by default (but allows it via a flag).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+ Approved-By: Keith Seitz <keiths@redhat.com>
+
+2022-11-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: add missing parens with e500 macro
+ This macro expansion was missing a set of outer-most parenthesis which
+ some compilers would complain about depending on how the macro is used.
+ This is just standard good macro hygiene too.
+
+ sim: ppc: drop useless linking of helper tools
+ We've never run these helper programs directly. The igen program
+ includes the relevant source files directly and runs the code that
+ way. So stop wasting developer CPU time linking programs that are
+ never run. We leave the rules in place for people who need to test
+ and debug the specific bits of code every now & then.
+
+2022-11-09 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: don't accept malformed EXTRQ / INSERTQ
+ Operand swapping was mistakenly suppressed when the first two operands
+ were immediate ones, not taking into account overall operand count. This
+ way EXTRQ / INSERTQ would have been accepted also with kind-of-AT&T
+ operand order.
+
+ For the testcase being extended, in order to not move around "GAS
+ LISTING" expectations, suppress pagination.
+
+2022-11-09 Alan Modra <amodra@gmail.com>
+
+ Re: Fuzzed files in archives
+ Like commit ffbe89531c2e this avoids more silliness writing output
+ that is going to be deleted. bfd_close and bfd_close_all_done differ
+ in that only the former calls _bfd_write_contents.
+
+ * objcopy.c (copy_archive): Don't call bfd_close for elements
+ that are going to be deleted, call bfd_close_all_done instead.
+ Do the same for the archive itself.
+
+2022-11-09 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: xtheadfmemidx: Use fp register in mnemonics
+ Although the encoding for scalar and fp registers is identical,
+ we should follow common pratice and use fp register names
+ when referencing fp registers.
+
+ The xtheadmemidx extension consists of indirect load/store instructions
+ which all load to or store from fp registers.
+ Let's use fp register names in this case and adjust the test cases
+ accordingly.
+
+ gas/
+ * testsuite/gas/riscv/x-thead-fmemidx-fail.l: Updated since rd need to
+ be float register.
+ * testsuite/gas/riscv/x-thead-fmemidx-fail.s: Likewise.
+ * testsuite/gas/riscv/x-thead-fmemidx.d: Likewise.
+ * testsuite/gas/riscv/x-thead-fmemidx.s: Likewise.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Updated since rd need to be float register.
+
+2022-11-09 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Always output local symbol for relocatable link
+ PR ld/29761
+ * elflink.c (elf_link_output_symstrtab): Don't skip local symbol
+ in SEC_EXCLUDE section for relocatable link.
+
+2022-11-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/linux-nat: get core count using /sys/devices/system/cpu/possible
+ I get this test failure on my CI;
+
+ FAIL: gdb.base/info-os.exp: get process list
+
+ The particularity of this setup is that builds are done in containers
+ who are allocated 4 CPUs on a machine that has 40. The code in
+ nat/linux-osdata.c fails to properly fetch the core number for each
+ task.
+
+ linux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which
+ returns 4, so it allocates an array of 4 integers. However, the core
+ numbers read from /proc/pid/task/tid/stat, by function
+ linux_common_core_of_thread, returns a value anywhere between 0 and 39.
+ The core numbers above 3 are therefore ignored, many processes end up
+ with no core value, and the regexp in the test doesn't match (it
+ requires an integer as the core field).
+
+ The way this the CPUs are exposed to the container is that the container
+ sees 40 CPUs "present" and "possible", but only 4 arbitrary CPUs
+ actually online:
+
+ root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present
+ 0-39
+ root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online
+ 5,11,24,31
+ root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible
+ 0-39
+
+ The solution proposed in this patch is to find out the number of
+ possible CPUs using /sys/devices/system/cpu/possible. In practice, this
+ will probably always contain `0-N`, where N is the number of CPUs, minus
+ one. But the documentation [1] doesn't such guarantee, so I'll assume
+ that it can contain a more complex range list such as `2,4-31,32-63`,
+ like the other files in that directory can have. The solution is to
+ iterate over these numbers to find the highest possible CPU id, and
+ use that that value plus one as the size of the array to allocate.
+
+ [1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst
+
+ Change-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3
+
+2022-11-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport, gdb: add read_text_file_to_string, use it in linux_common_core_of_thread
+ I would like to add more code to nat/linux-osdata.c that reads an entire
+ file from /proc or /sys and processes it as a string afterwards. I
+ would like to avoid duplicating the somewhat error-prone code that reads
+ an entire file to a buffer. I think we should have a utility function
+ that does that.
+
+ Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make
+ linux_common_core_of_thread use it. I want to make the new function
+ return an std::string, and because strtok doesn't play well with
+ std::string (it requires a `char *`, std::string::c_str returns a `const
+ char *`), change linux_common_core_of_thread to use std::string methods
+ instead.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a
+
+2022-11-08 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Add XSP operand define
+ opcodes/
+ * ppc-opc.c (XSP): New define.
+ (powerpc_opcodes) <stxvp, stxvpx, pstxvp>: Use it.
+
+2022-11-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Make quit really quit after remote connection closed
+ Consider a hello world a.out, started using gdbserver:
+ ...
+ $ gdbserver --once 127.0.0.1:2345 ./a.out
+ Process ./a.out created; pid = 15743
+ Listening on port 2345
+ ...
+ that we can connect to using gdb:
+ ...
+ $ gdb -ex "target remote 127.0.0.1:2345"
+ Remote debugging using 127.0.0.1:2345
+ Reading /home/vries/a.out from remote target...
+ ...
+ 0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2
+ (gdb)
+ ...
+
+ After that, we can for instance quit with confirmation:
+ ...
+ (gdb) quit
+ A debugging session is active.
+
+ Inferior 1 [process 16691] will be killed.
+
+ Quit anyway? (y or n) y
+ $
+ ...
+
+ Or, kill with confirmation and quit:
+ ...
+ (gdb) kill
+ Kill the program being debugged? (y or n) y
+ [Inferior 1 (process 16829) killed]
+ (gdb) quit
+ $
+ ...
+
+ Or, monitor exit, kill with confirmation, and quit:
+ ...
+ (gdb) monitor exit
+ (gdb) kill
+ Kill the program being debugged? (y or n) y
+ Remote connection closed
+ (gdb) quit
+ $
+ ...
+
+ But when doing monitor exit followed by quit with confirmation, we get the gdb
+ prompt back, requiring us to do quit once more:
+ ...
+ (gdb) monitor exit
+ (gdb) quit
+ A debugging session is active.
+
+ Inferior 1 [process 16944] will be killed.
+
+ Quit anyway? (y or n) y
+ Remote connection closed
+ (gdb) quit
+ $
+ ...
+
+ So, the first quit didn't quit. This happens as follows:
+ - quit_command calls query_if_trace_running
+ - a TARGET_CLOSE_ERROR is thrown
+ - it's caught in remote_target::get_trace_status, but then
+ rethrown because it's TARGET_CLOSE_ERROR
+ - catch_command_errors catches the error, at which point the quit command
+ has been aborted.
+
+ The TARGET_CLOSE_ERROR is defined as:
+ ...
+ /* Target throwing an error has been closed. Current command should be
+ aborted as the inferior state is no longer valid. */
+ TARGET_CLOSE_ERROR,
+ ...
+ so in a way this is expected behaviour. But aborting quit because the inferior
+ state (which we've already confirmed we're not interested in) is no longer
+ valid, and having to type quit again seems pointless.
+
+ Furthermore, the purpose of not catching errors thrown by
+ query_if_trace_running as per commit 2f9d54cfcef ("make -gdb-exit call
+ disconnect_tracing too, and don't lose history if the target errors on
+ "quit""), was to make sure that error (_("Not confirmed.") had effect.
+
+ Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception
+ during query_if_trace_running and reporting it:
+ ...
+ (gdb) monitor exit
+ (gdb) quit
+ A debugging session is active.
+
+ Inferior 1 [process 19219] will be killed.
+
+ Quit anyway? (y or n) y
+ Remote connection closed
+ $
+ ...
+
+ Tested on x86_64-linux.
+
+ PR server/15746
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-11-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove test-case from test name
+ Remove test-cases from test-names, such that we don't have the redundant:
+ ...
+ PASS: gdb.base/corefile.exp: backtrace in corefile.exp
+ ...
+ but simply:
+ ...
+ PASS: gdb.base/corefile.exp: backtrace
+ ...
+
+ Fixed all instances found using:
+ ...
+ $ grep ":.*:.*\.exp" gdb.sum
+ ...
+
+ Tested on x86_64-linux.
+
+2022-11-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix find_core_file for core named core
+ With test-case gdb.base/bigcore.exp I run into:
+ ...
+ (gdb) PASS: gdb.base/bigcore.exp: get inferior pid
+ signal SIGABRT^M
+ Continuing with signal SIGABRT.^M
+ ^M
+ Program terminated with signal SIGABRT, Aborted.^M
+ The program no longer exists.^M
+ (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
+ UNTESTED: gdb.base/bigcore.exp: can't generate a core file
+ ...
+ due to find_core_file returning "".
+
+ There is a core file name core:
+ ...
+ $ ls ./outputs/gdb.base/bigcore
+ bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1
+ ...
+ but it's not found.
+
+ The problem is this statement:
+ ...
+ lappend files [list ${::testfile}.core core]
+ ...
+ which adds a single list item "${::testfile}.core core".
+
+ Fix this in the most readable way:
+ ...
+ lappend files ${::testfile}.core
+ lappend files core
+ ...
+
+ Tested on x86_64-linux.
+
+2022-11-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: call Unpredictable instead of setting bogus values [PR sim/29276]
+ The intention of this code seems to be to indicate that this insn
+ should not be used and produces undefined behavior, so instead of
+ setting registers to bogus values, call Unpredictable. This fixes
+ build warnings due to 32-bit/64-bit type conversions, and outputs
+ a log message for users at runtime instead of silent corruption.
+
+ Bug: https://sourceware.org/PR29276
+
+2022-11-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: drop unused CORE_ADDR_TYPE
+ This hasn't been used by gdb in decades, and doesn't make sense with
+ a standalone sim program/library where the ABI is fixed. So punt it
+ to simplify the code.
+
+2022-11-08 Haochen Jiang <haochen.jiang@intel.com>
+
+ x86: Correct wrong comments in vex_w_table
+ Hi all,
+
+ This wrong comment was introduced by previous AVX-VNNI-INT8 commit.
+
+ Committed as obvious fix.
+
+ BRs,
+ Haochen
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (VEX_W_0F3851): Corrected from
+ VEX_W_0F3851_P_0.
+
+2022-11-08 Kong Lingling <lingling.kong@intel.com>
+
+ Support Intel RAO-INT
+ gas/ChangeLog:
+
+ * NEWS: Support Intel RAO-INT.
+ * config/tc-i386.c: Add raoint.
+ * doc/c-i386.texi: Document .raoint.
+ * testsuite/gas/i386/i386.exp: Run RAO_INT tests.
+ * testsuite/gas/i386/raoint-intel.d: New test.
+ * testsuite/gas/i386/raoint.d: Ditto.
+ * testsuite/gas/i386/raoint.s: Ditto.
+ * testsuite/gas/i386/x86-64-raoint-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-raoint.d: Ditto.
+ * testsuite/gas/i386/x86-64-raoint.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (PREFIX_0F38FC): New.
+ (prefix_table): Add PREFIX_0F38FC.
+ * i386-gen.c: (cpu_flag_init): Add CPU_RAO_INT_FLAGS and
+ CPU_ANY_RAO_INT_FLAGS.
+ * i386-init.h: Regenerated.
+ * i386-opc.h: (CpuRAO_INT): New.
+ (i386_cpu_flags): Add cpuraoint.
+ * i386-opc.tbl: Add RAO_INT instructions.
+ * i386-tbl.h: Regenerated.
+
+2022-11-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-07 Tom Tromey <tromey@adacore.com>
+
+ Silence libtool during link
+ The switch to linking with libtool now shows a very long link line
+ even when V=0. This patch arranges to silence libtool in this
+ situation.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make lookup_selected_frame static
+ Change-Id: Ide2749a34333110c7f0112b25852c78cace0d2b4
+
+2022-11-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: riscv: add missing AC_MSG_RESULT call
+ Previous commit in here forgot to include this.
+
+ sim: v850: drop subdir configure logic
+ We've been using this only to set the default word size to 32. We
+ can easily move this into the makefile via a -D compiler flag and
+ clean up the build logic quite a bit.
+
+ sim: mn10300: drop subdir configure logic
+ We've been using this only to set the default word size to 32. We
+ can easily move this into the makefile via a -D compiler flag and
+ clean up the build logic quite a bit.
+
+ sim: or1k: drop subdir configure logic
+ We've been using this only to set the default word size to 32. We
+ can easily move this into the makefile via a -D compiler flag and
+ clean up the build logic quite a bit.
+
+ sim: bpf: drop subdir configure logic
+ We've been using this only to set the default word size to 64. We
+ can easily move this into the makefile via a -D compiler flag and
+ clean up the build logic quite a bit.
+
+ sim: riscv: drop subdir configure logic
+ We've been using this only to set the default word size to 32-vs-64
+ based on the $target. We can easily merge this with the top-level
+ configure script to clean things up a bit.
+
+2022-11-07 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gdb: link executables with libtool
+ This patch changes the GDB build system in order to use libtool to
+ link the several built executables. This makes it possible to refer
+ to libtool libraries (.la files) in CLIBS.
+
+ As an application of the above,
+
+ BFD now refers to ../libbfd/libbfd.la
+ OPCODES now refers to ../opcodes/libopcodes.la
+ LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
+ LIBCTF now refers to ../libctf/libctf.la
+
+ NOTE1: The addition of libtool adds a few new configure-time options
+ to GDB. Among these, --enable-shared and --disable-shared, which were
+ previously ignored. Now GDB shall honor these options when linking,
+ picking up the right version of the referred libtool libraries
+ automagically.
+
+ NOTE2: I have not tested the insight build.
+
+ NOTE3: For regenerating configure I used an environment with Autoconf
+ 2.69 and Automake 1.15.1. This should match the previously
+ used version as announced in the configure script.
+
+ NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
+ libctf.so are used by gdb if binutils is installed with
+ --enable-shared.
+
+ Testing performed:
+
+ - --enable-shared and --disable-shared (the default in binutils) work
+ as expected: the linked executables link with the archive or shared
+ libraries transparently.
+
+ - Makefile.in modified for EXEEXT = .exe. It installs the binaries
+ just fine. The installed gdb.exe runs fine.
+
+ - Native build regtested in x86_64. No regressions found.
+
+ - Cross build for aarch64-linux-gnu built to exercise
+ program_transform_name and friends. The installed
+ aarch64-linux-gnu-gdb runs fine.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: use a more unique name in gdb.mi/mi-breakpoint-multiple-locations.exp
+ I see failures in this test, due to the function name "add" being too
+ generic, and unexpected breakpoint locations being found in my
+ libstdc++, such as (wrapped for readability):
+
+ {
+ number="2.4",enabled="y",addr="0x00007ffff7d67e68",
+ func="(anonymous namespace)::fast_float::bigint::add",
+ file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
+ fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
+ line="1815", thread-groups=["i1"]
+ }
+
+ Change the test to use a more unique name.
+
+ Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d
+
+2022-11-07 Pedro Alves <pedro@palves.net>
+
+ Don't explicitly set clone child ptrace options
+ linux_handle_extended_wait calls target_post_attach if we're handling
+ a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
+ target_post_attach just calls linux_init_ptrace_procfs to set the
+ lwp's ptrace options. However, this is completely unnecessary,
+ because, as man ptrace [1] says, options are inherited:
+
+ "Flags are inherited by new tracees created and "auto-attached" via
+ active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
+ options."
+
+ This removes the unnecessary call.
+
+ [1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
+
+2022-11-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: .gdbinit: generate for all arch subdirs
+ This was being skipped for ports that had a recursive configure,
+ but we want it for them too.
+
+ sim: build: add a proper var for enabled arches
+ The install code was using $SUBDIRS to track all enabled arches. This
+ works, but isn't great if we want to add a subdir that isn't an arch
+ port, or as we merge the subdirs into the top-level. Create a new var
+ explicitly to track the list of enabled arches instead.
+
+2022-11-07 Christophe Lyon <christophe.lyon@arm.com>
+
+ configure: require libzstd >= 1.4.0
+ gas uses ZSTD_compressStream2 which is only available with libzstd >=
+ 1.4.0, leading to build errors when an older version is installed.
+
+ This patch updates the check libzstd presence to check its version is
+ >= 1.4.0. However, since gas seems to be the only component requiring
+ such a recent version this may imply that we disable ZSTD support for
+ all components although some would still benefit from an older
+ version.
+
+ I ran 'autoreconf -f' in all directories containing a configure.ac
+ file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
+ several errors from autoheader in readline, as well as warnings in
+ intl, but they are unrelated to this patch.
+
+ This should fix some of the buildbots.
+
+ OK for trunk?
+
+ Thanks,
+
+ Christophe
+
+2022-11-07 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: skip tests related to -shared when disabled
+ Call the helper function "check_shared_lib_support" to ensure -shared
+ is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
+ This allows to catch custom targets explicitly disabling it.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
+ * testsuite/ld-elfweak/elfweak.exp: Likewise.
+ * testsuite/ld-shared/shared.exp: Likewise.
+
+2022-11-07 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove RV32EF conflict
+ Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
+ versions beginning with the version 20190608-Base-Ratified removed this
+ restriction. Because the 'E' extension is still a draft, the author chose
+ to *just* remove the conflict (not checking the ISA version).
+
+ Note that, because RV32E is only used with a soft-float calling convention,
+ there's no valid official ABI for RV32EF. It means, even if we can assemble
+ a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
+ in an unmanaged state (outside ABI management).
+
+ The purpose of this commit is to suppress unnecessary errors while parsing
+ an ISA string and/or disassembling, not to allow hard-float with RVE.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
+ because only older specifications disallowed it.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
+ prohibited.
+ * testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
+
+2022-11-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: respect AM_MAKEFLAGS when entering subdirs
+ This doesn't matter right now, but it will as we add more flags to
+ the recursive make step to pass state down.
+
+ sim: build: stop passing down SIM_PRIMARY_TARGET
+ This was needed when the install step was run in subdirs, but now
+ that we process that entirely in the top-level, we don't need to
+ pass this down, so drop it.
+
+2022-11-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-05 Tom Tromey <tom@tromey.com>
+
+ Deprecate MI version 1
+ MI version 1 is long since obsolete. Rather than remove it
+ immediately (though I did send a patch for that), instead let's
+ deprecate it in GDB 13 and then remove it for GDB 14.
+
+ This version of the patch incorporates Simon's warning change, and
+ Luis' recommendation to mention the gdb versions here.
+
+2022-11-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: fix readline linkage
+ Now that we link programs in the top dir instead of the arch subdir,
+ update the readline library path to be relative to the top dir.
+
+ sim: use libtool to install programs
+ Now that we use libtool to link, we have to use it to install instead
+ of keeping the manual logic so we don't install wrapper shell scripts.
+
+ sim: bfin: move linux-fixed-code.h to top-level
+
+2022-11-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: run: move linking into top-level
+ Automake will run each subdir individually before moving on to the next
+ one. This means that the linking phase, a single threaded process, will
+ not run in parallel with anything else. When we have to link ~32 ports,
+ that's 32 link steps that don't take advantage of parallel systems. On
+ my really old 4-core system, this cuts a multi-target build from ~60 sec
+ to ~30 sec. We eventually want to move all compile+link steps to this
+ common dir anyways, so might as well move linking now for a nice speedup.
+
+ We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
+ of the install ourselves rather than letting automake process it.
+
+2022-11-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: add uninstall support
+ This never worked before, but adding it to the common top-level dir
+ is pretty easy to do now that we're unified.
+
+ sim: build: move install steps to the top-level
+ We still have to maintain custom install rules due to how we rename
+ arch-specific files with an arch prefix in their name, but we can at
+ least unify the logic in the common dir.
+
+ sim: cris: move rvdummy linking to top-level
+ This is only used by `make check`, so we can move it out of the
+ default build too.
+
+ sim: build: add SIM_HW_CFLAGS to top-level build too
+ This matches what we do with targets already.
+
+ sim: drop unused SIM_HARDWARE variable
+ This hasn't been used since the refactor way back in commit
+ f872d0d643968c1101bb8c07b252edd54f626da2 ("Only enable H/W
+ on some mips targets."), so punt it.
+
+ sim: adjust sim_hw options style
+ We use uppercase for other variables, and are already turning it to
+ uppercase in the arch-subdir.mk, so convert it in the configure step.
+
+ sim: ppc: drop unused /dev/zero logic
+ Nothing in the tree checks this option, or has checked for decades.
+ The pre-cvs-import ChangeLog suggests this was added & removed back
+ then, but can't be sure as that history doesn't exist in the VCS.
+
+ sim: ppc: delete unused host bitsize settings
+ Nothing checks this define anywhere, so drop all the logic. We don't
+ want this to be a configure option in the first place as all such usage
+ should be automatic & following proper types.
+
+ sim: ppc: inline the sim-packages option
+ This has only ever had a single option that's enabled by default.
+ The objects it adds are pretty small and don't add overhead at
+ runtime if it isn't used, so just enable it all the time to make
+ the build code simpler.
+
+2022-11-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-04 H.J. Lu <hjl.tools@gmail.com>
+
+ binutils: Run PR binutils/26160 test
+ Update expected PR binutils/26160 test output for readelf out change
+ and run PR binutils/26160 test.
+
+ PR binutils/26160
+ * testsuite/binutils-all/pr26160.r: Updated.
+ * testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.
+
+2022-11-04 Lancelot SIX <lancelot.six@amd.com>
+
+ [testsuite] gdb.base/dlmopen: Fix test name and use gdb_attach
+ One test name in gdb.base/dlmopen.exp changes from run to run
+ since it includes a process id:
+
+ PASS: gdb.base/dlmopen.exp: attach 3442682
+
+ This is not convenient do diff gdb.sum files to compare test runs.
+
+ Fix by using gdb_attach helper function to handle attaching to the
+ process as it produce a constant test name.
+
+ While at it also check gdb_attach's return value to only run the
+ rest of the test if the attach was successful.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-04 Carl Love <cel@us.ibm.com>
+
+ PowerPC update comments for the MMA instruction name changes.
+ The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
+ pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
+ pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
+ pmdmxvi16ger* respectively. The old mnemonics are still supported by the
+ assembler as extended mnemonics. The disassembler generates the new
+ mnemonics. The name changes occurred in commit:
+
+ commit bb98553cad4e017f1851153fa5de91f2cee98fb2
+ Author: Peter Bergner <bergner@linux.ibm.com>
+ Date: Sat Oct 8 16:19:51 2022 -0500
+
+ PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
+
+ gas/
+ * config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
+ * testsuite/gas/ppc/rfc02658.s: New test.
+ * testsuite/gas/ppc/rfc02658.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+ opcodes/
+ * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
+ (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
+ dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
+ dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
+ dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
+ pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
+ pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
+ pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
+
+ This patch updates the comments in the various gdb files to reflect the
+ name changes. There are no functional changes made by this patch.
+
+ The older instruction names are still used in the test
+ gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.
+
+ Patch has been tested on Power 10 with no regressions.
+
+2022-11-04 Carl Love <cel@us.ibm.com>
+
+ PowerPC fix for the gdb.arch/powerpc-power10.exp test.
+ The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
+ pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
+ pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
+ pmdmxvi16ger* respectively. The old mnemonics are still supported by the
+ assembler as extended mnemonics. The disassembler generates the new
+ mnemonics. The name changes occurred in commit:
+
+ commit bb98553cad4e017f1851153fa5de91f2cee98fb2
+ Author: Peter Bergner <bergner@linux.ibm.com>
+ Date: Sat Oct 8 16:19:51 2022 -0500
+
+ PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
+
+ gas/
+ * config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
+ * testsuite/gas/ppc/rfc02658.s: New test.
+ * testsuite/gas/ppc/rfc02658.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+ opcodes/
+ * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
+ (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
+ dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
+ dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
+ dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
+ pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
+ pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
+ pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
+
+ The above commit results in about 224 failures on Power 10 since the
+ disassembled names do not match the expected names in the test. This
+ patch updates the expected names in the test to match the values produced
+ by the disassembler.
+
+ This patch updates file gdb.arch/powerpc-power10.exp with the new expected
+ values to the instructions. The comment giving the name of the instruction
+ for each binary value in the file gdb.arch/powerpc-power10.c is updated
+ with the new name. There are no functional changes in file
+ gdb.arch/powerpc-power10.c.
+
+2022-11-04 Carl Love <cel@us.ibm.com>
+
+ Powerpc fix for gdb.base/unwind-on-each-insn.exp
+ The test disassembles function foo and searches for the line
+ "End of assembler dump" to determing the last address in the function. The
+ assumption is the last instruction will be given right before the line
+ "End of assembler dump". This assumption fails on PowerPC.
+
+ The PowerPC disassembly of the function foo looks like:
+ Dump of assembler code for function foo:
+ # => 0x00000000100006dc <+0>: std r31,-8(r1)
+ # 0x00000000100006e0 <+4>: stdu r1,-48(r1)
+ # 0x00000000100006e4 <+8>: mr r31,r1
+ # 0x00000000100006e8 <+12>: nop
+ # 0x00000000100006ec <+16>: addi r1,r31,48
+ # 0x00000000100006f0 <+20>: ld r31,-8(r1)
+ # 0x00000000100006f4 <+24>: blr
+ # 0x00000000100006f8 <+28>: .long 0x0
+ # 0x00000000100006fc <+32>: .long 0x0
+ # 0x0000000010000700 <+36>: .long 0x1000180
+ # End of assembler dump.
+
+ The blr instruction is the last instruction in function foo. The lines
+ with .long following the blr instruction need to be ignored.
+
+ This patch adds a new condition to the gdb_test_multiple "disassemble foo"
+ test to ignore the lines with the .long.
+
+ The patch has been tested on PowerPC and Intel X86-64.
+
+2022-11-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: adjust recently introduced testcases
+ The issue addressed by 2c02c72c62d2 ("re: Support Intel AMX-FP16") has
+ been introduced once again in a number of new tests.
+
+2022-11-04 Nick Clifton <nickc@redhat.com>
+
+ Update release documentation with regard to uploading gprofng docs
+
+2022-11-04 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp
+ Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
+ PR record/29745, where we can't skip one funcion forward if we're using
+ native-gdbserver. This commit just adds kfails to the test.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-04 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: silence compiler warning about uninitialized variable use
+ After this commit:
+
+ commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
+ Date: Thu Jul 7 13:43:45 2022 +0100
+
+ opcodes/arm: add disassembler styling for arm
+
+ Some people were seeing their builds failing with complaints about a
+ possible uninitialized variable usage. I previously fixed an instance
+ of this issue in this commit:
+
+ commit 2df82cd4b459fbc32120e0ad1ce19e26349506fe
+ Date: Tue Nov 1 10:36:59 2022 +0000
+
+ opcodes/arm: silence compiler warning about uninitialized variable use
+
+ which did fix the build problems that the sourceware buildbot was
+ hitting, however, an additional instance of the same problem was
+ brought to my attention, and that is fixed in this commit.
+
+ Where commit 2df82cd4b4 fixed the uninitialized variable problem in
+ print_mve_unpredictable, this commit fixes the same problem in
+ print_mve_undefined.
+
+ As with the previous commit, I don't believe we could really ever get
+ an uninitialized variable usage, based on the current usage of the
+ function, so I have just initialized the reason variable to "??".
+
+2022-11-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: rx: drop unused $arch setting
+ This is only needed for CGEN ports which RX isn't, so drop it.
+
+2022-11-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: build: remove various obsolete generation dep variables
+ These manual settings were necessary when we weren't doing automatic
+ header dependency tracking. That was changed a while ago, and we use
+ automake now to do it all for us. As a result, many of these vars
+ aren't even referenced anymore.
+
+ Further, some of the source file generation (e.g. .c files, or igen,
+ or cgen outputs) were moved to the common automake build, and it takes
+ care of dependency tracking for us with the object files.
+
+2022-11-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: don't hardcode -ldl for SDL support
+ Since we use AC_SEARCH_LIBS to find dlopen, we don't need to hardcode
+ -ldl when using SDL ourselves.
+
+2022-11-04 konglin1 <lingling.kong@intel.com>
+
+ Support Intel AVX-NE-CONVERT
+ gas/ChangeLog:
+
+ * NEWS: Support Intel AVX-NE-CONVERT.
+ * config/tc-i386.c: Add avx_ne_convert.
+ * doc/c-i386.texi: Document .avx_ne_convert.
+ * testsuite/gas/i386/i386.exp: Run AVX NE CONVERT tests.
+ * testsuite/gas/i386/avx-ne-convert-intel.d: New test.
+ * testsuite/gas/i386/avx-ne-convert.d: Ditto.
+ * testsuite/gas/i386/avx-ne-convert.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (Mw): New.
+ (PREFIX_VEX_0F3872): Ditto.
+ (PREFIX_VEX_0F38B0_W_0): Ditto.
+ (PREFIX_VEX_0F38B1_W_0): Ditto.
+ (VEX_W_0F3872_P_1): Ditto.
+ (VEX_W_0F38B0): Ditto.
+ (VEX_W_0F38B1): Ditto.
+ (prefix_table): Add PREFIX_VEX_0F3872, PREFIX_VEX_0F38B0_W_0,
+ PREFIX_VEX_0F38B1_W_0.
+ (vex_w_table): Add VEX_W_0F3872_P_1, VEX_W_0F38B0, VEX_W_0F38B1.
+ * i386-gen.c (cpu_flag_init): Add CPU_AVX_NE_CONVERT_FLGAS and
+ CPU_ANY_AVX_NE_CONVERT_FLAGS.
+ (cpu_flags): Add CpuAVX_NE_CONVERT.
+ * i386-init.h: Regenerated.
+ * i386-opc.h (CpuAVX_NE CONVERT): New.
+ (i386_cpu_flags): Add cpuavx_ne_convert.
+ * i386-opc.tbl: Add Intel AVX-NE-CONVERT instructions.
+ * i386-tbl.h: Regenerated.
+
+2022-11-04 konglin1 <lingling.kong@intel.com>
+
+ i386: Rename <xy> template.
+ opcodes/
+ * i386-opc.tbl: Rename <xy> template for VEX insn with x/y suffix to <Vxy>.
+ Rename <xy> for EVEX insn with x/y suffix to <Exy>.
+
+2022-11-04 Jojo R <rjiejie@linux.alibaba.com>
+
+ Support multiple .eh_frame sections
+ This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE,
+ it allows backend to enable this feature and use '--gc-sections' simply.
+
+ * gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New.
+ (MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
+ * gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
+ (is_now_linkonce_segment): Likewise.
+ (get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section.
+
+ * bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New.
+ * bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise.
+ * bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for
+ elf_backend_can_make_multiple_eh_frame.
+
+2022-11-04 Jojo R <rjiejie@linux.alibaba.com>
+
+ gas/doc/internals.texi: fix typo
+ * gas/doc/internals.texi (md_emit_single_noop_insn):
+ fix '@var missing closing brace'
+ * gas/doc/internals.texi (Hash tables):
+ fix '@menu reference to nonexistent node `Hash tables''
+
+2022-11-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: drop -lm from SIM_EXTRA_LIBS
+ We have configure tests for this in the top-level configure script
+ to link this when necessary, so we don't need to explicitly list it
+ for specific ports.
+
+ sim: build: change AC_CHECK_LIB to AC_SEARCH_LIBS
+ With more C libraries moving functions entirely into the main -lc,
+ change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there
+ first and avoid extra linkage when possible.
+
+ sim: build: drop duplicate $(LIBS) usage
+ COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus
+ @LIBS@. This leds to the values being used twice. Inline the
+ CONFIG_LIBS variable without @LIBS@ since it's used only once.
+
+ sim: build: switch to bfd & opcodes libtool linker scripts
+ Now that we use libtool to link, we don't need to duplicate all the
+ libs that bfd itself uses. This simplifies the configure & Makefile.
+
+ sim: build: switch to libtool for linking
+ The top-level already sets up a libtool script for the host, so use
+ that when linking rather than invoking CC directly. This will also
+ happen when we (someday) move the building to pure automake.
+
+2022-11-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: fix cris stat3 in diff setups
+ This test uses the test itself as an input to stating regular files.
+ This gets funky though: when we run check in parallel, the output
+ object dir is the subdir that matches the .exp file. When we run
+ with -j1, the output object dir is the sim builddir itself.
+
+ The old test would append argv[0] to find the file, while the new
+ test uses basename on it. Each method works in only one of the
+ aforementioned build scenarios. Rather than complicate this any
+ more, switch to a different file that we know will always exist:
+ the Makefile.
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: fix cris badarch in multi-target builds
+ This test assumes that /bin/sh will never be a CRIS ELF by way of
+ assuming that the current bfd cannot load it (since a basic cris
+ cross-compiler only understands CRIS ELFs). In a multi-target
+ build though, bfd understands just about every ELF out there, so
+ we're able to read the /bin/sh format before failing at a diff
+ point in the cris code.
+
+ Let's switch to using / instead since it'll fail for a similar
+ reason (at least similar enough for what this test is testing).
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cleanup unused SIM_EXTRA_CFLAGS
+ We want to eventually delete this, so at least drop the empty ones.
+
+ sim: m32c/rx: drop useless $(ENDLIST)
+ This is used to allow for dangling \ in object lists, but these are the
+ only ports that do it, and it isn't really necessary. Punt it to keep
+ the various makefiles harmonized.
+
+ sim: mips: simplify fpu configure logic
+ The configure code always defaults to HARD_FLOATING_POINT, so inline
+ that value and drop redundant target checks as a result.
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: erc32: link sis to run program
+ The erc32 sim does a lot itself, including handling of the CLI. It
+ used to provide a run-compatible interface in the pre-nrun days, but
+ it was dropped when the old run interface was punted. Since the old
+ commit 465fb143c87076b6416a8d0d5dd79bb016060fe3 ("sim: make nrun the
+ default run program"), the erc32 run & sis programs have been the
+ same, and erc32 hasn't provide a real run-compatible interface.
+
+ Simplify this by linking the two programs via ln/cp instead of running
+ the linking phase twice to produce the same result. If/when we fix up
+ the erc32 port to have a proper run interface, it should be easy to
+ split these back apart into real programs.
+
+ Note: the interf.o reference in here is a bit of a misdirect. Since
+ that object is placed into libsim.a, it's never been linked into the
+ programs since the linker ignores objects that aren't referenced, and
+ only gdb uses those symbols.
+
+2022-11-03 Nick Clifton <nickc@redhat.com>
+
+ V850 Linker: do not complain about RWX segments.
+ PR 29748
+ * configure.tgt (ac_default_ld_warn_rwx_segments): Set to 0 for
+ the V850.
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: switch to standard (high-level) trace defines
+ The v850 port uses -DDEBUG to control whether to enable internal tracing.
+ We already have such options via the common trace framework, and those
+ can be controlled at build time via configure flags (which the v850 code
+ currently cannot). So switch it over to WITH_TRACE_ANY_P to simplify the
+ v850 build code even if it doesn't (yet) respect any other trace options.
+
+ sim: ppc: include copyright & license in --version
+ This makes it match the other sim run programs and GNU tools.
+
+ sim: update --version copyright year
+ Probably should have done this 11 months ago ...
+
+ sim: ppc: drop use of DATE & TIME
+ No other tool does this, sim or otherwise, and it makes the ppc build
+ non-reproducible. Drop it to simplify & make reproducible.
+
+2022-11-03 Bruno Larsen <blarsen@redhat.com>
+
+ gdb: Fix issue with Clang CLI macros
+ Clang up to version 15 (current) adds macros that were defined in the
+ command line or by "other means", according to the Dwarf specification,
+ after the last DW_MACRO_end_file, instead of before the first
+ DW_MACRO_start_file, as the specification dictates. When GDB reads the
+ macros after the last file is closed, the macros never end up "in scope"
+ and so we can't print them. This has been submitted as a bug to Clang
+ developers (https://github.com/llvm/llvm-project/issues/54506), and PR
+ macros/29034 was opened for GDB to keep track of this.
+
+ Seeing as there is no expected date for it to be fixed, add a workaround
+ for all current versions of Clang. The workaround detects when
+ the main file would be closed and if the producer is Clang, and turns
+ that operation into a noop, so we keep a reference to the current_file
+ as those macros are read.
+
+ A test case was added to confirm the functionality, and the KFAIL for
+ running gdb.base/macro-source-path when using clang.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29034
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-11-03 Nick Clifton <nickc@redhat.com>
+
+ AVR Linker: Allow the start of the data region to be specified on the linker command line. [Fix PR number in ChangeLog entry]
+ PR 29741
+ * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value
+ has not been provided on the command line then use DATA_ORIGIN.
+ (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
+
+ AVR Linker: Allow the start of the data region to specified on the command line.
+ PR 29471
+ * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value
+ has not been provided on the command line then use DATA_ORIGIN.
+ (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: move common flags to default AM_CPPFLAGS
+ Since all host files we compile use these settings, move them out of
+ libcommon.a and into the default AM_CPPFLAGS. This has the effect of
+ dropping the custom per-target automake rules. Currently it saves us
+ ~150 lines, but since it's about ~8 lines per object, the overhead
+ will increase quite a bit as we merge more files into a single build.
+
+ This also changes the object output names, so we have to tweak the
+ rules that were pulling in the common objects when linking.
+
+2022-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: merge gnulib logic into the top-level
+ We aren't using this just yet, but we will, so make it available to
+ building of common sim files.
+
+ sim: common: remove unused include paths
+ A bunch of these paths don't include any headers, and most likely
+ never will, so there's no real need to keep them. This will let
+ us harmonize paths with the top-level Makefile more easily, which
+ will in turn make it easier to move more compile steps there.
+
+2022-11-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-02 Christophe Lyon <christophe.lyon@arm.com>
+
+ arm: PR 29739 Fix typo where ';' should not have been replaced with '@'
+ ';' does not always indicate the start of a comment, and commit
+ 8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3
+ instances of ';' with '@' in expected diagnostics, leading to tests
+ failures.
+
+ This patch restores the original ';' as needed in these testcases.
+
+ Fixes bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29739
+
+2022-11-02 Mike Frysinger <vapier@gentoo.org>
+
+ sim: split CPPFLAGS between build & host
+ In order to merge more common/ files into the top-level, we need to
+ add more host flags to CPPFLAGS, and that conflicts with our current
+ use with build-time tools. So split them apart like we do with all
+ other build flags to avoid the issue.
+
+ sim: h8300: switch to cpu for state
+ Rather than rely on pulling out the first cpu from the sim state
+ for cpu state, pass down the active cpu that's already available.
+
+ sim: common: change sim_{fetch,store}_register helpers to use void* buffers
+ When reading/writing arbitrary data to the system's memory, the unsigned
+ char pointer type doesn't make that much sense. Switch it to void so we
+ align a bit with standard C library read/write functions, and to avoid
+ having to sprinkle casts everywhere.
+
+2022-11-02 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Fix Cygwin build after 20489cca
+ Update code under __CYGWIN__ which accesses inferior process information
+ which is now stored in windows_process_info rather than globals.
+
+2022-11-02 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Fix Cygwin build after bcb9251f
+ Absent _UNICODE being defined (which gdb's Makefile doesn't do),
+ windows.h will always define STARTUPINFO is as STARTUPINFOA, so this
+ cast isn't correct when create_process expects a STARTUPINFOW
+ parameter (i.e. in a Cygwin build).
+
+ Instead write this as &info_ex.StartupInfo (which is always of the
+ correct type).
+
+2022-11-02 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop bogus Tbyte
+ Prior to commit 1cb0ab18ad24 ("x86/Intel: restrict suffix derivation")
+ the Tbyte modifier on the FLDT and FSTPT templates was pointless, as
+ No_ldSuf would have prevented it being accepted. Due to the special
+ nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these
+ insns being accepted in Intel syntax mode even when "tbyte ptr" was
+ present. Restore original behavior by dropping Tbyte there. (Note that
+ these insns in principle should by marked AT&T syntax only, but since
+ they haven't been so far we probably shouldn't change that.)
+
+ x86: simplify expressions in update_imm()
+ Comparing the sum of the relevant .imm<N> fields against a constant imo
+ makes more obvious what is actually meant. It allows dropping of two
+ static variables, with a 3rd drop requiring two more minor adjustments
+ elsewhere, utilizing that "i" is zeroed first thing in md_assemble().
+ This also increases the chances of the compiler doing the calculations
+ all in registers.
+
+2022-11-02 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Fixed the missing $x+arch when adding odd paddings for alignment.
+ Consider the case,
+
+ .option arch, rv32i
+ .option norelax
+ .option arch, +c
+ .byte 1
+ .align 2
+ addi a0, zero, 1
+
+ Assembler adds $d for the odd .byte, and then adds $x+arch for the
+ alignment. Since norelax, riscv_add_odd_padding_symbol will add the
+ $d and $x for the odd alignment, but accidently remove the $x+arch because
+ it has the same address as $d. Therefore, we will get the unexpected result
+ before applying this patch,
+
+ .byte 1 # $d
+ .align 2 # odd alignment, $xrv32ic replaced by $d + $x
+
+ After this patch, the expected result should be,
+
+ .byte 1 # $d
+ .align 2 # odd alignment, $xrv32ic replaced by $d + $xrv32ic
+
+ gas/
+ * config/tc-riscv.c (make_mapping_symbol): If we are adding mapping symbol
+ for odd alignment, then we probably will remove the $x+arch by accidently
+ when it has the same address of $d. Try to add the removed $x+arch back
+ after the $d rather than just $x.
+ (riscv_mapping_state): Updated since parameters of make_mapping_symbol are
+ changed.
+ (riscv_add_odd_padding_symbol): Likewise.
+ (riscv_remove_mapping_symbol): Removed and moved the code into the
+ riscv_check_mapping_symbols.
+ (riscv_check_mapping_symbols): Updated.
+ * testsuite/gas/riscv/mapping-dis.d: Updated and added new testcase.
+ * testsuite/gas/riscv/mapping-symbols.d: Likewise.
+ * testsuite/gas/riscv/mapping.s: Likewise.
+
+2022-11-02 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support Intel MSRLIST
+ gas/ChangeLog:
+
+ * NEWS: Support Intel MSRLIST.
+ * config/tc-i386.c: Add msrlist.
+ * doc/c-i386.texi: Document .msrlist.
+ * testsuite/gas/i386/i386.exp: Add MSRLIST tests.
+ * testsuite/gas/i386/msrlist-inval.l: New test.
+ * testsuite/gas/i386/msrlist-inval.s: Ditto.
+ * testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-msrlist.d: Ditto.
+ * testsuite/gas/i386/x86-64-msrlist.s: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_6_P_1): New.
+ (X86_64_0F01_REG_0_MOD_3_RM_6_P_3): Ditto.
+ (prefix_table): New entry for msrlist.
+ (x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_6_P_1
+ and X86_64_0F01_REG_0_MOD_3_RM_6_P_3.
+ * i386-gen.c (cpu_flag_init): Add CPU_MSRLIST_FLAGS
+ and CPU_ANY_MSRLIST_FLAGS.
+ * i386-init.h: Regenerated.
+ * i386-opc.h (CpuMSRLIST): New.
+ (i386_cpu_flags): Add cpumsrlist.
+ * i386-opc.tbl: Add MSRLIST instructions.
+ * i386-tbl.h: Regenerated.
+
+2022-11-02 Hu, Lin1 <lin1.hu@intel.com>
+
+ Support Intel WRMSRNS
+ gas/ChangeLog:
+
+ * NEWS: Support Intel WRMSRNS.
+ * config/tc-i386.c: Add wrmsrns.
+ * doc/c-i386.texi: Document .wrmsrns.
+ * testsuite/gas/i386/i386.exp: Add WRMSRNS tests.
+ * testsuite/gas/i386/wrmsrns-intel.d: New test.
+ * testsuite/gas/i386/wrmsrns.d: Ditto.
+ * testsuite/gas/i386/wrmsrns.s: Ditto.
+ * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (PREFIX_0F01_REG_0_MOD_3_RM_6): New.
+ (prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_6.
+ (rm_table): New entry for wrmsrns.
+ * i386-gen.c (cpu_flag_init): Add CPU_WRMSRNS_FLAGS
+ and CPU_ANY_WRMSRNS_FLAGS.
+ (cpu_flags): Add CpuWRMSRNS.
+ * i386-init.h: Regenerated.
+ * i386-opc.h (CpuWRMSRNS): New.
+ (i386_cpu_flags): Add cpuwrmsrns.
+ * i386-opc.tbl: Add WRMSRNS instructions.
+ * i386-tbl.h: Regenerated.
+
+2022-11-02 Kong Lingling <lingling.kong@intel.com>
+
+ Add handler for more i386_cpu_flags
+ gas/ChangeLog:
+
+ * config/tc-i386.c (cpu_flags_all_zero): Add new ARRAY_SIZE handle.
+ (cpu_flags_equal): Ditto.
+ (cpu_flags_and): Ditto.
+ (cpu_flags_or): Ditto.
+ (cpu_flags_and_not): Ditto.
+
+2022-11-02 Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel CMPccXADD
+ gas/ChangeLog:
+
+ * NEWS: Support Intel CMPccXADD.
+ * config/tc-i386.c: Add cmpccxadd.
+ (build_modrm_byte): Add operations for Vex.VVVV reg
+ on operand 0 while have memory operand.
+ * doc/c-i386.texi: Document .cmpccxadd.
+ * testsuite/gas/i386/i386.exp: Run CMPccXADD tests.
+ * testsuite/gas/i386/cmpccxadd-inval.s: New test.
+ * testsuite/gas/i386/cmpccxadd-inval.l: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto.
+ * testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (Mdq): New.
+ (X86_64_VEX_0F38E0): Ditto.
+ (X86_64_VEX_0F38E1): Ditto.
+ (X86_64_VEX_0F38E2): Ditto.
+ (X86_64_VEX_0F38E3): Ditto.
+ (X86_64_VEX_0F38E4): Ditto.
+ (X86_64_VEX_0F38E5): Ditto.
+ (X86_64_VEX_0F38E6): Ditto.
+ (X86_64_VEX_0F38E7): Ditto.
+ (X86_64_VEX_0F38E8): Ditto.
+ (X86_64_VEX_0F38E9): Ditto.
+ (X86_64_VEX_0F38EA): Ditto.
+ (X86_64_VEX_0F38EB): Ditto.
+ (X86_64_VEX_0F38EC): Ditto.
+ (X86_64_VEX_0F38ED): Ditto.
+ (X86_64_VEX_0F38EE): Ditto.
+ (X86_64_VEX_0F38EF): Ditto.
+ (x86_64_table): Add X86_64_VEX_0F38E0, X86_64_VEX_0F38E1,
+ X86_64_VEX_0F38E2, X86_64_VEX_0F38E3, X86_64_VEX_0F38E4,
+ X86_64_VEX_0F38E5, X86_64_VEX_0F38E6, X86_64_VEX_0F38E7,
+ X86_64_VEX_0F38E8, X86_64_VEX_0F38E9, X86_64_VEX_0F38EA,
+ X86_64_VEX_0F38EB, X86_64_VEX_0F38EC, X86_64_VEX_0F38ED,
+ X86_64_VEX_0F38EE, X86_64_VEX_0F38EF.
+ * i386-gen.c (cpu_flag_init): Add CPU_CMPCCXADD_FLAGS and
+ CPU_ANY_CMPCCXADD_FLAGS.
+ (cpu_flags): Add CpuCMPCCXADD.
+ * i386-init.h: Regenerated.
+ * i386-opc.h (CpuCMPCCXADD): New.
+ (i386_cpu_flags): Add cpucmpccxadd. Comment unused for it is actually 0.
+ * i386-opc.tbl: Add Intel CMPccXADD instructions.
+ * i386-tbl.h: Regenerated.
+
+2022-11-02 Cui,Lili <lili.cui@intel.com>
+
+ Support Intel AVX-VNNI-INT8
+ gas/
+ * NEWS: Support Intel AVX-VNNI-INT8.
+ * config/tc-i386.c: Add avx_vnni_int8.
+ * doc/c-i386.texi: Document avx_vnni_int8.
+ * testsuite/gas/i386/avx-vnni-int8-intel.d: New file.
+ * testsuite/gas/i386/avx-vnni-int8.d: Likewise.
+ * testsuite/gas/i386/avx-vnni-int8.s: Likewise.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8.d: Likewise.
+ * testsuite/gas/i386/x86-64-avx-vnni-int8.s: Likewise.
+ * testsuite/gas/i386/i386.exp: Run AVX VNNI INT8 tests.
+
+ opcodes/
+ * i386-dis.c: (PREFIX_VEX_0F3850) New.
+ (PREFIX_VEX_0F3851): Likewise.
+ (VEX_W_0F3850_P_0): Likewise.
+ (VEX_W_0F3850_P_1): Likewise.
+ (VEX_W_0F3850_P_2): Likewise.
+ (VEX_W_0F3850_P_3): Likewise.
+ (VEX_W_0F3851_P_0): Likewise.
+ (VEX_W_0F3851_P_1): Likewise.
+ (VEX_W_0F3851_P_2): Likewise.
+ (VEX_W_0F3851_P_3): Likewise.
+ (VEX_W_0F3850): Delete.
+ (VEX_W_0F3851): Likewise.
+ (prefix_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851.
+ (vex_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851,
+ delete VEX_W_0F3850 and VEX_W_0F3851.
+ (vex_w_table): Add VEX_W_0F3850_P_0, VEX_W_0F3850_P_1, VEX_W_0F3850_P_2
+ VEX_W_0F3850_P_3, VEX_W_0F3851_P_0, VEX_W_0F3851_P_1, VEX_W_0F3851_P_2
+ and VEX_W_0F3851_P_3, delete VEX_W_0F3850 and VEX_W_0F3851.
+ * i386-gen.c: (cpu_flag_init): Add CPU_AVX_VNNI_INT8_FLAGS
+ and CPU_ANY_AVX_VNNI_INT8_FLAGS.
+ (cpu_flags): Add CpuAVX_VNNI_INT8.
+ * i386-opc.h (CpuAVX_VNNI_INT8): New.
+ * i386-opc.tbl: Add Intel AVX_VNNI_INT8 instructions.
+ * i386-init.h: Regenerated.
+ * i386-tbl.h: Likewise.
+
+2022-11-02 Hongyu Wang <hongyu.wang@intel.com>
+ Haochen Jiang <haochen.jiang@intel.com>
+
+ Support Intel AVX-IFMA
+ x86: Support Intel AVX-IFMA
+
+ Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is
+ cleared by default. Without {vex} pseudo prefix, Intel IFMA instructions
+ are encoded with EVEX prefix. {vex} pseudo prefix will turn on VEX
+ encoding for Intel IFMA instructions.
+
+ gas/
+
+ * NEWS: Support Intel AVX-IFMA.
+ * config/tc-i386.c (cpu_arch): Add avx_ifma.
+ * doc/c-i386.texi: Document .avx_ifma.
+ * testsuite/gas/i386/avx-ifma.d: New file.
+ * testsuite/gas/i386/avx-ifma-intel.d: Likewise.
+ * testsuite/gas/i386/avx-ifma.s: Likewise.
+ * testsuite/gas/i386/x86-64-avx-ifma.d: Likewise.
+ * testsuite/gas/i386/x86-64-avx-ifma-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-avx-ifma.s: Likewise.
+ * testsuite/gas/i386/i386.exp: Run AVX IFMA tests.
+
+ opcodes/
+
+ * i386-dis.c (PREFIX_VEX_0F38B4): New.
+ (PREFIX_VEX_0F38B5): Likewise.
+ (VEX_W_0F38B4_P_2): Likewise.
+ (VEX_W_0F38B5_P_2): Likewise.
+ (prefix_table): Add PREFIX_VEX_0F38B4 and PREFIX_VEX_0F38B5.
+ (vex_table): Add VEX_W_0F38B4_P_2 and VEX_W_0F38B5_P_2.
+ * i386-dis-evex.h: Fold AVX512IFMA entries to AVX-IFMA.
+ * i386-gen.c (cpu_flag_init): Clear the CpuAVX_IFMA bit in
+ CPU_UNKNOWN_FLAGS. Add CPU_AVX_IFMA_FLGAS and
+ CPU_ANY_AVX_IFMA_FLAGS. Add CpuAVX_IFMA to CPU_AVX2_FLAGS.
+ (cpu_flags): Add CpuAVX_IFMA.
+ * i386-opc.h (CpuAVX_IFMA): New.
+ (i386_cpu_flags): Add cpuavx_ifma.
+ * i386-opc.tbl: Add Intel AVX IFMA instructions.
+ * i386-init.h: Regenerated.
+ * i386-tbl.h: Likewise.
+
+2022-11-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-11-01 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: don't pass non-string literal to printf like function
+ The earlier commit:
+
+ commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
+ Date: Thu Jul 7 13:43:45 2022 +0100
+
+ opcodes/arm: add disassembler styling for arm
+
+ introduced two places where a register name was passed as the format
+ string to the disassembler's fprintf_styled_func callback. This will
+ cause a warning from some compilers, like this:
+
+ ../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’:
+ ../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security]
+ 6005 | func (stream, dis_style_register, arm_regnames[gpr]);
+ | ^~~~
+
+ This commit fixes these by using "%s" as the format string.
+
+2022-11-01 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: silence compiler warning about uninitialized variable use
+ The earlier commit:
+
+ commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
+ Date: Thu Jul 7 13:43:45 2022 +0100
+
+ opcodes/arm: add disassembler styling for arm
+
+ was causing a compiler warning about a possible uninitialized variable
+ usage within opcodes/arm-dis.c.
+
+ The problem is in print_mve_unpredictable, and relates to the reason
+ variable, which is set by a switch table.
+
+ Currently the switch table does cover every valid value, though there
+ is no default case. The variable switched on is passed in as an
+ argument to the print_mve_unpredictable function.
+
+ Looking at how print_mve_unpredictable is used, there is only one use,
+ the second argument is the one that is used for the switch table,
+ looking at how this argument is set, I don't believe it is possible
+ for this argument to take an invalid value.
+
+ So, I think the compiler warning is a false positive. As such, my
+ proposed solution is to initialize the reason variable to the string
+ "??", this will silence the warning, and the "??" string should never
+ end up being printed.
+
+2022-11-01 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: add disassembler styling for arm
+ This commit adds disassembler styling for the ARM architecture.
+
+ The ARM disassembler is driven by several instruction tables,
+ e.g. cde_opcodes, coprocessor_opcodes, neon_opcodes, etc
+
+ The type for elements in each table can vary, but they all have one
+ thing in common, a 'const char *assembler' field. This field
+ contains a string that describes the assembler syntax of the
+ instruction.
+
+ Embedded within that assembler syntax are various escape characters,
+ prefixed with a '%'. Here's an example of a very simple instruction
+ from the arm_opcodes table:
+
+ "pld\t%a"
+
+ The '%a' indicates a particular type of operand, the function
+ print_insn_arm processes the arm_opcodes table, and includes a switch
+ statement that handles the '%a' operand, and takes care of printing
+ the correct value for that instruction operand.
+
+ It is worth noting that there are many print_* functions, each
+ function handles a single *_opcodes table, and includes its own switch
+ statement for operand handling. As a result, every *_opcodes table
+ uses a different mapping for the operand escape sequences. This means
+ that '%a' might print an address for one *_opcodes table, but in a
+ different *_opcodes table '%a' might print a register operand.
+
+ Notice as well that in our example above, the instruction mnemonic
+ 'pld' is embedded within the assembler string. Some instructions also
+ include comments within the assembler string, for example, also from
+ the arm_opcodes table:
+
+ "nop\t\t\t@ (mov r0, r0)"
+
+ here, everything after the '@' is a comment that is displayed at the
+ end of the instruction disassembly.
+
+ The next complexity is that the meaning of some escape sequences is
+ not necessarily fixed. Consider these two examples from arm_opcodes:
+
+ "ldrex%c\tr%12-15d, [%16-19R]"
+ "setpan\t#%9-9d"
+
+ Here, the '%d' escape is used with a bitfield modifier, '%12-15d' in
+ the first instruction, and '%9-9d' in the second instruction, but,
+ both of these are the '%d' escape.
+
+ However, in the first instruction, the '%d' is used to print a
+ register number, notice the 'r' immediately before the '%d'. In the
+ second instruction the '%d' is used to print an immediate, notice the
+ '#' just before the '%d'.
+
+ We have two problems here, first, the '%d' needs to know if it should
+ use register style or immediate style, and secondly, the 'r' and '#'
+ characters also need to be styled appropriately.
+
+ The final thing we must consider is that some escape codes result in
+ more than just a single operand being printed, for example, the '%q'
+ operand as used in arm_opcodes ends up calling arm_decode_shift, which
+ can print a register name, a shift type, and a shift amount, this
+ could end up using register, sub-mnemonic, and immediate styles, as
+ well as the text style for things like ',' between the different
+ parts.
+
+ I propose a three layer approach to adding styling:
+
+ (1) Basic state machine:
+
+ When we start printing an instruction we should maintain the idea
+ of a 'base_style'. Every character from the assembler string will
+ be printed using the base_style.
+
+ The base_style will start as mnemonic, as each instruction starts
+ with an instruction mnemonic. When we encounter the first '\t'
+ character, the base_style will change to text. When we encounter
+ the first '@' the base_style will change to comment_start.
+
+ This simple state machine ensures that for simple instructions the
+ basic parts, except for the operands themselves, will be printed in
+ the correct style.
+
+ (2) Simple operand styling:
+
+ For operands that only have a single meaning, or which expand to
+ multiple parts, all of which have a consistent meaning, then I
+ will simply update the operand printing code to print the operand
+ with the correct style. This will cover a large number of the
+ operands, and is the most consistent with how styling has been
+ added to previous architectures.
+
+ (3) New styling syntax in assembler strings:
+
+ For cases like the '%d' that I describe above, I propose adding a
+ new extension to the assembler syntax. This extension will allow
+ me to temporarily change the base_style. Operands like '%d', will
+ then print using the base_style rather than using a fixed style.
+
+ Here are the two examples from above that use '%d', updated with
+ the new syntax extension:
+
+ "ldrex%c\t%{R:r%12-15d%}, [%16-19R]"
+ "setpan\t%{I:#%9-9d%}"
+
+ The syntax has the general form '%{X:....%}' where the 'X'
+ character changes to indicate a different style. In the first
+ instruction I use '%{R:...%}' to change base_style to the register
+ style, and in the second '%{I:...%}' changes base_style to
+ immediate style.
+
+ Notice that the 'r' and '#' characters are included within the new
+ style group, this ensures that these characters are printed with
+ the correct style rather than as text.
+
+ The function decode_base_style maps from character to style. I've
+ included a character for each style for completeness, though only
+ a small number of styles are currently used.
+
+ I have updated arm-dis.c to the above scheme, and checked all of the
+ tests in gas/testsuite/gas/arm/, and the styling looks reasonable.
+
+ There are no regressions on the ARM gas/binutils/ld tests that I can
+ see, so I don't believe I've changed the output layout at all. There
+ were two binutils tests for which I needed to force the disassembler
+ styling off.
+
+ I can't guarantee that I've not missed some untested corners of the
+ disassembler, or that I might have just missed some incorrectly styled
+ output when reviewing the test results, but I don't believe I've
+ introduced any changes that could break the disassembler - the worst
+ should be some aspect is not styled correctly.
+
+2022-11-01 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/arm: use '@' consistently for the comment character
+ Looking at the ARM disassembler output, every comment seems to start
+ with a ';' character, so I assumed this was the correct character to
+ start an assembler comment.
+
+ I then spotted a couple of places where there was no ';', but instead,
+ just a '@' character. I thought that this was a case of a missing
+ ';', and proposed a patch to add the missing ';' characters.
+
+ Turns out I was wrong, '@' is actually the ARM assembler comment
+ character, while ';' is the statement separator. Thus this:
+
+ nop ;@ comment
+
+ is two statements, the first is the 'nop' instruction, while the
+ second contains no instructions, just the '@ comment' comment text.
+
+ This:
+
+ nop @ comment
+
+ is a single 'nop' instruction followed by a comment. And finally,
+ this:
+
+ nop ; comment
+
+ is two statements, the first contains the 'nop' instruction, while the
+ second contains the instruction 'comment', which obviously isn't
+ actually an instruction at all.
+
+ Why this matters is that, in the next commit, I would like to add
+ libopcodes syntax styling support for ARM.
+
+ The question then is how should the disassembler style the three cases
+ above?
+
+ As '@' is the actual comment start character then clearly the '@' and
+ anything after it can be styled as a comment. But what about ';' in
+ the second example? Style as text? Style as a comment?
+
+ And the third example is even harder, what about the 'comment' text?
+ Style as an instruction mnemonic? Style as text? Style as a comment?
+
+ I think the only sensible answer is to move the disassembler to use
+ '@' consistently as its comment character, and remove all the uses of
+ ';'.
+
+ Then, in the next commit, it's obvious what to do.
+
+ There's obviously a *lot* of tests that get updated by this commit,
+ the only actual code changes are in opcodes/arm-dis.c.
+
+2022-11-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-31 Tom Tromey <tromey@adacore.com>
+
+ Add missing TYPE_CODE_* constants to Python
+ A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb
+ Python layer. This patch fixes the bug, and prevents future
+ occurences of this type of bug.
+
+2022-10-31 Carl Love <cel@us.ibm.com>
+
+ Remove REPARSE condition to force hardware resource checking when updating watchpoints
+ Currently the resource checking is done if REPARSE is true. The hardware
+ watchpoint resource checking in update_watchpoint needs to be redone on
+ each call to function update_watchpoints as the value chain may have
+ changed. The number of hardware registers needed for a watchpoint can
+ change if the variable being watched changes. This situation occurs in
+ this test when watching variable **global_ptr_ptr. Initially when the
+ watch command is issued, only two addresses need to be watched as
+ **global_ptr_ptr has not yet been initialized. Once the value of
+ **global_ptr_ptr is initialized the locations to be tracked increase to
+ three addresses. However, update_watchpoints is not called again with
+ REPARSE set to 1 to force the resource checking to be redone. When the
+ test is run on Power 10, an internal gdb error occurs when the PowerPC
+ routine tries to setup the three hardware watchpoint address since the hw
+ only has two hardware watchpoint registers. The error occurs because the
+ resource checking was not redone in update_watchpoints after
+ **global_ptr_ptr changed.
+
+ The following descibes the situation in detail that occurs on Power 10 with
+ gdb running on the binary for gdb.base/watchpoint.c.
+
+ 1 break func4
+ 2 run
+ 3 watch *global_ptr
+ 4 next execute source code: buf[0] = 3;
+ 5 next execute source code: global_ptr = buf;
+ 6 next execute source code: buf[0] = 7;
+ 7 delete 2 (delete watch *global_ptr)
+ 8 watch **global_ptr_ptr
+ 9 next execute source code: buf[1] = 5;
+ 10 next global_ptr_ptr = &global_ptr;
+ 11 next buf[0] = 9;
+
+ In step 8, the the watch **global_ptr_prt command calls update_watchpoint
+ in breakpoint.c with REPARSE set to 1. The function update_watchpoint
+ calls can_use_hardware_watchpoint to see if there are enough
+ resources available to add the watchpoint since REPARSE is set to 1. At
+ this point, **global_ptr_ptr has not been initialized so only two addresses
+ are watched. The val_chain contains the address for **global_ptr_ptr and 0
+ since **global_ptr_ptr has not been initialized. The update_watchpoint
+ updates the breakpoint list as follows:
+
+ breakpoint 0
+ loc 0: b->address = 0x100009c0
+ breakpoint 1
+ loc 1: b->address = 0x7ffff7f838a0
+ breakpoint 2
+ loc 2: b->address = 0x7ffff7b7fc54
+ breakpoint 3
+ loc 3: b->address = 0x7ffff7a5788c
+ breakpoint 4
+ loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr
+ loc 5: b->address = 0x100200b8 <-- global_ptr_ptr watchpoint
+ breakpoint 5
+ loc 6: b->address = 0x7ffff7b7fc54
+
+ In step 10, the next command executes the source code
+ global_ptr_ptr = &global_ptr. This changes the set of locations to be
+ watched for the watchpoint **global_ptr_prt. The list of addresses for the
+ breakpoint consist of the address for global_ptr_prt, global_ptr and buf.
+ The breakpoint list gets updated by update_watchpoint as follows:
+
+ breakpoint 0
+ loc 0: b->address = 0x100009c0
+ breakpoint 1
+ loc 1: b->address = 0x7ffff7f838a0
+ breakpoint 2
+ loc 2: b->address = 0x7ffff7b7fc54
+ breakpoint 3
+ loc 3: b->address = 0x7ffff7a5788c
+ breakpoint 4
+ loc 4: b->address = 0x10020050 buf
+ loc 5: b->address = 0x100200b0 watch *global_ptr
+ loc 6: b->address = 0x100200b8 watch **global_ptr_ptr
+ breakpoint 5
+ loc 7: b->address = 0x7ffff7b7fc54
+ breakpoint 6
+
+ However, the hardware resource checking was not redone because
+ update_breakpoint was called with REPARSE equal to 0.
+
+ Step 11, execute the third next command. The function
+ ppc_linux_nat_target::low_prepare_to_resume() attempts a ptrace
+ call to setup each of the three address for breakpoint 4. The slot
+ value returned for the third ptrace call is -1 indicating an error
+ because there are only two hardware watchpoint registers available on
+ Power 10.
+
+ This patch removes just the statement "if (reparse)" in function
+ update_watchpoint to force the resources to be rechecked on every call to
+ the function. This ensures that any changes to the val_chain resulting
+ in needing more resources then available will be caught.
+
+ The patch has been tested on Power 8, Power 10 and X86-64. Note the patch
+ has no effect on Power 9 since hardware watchpoint support is disabled on
+ that processor.
+
+2022-10-31 Carl Love <cel@us.ibm.com>
+
+ PowerPC, add support for recording pipe2 system call.
+ Test gdb.reverse/pipe-reverse.exp fails on Power 10 running the fedora 36
+ distro. The gdb record error message is:
+
+ Process record and replay target doesn't support syscall number 317.
+
+ System call 317 on PowerPC maps to the pipe2 system call.
+
+ This patch adds support for the missing pipe2 system call for PowerPC.
+
+ Patch fixes the test failure in gdb.reverse/pipe-reverse.exp.
+
+ The patch has been tested on Power 10 with no regression failures.
+
+2022-10-31 Jan Beulich <jbeulich@suse.com>
+
+ x86: minor improvements to optimize_imm() (part III)
+ Earlier tidying still missed an opportunity: There's no need for the
+ "anyimm" static variable. Instead of using it in the loop to mask
+ "allowed" (which is necessary to satisfy operand_type_or()'s assertions)
+ simply use "mask", requiring it to be calculated first. That way the
+ post-loop masking by "mask" ahead of the operand_type_all_zero() can be
+ dropped.
+
+2022-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: reg: constify store helper
+ These functions only read from memory, so mark the pointer as const.
+
+ sim: constify various integer readers
+ These functions only read from memory, so mark the pointer as const.
+
+ sim: cgen: constify GETT helpers
+ These functions only read from memory, so mark the pointer as const.
+
+ sim: common: change sim_read & sim_write to use void* buffers
+ When reading/writing arbitrary data to the system's memory, the unsigned
+ char pointer type doesn't make that much sense. Switch it to void so we
+ align a bit with standard C library read/write functions, and to avoid
+ having to sprinkle casts everywhere.
+
+2022-10-31 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Silence GCC 12 warning on tc-i386.c
+ Silence GCC 12 warning on tc-i386.c:
+
+ gas/config/tc-i386.c: In function ‘md_assemble’:
+ gas/config/tc-i386.c:5039:16: error: too many arguments for format [-Werror=format-extra-args]
+ 5039 | as_warn (_("only support RIP-relative address"), i.tm.name);
+
+ * config/tc-i386.c (md_assemble): Print mnemonic in RIP-relative
+ warning.
+ * estsuite/gas/i386/x86-64-prefetchi-warn.l: Updated.
+
+2022-10-31 Tom Tromey <tromey@adacore.com>
+
+ Use enum for gdbarch's call_dummy_location
+ This changes gdbarch to use an enum for call_dummy_location, providing
+ a little more type safety.
+
+ Inline initialization of gdbarch members
+ This changes gdbarch to use the "predefault" to initialize its members
+ inline. This required changing a couple of the Value instantiations
+ to avoid a use of "gdbarch" during initialization, but on the whole I
+ think this is better -- it removes a hidden ordering dependency.
+
+2022-10-31 Tom Tromey <tromey@adacore.com>
+
+ Fix regression in pointer-to-member printing
+ PR c++/29243 points out that "info func" on a certain C++ executable
+ will cause an infinite loop in gdb.
+
+ I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
+ member pointers directly in generic_value_print"). Before this
+ commit, the C++ code to print a member pointer would wind up calling
+ value_print_scalar_formatted; but afterward it simply calls
+ generic_value_print and gets into a loop.
+
+ This patch restores the previous behavior and adds a regression test.
+
+2022-10-31 Nick Clifton <nickc@redhat.com>
+
+ Updated Romainain translation for the binutils sub-directory and Swedish translations for the ld and opcodes sub-directories.
+
+2022-10-31 Cui, Lili <lili.cui@intel.com>
+
+ Support Intel PREFETCHI
+ gas/ChangeLog:
+
+ * NEWS: Add support for Intel PREFETCHI instruction.
+ * config/tc-i386.c (load_insn_p): Use prefetch* to fold all prefetches.
+ (md_assemble): Add warning for illegal input of PREFETCHI.
+ * doc/c-i386.texi: Document .prefetchi.
+ * testsuite/gas/i386/i386.exp: Run PREFETCHI tests.
+ * testsuite/gas/i386/x86-64-lfence-load.d: Add PREFETCHI.
+ * testsuite/gas/i386/x86-64-lfence-load.s: Likewise.
+ * testsuite/gas/i386/x86-64-prefetch.d: New test.
+ * testsuite/gas/i386/x86-64-prefetchi-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-prefetchi-inval-register.d: Likewise..
+ * testsuite/gas/i386/x86-64-prefetchi-inval-register.s: Likewise.
+ * testsuite/gas/i386/x86-64-prefetchi-warn.l: Likewise.
+ * testsuite/gas/i386/x86-64-prefetchi-warn.s: Likewise.
+ * testsuite/gas/i386/x86-64-prefetchi.d: Likewise.
+ * testsuite/gas/i386/x86-64-prefetchi.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * i386-dis.c (reg_table): Add MOD_0F18_REG_6 and MOD_0F18_REG_7
+ (x86_64_table): Add X86_64_0F18_REG_6_MOD_0 and X86_64_0F18_REG_7_MOD_0.
+ (mod_table): Add MOD_0F18_REG_6 and MOD_0F18_REG_7.
+ (prefix_table): Add PREFIX_0F18_REG_6_MOD_0_X86_64 and
+ PREFIX_0F18_REG_7_MOD_0_X86_64.
+ (PREFETCHI_Fixup): New.
+ * i386-gen.c (cpu_flag_init): Add CPU_PREFETCHI_FLAGS.
+ (cpu_flags): Add CpuPREFETCHI.
+ * i386-opc.h (CpuPREFETCHI): New.
+ (i386_cpu_flags): Add cpuprefetchi.
+ * i386-opc.tbl: Add Intel PREFETCHI instructions.
+ * i386-init.h: Regenerated.
+ * i386-tbl.h: Likewise.
+
+2022-10-31 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix gdb.cp/converts.exp to run with clang
+ Clang attempts to minimize the size of the debug-info by not adding
+ complete information about types that aren't constructed in a given
+ file. Specifically, this meant that there was minimal information about
+ class B in the test gdb.cp/converts.exp. To fix this, we just need to
+ construct any object of type B in that file.
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-10-31 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: add XFAIL to gdb.cp/ptype-flags.exp when using clang
+ When running gdb.cp/ptype-flags.exp using Clang, we get an unexpected
+ failure when printing the type of a class with an internal typedef. This
+ happens because Clang doesn't add accessibility information for typedefs
+ inside classes (see https://github.com/llvm/llvm-project/issues/57608
+ for more info). To help with Clang testing, an XFAIL was added to this
+ test.
+
+2022-10-31 Yoshinori Sato <ysato@users.sourceforge.jp>
+
+ RX assembler: switch arguments of thw MVTACGU insn.
+
+2022-10-31 Nick Clifton <nickc@redhat.com>
+
+ objdump: Add configure time option to enable colored disassembly output by default.
+ PR 29457
+ * configure.ac: Add --enable-colored-disassembly.
+ * objdump.c: Add --disassembler-color=terminal.
+ * doc/binutils.texi (objdump): Document the new option.
+ * NEWS: Mention new feature.
+ * config.in: Regenerate in.
+ * configure: Regenerate.
+
+2022-10-31 Mark Harmstone <mark@harmstone.com>
+
+ ld: Add publics stream to PDB files
+
+ ld: Add section header stream to PDB files
+
+ ld: Use %E in einfo in pdb.c
+ Resubmission, taking into account
+ https://sourceware.org/pipermail/binutils/2022-October/123948.html.
+
+2022-10-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-30 Alan Modra <amodra@gmail.com>
+
+ Pool section entries for DWP version 1
+ Ref: https://gcc.gnu.org/wiki/DebugFissionDWP?action=recall&rev=3
+
+ Fuzzers have found a weakness in the code stashing pool section
+ entries. With random nonsensical values in the index entries (rather
+ than each index pointing to its own set distinct from other sets),
+ it's possible to overflow the space allocated, losing the NULL
+ terminator. Without a terminator, find_section_in_set can run off the
+ end of the shndx_pool buffer. Fix this by scanning the pool directly.
+
+ binutils/
+ * dwarf.c (add_shndx_to_cu_tu_entry): Delete range check.
+ (end_cu_tu_entry): Likewise.
+ (process_cu_tu_index): Fill shndx_pool by directly scanning
+ pool, rather than indirectly from index entries.
+
+2022-10-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-29 Maciej W. Rozycki <macro@embecosm.com>
+
+ gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp
+ Wrap an overlong line in the definition of `param_integer_error' in
+ gdb.guile/scm-parameter.exp. No functional change.
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/sh: Remove redundant function declaration
+ Clang generates a warning if there is a function declaration/definition
+ with zero arguments. Such declarations/definitions without a prototype (an
+ argument list) are deprecated forms of indefinite arguments
+ ("-Wdeprecated-non-prototype"). On the default configuration, it causes a
+ build failure (unless "--disable-werror" is specified).
+
+ But there is another issue. This function declaration in sim/sh/interp.c
+ is completely redundant. This commit just removes that declaration.
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/m32r: Initialize "list" variable
+ The variable "list" is only initialized when arg1 > 0 and when arg1 == 0,
+ an uninitialized value is passed to translate_endian_h2t function.
+
+ Although this behavior is harmless, this commit adds initialization to avoid
+ a GCC warning ("-Wmaybe-uninitialized").
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/erc32: Use int32_t as IRQ callback argument
+ Clang generates a warning if an argument is passed to a function without
+ prototype (zero arguments, even without (void)). Such calls are deprecated
+ forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
+ On the default configuration, it (somehow) doesn't cause a build failure but
+ a warning is generated.
+
+ But because the cause is the same as the issue the author fixed in
+ "sim/erc32: Use int32_t as event callback argument", it would be better to
+ fix it now to prevent problems in the future.
+
+ To fix the issue, this commit makes struct irqcall to use int32_t as a
+ callback (callback) argument of an IRQ.
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/erc32: Use int32_t as event callback argument
+ Clang generates a warning if an argument is passed to a function without
+ prototype (zero arguments, even without (void)). Such calls are deprecated
+ forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
+ On the default configuration, it causes a build failure (unless
+ "--disable-werror" is specified).
+
+ To fix that, this commit makes struct evcell to use int32_t as a callback
+ (cfunc) argument of an event. int32_t is chosen because "event" function
+ accepts "int32_t arg".
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/erc32: Insert void parameter
+ Clang generates a warning if there is a function declaration/definition
+ with zero arguments. Such declarations/definitions without a prototype (an
+ argument list) are deprecated forms of indefinite arguments
+ ("-Wdeprecated-non-prototype"). On the default configuration, it causes a
+ build failure (unless "--disable-werror" is specified).
+
+ This commit replaces () with (void) to avoid this warning.
+
+2022-10-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use ssh -t in remote-*.exp
+ When running test-case gdb.server/multi-ui-errors.exp on target board
+ remote-gdbserver-on-localhost.exp, I run into:
+ ...
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
+ continue^M
+ Continuing.^M
+ PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
+ Remote debugging from host ::1, port 35466^M
+ FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running
+ ...
+
+ The problem is that the target board uses ssh -T, which fails to guarantee
+ that output from the inferior will be available.
+
+ Fix this by copying proc ${board}_spawn from local-remote-host.exp, which
+ ensures using ssh -t. [ It would be nice to define an ssh base board to
+ get rid of the copies, but I'm not addressing that in this commit. ]
+
+ Likewise for target board remote-stdio-gdbserver.exp.
+
+ Tested on x86_64-linux.
+
+2022-10-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp with local-remote-host-notty
+ With test-case gdb.server/multi-ui-errors.exp and host board
+ local-remote-host-notty, I run into:
+ ...
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
+ Executing on target: kill -9 29666 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 29666^M
+ echo^M
+ Remote connection closed^M
+ (gdb) (gdb) FAIL: gdb.server/multi-ui-errors.exp: \
+ main UI, prompt after gdbserver dies (timeout)
+ ...
+
+ In contrast, with local-remote-host (so, everything the same but editing off):
+ ...
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
+ Executing on target: kill -9 31245 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 31245^M
+ Remote connection closed^M
+ (gdb) echo^M
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: main UI, prompt after gdbserver dies
+ ...
+
+ The test-case issues a kill, which results in a "Remote connection closed"
+ message and a prompt.
+
+ The problem is that the prompt is not consumed, so the subsequent echo may be
+ issued before that prompt, which causes a mismatch when matching the result
+ of the echo.
+
+ Fix this by consuming the "Remote connection closed" message and prompt.
+
+ Tested on x86_64-linux.
+
+2022-10-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Consume output asap in gdb.server/multi-ui-errors.exp
+ With test-case gdb.server/multi-ui-errors.exp we see:
+ ...
+ (gdb) PASS: multi-ui-errors.exp: main UI, prompt after gdbserver dies
+ continue^M
+ Continuing.^M
+ echo^M
+ (gdb) PASS: multi-ui-errors.exp: extra UI, prompt after gdbserver dies
+ ...
+
+ The continue is issued earlier in the test-case, but the output has not been
+ consumed, which makes it show up much later.
+
+ Consume the continue output asap, to make it clear when the continue is issued:
+ ...
+ (gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
+ continue^M
+ Continuing.^M
+ PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
+ ...
+
+ Tested on x86_64-linux.
+
+2022-10-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove REMOTE_PORTNUM in remote-stdio-gdbserver.exp
+ The usage for board remote-stdio-gdbserver.exp is advertised as:
+ ...
+ # bash$ make check RUNTESTFLAGS="--target_board=remote-stdio-gdbserver \
+ # REMOTE_USERNAME=... REMOTE_HOSTNAME=... REMOTE_PORTNUM=... \
+ # [REMOTE_TMPDIR=${remote_dir}] [GDBSERVER=${remote_gdbserver}]"
+ ...
+ but when adding REMOTE_PORTNUM=22, I run into:
+ ...
+ Running stop-reply-no-thread-multi.exp ...
+ ERROR: tcl error sourcing stop-reply-no-thread-multi.exp.
+ ERROR: couldn't execute "/usr/bin/ssh -p22": no such file or directory
+ while executing
+ "builtin_spawn {/usr/bin/ssh -p22} -l vries localhost {/usr/bin/gdbserver \
+ --once localhost:2346 \
+ /home/vries/gdb_versions/devel/build/gdb/testsuite/outp..."
+ ...
+
+ Fix this by simply removing REMOTE_PORTNUM.
+
+ Tested on x86_64-linux.
+
+2022-10-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim, sim/{m32c,ppc,rl78}: Use getopt_long
+ Because of a Libiberty hack, getopt on GNU libc (2.25 or earlier) is
+ currently unusable on sim, causing a regression on CentOS 7.
+
+ This is caused as follows:
+
+ 1. If HAVE_DECL_GETOPT is defined (getopt declaration with known prototype
+ is detected while configuration), a declaration of getopt in
+ "include/getopt.h" is suppressed.
+ The author started to define HAVE_DECL_GETOPT in sim with the commit
+ 340aa4f6872c ("sim: Check known getopt definition existence").
+ 2. GNU libc (2.25 or earlier)'s <unistd.h> includes <getopt.h> with a
+ special purpose macro defined to declare only getopt function but due
+ to include path (not tested while configuration), it causes <unistd.h>
+ to include Libiberty's "include/getopt.h".
+ 3. If both 1. and 2. are satisfied, despite that <unistd.h> tries to
+ declare getopt by including <getopt.h>, "include/getopt.h" does not do
+ so, causing getopt function undeclared.
+
+ Getting rid of "include/getopt.h" (e.g. renaming this header file) is the
+ best solution to avoid hacking but as a short-term solution, this commit
+ replaces getopt with getopt_long under sim/.
+
+2022-10-29 Alan Modra <amodra@gmail.com>
+
+ pef: sanity check before malloc
+ And do the sanity check in a way that can't overflow.
+
+ * pef.c (bfd_pef_parse_function_stubs): Sanity check header
+ imported_library_count and total_imported_symbol_count before
+ allocating memory.
+
+2022-10-29 Alan Modra <amodra@gmail.com>
+
+ Fix small objcopy memory leak
+ * objcopy.c (copy_archive): Free l->name.
+
+2022-10-29 Alan Modra <amodra@gmail.com>
+
+ NULL dereference read in som_write_object_contents
+ objcopy copy_object may omit the call to bfd_copy_private_bfd_data for
+ various conditions deemed non-fatal, in which case obj_som_exec_data
+ will be NULL for the output file.
+
+ * som.c (som_finish_writing): Don't dereference NULL
+ obj_som_exec_data.
+
+2022-10-29 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Always generate mapping symbols at the start of the sections.
+ Before figuring out the suppress rule of mapping symbol with architecture
+ (changed back to $x), always generate them at the start of the sections.
+
+ gas/
+ * config/tc-riscv.c (need_arch_map_symbol): Removed.
+ (riscv_mapping_state): Updated.
+ (riscv_check_mapping_symbols): Updated.
+ * testsuite/gas/riscv/mapping-non-arch.d: Removed.
+ * testsuite/gas/riscv/mapping-non-arch.s: Likewise.
+
+2022-10-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-28 Palmer Dabbelt <palmer@rivosinc.com>
+
+ gas: NEWS: Note support for RISC-V Zawrs
+ This has been supported since eb668e50036 ("RISC-V: Add Zawrs ISA
+ extension support").
+
+ gas: NEWS: Add a missing newline
+
+2022-10-28 Tom Tromey <tom@tromey.com>
+
+ Convert compunit_language to a method
+ This changes compunit_language to be a method on compunit_symtab.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Improve "bits undefined" diagnostics
+ This commit improves internal error message
+ "internal: bad RISC-V opcode (bits 0x%lx undefined): %s %s"
+ to display actual unused bits (excluding non-instruction bits).
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Exclude non-
+ instruction bits from displaying internal diagnostics.
+ Change error message slightly.
+
+2022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fallback for instructions longer than 64b
+ We don't support instructions longer than 64-bits yet. Still, we can
+ modify validate_riscv_insn function to prevent unexpected behavior by
+ limiting the "length" of an instruction to 64-bit (or less).
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Fix function
+ description comment based on current spec. Limit instruction
+ length up to 64-bit for now. Make sure that required_bits does
+ not corrupt even if unsigned long long is longer than 64-bit.
+
+2022-10-28 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V/gas: fix build with certain gcc versions
+ Some versions of gcc warn by default about shadowed outer-scope
+ declarations. This affects frag_align_code, which is declared in
+ frags.h. Rename the offending function parameter. While there also
+ switch to using true/false at the function call sites.
+
+2022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix build failure for -Werror=maybe-uninitialized
+ Commit 40f1a1a4564b ("RISC-V: Output mapping symbols with ISA string.")
+ caused a build failure on GCC 12 as follows:
+
+ make[3]: Entering directory '$(builddir)/gas'
+ CC config/tc-riscv.o
+ In file included from $(srcdir)/gas/config/tc-riscv.c:23:
+ $(srcdir)/gas/as.h: In function ‘make_mapping_symbol’:
+ $(srcdir)/gas/as.h:123:15: error: ‘buff’ may be used uninitialized [-Werror=maybe-uninitialized]
+ 123 | #define xfree free
+ | ^~~~
+ $(srcdir)/gas/config/tc-riscv.c:487:9: note: ‘buff’ was declared here
+ 487 | char *buff;
+ | ^~~~
+ cc1: all warnings being treated as errors
+ make[3]: *** [Makefile:1425: config/tc-riscv.o] Error 1
+
+ This is caused by a false positive of "maybe uninitialized" variable
+ detection (-Wmaybe-uninitialized). To avoid this error, this commit
+ initializes the local variable buff to NULL first in all cases.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (make_mapping_symbol): Initialize variable
+ buff with NULL to avoid build failure caused by a GCC's false
+ positive of maybe uninitialized variable detection.
+
+2022-10-28 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, btrace: fix family and model computation
+ In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu
+ structure given to the libipt btrace decoder.
+
+ We only consider the extended model field for family 0x6 and forget about
+ family 0xf and we don't consider the extended family field. Fix it.
+
+2022-10-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ include: Define macro to ignore -Wdeprecated-declarations on GCC
+ "-Wdeprecated-declarations" warning option can be helpful to track
+ deprecated function delarations but sometimes we need to disable this
+ warning for a good reason.
+
+ DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS is an existing macro but only
+ defined on Clang. Since "-Wdeprecated-declarations" is also available on
+ GCC (>= 3.4.0), this commit adds equivalent definition as Clang.
+
+ __GNUC__ and __GNUC_MINOR__ are not checked because this header file seems
+ to assume GCC >= 4.6 (with "GCC diagnostic push/pop").
+
+ include/ChangeLog:
+
+ * diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS):
+ Define also on GCC.
+
+2022-10-28 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Output mapping symbols with ISA string.
+ RISC-V Psabi pr196,
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/196
+
+ bfd/
+ * elfxx-riscv.c (riscv_release_subset_list): Free arch_str if needed.
+ (riscv_copy_subset_list): Copy arch_str as well.
+ * elfxx-riscv.h (riscv_subset_list_t): Store arch_str for each subset list.
+ gas/
+ * config/tc-riscv.c (riscv_reset_subsets_list_arch_str): Update the
+ architecture string in the subset_list.
+ (riscv_set_arch): Call riscv_reset_subsets_list_arch_str after parsing new
+ architecture string.
+ (s_riscv_option): Likewise.
+ (need_arch_map_symbol): New boolean, used to indicate if .option
+ directives do affect instructions.
+ (make_mapping_symbol): New boolean parameter reset_seg_arch_str. Need to
+ generate $x+arch for MAP_INSN, and then store it into tc_segment_info_data
+ if reset_seg_arch_str is true.
+ (riscv_mapping_state): Decide if we need to add $x+arch for MAP_INSN. For
+ now, only add $x+arch if the architecture strings in subset list and segment
+ are different. Besides, always add $x+arch at the start of section, and do
+ not add $x+arch for code alignment, since rvc for alignment can be judged
+ from addend of R_RISCV_ALIGN.
+ (riscv_remove_mapping_symbol): If current and previous mapping symbol have
+ same value, then remove the current $x only if the previous is $x+arch;
+ Otherwise, always remove previous.
+ (riscv_add_odd_padding_symbol): Updated.
+ (riscv_check_mapping_symbols): Don't need to add any $x+arch if
+ need_arch_map_symbol is false, so changed them to $x.
+ (riscv_frag_align_code): Updated since riscv_mapping_state is changed.
+ (riscv_init_frag): Likewise.
+ (s_riscv_insn): Likewise.
+ (riscv_elf_final_processing): Call riscv_release_subset_list to release
+ subset_list of riscv_rps_as, rather than only release arch_str in the
+ riscv_write_out_attrs.
+ (riscv_write_out_attrs): No need to call riscv_arch_str, just get arch_str
+ from subset_list of riscv_rps_as.
+ * config/tc-riscv.h (riscv_segment_info_type): Record current $x+arch mapping
+ symbol of each segment.
+ * testsuite/gas/riscv/mapping-0*: Merged and replaced by mapping.s.
+ * testsuite/gas/riscv/mapping.s: New testcase, to test most of the cases in
+ one file.
+ * testsuite/gas/riscv/mapping-symbols.d: Likewise.
+ * testsuite/gas/riscv/mapping-dis.d: Likewise.
+ * testsuite/gas/riscv/mapping-non-arch.s: New testcase for the case that
+ does need any $x+arch.
+ * testsuite/gas/riscv/mapping-non-arch.d: Likewise.
+ * testsuite/gas/riscv/option-arch-01a.d: Updated.
+ opcodes/
+ * riscv-dis.c (riscv_disassemble_insn): Set riscv_fpr_names back to
+ riscv_fpr_names_abi or riscv_fpr_names_numeric when zfinx is disabled
+ for some specfic code region.
+ (riscv_get_map_state): Recognized mapping symbols $x+arch, and then reset
+ the architecture string once the ISA is different.
+
+2022-10-28 Lifang Xia <lifang_xia@linux.alibaba.com>
+
+ binutils: Update my e-mail and Yunhai's e-mail
+ binutils/
+ * MAINTAINERS(C-SKY): update e-mails of Lifang & Yunhai.
+
+2022-10-28 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
+ gas/
+ * config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
+ * testsuite/gas/ppc/rfc02658.s: New test.
+ * testsuite/gas/ppc/rfc02658.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+ opcodes/
+ * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
+ (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
+ dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
+ dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
+ dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
+ pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
+ pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
+ pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
+
+2022-10-28 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Add support for RFC02653 - Dense Math Facility
+ gas/
+ * config/tc-ppc.c (pre_defined_registers): Add dense math registers.
+ (md_assemble): Check dmr specified in correct operand.
+ * testsuite/gas/ppc/outerprod.s <dmsetaccz, dmxvbf16ger2,
+ dmxvbf16ger2nn, dmxvbf16ger2np, dmxvbf16ger2pn, dmxvbf16ger2pp,
+ dmxvf16ger2, dmxvf16ger2nn, dmxvf16ger2np, dmxvf16ger2pn, dmxvf16ger2pp,
+ dmxvf32ger, dmxvf32gernn, dmxvf32gernp, dmxvf32gerpn, dmxvf32gerpp,
+ dmxvf64ger, dmxvf64gernn, dmxvf64gernp, dmxvf64gerpn, dmxvf64gerpp,
+ dmxvi16ger2, dmxvi16ger2pp, dmxvi16ger2s, dmxvi16ger2spp, dmxvi4ger8,
+ dmxvi4ger8pp, dmxvi8ger4, dmxvi8ger4pp, dmxvi8ger4spp, dmxxmfacc,
+ dmxxmtacc, pmdmxvbf16ger2, pmdmxvbf16ger2nn, pmdmxvbf16ger2np,
+ pmdmxvbf16ger2pn, pmdmxvbf16ger2pp, pmdmxvf16ger2, pmdmxvf16ger2nn,
+ pmdmxvf16ger2np, pmdmxvf16ger2pn, pmdmxvf16ger2pp, pmdmxvf32ger,
+ pmdmxvf32gernn, pmdmxvf32gernp, pmdmxvf32gerpn, pmdmxvf32gerpp,
+ pmdmxvf64ger, pmdmxvf64gernn, pmdmxvf64gernp, pmdmxvf64gerpn,
+ pmdmxvf64gerpp, pmdmxvi16ger2, pmdmxvi16ger2pp, pmdmxvi16ger2s,
+ pmdmxvi16ger2spp, pmdmxvi4ger8, pmdmxvi4ger8pp, pmdmxvi8ger4,
+ pmdmxvi8ger4pp, pmdmxvi8ger4spp>: Add new tests.
+ * testsuite/gas/ppc/outerprod.d: Likewise.
+ * testsuite/gas/ppc/rfc02653.s: New test.
+ * testsuite/gas/ppc/rfc02653.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+ include/
+ * opcode/ppc.h (PPC_OPERAND_DMR): Define. Renumber following
+ PPC_OPERAND defines.
+
+ opcodes/
+ * ppc-dis.c (print_insn_powerpc): Prepend 'dm' when printing DMR regs.
+ * ppc-opc.c (insert_p2, (extract_p2, (insert_xa5, (extract_xa5,
+ insert_xb5, (extract_xb5): New functions.
+ (insert_xa6a, extract_xa6a, insert_xb6a, extract_xb6a): Disallow
+ operand overlap only on Power10.
+ (DMR, DMRAB, P1, P2, XA5p, XB5p, XDMR_MASK, XDMRDMR_MASK, XX2ACC_MASK,
+ XX2DMR_MASK, XX3DMR_MASK): New defines.
+ (powerpc_opcodes): Add dmmr, dmsetaccz, dmsetdmrz, dmxor, dmxvbf16ger2,
+ dmxvbf16ger2nn, dmxvbf16ger2np, dmxvbf16ger2pn, dmxvbf16ger2pp,
+ dmxvf16ger2, dmxvf16ger2nn, dmxvf16ger2np, dmxvf16ger2pn, dmxvf16ger2pp,
+ dmxvf32ger, dmxvf32gernn, dmxvf32gernp, dmxvf32gerpn, dmxvf32gerpp,
+ dmxvf64ger, dmxvf64gernn, dmxvf64gernp, dmxvf64gerpn, dmxvf64gerpp,
+ dmxvi16ger2, dmxvi16ger2pp, dmxvi16ger2s, dmxvi16ger2spp, dmxvi4ger8,
+ dmxvi4ger8pp, dmxvi8ger4, dmxvi8ger4pp, dmxvi8ger4spp, dmxxextfdmr256,
+ dmxxextfdmr512, dmxxinstdmr256, dmxxinstdmr512, dmxxmfacc, dmxxmtacc,
+ pmdmxvbf16ger2, pmdmxvbf16ger2nn, pmdmxvbf16ger2np, pmdmxvbf16ger2pn,
+ pmdmxvbf16ger2pp, pmdmxvf16ger2, pmdmxvf16ger2nn, pmdmxvf16ger2np,
+ pmdmxvf16ger2pn, pmdmxvf16ger2pp, pmdmxvf32ger, pmdmxvf32gernn,
+ pmdmxvf32gernp, pmdmxvf32gerpn, pmdmxvf32gerpp, pmdmxvf64ger,
+ pmdmxvf64gernn, pmdmxvf64gernp, pmdmxvf64gerpn, pmdmxvf64gerpp,
+ pmdmxvi16ger2, pmdmxvi16ger2pp, pmdmxvi16ger2s, pmdmxvi16ger2spp,
+ pmdmxvi4ger8, pmdmxvi4ger8pp, pmdmxvi8ger4, pmdmxvi8ger4pp,
+ pmdmxvi8ger4spp.
+
+2022-10-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-27 Andrew Burgess <aburgess@redhat.com>
+
+ sim/cgen: initialize variable at creation in engine_run_n
+ Zero initialize engine_fns entirely at creation, then override those
+ fields we intend to use, rather than zero just initializing the unused
+ fields later on.
+
+ There should be no user visible changes after this commit.
+
+2022-10-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove address from test names
+ I noticed an address in a test name:
+ ...
+ PASS: gdb.base/eh_return.exp: gdb_breakpoint: \
+ set breakpoint at *0x000000000040071b
+ ...
+
+ Stabilize the test name by using "set breakpoint on address" instead.
+
+ Likewise in two other test-cases.
+
+ Tested on x86_64-linux.
+
+2022-10-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Disable styling in host board local-remote-host-native.exp
+ Propagate fix from commit 17c68d98f74 ("[gdb/testsuite] Disable styling in host
+ board local-remote-host.exp") to local-remote-host-native.exp.
+
+ Tested on x86_64-linux.
+
+2022-10-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host
+ I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
+ local-remote-host.exp takes about 44 seconds.
+
+ I found two silent timeouts responsible for this.
+
+ The first is in mi_gdb_exit, where we have:
+ ...
+ if { [is_remote host] && [board_info host exists fileid] } {
+ send_gdb "999-gdb-exit\n"
+ gdb_expect 10 {
+ -re "y or n" {
+ send_gdb "y\n"
+ exp_continue
+ }
+ -re "Undefined command.*$gdb_prompt $" {
+ send_gdb "quit\n"
+ exp_continue
+ }
+ -re "DOSEXIT code" { }
+ }
+ }
+ ...
+ so in gdb.log we see:
+ ...
+ 999-gdb-exit^M
+ 999^exit^M
+ =thread-exited,id="1",group-id="i1"^M
+ =thread-group-exited,id="i1"^M
+ ...
+ after which expect just waits for the timeout.
+
+ Fix this by adding a gdb_expect clause to parse the exit:
+ ...
+ -re "\r\n999\\^exit\r\n" { }
+ ...
+
+ Note that we're not parsing the thread-exited/thread-group-exited messages, because
+ they may not be present:
+ ...
+ $ gdb -i=mi
+ =thread-group-added,id="i1"
+ (gdb)
+ 999-gdb-exit
+ 999^exit
+ $
+ ...
+
+ After fixing that, we have:
+ ...
+ (gdb) ^M
+ saw mi error
+ PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
+ force-fail=1: run failure detected
+ quit^M
+ &"quit\n"^M
+ ...
+
+ What seems to be happening is that default_gdb_exit sends a cli interpreter
+ quit command to an mi interpreter, after which again expect just waits for the
+ timeout.
+
+ Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
+ gdb.mi/*.exp test-cases.
+
+ After these two fixes, the test-case takes about 4 seconds.
+
+ Tested on x86_64-linux.
+
+2022-10-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use remote_exec chmod instead of remote_spawn
+ I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into:
+ ...
+ (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
+ action=delete: setup: adjust sysroot
+ builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M
+ /bin/bash: connect-with-no-symbol-file: Permission denied^M
+ /bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \
+ Permission denied^M
+ During startup program exited with code 126.^M
+ Exiting^M
+ target remote localhost:2385^M
+ `connect-with-no-symbol-file' has disappeared; keeping its symbols.^M
+ localhost:2385: Connection timed out.^M
+ (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
+ action=delete: connection to GDBserver succeeded
+ ...
+
+ The expected series of events is (skipping disconnect and detach as I don't
+ think they're relevant to the problem):
+ - enter scenario "permission"
+ - cp $exec.bak $exec
+ - gdbserver start with $exec
+ - chmod 000 $exec
+ - connect to gdbserver
+ - enter scenario "delete"
+ - cp $exec.bak $exec
+ - gdbserver start with $exec
+ - delete $exec
+ - connect to gdbserver
+
+ The problem is that the chmod is executed using remote_spawn:
+ ...
+ } elseif { $action == "permission" } {
+ remote_spawn target "chmod 000 $target_exec"
+ }
+ ...
+ without waiting on the resulting spawn id, so we're not sure when the
+ chmod will have effect.
+
+ The FAIL we're seeing above is explained by the chmod having effect during the
+ delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver
+ start with $exec".
+
+ Fix this by using remote_exec instead.
+
+ Likewise, fix a similar case in gdb.mi/mi-exec-run.exp.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29726
+
+2022-10-27 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Fix build failures for -Werror=sign-compare.
+ elfnn-riscv.c: In function ‘riscv_relax_resolve_delete_relocs’:
+ elfnn-riscv.c:4256:30: error: operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand [-Werror=sign-compare]
+
+ So make the operands unsigned could resolve problem.
+
+ bfd/
+ * elfnn-riscv.c (riscv_relax_resolve_delete_relocs): Fixed build
+ failures for -Werror=sign-compare.
+
+2022-10-27 Alan Modra <amodra@gmail.com>
+
+ Fuzzed files in archives
+ Given a fuzzed object file in an archive with section size exceeding
+ file size, objcopy will report an error like "section size (0xfeffffff
+ bytes) is larger than file size (0x17a bytes)" but will create a copy
+ of the object laid out for the large section. That means a large
+ temporary file on disk that is read back and written to the output
+ archive, which can take a while. The output archive is then deleted
+ due to the error. Avoid some of this silliness.
+
+ * objcopy.c (copy_section): If section contents cannot be read
+ set output section size to zero.
+
+2022-10-27 Martin Liska <mliska@suse.cz>
+
+ tests: use canonical option name
+ ld/ChangeLog:
+
+ * testsuite/ld-size/size.exp: Use canonical option name.
+
+2022-10-27 Alan Modra <amodra@gmail.com>
+
+ re: Support Intel AMX-FP16
+ Fix these fails due to the target padding out sections with nops.
+ x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns
+ x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns (Intel disassembly)
+
+ * testsuite/gas/i386/x86-64-amx-fp16-intel.d: Accept trailing nops.
+ * testsuite/gas/i386/x86-64-amx-fp16.d: Likewise.
+
+2022-10-27 Alan Modra <amodra@gmail.com>
+
+ Re: ld/testsuite: adjust ld-arm to run shared tests only when supported
+ commit 67527cffcd enabled previously disabled tests unresolved-1-dyn,
+ thumb-plt and thumb-plt-got for nacl. The first fails due to trying
+ to link against mixed-lib.so which isn't compiled for nacl. The last
+ two fail with
+ objdump: tmpdir/dump(.rel.plt): relocation 0 has invalid symbol index 14885104
+ and
+ readelf: Error: bad symbol index: 00e320f0 in reloc
+
+ Relocation section '.rel.plt' at offset 0x128 contains 1 entry:
+ Offset Info Type Sym. Value Symbol's Name
+ e320f000 e320f000 R_ARM_NONE
+
+ * testsuite/ld-arm/arm-elf.exp: Disable unresolved-1-dyn,
+ thumb-plt and thumb-plt-got for nacl.
+
+2022-10-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix gdb.guile/scm-parameter.exp "wrong type argument" test pattern for Guile >= 2.2
+ Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value
+ is boolean"), I see:
+
+ FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited)
+ FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited)
+
+ This comes from the fact that GDB outputs this:
+
+ ERROR: In procedure set-parameter-value!:
+ In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
+ Error while executing Scheme code.
+
+ while the test expects an additional "ERROR:" on the second line,
+ something like this:
+
+ ERROR: In procedure set-parameter-value!:
+ ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
+ Error while executing Scheme code.
+
+ Guile 2.0 outputs the `ERROR:` on the second line, while later versions
+ do not. Change the pattern to accept both outputs. This is similar to
+ commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
+ with guile 3.0").
+
+ Change-Id: I9dc45e7492a4f08340cad974610242ed689de959
+
+2022-10-26 Luis Machado <luis.machado@arm.com>
+
+ gdb/arm: Fix M-profile EXC_RETURN
+ Arm v8-M Architecture Reference Manual,
+ D1.2.95 EXC_RETURN, Exception Return Payload
+ describes ES bit:
+
+ "ES, bit [0]
+ Exception Secure. The security domain the exception was taken to.
+ The possible values of this bit are:
+ 0 Non-secure.
+ 1 Secure"
+
+ arm-tdep.c:3443, arm_m_exception_cache () function tests this bit:
+
+ exception_domain_is_secure = (bit (lr, 0) == 0);
+
+ The test is negated!
+
+ Later on line 3553, the condition evaluates if an additional state
+ context is stacked:
+
+ /* With the Security extension, the hardware saves R4..R11 too. */
+ if (tdep->have_sec_ext && secure_stack_used
+ && (!default_callee_register_stacking || exception_domain_is_secure))
+
+ RM, B3.19 Exception entry, context stacking
+ reads:
+ RPLHM "In a PE with the Security Extension, on taking an exception,
+ the PE hardware:
+ ...
+ 2. If exception entry requires a transition from Secure state to
+ Non-secure state, the PE hardware extends the stack frame and also
+ saves additional state context."
+
+ So we should test for !exception_domain_is_secure instead of non-negated
+ value!
+ These two bugs compensate each other so unstacking works correctly.
+
+ But another test of exception_domain_is_secure (negated due to the
+ first bug) prevents arm_unwind_secure_frames to work as expected:
+
+ /* Unwinding from non-secure to secure can trip security
+ measures. In order to avoid the debugger being
+ intrusive, rely on the user to configure the requested
+ mode. */
+ if (secure_stack_used && !exception_domain_is_secure
+ && !arm_unwind_secure_frames)
+
+ Test with GNU gdb (GDB) 13.0.50.20221016-git.
+ Stopped in a non-secure handler:
+
+ (gdb) set arm unwind-secure-frames 0
+ (gdb) bt
+ #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490
+ #1 0x0804081c in SysTick_Handler ()
+ at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134
+ #2 <signal handler called>
+ #3 HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192)
+ at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386
+ #4 0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86
+ #5 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+
+ The frames #3 and #4 are secure. backtrace should stop before #3.
+
+ Stopped in a secure handler:
+
+ (gdb) bt
+ #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
+ #1 0x0c000b6a in SysTick_Handler ()
+ at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
+ warning: Non-secure to secure stack unwinding disabled.
+ #2 <signal handler called>
+
+ The exception from secure to secure erroneously stops unwinding. It should
+ continue as far as the security unlimited backtrace:
+
+ (gdb) set arm unwind-secure-frames 1
+ (gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames
+ 0x0c0008e6 425 if (SecureTimingDelay != 0U)
+ (gdb) bt
+ #0 0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
+ #1 0x0c000b6a in SysTick_Handler ()
+ at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
+ #2 <signal handler called>
+ #3 0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88
+ #4 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
+
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+
+ Set exception_domain_is_secure to the value expected by its name.
+ Fix exception_domain_is_secure usage in the additional state context
+ stacking condition.
+
+2022-10-26 Luis Machado <luis.machado@arm.com>
+
+ gdb/arm: fix IPSR field test in arm_m_exception_cache ()
+ Arm v8-M Architecture Reference Manual,
+ D1.2.141 IPSR, Interrupt Program Status Register reads
+ "Exception, bits [8:0]"
+
+ 9 bits, not 8! It is uncommon but true!
+
+2022-10-26 Luis Machado <luis.machado@arm.com>
+
+ gdb/arm: Terminate frame unwinding in M-profile lockup
+ In the lockup state the PC value of the the outer frame is irreversibly
+ lost. The other registers are intact so LR likely contains
+ PC of some frame next to the outer one, but we cannot analyze
+ the nearest outer frame without knowing its PC
+ therefore we do not know SP fixup for this frame.
+
+ The frame unwinder possibly gets mad due to the wrong SP value.
+ To prevent problems terminate unwinding if PC contains the magic
+ value of the lockup state.
+
+ Example session wihtout this change,
+ Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git:
+ ----------------
+ (gdb) c
+ Continuing.
+
+ Program received signal SIGINT, Interrupt.
+ 0xeffffffe in ?? ()
+ (gdb) bt
+ #0 0xeffffffe in ?? ()
+ #1 0x0c000a9c in HardFault_Handler ()
+ at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99
+ #2 0x2002ffd8 in ?? ()
+ Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+ (gdb)
+ ----------------
+ The frame #1 is at correct PC taken from LR, #2 is a total nonsense.
+
+ With the change:
+ ----------------
+ (gdb) c
+ Continuing.
+
+ Program received signal SIGINT, Interrupt.
+ warning: ARM M in lockup state, stack unwinding terminated.
+ <signal handler called>
+ (gdb) bt
+ #0 <signal handler called>
+ (gdb)
+ ----------------
+
+ There is a visible drawback of emitting a warning in a cache buildnig routine
+ as introduced in Torbjörn SVENSSON's
+ [PATCH v4] gdb/arm: Stop unwinding on error, but do not assert
+ The warning is printed just once and not repeated on each backtrace command.
+
+2022-10-26 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: copyright: make file header scan a bit more pythonic
+ Should be functionally the same, but uses more pythonic idioms to get
+ fewer lines of code, and to make sure to not leak open file handles.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-26 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: make copyright.py interface a bit nicer
+ This way people can run `./copyright.py --help` and get some info as
+ to what this does without it going and modifying the tree.
+
+ sim: testsuite: improve parallel test processing
+ The current logic limits itself to a maxdepth of 4 when looking for
+ results. This wouldn't be a problem if cris didn't have a testsuite
+ at a depth of 5 which we end up ignoring when summarizing. Rather
+ than bump the number from 4 to 5, rework the code so that we gather
+ the exact set of tests that we tried to run.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ buffer overflow in _bfd_XX_print_ce_compressed_pdata
+ More fuzzed fun.
+
+ * peXXigen.c (_bfd_XX_print_ce_compressed_pdata): Use smaller of
+ virt_size and bfd section size as limit of function table.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ Correct ELF reloc size sanity check
+ The external reloc size check was wrong. Here asect is the code/data
+ section, not the reloc section. So using this_hdr gave the size of
+ the code/data section.
+
+ * elf.c (_bfd_elf_get_reloc_upper_bound): Properly get
+ external size from reloc headers.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ segfault in objdump.c reloc_at
+ bfd_canonicalize_reloc returns -1L on errors.
+
+ * objdump.c (load_specific_debug_section): Properly handle
+ error return from bfd_canonicalize_reloc.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ som.c reloc sanity checking
+ This patch checks that relocations emitted in som_write_fixups have
+ offsets that are monotonic and within a section. To do that properly
+ using bfd_reloc_offset_in_range it is necessary to set the reloc howto
+ size field, which isn't used otherwise by the som backend. Note that
+ the sizes used are not exactly those in the old sizing switch
+ statement deleted from som_write_fixups, but all relocs handled by the
+ main switch statement there get the same size. Most unhandled relocs
+ get a zero size (exceptions being R_RELOCATION, R_SPACE_REF,
+ R_MILLI_REL, R_BREAKPOINT which all involve writing one word according
+ to my SOM reference). I figure it doesn't matter since any unhandled
+ reloc is converted to 0xff R_RESERVED, and a default of zero is better
+ for a "don't know" reloc.
+
+ Besides tidying the code, stringizing name from type in SOM_HOWTO
+ fixes R_REPEATED_INIT name.
+
+ * som.c (SOM_HOWTO): Add SIZE arg, delete NAME. Stringize type
+ to name.
+ (som_hppa_howto_table): Update with sizes.
+ (som_write_fixups): Delete sizing switch statement. Sanity check
+ bfd_reloc address against subsection size.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ som.c buffer overflow
+ Fuzzed object files can put random values in bfd_reloc->address,
+ leading to large som_reloc_skip output.
+
+ * som.c (som_write_fixups): Allow for maximal som_reloc_skip.
+
+2022-10-26 Alan Modra <amodra@gmail.com>
+
+ PR29720, objdump -S crashes if build-id is missing
+ PR 29720
+ * objdump.c (slurp_file): Don't call debuginfod_find_source
+ when build_id is NULL.
+
+2022-10-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove spurious spaces after frame_info_ptr
+ Fix some whitespace issues introduced with the frame_info_ptr patch.
+
+ Change-Id: I158d30d8108c97564276c647fc98283ff7b12163
+
+2022-10-25 Michael Matz <matz@suse.de>
+
+ x86-64: Use only one default max-page-size
+ On x86-64 the default ELF_MAXPAGESIZE depends on a configure
+ option (--disable-separate-code). Since 9833b775
+ ("PR28824, relro security issues") we use max-page-size for relro
+ alignment (with a short interval, from 31b4d3a ("PR28824, relro
+ security issues, x86 keep COMMONPAGESIZE relro") to its revert
+ a1faa5ea, where x86-64 only used COMMONPAGESIZE as relro alignment
+ target).
+
+ But that means that a linker configured with --disable-separate-code
+ behaves different from one configured with --enable-separate-code
+ (the default), _even if using "-z {no,}separate-code" option to use
+ the non-configured behaviour_ . In particular it means that when
+ configuring with --disable-separate-code the linker will produce
+ binaries aligned to 2MB pages on disk, and hence generate 2MB
+ executables for a hello world (and even 6MB when linked with
+ "-z separate-code").
+
+ Generally we can't have constants that ultimately land in static
+ variables be depending on configure options if those only influence
+ behaviour that is overridable by command line options.
+
+ So, do away with that, make the default MAXPAGESIZE be 4k (as is default
+ for most x86-64 configs anyway, as most people won't configure with
+ --disable-separate-code). If people need more they can use the
+ "-z max-page-size" (with would have been required right now for a
+ default configure binutils).
+
+ bfd/
+ * elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on
+ DEFAULT_LD_Z_SEPARATE_CODE.
+
+2022-10-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: make sure to consume the prompt in gdb.base/unwind-on-each-insn.exp
+ This test fails quite reliably for me when ran as:
+
+ $ taskset -c 1 make check TESTS="gdb.base/unwind-on-each-insn.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+
+ or more simply:
+
+ $ make check-read1 TESTS="gdb.base/unwind-on-each-insn.exp"
+
+ The problem is that the gdb_test_multiple call that grabs the frame id
+ from "maint print frame-id" does not consume the prompt. Well, it does
+ sometimes due to the trailing .*, but not always. If the prompt is not
+ consumed, the tests that follow get confused:
+
+ FAIL: gdb.base/unwind-on-each-insn.exp: gdb_breakpoint: set breakpoint at *foo
+ FAIL: gdb.base/unwind-on-each-insn.exp: disassemble foo
+ FAIL: gdb.base/unwind-on-each-insn.exp: get $sp and frame base in foo: get hexadecimal valueof "$sp"
+ ... many more ...
+
+ Use -wrap to make gdb_test_multiple consume the prompt.
+
+ While at it, remove the bit that consumes the command name and do
+ exp_continue, it's not really necessary. And for consistency, do the
+ same changes to the gdb_test_multiple that consumes the stack address,
+ although that one was fine, it did consume the prompt explicitly.
+
+ Change-Id: I2b7328c8844c7e98921ea494c4c05107162619fc
+ Reviewed-By: Bruno Larsen <blarsen@redhat.com>
+
+2022-10-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle missing .note.GNU-stack
+ On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
+ some hardcoded assembly test-cases:
+ ...
+ Running gdb.dwarf2/fission-absolute-dwo.exp ...
+ gdb compile failed, ld: warning: fission-absolute-dwo.o: \
+ missing .note.GNU-stack section implies executable stack
+ ld: NOTE: This behaviour is deprecated and will be removed in a future \
+ version of the linker
+
+ === gdb Summary ===
+
+ # of untested testcases 1
+ ...
+
+ Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
+ proc Dwarf::assemble.
+
+ Fix the hard-coded test-cases using this command:
+ ...
+ $ for f in $(find gdb/testsuite/gdb.* -name *.S); do
+ if ! grep -q note.GNU-stack $f; then
+ echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
+ fi;
+ done
+ ...
+
+ Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.
+
+ The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08be
+ ("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
+ hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.
+
+ Note that dwarf assembly testcases use %progbits as decided by proc _section.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
+
+2022-10-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing skip_gdbserver_tests in gdb.multi/attach-no-multi-process.exp
+ I build gdb without gdbserver, and ran into:
+ ...
+ (gdb) PASS: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
+ switch to inferior 2
+ spawn of --once --multi localhost:2346 failed
+ ERROR: tcl error sourcing attach-no-multi-process.exp.
+ ERROR: tcl error code NONE
+ ERROR: Timeout waiting for gdbserver response.
+ ...
+
+ Add the missing skip_gdbserver_tests.
+
+ Tested on x86_64-linux.
+
+2022-10-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Rewrite RETHROW_ON_TARGET_CLOSE_ERROR into function
+ Recent commit b2829fcf9b5 ("[gdb] Fix rethrow exception slicing in
+ insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR.
+
+ I wrote this as a macro in order to have the rethrowing throw be part of the
+ same function as the catch, but as it turns out that's not necessary.
+
+ Rewrite into a function.
+
+ Tested on x86_64-linux.
+
+2022-10-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: internal_error -> internal_error_loc in gdb-gdb.gdb.in
+ Commit f34652de0b ("internal_error: remove need to pass
+ __FILE__/__LINE__") renamed the internal_error function to
+ internal_error_loc. Change gdb-gdb.gdb.in accordingly.
+
+ Change-Id: I876e1623607b6becf74ade53d102ead53a74ed86
+
+2022-10-25 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Should reset `again' flag for _bfd_riscv_relax_pc.
+ The R_RISCV_DELETE relocations are no longer deleted at another relax pass,
+ so we should reset 'again' flag to true for _bfd_riscv_relax_pc, while the
+ deleted bytes are marked as R_RISCV_DELETE.
+
+ bfd/
+ * elfnn-riscv.c (_bfd_riscv_relax_pc): Set `again' to true while the
+ deleted bytes are marked as R_RISCV_DELETE.
+
+2022-10-25 Patrick O'Neill <patrick@rivosinc.com>
+
+ RISC-V: Improve link time complexity.
+ The riscv port does deletion and symbol table update for each relocation
+ while relaxing, so we are moving section bytes and scanning symbol table once
+ for each relocation. Compared to microblaze port, they record the relaxation
+ changes into a table, then do the deletion and symbol table update once per
+ section, rather than per relocation. Therefore, they should have better link
+ time complexity than us.
+
+ To improve the link time complexity, this patch try to make the deletion in
+ linear time. Compared to record the relaxation changes into a table, we
+ replace the unused relocation with R_RISCV_DELETE for the deleted bytes, and
+ then resolve them at the end of the section. Assuming the number of
+ R_RISCV_DELETE is m, and the number of symbols is n, the total link complexity
+ should be O(m) for moving section bytes, and O(m*n^2) for symbol table update.
+ If we record the relaxation changes into the table, and then sort the symbol
+ table by values, then probably can reduce the time complexity to O(m*n*log(n))
+ for updating symbol table, but it doesn't seem worth it for now.
+
+ bfd/
+ * elfnn-riscv.c (_riscv_relax_delete_bytes): Renamed from
+ riscv_relax_delete_bytes, updated to reduce the tiem complexity to O(m)
+ for memmove.
+ (typedef relax_delete_t): Function pointer declaration of delete functions.
+ (riscv_relax_delete_bytes): Can choose to use _riscv_relax_delete_piecewise
+ or _riscv_relax_delete_immediate for deletion.
+ (_riscv_relax_delete_piecewise): Just mark the deleted bytes as R_RISCV_DELETE.
+ (_riscv_relax_delete_immediate): Delete some bytes from a section while
+ relaxing.
+ (riscv_relax_resolve_delete_relocs): Delete the bytes for R_RISCV_DELETE
+ relocations from a section, at the end of _bfd_riscv_relax_section.
+ (_bfd_riscv_relax_call): Mark deleted bytes as R_RISCV_DELETE by reusing
+ R_RISCV_RELAX.
+ (_bfd_riscv_relax_lui): Likewise, but reuse R_RISCV_HI20 for lui, and reuse
+ R_RISCV_RELAX for c.lui.
+ (_bfd_riscv_relax_tls_le): Likewise, but resue R_RISCV_TPREL_HI20 and
+ R_RISCV_TPREL_ADD.
+ (_bfd_riscv_relax_pc): Likewise, but resue R_RISCV_PCREL_HI20 for auipc.
+ (_bfd_riscv_relax_align): Updated, don't need to resue relocation since
+ calling _riscv_relax_delete_immediate.
+ (_bfd_riscv_relax_delete): Removed.
+ (_bfd_riscv_relax_section): Set riscv_relax_delete_bytes for each relax_func,
+ to delete bytes immediately or later. Call riscv_relax_resolve_delete_relocs
+ to delete bytes for DELETE relocations from a section.
+
+2022-10-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: reword description of DisassembleInfo.read_memory
+ While reading the documentation of DisassembleInfo.read_memory I
+ spotted the word 'available' in one sentence where it didn't make
+ sense.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/lm32: fix some missing function declaration warnings
+ In the lm32 simulator, I was seeing some warnings about missing
+ function declarations.
+
+ The lm32 simulator has a weird header structure, in order to pull in
+ the full cpu.h header we need to define WANT_CPU_LM32BF. This is done
+ in some files, but not in others. Critically, it's not done in some
+ files that then use functions declared in cpu.h
+
+ In this commit I added the missing #define so that the full cpu.h can
+ be included.
+
+ After doing this there are still a few functions that are used
+ undeclared, these functions appear to be missing any declarations at
+ all, so I've added some to cpu.h.
+
+ With this done all the warnings when compiling lm32 are resolved for
+ both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from
+ Makefile.in, this allows lm32 to build with -Werror.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/h8300: avoid self assignment
+ There are two places in the h8300 simulator where we assign a variable
+ to itself. Clang gives a warning for this, which is converted into an
+ error by -Werror.
+
+ Silence the warning by removing the self assignments. As these
+ assignments were in a complex if/then/else tree, rather than try to
+ adjust all the conditions, I've just replaced the self assignments
+ with a comment and an empty statement.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/aarch64: remove two unused functions
+ These functions are not used. Clang warns about the unused functions,
+ which is then converted into an error by -Werror.
+
+ Delete the unused functions.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: fix for operator precedence warning from clang
+ In the ppc simulator, clang was warning about some code like this:
+
+ busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2;
+
+ The warning was:
+
+ operator '?:' has lower precedence than '+'; '+' will be evaluated first
+
+ I suspect that this is not the original authors intention.
+ PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+'
+ first, the condition will always be non-zero, so true. The whole
+ expression could then be simplified to just '1', which doesn't make
+ much sense.
+
+ I suspect the answer the author was expecting was either 2 or 3. Why
+ they didn't just write:
+
+ busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3;
+
+ I have no clue, however, to keep the structure of the code unchanged,
+ I've updated things to:
+
+ busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2);
+
+ which silences the warning from clang, and is, I am guessing, what the
+ original author intended.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: initialize a memory buffer in all cases
+ In the ppc simulator's do_fstat function, which provides the fstat
+ call for the simulator, if the fstat is going to fail then we
+ currently write an uninitialized buffer into the simulated target.
+
+ In theory, I think this is fine, we also write the error status into
+ the simulated target, so, given that the fstat has failed, the target
+ shouldn't be relying on the buffer contents.
+
+ However, writing an uninitialized buffer means we might leak simulator
+ private data into the simulated target, which is probably a bad thing.
+ Plus it probably makes life easier if something consistent, like all
+ zeros, is written rather than random junk, which might look like a
+ successful call (except for the error code).
+
+ So, in this commit, I initialize the stat buffer to zero before
+ it is potentially used. If the stat call is not made then the buffer
+ will be left initialized as all zeros.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: don't try to print an uninitialized variable
+ The ppc simulator, in sim_create_inferior, tries to print the function
+ local entry_point variable before the variable is initialized.
+
+ In this commit, I defer the debug print line until the variable has
+ been initialized.
+
+2022-10-24 Andrew Burgess <aburgess@redhat.com>
+
+ sim/sh: use fabs instead of abs
+ The sh simulator incorrectly uses integer abs instead of the floating
+ point fabs on some floating point values, fixed in this commit.
+
+2022-10-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix rethrow exception slicing in insert_bp_location
+ The preferred way of rethrowing an exception is by using throw without
+ expression, because it avoids object slicing of the exception [1].
+
+ Fix this in insert_bp_location.
+
+ Tested on x86_64-linux.
+
+ [1] https://en.cppreference.com/w/cpp/language/throw
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-10-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix rethrow exception slicing in pretty_print_insn
+ The preferred way of rethrowing an exception is by using throw without
+ expression, because it avoids object slicing of the exception [1].
+
+ Fix this in gdb_pretty_print_disassembler::pretty_print_insn.
+
+ Tested on x86_64-linux.
+
+ [1] https://en.cppreference.com/w/cpp/language/throw
+
+ Approved-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-10-24 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: adjust ld-arm to run shared tests only when supported
+ If a custom arm-elf target is disabling the shared support, a lot of
+ failures are reported by the testsuite.
+ Moreover, some tests try to access libraries which have been explicitly
+ skipped earlier (eg mixed-lib.so).
+
+ ld/ChangeLog:
+
+ * testsuite/ld-arm/arm-elf.exp: Separate tests needing shared
+ lib support.
+
+2022-10-24 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: skip ld-elf/exclude when -shared is not supported
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/exclude.exp: Call check_shared_lib_support.
+ to skip for all targets without shared lib support.
+
+2022-10-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: consolidate VPCLMUL tests
+ There's little point in having Intel syntax disassembler tests when the
+ purpose of a test is assembler functionality: Drop all
+ *avx512*_vpclmulqdq-wig1-intel.
+
+ For *avx512*_vpclmulqdq-wig1 share source with *avx512*_vpclmulqdq.
+
+ Finally put in place similar tests for -mvexwig=1.
+
+2022-10-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: consolidate VAES tests
+ There's little point in having Intel syntax disassembler tests when the
+ purpose of a test is assembler functionality: Drop all
+ *avx512*_vaes-wig1-intel.
+
+ For *avx512*_vaes-wig1 share source with *avx512*_vaes. This in
+ particular makes sure that the 32-bit VL test actually tests any EVEX
+ encodings in the first place.
+
+ Finally put in place similar tests for -mvexwig=1.
+
+2022-10-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: emit {evex} prefix when disassembling ambiguous AVX512VL insns
+ When no AVX512-specific functionality is in use, the disassembly of
+ AVX512VL insns is indistinguishable from their AVX counterparts (if such
+ exist). Emit the {evex} pseudo-prefix in such cases.
+
+ Where applicable drop stray uses of PREFIX_OPCODE from table entries.
+
+2022-10-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add skip_python_tests in gdb.python/tui-window-names.exp
+ I did a gdb build without python support, and during testing ran into FAILs in
+ test-case gdb.python/tui-window-names.exp.
+
+ Fix this by adding the missing skip_python_test.
+
+ Tested on x86_64-linux.
+
+2022-10-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: update ignored .exp files [PR sim/29596]
+ Now that we run `check/foo.exp` instead of `check/./foo.exp`,
+ update the config/ & lib/ exceptions to cover both paths.
+
+ Bug: https://sourceware.org/PR29596
+
+2022-10-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: tweak parallel find invocation [PR sim/29596]
+ Make sure we invoke runtest with the same exp filenames when running in
+ parallel as it will find when run single threaded. When `runtest` finds
+ files itself, it will use paths like "aarch64/allinsn.exp". When we run
+ `find .` with the %p option, it produces "./aarch64/allinsn.exp". Switch
+ to %P to get "aarch64/allinsn.exp".
+
+ Bug: https://sourceware.org/PR29596
+
+2022-10-23 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips/ppc/riscv: re-add AC_CANONICAL_SYSTEM [PR sim/29439]
+ These configure scripts check $target and change behavior. They
+ shouldn't be doing that, but until we can rework the sim to change
+ behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to
+ these so that $target is correctly populated.
+
+ This was lost in the d3562f83a7b8a1ae6e333cd5561419d3da18fcb4
+ ("sim: unify toolchain probing logic") refactor as the logic was
+ hoisted up to the common code. But the fact the vars weren't
+ passed down to the sub-configure scripts was missed.
+
+ Bug: https://sourceware.org/PR29439
+
+2022-10-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: add max number of instructions check in gdb.base/unwind-on-each-insn.exp
+ This test sends my CI in an infinite loop of failures. We expect to
+ have a handful of iterations (5 on my development machine, where the
+ test passes fine)but the log shows that it went up to 104340 iterations:
+
+ FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
+ DUPLICATE: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
+ FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: [string equal $fid $main_fid]
+ FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: get hexadecimal valueof "$pc"
+
+ Add a max instruction check, exit the loop if we reach 100 iterations.
+ This should allow the test to fail fast if there's a problem, but 100
+ iterations should be more than enough for when things are working.
+
+ Change-Id: I77978d593aca046068f9209272d82e1675ba17c2
+
+2022-10-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-21 Pedro Alves <pedro@palves.net>
+
+ Improve Python Unwinders documentation
+ - avoid "GDB proper" to refer to global locus, as object files and
+ program spaces are also GDB proper.
+
+ - gdb.register_unwinder does not accept locus=gdb.
+
+ - "a unwinder" -> "an unwinder"
+
+ Approved-by: Eli Zaretskii <eliz@gnu.org>
+ Change-Id: I98c1b1000e1063815238e945ca71ec6f37b5702e
+
+2022-10-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make inherit_abstract_dies use vector iterators
+ Small cleanup to use std::vector iterators rather than raw pointers.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Change-Id: I8d50dbb3f2d8dad7ff94066a578d523f1f31b590
+
+2022-10-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: check for empty offsets vector in inherit_abstract_dies
+ When building GDB with clang and --enable-ubsan, I get:
+
+ UNRESOLVED: gdb.dwarf2/frame-inlined-in-outer-frame.exp: starti prompt
+
+ The cause being:
+
+ $ ./gdb --data-directory=data-directory -nx -q -readnow testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame
+ Reading symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
+ Expanding full symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
+ /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer
+
+ I found this to happen with ld-linux on at least Arch Linux and Ubuntu
+ 22.04:
+
+ $ ./gdb --data-directory=data-directory -nx -q -readnow -iex "set debuginfod enabled on" /lib64/ld-linux-x86-64.so.2
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ Reading symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
+ Expanding full symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
+ /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer
+
+ The problem happens when doing this:
+
+ sect_offset *offsetp = offsets.data () + 1
+
+ When `offsets` is an empty vector, `offsets.data ()` returns nullptr.
+ Fix it by wrapping that in a `!offsets.empty ()` check.
+
+ Change-Id: I6d29ba2fe80ba4308f68effd9c57d4ee8d67c29f
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-10-21 Fangrui Song <maskray@google.com>
+
+ readelf: support zstd compressed debug sections [PR 29640]
+
+2022-10-21 Tom Tromey <tromey@adacore.com>
+
+ Fix incorrect .gdb_index with new DWARF scanner
+ PR symtab/29694 points out a regression caused by the new DWARF
+ scanner when the cc-with-gdb-index target board is used.
+
+ What happens here is that an older version of gdb will make an index
+ describing the "A" type as:
+
+ [737] A: 1 [global, type]
+
+ whereas the new gdb says:
+
+ [1008] A: 0 [global, type]
+
+ Here the old one is correct because the A in CU 0 is just a
+ declaration without a size:
+
+ <1><45>: Abbrev Number: 10 (DW_TAG_structure_type)
+ <46> DW_AT_name : A
+ <48> DW_AT_declaration : 1
+ <48> DW_AT_sibling : <0x6d>
+
+ This patch fixes the problem by introducing the idea of a "type
+ declaration". I think gdb still needs to recurse into these types,
+ searching for methods, but by marking the type itself as a
+ declaration, gdb can skip this type during lookups and when writing
+ the index.
+
+ Regression tested on x86-64 using the cc-with-gdb-index board.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29694
+
+2022-10-21 Tom Tromey <tromey@adacore.com>
+
+ Fix crash in value_print_array_elements
+ A user noticed that gdb would crash when printing a packed array after
+ doing "set lang c". Packed arrays don't exist in C, but it's
+ occasionally useful to print things in C mode when working in a non-C
+ language -- this lets you see under the hood a little bit.
+
+ The bug here is that generic value printing does not handle packed
+ arrays at all. This patch fixes the bug by introducing a new function
+ to extract a value from a bit offset and width.
+
+ The new function includes a hack to avoid problems with some existing
+ test cases when using -fgnat-encodings=all. Cleaning up this code
+ looked difficult, and since "all" is effectively deprecated, I thought
+ it made sense to simply work around the problems.
+
+2022-10-21 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in Ada packed array handling
+ A user found a bug where an array of packed arrays was printed
+ incorrectly. The bug here is that the packed array has a bit stride,
+ but the outer array does not -- and should not. However,
+ update_static_array_size does not distinguish between an array of
+ packed arrays and a multi-dimensional packed array, and for the
+ latter, only the innermost array will end up with a stride.
+
+ This patch fixes the problem by adding a flag to indicate whether a
+ given array type is a constituent of a multi-dimensional array.
+
+2022-10-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: declare variables on first use in inherit_abstract_dies
+ Move variable declarations to where they are first use, plus some random
+ style fixes.
+
+ Change-Id: Idf40d60f9034996fa6a234165cd989a721eb4148
+
+2022-10-21 Nick Clifton <nickc@redhat.com>
+
+ Add a -w option to the linker to suppress warning and error messages.
+ PR 29654
+ * ld.h (struct ld_config_type): Add no_warnings field.
+ * ldlex.h (enum option_values): Add OPTION_NO_WARNINGS.
+ * lexsup.c (ld_options): Add --no-warnings.
+ (parse_args): Add support for -w and --no-warnings.
+ * ldmisc.c (vfinfo): Return early if the message is a warning and
+ -w has been enabled.
+ * ld.texi (options): Document new command line option.
+ * NEWS: Mention the new feature.
+
+ Add a note to the binutils/NEWS file about DCO signed contributions.
+
+2022-10-21 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/reverse: Fix stepping over recursive functions
+ Currently, when using GDB to do reverse debugging, if we try to use the
+ command "reverse next" to skip a recursive function, instead of skipping
+ all of the recursive calls and stopping in the previous line, we stop at
+ the second to last recursive call, and need to manually step backwards
+ until we leave the first call. This is well documented in PR gdb/16678.
+
+ This bug happens because when GDB notices that a reverse step has
+ entered into a function, GDB will add a step_resume_breakpoint at the
+ start of the function, then single step out of the prologue once that
+ breakpoint is hit. The problem was happening because GDB wouldn't give
+ that step_resume_breakpoint a frame-id, so the first time the breakpoint
+ was hit, the inferior would be stopped. This is fixed by giving the
+ current frame-id to the breakpoint.
+
+ This commit also changes gdb.reverse/step-reverse.c to contain a
+ recursive function and attempt to both, skip it altogether, and to skip
+ the second call from inside the first call, as this setup broke a
+ previous version of the patch.
+
+2022-10-21 Bruno Larsen <blarsen@redhat.com>
+
+ Change calculation of frame_id by amd64 epilogue unwinder
+ When GDB is stopped at a ret instruction and no debug information is
+ available for unwinding, GDB defaults to the amd64 epilogue unwinder, to
+ be able to generate a decent backtrace. However, when calculating the
+ frame id, the epilogue unwinder generates information as if the return
+ instruction was the whole frame.
+
+ This was an issue especially when attempting to reverse debug, as GDB
+ would place a step_resume_breakpoint from the epilogue of a function if
+ we were to attempt to skip that function, and this breakpoint should
+ ideally have the current function's frame_id to avoid other problems
+ such as PR record/16678.
+
+ This commit changes the frame_id calculation for the amd64 epilogue,
+ so that it is always the same as the dwarf2 unwinder's frame_id.
+
+ It also adds a test to confirm that the frame_id will be the same,
+ regardless of using the epilogue unwinder or not, thanks to Andrew
+ Burgess.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-10-21 Nick Clifton <nickc@redhat.com>
+
+ Updated Hungarian translation for the gprof sub-directory.
+ * po/hu.po: Updated Hungarian translation.
+
+2022-10-21 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/Python: Make `None' stand for `unlimited' in setting integer parameters
+ Similarly to booleans and following the fix for PR python/29217 make
+ `gdb.parameter' accept `None' for `unlimited' with parameters of the
+ PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZUINTEGER_UNLIMITED types, as
+ `None' is already returned by parameters of the two former types, so
+ one might expect to be able to feed it back. It also makes it possible
+ to avoid the need to know what the internal integer representation is
+ for the special setting of `unlimited'.
+
+ Expand the testsuite accordingly.
+
+ Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2022-10-21 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Expand Python integer parameter coverage across all types
+ Also verify PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZINTEGER parameter
+ types, in addition to PARAM_ZUINTEGER and PARAM_ZUINTEGER_UNLIMITED
+ already covered, and verify a choice of existing GDB parameters. Add
+ verification for reading parameters via `<parameter>.value' in addition
+ to `gdb.parameter('<parameter>')' as this covers different code paths.
+
+ Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2022-10-21 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/Guile: Don't assert that an integer value is boolean
+ Do not assert that a value intended for an integer parameter, of either
+ the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean,
+ causing error messages such as:
+
+ ERROR: In procedure make-parameter:
+ ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3
+ Error while executing Scheme code.
+
+ when initialization with a number is attempted. Instead assert that it
+ is integer. Keep matching `#:unlimited' keyword as an alternative. Add
+ suitable test cases.
+
+ Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2022-10-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Silence compilation fail in gdb.base/rtld-step.exp
+ With gcc 7.5.0 and test-case gdb.base/rtld-step.exp, I run into:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option \
+ '-static-pie'; did you mean '-static'?
+ ...
+
+ Silence this by checking in the test-case that -static-pie is supported, and
+ emitting instead:
+ ...
+ UNTESTED: gdb.base/rtld-step.exp: \
+ failed to compile (-static-pie not supported or static libc missing)
+ ...
+
+ Tested on x86_64-linux, with:
+ - gcc 7.5.0: UNTESTED
+ - gcc 12.2.1 with static glibc not installed: UNTESTED
+ - gcc 12.2.1 with static glibc installed: PASS
+
+2022-10-21 Cui,Lili <lili.cui@intel.com>
+
+ Support Intel AMX-FP16
+ gas/
+
+ * NEWS: Add support for Intel AMX-FP16 instruction.
+ * config/tc-i386.c: Add amx_fp16.
+ * doc/c-i386.texi: Document .amx_fp16.
+ * testsuite/gas/i386/i386.exp: Add AMX-FP16 tests.
+ * testsuite/gas/i386/x86-64-amx-fp16-intel.d: New test.
+ * testsuite/gas/i386/x86-64-amx-fp16.d: Likewise.
+ * testsuite/gas/i386/x86-64-amx-fp16.s: Likewise.
+ * testsuite/gas/i386/x86-64-amx-fp16-bad.d: Likewise.
+ * testsuite/gas/i386/x86-64-amx-fp16-bad.s: Likewise.
+
+ opcodes/
+
+ * i386-dis.c (MOD_VEX_0F385C_X86_64_P_3_W_0): New.
+ (VEX_LEN_0F385C_X86_64_P_3_W_0_M_0): Likewise.
+ (VEX_W_0F385C_X86_64_P_3): Likewise.
+ (prefix_table): Add VEX_W_0F385C_X86_64_P_3.
+ (vex_len_table): Add VEX_LEN_0F385C_X86_64_P_3_W_0_M_0.
+ (vex_w_table): Add VEX_W_0F385C_X86_64_P_3.
+ (mod_table): Add MOD_VEX_0F385C_X86_64_P_3_W_0.
+ * i386-gen.c (cpu_flag_init): Add AMX-FP16_FLAGS.
+ (CPU_ANY_AMX_TILE_FLAGS): Add CpuAMX_FP16.
+ (cpu_flags): Add CpuAMX-FP16.
+ * i386-opc.h (enum): Add CpuAMX-FP16.
+ (i386_cpu_flags): Add cpuamx_fp16.
+ * i386-opc.tbl: Add Intel AMX-FP16 instruction.
+ * i386-init.h: Regenerate.
+ * i386-tbl.h: Likewise.
+
+2022-10-21 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Remove unused CXXFLAGS substitution
+ Not only that sim/configure.ac does not AC_SUBST CXXFLAGS,
+ unless we need C++ compiler like CXX, substitution @CXXFLAGS@ is useless.
+ Because of this, this commit removes this substitution.
+
+2022-10-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-20 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Check VEX/EVEX encoding before checking vector operands
+ Since
+
+ commit 837e225ba1992f9745e5bbbd5e8443243a7f475f
+ Author: Jan Beulich <jbeulich@suse.com>
+ Date: Thu Oct 20 10:01:12 2022 +0200
+
+ x86: re-work AVX-VNNI support
+
+ moved AVX-VNNI after AVX512-VNNI, vector Disp8 is applied even when VEX
+ encoding is selected. Check VEX/EVEX encoding before checking vector
+ operands to avoid vector Disp8 with VEX encoding.
+
+ PR gas/29708
+ * config/tc-i386.c (match_template): Check VEX/EVEX encoding
+ before checking vector operands.
+ * testsuite/gas/i386/avx-vnni.d: Updated.
+ * testsuite/gas/i386/x86-64-avx-vnni.d: Likewise.
+ * testsuite/gas/i386/avx-vnni.s: Add a Disp32 test.
+ * testsuite/gas/i386/x86-64-avx-vnni.s: Likewise.
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: break more dependencies between gdbpy_initialize_* functions
+ In a later commit in this series I will propose removing all of the
+ explicit gdbpy_initialize_* calls from python.c and replace these
+ calls with a more generic mechanism.
+
+ One of the side effects of this generic mechanism is that the order in
+ which the various Python sub-systems within GDB are initialized is no
+ longer guaranteed.
+
+ On the whole I don't think this matters, most of the sub-systems are
+ independent of each other, though testing did reveal a few places
+ where we did have dependencies, though I don't think those
+ dependencies were explicitly documented in comment anywhere.
+
+ This commit is similar to the previous one, and fixes the second
+ dependency issue that I found.
+
+ In this case the finish_breakpoint_object_type uses the
+ breakpoint_object_type as its tp_base, this means that
+ breakpoint_object_type must have been initialized with a call to
+ PyType_Ready before finish_breakpoint_object_type can be initialized.
+
+ Previously we depended on the ordering of calls to
+ gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
+ python.c.
+
+ After this commit a new function gdbpy_breakpoint_init_breakpoint_type
+ exists, this function ensures that breakpoint_object_type has been
+ initialized, and can be called from any gdbpy_initialize_* function.
+
+ I feel that this change makes the dependency explicit, which I think
+ is a good thing.
+
+ There should be no user visible changes after this commit.
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: break dependencies between gdbpy_initialize_* functions
+ In a later commit in this series I will propose removing all of the
+ explicit gdbpy_initialize_* calls from python.c and replace these
+ calls with a more generic mechanism.
+
+ One of the side effects of this generic mechanism is that the order in
+ which the various Python sub-systems within GDB are initialized is no
+ longer guaranteed.
+
+ On the whole I don't think this matters, most of the sub-systems are
+ independent of each other, though testing did reveal a few places
+ where we did have dependencies, though I don't think those
+ dependencies were explicitly documented in a comment anywhere.
+
+ This commit removes the first dependency issue, with this and the next
+ commit, all of the implicit inter-sub-system dependencies will be
+ replaced by explicit dependencies, which will allow me to, I think,
+ clean up how the sub-systems are initialized.
+
+ The dependency is around the py_insn_type. This type is setup in
+ gdbpy_initialize_instruction and used in gdbpy_initialize_record.
+ Rather than depend on the calls to these two functions being in a
+ particular order, in this commit I propose adding a new function
+ py_insn_get_insn_type. This function will take care of setting up the
+ py_insn_type type and calling PyType_Ready. This helper function can
+ be called from gdbpy_initialize_record and
+ gdbpy_initialize_instruction, and the py_insn_type will be initialized
+ just once.
+
+ To me this is better, the dependency is now really obvious, but also,
+ we no longer care in which order gdbpy_initialize_record and
+ gdbpy_initialize_instruction are called.
+
+ There should be no user visible changes after this commit.
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: some int to bool conversion in breakpoint.c
+ Some int to bool conversion in breakpoint.c. I've only updated the
+ function signatures of static functions, but I've updated some
+ function local variables throughout the file.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make use of scoped_restore in unduplicated_should_be_inserted
+ I noticed that we could make use of a scoped_restore in the function
+ unduplicated_should_be_inserted. I've also converted the function
+ return type from int to bool.
+
+ This change shouldn't make any difference, as I don't think anything
+ within should_be_inserted could throw an exception, but the change
+ doesn't hurt, and will help keep us safe if anything ever changes in
+ the future.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: used scoped_restore_frame in update_watchpoint
+ I was doing some int to bool cleanup in update_watchpoint, and I
+ noticed a manual version of scoped_restore_selected_frame. As always
+ when these things are done manually, there is the chance that, in an
+ error case, we might leave the wrong frame selected.
+
+ This commit updates things to use scoped_restore_selected_frame, and
+ also converts a local variable from int to bool.
+
+ The only user visible change after this commit is in the case where
+ update_watchpoint throws an error - we should now correctly restore
+ the previously selected frame. Otherwise, this commit should be
+ invisible to the user.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make some bp_location arguments const in breakpoint.c
+ I spotted a few places where I could make some 'bp_location *'
+ arguments constant in breakpoint.c.
+
+ There should be no user visible changes after this commit.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2022-10-20 Дилян Палаузов <dilyan.palauzov@aegee.org>
+
+ Reapply "Don't build readline/libreadline.a, when --with-system-readline is supplied"
+ Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the
+ change originally done in commit 69961a84c9b ("Don't build
+ readline/libreadline.a, when --with-system-readline is supplied").
+ Re-apply it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18632
+
+2022-10-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-work AVX-VNNI support
+ By putting the templates after their AVX512 counterparts, the AVX512
+ flavors will be picked by default. That way the need to always use {vex}
+ ceases to exist once respective CPU features (AVX512-VNNI or AVX512VL as
+ a whole) have been disabled. This way the need for the PseudoVexPrefix
+ attribute also disappears.
+
+2022-10-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with check-read1
+ With test-case gdb.debuginfod/fetch_src_and_symbols.exp and check-read1, I run
+ into:
+ ...
+ (gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: \
+ file fetch_src_and_symbols (got interactive prompt)
+ ...
+
+ The problem is that this output:
+ ...
+ Enable debuginfod for this session? (y or [n]) y^M
+ ...
+ is matched using regexp "Enable debuginfod?.*" with matches only the first two
+ words of the output, after which an implicit clause in gdb_test_multiple triggers
+ on the second part containing the interactive prompt.
+
+ Fix this by included the interactive prompt in the regexp.
+
+ Tested on x86_64-linux.
+
+2022-10-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with check-read1
+ With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into:
+ ...
+ FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main
+ FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)"
+ ...
+
+ The problem for both FAILs is that the output is parsed using
+ gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can
+ match before the explicit clauses using $mi_gdb_prompt.
+
+ Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple.
+
+ Tested on x86-64-linux.
+
+2022-10-20 Alan Modra <amodra@gmail.com>
+
+ Re: aarch64-pe support for LD, GAS and BFD
+ Fix dependencies for eaarch64pe.c. Generated files aren't handled
+ fully automatically.
+
+2022-10-20 Mark Harmstone <mark@harmstone.com>
+
+ ld: Add minimal pdb generation
+
+ ld: Add --pdb option
+ Second patch incorporates fixes for endian and UB issues in calc_hash, as per
+ https://sourceware.org/pipermail/binutils/2022-October/123514.html.
+
+2022-10-20 Kevin Buettner <kevinb@redhat.com>
+
+ Test stepping within a runtime loader / dynamic linker
+ See the remarks in rtld-step.exp for a description of what this
+ test is about.
+
+ This test case has been tested using gcc on the following x86-64 Linux
+ distributions/releases:
+
+ Fedora 28
+ Fedora 32
+ Fedora 33
+ Fedora 34
+ Fedora 35
+ Fedora 36
+ Fedora 37
+ rawhide (f38)
+ RHEL 9.1
+ Ubuntu 22.04.1 LTS
+
+ It's also been tested (and found to be working) with
+ RUNTESTFLAGS="CC_FOR_TARGET=clang" on all of the above expect for
+ Fedora 28. The (old) version of clang available on F28 did not
+ accept the -static-pie option.
+
+ I also tried to make this test work on FreeBSD 13.1. While I think I
+ made significant progress, I was ultimately stymied by this message
+ which occurs when attempting to run the main program which has been
+ set to use the fake/pretend RTLD as the ELF interpreter:
+
+ ELF interpreter /path/to/rtld-step-rtld not found, error 22
+
+ I have left one of the flags (-static) in place which I believe
+ to be needed for FreeBSD (though since I never got it to work, I
+ don't know for sure.) I've also left some declarations needed
+ for FreeBSD in rtld-step-rtld.c. They're currently disabled via
+ a #if 0; you'll need to enable them if you want to try to make
+ it work on FreeBSD.
+
+2022-10-20 Kevin Buettner <kevinb@redhat.com>
+
+ Allow debugging of runtime loader / dynamic linker
+ At present, GDB does not allow for the debugging of the runtime loader
+ and/or dynamic linker. Much of the time, this makes sense. An
+ application programmer doesn't normally want to see symbol resolution
+ code when stepping into a function that hasn't been resolved yet.
+
+ But someone who wishes to debug the runtime loader / dynamic linker
+ might place a breakpoint in that code and then wish to debug it
+ as normal. At the moment, this is not possible. Attempting to step
+ will cause GDB to internally step (and not stop) until code
+ unrelated to the dynamic linker is reached.
+
+ This commit makes a minor change to infrun.c which allows the dynamic
+ loader / linker to be debugged in the case where a step, next, etc.
+ is initiated from within that code.
+
+ While developing this fix, I tried some approaches which weren't quite
+ right. The GDB testusite definitely contains tests which FAIL when
+ it's done incorrectly. (At one point, I saw 17 regressions!) This
+ commit has been tested on x86-64 linux with no regressions.
+
+2022-10-20 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ binutils: Remove unused substitution PROGRAM
+ Unlike other substitution, this substitution of @PROGRAM@ was done in
+ binutils/Makefile and it was intended for binutils/cxxfilt.man. @PROGRAM@
+ in binutils/cxxfilt.man is removed in the commit 0285c67df190 ("Automate
+ generate on man pages") in 2001 and @PROGRAM@ is ineffective since then.
+
+ Because PROGRAM substitution does nothing, removing this manual
+ substitution should be completely safe.
+
+ binutils/ChangeLog:
+
+ * doc/local.mk: Remove unused substitution PROGRAM.
+ * Makefile.in: Regenerate.
+
+2022-10-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-20 Alan Modra <amodra@gmail.com>
+
+ Obsolete beos
+ * config.bfd: Obsolete *-*-beos*. Simplify x86 beos match.
+
+ Regen ld/po/BLD-POTFILES.in
+
+2022-10-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix assert in handle_jit_event
+ With the cc-with-tweaks.sh patch submitted here (
+ https://sourceware.org/pipermail/gdb-patches/2022-October/192586.html ) we run
+ with:
+ ...
+ $ export STRIP_ARGS_STRIP_DEBUG=--strip-all
+ $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
+ --target_board cc-with-gnu-debuglink"
+ ...
+ into the following assert:
+ ...
+ (gdb) run ^M
+ Starting program: jit-reader ^M
+ gdb/jit.c:1247: internal-error: jit_event_handler: \
+ Assertion `jiter->jiter_data != nullptr' failed.^M
+ ...
+
+ Fix this by handling the
+ jit_bp_sym.objfile->separate_debug_objfile_backlink != nullptr case in
+ handle_jit_event.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29277
+
+2022-10-19 Pedro Alves <pedro@palves.net>
+
+ internal_error: remove need to pass __FILE__/__LINE__
+ Currently, every internal_error call must be passed __FILE__/__LINE__
+ explicitly, like:
+
+ internal_error (__FILE__, __LINE__, "foo %d", var);
+
+ The need to pass in explicit __FILE__/__LINE__ is there probably
+ because the function predates widespread and portable variadic macros
+ availability. We can use variadic macros nowadays, and in fact, we
+ already use them in several places, including the related
+ gdb_assert_not_reached.
+
+ So this patch renames the internal_error function to something else,
+ and then reimplements internal_error as a variadic macro that expands
+ __FILE__/__LINE__ itself.
+
+ The result is that we now should call internal_error like so:
+
+ internal_error ("foo %d", var);
+
+ Likewise for internal_warning.
+
+ The patch adjusts all calls sites. 99% of the adjustments were done
+ with a perl/sed script.
+
+ The non-mechanical changes are in gdbsupport/errors.h,
+ gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
+
+2022-10-19 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access when parsing an ELF file containing corrupt symbol version information.
+ PR 29699
+ * elf.c (_bfd_elf_slurp_version_tables): Fail if the sh_info field
+ of the section header is zero.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ sim/iq2000: silence pointer-sign warnings
+ When building the iq2000 simulator I see a few warnings like this:
+
+ /tmp/build/sim/../../src/sim/iq2000/iq2000.c: In function ‘fetch_str’:
+ /tmp/build/sim/../../src/sim/iq2000/iq2000.c:50:54: error: pointer targets in passing argument 3 of ‘sim_read’ differ in signedness [-Werror=pointer-sign]
+ 50 | sim_read (CPU_STATE (current_cpu), CPU2DATA(addr), buf, nr);
+ | ^~~
+ | |
+ | char *
+
+ I've silenced these warnings by casting buf to 'unsigned char *'.
+ With this change I now see no warnings when compiling iq2000.c, so
+ I've removed the line from Makefile.in that disables -Werror.
+
+ Makefile.in was also disabling -Werror when compiling mloop.c,
+ however, I'm not seeing any warnings when compiling that file, so I've
+ removed the -Werror disable in that case too.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ sim/erc32: avoid dereferencing type-punned pointer warnings
+ When building the erc32 simulator I get a few warnings like this:
+
+ /tmp/build/sim/../../src/sim/erc32/exec.c:1377:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
+ 1377 | sregs->fs[rd] = *((float32 *) & ddata[0]);
+ | ~^~~~~~~~~~~~~~~~~~~~~~~
+
+ The type of '& ddata[0]' will be 'uint32_t *', which is what triggers
+ the warning.
+
+ This commit makes use of memcpy when performing the type-punning,
+ which resolves the above warnings.
+
+ With this change, I now see no warnings when compiling exec.c, which
+ means that the line in Makefile.in that disables -Werror can be
+ removed.
+
+ There should be no change in behaviour after this commit.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: mark device_error function as ATTRIBUTE_NORETURN
+ The device_error function always ends up calling the error function,
+ which is itself marked as ATTRIBUTE_NORETURN, so it makes sense that
+ device_error should also be marked ATTRIBUTE_NORETURN.
+
+ Doing this resolves a few warnings from hw_ide.c about possibly
+ uninitialized variables - the variables are only uninitialized after
+ passing through a call to device_error, which obviously means the
+ variables are never really used uninitialized, the simulation will
+ terminate with the device_error call.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: fix warnings related to printf format strings
+ This commit is a follow on to:
+
+ commit 182421c9d2eea8c4877d983a2124e591f0aca710
+ Date: Tue Oct 11 15:02:08 2022 +0100
+
+ sim/ppc: fixes for arguments to printf style functions
+
+ where commit 182421c9d2ee addressed issues with printf format
+ arguments that were causing the compiler to give an error, this commit
+ addresses issues that caused the compiler to emit a warning.
+
+ This commit is mostly either changing the format string to match the
+ argument, or in some cases, excess, unused arguments are removed.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ sim/cgen: mask uninitialized variable warning in cgen-run.c
+ I see an uninitialized variable warning (with gcc 9.3.1) from
+ cgen-run.c, like this:
+
+ /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c: In function ‘sim_resume’:
+ /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:259:5: warning: ‘engine_fns$’ may be used uninitialized in this function [-Wmaybe-uninitialized]
+ 259 | (* engine_fns[next_cpu_nr]) (cpu);
+ | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:232:14: note: ‘engine_fns$’ was declared here
+ 232 | ENGINE_FN *engine_fns[MAX_NR_PROCESSORS];
+ | ^~~~~~~~~~
+
+ This is a false positive - we over allocate engine_fn, and then only
+ initialize the nr_cpus entries which we will later go on to use.
+
+ However, we can easily silence this warning by initializing the unused
+ entries in engine_fns to NULL, this might also help if anyone ever
+ looks at engine_fns in a debugger, it should now be obvious which
+ entries are in use, and which are not.
+
+ With this change the warning is gone.
+
+ There should be no change in behaviour with this commit.
+
+2022-10-19 Alan Modra <amodra@gmail.com>
+
+ Fix addr2line test for ppc64 elfv1 and mingw
+ * testsuite/binutils-all/addr2line.exp: Tidy. For powerpc64
+ arrange to pass --synthetic to nm, and extract .main and .fn
+ symbol address for addr2line test. Handle default executable
+ extension on cygwin/mingw compilers.
+
+2022-10-19 Nick Clifton <nickc@redhat.com>
+
+ Update MAINTAINERS file with details about accepting DCO signed contributions.
+ * MAINTAINERS: Add section on patches, copyright and DCO.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: avoid temporary file in gdb/testsuite (unittest.exp)
+ I spotted that the gdb.gdb/unittest.exp script causes a temporary file
+ inserters_extractors-2.txt to be created in build/gdb/testsuite/
+ instead of in build/gdb/testsuite/output/gdb.gdb/unittest/.
+
+ This is because some of the 'maint selftest' tests create temporary
+ files in GDB's current directory, specifically, the two source files:
+
+ gdb/unittests/basic_string_view/inserters/wchar_t/2.cc
+ gdb/unittests/basic_string_view/inserters/char/2.cc
+
+ both create a temporary file called inserters_extractors-2.txt, though
+ we only run the second of these as part of GDB's selftests.
+
+ I initially proposed just using GDB's 'cd' command in unittest.exp to
+ switch to the test output directory before running the selftests,
+ however, Pedro pointed out that there was a risk here that, if GDB
+ crashed during shutdown, the generated core file would be left in the
+ test output directory rather than in the testsuite directory. As a
+ result, our clever core file spotting logic would fail to spot the
+ core file and alert the user.
+
+ Instead, I propose this slightly more involved solution. I've added a
+ new with_gdb_cwd directory proc, used like this:
+
+ with_gdb_cwd $directory {
+ # Tests here...
+ }
+
+ The new proc temporarily switches to $directory and then runs the
+ tests within the block. After running the tests the previous current
+ working directory is restored.
+
+ Additionally, after switching back to the previous cwd, we check that
+ GDB is still responsive. This means that if GDB crashed immediately
+ prior to restoring the previous directory, and left the core file in
+ the wrong place, then the responsiveness check will fail, and a FAIL
+ will be emitted, this should be enough to alert the user that
+ something has gone wrong.
+
+ With this commit in place the unittest.exp script now leaves its
+ temporary file in the test output directory.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: avoid creating files in gdb/testsuite directory
+ I spotted that the test gdb.dwarf2/dw2-using-debug-str.exp was
+ creating an output file called debug_str_section in the root
+ build/gdb/testsuite directory instead of using the
+ build/gdb/testsuite/output/gdb.dwarf2/dw2-using-debug-str/ directory.
+
+ This appears to be caused by a missing '$' character. We setup a
+ variable debug_str_section which contains a path within the output
+ directory, but then when we build the objcopy command we use
+ 'debug_str_section' without a '$' prefix, as a result, we create the
+ debug_str_section file.
+
+ This commit adds the missing '$', the file is now created in the
+ output directory.
+
+2022-10-19 Andrew Burgess <aburgess@redhat.com>
+
+ bfd: fix undefined references to aarch64_pe_le_vec
+ After commit:
+
+ commit c60b3806799abf1d7f6cf5108a1b0e733a950b13
+ Date: Wed Oct 19 10:57:12 2022 +0200
+
+ aarch64-pe support for LD, GAS and BFD
+
+ It appears that bfd/Makefile.in and bfd/configure were not regenerated
+ correctly. The differences in the configure file are only whitespace,
+ but in Makefile.in a critical reference to pe-aarch64.lo was missing.
+
+2022-10-19 Jedidiah Thompson <wej22007@outlook.com>
+ Jedidiah Thompson <wej22007@outlook.com>
+ Zac Walker <zac.walker@linaro.org>
+
+ aarch64-pe support for LD, GAS and BFD
+ Allows aarch64-pe to be targeted natively, not having to use objcopy to convert it from ELF to PE.
+ Based on initial work by Jedidiah Thompson
+
+2022-10-19 rupesh potharla <rupesh.potharla@amd.com>
+
+ Binutils: Adding new testcase for addr2line.
+ * binutils/testsuite/config/default.exp: Set ADDR2LINE and ADDR2LINEFLAGS.
+ * binutils/testsuite/binutils-all/addr2line.exp: New file.
+
+2022-10-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix ERROR in gdb.python/py-breakpoint.exp
+ With test-case gdb.python/py-breakpoint.exp I run into:
+ ...
+ (gdb) ERROR: tcl error sourcing gdb.python/py-breakpoint.exp.
+ ERROR: can't read "skip_hw_watchpoint_tests_p": no such variable
+ while executing
+ "if {$skip_hw_watchpoint_tests_p} {
+ gdb_test_no_output "set can-use-hw-watchpoints 0" ""
+ }"
+ ...
+
+ Fix this by adding the missing "global skip_hw_watchpoint_tests_p" in two
+ procs.
+
+ Tested on x86_64-linux.
+
+2022-10-19 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM zSystems: Issue error for *DBL relocs on misaligned symbols
+ Relocs like PC32DBL require a right shift of the symbol value. There
+ is no situation where dropping symbol value bits with the right shift
+ is a good thing. Hence we now issue an error to detect such problems.
+
+2022-10-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: check for groups with duplicate names in reggroups:add
+ In the downstream ROCm GDB port, we would create multiple register
+ groups with duplicate names. While it did not really hurt, it certainly
+ wasn't the intent. And I don't think it ever makes sense to do so.
+
+ To catch these, change the assert in reggroups::add to check for
+ duplicate names. It's no longer necessary to check for duplicate
+ reggroup pointers, because adding the same group twice would be caught
+ by the duplicate name check.
+
+ Change-Id: Id216a58acf91f1b314d3cba2d02de73656f8851d
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2022-10-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-18 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Disable AVX-VNNI when disabling AVX2
+ Since AVX-VNNI requires AVX2, disable AVX-VNNI when disabling AVX2.
+
+ * i386-gen.c (cpu_flag_init): Add CpuAVX_VNNI to
+ CPU_ANY_AVX2_FLAGS.
+ * i386-init.h: Regenerate.
+
+2022-10-18 Tom Tromey <tom@tromey.com>
+
+ Remove dead code from py-finishbreakpoint.c
+ PR python/16324 points out that comparing a frame id to null_frame_id
+ can never succeed, and proposes simply removing the dead code. That
+ is what this patch does.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16324
+
+2022-10-18 Carl Love <cel@us.ibm.com>
+
+ Update tests to use skip_hw_watchpoint_tests to test for HW watchpoint support.
+ The hardware watchpoint check has been updated in a couple of recent
+ patches. This patch updates the hardware watchpoint test in the remaining
+ gdb tests.
+
+ The issue is the PowerPC processors support hardware watchpoints with the
+ exception of Power 9. The hardware watchpoint support is disabled on
+ Power 9. The test skip_hw_watchpoint_tests must be used to correctly
+ determine if the PowerPC processor supports hardware watchpoints.
+
+ This patch fixes 6 test failures in test gdb.threads/watchpoint-fork.exp.
+
+ Test gdb.base/watch-vfork.exp runs with can-use-hw-watchpoints set to
+ true and false. When the test is run with can-use-hw-watchpoints set to
+ true, gdb just falls back to using software watchpoints. The
+ patch reduces the number of expected passes by 2 since because it now
+ only runs once with can-use-hw-watchpoints set to false.
+
+ Test gdb.mi/mi-watch.exp runs the test with argument hw and sw. If the
+ argument is hw and hardware watchpoints are not supported the test exits.
+ The number of expected passes is cut in half with the patch as it now only
+ runs the test using software breakpoints. Previously the pass to use
+ hardware watchpoints was not skipped and the test actually ran using
+ software watchpoints.
+
+ The following tests run the same with and without the patch. The tests
+ are supposed to execute the gdb command "set can-use-hw-watchpoints 0" if
+ the processor does not support hardware bwatchpoints. However the command
+ was not being executed and gdb was falling back to using software
+ watchpoints since the Power 9 watchpoint resource check fails. With the
+ patch, the tests now execute the command and the test runs using software
+ watchpoints as it did previously. The tests are:
+
+ gdb.base/commands.exp
+ gdb.base/cond-eval-mode.exp
+ gdb.base/display.exp
+ gdb.base/gdb11531.exp
+ gdb.base/recurse.exp
+ gdb.base/value-double-free.exp
+ gdb.base/watch-bitfields.exp
+ gdb.base/watch-cond-infcall.exp
+ gdb.base/watch-cond.exp
+ gdb.base/watchpoint-solib.exp
+ gdb.base/watchpoints.exp
+
+ The following two tests are not supported on the Power 9 system used to
+ test the changes. The patch does not change the tests results for these
+ tests:
+
+ gdb.python/py-breakpoint.exp
+ gdb.mi/mi-watch-nonstop.exp
+
+2022-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle header files with local-remote-host.exp
+ With test-case gdb.base/included.exp and host board local-remote-host.exp with
+ tentative fix for PR29697 I run into:
+ ...
+ included.c:18:10: fatal error: included.h: No such file or directory
+ #include "included.h"
+ ^~~~~~~~~~~~
+ compilation terminated.
+ ...
+
+ Fix this by adding the missing gdb_remote_download calls.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2022-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/no-thread-db.exp with local-remote-host.exp
+ With test-case gdb.server/no-thread-db.exp and host board local-remote-host.exp
+ with a tentative fix for PR29697 I run into:
+ ...
+ (gdb) print foo^M
+ Cannot find thread-local storage for Thread 29613.29613, executable file \
+ $HOME/no-thread-db:^M
+ Remote target failed to process qGetTLSAddr request^M
+ (gdb) FAIL: gdb.server/no-thread-db.exp: print foo
+ ...
+
+ The regexp in the test-case expects the full $binfile pathname, but we have
+ instead $HOME/no-thread-db.
+
+ Fix this by making the regexp less strict.
+
+ Tested on x86_64-linux.
+
+2022-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/return-nodebug.exp with local-remote-host.exp
+ With host board local-remote-host.exp and test-case
+ gdb.base/return-nodebug.exp, I run into:
+ ...
+ Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never \
+ -DTYPE=signed\ char -c -g -o return-nodebug-signed-char0.o \
+ /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/return-nodebug.c \
+ (timeout = 300)
+ builtin_spawn [open ...]^M
+ gcc: error: char: No such file or directory
+ ...
+
+ Avoid the quoting problem by not using spaces in the define.
+
+ Tested on x86_64-linux.
+
+2022-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/file-transfer.exp with local-remote-host.exp
+ When running test-case gdb.server/file-transfer.exp with host
+ board local-remote-host.exp, I get:
+ ...
+ Executing on host: cmp -s $outputs/gdb.server/file-transfer/file-transfer \
+ down-server (timeout = 300)
+ builtin_spawn [open ...]^M
+ XYZ2ZYX
+ FAIL: gdb.server/file-transfer.exp: compare intermediate binary file
+ ...
+
+ The remote host and remote target cases are handled here together here in proc
+ test_file_transfer:
+ ...
+ if {![is_remote host] && ![is_remote target]} {
+ set up_server [standard_output_file $up_server]
+ set down_server [standard_output_file $down_server]
+ }
+ ...
+
+ Fix this by handling them separately.
+
+ Tested on x86_64-linux.
+
+2022-10-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Update boards/README
+ Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d
+ ("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which
+ means the board now uses a pseudo-tty, but with editing disabled.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, solib-svr4: support namespaces in DSO iteration
+ When looking up names, GDB needs to stay within one linker namespace to
+ find the correct instance in case the same name is provided in more than
+ one namespace.
+
+ Modify svr4_iterate_over_objfiles_in_search_order() to stay within the
+ namespace of the current_objfile argument. If no current_objfile is
+ provided (i.e. it is nullptr), iterate over objfiles in the initial
+ namespace.
+
+ For objfiles that do not have a corresponding so_list to provide the
+ namespace, assume that the objfile was loaded into the initial namespace.
+ This would cover the main executable objfile (which is indeed loaded into
+ the initial namespace) as well as manually added symbol files.
+
+ Expected fails:
+
+ - gdb.base/non-lazy-array-index.exp: the expression parser may lookup
+ global symbols, which may result in xfers to read auxv for determining
+ the debug base as part of svr4_iterate_over_objfiles_in_search_order().
+
+ - gdb.server/non-lazy-array-index.exp: symbol lookup may access the
+ target to read AUXV in order to determine the debug base for SVR4
+ linker namespaces.
+
+ Known issues:
+
+ - get_symbol_address() and get_msymbol_address() search objfiles for a
+ 'better' match. This was introduced by
+
+ 4b610737f02 Handle copy relocations
+
+ to handle copy relocations but it now causes a wrong address to be
+ read after symbol lookup actually cound the correct symbol. This can
+ be seen, for example, with gdb.base/dlmopen.exp when compiled with
+ clang.
+
+ - gnu ifuncs are only looked up in the initial namespace.
+
+ - lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
+ iterate over objfiles and are not aware of linker namespaces.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb: update gnu ifunc resolve
+ Update elf_gnu_ifunc_resolve_by_cache() and elf_gnu_ifunc_resolve_by_got()
+ to use gdbarch_iterate_over_objfiles_in_search_order() in order to
+ restrict the objfile traversal to the initial namespace.
+
+ In order to extend this to other namespaces, we'd need to provide context,
+ e.g. via an objfile inside that namespace.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, symtab: inline find_quick_global_symbol_language
+ There is only one use of find_quick_global_symbol_language that calls it
+ for the special symbol "main".
+
+ Inline the function as it is probably not correct in the general case
+ where we may have multiple instances of global symbols with the same name
+ but different languages in different libraries in different linker
+ namespaces.
+
+ Further, change the objfiles iteration into a call to
+ gdbarch_iterate_over_objfiles_in_search_order, which would only search the
+ initial linker namespace, where we expect "main" to be located.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol
+ I stumbled over this while reviewing all objfiles traversals with regards
+ to impact of linker namespaces.
+
+ Recursive grep only finds two occurrences of hppa_lookup_stub_minimal_symbol:
+ - the declaration in hppa-tdep.h.
+ - the definition in hppa-tdep.c.
+
+ There appear to be no calls to this function. Remove it.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, cp: update add_symbol_overload_list_qualified
+ Iterate over objfiles in search order using the objfile of the selected
+ block as current_objfile so the iteration can stay inside the block's
+ linker namespace.
+
+ fixup! gdb, ada: update ada_lookup_simple_minsym
+ remove get_selected_block()
+
+ gdb, ada: update ada_lookup_simple_minsym
+ Iterate over objfile in search order using the objfile of the context
+ block as current_objfile so the iteration can stay inside the block's
+ linker namespace.
+
+ gdb, ada: collect standard exceptions in all objfiles
+ When searching for standard exceptions for Ada, we lookup the minimal
+ symbol of each exception. With linker namespaces there can be multiple
+ instances in different namespaces. Collect them all.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, python: use gdbarch_iterate_over_objfiles_in_search_order
+ The implementation of gdb.lookup_objfile() iterates over all objfiles and
+ compares their name or build id to the user-provided search string.
+
+ This will cause problems when supporting linker namespaces as the first
+ objfile in any namespace will be found. Instead, use
+ gdbarch_iterate_over_objfiles_in_search_order to only consider the
+ namespace of gdb.current_objfile() for the search, which defaults to the
+ initial namespace when gdb.current_objfile() is None.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, compile: unlink objfile stored in module
+ When cleaning up after a compile command, we iterate over all objfiles and
+ unlink the first objfile with the same name as the one we compiled.
+
+ Since we already store a pointer to that objfile in the module and use it
+ to get the name we're comparing against, there's no reason to iterate, at
+ all. We can simply use that objfile.
+
+ This further avoids potential issues when an objfile with the same name is
+ loaded into a different linker namespace.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, gdbserver: extend RSP to support namespaces
+ Introduce a new qXfer:libraries-svr4:read annex key/value pair
+
+ lmid=<namespace identifier>
+
+ to be used together with start and prev to provide the namespace of start
+ and prev to gdbserver.
+
+ Unknown key/value pairs are ignored by gdbserver so no new supports check
+ is needed.
+
+ Introduce a new library-list-svr4 library attribute
+
+ lmid
+
+ to provide the namespace of a library entry to GDB.
+
+ This implementation uses the address of a namespace's r_debug object as
+ namespace identifier.
+
+ This should have incremented the minor version but since unknown XML
+ attributes are ignored, anyway, and since changing the version results in
+ a warning from GDB, the version is left at 1.0.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdbserver: move main_lm handling into caller
+ When listing SVR4 shared libraries, special care has to be taken about the
+ first library in the default namespace as that refers to the main
+ executable. The load map address of this main executable is provided in
+ an attribute of the library-list-svr4 element.
+
+ Move that code from where we enumerate libraries inside a single namespace
+ to where we generate the rest of the library-list-svr4 element. This
+ allows us to complete the library-list-svr4 element inside one function.
+
+ There should be no functional change.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+ Lu, Hongjiu <hongjiu.lu@intel.com>
+
+ gdb, gdbserver: support dlmopen()
+ In glibc, the r_debug structure contains (amongst others) the following
+ fields:
+
+ int r_version:
+ Version number for this protocol. It should be greater than 0.
+
+ If r_version is 2, struct r_debug is extended to struct r_debug_extended
+ with one additional field:
+
+ struct r_debug_extended *r_next;
+ Link to the next r_debug_extended structure. Each r_debug_extended
+ structure represents a different namespace. The first r_debug_extended
+ structure is for the default namespace.
+
+ 1. Change solib_svr4_r_map argument to take the debug base.
+ 2. Add solib_svr4_r_next to find the link map in the next namespace from
+ the r_next field.
+ 3. Update svr4_current_sos_direct to get the link map in the next namespace
+ from the r_next field.
+ 4. Don't check shared libraries in other namespaces when updating shared
+ libraries in a new namespace.
+ 5. Update svr4_same to check the load offset in addition to the name
+ 6. Update svr4_default_sos to also set l_addr_inferior
+ 7. Change the flat solib_list into a per-namespace list using the
+ namespace's r_debug address to identify the namespace.
+
+ Add gdb.base/dlmopen.exp to test this.
+
+ To remain backwards compatible with older gdbserver, we reserve the
+ namespace zero for a flat list of solibs from all namespaces. Subsequent
+ patches will extend RSP to allow listing libraries grouped by namespace.
+
+ This fixes PR 11839.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, solib-svr4: remove locate_base()
+ Whenever we call locate_base(), we clear info->debug_base directly before
+ the call. Thus, we never cache the base location as locate_base() had
+ intended.
+
+ Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline
+ locate_base() at all call sites, and remove it.
+
+2022-10-18 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, testsuite: extend gdb_test_multiple checks
+ Check for
+
+ warning: Corrupted shared library list
+
+ and for
+
+ Invalid cast.
+ warning: Probes-based dynamic linker interface failed.
+ Reverting to original interface.
+
+ in gdb_test_multiple.
+
+2022-10-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: generalize gas documentation for disabling of ISA extensions
+ As of commit ae89daecb132 ("x86: generalize disabling of sub-
+ architectures") there's no arbitrary subset of ISAs which can also be
+ disabled. This should have been reflected in documentation right away.
+ Since I failed to do so, correct this now.
+
+ x86: correct CPU_AMX_{BF16,INT8}_FLAGS
+ AMX-TILE is a prereq to these, as already correctly expressed by
+ CPU_ANY_AMX_TILE_FLAGS. Express the dependency also in the reverse
+ ("positive") direction.
+
+2022-10-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ kfail an Ada test for GCC < 12
+ I noticed one particular Ada test was failing on Fedora 34, but works
+ when I switch to GCC 12. This patch arranges to kfail the test when
+ an older compiler is used.
+
+ I tested this with GCC 11, 12, and 13. I'm going to check it in.
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ Remove a nullptr check in DWARF scanner
+ In scan_attributes, The DWARF scanner checks whether maybe_defer is
+ nullptr, but this can never happen. This patch removes the check.
+
+2022-10-17 Pedro Alves <pedro@palves.net>
+
+ gdbarch-components.py: Remove spurious space from "frame_info_ptr " params
+ If you run gdbarch.py today, you'll get local modifications compared
+ to what's in the tree, like:
+
+ --- c/gdb/gdbarch-gen.h
+ +++ w/gdb/gdbarch-gen.h
+ @@ -315,8 +315,8 @@ extern void set_gdbarch_register_type (struct gdbarch *gdbarch, gdbarch_register
+ should match the address at which the breakpoint was set in the dummy
+ frame. */
+
+ -typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+ -extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+ +typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+ +extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+ extern void set_gdbarch_dummy_id (struct gdbarch *gdbarch, gdbarch_dummy_id_ftype *dummy_id);
+
+ etc.
+
+ The extra space comes from the "frame_info_ptr " param that appears in
+ a number of gdbarch methods in gdbarch-components.py. With the extra
+ space removed, running ./gdbarch.py generates the exact code that's in
+ the tree already.
+
+ Change-Id: If7d20b8c6b2fd9ff466142a01bd2611c9ef9f53e
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ Change .gdb_index de-duplication implementation
+ While investigating PR symtab/29179, I found that one Ada test failed
+ because, although a certain symbol was present in the index, with the
+ new DWARF reader it pointed to a different CU than was chosen by
+ earlier versions of gdb.
+
+ This patch changes how symbol de-duplication is done, deferring the
+ process until the entire symbol table has been constructed. This way,
+ it's possible to always choose the lower-numbered CU among duplicates,
+ which is how gdb (implicitly) previously worked.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ Improve Ada support in .gdb_index
+ The cooked index work changed how .gdb_index is constructed, and in
+ the process broke .gdb_index support. This is PR symtab/29179.
+
+ This patch partially fixes the problem. It arranges for Ada names to
+ be encoded in the form expected by the index code. In particular,
+ linkage names for Ada are emitted, including the "main" name; names
+ are Ada-encoded; and names are no longer case-folded, something that
+ prevented operator names from round-tripping correctly.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ Don't add type linkage names to cooked index
+ The compiler will sometimes emit a linkage name for a type, like:
+
+ <1d3> DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t
+
+ These names aren't very useful, and this patch changes the DWARF
+ reader so that they are ignored by the cooked index.
+
+2022-10-17 Tom Tromey <tromey@adacore.com>
+
+ Fix regression in c-linkage-name.exp with gdb index
+ c-linkage-name.exp started failing with the gdb-index target board due
+ to an earlier patch. The problem here is that some linkage names must
+ be in the index -- but, based on inspection, not C++ linkage names.
+ This patch updates the code to exclude only these.
+
+2022-10-17 TaiseiIto <taisei1212@outlook.jp>
+
+ Fix null pointer representations
+ Since "NULL" and "0" are used to represent invalid address in function
+ "gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified
+ them to "nullptr".
+
+2022-10-17 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: silence unused-but-set-variable warning about yynerrs in cp-name-parser.y
+ When building with clang 15 on Ubuntu 20.04, I get:
+
+ CXX cp-name-parser.o
+ cp-name-parser.c.tmp:1777:9: error: variable 'cpnameyynerrs' set but not used [-Werror,-Wunused-but-set-variable]
+ int yynerrs;
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:58:18: note: expanded from macro 'yynerrs'
+ #define yynerrs GDB_YY_REMAP (yynerrs)
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:40:29: note: expanded from macro 'GDB_YY_REMAP'
+ #define GDB_YY_REMAP(YYSYM) GDB_YY_REMAP_1 (GDB_YY_REMAP_PREFIX, YYSYM)
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:39:39: note: expanded from macro 'GDB_YY_REMAP_1'
+ #define GDB_YY_REMAP_1(PREFIX, YYSYM) GDB_YY_REMAP_2 (PREFIX, YYSYM)
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:38:39: note: expanded from macro 'GDB_YY_REMAP_2'
+ #define GDB_YY_REMAP_2(PREFIX, YYSYM) PREFIX ## YYSYM
+ ^
+ <scratch space>:45:1: note: expanded from here
+ cpnameyynerrs
+ ^
+
+ This is because clang 15 warns for something like this:
+
+ int n;
+ n = 0;
+ ++n;
+
+ whereas previous versions do not.
+
+ yynerrs is defined in yyparse and is there for actions to use. Since
+ the actions in cp-name-parser.y don't use it, we get a warning. We see
+ this problem on this particular .y file because it uses `%pure-parser`
+ [1], which makes yynerrs a local rather than a global.
+
+ I initially fixed this by using
+ DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE (like in commit f7aa1a5acc5
+ ("gold: Suppress "unused" variable warning on Clang")), but then I
+ realized we could suppress the warning in a more fine-grained way using
+ this in a rule:
+
+ (void) yynerrs;
+
+ [1] https://www.gnu.org/software/bison/manual/html_node/Error-Reporting-Function.html
+
+ Change-Id: I6cae7a4207c19fe1b719e2ac19be69122ebe3af1
+
+2022-10-17 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: consistently add board_ldflags when linking with GCC
+ Currently, the functions checking if the compiler is available or if a
+ feature is available add both board_cflags and board_ldflags.
+ However, functions running the tests only retrieve board_cflags. This
+ can lead to unexpected errors when mandaratory flags are defined in
+ board_ldflags and not board_cflags.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-unique/unique.exp: Add board_ldflags when
+ linking with GCC.
+ * testsuite/lib/ld-lib.exp: Likewise.
+
+2022-10-17 CaiJingtao <caijingtao@huawei.com>
+
+ Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}
+ Omitting predicate size specifier in vector form of {sq, uq, }{decp, incp} is deprecated and will be prohibited in a future release of the aarch64,
+ see https://developer.arm.com/documentation/ddi0602/2021-09/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-.
+
+ This allows explicit size specifier, e.g. `decp z0.h, p0.h`, for predicate operand of these SVE instructions.
+ The existing behaviour of not requiring the specifier is preserved.
+ And the disasembly is with the specifier with this patch.
+
+ The GAS tests passed under our local tests.
+
+ opcodes/
+ * aarch64-asm.c: Modify `sve_size_hsd` encoding.
+ * aarch64-tbl.h (aarch64_opcode_table): Add QUALS's type OP_SVE_Vv_HSD
+ for decp, incp, sqdecp, sqincp, uqdecp and uqincp.
+
+ gas/
+ * testsuite/gas/aarch64/sve-movprfx_23.s: Update movprfx_23 testcase's
+ test_sametwo macro, where take the predicate size specifier.
+ * testsuite/gas/aarch64/sve-movprfx_23.d: Update movprfx_23 testcase's
+ expected disassembly.
+ * testsuite/gas/aarch64/sve-movprfx_23.l: Update movprfx_23 testcase's
+ expected assembler messages.
+ * testsuite/gas/aarch64/sve.s: Add sve testcase's instructions for
+ decp, incp, sqdecp, sqincp, uqdecp and uqincp, which take the
+ predicate size specifier.
+ * testsuite/gas/aarch64/sve.d: Update sve testcase's expected
+ disassembly.
+
+2022-10-17 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak handling of F_STRICT
+ Current F_STRICT qualifier checking is enforced after the fact
+ rather than as part of the match. This makes it impossible to
+ have, e.g.:
+
+ QLF2(S_D, S_D)
+ QLF2(S_D, NIL)
+
+ in the same list.
+
+ opcodes/
+ * aarch64-opc.c (aarch64_find_best_match): Handle F_STRICT here
+ rather than...
+ (match_operands_qualifier): ...here.
+
+2022-10-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: properly decode EVEX.W for AVX512_4{FMAPS,VNNIW} insns
+ These require EVEX.W=0. Use %XS to facilitate the checking, even if for
+ the AVX512_4VNNIW ones this is kind of an abuse (as 's' there stands for
+ "signed", not "single").
+
+ While there also correct the 3rd operand for the AVX512_4VNNIW entries:
+ Only the memory form is allowed (just like for AVX512_4FMAPS, where the
+ correct type is already in use).
+
+2022-10-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold AVX512-VNNI disassembler entries with AVX-VNNI ones
+ Make %XV also print the separating blank in the VEX case, while making
+ it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries
+ can be re-used for AVX512-VNNI, at the same time fixing the lack of
+ EVEX.W decoding.
+
+ For the AVX-VNNI ones further make sure only VEX.66 forms are actually
+ decoded.
+
+2022-10-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-16 Tom Tromey <tom@tromey.com>
+
+ More uses of checked_static_cast
+ This patch changes a few more uses of static_cast to use
+ checked_static_cast. In this patch, cast-to-references are converted
+ by moving the dereference outside of the cast, as checked_static_cast
+ only handles pointers.
+
+2022-10-16 Tom Tromey <tom@tromey.com>
+
+ Use checked_static_cast in more places
+ I looked through all the uses of static_cast<... *> in gdb and
+ converted many of them to checked_static_cast.
+
+ I couldn't test a few of these changes.
+
+2022-10-16 Alan Modra <amodra@gmail.com>
+
+ PowerPC se_rfmci and VLE, SPE2 and LSP insns with -many
+ I noticed recently that se_rfmci, a VLE mode instruction, was being
+ accepted by non-VLE cpus, and also that se_rfmci by itself in a
+ section did not cause SHF_PPC_VLE to be set. ie. both testcases added
+ by this patch fail without the changes to tc-ppc.c here.
+
+ Also, VLE, SPE2 and LSP insns were not accepted by the assembler with
+ -many nor were SPE2 and LSP being disassembled with -Many.
+
+ gas/
+ * config/tc-ppc.c (ppc_setup_opcodes): Wrap long lines. Add
+ vle_opcodes when PPC_OPCODE_VLE or PPC_OPCODE_ANY. Simplify
+ disassembler index segment checks. Add LSP and SPE2 opcodes
+ when PPC_OPCODE_ANY too.
+ (md_assemble): Correct logic adding PPC_APUINFO_VLE and
+ SHF_PPC_VLE.
+ * testsuite/gas/ppc/se_rfmci.s
+ * testsuite/gas/ppc/se_rfmci.d,
+ * testsuite/gas/ppc/se_rfmci_bad.d: New tests.
+ * testsuite/gas/ppc/ppc.exp: Run them.
+ opcodes/
+ * ppc-dis.c (print_insn_powerpc): Disassemble SPE2 and LSP insn
+ when -Many.
+ * ppc-opc.c (vle_opcodes <se_rfmci>): Comment.
+
+2022-10-16 Alan Modra <amodra@gmail.com>
+
+ zlib-gabi to zstd woes
+ So we had a zlib-gabi .debug_info section that increased in size with
+ zstd, so much so that it was better to leave the section
+ uncompressed. Things went horribly wrong when the section was read
+ again later. The section was read again off disk using the
+ uncompressed size. So you get the zlib section again with some
+ garbage at the end. Fix that particular problem by setting the
+ section flag SEC_IN_MEMORY. Any future read will get sec->contents.
+
+ Also, if the section is to be left uncompressed, the input
+ SHF_COMPRESSED flag needs to be reset otherwise objcopy will copy it
+ to output.
+
+ Finally, bfd_convert_section_contents needed a small update to handle
+ zstd compressed sections, and I've deleted bfd_cache_section_contents.
+
+ * bfd.c (bfd_convert_section_contents): Handle zstd.
+ * compress.c (bfd_compress_section_contents): When section
+ contents are uncompressed set SEC_IN_MEMORY flag,
+ compress_status to COMRESS_SECTION_NONE, and clear
+ SHF_COMPRESSED. Set SEC_IN_MEMORY for compressed contents.
+ (bfd_get_full_section_contents): Don't check section size
+ against file size when SEC_IN_MEMORY.
+ (bfd_cache_section_contents): Delete function.
+ * elf32-arm.c (elf32_arm_get_synthetic_symtab): Expand
+ bfd_cache_section_contents here.
+ * bfd-in2.h: Regenerate.
+
+2022-10-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-15 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Don't rely on loop detection to stop unwinding
+ Setting SP of the next frame to the same address as the current frame
+ is an ugly way to stop the unwinding. A cleaner way is to rely on
+ the frame_unwind_stop_reason function to return UNWIND_OUTERMOST.
+
+2022-10-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add boards/README
+ Add a file gdb/testsuite/boards/README, to make it easier to get a high-level
+ overview of the various boards.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/contrib] Handle STRIP_ARGS_{STRIP,KEEP}_DEBUG in cc-with-tweaks.sh
+ Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to
+ --strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily
+ reproduce the PR29277 assert using:
+ ...
+ $ export STRIP_ARGS_STRIP_DEBUG=--strip-all
+ $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
+ --target_board cc-with-gnu-debuglink"
+ ...
+
+ For completeness sake and to avoid confusion about which of the two used strip
+ invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG,
+ defaulting to --only-keep-debug.
+
+ Script checked with shellcheck, no new warnings added.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix heap-buffer-overflow in find_program_interpreter
+ With the test-case included in this patch, we run into:
+ ...
+ (gdb) target remote localhost:2347^M
+ `target:twice-connect' has disappeared; keeping its symbols.^M
+ Remote debugging using localhost:2347^M
+ warning: Unable to find dynamic linker breakpoint function.^M
+ GDB will be unable to debug shared library initializers^M
+ and track explicitly loaded dynamic code.^M
+ Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
+ 0x00007ffff7dd4550 in ?? ()^M
+ (gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
+ FAIL: gdb.server/twice-connect.exp: found interpreter
+ ...
+
+ The problem originates in find_program_interpreter, where
+ bfd_get_section_contents is called to read .interp, but fails. The function
+ returns false but the result is ignored, so find_program_interpreter returns
+ some random string.
+
+ Fix this by checking the result of the call to bfd_get_section_contents.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/unittest.exp with host board local-remote-host.exp
+ With test-case gdb.server/unittest.exp and host board local-remote-host.exp I
+ run into:
+ ...
+ builtin_spawn build/gdbserver/gdbserver --selftest^M
+ ERROR: : spawn id exp7 not open
+ while executing
+ "expect {
+ -i exp7 -timeout 10
+ -i $server_spawn_id
+ -re "Ran ($decimal) unit tests, 0 failed" {
+ set num_ran $expect_out(1,string)
+ gdb_assert "..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE : spawn id exp7 not open
+ UNRESOLVED: gdb.server/unittest.exp: unit tests
+ ...
+
+ The problem is (as fixed for avr in commit df5b8876083 ("gdb/testsuite: better
+ handle failures in simavr board, reap simavr process")), that gdb_expect through
+ remote_expect adds a "-i <gdb spawn id> -timeout 10", which is the one causing
+ the error.
+
+ As in aforementioned commit, fix this by using expect instead.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts
+ With test-case gdb.server/stop-reply-no-thread-multi.exp and host board
+ local-remote-host-notty.exp we occasionally run into a silent out, due to
+ getting:
+ ...
+ (gdb) kill^M
+ (gdb) The program is not being run.^M
+ ...
+ instead of the expected:
+ ...
+ (gdb) kill^M
+ The program is not being run.^M
+ (gdb)
+ ...
+
+ Likewise, we occasionally run into a nonsilent timeout:
+ ...
+ (gdb) disconnect^M
+ (gdb) You can't do that when your target is `exec'^M
+ FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \
+ disconnect (timeout)
+ ...
+
+ Typically, this results in the test-case taking more than two minutes to run.
+
+ The problem can be reproduced using just:
+ ...
+ $ ssh -l $USER 127.0.0.1 gdb -q -ex kill
+ ...
+
+ Note that ssh by default uses -T which disables pseudo-tty allocation (as
+ opposed to -t which forces pseudo-tty allocation):
+ ...
+ $ ssh -l $USER 127.0.0.1 -T tty
+ not a tty
+ $ ssh -l $USER 127.0.0.1 -t tty
+ /dev/pts/5
+ Connection to 127.0.0.1 closed.
+ ...
+ and according to https://stackoverflow.com/a/63241102 the behaviour we're
+ seeing is specific to using '-T'.
+
+ The related host board local-remote-host.exp does use '-t', and the only
+ difference between the two boards mentioned is whether editing is on or off.
+
+ Fix this by:
+ - moving the content of local-remote-host-notty.exp into
+ local-remote-host.exp
+ - consequently, extending the copyright years in local-remote-host.exp
+ - including local-remote-host.exp in local-remote-host-notty.exp
+ (making local-remote-host-notty.exp use '-t')
+ - adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp
+
+ This results in the test-case taking just 6 seconds to run.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Disable styling in host board local-remote-host.exp
+ With test-case gdb.server/stop-reply-no-thread.exp and host board
+ local-remote-host.exp, I run into:
+ ...
+ Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M
+ 21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M
+ (gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \
+ continue to main
+ ...
+
+ The problem is that styling is enabled, and that is causing a regexp mismatch.
+
+ With native, styling is disabled in default_gdb_init by doing
+ 'setenv TERM "dumb"', but that only has effect because the build (where we
+ execute runtest, and consequently the setenv) and the host (where we execute
+ gdb) are the same. For this host board however, gdb executes on a remote
+ host, and the setenv has no effect.
+
+ We could try to make some generic way to set TERM on the host, but for the
+ purposes of this test-case it seems sufficient to just add:
+ ...
+ set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\""
+ ...
+ so let's go with that for now.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom Tromey <tromey@adacore.com>
+
+ Use scoped_value_mark in more places
+ I looked at all the spots using value_mark, and converted all the
+ straightforward ones to use scoped_value_mark instead.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-10-14 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Stop unwinding on error, but do not assert
+ When it's impossible to read the FPCCR and XPSR, the unwinding is
+ unpredictable as the it's not possible to determine the correct
+ frame size or padding.
+ The only sane thing to do in this condition is to stop the unwinding.
+
+ Example session without this patch:
+
+ (gdb) bt
+ #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
+ .../gdb/arm-tdep.c:3594: internal-error: arm_m_exception_cache: Assertion `safe_read_memory_unsigned_integer (FPCCR, ARM_INT_REGISTER_SIZE, byte_order, &fpccr)' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x5583bfb2a157 gdb_internal_backtrace_1
+ ...
+ ---------------------
+
+ This is a bug, please report it. For instructions, see:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ Aborted (core dumped)
+
+ Example session with this patch:
+
+ (gdb) bt
+ #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
+ warning: Could not fetch required FPCCR content. Further unwind is impossible.
+ #1 <signal handler called>
+ (gdb)
+
+ Reviewed-by: Pedro Alves <pedro@palves.net>
+
+2022-10-14 Alan Modra <amodra@gmail.com>
+
+ PowerPC SPE disassembly and tests
+ Where sub and subf forms of an instruction exist we generally
+ disassemble to the extended insn sub form rather than the underlying
+ machine subf instruction. Do so for SPE evsubw and evsubiw too.
+
+ spe_ambiguous.d always was a bit too optimistic. There is no sensible
+ way to disassemble identical bytes back to different and original
+ source. Instead change the test to check -Mraw results.
+
+ gas/
+ * testsuite/gas/ppc/ppc.exp: Run spe_ambiguous test.
+ * testsuite/gas/ppc/spe.d: Expect evsubw and evsubiw rather than
+ evsubfw and evsubifw.
+ * testsuite/gas/ppc/spe_ambiguous.s: Test evnor form equivalent
+ to evnot.
+ * testsuite/gas/ppc/spe_ambiguous.d: Test Mraw.
+ opcodes/
+ * ppc-opc.c (powerpc_opcodes): Move evsubw before evsubfw and
+ evsubiw before evsubifw and mark EXT.
+
+2022-10-14 Alan Modra <amodra@gmail.com>
+
+ e200 LSP support
+ It has bothered me for a long time that we have disabled LSP (and SPE)
+ tests. Also the LSP test comment indicating there is something wrong
+ with get_powerpc_dialect. I don't think there is. Decoding of a VLE
+ instruction depends on whether the processor is in VLE mode (some
+ processors support both VLE and standard PPC) which we flag per
+ section with SHF_PPC_VLE for decoding when disassembling.
+
+ Background: Some versions of powerpc e200 have "Lightweight Signal
+ Processing" support, examples being e200z215 and e200z425. As far as
+ I can tell, LSP and SPE are mutually exclusive. This seems to be
+ borne out by insn encoding, for example LSP "zvaddih" and SPE "evaddw"
+ have the same encoding. So none of the processor descriptions in
+ ppc_opts ought to have both PPC_OPCODE_LSP and PPC_OPCODE_SPE/2, if we
+ want disassembly to work. I also could not find anything to suggest
+ that the LSP insns are enabled only in VLE mode, which means the LSP
+ insns should not be in vle_opcodes.
+
+ Fix all this by moving the LSP insns to their own table, and add a new
+ e200z2 cpu entry with LSP support, removing LSP from -me200z4 and from
+ -mvle. (Yes, I know, as I said above some of the e200z4 processors
+ have LSP. Others have SPE. It's hard to choose good options. Think
+ of z2 as meaning earlier, z4 as later.) Also add -mlsp to allow
+ adding the LSP insn set.
+
+ include/
+ * opcode/ppc.h (lsp_opcodes, lsp_num_opcodes): Declare.
+ (LSP_OP_TO_SEG): Define.
+ binutils/
+ * doc/binutils.texi: Update ppc docs.
+ gas/
+ * config/tc-ppc.c (ppc_setup_opcodes): Add lsp opcodes to ppc_hash.
+ * doc/c-ppc.texi: Document e200 and lsp.
+ * testsuite/gas/ppc/lsp-checks.d: Assemble with -me200z2.
+ * testsuite/gas/ppc/lsp.d: Likewise, disassembly too.
+ * testsuite/gas/ppc/ppc.exp: Don't xfail lsp test.
+ opcodes/
+ * ppc-dis.c (ppc_opts): Add e200z2 and lsp. Don't set
+ PPC_OPCODE_LSP for e200z4 or vle.
+ (ppc_parse_cpu): Mutually exclude LSP and SPE.
+ (LSP_OPCD_SEGS): Define.
+ (lsp_opcd_indices): New array.
+ (disassemble_init_powerpc): Init lsp_opcd_indices.
+ (lookup_lsp): New function.
+ (print_insn_powerpc): Call it.
+ * ppc-opc.c: Include libiberty.h for ARRAY_SIZE and use throughout.
+ (vle_opcodes): Move LSP opcodes to..
+ (lsp_opcodes): ..here, and sort.
+ (lsp_num_opcodes): New.
+
+2022-10-14 Alan Modra <amodra@gmail.com>
+
+ PR29677, Field `the_bfd` of `asymbol` is uninitialised
+ Besides not initialising the_bfd of synthetic symbols, counting
+ symbols when sizing didn't match symbols created if there were any
+ dynsyms named "". We don't want synthetic symbols without names
+ anyway, so get rid of them. Also, simplify and correct sanity checks.
+
+ PR 29677
+ * mach-o.c (bfd_mach_o_get_synthetic_symtab): Rewrite.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Drop unnecessary -Wl,-soname in gdb.base/skip-solib.exp
+ I noticed in gdb.base/skip-solib.exp:
+ ...
+ if {[gdb_compile_shlib ${srcdir}/${subdir}/${srcfile_lib} ${binfile_lib} \
+ [list debug -Wl,-soname,${libname}.so]] != ""} {
+ return -1
+ }
+ ...
+ that the -Wl,-soname argument is missing an ldflags= prefix, but adding it
+ gives us a duplicate:
+ ...
+ Executing on host: gcc -fno-stack-protector \
+ outputs/gdb.base/skip-solib/skip-solib-lib.c.o -fdiagnostics-color=never \
+ -shared -g -Wl,-soname,libskip-solib.so -Wl,-soname,libskip-solib.so -lm \
+ -o outputs/gdb.base/skip-solib/libskip-solib.so (timeout = 300)
+ ...
+ so apparently it's taken care of by gdb_compile_shlib.
+
+ Drop the inactive and also unnecessary -Wl,-soname,${libname}.so from the
+ flags list for the gdb_compile_shlib call.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with PIE
+ With test-case gdb.base/infoline-reloc-main-from-zero.exp and target board
+ unix/-fPIE/-pie I run into:
+ ...
+ gdb compile failed, ld: infoline-reloc-main-from-zero: error: \
+ PHDR segment not covered by LOAD segment
+ collect2: error: ld returned 1 exit status
+ ...
+
+ When running with native, I find that the executable is static:
+ ...
+ $ file infoline-reloc-main-from-zero
+ infoline-reloc-main-from-zero: ELF 64-bit LSB executable, x86-64, \
+ version 1 (SYSV), statically linked, BuildID[sha1]=$hex, with debug_info, \
+ not stripped
+ ...
+ despite not having been compiled with -static.
+
+ Fix the compilation by adding -static to the compilation flags.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with clang
+ With test-case gdb.base/infoline-reloc-main-from-zero.exp and clang I run into:
+ ...
+ gdb compile failed, clang-13.0: warning: -e main: 'linker' input unused \
+ [-Wunused-command-line-argument]
+ clang-13.0: warning: -Wl,-Ttext=0x00: 'linker' input unused \
+ [-Wunused-command-line-argument]
+ clang-13.0: warning: -Wl,-N: 'linker' input unused \
+ [-Wunused-command-line-argument]
+ UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
+ infoline-reloc-main-from-zero.exp
+ UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
+ ...
+
+ Fix this by using ldflags instead of additional_flags.
+
+ Likewise, fix all occurrences of:
+ ...
+ $ find gdb/testsuite -name *.exp | xargs grep additional_flags.*Wl
+ ...
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix nopie test-cases with target board unix/-fPIE/-pie
+ Compilers default to either PIE or no-PIE executables.
+
+ In order to test PIE executables with a compiler that produces non-PIE by
+ default, we can use target board unix/-fPIE/-pie, which set the multilib_flags
+ of the target board to "-fPIE -pie".
+
+ Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that
+ produces PIE by default.
+
+ The target board unix/-fno-PIE/-no-pie has a potential problem when compiling
+ shared libs, because the multilib_flags will override the attempts of
+ gdb_compile_shlib to compile with -fPIC. This is taken care of by running the
+ body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered.
+
+ The target board unix/-fPIE/-pie has a problem with nopie compilations. The
+ current approach is to do the compilation hoping for the best, and if we find
+ out that the resulting executable is PIE despite specifying nopie, we error
+ out with the standard error message "nopie failed to prevent PIE executable".
+
+ That however does not work for hard-coded assembly nopie test-cases, which will
+ just noisily refuse to compile:
+ ...
+ ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \
+ used when making a PIE object; recompile with -fPIE^M
+ ...
+
+ Fix this in gdb_compile by filtering out the PIE settings in the target board
+ multilib_flags when pie or nopie is specified.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Factor out with_PIE_multilib_flags_filtered
+ Factor out new procs with_PIE_multilib_flags_filtered and
+ with_multilib_flags_filtered from proc gdb_compile_shlib.
+
+ Tested on x86_64-linux.
+
+2022-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add cond_wrap proc
+ Add a new proc cond_wrap, that can be used to replace the repetitive:
+ ...
+ if { $cond } {
+ wrap {
+ <body>
+ }
+ } else {
+ <body>
+ }
+ ...
+ with the shorter:
+ ...
+ cond_wrap $cond wrap {
+ <body>
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+2022-10-14 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb: add Torbjörn Svensson to gdb/MAINTAINERS
+
+2022-10-14 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: Zicbo{m,p,z} adjustments to riscv_multi_subset_supports_ext()
+ The lack thereof did caused gas to issue "internal: unreachable
+ INSN_CLASS_*" errors when trying to assemble respective insns without
+ the feature(s) enabled via e.g. ".option arch, ...". Of course a proper
+ hint towards the missing extension then wasn't given either.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Imply 'Zicsr' from privileged extensions with CSRs
+ 'H', 'Smstateen', 'Sscofpmf' and 'Sstc' are four privileged extensions with
+ their CSR definitions and 'Smepmp' is a privileged extension with additional
+ CSR bits.
+
+ Volume II: Privileged Architecture of the RISC-V ISA Manual states that the
+ privileged architecture requires the 'Zicsr' extension. However, current
+ GNU Binutils has no direct way whether the program has dependency to the
+ privileged architecture itself.
+
+ As a workaround, we should add implications from privileged extensions that
+ either add new CSRs, extend existing CSRs or depends on using CSRs.
+
+ This commit adds such implications for existing privileged extensions that
+ satisfy this condition.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-imply-h.d: New test, at least for 'H'.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zicsr'
+ implicications for privileged extensions 'H', 'Smstateen',
+ 'Sscofpmf', 'Sstc' and 'Smepmp'.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes/riscv-dis.c: Remove last_map_state
+ Before changing the core disassembler, we take care of minor code clarity
+ issues and improve readability.
+
+ This commit removes unused variable last_map_state (set by the
+ print_insn_riscv function but not read anywhere else).
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (last_map_state): Remove.
+ (print_insn_riscv): Remove setting last_map_state.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes/riscv-dis.c: Make XLEN variable static
+ Before changing the core disassembler, we take care of minor code clarity
+ issues and improve readability.
+
+ Since xlen variable is not (and should not) used outside riscv-dis.c,
+ this commit makes this variable static.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (xlen): Make this variable static.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes/riscv-dis.c: Use bool type whenever possible
+ Before changing the core disassembler, we take care of minor code clarity
+ issues and improve readability.
+
+ This commit replaces uses of int with bool whenever possible.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (no_aliases) Change type to bool.
+ (set_default_riscv_dis_options): Use boolean.
+ (parse_riscv_dis_option_without_args): Likewise.
+ (riscv_disassemble_insn): Use boolean keywords.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes/riscv-dis.c: Tidying with spacing
+ Before changing the core disassembler, we take care of minor code clarity
+ issues and improve readability.
+
+ This commit takes care of improper spacing for code clarity.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_insn): Tidying with spacing.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes/riscv-dis.c: Tidying with comments/clarity
+ Before changing the core disassembler, we take care of minor code clarity
+ issues and improve readability.
+
+ First, we need to clarify the roles of variables and code portions.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (xlen): Move before default_isa_spec. Add comment.
+ (default_isa_spec, default_priv_spec): Add comment.
+ (riscv_gpr_names, riscv_fpr_names): Likewise.
+ (parse_riscv_dis_option_without_args): Likewise.
+ (parse_riscv_dis_option, parse_riscv_dis_options): Likewise.
+ (maybe_print_address): Likewise.
+ (riscv_disassemble_insn): Fix comment about the Zfinx "extension".
+ Add comment about the riscv_multi_subset_supports call.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Test DWARF register number for "fp"
+ This commit adds "fp" (x8 or s0) to dw-regnums.{s,d}.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/dw-regnums.s: Add "fp".
+ * testsuite/gas/riscv/dw-regnums.d: Likewise.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Move standard hints before all instructions
+ Because all standard hints must be placed before corresponding instruction
+ for the disassembler, they may taint basic RVI instruction section.
+
+ This commit moves all standard hints before all basic RVI instructions
+ to improve maintainability.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Move all standard hints before all
+ standard instructions.
+
+2022-10-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Move certain arrays to riscv-opc.c
+ This is a part of small tidying (declare tables in riscv-opc.c).
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (riscv_rm, riscv_pred_succ): Move declarations to
+ opcodes/riscv-opc.c. New non-static definitions.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_rm, riscv_pred_succ): Move from
+ include/opcode/riscv.h. Add description.
+
+2022-10-14 Fangrui Song <i@maskray.me>
+
+ ld: Add --undefined-version
+ This cancels a previous --no-undefined-version.
+ gold has had --undefined-version for a long time.
+
+2022-10-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-13 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix gdb.base/watchpoint.exp on Power 9
+ Test gdb.base/watchpoint.exp generates 4 test errors on Power 9. The
+ test uses the test [target_info exists gdb,no_hardware_watchpoints] to
+ determine if the processor supports hardware watchpoints. The check
+ only examines the processor type to determine if it supports hardware
+ watchpoints.
+
+ The PowerPC processors support hardware watchpoints with the
+ exception of Power 9. The hardware watchpoint support is disabled on
+ Power 9. The test skip_hw_watchpoint_tests must be used to correctly
+ determine if the PowerPC processor supports hardware watchpoints.
+
+ This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
+ with the skip_hw_watchpoint_tests_p check. With the patch, the test runs
+ on Power 9 with hardware watchpoint force-disabled. The test runs on
+ all other PowerPC processors with and without hardware watchpoints
+ enabled.
+
+ The patch has been tested on Power 9 to verify the test only runs with
+ hardware breakpoints disabled. The patch has been tested on X86-64 with
+ no regression failures. The test fails on Power 10 due to an internal GDB
+ error due to resource management. The resource management issue will be
+ addressed in another patch.
+
+2022-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/macro-source-path.exp with -m32
+ With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
+ run into:
+ ...
+ as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
+ unsupported relocation type: 0x1^M
+ ...
+
+ The problem is that we have 64-bit dwarf so the debug_line offset in the
+ .debug_macro section is an 8-byte entity, emitted using ".8byte":
+ ...
+ .section .debug_macro
+ .Lcu_macros4:
+ .2byte 5 /* version */
+ .byte 3 /* flags */
+ .8byte .LLlines3 /* debug_line offset */
+ ...
+ but the linker doesn't support 8-byte relocation types on a 32-bit architecture.
+
+ This is similar to what was fixed in commit a5ac8e7fa3b
+ ("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
+ .debug_abbrev.
+
+ Fix this in the same way, by using _op_offset to emit the debug_line offset.
+
+ Tested on x86_64-linux with native and target board unix/-m32.
+
+2022-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/entry-value-typedef.exp with -m32
+ With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32,
+ I run into:
+ ...
+ builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \
+ gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \
+ -fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \
+ -o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M
+ entry-value-typedef.cpp: Assembler messages:^M
+ entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M
+ ...
+
+ The problem is that the test-cases selects an amd64 .S file based on the check:
+ ...
+ if { [istarget "x86_64-*-linux*"] } {
+ ...
+ which is also true for target board unix/-m32 on x86_64-linux.
+
+ Fix this by adding the missing is_lp64_target check.
+
+ Tested on x86_64-linux, using native and target board unix/-m32.
+
+2022-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with -m32
+ With target board unix/-m32 and test-case gdb.mi/mi-disassemble.exp we have:
+ ...
+ (gdb) ^M
+ print/x *((unsigned char *) 0x8048485)^M
+ &"print/x *((unsigned char *) 0x8048485)\n"^M
+ ~"$9 = 0x83\n"^M
+ ^done^M
+ (gdb) ^M
+ PASS: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x8048485)"
+ FAIL: gdb.mi/mi-disassemble.exp: byte at 0x8048485 matches
+ ...
+ The test-case passes with native.
+
+ With native we see in gdb.log that variable longest_insn_bytes is:
+ ...
+ Longest instruction at 0x0000000000400549 with bytes '48 8b 05 20 01 00 00'
+ ...
+ and variable split_bytes (added debug puts) ends up as:
+ ...
+ SPLIT_BYTES: 48 8b 05 20 01 00 00
+ ...
+
+ But with unix/-m32 we have longest_insn_byte:
+ ...
+ Longest instruction at 0x08048481 with bytes '8d 4c 24 04 '
+ ...
+ and split_bytes ends up as:
+ ...
+ SPLIT_BYTES: 8d 4c 24 04 {} {} {} {} {} {} {} {}
+ ...
+ so the trailing whitespace is translated by split to empty bytes, and the
+ mismatch FAILs are generated for those.
+
+ Fix this by stripping the whitespace, which makes us end up with a different
+ and indeed longer insn:
+ ...
+ Longest instruction at 0x08048492 with bytes 'dd 05 98 85 04 08'
+ ...
+
+ Tested on x86_64-linux, with native and target board unix/-m32.
+
+2022-10-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-12 Carl Love <cel@us.ibm.com>
+
+ PowerPC, fix test gdb.base/watchpoint-stops-at-right-insn.exp
+ Test gdb.base/watchpoint-stops-at-right-insn.exp generates 4 test errors
+ on Power 9. The test uses the test [target_info exists gdb,
+ no_hardware_watchpoints] to determine if the processor supports hardware
+ watchpoints. The check only examines the processor type to determine if
+ it supports hardware watchpoints. Note, the test works fine on Power 10.
+
+ The PowerPC processors support hardware watchpoints with the
+ exception of Power 9. The hardware watchpoint support is disabled on
+ Power 9. The test skip_hw_watchpoint_tests must be used to correctly
+ determine if the PowerPC processor supports hardware watchpoints.
+
+ This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
+ with the skip_hw_watchpoint_tests_p check. With the patch, the test is
+ disabled on Power 9 but runs on all other PowerPC processors.
+
+ The patch has been tested on Power 9, Power 10 and X86-64 with no
+ regression failures.
+
+2022-10-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop "regmask" static variable
+ Replace its two uses by more direct checks, paralleling what's already
+ there for SIMD registers.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Factor out elf_symfile_read_dwarf2
+ Factor out elf_symfile_read_dwarf2 from elf_symfile_read. NFC.
+
+ Tested on x86_64-linux.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed
+ When running test-case gdb.base/ctf-constvars.exp on openSUSE Tumbleweed (with
+ system gcc version 12, providing gcc -gctf support, enabling the ctf test-cases
+ in the gdb testsuite), I run into:
+ ...
+ (gdb) print vox^M
+ 'vox' has unknown type; cast it to its declared type^M
+ (gdb) FAIL: gdb.base/ctf-constvars.exp: print vox
+ ...
+
+ There are two causes for this:
+ - the linker flags are missing --ctf-variables, so the information for variable
+ vox is missing (reported in PR29468), and
+ - the executable contains some dwarf2 due to some linked-in glibc objects,
+ so the ctf info is ignored (reported in PR29160).
+
+ By using:
+ - -Wl,--ctf-variable,
+ - -Wl,--strip-debug, and
+ we can make the test-case and some similar test-cases pass.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29160
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29468
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Silence warnings about obsolete -gstabs
+ When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with
+ gcc 12) I get:
+ ...
+ gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \
+ STABS debugging information is obsolete and not supported anymore
+ ...
+
+ Silence the warning by passing quiet to gdb_compile. Likewise in two other
+ test-cases.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Replace remaining -gt with -gctf
+ With test-cases gdb.base/cvexpr.exp and gdb.base/whatis.exp I run into:
+ ...
+ gdb compile failed, gcc: error: unrecognized debug output level 't'
+ ...
+
+ This is due to using additional_flags=-gt.
+
+ Commit ffb3f587933 ("CTF: multi-CU and archive support") replaced
+ additional_flags=-gt with additional_flags=-gctf in gdb.ctf/*.exp and
+ gdb.base/ctf-*.exp.
+
+ Do the same in these two test-cases.
+
+ Tested on x86_64-linux.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with recent ld
+ On openSUSE Tumbleweed (with ld 2.39) and test-case
+ gdb.base/infoline-reloc-main-from-zero.exp, I get:
+ ...
+ gdb compile failed, ld: warning: infoline-reloc-main-from-zero has a LOAD \
+ segment with RWX permissions
+ UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
+ infoline-reloc-main-from-zero.exp
+ ...
+
+ Fix this by compiling with -Wl,--no-warn-rwx-segments.
+
+ Tested on x86_64-linux.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/nested-subp{2,3}.exp with recent ld
+ On openSUSE Tumbleweed (with ld 2.39) I get for test-case
+ gdb.base/nested-subp2.exp:
+ ...
+ gdb compile failed, ld: warning: tmp.o: requires executable stack \
+ (because the .note.GNU-stack section is executable)
+ ...
+
+ Fix this by compiling with -Wl,--no-warn-execstack.
+
+ Likewise in gdb.base/nested-subp3.exp
+
+ Tested on x86_64-linux.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove unnecessary perror in some test-cases
+ On openSUSE Tumbleweed I noticed:
+ ...
+ UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp
+ ERROR: failed to compile fission-absolute-dwo
+ ...
+
+ The ERROR is unnecessary, given that an UNTESTED is already emitted.
+
+ Furthermore, it could be argued that it is incorrect because it's not a
+ testsuite error to not be able to compile something, and UNTESTED or
+ UNSUPPORTED is more appropriate.
+
+ Remove the perror call, likewise in fission-relative-dwo.exp.
+
+ Tested on x86_64-linux.
+
+2022-10-12 Nick Clifton <nickc@redhat.com>
+
+ Fix objcopy's error message when it cannot add a .gnu_debuglink section because the section already exists.
+ PR 29665
+ * objcopy.c (copy_object): Use the input filename when
+ reporting that a .gnu_debuglink section already exists.
+
+2022-10-12 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/ppc: Fix core_find_mapping diagnostics
+ Because "%p" is the pointer conversion specifier to print a pointer in an
+ implementation-defined manner, the result with format string containing
+ "0x%p" can be strange. For instance, core_map_find_mapping prints error
+ containing "0x0x...." (processor is not NULL) or "0x(null)" (processor is
+ NULL) on glibc.
+
+ This commit replaces "0x%p" with "%p" to prevent unpredictable behavior.
+
+2022-10-12 Andrew Burgess <aburgess@redhat.com>
+
+ sim/ppc: fixes for arguments to printf style functions
+ After the recent series of fixes to mark more functions in the
+ simulator with ATTRIBUTE_PRINTF, there were some build failures in the
+ ppc sim due, in some cases, to bugs with the arguments being passed,
+ and in other cases, the issues were (maybe) less serious, with
+ arguments being the wrong size, or type, for the printf format being
+ used.
+
+ This commit fixes all of the issues that I ran into.
+
+ In each case I selected the easiest solution to the problem, which is
+ usually just casting the argument to the correct type. If anyone
+ later on thinks the print format should change, please feel free to do
+ that. What we have here should keep the simulator basically working
+ as it does currently, which is my goal with this commit.
+
+2022-10-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/contrib] Use OBJCOPY everywhere in cc-with-tweaks.sh
+ I noticed that the $want_gnu_debuglink code in gdb/contrib/cc-with-tweaks.sh
+ uses objcopy instead of $OBJCOPY. Fix this.
+
+ Script checked with shellcheck, no new warnings added.
+
+ Tested on x86_64-linux.
+
+2022-10-12 Simon Marchi <simon.marchi@efficios.com>
+
+ Re-apply "Pass PKG_CONFIG_PATH down from top-level Makefile"
+ Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the
+ change originally done in de83289ef32e ("Pass PKG_CONFIG_PATH down from
+ top-level Makefile"). Re-apply it.
+
+ Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
+
+2022-10-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: rename target_read_auxv(target_ops *) to target_read_auxv_raw
+ Having two overloads of target_read_auxv that don't have the same goals
+ is confusing. Rename the one that reads from an explicit target_ops to
+ target_read_auxv_raw. Also, it occured to me that the non-raw version
+ could use the raw version, that reduces duplication a bit.
+
+ Change-Id: I28e5f7cecbfcacd0174d4686efb3e4a23b4ad491
+
+2022-10-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-12 Alan Modra <amodra@gmail.com>
+
+ Re: Merge configure.ac from gcc project
+ Also copy over config.acx.m4, and regenerate.
+
+2022-10-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix auxv caching
+ There's a flaw in the interaction of the auxv caching and the fact that
+ target_auxv_search allows reading auxv from an arbitrary target_ops
+ (passed in as a parameter). This has consequences as explained in this
+ thread:
+
+ https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
+
+ In summary, when loading an AArch64 core file with MTE support by
+ passing the executable and core file names directly to GDB, we see the
+ MTE info:
+
+ $ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
+ ...
+ Program terminated with signal SIGSEGV, Segmentation fault
+ Memory tag violation while accessing address 0x0000ffff8ef5e000
+ Allocation tag 0x1
+ Logical tag 0x0.
+ #0 0x0000aaaade3d0b4c in ?? ()
+ (gdb)
+
+ But if we do it as two separate commands (file and core) we don't:
+
+ $ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
+ ...
+ Program terminated with signal SIGSEGV, Segmentation fault.
+ #0 0x0000aaaade3d0b4c in ?? ()
+ (gdb)
+
+ The problem with the latter is that auxv data gets improperly cached
+ between the two commands. When executing the file command, auxv gets
+ first queried here, when loading the executable:
+
+ #0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
+ #1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
+ #2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
+ #3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
+ #4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
+ #5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
+ #6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
+ #7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
+ #8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
+ #9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
+ #10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
+ #11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
+ #12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
+ #13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
+ #14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
+ #15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
+
+ Here, target_auxv_search is called on the inferior's target stack. The
+ target stack only contains the exec target, so the query returns empty
+ auxv data. This gets cached for that inferior in `auxv_inferior_data`.
+
+ In its constructor (before it is pushed to the inferior's target stack),
+ the core_target needs to identify the right target description from the
+ core, and for that asks the gdbarch to read a target description from
+ the core file. Because some implementations of
+ gdbarch_core_read_description (such as AArch64's) need to read auxv data
+ from the core in order to determine the right target description, the
+ core_target passes a pointer to itself, allowing implementations to call
+ target_auxv_search it. However, because we have previously cached
+ (empty) auxv data for that inferior, target_auxv_search searched that
+ cached (empty) auxv data, not auxv data read from the core. Remember
+ that this data was obtained by reading auxv on the inferior's target
+ stack, which only contained an exec target.
+
+ The problem I see is that while target_auxv_search offers the
+ flexibility of reading from an arbitrary (passed as an argument) target,
+ the caching doesn't do the distinction of which target is being queried,
+ and where the cached data came from. So, you could read auxv from a
+ target A, it gets cached, then you try to read auxv from a target B, and
+ it returns the cached data from target A. That sounds wrong. In our
+ case, we expect to read different auxv data from the core target than
+ what we have read from the target stack earlier, so it doesn't make
+ sense to hit the cache in this case.
+
+ To fix this, I propose splitting the code paths that read auxv data from
+ an inferior's target stack and those that read from a passed-in target.
+ The code path that reads from the target stack will keep caching,
+ whereas the one that reads from a passed-in target won't. And since,
+ searching in auxv data is independent from where this data came from,
+ split the "read" part from the "search" part.
+
+ From what I understand, auxv caching was introduced mostly to reduce
+ latency on remote connections, when doing many queries. With the change
+ I propose, only the queries done while constructing the core_target
+ end up not using cached auxv data. This is fine, because there are just
+ a handful of queries max, done at this point, and reading core files is
+ local.
+
+ The changes to auxv functions are:
+
+ - Introduce 2 target_read_auxv functions. One reads from an explicit
+ target_ops and doesn't do caching (to be used in
+ gdbarch_core_read_description context). The other takes no argument,
+ reads from the current inferior's target stack (it looks just like a
+ standard target function wrapper) and does caching.
+
+ The first target_read_auxv actually replaces get_auxv_inferior_data,
+ since it became a trivial wrapper around it.
+
+ - Change the existing target_auxv_search to not read auxv data from the
+ target, but to accept it as a parameter (a gdb::byte_vector). This
+ function doesn't care where the data came from, it just searches in
+ it. It still needs to take a target_ops and gdbarch to know how to
+ parse auxv entries.
+
+ - Add a convenience target_auxv_search overload that reads auxv
+ data from the inferior's target stack and searches in it. This
+ overload is useful to replace the exist target_auxv_search calls that
+ passed the `current_inferior ()->top_target ()` target and keep the
+ call sites short.
+
+ - Modify parse_auxv to accept a target_ops and gdbarch to use for
+ parsing entries. Not strictly related to the rest of this change,
+ but it seems like a good change in the context.
+
+ Changes in architecture-specific files (tdep and nat):
+
+ - In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
+ similar to target_auxv_search. One version receives auxv data,
+ target and arch as parameters. The other gets everything from the
+ current inferior. The latter is for convenience, to avoid making
+ call sites too ugly.
+
+ - Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
+ use either of the new versions. The call sites in
+ gdbarch_core_read_description context explicitly read auxv data from
+ the passed-in target and call the linux_get_hwcap{,2} function with
+ parameters. Other call sites use the versions without parameters.
+
+ - Same idea for arm_fbsd_read_description_auxv.
+
+ - Call sites of target_auxv_search that passed
+ `current_inferior ()->top_target ()` are changed to use the
+ target_auxv_search overload that works in the current inferior.
+
+ Reviewed-By: John Baldwin <jhb@FreeBSD.org>
+ Reviewed-By: Luis Machado <luis.machado@arm.com>
+ Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
+
+2022-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with native-gdbserver
+ When running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
+ board native-gdbserver, I get:
+ ...
+ Running gdb.debuginfod/fetch_src_and_symbols.exp ...
+ ERROR: tcl error sourcing gdb.debuginfod/fetch_src_and_symbols.exp.
+ ERROR: gdbserver does not support start 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 $command $message {*}$opts $user_code"
+ (procedure "gdb_test" line 56)
+ invoked from within
+ "gdb_test "start" "Temporary breakpoint.*""
+ ...
+
+ Fix this by replacing gdb_test "start" with runto_main.
+
+ Tested on x86_64-linux.
+
+2022-10-11 Nick Clifton <nickc@redhat.com>
+
+ Re: Error: attempt to get value of unresolved symbol `L0'
+ * symbols.c (S_GET_VALUE): If the unresolved symbol is the fake
+ label provide a more helpful error message to the user.
+ (S_GET_VALUE_WHERE): Like S_GET_VALUE, but includes a file/line
+ number for error reporting purposes.
+ * symbols.h (S_GET_VALUE_WHERE): Prototype.
+ * write.c (fixup_segment): Use S_GET_VALUE_WHERE.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Initialize pbb_br_* by default
+ On the files generated by sim/common/genmloop.sh, variables pbb_br_type and
+ pbb_br_npc are declared uninitialized and passed to other functions in some
+ cases. Despite that those are harmless, they will generate GCC warnings
+ ("-Wmaybe-uninitialized").
+
+ This commit ensures that pbb_br_type and pbb_br_npc variables are
+ initialized to a harmless value.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Check known getopt definition existence
+ Clang generates a warning if there is a function declaration/definition
+ with zero arguments. Such declarations/definitions without a prototype (an
+ argument list) are deprecated forms of indefinite arguments
+ ("-Wdeprecated-non-prototype"). On the default configuration, it causes a
+ build failure (unless "--disable-werror" is specified).
+
+ include/getopt.h defines some getopt function definitions but one of them
+ has a form "extern int getopt ();". If this form is selected in
+ include/getopt.h, Clang generates a warning and the build fails by default.
+
+ In really old environments, this getopt definition with no arguments is
+ necessary (because the definition may change between environments).
+ However, this definition is now a cause of problems on modern environments.
+
+ A good news is, this definition is not always selected (e.g. if used by
+ binutils/*.c). This is because configuration scripts of binutils, gas,
+ gprof and ld tries to find known definition of getopt function is used and
+ defines HAVE_DECL_GETOPT macro. If this macro is defined when getopt.h is
+ included, a good form of getopt is used and Clang won't generate warnings.
+
+ This commit adds a modified portion of ld/configure.ac to find the known
+ getopt definition. If we could find one (and we *will* in most modern
+ environments), we don't need to rely on the deprecated definition.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+ Andrew Burgess <aburgess@redhat.com>
+
+ sim: Suppress non-literal printf warning
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid this warning, this commit now uses vsnprintf to format error
+ message and pass the message to sim_engine_abort function with another
+ printf-style formatting.
+
+ This patch is mostly authored by Andrew Burgess and slightly modified by
+ Tsukasa OI.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Make WITH_{TRACE,PROFILE}-based macros bool
+ Clang generates a warning if there is an ambiguous expression (possibly a
+ bitwise operation (& or |), but a logical operator (&& or ||) is used;
+ "-Wconstant-logical-operand"). On the default configuration, it causes a
+ build failure (unless "--disable-werror" is specified).
+
+ This is caused by predicate macros that use the form (base_variable & flag).
+ Clang considers them as regular integer values (not boolean) and
+ generates that warning.
+
+ This commit makes Clang think those predicate macros to be boolean.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Remove self-assignments
+ Clang generates a warning if there is a redundant self-assignment
+ ("-Wself-assign"). On the default configuration, it causes a build failure
+ (unless "--disable-werror" is specified).
+
+ This commit removes redundant self-assignments from two files.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/rl78: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to the printf-like functions.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/ppc: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to the printf-like functions.
+
+ For the error function defined in sim_calls.c, the ATTRIBUTE_NORETURN
+ has been moved to the function declaration.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/m68hc11: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to a printf-like function.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/m32c: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to the printf-like functions.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/erc32: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to the printf-like functions.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/cris: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to a printf-like function.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/common: Add ATTRIBUTE_PRINTF
+ Clang generates a warning if the format string of a printf-like function is
+ not a literal ("-Wformat-nonliteral"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ To avoid warnings on the printf-like wrapper, it requires proper
+ __attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
+
+ This commit adds ATTRIBUTE_PRINTF to a printf-like function.
+
+2022-10-11 Martin Liska <mliska@suse.cz>
+
+ fix compressed_debug_section_names definition for "zlib"
+ bfd/ChangeLog:
+
+ * libbfd.c: Set COMPRESS_DEBUG_GABI_ZLIB for "zlib" value.
+
+2022-10-11 Martin Liska <mliska@suse.cz>
+
+ add --enable-default-compressed-debug-sections-algorithm configure option
+ ChangeLog:
+
+ * configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
+ * configure: Regenerate.
+
+ gas/ChangeLog:
+
+ * NEWS: Document the new option.
+ * as.c (flag_compress_debug): Set default algorithm based
+ on the configure option.
+ * configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
+ * configure: Regenerate.
+ * config.in: Likewise.
+
+ ld/ChangeLog:
+
+ * NEWS: Document the new option.
+ * configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
+ * configure: Regenerate.
+ * config.in: Likewise.
+ * ldmain.c: Set default algorithm based
+ on the configure option.
+
+2022-10-11 Martin Liska <mliska@suse.cz>
+
+ refactor usage of compressed_debug_section_type
+ bfd/ChangeLog:
+
+ * bfd-in.h (bfd_hash_set_default_size): Add COMPRESS_UNKNOWN
+ enum value.
+ (struct compressed_type_tuple): New.
+ * bfd-in2.h (bfd_hash_set_default_size): Regenerate.
+ (struct compressed_type_tuple): Likewise.
+ * libbfd.c (ARRAY_SIZE): New macro.
+ (bfd_get_compression_algorithm): New function.
+ (bfd_get_compression_algorithm_name): Likewise.
+
+ gas/ChangeLog:
+
+ * as.c: Do not special-case, use the new functions.
+
+ ld/ChangeLog:
+
+ * emultempl/elf.em: Do not special-case, use the new functions.
+ * lexsup.c (elf_static_list_options): Likewise.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/riscv: fix multiply instructions on simulator
+ After this commit:
+
+ commit 0938b032daa52129b4215d8e0eedb6c9804f5280
+ Date: Wed Feb 2 10:06:15 2022 +0900
+
+ RISC-V: Add 'Zmmul' extension in assembler.
+
+ some instructions in the RISC-V simulator stopped working as a new
+ instruction class 'INSN_CLASS_ZMMUL' was added, and some existing
+ instructions were moved into this class.
+
+ The simulator doesn't currently handle this instruction class, and so
+ the instructions will now cause an illegal instruction trap.
+
+ This commit adds support for INSN_CLASS_ZMMUL, and adds a test that
+ ensures the affected instructions can be executed by the simulator.
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+ Reviewed-by: Andrew Burgess <aburgess@redhat.com>
+
+2022-10-11 Nick Clifton <nickc@redhat.com>
+
+ Error: attempt to get value of unresolved symbol `L0'
+ * symbols.c (S_GET_VALUE): If the unresolved symbol is the fake
+ label provide a more helpful error message to the user.
+
+2022-10-11 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/moxie: add custom directory stamp rule
+ Because sim/moxie/moxie-gdb.dtb is neither a program nor a library, automake
+ does not generate dirstamp file ($builddir/sim/moxie/.dirstamp) for it.
+
+ When maintainer mode is enabled, it tries to rebuild sim/moxie/moxie-gdb.dtb
+ but fails because there's no rules for automake-generated dirstamp file
+ which moxie-gdb.dtb depends.
+
+ This commit adds its own rule for the directory stamp (modified copy of the
+ automake output) and adds the directory stamp file to DISTCLEANFILES to
+ mimic automake-generated behavior (although "make distclean" does not work
+ when maintainer mode is enabled).
+
+2022-10-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Fix formatting of python script
+ The python black formatter was complaining about formatting on the
+ script gdb.python/pretty-print-call-by-hand.py. This commit changed
+ the offending lines to make the formatter happy.
+
+2022-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix prompt parsing in capture_command_output
+ I noticed in capture_command_output that the output of a single command is
+ matched using two gdb_test_multiples:
+ - the first one matching the echoed command and skipping an optional prefix,
+ - the second one matching the output and the prompt.
+
+ This is error-prone, because the first gdb_test_multiple has implicit
+ clauses which may consume the prompt.
+
+ The problem is easy to spot with an example. First consider:
+ ...
+ set output [capture_command_output "print 1" "\\\$1 = "]
+ gdb_assert { [string equal $output "1"] }
+ ...
+ for which we get:
+ ...
+ PASS: [string equal $output "1"]
+ ...
+
+ If we change the prefix string to a no-match, say "1 = ", and update the
+ output string match accordingly, we get instead:
+ ...
+ FAIL: capture_command_output for print 1
+ FAIL: [string equal $output "\$1 = 1"]
+ ...
+
+ The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.
+
+ The second gdb_test_multiple then silently times out waiting for another prompt,
+ after which the second FAIL is produced. Note that the timeout is silent
+ because the gdb_test_multiple is called with an empty message argument.
+
+ The second FAIL is because capture_command_output returns "", given that all
+ the command output was consumed by the first gdb_test_multiple.
+
+ Fix this by rewriting capture_command_output to use only a single
+ gdb_test_multiple.
+
+ Tested on x86_64-linux.
+
+2022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: no need to build version.texi
+ gprofng/ChangeLog
+ 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29465
+ PR gprofng/29667
+ * doc/Makefile.am: No need to build version.texi.
+ * doc/Makefile.in: Rebuild.
+
+2022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: use the --libdir path to find libraries
+ gprofng/ChangeLog
+ 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29663
+ * src/Makefile.am: Add -DLIBDIR to CPPFLAGS.
+ * src/Makefile.in: Rebuild.
+ * src/envsets.cc (putenv_libcollector_ld_misc): Use LIBDIR to find
+ the gprofng libraries.
+
+2022-10-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: run tests without installation
+ gprofng/ChangeLog
+ 2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29107
+ * testsuite/config/default.exp: Set up environment to run gprofng tests
+ without installation.
+ * testsuite/lib/Makefile.skel: Likewise.
+ * testsuite/lib/display-lib.exp: Likewise.
+
+2022-10-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix race in gdb.base/async-shell.exp
+ I see some random failures in this test:
+
+ FAIL: gdb.base/async-shell.exp: run & (timeout)
+
+ It can be reliably reproduced on a recent enough GNU/Linux with this
+ change:
+
+ diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
+ index 44cc28b30051..2a3c8253ba5a 100644
+ --- a/gdb/testsuite/lib/gdb.exp
+ +++ b/gdb/testsuite/lib/gdb.exp
+ @@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
+ }
+ set gdb_test_name "$message"
+
+ + sleep 2
+ set result 0
+ set code [catch {gdb_expect $code} string]
+
+ "recent enough" means a system where libpthread.so was merged with
+ libc.so, so at least glibc 2.34.
+
+ The problem is that the `run &` command prints some things after the
+ prompt:
+
+ (gdb) [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+
+ If expect is quick enough, it will consume only up to the prompt. But
+ if it is slow enough, it will consume those messages at the same time as
+ the prompt, in which case the gdb_test used for "run &" won't match. By
+ default, the prompt used by gdb_test uses a `$` to anchor the match at
+ the end of the buffer. If there's anything following the prompt, it
+ won't match.
+
+ The diff above adds a delay between sending the command and consuming
+ the output, giving GDB more time to output the messages, giving a good
+ chance that expect consumes them at the same time as the prompt.
+
+ This is normally handled by using gdb_test_multiple and specifying a
+ pattern that ends with "$gdb_prompt", but not a trailing $. I think
+ this is common enough that it deserves its own gdb_test option.
+ Therefore, add the -no-anchor-prompt option to gdb_test, and
+ gdb_test_no_output for completeness. Use it in
+ gdb.base/async-shell.exp.
+
+ Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
+ Approved-By: Tom de Vries <tdevries@suse.de>
+
+2022-10-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+
+ Fix a latent bug in print_wchar
+ print_wchar keeps track of when escape sequences are emitted, to force
+ an escape sequence if needed by a subsequent character. For example
+ for the string concatenation "\0" "1", gdb will print "\000\061" --
+ because printing "\0001" might be confusing.
+
+ However, this code has two errors. First, this logic is not needed
+ for octal escapes, because there is a length limit of 3 for octal
+ escapes, and gdb always prints these with "%.3o". Second, though,
+ this *is* needed for hex escapes, because those do not have a length
+ limit.
+
+ This patch fixes these problems and adds the appropriate tests.
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+
+ Don't use wchar_printable in print_wchar
+ print_wchar uses wchar_printable, but this isn't needed -- all the
+ relevant cases are already handled by the 'switch'. This changes the
+ code to use gdb_iswprint, and removes a somewhat confusing comment
+ related to this code.
+
+ Remove c_printstr
+ This renames c_printstr, removing a layer of indirection.
+
+ Remove c_emit_char
+ This renames c_emit_char, removing a layer of indirection.
+
+ Boolify need_escape in generic_emit_char
+ This changes 'need_escape' in generic_emit_char to be of type bool,
+ rather than int.
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+ Andrew Burgess <aburgess@redhat.com>
+
+ Fix latent quote char bug in generic_printstr
+ generic_printstr prints an empty string like:
+
+ fputs_filtered ("\"\"", stream);
+
+ However, this seems wrong to me if the quote character is something
+ other than double quote. This patch fixes this latent bug. Thanks to
+ Andrew for the test case.
+
+2022-10-10 Tom Tromey <tromey@adacore.com>
+
+ Fix the guile build
+ The frame_info_ptr patches broke the build with Guile. This patch
+ fixes the problem. In mos cases I chose to preserve the use of
+ frame_info_ptr, at least where I could be sure that the object
+ lifetime did not interact with Guile's longjmp-based exception scheme.
+
+ Tested on x86-64 Fedora 34.
+
+2022-10-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Detect trailing ^C/^D in command
+ Detect a trailing ^C/^D in the command argument of gdb_test_multiple, and
+ error out.
+
+ Tested on x86_64-linux.
+
+2022-10-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix error message for cmd with trailing newline
+ I noticed that the error message in gdb_test_multiple about trailing newline
+ in a command does not mention the offending command, nor the word command:
+ ...
+ if [string match "*\[\r\n\]" $command] {
+ error "Invalid trailing newline in \"$message\" test"
+ }
+ ...
+
+ Fix this by using instead:
+ ...
+ error "Invalid trailing newline in \"$command\" command"
+ ...
+
+ Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp.
+
+ Tested on x86_64-linux.
+
+2022-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: include the base address in in-memory bfd filenames
+ The struct target_buffer (in gdb_bfd.c) is used to hold information
+ about an in-memory BFD object created by GDB. For now this mechanism
+ is used by GDB when loading information about JIT symfiles.
+
+ This commit updates target_buffer (in gdb_bfd.c) to be more C++ like,
+ and, at the same time, adds the base address of the symfile into the
+ BFD filename.
+
+ Right now, every in-memory BFD is given the filename "<in-memory>".
+ This filename is visible in things like 'maint info symtabs' and
+ 'maint info line-table'. If there are multiple in-memory BFD objects
+ then it can be hard to match keep track if which BFD is which. This
+ commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is
+ replaced with the base address for where the in-memory symbol file was
+ read from.
+
+ As an example of how this is useful, here's the output of 'maint info
+ jit' showing a single loaded JIT symfile:
+
+ (gdb) maintenance info jit
+ jit_code_entry address symfile address symfile size
+ 0x00000000004056b0 0x0000000007000000 17320
+
+ And here's part of the output from 'maint info symtabs':
+
+ (gdb) maintenance info symtabs
+ ...snip...
+ { objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250)
+ { ((struct compunit_symtab *) 0x4f0afb0)
+ debugformat DWARF 4
+ producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic
+ name jit-elf-solib.c
+ dirname /tmp/binutils-gdb/build/gdb/testsuite
+ blockvector ((struct blockvector *) 0x5477850)
+ user ((struct compunit_symtab *) (null))
+ { symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030)
+ fullname (null)
+ linetable ((struct linetable *) 0x5477880)
+ }
+ }
+ }
+
+ I've added a new test that checks the new in-memory file names are
+ generated correctly, and also checks that the in-memory JIT files can
+ be dumped back out using 'dump binary memory'.
+
+2022-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove filename arg from gdb_bfd_open_from_target_memory
+ The filename argument to gdb_bfd_open_from_target_memory was never
+ used; this argument had a default value of nullptr, and the only call
+ to this function, in jit.c, relied on the default value.
+
+ In the next commit I'm going to make some changes to the
+ gdb_bfd_open_from_target_memory function, and, though I could take
+ account of a filename parameter, it seems pointless to maintain an
+ unused argument.
+
+ This commit removes the filename argument.
+
+ There should be no user visible changes after this commit.
+
+2022-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add infcall specific debugging
+ Add two new commands:
+
+ set debug infcall on|off
+ show debug infcall
+
+ These enable some new debugging related to when GDB makes inferior
+ function calls. I've added some basic debugging for what I think are
+ the major steps in the inferior function call process, but I'm sure we
+ might want to add more later.
+
+2022-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: extra debug output in thread.c
+ Add some extra 'threads' debug in a couple of places in thread.c.
+ I've also added an additional gdb_assert in one case.
+
+ gdb: improve infrun_debug_show_threads output
+ This commit switches to use INFRUN_SCOPED_DEBUG_START_END in the
+ infrun_debug_show_threads function, which means the output will get an
+ extra level of indentation, this looks a little nicer I think.
+
+2022-10-10 Nick Clifton <nickc@redhat.com>
+
+ Add ability to create reproducible source tarballs.
+ * src-release.sh: Add "-r <date>" option to create reproducible
+ tarballs based upon a fixed timestamp of <date>.
+ * binutils/README-how-to-make-a-release: Add a line showing how to
+ use -r <date> when creating a binutils release.
+
+2022-10-10 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/frame: Add reinflation method for frame_info_ptr
+ Currently, despite having a smart pointer for frame_infos, GDB may
+ attempt to use an invalidated frame_info_ptr, which would cause internal
+ errors to happen. One such example has been documented as PR
+ python/28856, that happened when printing frame arguments calls an
+ inferior function.
+
+ To avoid failures, the smart wrapper was changed to also cache the frame
+ id, so the pointer can be reinflated later. For this to work, the
+ frame-id stuff had to be moved to their own .h file, which is included
+ by frame-info.h.
+
+ Frame_id caching is done explicitly using the prepare_reinflate method.
+ Caching is done manually so that only the pointers that need to be saved
+ will be, and reinflating has to be done manually using the reinflate
+ method because the get method and the -> operator must not change
+ the internals of the class. Finally, attempting to reinflate when the
+ pointer is being invalidated causes the following assertion errors:
+
+ check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
+ get_frame_pc: Assertion `frame->next != NULL` failed.
+
+ As for performance concerns, my personal testing with `time make
+ chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
+ 10% of time running.
+
+ This commit also adds a testcase that exercises the python/28856 bug with
+ 7 different triggers, run, continue, step, backtrace, finish, up and down.
+ Some of them can seem to be testing the same thing twice, but since this
+ test relies on stale pointers, there is always a chance that GDB got lucky
+ when testing, so better to test extra.
+
+ Regression tested on x86_64, using both gcc and clang.
+
+ Approved-by: Tom Tomey <tom@tromey.com>
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+
+ Change GDB to use frame_info_ptr
+ This changes GDB to use frame_info_ptr instead of frame_info *
+ The substitution was done with multiple sequential `sed` commands:
+
+ sed 's/^struct frame_info;/class frame_info_ptr;/'
+ sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
+ issues in a few files, that were manually fixed.
+ sed 's/\<frame_info \*/frame_info_ptr /g'
+ sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
+ problems.
+
+ The changed files were then manually checked and some 'sed' changes
+ undone, some constructors and some gets were added, according to what
+ made sense, and what Tromey originally did
+
+ Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-by: Tom Tomey <tom@tromey.com>
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+
+ Introduce frame_info_ptr smart pointer class
+ This adds frame_info_ptr, a smart pointer class. Every instance of
+ the class is kept on an intrusive list. When reinit_frame_cache is
+ called, the list is traversed and all the pointers are invalidated.
+ This should help catch the typical GDB bug of keeping a frame_info
+ pointer alive where a frame ID was needed instead.
+
+ Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
+ Approved-by: Tom Tomey <tom@tromey.com>
+
+2022-10-10 Tom Tromey <tom@tromey.com>
+
+ Remove frame_id_eq
+ This replaces frame_id_eq with operator== and operator!=. I wrote
+ this for a version of this series that I later abandoned; but since it
+ simplifies the code, I left this patch in.
+
+ Approved-by: Tom Tomey <tom@tromey.com>
+
+2022-10-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: use 'end' at the end of python blocks
+ Within the testsuite, use the keyword 'end' to terminate blocks of
+ Python code being sent to GDB, rather than sending \004. I could only
+ find three instances of this, all in tests that I originally wrote. I
+ have no memory of there being any special reason why I used \004
+ instead of 'end' - I assume I copied this from somewhere else that has
+ since changed.
+
+ Non of the tests being changed here are specifically about whether
+ \004 can be used to terminate a Python block, so I think switching to
+ the more standard 'end' keyword is the right choice.
+
+2022-10-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: re-generate configure
+ I get this diff when re-generating configure, probably leftover from
+ 67d1991b785 ("egrep in binutils").
+
+ Change-Id: I759c88c2bad648736d33ff98089db45c9b686356
+
+2022-10-10 Alan Modra <amodra@gmail.com>
+
+ Merge configure.ac from gcc project
+ To merge with gcc's copy of configure.ac we need to revert changes to
+ configure.ac in the following gcc commits:
+ dc832fb39fc0 2022-08-25
+ fc259b522c0f 2022-06-25
+ Then reapply configure.ac changes in binutils from these binutils
+ commits:
+ 50ad1254d503 2021-01-09
+ bb368aad297f 2022-03-11
+ e5f2f7d901ee 2022-07-26
+ 2cac01e3ffff 2022-09-26
+ Plus copy over gcc's config/ax_cxx_compile_stdcxx.m4, then regenerate
+ configure.
+
+2022-10-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-08 Tom Tromey <tom@tromey.com>
+
+ Merge both implementations of debug_names::insert
+ The class debug_names has two 'insert' overloads, but only one of them
+ is ever called externally, and it simply forwards to the other
+ implementation. It seems cleaner to me to have a single method, so
+ this patch merges the two.
+
+2022-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix silent fail in gdb.server/connect-with-no-symbol-file.exp
+ With native and target boards native-gdbserver, remote-gdbserver-on-localhost and
+ remote-stdio-gdbserver I have for gdb.server/connect-with-no-symbol-file.exp:
+ ...
+ # of expected passes 8
+ ...
+ but with native-extended-gdbserver I have instead:
+ ...
+ # of expected passes 8
+ # of unexpected failures 4
+ ...
+
+ The extra FAILs are of the form:
+ ...
+ (gdb) detach^M
+ Detaching from pid process 28985^M
+ [Inferior 1 (process 28985) detached]^M
+ (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
+ action=permission: connection to GDBserver succeeded
+ ...
+ and are due to the fact that the actual gdb output doesn't match the regexp:
+ ...
+ gdb_test "detach" \
+ ".*Detaching from program: , process.*Ending remote debugging.*" \
+ "connection to GDBserver succeeded"
+ ...
+
+ With native, the actual gdb output is:
+ ...
+ (gdb) detach^M
+ Detaching from pid process 29657^M
+ Ending remote debugging.^M
+ [Inferior 1 (process 29657) detached]^M
+ (gdb) Remote debugging from host ::1, port 51028^M
+ ...
+ and because the regexp doesn't match, it triggers an implicit clause for
+ "Ending remote debugging" in gdb_test_multiple, which has the consequence
+ that the FAIL is silent.
+
+ Fix:
+ - the regexp by making it less strict
+ - the silent fail by rewriting into a gdb_test_multiple, and adding an
+ explicit fail clause.
+
+ Tested on x86_64-linux, using native and aforementioned target boards.
+
+2022-10-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-07 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: fix gdb.threads/linux-dp.exp regex
+ On ubuntu 22.04 with the libc6-dbg package installed, I have the
+ following failure:
+
+ where
+ #0 print_philosopher (n=3, left=33 '!', right=33 '!') at .../gdb/testsuite/gdb.threads/linux-dp.c:105
+ #1 0x000055555555576a in philosopher (data=0x55555555937c) at .../gdb/testsuite/gdb.threads/linux-dp.c:148
+ #2 0x00007ffff7e11b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+ #3 0x00007ffff7ea3a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+ (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
+
+ The regex for this test accounts for different situations (with /
+ without debug symbol) but assumes that if debug info is present the
+ backtrace shows execution under pthread_create. However, for the
+ implementation under test, we are under start_thread.
+
+ Update the regex to accept start_thread.
+
+ Tested on Ubuntu-22.04 x86_64 with and without libc6-dbg debug symbols
+ available.
+
+ Change-Id: I1e1536279890bca2cd07f038e026b41e46af44e0
+
+2022-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle host cleanfiles
+ When running test-case gdb.server/abspath.exp with host board
+ local-remote-host-notty, I get:
+ ...
+ $ git sti
+ ...
+ deleted: gdb/testsuite/gdb.xml/trivial.xml
+ ...
+
+ This happens as follows. The test-case calls skip_gdbserver_test, which calls
+ gdb_skip_xml_test, which does:
+ ...
+ set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"]
+ ...
+
+ Then proc gdb_remote_download appends $xml_file (which for this particular
+ host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which
+ ends up being handled in gdb_finish by:
+ ...
+ eval remote_file target delete $cleanfiles
+ ...
+
+ The problem is that a host file is deleted using target delete.
+
+ Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host.
+
+ Tested on x86_64-linux.
+
+2022-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove unnecessary warning in gdb.base/default.exp
+ When running test-case gdb.base/default.exp with target board
+ native-gdbserver, we get:
+ ...
+ WARNING: Skipping backtrace and break tests because of GDB stub.
+ ...
+
+ There's no need for such a warning, so remove it.
+
+ Tested on x86_64-linux with native and target board native-gdbserver.
+
+2022-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix have_mpx with remote-gdbserver-on-localhost
+ With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp
+ I run into:
+ ...
+ FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
+ ...
+
+ This is due to the have_mpx test which should return 0, but instead returns 1
+ because the captured output:
+ ...
+ No MPX support
+ No MPX support
+ ...
+ does not match the used regexp:
+ ...
+ set status [expr ($status == 0) \
+ && ![regexp "^No MPX support\r\n" $output]]
+ ...
+ which does match the captured output with native:
+ ...
+ No MPX support^M
+ No MPX support^M
+ ...
+
+ Fix this by making the \r in the regexp optional.
+
+ Tested on x86_64-linux, with native and target board
+ remote-gdbserver-on-localhost.
+
+2022-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATEs with remote-gdbserver-on-localhost
+ Fix some DUPLICATEs that we run into with target board
+ remote-gdbserver-on-localhost, by using test_with_prefix.
+
+ Tested on x86_64-linux, with native and target board
+ remote-gdbserver-on-localhost.
+
+2022-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix path in test name in gdb_load_shlib
+ When running test-case gdb.server/solib-list.exp with target board
+ remote-gdbserver-on-localhost, I run into:
+ ...
+ (gdb) set solib-search-path $outputs/gdb.server/solib-list^M
+ (gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \
+ set solib-search-path $outputs/gdb.server/solib-list
+ PATH: gdb.server/solib-list.exp: non-stop 0: \
+ set solib-search-path $outputs/gdb.server/solib-list
+ ...
+
+ This is due to this code in gdb_load_shlib:
+ ...
+ gdb_test "set solib-search-path [file dirname $file]" "" ""
+ ...
+
+ Fix this by setting an explicit test name.
+
+ Tested on x86_64-linux, with native and target boards
+ remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver.
+
+2022-10-07 Alan Modra <amodra@gmail.com>
+
+ PR29653, objcopy/strip: fuzzed small input file induces large output file
+ _bfd_check_format functions should not print errors or warnings if
+ they return NULL. A NULL return means the particular target under
+ test does not match, so there isn't any reason to make a complaint
+ about the target. In fact there isn't a good reason to warn even if
+ the target matches, except via the _bfd_per_xvec_warn mechanism; Some
+ other target might be a better match.
+
+ This patch tidies pe_bfd_object_p with the above in mind, and
+ restricts the PE optional header SectionAlignment and FileAlignment
+ fields somewhat. I chose to warn on nonsense values rather than
+ refusing to match. Refusing to match would be OK too.
+
+ PR 29653
+ * peXXigen.c (_bfd_XXi_swap_aouthdr_in): Don't emit error about
+ invalid NumberOfRvaAndSizes here. Limit loop copying data
+ directory to IMAGE_NUMBEROF_DIRECTORY_ENTRIES.
+ * peicode.h (pe_bfd_object_p): Don't clear and test bfd_error
+ around bfd_coff_swap_aouthdr_in. Warn on invalid SectionAlignment,
+ FileAlignment and NumberOfRvaAndSizes. Don't return NULL on
+ invalid NumberOfRvaAndSizes.
+
+2022-10-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-06 Tom Tromey <tromey@adacore.com>
+
+ Fix indentation in riscv-tdep.c
+ This just fixes some indentation in riscv-tdep.c.
+
+2022-10-06 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Handle lazy FPU state preservation
+ Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together
+ with FPCAR to identify if lazy FPU state preservation is active for
+ the current frame. See "Lazy context save of FP state", in B1.5.7,
+ also ARM AN298, supported by Cortex-M4F architecture for details on
+ lazy FPU register stacking. The same conditions are valid for other
+ Cortex-M cores with FPU.
+
+ This patch has been verified on a STM32F4-Discovery board by:
+ a) writing a non-zero value (lets use 0x1122334455667788 as an
+ example) to all the D-registers in the main function
+ b) configured the SysTick to fire
+ c) in the SysTick_Handler, write some other value (lets use
+ 0x0022446688aaccee as an example) to one of the D-registers (D0 as
+ an example) and then do "SVC #0"
+ d) in the SVC_Handler, write some other value (lets use
+ 0x0099aabbccddeeff) to one of the D-registers (D0 as an example)
+
+ In GDB, suspend the execution in the SVC_Handler function and compare
+ the value of the D-registers for the SVC_handler frame and the
+ SysTick_Handler frame. With the patch, the value of the modified
+ D-register (D0) should be the new value (0x009..eff) on the
+ SVC_Handler frame, and the intermediate value (0x002..cee) for the
+ SysTick_Handler frame. Now compare the D-register value for the
+ SysTick_Handler frame and the main frame. The main frame should
+ have the initial value (0x112..788).
+
+2022-10-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Factor out have_complaint
+ After committing 8ba677d3560 ("[gdb/symtab] Don't complain about function
+ decls") I noticed that quite a bit of code in read_func_scope is used to decide
+ whether to issue the "cannot get low and high bounds for subprogram DIE at
+ $hex" complaint, which executes unnecessarily if we have the default
+ "set complaints 0".
+
+ Fix this by (NFC):
+ - factoring out new static function have_complaint from macro complaint, and
+ - using it to wrap the relevant code in read_func_scope.
+
+ Tested on x86_64-linux.
+
+2022-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add missing nullptr checks in bpstat_check_breakpoint_conditions
+ Add a couple of missing nullptr checks in the function
+ bpstat_check_breakpoint_conditions.
+
+ No user visible change after this commit.
+
+2022-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: more infrun debug from breakpoint.c
+ This commit adds additional infrun debug from the breakpoint.c file.
+ The new debug output all relates to breakpoint condition evaluation.
+
+ There is already some infrun debug emitted from the breakpoint.c file,
+ so hopefully, adding more will not be contentious. I think the
+ functions being instrumented make sense as part of the infrun process,
+ the inferior stops, evaluates the condition, and then either stops or
+ continues. This new debug gives more insight into that process.
+
+ I had to make the bp_location* argument to find_loc_num_by_location
+ const, and add a declaration for find_loc_num_by_location.
+
+ There should be no user visible changes unless they turn on debug
+ output.
+
+2022-10-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add some additional debug in mark_async_event_handler
+ Extend the existing debug printf call to include the previous state of
+ the async_event_handler object.
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Print XTheadMemPair literal as "immediate"
+ The operand type "Xl(...)" denotes that (...) is a literal. Specifically,
+ they are intended to be a constant immediate value.
+
+ This commit prints "Xl(...)" operand with dis_style_immediate style,
+ not dis_style_text.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Use dis_style_immediate on
+ the constant literal of the "Xl..." operand.
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix T-Head immediate types on printing
+ This commit fixes two minor typing-related issues for
+ T-Head immediate operands.
+
+ 1. A signed type must be specified when printing with %i.
+ 2. unsigned/signed int is not portable enough for max 32-bit immediates.
+ Instead, we should use unsigned/signed long.
+ The format string is changed accordingly.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Fix T-Head immediate types on
+ printing.
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Print comma and tabs as the "text" style
+ On the RISC-V disassembler, some separators have non-text style when
+ printed with another word with another style.
+
+ This commit splits those, making sure that those comma and tabs are printed
+ with the "text" style.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Split and print the comma as
+ text. (riscv_disassemble_insn): Split and print tabs as text.
+ (riscv_disassemble_data): Likewise.
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Optimize riscv_disassemble_data printf
+ This commit makes types of printf arguments on riscv_disassemble_data
+ as small as possible (as long as we can preserve the portability) to reduce
+ the cost of printf (especially on 32-bit host).
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_data): Use smallest possible type
+ to printing data.
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix printf argument types corresponding %x
+ "%x" format specifier requires unsigned type, not int. This commit
+ fixes this issue on the RISC-V disassembler.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Fix printf argument types where
+ the format specifier is "%x".
+
+2022-10-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix immediates to have "immediate" style
+ This commit fixes certain print calls on immediate operands to have
+ dis_style_immediate.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Fix immediates to have
+ "immediate" style. (riscv_disassemble_data): Likewise.
+
+2022-10-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-06 Alan Modra <amodra@gmail.com>
+
+ Re: bfd BLD-POTFILES.in dependencies
+ Removing $BLD_POTFILES from BFD-POTFILES.in was correct, but left a
+ hole in dependencies.
+ make[4]: Entering directory '/home/alan/build/gas/all/bfd/po'
+ make[4]: *** No rule to make target '../elf32-aarch64.c', needed by '/home/alan/src/binutils-gdb/bfd/po/bfd.pot'. Stop.
+
+ * Makefile.am (BUILT_SOURCES): Add BUILD_CFILES.
+ * Makefile.in: Regenerate.
+
+2022-10-05 Jan Beulich <jbeulich@suse.com>
+
+ x86/gas: support quoted address scale factor in AT&T syntax
+ An earlier attempt (e68c3d59acd0 ["x86: better respect quotes in
+ parse_operands()"]) needed undoing (cc0f96357e0b ["x86: permit
+ parenthesized expressions again as addressing scale factor"]) as far its
+ effect here went. As indicated back then, the issue is the backwards
+ scanning of the operand string to find the matching opening parenthesis.
+ Switch to forward scanning, finding the last outermost unquoted opening
+ parenthesis (which is the one matching the trailing closing one).
+
+ Arm64: support CLEARBHB alias
+ While the Arm v8 ARM (rev I-a) still doesn't mention this alias, it is
+ (typically via a macro) already in use in kernels and alike.
+
+2022-10-05 Alan Modra <amodra@gmail.com>
+
+ PR29647, objdump -S looping
+ Fuzzed input with this in .debug_line
+ [0x0000003b] Special opcode 115: advance Address by 8 to 0x401180 and Line by -2 to -1
+
+ PR 29647
+ * objdump.c (print_line): Don't decrement line number here..
+ (dump_lines): ..do so here instead, ensuring loop terminates.
+
+2022-10-05 Alan Modra <amodra@gmail.com>
+
+ Re: stab nearest_line bfd_malloc_and_get_section
+ It didn't take long for the fuzzers to avoid size checks in
+ bfd_malloc_and_get_section. Plug this hole.
+
+ * syms.c (_bfd_stab_section_find_nearest_line): Ignore fuzzed
+ sections with no contents.
+
+2022-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with --enable-pgo-build=lto
+ gprofng/ChangeLog
+ 2022-10-04 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29579
+ * libcollector/dispatcher.c: Fix the symbol version in SYMVER_ATTRIBUTE.
+ * libcollector/iotrace.c: Likewise.
+ * libcollector/linetrace.c: Likewise.
+ * libcollector/mmaptrace.c: Likewise.
+ * libcollector/synctrace.c: Likewise.
+
+2022-10-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-04 Tom Tromey <tom@tromey.com>
+
+ Remove decode_location_spec_default
+ This removes decode_location_spec_default, inlining it into its sole
+ caller.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-10-04 Palmer Dabbelt <palmer@rivosinc.com>
+
+ gas: NEWS: Mention the T-Head extensions that were recently added
+
+2022-10-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Don't complain about function decls
+ [ Requires "[gdb/symtab] Don't complain about inlined functions" as
+ submitted here (
+ https://sourceware.org/pipermail/gdb-patches/2022-September/191762.html ). ]
+
+ With the test-case included in this patch, we get:
+ ...
+ (gdb) ptype main^M
+ During symbol reading: cannot get low and high bounds for subprogram DIE \
+ at 0xc1^M
+ type = int (void)^M
+ (gdb) FAIL: gdb.dwarf2/anon-ns-fn.exp: ptype main without complaints
+ ...
+
+ The DIE causing the complaint is a function declaration:
+ ...
+ <2><c1>: Abbrev Number: 3 (DW_TAG_subprogram)
+ <c2> DW_AT_name : foo
+ <c8> DW_AT_declaration : 1
+ ...
+ which is referred to from the DIE representing the function definition:
+ ...
+ <1><f4>: Abbrev Number: 7 (DW_TAG_subprogram)
+ <f5> DW_AT_specification: <0xc1>
+ <f9> DW_AT_low_pc : 0x4004c7
+ <101> DW_AT_high_pc : 0x7
+ ...
+ which does contain the low and high bounds.
+
+ Fix this by not complaining about function declarations.
+
+ Tested on x86_64-linux.
+
+2022-10-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Don't complain about inlined functions
+ With the test-case included in this patch, we get:
+ ...
+ (gdb) ptype main^M
+ During symbol reading: cannot get low and high bounds for subprogram DIE \
+ at 0x113^M
+ During symbol reading: cannot get low and high bounds for subprogram DIE \
+ at 0x11f^M
+ type = int (void)^M
+ (gdb) FAIL: gdb.dwarf2/inline.exp: ptype main
+ ...
+
+ The complaints are about foo, with DW_AT_inline == DW_INL_inlined:
+ ...
+ <1><11f>: Abbrev Number: 6 (DW_TAG_subprogram)
+ <120> DW_AT_name : foo
+ <126> DW_AT_prototyped : 1
+ <126> DW_AT_type : <0x10c>
+ <12a> DW_AT_inline : 1 (inlined)
+ ...
+ and foo2, with DW_AT_inline == DW_INL_declared_inlined:
+ ...
+ <1><113>: Abbrev Number: 5 (DW_TAG_subprogram)
+ <114> DW_AT_name : foo2
+ <11a> DW_AT_prototyped : 1
+ <11a> DW_AT_type : <0x10c>
+ <11e> DW_AT_inline : 3 (declared as inline and inlined)
+ ...
+
+ Fix this by not complaining about inlined functions.
+
+ Tested on x86_64-linux.
+
+2022-10-04 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdb/riscv: Partial support for instructions up to 176-bit
+ Because riscv_insn_length started to support instructions up to 176-bit,
+ we need to increase buf size to 176-bit in size.
+
+ Also, that would break an assumption in riscv_insn::decode so this commit
+ fixes it, noting that instructions longer than 64-bit are not fully
+ supported yet.
+
+2022-10-04 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix buffer overflow on print_insn_riscv
+ Because riscv_insn_length started to support instructions up to 176-bit,
+ we need to increase packet buffer size to 176-bit in size.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (RISCV_MAX_INSN_LEN): Max instruction length for
+ use in buffer size.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_riscv): Increase buffer size for max
+ 176-bit length instructions.
+
+2022-10-04 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Renamed INSN_CLASS for floating point in integer extensions.
+ Just added suffix _INX for those INSN_CLASS should be enough to represent
+ their fpr can be replaced by gpr.
+
+2022-10-04 Nick Clifton <nickc@redhat.com>
+
+ Note that at least dejagnu version 1.5.3 is required in order to be ale to run the testsuites.
+ * README-maintainer-mode: Add a minimum version of dejagnu
+ requirement.
+
+2022-10-04 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/riscv: style csr names as registers
+ While reviewing another patch I noticed that RISC-V CSR names are
+ given the text style, not the register style. This patch fixes this
+ mistake.
+
+2022-10-04 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Update FPSR/FPCR fields for FPU and SVE
+ I noticed some missing flags/fields from FPSR and FPCR registers in
+ both the FPU and SVE target descriptions.
+
+ This patch adds those and makes the SVE versions of FPSR and FPCR
+ use the proper flags/bitfields types.
+
+2022-10-04 Alan Modra <amodra@gmail.com>
+
+ Support objcopy changing compression to or from zstd
+ Commit 2cac01e3ffff lacked support for objcopy changing compression
+ style. Add that support, which meant a rewrite of
+ bfd_compress_section_contents. In the process I've fixed some memory
+ leaks.
+
+ * compress.c (bfd_is_section_compressed_info): Rename from
+ bfd_is_section_compressed_with_header and add ch_type param
+ to return compression header ch_type field.
+ Update all callers.
+ (decompress_section_contents): Remove buffer and size params.
+ Rewrite. Update callers.
+ (bfd_init_section_compress_status): Free contents on failure.
+ (bfd_compress_section): Likewise.
+ * elf.c (_bfd_elf_make_section_from_shdr): Support objcopy
+ changing between any of the three compression schemes. Report
+ "unable to compress/decompress" rather than "unable to
+ initialize compress/decompress status" on compress/decompress
+ failures.
+ * bfd-in2.h: Regenerate.
+
+2022-10-04 Alan Modra <amodra@gmail.com>
+
+ Re: compress .gnu.debuglto_.debug_* sections if requested
+ Enable zlib-gnu compression for .gnu.debuglto_.debug_*. This differs
+ from zlib-gnu for .debug_* where the name is changed to .zdebug_*.
+ The name change isn't really needed.
+
+ bfd/
+ * elf.c (elf_fake_sections): Replace "." with ".z" in debug
+ section names only when name was ".d*", ie. ".debug_*".
+ (_bfd_elf_assign_file_positions_for_non_load): Likewise.
+ gas/
+ * write.c (compress_debug): Compress .gnu.debuglto_.debug_*
+ for zlib-gnu too. Compress .gnu.linkonce.wi.*.
+
+2022-10-04 Martin Liska <mliska@suse.cz>
+
+ compress .gnu.debuglto_.debug_* sections if requested
+ Right now, when using LTO, the intermediate object files do contain
+ debug info in sections starting with .gnu.debuglto_ prefix and are
+ not compressed when --compress-debug-sections is used.
+
+ It's a mistake and we can save quite some disk space. The following
+ example comes from tramp3d when the corresponding LTO sections
+ are compressed with zlib:
+
+ $ bloaty tramp3d-v4-v2.o -- tramp3d-v4.o
+ FILE SIZE VM SIZE
+ -------------- --------------
+ +83% +10 [ = ] 0 [Unmapped]
+ -68.0% -441 [ = ] 0 .gnu.debuglto_.debug_line
+ -52.3% -759 [ = ] 0 .gnu.debuglto_.debug_line_str
+ -62.4% -3.24Ki [ = ] 0 .gnu.debuglto_.debug_abbrev
+ -64.8% -1.12Mi [ = ] 0 .gnu.debuglto_.debug_info
+ -88.8% -4.58Mi [ = ] 0 .gnu.debuglto_.debug_str
+ -27.7% -5.70Mi [ = ] 0 TOTAL
+
+ bfd/ChangeLog:
+
+ * elf.c (_bfd_elf_make_section_from_shdr): Compress all debug
+ info sections.
+
+ gas/ChangeLog:
+
+ * write.c (compress_debug): Compress also ".gnu.debuglto_.debug_"
+ if the compression algorithm is different from zlib-gnu.
+
+2022-10-04 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V/gas: allow generating up to 176-bit instructions with .insn
+ For the time being simply utilize O_big to avoid widening other fields,
+ bypassing append_insn() etc.
+
+ RISC-V/gas: don't open-code insn_length()
+ Use the helper when it can be used.
+
+ RISC-V/gas: drop stray call to install_insn()
+ add_fixed_insn(), by calling move_insn(), already invokes install_insn().
+
+ RISC-V/gas: drop riscv_subsets static variable
+ It's fully redundant with the subset_list member of riscv_rps_as.
+
+ RISC-V: don't cast expressions' X_add_number to long in diagnostics
+ There's no need for such workarounds anymore now that we use C99
+ uniformly. This addresses several testsuite failures encountered when
+ (cross-)building on a 32-bit host.
+
+2022-10-04 Potharla, Rupesh <Rupesh.Potharla@amd.com>
+
+ ignore DWARF debug information for -gsplit-dwarf with dwarf-5
+ Skip dwo_id for split dwarf.
+
+ * dwarf2.c (parse_comp_unit): Skip DWO_id for DW_UT_skeleton.
+
+2022-10-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-03 Jan-Benedict Glaw <jbglaw@lug-owl.de>
+
+ Fix self-move warning check for GCC 13+
+ GCC 13 got the self-move warning (0abb78dda084a14b3d955757c6431fff71c263f3),
+ but that warning is only checked for clang, resulting in:
+
+ /usr/lib/gcc-snapshot/bin/g++ -x c++ -I. -I. -I./config -DLOCALEDIR="\"/tmp/gdb-m68k-linux/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/readline/.. -I./../zlib -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/ -I../libbacktrace/ -DTUI=1 -I./.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -g -O2 -c -o unittests/environ-selftests.o -MT unittests/environ-selftests.o -MMD -MP -MF unittests/.deps/environ-selftests.Tpo unittests/environ-selftests.c
+ unittests/environ-selftests.c: In function 'void selftests::gdb_environ_tests::test_self_move()':
+ unittests/environ-selftests.c:228:7: error: moving 'env' of type 'gdb_environ' to itself [-Werror=self-move]
+ 228 | env = std::move (env);
+ | ~~~~^~~~~~~~~~~~~~~~~
+ unittests/environ-selftests.c:228:7: note: remove 'std::move' call
+ cc1plus: all warnings being treated as errors
+ make[1]: *** [Makefile:1896: unittests/environ-selftests.o] Error 1
+ make[1]: Leaving directory '/var/lib/laminar/run/gdb-m68k-linux/3/binutils-gdb/gdb'
+ make: *** [Makefile:13193: all-gdb] Error 2
+
+2022-10-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: constify inferior::target_is_pushed
+ Change-Id: Ia4143b9c63cb76e2c824ba773c66f5c5cd94b2aa
+
+2022-10-03 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Handle W registers as pseudo-registers instead of aliases of X registers
+ The aarch64 port handles W registers as aliases of X registers. This is
+ incorrect because X registers are 64-bit and W registers are 32-bit.
+
+ This patch teaches GDB how to handle W registers as pseudo-registers of
+ 32-bit, the bottom half of the X registers.
+
+ Testcase included.
+
+2022-10-03 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Fix pseudo-register numbering in the presence of unexpected additional registers
+ When using AArch64 GDB with the QEMU debugging stub (in user mode), we get
+ additional system registers that GDB doesn't particularly care about, so
+ it doesn't number those explicitly.
+
+ But given the pseudo-register numbers are above the number of real registers,
+ we need to setup/account for the real registers first before going ahead and
+ numbering the pseudo-registers. This has to happen at the end of
+ aarch64_gdbarch_init, after the call to tdesc_use_registers, as that
+ updates the total number of real registers.
+
+ This is in preparation to supporting pointer authentication for bare metal
+ aarch64 (QEMU).
+
+2022-10-03 Nick Clifton <nickc@redhat.com>
+
+ readelf: DO not load section headers from file offset zero
+ * readelf.c (get_32bit_section_headers): Return false if the
+ e_shoff field is zero.
+ (get_64bit_section_headers): Likewise.
+
+2022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Move supervisor instructions after all unprivileged ones
+ This location of supervisor instructions is out of place (because many other
+ privileged instructions are located at the tail but after the supervisor
+ instructions, we have many unprivileged instructions including bit
+ manipulation / crypto / vector instructions).
+
+ Not only that, this is harmful to implement pseudoinstructions in the latest
+ 'P'-extension proposal (CLROV and RDOV). This commit moves supervisor
+ instructions after all unprivileged instructions.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Adjust indents. Move supervisor
+ instructions after all unprivileged instructions.
+
+2022-10-03 Bruno Larsen <blarsen@redhat.com>
+
+ Improve GDB's baseclass detection with typedefs
+ When a class inherits from a typedef'd baseclass, GDB may be unable to
+ find the baseclass if the user is not using the typedef'd name, as is
+ tested on gdb.cp/virtbase2.exp; the reason that test case is working
+ under gcc is that the dwarf generated by gcc links the class to the
+ original definition of the baseclass, not to the typedef. If the
+ inheritance is linked to the typedef, such as how clang does it,
+ gdb.cp/virtbase2.exp starts failing.
+
+ This can also be seen in gdb.cp/impl-this.exp, when attempting to print
+ D::Bint::i, and GDB not being able to find the baseclass Bint.
+
+ This happens because searching for baseclasses only uses the macro
+ TYPE_BASECLASS_NAME, which returns the typedef'd name. However, we can't
+ switch that macro to checking for typedefs, otherwise we wouldn't be
+ able to find the typedef'd name anymore. This is fixed by searching for
+ members or baseclasses by name, we check both the saved name and the
+ name after checking for typedefs.
+
+ This also fixes said long-standing bug in gdb.cp/impl-this.exp when the
+ compiler adds information about typedefs in the debuginfo.
+
+2022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Assign DWARF numbers to vector registers
+ This commit assigns DWARF register numbers to vector registers (v0-v31:
+ 96..127) to implement RISC-V DWARF Specification version 1.0-rc4
+ (now in the frozen state):
+
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc4
+
+ binutils/ChangeLog:
+
+ * dwarf.c (dwarf_regnames_riscv): Assign DWARF register numbers
+ 96..127 to vector registers v0-v31.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (tc_riscv_regname_to_dw2regnum): Support
+ vector registers.
+ * testsuite/gas/riscv/dw-regnums.s: Add vector registers to the
+ DWARF register number test.
+ * testsuite/gas/riscv/dw-regnums.d: Likewise.
+
+2022-10-03 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add testcase for DWARF register numbers
+ Although it had csr-dw-regnums.d (for CSRs), it didn't have DWARF register
+ number test for GPRs/FPRs.
+
+ This commit adds dw-regnums.{s,d} to test such registers.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/dw-regnums.s: New DWARF register number test
+ for GPRs/FPRs.
+ * testsuite/gas/riscv/dw-regnums.d: Likewise.
+
+2022-10-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix waitpid testing in next-fork-other-thread.c
+ In next-fork-other-thread.c, there's this loop:
+ ...
+ do
+ {
+ ret = waitpid (pid, &stat, 0);
+ } while (ret == EINTR);
+ ...
+
+ The loop condition tests for "ret == EINTR" but waitpid signals EINTR by
+ returning -1 and setting errno to EINTR.
+
+ Fix this by changing the loop condition to "ret == -1 && errno == EINTR".
+
+ Tested on x86_64-linux.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: handle invalid .exp names passed in TESTS
+ I ran some tests like:
+
+ $ make check-gdb TESTS="gdb.base/break.exp"
+
+ then, then I went to rerun the tests later, I managed to corrupt the
+ command line, like this:
+
+ $ make check-gdb TESTS="gdb.base/breakff.exp"
+
+ the make command did exit with an error, but DejaGnu appeared to
+ report that every test passed! The tail end of the output looks like
+ this:
+
+ Illegal Argument "no-matching-tests-found"
+ try "runtest --help" for option list
+ === gdb Summary ===
+
+ # of expected passes 115
+ /tmp/build/gdb/gdb version 13.0.50.20220831-git -nw -nx -iex "set height 0" -iex "set width 0" -data-directory /tmp/build/gdb/testsuite/../data-directory
+
+ make[3]: *** [Makefile:212: check-single] Error 1
+ make[3]: Leaving directory '/tmp/build/gdb/testsuite'
+ make[2]: *** [Makefile:161: check] Error 2
+ make[2]: Leaving directory '/tmp/build/gdb/testsuite'
+ make[1]: *** [Makefile:1916: check] Error 2
+ make[1]: Leaving directory '/tmp/build/gdb'
+ make: *** [Makefile:13565: check-gdb] Error 2
+
+ For a while, I didn't spot that DejaGnu had failed at all, I saw the
+ 115 passes, and thought everything had run correctly - though I was
+ puzzled that make was reporting an error.
+
+ What happens is that in gdb/testsuite/Makefile, in the check-single
+ rule, we first run DejaGnu, then run the dg-add-core-file-count.sh
+ script, and finally, we use sed to extract the results from the
+ gdb.sum file.
+
+ In my case, with the invalid test name, DejaGnu fails, but the
+ following steps are still run, the final result, the 115 passes, is
+ then extracted from the pre-existing gdb.sum file.
+
+ If I use 'make -jN' then the 'check-parallel' rule, rather than the
+ 'check-single' rule is used. In this case the behaviour is slightly
+ different, the tail end of the output now looks like this:
+
+ No matching tests found.
+
+ make[4]: Leaving directory '/tmp/build/gdb/testsuite'
+ find: ‘outputs’: No such file or directory
+ Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ...
+
+ tool The tool (e.g. g++, libffi) for which to create a
+ new test summary file. If not specified then output
+ is created for all tools.
+ variant-list One or more test variant names. If the list is
+ not specified then one is constructed from all
+ variants in the files for <tool>.
+ sum-file A test summary file with the format of those
+ created by runtest from DejaGnu.
+ If -L is used, merge *.log files instead of *.sum. In this
+ mode the exact order of lines may not be preserved, just different
+ Running *.exp chunks should be in correct order.
+ find: ‘outputs’: No such file or directory
+ Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ...
+
+ tool The tool (e.g. g++, libffi) for which to create a
+ new test summary file. If not specified then output
+ is created for all tools.
+ variant-list One or more test variant names. If the list is
+ not specified then one is constructed from all
+ variants in the files for <tool>.
+ sum-file A test summary file with the format of those
+ created by runtest from DejaGnu.
+ If -L is used, merge *.log files instead of *.sum. In this
+ mode the exact order of lines may not be preserved, just different
+ Running *.exp chunks should be in correct order.
+ make[3]: Leaving directory '/tmp/build/gdb/testsuite'
+ make[2]: Leaving directory '/tmp/build/gdb/testsuite'
+ make[1]: Leaving directory '/tmp/build/gdb'
+
+ Rather than DejaGnu failing, we now get a nice 'No matching tests
+ found' message, followed by some other noise. This other noise is
+ first `find` failing, followed by the dg-extract-results.py script
+ failing.
+
+ What happens here is that, in the check-parallel rule, the outputs
+ directory is deleted before DejaGnu is invoked. Then we try to run
+ all the tests, and finally we use find and dg-extract-results.py to
+ combine all the separate .sun and .log files together. However, if
+ there are no tests run then the outputs/ directory is never created,
+ so the find command and consequently the dg-extract-results.py script,
+ fail.
+
+ This commit aims to fix the following issues:
+
+ (1) For check-single and check-parallel rules, don't run any of the
+ post-processing steps if DejaGnu failed to run. This will avoid all
+ the noise after the initial failure of DejaGnu,
+
+ (2) For check-single ensure that we don't accidentally report
+ previous results, this is related to the above, but is worth calling
+ out as a separate point, and
+
+ (3) For check-single, print the 'No matching tests found' message
+ just like we do for a parallel test run. This makes the parallel and
+ non-parallel testing behaviour more similar, and I think is clearer
+ than the current 'Illegal Argument' error message.
+
+ Points (1) and (2) will be handled by moving the post processing steps
+ inside an if block within the recipe. For check-single I propose
+ deleting the gdb.sum and gdb.log files before running DejaGnu, this is
+ similar (I think) to how we delete the outputs/ directory in the
+ check-parallel rule.
+
+ For point (3) I plan to split the check-single rule in two, the
+ existing check-single will be renamed do-check-single, then a new
+ check-single rule will be added. The new check-single rule can either
+ depend on the new do-check-single, or will ensure the 'No matching
+ tests found' message is printed when appropriate.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/disasm: better intel flavour disassembly styling with Pygments
+ This commit was inspired by this stackoverflow post:
+
+ https://stackoverflow.com/questions/73491793/why-is-there-a-%C2%B1-in-lea-rax-rip-%C2%B1-0xeb3
+
+ One of the comments helpfully links to this Python test case:
+
+ from pygments import formatters, lexers, highlight
+
+ def colorize_disasm(content, gdbarch):
+ try:
+ lexer = lexers.get_lexer_by_name("asm")
+ formatter = formatters.TerminalFormatter()
+ return highlight(content, lexer, formatter).rstrip().encode()
+ except:
+ return None
+
+ print(colorize_disasm("lea [rip+0x211] # COMMENT", None).decode())
+
+ Run the test case and you should see that the '+' character is
+ underlined, and could be confused with a combined +/- symbol.
+
+ What's happening is that Pygments is failing to parse the input text,
+ and the '+' is actually being marked in the error style. The error
+ style is red and underlined.
+
+ It is worth noting that the assembly instruction being disassembled
+ here is an x86-64 instruction in the 'intel' disassembly style, rather
+ than the default att style. Clearly the Pygments module expects the
+ att syntax by default.
+
+ If we change the test case to this:
+
+ from pygments import formatters, lexers, highlight
+
+ def colorize_disasm(content, gdbarch):
+ try:
+ lexer = lexers.get_lexer_by_name("asm")
+ lexer.add_filter('raiseonerror')
+ formatter = formatters.TerminalFormatter()
+ return highlight(content, lexer, formatter).rstrip().encode()
+ except:
+ return None
+
+ res = colorize_disasm("lea rax,[rip+0xeb3] # COMMENT", None)
+ if res:
+ print(res.decode())
+ else:
+ print("No result!")
+
+ Here I've added the call: lexer.add_filter('raiseonerror'), and I am
+ now checking to see if the result is None or not. Running this and
+ the test now print 'No result!' - instead of styling the '+' in the
+ error style, we instead give up on the styling attempt.
+
+ There are two things we need to fix relating to this disassembly
+ text. First, Pygments is expecting att style disassembly, not the
+ intel style that this example uses. Fortunately, Pygments also
+ supports the intel style, all we need to do is use the 'nasm' lexer
+ instead of the 'asm' lexer.
+
+ However, this leads to the second problem; in our disassembler line we
+ have '# COMMENT'. The "official" Intel disassembler style uses ';'
+ for its comment character, however, gas and libopcodes use '#' as the
+ comment character, as gas uses ';' for an instruction separator.
+
+ Unfortunately, Pygments expects ';' as the comment character, and
+ treats '#' as an error, which means, with the addition of the
+ 'raiseonerror' filter, that any line containing a '#' comment, will
+ not get styled correctly.
+
+ However, as the i386 disassembler never produces a '#' character other
+ than for comments, we can easily "fix" Pygments parsing of the
+ disassembly line. This is done by creating a filter. This filter
+ looks for an Error token with the value '#', we then change this into
+ a comment token. Every token after this (until the end of the line)
+ is also converted into a comment.
+
+ In this commit I do the following:
+
+ 1. Check the 'disassembly-flavor' setting and select between the
+ 'asm' and 'nasm' lexers based on the setting. If the setting is not
+ available then the 'asm' lexer is used by default,
+
+ 2. Use "add_filter('raiseonerror')" to ensure that the formatted
+ output will not include any error text, which would be underlined,
+ and might be confusing,
+
+ 3. If the 'nasm' lexer is selected, then add an additional filter
+ that will format '#' and all other text on the line, as a comment,
+ and
+
+ 4. If Pygments throws an exception, instead of returning None,
+ return the original, unmodified content. This will mean that this
+ one instruction is printed without styling, but GDB will continue to
+ call into the Python code to style later instructions.
+
+ I haven't included a test specifically for the above error case,
+ though I have manually check that the above case now styles
+ correctly (with no underline). The existing style tests check that
+ the disassembler styling still works though, so I know I've not
+ generally broken things.
+
+ One final thought I have after looking at this issue is that I wonder
+ now if using Pygments for styling disassembly from every architecture
+ is actually a good idea?
+
+ Clearly, the 'asm' lexer is OK with att style x86-64, but not OK with
+ intel style x86-64, so who knows how well it will handle other random
+ architectures?
+
+ When I first added this feature I tested it against some random
+ RISC-V, ARM, and X86-64 (att style) code, and it seemed fine, but I
+ never tried to make an exhaustive check of all instructions, so its
+ quite possible that there are corner cases where things are styled
+ incorrectly.
+
+ With the above changes I think that things should be a bit better
+ now. If a particular instruction doesn't parse correctly then our
+ Pygments based styling code will just not style that one instruction.
+ This is combined with the fact that many architectures are now moving
+ to libopcodes based styling, which is much more reliable.
+
+ So, I think it is fine to keep using Pygments as a fallback mechanism
+ for styling all architectures, even if we know it might not be perfect
+ in all cases.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: improve disassembler styling when Pygments raises an exception
+ While working on another issue relating to GDB's use of the Python
+ Pygments package for disassembly styling I noticed an issue in the
+ case where the Pygments package raises an exception.
+
+ The intention of the current code is that, should the Pygments package
+ raise an exception, GDB will disable future attempts to call into the
+ Pygments code. This was intended to prevent repeated errors during
+ disassembly if, for some reason, the Pygments code isn't working.
+
+ Since the Pygments based styling was added, GDB now supports
+ disassembly styling using libopcodes, but this is only available for
+ some architectures. For architectures not covered by libopcodes
+ Pygments is still the only option.
+
+ What I observed is that, if I disable the libopcodes styling, then
+ setup GDB so that the Pygments based styling code will indicate an
+ error (by returning None), GDB does, as expected, stop using the
+ Pygments based styling. However, the libopcodes based styling will
+ instead be used, despite this feature having been disabled.
+
+ The problem is that the disassembler output is produced into a
+ string_file buffer. When we are using Pygments, this buffer is
+ created without styling support. However, when Pygments fails, we
+ recreate the buffer with styling support.
+
+ The problem is that we should only recreate the buffer with styling
+ support only if libopcodes styling is enabled. This was an oversight
+ in commit:
+
+ commit 4cbe4ca5da5cd7e1e6331ce11f024bf3c07b9744
+ Date: Mon Feb 14 14:40:52 2022 +0000
+
+ gdb: add support for disassembler styling using libopcodes
+
+ This commit:
+
+ 1. Factors out some of the condition checking logic into two new
+ helper functions use_ext_lang_for_styling and
+ use_libopcodes_for_styling,
+
+ 2. Reorders gdb_disassembler::m_buffer and gdb_disassembler::m_dest,
+ this allows these fields to be initialised m_dest first, which means
+ that the new condition checking functions can rely on m_dest being
+ set, even when called from the gdb_disassembler constructor,
+
+ 3. Make use of the new condition checking functions each time
+ m_buffer is initialised,
+
+ 4. Add a new test that forces the Python disassembler styling
+ function to return None, this will cause GDB to disable use of
+ Pygments for styling, and
+
+ 5. When we reinitialise m_buffer, and re-disassemble the
+ instruction, call reset the in-comment flag. If the instruction
+ being disassembler ends in a comment then the first disassembly pass
+ will have set the in-comment flag to true. This shouldn't be a
+ problem as we will only be using Pygments, and thus performing a
+ re-disassembly pass, if libopcodes is disabled, so the in-comment
+ flag will never be checked, even if it is set incorrectly. However,
+ I think that having the flag set correctly is a good thing, even if
+ we don't check it (you never know what future uses might come up).
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: extend styling test for libopcodes styling
+ This commit extends the gdb.base/style.exp test to cover disassembler
+ styling using libopcodes (where available).
+
+ The test will try to enable libopcode based styling, if this
+ works (because such styling is available) then some tests are run to
+ check that the output is styled, and that the styling can be disabled
+ using 'set style disassembler enabled off'. If libopcodes styling is
+ not available on the current architecture then these new tests will be
+ skipped.
+
+ I've moved the Python Pygments module check inside the
+ test_disable_disassembler_styling function now, so that the test will
+ be run even when Python Pygments is not available, this allows the new
+ tests discussed above.
+
+ If the Pygments module is not available then the Pygments based tests
+ will be skipped just as they were before.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: update now gdbarch_register_name doesn't return nullptr
+ After the previous few commit, gdbarch_register_name no longer returns
+ nullptr. This commit audits all the calls to gdbarch_register_name
+ and removes any code that checks the result against nullptr.
+
+ There should be no visible change after this commit.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: final cleanup of various gdbarch_register_name methods
+ Building on the previous commits, this commit goes through the various
+ gdbarch_register_name methods and removes all the remaining 'return
+ NULL' cases, I claim that these either couldn't be hit, or should be
+ returning the empty string.
+
+ In all cases the return of NULL was used if the register number being
+ passed to gdbarch_register_name was "invalid", i.e. negative, or
+ greater than the total number of declared registers. I don't believe
+ either of these cases can occur, and the previous commit asserts that
+ this is the case. As a result we can simplify the code by removing
+ these checks. In many cases, where the register names are held in an
+ array, I was able to add a static assert that the array contains the
+ correct number of strings, after that, a direct access into the array
+ is fine.
+
+ I don't have any means of testing these changes.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/csky: remove nullptr return from csky_pseudo_register_name
+ Building on the previous commits, in this commit I remove two
+ instances of 'return NULL' from csky_pseudo_register_name, and replace
+ them with a return of the empty string.
+
+ These two are particularly interesting, and worth pulling into their
+ own commit, because these returns of NULL appear to be depended on
+ within other parts of the csky code.
+
+ In csky-linux-tdep.c in the register collect/supply code, GDB checks
+ for the register name being nullptr in order to decide if a target
+ supports a particular feature or not. I've updated the code to check
+ for the empty string.
+
+ I have no way of testing this change.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add asserts to gdbarch_register_name
+ This commit adds asserts to gdbarch_register_name that validate the
+ parameters, and the return value.
+
+ The interesting thing here is that gdbarch_register_name is generated
+ by gdbarch.py, and so, to add these asserts, I need to update the
+ generation script.
+
+ I've added two new arguments for Functions and Methods (as declared in
+ gdbarch-components.py), these arguments are 'param_checks' and
+ 'result_checks'. Each of these new arguments can be used to list some
+ expressions that are then used within gdb_assert calls in the
+ generated code.
+
+ The asserts that validate the API as described in the comment I added
+ to gdbarch_register_name a few commits back; the register number
+ passed in needs to be a valid cooked register number, and the result
+ being returned should not be nullptr.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: check for duplicate register names in selftest
+ Building on the previous commit, this commit extends the register_name
+ selftest to check for duplicate register names.
+
+ If two registers in the cooked register set (real + pseudo registers)
+ have the same name, then this will show up as duplicate registers in
+ the 'info all-registers' output, but the user will only be able to
+ interact with one copy of the register.
+
+ In this commit I extend the selftest that I added in the previous
+ commit to check for duplicate register names, I didn't include this
+ functionality in the previous commit because one architecture needed
+ fixing, and I wanted to keep those fixes separate from the fixes in
+ the previous commit.
+
+ The problematic architecture(s) are powerpc:750 and powerpc:604. In
+ both of these cases the 'dabr' register appears twice, there's a
+ definition of dabr in power-oea.xml which is included into both
+ powerpc-604.xml and powerpc-750.xml. Both of these later two xml
+ files also define the dabr register.
+
+ I'm hopeful that this change shouldn't break anything, but I don't
+ have the ability to actually test this change, however:
+
+ On the gdbserver side, neither powerpc-604.xml nor powerpc-750.xml are
+ mentioned in gdbserver/configure.srv, which I think means that
+ gdbserver will never use these descriptions, and,
+
+ Within GDB the problematic descriptions are held in the variables
+ tdesc_powerpc_604 and tdesc_powerpc_750, which are only mentioned in
+ the variants array in rs6000-tdep.c, this is used when looking up a
+ description based on the architecture.
+
+ For a native Linux target however, this will not be used as
+ ppc_linux_nat_target::read_description exists, which calls
+ ppc_linux_match_description, which I don't believe can return either
+ of the problematic descriptions.
+
+ This leaves the other native targets, FreeBSD, AIX, etc. These don't
+ appear to override the ::read_description method, so will potentially
+ return the problematic descriptions, but, in each case I think the
+ ::fetch_registers and ::store_registers methods will ignore the dabr
+ register, which will leave the register as <unavailable>.
+
+ So, my proposed solution is to just remove the duplicate register from
+ each of powerpc-604.xml and powerpc-750.xml, then regenerate the
+ corresponding C++ source file. With this change made, the selftest
+ now passes for all architectures.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add a gdbarch_register_name self test, and fix some architectures
+ This commit adds a self-test that checks that gdbarch_register_name
+ never returns nullptr for any valid register number.
+
+ Most architectures already met this requirement, there were just 6
+ that failed the new selftest, and are updated in this commit.
+
+ Beyond the self-tests I don't have any facilities to test that the
+ architectures I've adjusted still work correctly.
+
+ If you review all the various gdbarch_register_name implementations
+ then you will see that there are far more architectures that seem like
+ they might return nullptr in some situations, e.g. alpha, avr, bpf,
+ etc. This commit doesn't attempt to address these cases as non of
+ them are hit during the selftest. Many of these cases can never be
+ hit, for example, in alpha_register_name GDB checks for a register
+ number less than zero, this case can't happen and could be changed
+ into an assert.
+
+ A later commit in this series will have a general cleanup of all the
+ various register_name methods, and remove all references to NULL from
+ their code, however, as that commit will be mostly adjusting code that
+ is never hit, I want to keep those changes separate.
+
+ The selftest has been tested on x86-64, but I don't have access to
+ suitable systems to fully test any of the *-tdep.c code I've changed
+ in this commit.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: add a comment to gdbarch_register_name
+ After the previous commit, this commit sets out to formalise the API
+ for gdbarch_register_name. Not every architecture is actually in
+ compliance with the API I set out here, but I believe that most are.
+
+ I think architectures that don't comply with the API laid out here
+ will fail the gdb.base/completion.exp test.
+
+ The claims in the comment are I feel, best demonstrated with the
+ asserts in this code:
+
+ const char *
+ gdbarch_register_name (struct gdbarch *gdbarch, int regnr)
+ {
+ gdb_assert (regnr >= 0);
+ gdb_assert (regnr < gdbarch_num_cooked_regs (gdbarch));
+
+ const char *name = gdbarch->register_name (gdbarch, regnr);
+
+ gdb_assert (name != nullptr);
+
+ return name;
+ }
+
+ Like I said, I don't believe every architecture follows these rules
+ right now, which is why I'm not actually adding any asserts. Instead,
+ this commit adds a comment to gdbarch_register_name, this comment is
+ where I'd like to get to, rather than where we are right now.
+
+ Subsequent commits will fix all targets to be in compliance with this
+ comment, and will even add the asserts shown above to
+ gdbarch_register_name.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: fix failure in gdb.base/completion.exp
+ I noticed a test failure in gdb.base/completion.exp for RISC-V on
+ a native Linux target, this is the failure:
+
+ (gdb) FAIL: gdb.base/completion.exp: complete 'info registers '
+
+ The problem is caused by a mismatch in the output of 'maint print
+ registers' and the completion list for 'info registers'. The 'info
+ registers' completion list contains less registers than
+ expected. Additionally, the list of registers extracted from the
+ 'maint print registers' list was wrong too, in some cases the test was
+ grabbing the register number, rather than a register name,
+
+ Both of these problems have the same root cause, riscv_register_name
+ returns nullptr for some registers when it should return an empty
+ string.
+
+ The gdbarch_register_name API is not clearly documented anywhere, and
+ at first glance it would appear that the function can return either
+ nullptr, or an empty string to indicate that a register is not
+ available on the current target. Indeed, there are plenty of places
+ in GDB where we compare the output of gdbarch_register_name to both
+ nullptr and '\0' in order to see if a register is supported or not,
+ and there are plenty of targets that return empty string in some
+ cases, and nullptr in others.
+
+ However, the 'info registers' completion code (reg_or_group_completer)
+ clearly depends on user_reg_map_regnum_to_name only returning nullptr
+ when the passed in regnum is greater than the maximum possible
+ register number (i.e. after all physical registers, pseudo-registers,
+ and user-registers), this means that gdbarch_register_name should not
+ be returning nullptr.
+
+ I did consider "fixing" user_reg_map_regnum_to_name, if
+ gdbarch_register_name returns nullptr, I could convert to an empty
+ string at this point, but that felt like a real hack, so I discarded
+ that plan.
+
+ The next possibility I considered was "fixing" reg_or_group_completer
+ to not rely on nullptr to indicate the end marker. Or rather, I could
+ have reg_or_group_completer use gdbarch_num_cooked_regs, we know that
+ we should check at least that many register numbers. Then, once we're
+ passed that limit, we keep checking until we hit a nullptr. This
+ would absolutely work, and didn't actually feel that bad, but, it
+ still felt a little weird that gdbarch_register_name could return
+ nullptr OR the empty string to mean the same thing, so I wondered if
+ the "right" solution was to have gdbarch_register_name not return
+ nullptr. With this in mind I tried an experiment:
+
+ I added a self-test that, for each architecture, calls
+ gdbarch_register_name for every register number up to the
+ gdbarch_num_cooked_regs limit, and checks that the name is not
+ nullptr.
+
+ Only a handful of architectures failed this test, RISC-V being one of
+ them.
+
+ This seems to suggest that most architectures agree that the correct
+ API for gdbarch_register_name is to return an empty string for
+ registers that are not supported on the current target, and that
+ returning nullptr is really a mistake.
+
+ In this commit I will update the RISC-V target so that GDB no longer
+ returns nullptr from riscv_register_name, instead we return the empty
+ string.
+
+ In subsequent commits I will add the selftest that I mention above,
+ and will fix the targets that fail the selftest.
+
+ With this change the gdb.base/completion.exp test now passes.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: rewrite capture_command_output proc
+ I noticed a test failure in gdb.base/completion.exp for RISC-V on a
+ native Linux target. Upon investigation I discovered a couple of
+ reasons for the failure, this commit addresses one of them. A later
+ commit will address the other issue.
+
+ The completion.exp test makes use of the capture_command_output proc
+ to collect the output of the 'maint print registers' command. For
+ RISC-V this command produces a lot of output.
+
+ Currently the capture_command_output proc tries to collect the
+ complete command output in a single expect buffer, and what I see is
+ an error caused by the expect buffer becoming full.
+
+ This commit rewrites capture_command_output to make use of
+ gdb_test_multiple to collect the command output line at a time, in
+ this way we avoid overflowing the expect buffer.
+
+ The capture_command_output proc has some logic for skipping a prefix
+ pattern, which is passed in to the proc as an argument. In order to
+ handle this correctly (only matching the prefix at the start of the
+ command output), I use two gdb_test_multiple calls, the first spots
+ and discards the echoed command and the (optional) prefix pattern, the
+ second gdb_test_multiple call then collects the rest of the command
+ output line at a time until a prompt is seen.
+
+ There is one slight oddity with the current implementation, which I
+ have changed in my rewrite, this does, slightly, change the behaviour
+ of the proc.
+
+ The current implementation uses this pattern:
+
+ -re "[string_to_regexp ${command}]\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $"
+
+ Now a typical command output will look like this:
+
+ output here\r\n
+ (gdb)
+
+ As the TCL regexp matching is greedy, TCL will try to match as much as
+ possible in one part of the pattern before moving on to the next.
+ Thus, when this matches against (.*)[\r\n]+, the (.*) will end up
+ matching against 'output here\r' and the [\r\n]+ will match '\n' only.
+
+ In short the previous implementation would leave the '\r' on the end
+ of the returned text, but not the final trailing '\n'.
+
+ Now clearly I could make a new version of capture_command_output that
+ maintained this behaviour, but I couldn't see any reason to do this.
+ So, my new implementation drops the final '\r\n' completely, in our
+ example above we now return 'output here' with no '\r'.
+
+ This change doesn't seem to affect any of the existing tests, but I
+ thought it was worth mentioning.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: new options for -data-disassemble command
+ Now that the disassembler has two different strategies for laying out
+ the opcode bytes of an instruction (see /r vs /b for the disassemble
+ command), I wanted to add support for this to the MI disassemble
+ command.
+
+ Currently the -data-disassemble command takes a single 'mode' value,
+ which currently has 6 different values (0 -> 5), 3 of these modes
+ relate to opcode display.
+
+ So, clearly I should just add an additional 3 modes to handle the new
+ opcode format, right?
+
+ No, I didn't think that was a great idea either.
+
+ So, I wonder, could I adjust the -data-disassemble command in a
+ backward compatible way, that would allow GDB to move away from using
+ the mode value altogether?
+
+ I think we can.
+
+ In this commit, I propose adding two new options to -data-disassemble,
+ these are:
+
+ --opcodes none|bytes|display
+ --source
+
+ Additionally, I will make the mode optional, and default to mode 0 if
+ no mode value is given. Mode 0 is the simplest, no source code, no
+ opcodes disassembly mode.
+
+ The two new options are only valid for mode 0, if they are used with
+ any other mode then an error is thrown.
+
+ The --opcodes option can add opcodes to the result, with 'bytes' being
+ equivalent to 'disassemble /b' and 'display' being 'disassemble /r'.
+
+ The --source option will enable the /s style source code display, this
+ is equivalent to modes 4 and 5. There is no way, using the new
+ command options to get the now deprecated /m style source code
+ display, that is mode 1 and 3.
+
+ My hope is that new users of the MI will not use the mode at all, and
+ instead will just use the new options to achieve the output they need.
+ Existing MI users can continue to use the mode, and will not need to
+ be updated to use the new options.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: some int to bool conversion
+ Just some simple int to bool conversion in mi_cmd_disassemble. There
+ should be no user visible changes after this commit.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: update syntax of -data-disassemble command arguments
+ The argument documentation for -data-disassemble looks like this:
+
+ -data-disassemble
+ [ -s @var{start-addr} -e @var{end-addr} ]
+ | [ -a @var{addr} ]
+ | [ -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ]
+ -- @var{mode}
+
+ However, I believe, according to the 'Notation and Terminology'
+ section, this means that the there are 3 optional location
+ specification argument groups for the command, followed by a
+ non-optional '-- mode'.
+
+ However, this is not true, one of the location specifications must be
+ given, i.e. we can't choose to give NO location specification, which
+ is what the above implies.
+
+ I propose that we change this to instead be:
+
+ -data-disassemble
+ ( -s @var{start-addr} -e @var{end-addr}
+ | -a @var{addr}
+ | -f @var{filename} -l @var{linenum} [ -n @var{lines} ] )
+ -- @var{mode}
+
+ By placing all the location specifications within '( ... )' we
+ indication that these are a group, from which one of the options,
+ separated by '|', must be selected.
+
+ However, the 'Notation and Terminology' section only describes two
+ uses for parenthesis: '( GROUP )*' and '( GROUP )+', in the first case
+ GROUP is repeated zero or more times, and in the second GROUP is
+ repeated 1 or more times.
+
+ Neither of those exactly describe what I want, which is GROUP must
+ appear exactly once. I propose to extend 'Notation and Terminology'
+ to include '( GROUP )' which means that GROUP should appear exactly
+ once.
+
+ This change is important because, in a later commit, I want to add
+ additional optional arguments to the -data-disassemble command, and
+ things start to get confusing with the original syntax.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make gdb_disassembly_flag unsigned
+ In a later commit I want to use operator~ on a gdb_disassembly_flag
+ flag value. This is currently not possible as gdb_disassembly_flag
+ is, by default, signed.
+
+ This commit just makes this enum unsigned.
+
+ There should be no user visible changes after this commit.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: disassembler opcode display formatting
+ This commit changes the format of 'disassemble /r' to match GNU
+ objdump. Specifically, GDB will now display the instruction bytes in
+ as 'objdump --wide --disassemble' does.
+
+ Here is an example for RISC-V before this patch:
+
+ (gdb) disassemble /r 0x0001018e,0x0001019e
+ Dump of assembler code from 0x1018e to 0x1019e:
+ 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0)
+ 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0)
+ 0x00010196 <call_me+74>: 61 65 lui a0,0x18
+ 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704
+ 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf>
+ End of assembler dump.
+
+ And here's an example after this patch:
+
+ (gdb) disassemble /r 0x0001018e,0x0001019e
+ Dump of assembler code from 0x1018e to 0x1019e:
+ 0x0001018e <call_me+66>: fe842603 lw a2,-24(s0)
+ 0x00010192 <call_me+70>: fec42583 lw a1,-20(s0)
+ 0x00010196 <call_me+74>: 6561 lui a0,0x18
+ 0x00010198 <call_me+76>: 6a850513 addi a0,a0,1704
+ 0x0001019c <call_me+80>: 22f1 jal 0x10368 <printf>
+ End of assembler dump.
+
+ There are two differences here. First, the instruction bytes after
+ the patch are grouped based on the size of the instruction, and are
+ byte-swapped to little-endian order.
+
+ Second, after the patch, GDB now uses the bytes-per-line hint from
+ libopcodes to add whitespace padding after the opcode bytes, this
+ means that in most cases the instructions are nicely aligned.
+
+ It is still possible for a very long instruction to intrude into the
+ disassembled text space. The next example is x86-64, before the
+ patch:
+
+ (gdb) disassemble /r main
+ Dump of assembler code for function main:
+ 0x0000000000401106 <+0>: 55 push %rbp
+ 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp
+ 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi)
+ 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax
+ 0x0000000000401119 <+19>: 5d pop %rbp
+ 0x000000000040111a <+20>: c3 ret
+ End of assembler dump.
+
+ And after the patch:
+
+ (gdb) disassemble /r main
+ Dump of assembler code for function main:
+ 0x0000000000401106 <+0>: 55 push %rbp
+ 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp
+ 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi)
+ 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax
+ 0x0000000000401119 <+19>: 5d pop %rbp
+ 0x000000000040111a <+20>: c3 ret
+ End of assembler dump.
+
+ Most instructions are aligned, except for the very long instruction.
+ Notice too that for x86-64 libopcodes doesn't request that GDB group
+ the instruction bytes. This matches the behaviour of objdump.
+
+ In case the user really wants the old behaviour, I have added a new
+ modifier 'disassemble /b', this displays the instruction byte at a
+ time. For x86-64, which never groups instruction bytes, /b and /r are
+ equivalent, but for RISC-V, using /b gets the old layout back (except
+ that the whitespace for alignment is still present). Consider our
+ original RISC-V example, this time using /b:
+
+ (gdb) disassemble /b 0x0001018e,0x0001019e
+ Dump of assembler code from 0x1018e to 0x1019e:
+ 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0)
+ 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0)
+ 0x00010196 <call_me+74>: 61 65 lui a0,0x18
+ 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704
+ 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf>
+ End of assembler dump.
+
+ Obviously, this patch is a potentially significant change to the
+ behaviour or /r. I could have added /b with the new behaviour and
+ left /r alone. However, personally, I feel the new behaviour is
+ significantly better than the old, hence, I made /r be what I consider
+ the "better" behaviour.
+
+ The reason I prefer the new behaviour is that, when I use /r, I almost
+ always want to manually decode the instruction for some reason, and
+ having the bytes displayed in "instruction order" rather than memory
+ order, just makes this easier.
+
+ The 'record instruction-history' command also takes a /r modifier, and
+ has been modified in the same way as disassemble; /r gets the new
+ behaviour, and /b has been added to retain the old behaviour.
+
+ Finally, the MI command -data-disassemble, is unchanged in behaviour,
+ this command now requests the raw bytes of the instruction, which is
+ equivalent to the /b modifier. This means that the MI output will
+ remain backward compatible.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/disasm: read opcodes bytes with a single read_code call
+ This commit reduces the number of times we call read_code when
+ printing the instruction opcode bytes during disassembly.
+
+ I've added a new gdb::byte_vector within the
+ gdb_pretty_print_disassembler class, in line with all the other
+ buffers that gdb_pretty_print_disassembler needs. This byte_vector is
+ then resized as needed, and filled with a single read_code call for
+ each instruction.
+
+ There should be no user visible changes after this commit.
+
+2022-10-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: new test for -data-disassemble opcodes format
+ Add another test for the output of MI command -data-disassemble. The
+ new check validates the format of the 'opcodes' field, specifically,
+ this test checks that the field contains a series of bytes, separated
+ by a single space.
+
+ We also check that the bytes are in the correct order, that is, the
+ first byte is from the lowest address, and subsequent bytes are from
+ increasing addresses.
+
+ The motivation for this test (besides more tests being generally good)
+ is that I plan to make changes to how opcode bytes are displayed in
+ the disassembler output, and I want to ensure that I don't break any
+ existing MI behaviour.
+
+ There should be no user visible changes to GDB after this commit.
+
+2022-10-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-10-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Relax "fmv.[sdq]" requirements
+ This commit relaxes requirements to "fmv.s" instructions from 'F' to ('F'
+ or 'Zfinx'). The same applies to "fmv.d" and "fmv.q". Note that 'Zhinx'
+ extension already contains "fmv.h" instruction (as well as 'Zfh').
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zfinx.s: Add "fmv.s" instruction.
+ * testsuite/gas/riscv/zfinx.d: Likewise.
+ * testsuite/gas/riscv/zdinx.s: Add "fmv.d" instruction.
+ * testsuite/gas/riscv/zdinx.d: Likewise.
+ * testsuite/gas/riscv/zqinx.d: Add "fmv.q" instruction.
+ * testsuite/gas/riscv/zqinx.s: Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Relax requirements to "fmv.[sdq]"
+ instructions to support those in 'Zfinx'/'Zdinx'/'Zqinx'.
+
+2022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Reorganize and enhance 'Zfinx' tests
+ This commit adds certain test cases for 'Zfinx'/'Zdinx'/'Zqinx' extensions
+ and reorganizes them, fixing coding style while improving coverage.
+ This is partially based on jiawei's 'Zhinx' testcases.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zfinx.s: Use different registers for
+ better encode space testing. Make indentation consistent.
+ Add tests for instruction with rounding mode. Change march
+ to minimum required extensions. Remove source line.
+ * testsuite/gas/riscv/zfinx.d: Likewise.
+ * testsuite/gas/riscv/zdinx.s: Likewise.
+ * testsuite/gas/riscv/zdinx.d: Likewise.
+ * testsuite/gas/riscv/zqinx.s: Likewise.
+ Also use even-numbered registers to use valid register pairs.
+ * testsuite/gas/riscv/zqinx.d: Likewise.
+
+2022-09-30 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Eliminate long-casts of X_add_number in diagnostics
+ There is no need for casts to (signed/unsigned) long, as we can use
+ C99's PRId64/PRIu64 format specifiers.
+
+2022-09-30 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: fallout from "re-arrange opcode table for consistent alias handling"
+ Several new testcasee have appeared since the submission of said change,
+ some of which now also need adjustment.
+
+ RISC-V: fix build after "Add support for arbitrary immediate encoding formats"
+ Pre- and post-increment/decrement are side effects, the behavior of
+ which is undefined when combined with passing an address of the accessed
+ variable in the same function invocation. There's no need for the
+ increments here - simply adding 1 achieves the intended effect without
+ triggering compiler diagnostics (which are fatal with -Werror).
+
+ objcopy: avoid "shadowing" of remove() function name
+ remove() is a standard library function (declared in stdio.h), which
+ triggers a "shadows a global declaration" warning with some gcc versions.
+
+ RISC-V: drop stray INSN_ALIAS flags
+ FENCE.TSO isn't an alias. ZIP and UNZIP in the long run likely are, but
+ presently they aren't. This fixes disassembly of these insns with
+ -Mno-aliases.
+
+2022-09-30 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: re-arrange opcode table for consistent alias handling
+ For disassembly to pick up aliases in favor of underlying insns (helping
+ readability in the common case), the aliases need to come ahead of the
+ "base" insns. Slightly more code movement is needed because of insns
+ with the same name needing to stay next to each other.
+
+ Note that the "rorw" alias entry also has the missing INSN_ALIAS added
+ here.
+
+ Clone a few testcases to exercise -Mno-aliases some more, better
+ covering the differences between the default and that disassembly mode.
+
+2022-09-30 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct build dependencies in opcodes/
+ With the command in the rule merely being "echo", i386-tbl.h won't be
+ rebuilt if missing, when at the same time i386-init.h is present and
+ up-to-date. Use a pattern rule instead to express the multiple targets
+ correctly (the &: rule separator is supported only by GNU make 4.3 and
+ newer). Note that now, for the opposite case to work (i386-tbl.h is
+ up-to-date but i386-init.h is missing), i386-init.h also needs
+ mentioning as a dependency somewhere: Add a fake dependency for
+ i386-opc.lo ("fake" because i386-opc.c doesn't include that header).
+
+ At the same time use $(AM_V_GEN) in the actual rule, replacing the
+ earlier (open-coded) "echo". And while there also drop a duplicate
+ dependency of i386-gen.o on i386-opc.h.
+
+2022-09-30 Jan Beulich <jbeulich@suse.com>
+
+ x86: improve match_template()'s diagnostics
+ At the example of
+
+ extractps $0, %xmm0, %xmm0
+ insertps $0, %xmm0, %eax
+
+ (both having respectively the same mistake of using the wrong kind of
+ destination register) it is easy to see that current behavior is far
+ from ideal: The former results in "unsupported instruction" for 32-bit
+ code simply because the 2nd template we have is a Cpu64 one. Instead we
+ should aim at emitting the "best" possible error, which will typically
+ be the one where we passed the largest number of checks. Generalize the
+ original "specific_error" approach by making it apply to the entire
+ matching loop, utilizing that line numbers increase as we pass further
+ checks.
+
+2022-09-30 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: restrict suffix derivation
+ While in some cases deriving an AT&T-style suffix from an Intel syntax
+ memory operand size specifier is necessary, in many cases this is not
+ only pointless, but has led to the introduction of various workarounds:
+ Excessive use of IgnoreSize and NoRex64 as well as the ToDword and
+ ToQword attributes. Suppress suffix derivation when we can clearly tell
+ that the memory operand's size isn't going to be needed to infer the
+ possible need for the low byte/word opcode bit or an operand size prefix
+ (0x66 or REX.W).
+
+ As a result ToDword and ToQword can be dropped entirely, plus a fair
+ number of IgnoreSize and NoRex64 can also be got rid of. Note that
+ IgnoreSize needs to remain on legacy encoded SIMD insns with GPR
+ operand, to avoid emitting an operand size prefix in 16-bit mode. (Since
+ 16-bit code using SIMD insns isn't well tested, clone an existing
+ testcase just enough to cover a few insns which are potentially
+ problematic but are being touched here.)
+
+ Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI
+ isn't included there. This is to fulfill the request of not allowing L
+ and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI.
+
+2022-09-30 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Update ELF e_flags handling according to specification.
+ Update handling of e_flags according to the documentation
+ update [1] (discussions [2][3]).
+
+ Object file bitness is now represented in the EI_CLASS byte.
+ The e_flags field is now interpreted as follows:
+
+ e_flags[2:0]: Base ABI modifier
+
+ - 0x1: soft-float
+ - 0x2: single-precision hard-float
+ - 0x3: double-precision hard-float
+
+ e_flags[7:6]: ELF object ABI version
+
+ - 0x0: v0
+ - 0x1: v1
+
+ [1]: https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc#e_flags-identifies-abi-type-and-version
+ [2]: https://github.com/loongson/LoongArch-Documentation/pull/61
+ [3]: https://github.com/loongson/LoongArch-Documentation/pull/47
+
+2022-09-30 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix cppcheck warnings
+ gprofng/ChangeLog
+ 2022-09-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * common/hwcdrv.c: Fix cppcheck warning.
+ * src/ABS.h: Likewise.
+ * src/CompCom.cc: Likewise.
+
+2022-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/mi-sym-info.exp on openSUSE Tumbleweed
+ On openSUSE Tumbleweed, I run into:
+ ...
+ FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only
+ ...
+
+ The problem is in matching this string:
+ ...
+ {name="_start",type="void (void)",description="void _start(void);"}
+ ...
+ using regexp fun_re, which requires a line field:
+ ...
+ set fun_re \
+ "\{line=\"$decimal\",name=${qstr},type=${qstr},description=${qstr}\}"
+ ...
+
+ Fix this by making the line field optional in fun_re.
+
+ Tested on x86_64-linux.
+
+2022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add privileged extensions without instructions/CSRs
+ Currently, GNU Binutils does not support following privileged extensions:
+
+ - 'Smepmp'
+ - 'Svnapot'
+ - 'Svpbmt'
+
+ as they do not provide new CSRs or new instructions ('Smepmp' extends the
+ privileged architecture CSRs but does not define the CSR itself). However,
+ adding them might be useful as we no longer have to "filter" ISA strings
+ just for toolchains (if full ISA string is given by a vendor, we can
+ straightly use it).
+
+ And there's a fact that supports this theory: there's already an
+ (unprivileged) extension which does not provide CSRs or instructions (but
+ only an architectural guarantee): 'Zkt' (constant timing guarantee for
+ certain subset of RISC-V instructions).
+
+ This simple commit simply adds three privileged extensions listed above.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
+ 'Svnapot' and 'Svpbmt' extensions.
+
+2022-09-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdb: Remove unused extra_lines variable
+ Clang generates a warning if there is a variable that is set but not used
+ otherwise ("-Wunused-but-set-variable"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ The only extra_lines use in arrange_linetable function is removed on the
+ commit 558802e4d1c5dcbd0df7d2c6ef62a6deac247a2f
+ ("gdb: change subfile::line_vector to an std::vector"). So, this variable
+ should be removed to prevent a build failure.
+
+2022-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add aranges to gdb.dwarf2/dw2-dir-file-name.exp
+ Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
+ for ppc64le"), the test-case fails with target board cc-with-debug-names, due
+ to missing .debug_aranges info.
+
+ Add the missing .debug_aranges info.
+
+ Also add a file_id option to Dwarf::assemble, to make it possible to contribute
+ to an already open file.
+
+ Tested on x86_64-linux.
+
+2022-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/c++] Print destructor the same for gcc and clang
+ Consider the test-case contained in this patch.
+
+ With g++ (7.5.0) we have for "ptype A":
+ ...
+ type = class A {
+ public:
+ int a;
+
+ A(void);
+ ~A();
+ }
+ ...
+ and with clang++ (13.0.1):
+ ...
+ type = class A {
+ public:
+ int a;
+
+ A(void);
+ ~A(void);
+ }
+ ...
+ and we observe that the destructor is printed differently.
+
+ There's a difference in debug info between the two cases: in the clang case,
+ there's one artificial parameter, but in the g++ case, there are two, and
+ these similar cases are handled differently in cp_type_print_method_args.
+
+ This is due to this slightly convoluted bit of code:
+ ...
+ i = staticp ? 0 : 1;
+ if (nargs > i)
+ {
+ while (i < nargs)
+ ...
+ }
+ else if (varargs)
+ gdb_printf (stream, "...");
+ else if (language == language_cplus)
+ gdb_printf (stream, "void");
+ ...
+
+ The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit
+ this parameter.
+
+ In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other
+ artificial parameters was added, but using a different method: rather than
+ adjusting the potential loop start, it skips the parameter in the loop.
+
+ The observed difference in printing is explained by whether we enter the loop:
+ - in the clang case, the loop is not entered and we print "void".
+ - in the gcc case, the loop is entered, and nothing is printed.
+
+ Fix this by rewriting the code to:
+ - always enter the loop
+ - handle whether arguments need printing in the loop
+ - keep track of how many arguments are printed, and
+ use that after the loop to print void etc.
+ such that we have the same for both gcc and clang:
+ ...
+ A(void);
+ ~A(void);
+ ...
+
+ Note that I consider the discussion of whether we want to print:
+ - A(void) / ~A(void), or
+ - A() / ~A()
+ out-of-scope for this patch.
+
+ Tested on x86_64-linux.
+
+2022-09-30 Alan Modra <amodra@gmail.com>
+
+ PR29626, Segfault when disassembling ARM code
+ PR 29626
+ * arm-dis.c (mapping_symbol_for_insn): Return false on zero
+ symtab_size. Delete later symtab_size test.
+
+2022-09-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make target_auxv_parse static and rename
+ It is only used in auxv.c. Also, given it is not strictly a wrapper
+ around target_ops::auxv (since 27a48a9223d0 "Add auxv parsing to the
+ architecture vector."), I think that the name prefixed with target is a
+ bit misleading. Rename to just parse_auxv.
+
+ Change-Id: I41cca055b92c8ede37c258ba6583746a07d8f77e
+
+2022-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make fprint_target_auxv static
+ It's only used in auxv.c.
+
+ Change-Id: I4992d9aae37b6631a074ab99bbab2f619725b642
+
+2022-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: constify auxv parse functions
+ Constify the input parameters of the various auxv parse functions, they
+ don't need to modify the raw auxv data.
+
+ Change-Id: I13eacd5ab8e925ec2b5c1f7722cbab39c41516ec
+
+2022-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: constify target_stack::is_pushed
+ The target_ops parameters here can be made const.
+
+ Change-Id: Ibc18b17d6b21d06145251a03e68aca90538117d6
+
+2022-09-29 Keith Seitz <keiths@redhat.com>
+
+ Constify target_desc declarations
+ This patch changes various global target_desc declarations to const, thereby
+ correcting a prominent source of ODR violations in PowerPC-related target code.
+ The majority of files/changes are mechanical const-ifications accomplished by
+ regenerating the C files in features/.
+
+ This also required manually updating mips-linux-tdep.h, s390-linux-tdep.h,
+ nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c,
+ and rs6000-tdep.c.
+
+ Patch tested against the sourceware trybot, and fully regression tested against
+ our (Red Hat's) internal test infrastructure on Rawhide aarch64, s390x, x86_64,
+ and powerpcle.
+
+ With this patch, I can finally enable LTO in our GDB package builds. [Tested
+ with a rawhide scratch build containing this patch.]
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24835
+
+2022-09-29 Keith Seitz <keiths@redhat.com>
+
+ cleanup: Add missing feature/ XML files to Makefile
+ This patch adds some missing .xml files to features/Makefile so that when the
+ directory's C files are regenerated, all files are appropriately remade.
+
+ This has demonstrated that there have been several "misses" in regenerating
+ files in this directory. Namely, arm-secext.c and sparc{32,64}-solaris.c. For
+ the former case, there was what essentially amounts to a typo regarding the
+ create feature function's name. In the later case, this file has missed at least
+ one important update in July, 2020, when allocate_target_description was
+ changed to return a unique pointer.
+
+ Those corrections are included.
+
+2022-09-29 Nick Clifton <nickc@redhat.com>
+
+ Add -B to the help output from gprof, and add suitable documentation.
+ PR 29627
+ * gprof.c (usage): Add -B.
+ * gprof.texi (synopsis): Add -B.
+ (Output Options): Add entry for -B.
+
+2022-09-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-28 Pedro Alves <pedro@palves.net>
+
+ Fix GDB build: ELF support check & -lzstd
+ GDB fails to build for me, on Ubuntu 20.04. I get:
+
+ ...
+ CXXLD gdb
+ /usr/bin/ld: linux-tdep.o: in function `linux_corefile_thread(thread_info*, linux_corefile_thread_data*)':
+ /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:1831: undefined reference to `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, gdb_signal, bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
+ /usr/bin/ld: linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, bfd*, int*)':
+ /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:2117: undefined reference to `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
+ collect2: error: ld returned 1 exit status
+ make[2]: *** [Makefile:2149: gdb] Error 1
+ make[2]: Leaving directory '/home/pedro/gdb/binutils-gdb/build/gdb'
+ make[1]: *** [Makefile:11847: all-gdb] Error 2
+ make[1]: Leaving directory '/home/pedro/gdb/binutils-gdb/build'
+ make: *** [Makefile:1004: all] Error 2
+
+ Those undefined functions exist in gdb/gcore-elf.c, which is only
+ included in the build if GDB's configure thinks that the target you're
+ configuring for is an ELF target. GDB's configure thinks my system
+ isn't ELF, which is incorrect.
+
+ For the ELF support check, gdb/config.log shows:
+
+ configure:17387: checking for ELF support in BFD
+ configure:17407: gcc -o conftest -I/home/pedro/gdb/binutils-gdb/src/gdb/../include -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdb/../bfd -g3 -O0 -L../bfd -L../libiberty -lzstd conftest.c -lbfd -liberty -lz -lncursesw -lm -ldl >&5
+ /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `decompress_contents':
+ /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:42: undefined reference to `ZSTD_decompress'
+ /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:44: undefined reference to `ZSTD_isError'
+ /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents':
+ /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:195: undefined reference to `ZSTD_compress'
+ /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:198: undefined reference to `ZSTD_isError'
+ collect2: error: ld returned 1 exit status
+ configure:17407: $? = 1
+ ...
+ configure:17417: result: no
+
+ Note how above, in the gcc command line, "-lzstd" appears before
+ "-lbfd". That explain the link failure. It should appear after, like
+ -lz does.
+
+ This commit fixes it, by moving ZSTD_LIBS from LDFLAGS to LIBS, next
+ to -lz, in GDB_AC_CHECK_BFD, and regenerating gdb/configure.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29630
+ Change-Id: I1f4128dde634e8ea04c9002904f1005a8b3a6863
+
+2022-09-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove trailing spaces in README
+ Change-Id: Ic7f8e415acd1bff6194cf08ed646bff45571f165
+
+2022-09-28 Tom Tromey <tromey@adacore.com>
+
+ Treat Character as a discrete type in Ada
+ A user noticed that gdb would assert when printing a certain array
+ with array-indexes enabled. This turned out to be caused by the array
+ having an index type of Character, which is completely valid in Ada.
+ This patch changes the Ada support to recognize Character as a
+ discrete type, and adds some tests.
+
+ Because this is Ada-specific and was also reviewed internally, I am
+ checking it in.
+
+2022-09-28 Nick Clifton <nickc@redhat.com>
+
+ The help document of size misses an option.
+ PR 29628
+ * size.c (usage): Add -f.
+ * doc/binutils.texi (size): Add -f.
+
+2022-09-28 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: force warnings when dealing with execstack tests
+ Binutils can be configured to avoid printing the execstack or RWD
+ segment warnings. In this case, the first test of PR ld/29072 will fail.
+ Fix that by always manually forcing the warnings for it.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elf/elf.exp (PR ld/29072): Force execstack and
+ RWD segment warnings.
+
+2022-09-28 Alan Modra <amodra@gmail.com>
+
+ Re: egrep in binutils
+ Multi-line patterns for grep are not supported on some old versions
+ of grep.
+
+ binutils/
+ * embedspu.sh: Replace multi-line grep with sed.
+ ld/
+ * testsuite/ld-elfvers/vers.exp: Replace multi-line grep with sed.
+
+2022-09-28 Pedro Alves <pedro@palves.net>
+
+ Renenerate {gdb,gdbserver}/configure
+ Pick up config/lib-ld.m4 changes from:
+
+ commit 67d1991b785bdfef1d70cddfa0202b99b43ccce9
+ Author: Alan Modra <amodra@gmail.com>
+ AuthorDate: Wed Sep 28 13:37:31 2022 +0930
+ Commit: Alan Modra <amodra@gmail.com>
+ CommitDate: Wed Sep 28 13:37:31 2022 +0930
+
+ egrep in binutils
+
+ Change-Id: Ifc84d30f1fca015e80bafa80f9a35616b0077220
+
+2022-09-28 Nick Clifton <nickc@redhat.com>
+
+ The help document of as misses some many options
+ PR 29623
+ * as.c (show_usage): Document the --dump-config,
+ --gdwarf-cie-version, --hash-size, --multibyte-handling,
+ and --reduce-memory-overheads options.
+ * config/tc-i386.c (md_show_usage): Document the -O option.
+ * doc/as.texi: Document the --dump-config, --emulation,
+ --hash-size, and --reduce-memory-overheads options.
+
+2022-09-28 Alan Modra <amodra@gmail.com>
+
+ egrep in binutils
+ Apparently some distros have a nagging egrep that helpfully tells you
+ egrep is deprecated and to use "grep -E". The nag message causes a ld
+ testsuite failure. What's more the advice isn't that good. The "-E"
+ flag may not be available with older versions of grep.
+
+ This patch fixes bare invocation of egrep within binutils, replacing
+ it with the autoconf $EGREP or with grep.
+
+ config/
+ * lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
+ invoke $EGREP.
+ (AC_LIB_PROG_LD): Likewise.
+ binutils/
+ * configure: Regenerate.
+ * embedspu.sh: Replace egrep with grep.
+ gold/
+ * testsuite/Makefile.am (flagstest_compress_debug_sections.check):
+ Replace egrep with grep.
+ * testsuite/Makefile.in: Regenerate.
+ * testsuite/bnd_ifunc_1.sh: Replace egrep with $EGREP.
+ * testsuite/bnd_ifunc_2.sh: Likewise.
+ * testsuite/bnd_plt_1.sh: Likewise.
+ * testsuite/discard_locals_test.sh: Likewise.
+ * testsuite/gnu_property_test.sh: Likewise.
+ * testsuite/no_version_test.sh: Likewise.
+ * testsuite/pr18689.sh: Likewise.
+ * testsuite/pr26936.sh: Likewise.
+ * testsuite/retain.sh: Likewise.
+ * testsuite/split_i386.sh: Likewise.
+ * testsuite/split_s390.sh: Likewise.
+ * testsuite/split_x32.sh: Likewise.
+ * testsuite/split_x86_64.sh: Likewise.
+ * testsuite/ver_test_pr16504.sh: Likewise.
+ intl/
+ * configure: Regenerate.
+ ld/
+ * testsuite/ld-elfvers/vers.exp (test_ar): Replace egrep with grep.
+
+2022-09-28 Alan Modra <amodra@gmail.com>
+
+ regen bfd/configure
+
+2022-09-28 Alan Modra <amodra@gmail.com>
+
+ asan: _bfd_stab_section_find_nearest_line segv
+ The segv was on "info->strs[strsize - 1] = 0;" with strsize zero. OK,
+ if strsize is zero we don't have any filenames in stabs so no useful
+ info.
+
+ * syms.c (_bfd_stab_section_find_nearest_line): Exit if either
+ stabsize or strsize is zero.
+
+2022-09-28 Alan Modra <amodra@gmail.com>
+
+ asan: segv in _bfd_archive_close_and_cleanup
+ Uninitialised arelt_data->parent_cache led to this segv.
+
+ * pdb.c (pdb_get_elt_at_index): Clear arelt_data.
+
+2022-09-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-27 Fangrui Song <maskray@google.com>
+
+ sim: Link ZSTD_LIBS
+ This fixes linker errors in a `../../configure --enable-targets
+ --enable-sim; make all-gdb` build.
+
+2022-09-27 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gold: Suppress "unused" variable warning on Clang
+ Clang generates a warning if there is a variable that is set but not used
+ otherwise ("-Wunused-but-set-variable"). On the default configuration, it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ Because the cause of this error is in the Bison-generated code
+ ($(srcdir)/gold/yyscript.y -> $(builddir)/gold/yyscript.c),
+ this commit suppresses this warning ("-Wunused-but-set-variable") by placing
+ DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro at the end of user
+ prologue on yyscript.y.
+
+ * yyscript.y: Suppress -Wunused-but-set-variable warning on
+ the Bison-generated code.
+
+2022-09-27 Fangrui Song <i@maskray.me>
+
+ libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true
+
+2022-09-27 Fangrui Song <maskray@google.com>
+
+ binutils, gdb: support zstd compressed debug sections
+ PR29397 PR29563: Add new configure option --with-zstd which defaults to
+ auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
+ zstd compressed debug sections for most tools.
+
+ * bfd: for addr2line, objdump --dwarf, gdb, etc
+ * gas: support --compress-debug-sections=zstd
+ * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
+ * objcopy: support ELFCOMPRESS_ZSTD input for
+ --decompress-debug-sections and --compress-debug-sections=zstd
+ * gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd
+ symbols, so gdb has to link against -lzstd in this patch.
+
+ If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We
+ can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
+ is too heavyweight, so don't do it for now.
+
+ ```
+ % ld/ld-new a.o
+ ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
+ ...
+
+ % ld/ld-new a.o --compress-debug-sections=zstd
+ ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
+
+ % binutils/objcopy --compress-debug-sections=zstd a.o b.o
+ binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support
+
+ % binutils/objcopy b.o --decompress-debug-sections
+ binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
+ ...
+ ```
+
+2022-09-27 Alan Modra <amodra@gmail.com>
+
+ PR29617, ld segfaults when bfd_close fails
+ PR 29617
+ * ldmain.c (main): Don't access output_bfd after bfd_close.
+
+2022-09-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: update field names in gdb-gdb.py.in
+ Patches that renamed the type::length and type::target_type fields
+ didn't update gdb-gdb.py.in accordingly, do that.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29599
+ Change-Id: I0f3f37a94d43497789156b0ded4d2f2dd5b89496
+
+2022-09-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp
+ If some command in there gives the wrong answer, we currently have to
+ wait for a timeout for the test to continue. For instance, I currently
+ see:
+
+ print *val->type
+ $1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.
+
+ (outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)
+
+ We can avoid this and modernize the test at the same time by using the
+ -prompt option of gdb_test.
+
+ gdb_test_no_output currently accepts a -prompt_re option (the variable
+ name passed to parse_args defines the option name), but I think
+ it's a typo. It's supposed to be -prompt, like gdb_test. I can't find
+ anything using -prompt_re using grep. Change it to just "prompt".
+
+ Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca
+
+2022-09-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: bump duration for the whole test in do_self_tests
+ When running gdb.gdb/python-helper.exp, I get some timeouts:
+
+ continue
+ Continuing.
+ print 1
+
+ FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout)
+
+ At this time, GDB is actually processing the stop and reading in some
+ CUs. selftest_setup does bump the timeout, but it's not for the whole
+ test.
+
+ Since debugging GDB with GDB is (unfortunately) a bit slow, bump the
+ timeout for the whole duration of the setup and body. On my optimized
+ build, the command takes just a bit more than the current timeout of 10
+ seconds. But it's much slower if running the test on an unoptimized
+ build, so I think it's necessary to bump the timeout for that in any
+ case.
+
+ Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d
+
+2022-09-26 Clément Chigot <chigot@adacore.com>
+
+ binutils/testsuite: handle the different install names of c++filt
+ c++filt is always named cxxfilt in a build directory, but in a install
+ directory it would be named either cxxfilt or c++filt (depending on
+ the host). Handle this last case in testsuite.
+
+ binutils/ChangeLog:
+ * testsuite/config/default.exp (CXXFILE): if cxxfilt not found,
+ try c++filt.
+
+2022-09-26 Clément Chigot <chigot@adacore.com>
+
+ binutils/testsuite: skip gentestdlls related tests if missing
+ When launching the testsuite through runtest outside the build tree,
+ gentestdlls might not be available, this binary being created by make
+ check.
+ Simply untested the related tests instead of crashing.
+
+ binutils/ChangeLog:
+
+ * testsuite/binutils-all/objdump.exp: Skip dotnet tests if
+ gentestdlls is not available.
+
+2022-09-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-unspecified-type-foo.c with -m32
+ When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board
+ unix/-m32, I run into:
+ ...
+ (gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo
+ p ((int (*) ()) foo) ()^M
+ $1 = -135698472^M
+ ...
+
+ Add the missing "return 0" in foo, which fixes this.
+
+ Tested on x86_64-linux.
+
+2022-09-26 Alan Modra <amodra@gmail.com>
+
+ PR29613, use of uninitialized value in objcopy
+ PR 29613
+ * elf.c (_bfd_elf_write_secondary_reloc_section): Trim sh_size
+ back to relocs written. Use better types for vars.
+
+2022-09-26 Alan Modra <amodra@gmail.com>
+
+ PR29542, PowerPC gold internal error in get_output_view,
+ We were attempting to set a BSS style section contents.
+
+ PR 29542
+ * powerpc.cc (Output_data_plt_powerpc::do_write): Don't set .plt,
+ .iplt or .lplt section contents when position independent.
+
+2022-09-26 Alan Modra <amodra@gmail.com>
+
+ stab nearest_line bfd_malloc_and_get_section
+ bfd_malloc_and_get_section performs some sanity checks on the section
+ size before allocating memory. This patch avails the stab
+ nearest_line code of that sanity checking, and tidies up memory
+ afterward.
+
+ * coffgen.c (_bfd_coff_close_and_cleanup): Call _bfd_stab_cleanup.
+ * elf.c (_bfd_elf_close_and_cleanup): Likewise.
+ * syms.c (_bfd_stab_section_find_nearest_line): Set *pinfo earlier.
+ Use bfd_malloc_and_get_section. Free malloc'd buffers on failure.
+ Malloc indextable.
+ (_bfd_stab_cleanup): New function.
+ * libbfd-in.h (_bfd_stab_cleanup): Declare.
+ * libbfd.h: Regnerate.
+
+2022-09-26 Alan Modra <amodra@gmail.com>
+
+ PKG_CHECK_MODULES for msgpack and jansson
+ Using AS_IF rather than shell "if" is recommended for conditionals
+ that contain non-trivial autoconf macros, because autoconf will emit
+ any AC_REQUIREd autoconf macro expansions outside of the conditional.
+ This makes them available elsewhere in the configure script.
+
+ binutils/
+ * configure.ac (msgpack): Use "AS_IF" rather than "if".
+ * configure: Regenerate.
+ ld/
+ * configure.ac (jansson): Use "AS_IF" rather than "if".
+ * configure: Regenerate.
+
+2022-09-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-24 Magne Hov <mhov@undo.io>
+
+ gdb/source.c: Fix undefined behaviour dereferencing empty string
+ When a source file's dirname is solely made up of directory separators
+ we end up trying to dereference the last character of an empty string
+ with std::string::back, which results in undefined behaviour. A typical
+ use case where this can happen is when the root directory "/" is used as
+ a compilation directory.
+
+ With libstdc++.so.6.0.28 we get no out-of-bounds checks and the byte
+ preceding the storage of the empty string is returned. The character
+ value of this byte depends on heap implementation and usage, but when
+ this byte happens to hold the value of the directory separator character
+ we go on to call std::string::pop_back on the empty string which results
+ in an out_of_range exception which terminates GDB.
+
+ Fix this by using path_join. prepare_path_for_appending ensures that the
+ filename component is relative.
+
+ The testsuite has been run before and after the change and no
+ regressions were found.
+
+2022-09-24 Enze Li <enze.li@hotmail.com>
+
+ gdbserver: remove unused for loop
+ In this commit,
+
+ commit cf6c1e710ee162a5adb0ae47acb731f2bfecc956
+ Date: Mon Jul 11 20:53:48 2022 +0800
+
+ gdbserver: remove unused variable
+
+ I removed an unused variable in handle_v_run. Pedro then pointed out
+ that the for loop after it was also unused. After a period of smoke
+ testing, no exceptions were found.
+
+ Tested on x86_64-linux.
+
+2022-09-24 Alan Modra <amodra@gmail.com>
+
+ The problem with warning in elf_object_p
+ elfcode.h can emit three warnings in elf_object_p for various things,
+ "section extending past end of file", "corrupt string table index",
+ and "program header with invalid alignment". The problem with doing
+ this is that the warning can be emitted for multiple possible targets
+ as each one is tried. I was looking at a fuzzer testcase that had an
+ object file with 6144 program headers, 5316 of which had invalid
+ alignment. It would be bad enough to get 5316 messages all the same,
+ but this object was contained in an archive and resulted in 4975776
+ repeats.
+
+ Some trimming can be done by not warning if the bfd is already marked
+ read_only, as is done for the "section extending past end of file"
+ warning, but that still results in an unacceptable number of
+ warnings for object files in archives. Besides that, it is just wrong
+ to warn about a problem detected by a target elf_object_p other than
+ the one that actually matches. At some point we might have more
+ target specific warnings.
+
+ So what to do? One obvious solution is to remove the warnings.
+ Another is to poke any warning strings into the target xvec, emitting
+ them if that xvec is the final one chosen. This also has the benefit
+ of solving the archive problem. A warning when recursing into
+ _bfd_check_format for the first element of the archive (to find the
+ correct target for the archive) will still be on the xvec at the point
+ that target is chosen for the archive. However, target xvecs are
+ read-only. Thus the need for per_xvec_warn to logically extend
+ bfd_target with a writable field. I've made per_xvec_warn one larger
+ than bfd_target_vector to provide one place for user code that makes
+ private copies of target xvecs.
+
+ * elfcode.h (elf_swap_shdr_in, elf_object_p): Stash potential
+ warnings in _bfd_per_xvec_warn location.
+ * format.c (clear_warnmsg): New function.
+ (bfd_check_format_matches): Call clear_warnmsg before trying
+ a new xvec. Print warnings for the successful non-archive
+ match.
+ * targets.c: Include libiberty.h.
+ (_bfd_target_vector_entries): Use ARRAY_SIZE.
+ (per_xvec_warn): New.
+ (_bfd_per_xvec_warn): New function.
+ * Makefile.am (LIBBFD_H_FILES): Add targets.c.
+ * Makefile.in: Regenerate.
+ * libbfd.h: Regenerate.
+
+2022-09-24 Alan Modra <amodra@gmail.com>
+
+ Re: bfd_cleanup for object_p
+ Bits still missing from commit cb001c0d283d.
+
+ * aoutx.h (aout_@var{size}_some_aout_object_p): Correct synopsis.
+ * i386lynx.c (lynx_core_file_p): Correct return type.
+ * ptrace-core.c (ptrace_unix_core_file_p): Likewise.
+
+2022-09-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-23 John Baldwin <jhb@FreeBSD.org>
+
+ Support AT_USRSTACKBASE and AT_USRSTACKLIM.
+ FreeBSD's kernel has recently added two new ELF auxiliary vector
+ entries to describe the location of the user stack for the initial
+ thread in a process.
+
+ This change displays the proper name and description of these entries
+ in 'info auxv'.
+
+2022-09-23 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add Zawrs ISA extension support
+ This patch adds support for the Zawrs ISA extension
+ ("wrs.nto" and "wrs.sto" instructions).
+
+ The specification can be found here:
+ https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
+
+2022-09-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/tui: start GDB with "set filename-display basename"
+ The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
+ concluded that it is caused by the long source directory name:
+
+ /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb
+
+ The long name causes some particular redrawing that doesn't happen for
+ shorter directories, and causes a Term::command call to return too
+ early.
+
+ This can be reproduced by cloning the binutils-gdb repo in a directory
+ with a name similar to the one shown above.
+
+ $ pwd
+ /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
+ $ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
+ FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
+ FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
+ FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
+ FAIL: gdb.tui/tui-missing-src.exp: Back in main
+
+ Note that using "make check" instead of "make check-read1" only shows
+ the last 2 failures for me.
+
+ When running gdb.tui/tui-missing-src.exp in a directory with a shorter
+ name, the terminal looks like this by the time the "checking if inside
+ f2" test runs:
+
+ Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
+ 0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
+ 1 | 1 |
+ 2 | 2 int |
+ 3 | 3 f2 (int x) |
+ 4 | 4 { |
+ 5 | > 5 x <<= 1; |
+ 6 | 6 return x+5; |
+ 7 | 7 } |
+ 8 | 8 |
+ 9 | 9 |
+ 10 | 10 |
+ 11 | 11 |
+ 12 | 12 |
+ 13 | 13 |
+ 14 +------------------------------------------------------------------------------+
+ 15 multi-thre Thread 0x7ffff7cc07 In: f2 L5 PC: 0x555555555143
+ 16 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
+ 17 missing-src/main.c:6
+ 18 (gdb) next
+ 19 (gdb) step
+ 20 f2 (x=4)
+ 21 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
+ 22 missing-src/f2.c:5
+ 23 (gdb)
+ PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
+
+ When running the `Term::command "step"` just before, GDB writes the
+ "step", which makes the `wait_for` proc go in the "looking for the
+ prompt" mode, to know when the command's execution is complete. As some
+ new output appears, lines that must disappear are deleted using the
+ "Delete Line" operation [1] and some new ones are drawn. The source
+ window gets redrawn with the contents of the f2.c file. Then, GDB
+ writes the prompt (at line 23 above), which satisfies `wait_for`, which
+ then returns. The state of the terminal is therefore correct for the
+ "check if inside f2" and "f2.c must be displayed in the source window"
+ tests.
+
+ In the non-working case, the terminal looks like this by the time the
+ "check if inside f2" test runs:
+
+ Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
+ 0 +------------------------------------------------------------------------------+
+ 1 | |
+ 2 | |
+ 3 | |
+ 4 | |
+ 5 | |
+ 6 | |
+ 7 | [ No Source Available ] |
+ 8 | |
+ 9 | |
+ 10 | |
+ 11 | |
+ 12 | |
+ 13 | |
+ 14 +------------------------------------------------------------------------------+
+ 15 multi-thre Thread 0x7ffff7cc1b In: main L7 PC: 0x555555555128
+ 16 sing-src/main.c:6
+ 17 (gdb) ary breakpoint 1, main ()
+ 18 at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
+ 19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
+ 20 sing-src/main.c:6
+ 21 (gdb) next
+ 22 (gdb) step
+ 23
+ FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
+
+ What happened is: GDB wrote the "step" command, which make the
+ `wait_for` proc go in its "looking for the prompt" mode. However,
+ curses decided to redraw whatever scrolled up to line 17 using some
+ standard character insertion operations:
+
+ +++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
+ +++ Inserting string '('
+ +++ Inserted char '(', cursor: (17, 0) -> (17, 1)
+ +++ Inserted string '(', cursor: (17, 0) -> (17, 1)
+ +++ Inserting string 'g'
+ +++ Inserted char 'g', cursor: (17, 1) -> (17, 2)
+ +++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
+ +++ Inserting string 'd'
+ +++ Inserted char 'd', cursor: (17, 2) -> (17, 3)
+ +++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
+ +++ Inserting string 'b'
+ +++ Inserted char 'b', cursor: (17, 3) -> (17, 4)
+ +++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
+ +++ Inserting string ')'
+ +++ Inserted char ')', cursor: (17, 4) -> (17, 5)
+ +++ Inserted string ')', cursor: (17, 4) -> (17, 5)
+ +++ Inserting string ' '
+ +++ Inserted char ' ', cursor: (17, 5) -> (17, 6)
+ +++ Inserted string ' ', cursor: (17, 5) -> (17, 6)
+
+ And that causes `wait_for` to think the "step" command is complete.
+ This is wrong, as the prompt at line 17 isn't the prompt drawn after the
+ completion of the "step" command. The subsequent tests now run with a
+ partially updated screen (what is shown above) and obviously fail.
+
+ The ideal way to fix this would be for `wait_for` to be smarter, to
+ avoid it confusing the different prompts drawn.
+
+ However, I would also like to reduce the variations in TUI test results
+ due to the directories (source and build) in which tests are ran. TUI
+ tests are more prone to differences in test results due to variations in
+ directory names than other tests, as it makes curses take different
+ redrawing decisions. So in this patch, I propose to make TUI tests use
+ "set filename-display basename", which makes GDB omit directory names
+ when it prints file names. This way, regardless of where you run the
+ tests, you should get the same results (all other things being equal).
+
+ Doing this happens to fix my failures and makes my CI happy (which in
+ turns makes me happy). To be clear, I understand that this does not fix
+ the root issue of `proc wait_for` being confused. However, it makes TUI
+ test runs be more similar for everyone, such that there's less chance of
+ TUI tests randomly failing for somebody. If some other change triggers
+ the `wait_for` problem again in the future, hopefully everybody will see
+ the problem and we can work on getting it fixed more easily than if just
+ one unlucky person sees the problem.
+
+ Note that there are other reasons why TUI tests could vary, like
+ different curses library versions taking different re-drawing decisions.
+ However, I think my change is a good step towards more stable test
+ results.
+
+ [1] https://vt100.net/docs/vt510-rm/DL.html
+
+ Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5
+
+2022-09-23 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky add cskyv2-linux.xml for cskyv2-linux.c
+ Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed.
+ Also update cskyv2-linux.c.
+
+2022-09-23 Alan Modra <amodra@gmail.com>
+
+ pdb: _bfd_generic_close_and_cleanup
+ Every format that might appear inside a generic archive needs to call
+ _bfd_generic_close_and_cleanup, so that the archive element lookup
+ htab can be tidied on closing an element. Otherwise you get stale
+ entries in the htab pointing at freed and perhaps reused memory,
+ resulting in segfaults when the archive is closed.
+
+ Calling _bfd_generic_close_and_cleanup on close means tdata needs to
+ be set up too, since pdb claims to be of format bfd_archive.
+
+ * pdb.c (pdb_close_and_cleanup): Define as
+ _bfd_generic_close_and_cleanup.
+ (pdb_archive_p): Set up tdata for bfd_archive format.
+
+2022-09-23 Alan Modra <amodra@gmail.com>
+
+ Don't attempt to compress bss sections
+ It doesn't make sense to try to compress a section without contents
+ since those sections take no space on disk. Compression can only
+ increase the disk image size.
+
+ * coffgen.c (make_a_section_from_file): Exclude !SEC_HAS_CONTENTS
+ sections from compression and decompression.
+ * elf.c (_bfd_elf_make_section_from_shdr): Likewise.
+
+2022-09-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-22 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite/lib/future.exp: follow dejagnu default_target_compile
+ GDB's testsuite can override dejagnu's default_target_compile if the
+ system provided dejagnu installation does not provide support to compile
+ languages GDB needs.
+
+ Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
+ "Establish a default C compiler by evaluating [find_gcc] if no other
+ compiler is given."[1]. This commit removed calls such as
+ `set_board_info compiler "[find_gcc]"` from the various baseboards
+ and has default_target_compile call `find_gcc` itself to find a compiler
+ if none was specified by the board description.
+
+ On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
+ languages still unknown to dejagnu, we end up in the following
+ situation:
+ - The system board files do not set the C compiler anymore,
+ - GDB's replacement for default_target_compile assumes that the
+ compiler should have been set up by the board file.
+
+ In this situation, no one sets the C compiler for the board and as a
+ result many test are not compiled and not executed:
+
+ [...]
+ Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
+ gdb compile failed, default_target_compile: No compiler to compile with
+ Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
+ gdb compile failed, default_target_compile: No compiler to compile with
+ Running .../gdb/testsuite/gdb.base/structs3.exp ...
+ gdb compile failed, default_target_compile: No compiler to compile with
+ [...]
+
+ We are observing this error with ROCgdb[2], a downstream port of GDB
+ supporting AMD GPUs. This port needs to use GDB's override of
+ default_target_compile to compile HIP programs since dejagnu does not
+ provide support for this language yet.
+
+ This patch changes gdb_default_target_compile_1 in a similar way
+ default_target_compile has been updated so both implementations remain
+ compatible. Even if this is not strictly required by GDB just yet,
+ I believe keeping both implementations in sync desirable.
+
+ Using board files provided with dejagnu <=1.6.2 is still supported: if
+ the compiler is set by the board file, gdb_default_target_compile_1 uses
+ it and does not need `find_gcc`.
+
+ Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.
+
+ [1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
+ [2] https://github.com/ROCm-Developer-Tools/ROCgdb
+
+ Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head MemPair vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadMemPair extension, a collection of T-Head specific
+ two-GP-register memory operations.
+ The 'th' prefix and the "XTheadMemPair" extension are documented in a PR
+ for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for literal instruction arguments
+ This patch introduces support for arbitrary literal instruction
+ arguments, that are not encoded in the opcode.
+
+ A typical use case for this feature would be an instruction that
+ applies an implicit shift by a constant value on an immediate
+ (that is a real operand). With this patch it is possible to make
+ this shift visible in the dissasembly and support such artificial
+ parameter as part of the asssembly code.
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head MemIdx vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadMemIdx extension, a collection of T-Head specific
+ GPR memory access instructions.
+ The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR
+ for the RISC-V toolchain conventions ([1]).
+
+ In total XTheadCmo introduces the following 44 instructions
+ (BU,HU,WU only for loads (zero-extend instead of sign-extend)):
+
+ * {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2
+ * {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2
+ * {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head FMemIdx vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadFMemIdx extension, a collection of
+ T-Head-specific floating-point memory access instructions.
+ The 'th' prefix and the "XTheadFMemIdx" extension are documented
+ in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head MAC vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadMac extension, a collection of
+ T-Head-specific multiply-accumulate instructions.
+ The 'th' prefix and the "XTheadMac" extension are documented
+ in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head CondMov vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadCondMov extension, a collection of
+ T-Head-specific conditional move instructions.
+ The 'th' prefix and the "XTheadCondMov" extension are documented
+ in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head Bitmanip vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of
+ T-Head-specific bitmanipulation instructions.
+ The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented
+ in a PR for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add support for arbitrary immediate encoding formats
+ This patch introduces support for arbitrary signed or unsigned immediate
+ encoding formats. The formats have the form "XsN@S" and "XuN@S" with N
+ being the number of bits and S the LSB position.
+
+ For example an immediate field of 5 bytes that encodes a signed value
+ and is stored in the bits 24-20 of the instruction word can use the
+ format specifier "Xs5@20".
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head SYNC vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadSync extension, a collection of
+ T-Head-specific multi-processor synchronization instructions.
+ The 'th' prefix and the "XTheadSync" extension are documented in a PR
+ for the RISC-V toolchain conventions ([1]).
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add T-Head CMO vendor extension
+ T-Head has a range of vendor-specific instructions.
+ Therefore it makes sense to group them into smaller chunks
+ in form of vendor extensions.
+
+ This patch adds the XTheadCmo extension, a collection of T-Head specific
+ cache management operations.
+ The 'th' prefix and the "XTheadCmo" extension are documented in a PR
+ for the RISC-V toolchain conventions ([1]).
+
+ In total XTheadCmo introduces the following 21 instructions:
+
+ * DCACHE.{C,CI,I}ALL
+ * DCACHE.{C,CI,I}{PA,VA,SW} rs1
+ * DCACHE.C{PAL1,VAL1} rs1
+ * ICACHE.I{ALL,ALLS}
+ * ICACHE.I{PA,VA} rs1
+ * L2CACHE.{C,CI,I}ALL
+
+ Contrary to Zicbom, the XTheadCmo instructions don't have a constant
+ displacement, therefore we have a different syntax for the arguments.
+ To clarify this is intended behaviour, there is a set of negative test
+ for Zicbom-style arguments in x-thead-cmo-fail.s.
+
+ [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
+
+ v2:
+ - Add missing DECLARE_INSN() list
+ - Fix ordering
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Christoph Müllner <christoph.muellner@vrull.eu>
+
+ RISC-V: Add generic support for vendor extensions
+ This patch introduces changes that allow the integration of vendor ISA
+ extensions:
+ * Define a list of vendor extensions (riscv_supported_vendor_x_ext)
+ where vendor extensions can be added
+ * Introduce a section with a table in the documentation where vendor
+ extensions can be added
+
+ To add a vendor extension that consists of instructions only,
+ the following things need to be done:
+ * Add the extension to the riscv_supported_vendor_x_ext list
+ * Add lookup entry in riscv_multi_subset_supports
+ * Documenting the extension in c-riscv.texti
+ * Add test cases for all instructions
+ * Add MATCH*/MASK* constants and DECLARE_INSN() for all instructions
+ * Add new instruction class to enum riscv_insn_class
+ * Define the instructions in riscv_opcodes
+ * Additional changes if necessary (depending on the instructions)
+
+ Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
+
+2022-09-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add all_comp_units/all_type_units views on all_units
+ Add all_comp_units/all_type_units views on all_units.
+
+ Having the views allows us to:
+ - easily get the number of CUs or TUs in all_units, and
+ - easily access the nth CU or TU.
+
+ This minimizes the use of tu_stats.nr_tus.
+
+ Tested on x86_64-linux.
+
+2022-09-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Rename all_comp_units to all_units
+ Mechanically rename all_comp_units to all_units:
+ ...
+ $ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/*
+ ...
+
+ Tested on x86_64-linux.
+
+2022-09-22 Yoshinori Sato <ysato@users.sourceforge.jp>
+
+ opcodes: SH fix bank register disassemble.
+ * sh-dis.c (print_insn_sh): Enforce bit7 of LDC Rm,Rn_BANK and STC
+ Rm_BANK,Rn is always 1.
+
+2022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ include: Add macro to ignore -Wunused-but-set-variable
+ "-Wunused-but-set-variable" warning option can be helpful to track variables
+ that are written but not read thereafter. But it can be harmful if some of
+ the code is auto-generated and we have no ways to deal with it.
+
+ The particular example is Bison-generated code.
+
+ The new DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro can be helpful on
+ such cases. A typical use of this macro is to place this macro before the
+ end of user prologues on Bison (.y) files.
+
+ include/ChangeLog:
+
+ * diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE): New.
+
+2022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ include: Add macro to ignore -Wuser-defined-warnings
+ User-defined warnings (on Clang, "-Wuser-defined-warnings") can be harmful
+ if we have specified "-Werror" and we have no control to disable the warning
+ ourself. The particular example is Gnulib.
+
+ Gnulib generates a warning if the system version of certain functions
+ are used (to redirect the developer to use Gnulib version). However,
+ it can be harmful if we cannot easily replace them (e.g. the target is in
+ the standard C++ library).
+
+ The new DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS macro can be helpful on such
+ cases. A typical use of this macro is to place this macro before including
+ certain system headers.
+
+ include/ChangeLog:
+
+ * diagnostics.h (DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS): New.
+
+2022-09-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: restrict the names accepted by gdb.register_window_type
+ I noticed that, from Python, I could register a new TUI window that
+ had whitespace in its name, like this:
+
+ gdb.register_window_type('my window', MyWindowType)
+
+ however, it is not possible to then use this window in a new TUI
+ layout, e.g.:
+
+ (gdb) tui new-layout foo my window 1 cmd 1
+ Unknown window "my"
+ (gdb) tui new-layout foo "my window" 1 cmd 1
+ Unknown window ""my"
+ (gdb) tui new-layout foo my\ window 1 cmd 1
+ Unknown window "my\"
+
+ GDB clearly uses the whitespace to split the incoming command line.
+
+ I could fix this by trying to add a mechanism by which we can use
+ whitespace within a window name, but it seems like an easier solution
+ if we just forbid whitespace within a window name. Not only is this
+ easier, but I think this is probably the better solution, identifier
+ names with spaces in would mean we'd need to audit all the places a
+ window name could be printed and ensure that the use of a space didn't
+ make the output ambiguous.
+
+ So, having decided to disallow whitespace, I then thought about other
+ special characters. We currently accept anything as a window name,
+ and I wondered if this was a good idea.
+
+ My concerns were about how special characters used in a window name
+ might cause confusion, for example, we allow '$' in window names,
+ which is maybe fine now, but what if one day we wanted to allow
+ variable expansion when creating new layouts? Or what about starting
+ a window name with '-'? We already support a '-horizontal' option,
+ what if we want to add more in the future? Or use of the special
+ character '{' which has special meaning within a new layout?
+
+ In the end I figured it might make sense to place some restrictive
+ rules in place, and then relax the rules later if/when users complain,
+ we can consider each relaxation as its requested.
+
+ So, I propose that window names should match this regular expression:
+
+ [a-zA-Z][-_.a-zA-Z0-9]*
+
+ There is a chance that there is user code in the wild which will break
+ with the addition of this change, but hopefully adapting to the new
+ restrictions shouldn't be too difficult.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Add test to step through function epilogue
+ The testsuite implicitly tests GDB's ability to step through epilogues
+ in multiple tests, without doing it explicitly anywhere. This is
+ unfortunate, as clang does not emit epilogue information, so using clang
+ on our testsuite makes many tests fail. This patch adds a central,
+ explicit test for walking through the epilogue so we can safely remove
+ this from other tests and have them working with clang.
+
+ The test created attempts to step through a simple epilogue, an
+ epilogue that ends on another epilogue, and epilogues leading to other
+ function calls.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb.base/skip.exp: Use finish to exit functions
+ gdb.base/skip.exp was making use of a fixed number of step commands to
+ exit some functions. This caused some problems when using clang to test
+ GDB, as GDB would need fewer steps to reach the desired spots. For
+ instance, when testing in the section "step after disabling 3", the log
+ looks like this:
+
+ Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
+ 32 x = baz ((bar (), foo ()));
+ (gdb) step
+ bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
+ 21 return 1;
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
+ step
+ foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
+ 42 return 0;
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
+ step
+ main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
+ 34 test_skip_file_and_function ();
+ (gdb) step
+ test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
+ 59 test_skip ();
+ (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
+ step
+ test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
+ 48 }
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
+ step
+ test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
+ 60 skip1_test_skip_file_and_function ();
+ (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5
+
+ This shows that the feature is working but because the inferior lands in
+ a different location, it registers as a failure. Seeing as along with
+ this difference, there are also some differences that depend on gcc
+ versions (where gdb might stop back at line 32 before entering foo), it
+ would not be easy to test for this behavior using steps and analzing
+ where the inferior stops at each point. On the other hand, using
+ gdb_step_until is not feasible because we'd possibly gloss over stepping
+ into baz and rendering the whole test useless. Instead, skip.exp now
+ uses finish to leave functions, synchronizing through compilers and
+ compiler versions. Some test names were also changed to be a bit more
+ descriptive. The new log looks like this, independently of compiler used:
+
+ Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
+ 32 x = baz ((bar (), foo ()));
+ (gdb) step
+ bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
+ 21 return 1;
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
+ finish
+ Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
+ main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
+ 32 x = baz ((bar (), foo ()));
+ Value returned is $2 = 1
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
+ step
+ foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
+ 42 return 0;
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
+ finish
+ Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
+ main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
+ 32 x = baz ((bar (), foo ()));
+ Value returned is $3 = 0
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
+ step
+ 34 test_skip_file_and_function ();
+ (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ fix gdb.base/jit-elf.exp when testing with clang
+ When using clang as the compiler for the target, gdb.base/jit-elf.exp
+ was failing because the filename displayed when GDB attached to the
+ inferior was only showing up as with a relative path, like so:
+
+ (gdb) attach 3674146
+ Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
+ Reading symbols from /lib64/libm.so.6...
+ Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
+ (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
+ 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...
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib64/libthread_db.so.1".
+ 0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
+ 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
+ (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
+
+ While gcc's output is as follows:
+
+ (gdb) attach 3592961
+ Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
+ Reading symbols from /lib64/libm.so.6...
+ Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
+ (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
+ 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...
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib64/libthread_db.so.1".
+ main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
+ 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
+ (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
+
+ This difference only happens when GDB's configure is ran using a
+ relative path, but seeing as testing the full path is not important for
+ this specific test, it feels worth fixing anyway. To fix the false
+ positive, the regexp for checking where gdb has stopped was relaxed a
+ little to allow the relative path.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
+ When trying to test gdb.base/msym-bp-shl.exp using clang, it would have
+ many failures because one of the version of the foo function was being
+ optimized away. Adding __attribute__ ((used)) to it fixed this.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix testing gdb.base/skip-inline.exp with clang
+ When testing gdb.base/skip-inline.exp using clang, we get failures
+ when trying to step out of functions, since clang requires one fewer
+ step when compared to gcc. The inferior gets increasingly out of sync
+ as the test continues because of this difference, which generates those
+ failures.
+
+ This commit fixes this by switching those hardcoded steps to
+ gdb_step_until, to guarantee that the inferior is always synced to what
+ the test expects. This approach does not work for the parts that use
+ step 2 or step 3, so when we identify that clang is being used, those
+ tests are skipped.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ Change gdb.base/skip-solib.exp deal with lack of epilogue information
+ When running gdb.base/skip-solib.exp, the backtrace tests could fail with
+ compilers that associated epilogue instructions with the last statement
+ line of the function, instead of associating it with the closing brace,
+ despite the feature being fully functional. As an example, when testing
+ skipping the function square, the testsuite would show
+
+ Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
+ 5 return square(0);
+ (gdb) step
+ 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
+ (gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
+ bt
+ #0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
+ #1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
+ #2 0x0000000000401065 in _start ()
+ (gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt
+
+ Which means that the feature is working, the testsuite is just
+ mis-identifying it. To avoid this problem, the skipped function calls
+ have been sent to a line before `return`, so epilogues won't factor in.
+
+2022-09-22 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Add a proc to test where compiler links the epilogue
+ Different compilers link the epilogue of functions to different lines.
+ As an example, gcc links it to the closing brace of the function,
+ whereas clang links it to the last statement of the function. This
+ difference is important for the testsuite, since the where GDB will land
+ after a step can be wildly different. Where possible, this dependency
+ should be side-stepped in the testsuite, but it isn't always possible,
+ so this commit adds a gdb_caching_proc that is able to detect where the
+ epilogue is linked, so tests can react accordingly.
+
+2022-09-22 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: allow to force another directory for gcc linker
+ Add a new variable "ld_testsuite_tmpdir" to enable manual configuration
+ of the -B flag added to gcc calls. This flag ensure that gcc is invoking
+ the linker and the assembler we want to test.
+
+ When launching the testsuite outside of the build tree, the links made
+ by the testsuite in tmpdir/ld will point to nothing. Thus, even with the
+ PATH correctly setup towards the linker directory, gcc might end up
+ falling back to its default linker. Hence this variable to ensure that
+ gcc, whatever happens, is using the linker we want.
+
+ ld/ChangeLog:
+
+ * testsuite/config/default.exp: Allow to change -B flag with
+ ld_testsuite_bindir variable.
+
+2022-09-22 Clément Chigot <chigot@adacore.com>
+
+ ld/testsuite: skip bootstrap.exp when OFILES are missing
+ OFILES are normally provided through an environment variable set by
+ Makefiles. However, when launching the testsuite directly through
+ runtest outside the build tree, it can be hard to retrieve them.
+ Thus, they can be missing.
+ Instead of letting tcl raise an error when trying to access this
+ OFILES variable, skip bootstrap.exp if it doesn't exist.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-bootstrap/bootstrap.exp: Skip if OFILES is
+ missing
+
+2022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove "b" operand type from disassembler
+ There are a few operand types not used by any RISC-V instructions.
+
+ - Cx
+ - Vf
+ - Ve
+ - [
+ - ]
+ - b
+
+ But most of them has a reasoning to keep them:
+
+ - Cx : Same as "Ct" except it has a constraint to have rd == rs2
+ (similar to "Cw"). Although it hasn't used, its role is clear
+ enough to implement a new instruction with this operand type.
+ - Vf, Ve : Used by vector AMO instructions (not ratified and real
+ instructions are not upstreamed yet).
+ - [, ] : Unused tokenization symbols. Reserving them is not harmful
+ and a vendor may use this symbol for special purposes.
+
+ ... except "b". I could not have found any reference to this operand type
+ except it works like the "s" operand type. Historically, it seems... it's
+ just unused from the beginning. Its role is not clear either.
+
+ On such cases, we should vacate this room for the new operand type with
+ much clearer roles.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Remove 'b' operand type.
+
+2022-09-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add macro-only operands to validate_riscv_insn
+ Although they are not (and should not be) reachable, following macro-only
+ operands are parsed in the `validate_riscv_insn' function and ignored.
+ That function also notes that they are macro-only.
+
+ - "A"
+ - "B"
+ - "I"
+
+ Following this convention, this commit adds three remaining macro-only
+ operands to this function. By doing this, we could instead choose to reject
+ those operands from appearing in regular instructions later.
+
+ - "c" (used by call, tail and jump macros)
+ - "VM" (used by vmsge.vx and vmsgeu.vx macros)
+ - "VT" (likewise)
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (validate_riscv_insn): Add "c", "VM" and "VT"
+ macro-only operand types.
+
+2022-09-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix -Wduplicated-cond warning
+ gprofng/ChangeLog
+ 2022-09-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/collctrl.cc: Fix -Wduplicated-cond warning.
+
+2022-09-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ bfd BLD-POTFILES.in dependencies
+ A file that consists of a list of files doesn't depend on those files
+ being built. This patch came from trying to avoid a maintainer-mode
+ make -j bug, where the recipe for targmatch.h was being run twice in
+ parallel. Typical output shown below.
+
+ make[2]: Entering directory '/build/gas/all/bfd'
+ GEN bfdver.h
+ GEN elf32-target.h
+ GEN elf64-target.h
+ GEN targmatch.h
+ Making info in po
+ make[3]: Entering directory '/build/gas/all/bfd/po'
+ cd .. && make po/SRC-POTFILES.in
+ cd .. && make po/BLD-POTFILES.in
+ make[4]: Entering directory '/build/gas/all/bfd'
+ GEN elf32-aarch64.c
+ GEN elf64-aarch64.c
+ GEN elf32-ia64.c
+ GEN elf64-ia64.c
+ GEN elf32-loongarch.c
+ GEN elf64-loongarch.c
+ GEN elf32-riscv.c
+ GEN elf64-riscv.c
+ GEN peigen.c
+ GEN pepigen.c
+ GEN pex64igen.c
+ GEN pe-aarch64igen.c
+ GEN targmatch.h
+ make[4]: Entering directory '/build/gas/all/bfd'
+ CCLD doc/chew.stamp
+ mv: cannot stat 'targmatch.new': No such file or directory
+ make[4]: *** [Makefile:2325: targmatch.h] Error 1
+
+ * Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES).
+ (po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).
+
+2022-09-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and rename
+ gdb_bfd.c and remote.c contain identical implementations of a
+ fileio_error -> errno function. Factor that out to
+ gdbsupport/fileio.{h,cc}.
+
+ Rename it fileio_error_to_host, for symmetry with host_to_fileio_error.
+
+ Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df
+
+2022-09-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: convert FILEIO_* macros to an enum
+ Converting from free-form macros to an enum gives a bit of type-safety.
+ This caught places where we would assign host error numbers to what
+ should contain a target fileio error number, for instance in
+ target_fileio_pread.
+
+ I added the FILEIO_SUCCESS enumerator, because
+ remote.c:remote_hostio_parse_result initializes the remote_errno output
+ variable to 0. It seems better to have an explicit enumerator than to
+ assign a value for which there is no enumerator. I considered
+ initializing this variable to FILEIO_EUNKNOWN instead, such that if the
+ remote side replies with an error and omits the errno value, we'll get
+ an errno that represents an error instead of 0 (which reprensents no
+ error). But it's not clear what the consequences of that change would
+ be, so I prefer to err on the side of caution and just keep the existing
+ behavior (there is no intended change in behavior with this patch).
+
+ Note that remote_hostio_parse_resul still reads blindly what the remote
+ side sends as a target errno into this variable, so we can still end up
+ with a nonsensical value here. It's not good, but out of the scope of
+ this patch.
+
+ Convert host_to_fileio_error and fileio_errno_to_host to return / accept
+ a fileio_error instead of an int, and cascade the change in the whole
+ chain that uses that.
+
+ Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03
+
+2022-09-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: move include/gdb/fileio.h contents to fileio.h
+ I don't see why include/gdb/fileio.h is placed there. It's not
+ installed by "make install", and it's not included by anything outside
+ of gdb/gdbserver/gdbsupport.
+
+ Move its content back to gdbsupport/fileio.h. I have omitted the bits
+ inside an `#if 0`, since it's obviously not used, as well as the
+ "limits" constants, which are also unused.
+
+ Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
+
+2022-09-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: change path_join parameter to array_view<const char *>
+ When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single
+ character name, we hit this assertion failure:
+
+ $ ./gdb -q --data-directory=data-directory -nx ./x
+ /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
+
+ The backtrace:
+
+ #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60
+ #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239
+ #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203
+ #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84
+ #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122
+ #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471
+ #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513
+ #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209
+ #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319
+ #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344
+ #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
+
+ The problem is this line in path_join:
+
+ gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path));
+
+ ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls
+ HAS_DRIVE_SPEC_1:
+
+ #define HAS_DRIVE_SPEC_1(dos_based, f) \
+ ((f)[0] && ((f)[1] == ':') && (dos_based))
+
+ This macro accesses indices 0 and 1 of the input string. However, `f`
+ is a string_view of length 1, so it's incorrect to try to access index
+ 1. We know that the string_view's underlying object is a null-terminated
+ string, so in practice there's no harm. But as far as the string_view
+ is concerned, index 1 is considered out of bounds.
+
+ This patch makes the easy fix, that is to change the path_join parameter
+ from a vector of to a vector of `const char *`. Another solution would
+ be to introduce a non-standard gdb::cstring_view class, which would be a
+ view over a null-terminated string. With that class, it would be
+ correct to access index 1, it would yield the NUL character. If there
+ is interest in having this class (it has been mentioned a few times in
+ the past) I can do it and use it here.
+
+ This was found by running tests such as gdb.ada/arrayidx.exp, which
+ produce 1-char long filenames, so adding a new test is not necessary.
+
+ Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
+
+2022-09-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_LENGTH
+ Remove the macro, replace all uses with calls to type::length.
+
+ Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
+
+2022-09-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add type::length / type::set_length
+ Add the `length` and `set_length` methods on `struct type`, in order to remove
+ the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
+ getter, so all the call sites of the macro that are used as a setter are
+ changed to use the setter method directly. The next patch will remove the
+ macro completely.
+
+ Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
+
+2022-09-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_TARGET_TYPE
+ Remove the macro, replace all uses by calls to type::target_type.
+
+ Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
+
+2022-09-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add type::target_type / type::set_target_type
+ Add the `target_type` and `set_target_type` methods on `struct type`, in order
+ to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to
+ use the getter, so all the call sites of the macro that are used as a setter
+ are changed to use the setter method directly. The next patch will remove the
+ macro completely.
+
+ Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
+
+2022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix riscv_set_tso declaration
+ To avoid -Werror=strict-prototypes, this commit changes () to (void).
+ This is because "()" possibly means a function prototype with indeterminate
+ arguments on old C standards.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_set_tso): Fix declaration.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ PR29566, objdump -p considers an empty .gnu.version_r invalid
+ Allow and ignore an empty section.
+
+ PR 29566
+ * elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or
+ elf_dynverref for empty sections.
+ (_bfd_elf_slurp_version_tables): Remove now redundant tests.
+
+2022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Set EF_RISCV_TSO also on .option arch
+ This is a minor fix to commit 96462b012988d35ebb1137a2ad9fd0a96547d79a
+ ("RISC-V: Implement Ztso extension"). Currently, it sets EF_RISCV_TSO ELF
+ flag when initial ISA string contains the 'Ztso' extension. However, GAS
+ has a way to update the ISA string: ".option arch".
+
+ When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag
+ is set when the 'C' extension is detected. Analogously, this commit sets
+ the EF_RISCV_TSO when the 'Ztso' extension is detected.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the
+ 'Ztso' extension is specified via ".option arch" directive.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ PR29573, addr2line doesn't display file/line for local symbols
+ The DWARF standard is clear that DW_AT_linkage_name is optional.
+ Compilers may not provide the attribute on functions and variables,
+ even though the language mangles names. g++ does not for local
+ variables and functions. Without DW_AT_linkage_name, mangled object
+ file symbols can't be directly matched against the source-level
+ DW_AT_name in DWARF info. One possibility is demangling the object
+ file symbols, but that comes with its own set of problems:
+ 1) A demangler might not be available for the compiler/language.
+ 2) Demangling doesn't give the source function name as stored in
+ DW_AT_name. Class and template parameters must be stripped at
+ least.
+
+ So this patch takes a simpler approach. A symbol matches DWARF info
+ if the DWARF address matches the symbol address, and if the symbol
+ name contains the DWARF name as a sub-string. Very likely the name
+ matching is entirely superfluous.
+
+ PR 29573
+ * dwarf.c (lookup_symbol_in_function_table): Match a symbol
+ containing the DWARF source name as a substring.
+ (lookup_symbol_in_variable_table): Likewise.
+ (_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast
+ returns false, fall back to comp_unit_find_line.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ dwarf2.c: simplify best_fit_len tests
+ * dwarf2.c (lookup_address_in_function_table): Simplify
+ best_fit_len test.
+ (info_hash_lookup_funcinfo): Likewise.
+ (lookup_symbol_in_function_table): Likewise, also reorder tests
+ and check "file" is set.
+ (lookup_symbol_in_variable_table): Reorder tests.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ dwarf2.c: mangle_style
+ non_mangled incorrectly returned "true" for Ada. Correct that, and
+ add a few more non-mangled entries. Return a value suitable for
+ passing to cplus_demangle to control demangling.
+
+ * dwarf2.c: Include demangle.h.
+ (mangle_style): Rename from non_mangled. Return DMGL_* value
+ to suit lang. Adjust all callers.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ dwarf2.c remove varinfo and funcinfo sec field
+ The "sec" field in these structures is only set and used in lookup
+ functions. It always starts off as NULL. So the only possible effect
+ of the field is to modify the return of the lookup, which was its
+ purpose back in 2005 when HJ fixed PR990. Since then we solved the
+ problem of relocatable object files with the fix for PR2338, so this
+ field is now redundant.
+
+ * dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
+ (lookup_symbol_in_function_table): Don't set or test "sec".
+ (lookup_symbol_in_variable_table): Likewise.
+ (info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.
+
+2022-09-21 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ configure: Pass CPPFLAGS_FOR_BUILD to subdirs
+ Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through
+ bfd/warning.m4), not AC_SUBSTing the variable causes minor issues.
+
+ Fortunately, it didn't cause severe errors but error messages related to
+ @CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed
+ to subdirectories through Makefile) remain in config.log.
+
+ To avoid invalid invocation of preprocessor for build environment, we
+ need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to
+ subdirectories that need it. This is what this commit does.
+
+ ChangeLog:
+
+ * configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories.
+ * configure: Regenerate.
+
+2022-09-21 Shihua <shihua@iscas.ac.cn>
+
+ RISC-V: Implement Ztso extension
+ This patch support ZTSO extension. It will turn on the tso flag for elf_flags
+ once we have enabled Ztso extension. This is intended to implement v0.1 of
+ the proposed specification which can be found in Chapter 25 of,
+ https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.
+
+ bfd\ChangeLog:
+
+ * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag.
+ * elfxx-riscv.c: Add Ztso's arch.
+
+ binutils\ChangeLog:
+
+ * readelf.c (get_machine_flags): Set TSO flag.
+
+ gas\ChangeLog:
+
+ * config/tc-riscv.c (riscv_set_tso): Ditto.
+ (riscv_set_arch): Ditto.
+ * testsuite/gas/riscv/ztso.d: New test.
+
+ include\ChangeLog:
+
+ * elf/riscv.h (EF_RISCV_TSO): Ditto.
+
+2022-09-21 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Always generate R_RISCV_CALL_PLT reloc for call in assembler.
+ Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now,
+ https://github.com/bminor/binutils-gdb/commit/3b1450b38c644f99aa2e211747b428b9f8d15cca
+
+ And the psabi already deprecate the CALL reloc,
+ https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0
+
+ Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if
+ it has @plt postfix. I believe LLVM (https://reviews.llvm.org/D132530) already
+ support this, so GNU as should do the same thing.
+
+ gas/
+ * config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for
+ call, even if it has @plt postfix.
+ * testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT.
+ * testsuite/gas/riscv/relax-reloc.d: Likewise.
+ ld/
+ * testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.
+
+2022-09-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ Re: PowerPC64 pcrel got relocs against local symbols
+ The last patch wasn't all that shiny. There are rather a lot more
+ relocations that can hit the assertion in md_apply_fix if the symbol
+ is local or absolute. Fix them all.
+
+ * config/tc-ppc.c (ppc_force_relocation): Add all relocs that
+ expect a symbol in md_apply_fix. Remove tls pcrel relocs
+ already covered in general tls match range.
+
+2022-09-21 Alan Modra <amodra@gmail.com>
+
+ looping in alpha_vms_slurp_relocs
+ The direct cause for the looping was failing to test for error return
+ from _bfd_vms_get_object_record inside a while(1) loop. Fix that.
+ Also record status of first alpha_vms_slurp_relocs call and return
+ that for all subsequent calls. (The object format has one set of
+ relocation records for all sections.) If the first call fails, all
+ others should too.
+
+ * vms-alpha.c (struct vms_private_data_struct): Make reloc_done
+ a tri-state int.
+ (alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on
+ failure. Return that status on subsequent calls. Check
+ _bfd_vms_get_object_record return status.
+ (alpha_vms_get_reloc_upper_bound): Return status from
+ alpha_vms_slurp_relocs.
+ (alpha_vms_write_exec): Exclude sections with contents NULL due
+ to previous errors from layout, and don't try to write them.
+
+2022-09-20 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ ppc/svp64: test setvl ms operand
+
+2022-09-20 Tom Tromey <tom@tromey.com>
+
+ Make stdin_event_handler static
+ I noticed that stdin_event_handler is only used in event-top.c, so
+ this patch changes it to be 'static'.
+
+2022-09-20 Tom Tromey <tromey@adacore.com>
+
+ Constify some target_so_ops instances
+ This changes some target_so_ops instances to be const. This makes
+ their use a little more obvious (they can't be mutated) and also
+ allows for the removal of some initialization code.
+
+ Move solib_ops into gdbarch
+ This changs solib_ops to be an ordinary gdbarch value and updates all
+ the uses. This removes a longstanding FIXME and makes the code
+ somewhat cleaner as well.
+
+ Remove current_target_so_ops
+ current_target_so_ops is only set in a single place. It seems better
+ to simply remove it.
+
+2022-09-20 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add a debuginfod-support.exp helper library
+ We currently have a single test for GDB's debuginfod support, this is
+ gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
+ setup, starts debuginfod, and then does the testing.
+
+ This commit tries to split the existing script in two, there is a new
+ library lib/debuginfod-support.exp, which contains a helper functions
+ related to running debuginfod tests. All the code in the new library
+ is basically copied from the existing test case (which is why I
+ retained the copyright date range on the new library), with some minor
+ adjustments to try and make the code a little more generic.
+
+ One change I made, for example, is the library offers functions to
+ shut down debuginfod, previously we just relied on expect shutting
+ down debuginfod when dejagnu completed.
+
+ The existing test script is updated to make use of the new library
+ code, and this test is still passing for me. The only change in the
+ test results is a single test where I changed the name to remove the
+ port number from the test name - the port number can change from run
+ to run, so could make it hard to compare test results.
+
+ I have also done a little light house keeping on the original test
+ script, updating and adding new comments, and making use of
+ proc_with_prefix in a couple of places.
+
+2022-09-20 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Set macro SUB_SEGMENT_ALIGN to 0.
+
+2022-09-20 Nick Clifton <nickc@redhat.com>
+
+ Stop strip from complaining about empty note sections when stripping a binary for a second time.
+ * objcopy.c (copy_object): Do not issue a warning message when
+ encountering empty .gnu.build.attribute sections.
+
+ New Serbian translations for various binutils sub-directories.
+
+2022-09-20 Zeke Lu <lvzecai@gmail.com>
+
+ Bug 29580 - typo in warning message: .note.gnu.build-id data size is too bug
+
+2022-09-20 Xi Ruoyao <xry111@xry111.site>
+
+ LoongArch: Fix R_LARCH_IRELATIVE insertion after elf_link_sort_relocs
+ loongarch_elf_finish_dynamic_symbol is called after elf_link_sort_relocs
+ if -z combreloc. elf_link_sort_relocs redistributes the contents of
+ .rela.* sections those would be merged into .rela.dyn, so the slot for
+ R_LARCH_IRELATIVE may be out of relplt->contents now.
+
+ To make things worse, the boundary check
+
+ dyn < dyn + relplt->size / sizeof (*dyn)
+
+ is obviously wrong ("x + 10 < x"? :), causing the issue undetected
+ during the linking process and the resulted executable suddenly crashes
+ at runtime.
+
+ The issue was found during an attempt to add static-pie support to the
+ toolchain.
+
+ Fix it by iterating through the inputs of .rela.dyn to find the slot.
+
+2022-09-20 Xi Ruoyao <xry111@xry111.site>
+
+ LoongArch: Don't write into GOT for local ifunc
+ Local ifuncs are always resolved at runtime via R_LARCH_IRELATIVE, so
+ there is no need to write anything into GOT. And when we write the GOT
+ we actually trigger a heap-buffer-overflow: If a and b are different
+ sections, we cannot access something in b with "a->contents + (offset
+ from a)" because "a->contents" and "b->contents" are heap buffers
+ allocated separately, not slices of a large buffer.
+
+ So stop writing into GOT for local ifunc now.
+
+2022-09-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: build documentation only if BUILD_MAN is true
+ gprofng/ChangeLog
+ 2022-09-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29476
+ * gprofng/Makefile.am: Build documentation only if BUILD_MAN is true
+ * gprofng/Makefile.in: Rebuild.
+ * gprofng/configure: Rebuild.
+
+2022-09-19 Enze Li <enze.li@hotmail.com>
+
+ gdb: add ATTRIBUTE_PRINTF to gdb_bfd_error_handler
+ I see this error when building with clang,
+
+ CXX gdb_bfd.o
+ gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
+ const std::string str = string_vprintf (fmt, ap_copy);
+ ^~~
+ 1 error generated.
+
+ This patch adds missing ATTRIBUTE_PRINTF to fix the error.
+
+ Tested on x86_64-linux with gcc 12 and clang 14.
+
+2022-09-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-17 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix "file index out of range" complaint
+ With the test-case included in this commit, we run into this FAIL:
+ ...
+ (gdb) p var^M
+ During symbol reading: file index out of range^M
+ $1 = 0^M
+ (gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints
+ ...
+
+ This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with
+ --gc-sections"), which contains this change in read_file_scope:
+ ...
+ - handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+ + if (lowpc != highpc)
+ + handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+ ...
+
+ The change intends to avoid a problem with a check in
+ lnp_state_machine::check_line_address, but also prevents the file and dir
+ tables from being read, which causes the complaint.
+
+ Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the
+ call to dwarf_decode_lines in handle_DW_AT_stmt_list.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561
+
+2022-09-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-17 Kevin Buettner <kevinb@redhat.com>
+
+ BFD error message suppression test case
+ This commit adds a GDB test case which tests GDB's BFD error handler
+ hook for suppressing output of all but the first identical messages.
+
+ See the comment at the beginning of bfd-errors.exp for details about
+ this new test.
+
+ I've tested this test for both 32- and 64-bit ELF files and also
+ on both little endian and big endian machines. It also works for
+ both native and remote targets. The only major restriction is that
+ it only works for ELF targets.
+
+2022-09-17 Kevin Buettner <kevinb@redhat.com>
+
+ Suppress printing of superfluous BFD error messages
+ This commit adds a hook to the BFD error handler for suppressing
+ identical messages which have been output once already.
+
+ It's motivated by this Fedora bug...
+
+ https://bugzilla.redhat.com/show_bug.cgi?id=2083315
+
+ ...in which over 900,000 BFD error messages are output when attaching
+ to firefox. From the bug report, the messages all say:
+
+ BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38)
+
+ Since there's no (additional) context which might assist the user in
+ determining what's wrong, there's really no point in outputting more
+ than one message. Of course, if BFD should output some
+ other/different message, it should be output too, but all future
+ messages identical to those already output should be suppressed.
+
+ For the firefox problem, it turned out that there were only 37
+ sections, but something was referring to section #38. I haven't
+ investigated further to find out how this came to be.
+
+ Despite this problem, useful debugging might still be done, especially
+ if the user doesn't care about debugging the problematic library.
+
+ If it turns out that knowing the quantity of messages might be useful,
+ I've implemented the suppression mechanism by keeping a count of each
+ identical message. A new GDB command, perhaps a 'maintenance'
+ command, could be added to print out each message along with the
+ count. I haven't implemented this though because I'm not convinced of
+ its utility. Also, the BFD message printer has support for BFD-
+ specific format specifiers. The BFD message strings that GDB stores
+ in its map are sufficient for distinguishing messages from each
+ other, but are not identical to those output by BFD's default error
+ handler. So, that problem would need to be solved too.
+
+2022-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle named DW_TAG_unspecified_type DIE
+ With the test-case included in the patch, we run into:
+ ...
+ (gdb) info types -q std::nullptr_t^M
+ During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M
+ ^M
+ File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M
+ 2198: typedef decltype(nullptr) std::nullptr_t;^M
+ (gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \
+ without complaint
+ ...
+
+ Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify
+ in the test-case using "maint print symbols" that the symbol exists.
+
+ Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271
+
+2022-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix PowerPC IEEE 128-bit format arg passing
+ On a powerpc system with gcc 12 built to default to 128-bit IEEE long double,
+ I run into:
+ ...
+ (gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M
+ $8 = 0 + 0i^M
+ (gdb) FAIL: gdb.base/varargs.exp: print \
+ find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)
+ ...
+
+ This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param.
+
+ Fix this and similar cases, and expand the test-case to test handling of
+ homogeneous aggregates.
+
+ Tested on ppc64le-linux, power 10.
+
+ Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
+ Tested-by: Carl Love <cel@us.ibm.com>
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543
+
+2022-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64
+ [ Another attempt at fixing the problem described in commit cd919f5533c
+ ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ]
+
+ When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with
+ aarch64-linux, we run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \
+ tmp-dw2-dir-file-name.c:999^M
+ (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
+ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
+ compdir_missing__ldir_missing__file_basename
+ ...
+
+ The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
+ address 0x400608 starts at a line entry:
+ ...
+ CU: tmp-dw2-dir-file-name.c:
+ File name Line number Starting address View Stmt
+ tmp-dw2-dir-file-name.c 999 0x400608 x
+ tmp-dw2-dir-file-name.c 1000 0x40062c x
+ tmp-dw2-dir-file-name.c - 0x40062c
+ ...
+ and therefore the breakpoint is printed without instruction address.
+
+ In contrast, for x86_64-linux, we have the breakpoint printed with instruction
+ address:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \
+ at tmp-dw2-dir-file-name.c:999^M
+ (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
+ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
+ compdir_missing__ldir_missing__file_basename
+ ...
+
+ The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
+ address 0x004004c1 doesn't start at a line entry:
+ ...
+ CU: tmp-dw2-dir-file-name.c:
+ File name Line number Starting address View Stmt
+ tmp-dw2-dir-file-name.c 999 0x4004bd x
+ tmp-dw2-dir-file-name.c 1000 0x4004d3 x
+ tmp-dw2-dir-file-name.c - 0x4004d3
+ ...
+
+ Fix this by:
+ - unifying behaviour between the archs by adding an explicit line number entry
+ for the address compdir_missing__ldir_missing__file_basename_label, making
+ the FAIL reproducible on x86_64-linux.
+ - expecting the breakpoint to be printed without instruction address.
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2022-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Handle pending ^C after rl_callback_read_char
+ In completion tests in various test-cases, we've been running into these
+ "clearing input line" timeouts:
+ ...
+ (gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd"
+ FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout)
+ ...
+ where $cmd == "maintenance selftest name_that_does_not_exist".
+
+ AFAIU, the following scenario happens:
+ - expect sends "$cmd\t"
+ - gdb detects the stdin event, and calls rl_callback_read_char until it
+ comes to handle \t
+ - readline interprets the \t as completion, tries to complete, fails to do so,
+ outputs a bell (^G)
+ - expect sees the bell, and proceeds to send ^C
+ - readline is still in the call to rl_callback_read_char, and stores the
+ signal in _rl_caught_signal
+ - readline returns from the call to rl_callback_read_char, without having
+ handled _rl_caught_signal
+ - gdb goes to wait for the next event
+ - expect times out waiting for "Quit", the expected reaction for ^C
+
+ Fix this by handling pending signals after each call to rl_callback_read_char.
+
+ The fix is only available for readline 8.x, if --with-system-readline provides
+ an older version, then the fix is disabled due to missing function
+ rl_check_signals.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813
+
+2022-09-16 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 pcrel got relocs against local symbols
+ Not that anyone would want to indirect via the GOT when an address can
+ be loaded directly with pla, the following:
+
+ pld 3,x@got@pcrel
+ x:
+
+ leads to "Internal error in md_apply_fix", because the generic parts
+ of assembler fixup handling convert the fx_pcrel fixup to one without
+ a symbol. Stop that happening.
+
+ * config/tc-ppc.c (ppc_force_relocation): Add PLT_PCREL34 and
+ assorted GOT_PCREL34 relocs.
+
+2022-09-16 Alan Modra <amodra@gmail.com>
+
+ pdb sanity check block_size
+ * pdb.c (pdb_get_elt_at_index): Only allow block_size to be
+ 512, 1024, 2048, or 4096.
+
+2022-09-16 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: Make g imply zmmul extension.
+ bfd/
+ * elfxx-riscv.c (riscv_implicit_subset): Moved entry of m after g,
+ so that g can imply zmmul.
+ gas/
+ * testsuite/gas/riscv/attribute-01.d: Updated.
+ * testsuite/gas/riscv/attribute-02.d: Likewise.
+ * testsuite/gas/riscv/attribute-03.d: Likewise.
+ * testsuite/gas/riscv/attribute-04.d: Likewise.
+ * testsuite/gas/riscv/attribute-05.d: Likewise.
+ * testsuite/gas/riscv/attribute-10.d: Likewise.
+ * testsuite/gas/riscv/march-imply-g.d: Likewise.
+ * testsuite/gas/riscv/march-imply-unsupported.d: Likewise.
+
+2022-09-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-15 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ bfd, binutils, gas: Remove/mark unused variables
+ Clang generates a warning on unused (technically, written but not read
+ thereafter) variables. By the default configuration (with "-Werror"), it
+ causes a build failure (unless "--disable-werror" is specified).
+
+ This commit adds ATTRIBUTE_UNUSED attribute to some of them, which means
+ they are *possibly* unused (can be used but no warnings occur when
+ unused) and removes others.
+
+ bfd/ChangeLog:
+
+ * elf32-lm32.c (lm32_elf_size_dynamic_sections): Mark unused
+ rgot_count variable.
+ * elf32-nds32.c (elf32_nds32_unify_relax_group): Remove unused
+ count variable.
+ * mmo.c (mmo_scan): Mark unused lineno variable.
+
+ binutils/ChangeLog:
+
+ * windmc.c (write_rc): Remove unused i variable.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_ip): Remove unused argnum variable.
+
+ ld/ChangeLog:
+
+ * pe-dll.c (generate_reloc): Remove unused bi and page_count
+ variables.
+
+2022-09-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build issues on musl
+ gprofng/ChangeLog
+ 2022-09-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29477
+ * configure.ac: Set __MUSL_LIBC.
+ * configure: Rebuild.
+ * common/config.h.in: Rebuild.
+ * src/collector_module.h: Fix compiler errors because mmap64, open64,
+ pwrite64 are macros and getcontext() is absent on musl.
+ * libcollector/collector.c: Likewise.
+ * libcollector/hwprofile.c: Likewise.
+ * libcollector/iolib.c: Likewise.
+ * libcollector/libcol_util.c: Likewise.
+ * libcollector/linetrace.c: Likewise.
+ * libcollector/memmgr.c: Likewise.
+ * libcollector/profile.c: Likewise.
+ * libcollector/unwind.c: Likewise.
+ * libcollector/dispatcher.c: Likewise.
+ * src/Experiment.cc: Likewise.
+ * libcollector/collector.h: Use dlsym() because dlvsym() is not defined
+ on musl.
+ * libcollector/iotrace.c: Remove interposition of versioned functions.
+ * libcollector/mmaptrace.c: Likewise.
+ * libcollector/libcol_util.h: Fix -Wint-to-pointer-cast warnings.
+ * libcollector/jprofile.c: Likewise.
+ * libcollector/synctrace.c: Include "collector.h".
+ * src/Print.cc: Use get_basename() because basename() is not defined
+ on musl.
+ * common/hwcdrv.c: Fix -Wformat= warnings.
+
+2022-09-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-14 Rupesh Potharla <Rupesh.Potharla@amd.com>
+
+ Binutils: Readelf testcase failing with clang
+ * testsuite/binutils-all/readelf.exp (readelf_wi_test): Extend
+ regexps to allow for output genreated by the Clang compiler.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ looping in bfd_mach_o_fat_openr_next_archived_file
+ mach-o.c doesn't sanity check mach-o-fat archives, making it easy for
+ fuzzers to create an archive with mach_o_fat_archentry headers that
+ point to the same offset. bfd_mach_o_fat_openr_next_archived_file
+ uses the previous element offset to find its header, and thus the next
+ element. If two offsets are the same, any tool reading the archive
+ will get stuck. This patch rejects such archives, and any with
+ overlapping elements.
+
+ * mach-o.c (overlap_previous): New function.
+ (bfd_mach_o_fat_archive_p): Sanity check that elements do not
+ overlap each other or the file and archive headers.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ regen pofiles
+
+2022-09-14 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ bfd: Stop using -Wstack-usage=262144 when built with Clang
+ Some components of GNU Binutils will pass "-Wstack-usage=262144" when
+ "GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage",
+ despite that related configuration part in bfd/warning.m4 handles the latest
+ Clang (15.0.0 as of this writing) as "GCC >= 5.0".
+
+ The option "-Wstack-usage" was ignored when the first version of Clang is
+ released but even this "ignoring" behavior is removed before Clang 4.0.0.
+ So, if we give Clang "-Wstack-usage=262144", it generates a warning, making
+ the build failure.
+
+ This commit checks "__clang__" macro to prevent adding the option if the
+ compiler is identified as Clang.
+
+ bfd/ChangeLog:
+
+ * warning.m4: Stop appending "-Wstack-usage=262144" option when
+ compiled with Clang.
+ * configure: Regenerate.
+
+ binutils/ChangeLog:
+
+ * configure: Regenerate.
+
+ gas/ChangeLog:
+
+ * configure: Regenerate.
+
+ gold/ChangeLog:
+
+ * configure: Regenerate.
+
+ gprof/ChangeLog:
+
+ * configure: Regenerate.
+
+ ld/ChangeLog:
+
+ * configure: Regenerate.
+
+ opcodes/ChangeLog:
+
+ * configure: Regenerate.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ Modify ld-ctf test files to suit ARM
+ The "@" char starts a comment on ARM.
+
+ * testsuite/ld-ctf/diag-ctf-version-0.s: Replace @progbits with
+ %progbits.
+ * testsuite/ld-ctf/diag-ctf-version-2-unsupported-feature.s: Likewise.
+ * testsuite/ld-ctf/diag-ctf-version-f.s: Likewise.
+ * testsuite/ld-ctf/diag-cttname-invalid.s: Likewise.
+ * testsuite/ld-ctf/diag-cttname-null.s: Likewise.
+ * testsuite/ld-ctf/diag-cuname.s: Likewise.
+ * testsuite/ld-ctf/diag-decompression-failure.s: Likewise.
+ * testsuite/ld-ctf/diag-parlabel.s: Likewise.
+ * testsuite/ld-ctf/diag-parname.s: Likewise.
+ * testsuite/ld-ctf/diag-strlen-invalid.s: Likewise.
+ * testsuite/ld-ctf/diag-unsupported-flag.s: Likewise.
+ * testsuite/ld-ctf/diag-wrong-magic-number.s: Likewise.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ asan: som_set_reloc_info heap buffer overflow
+ Also a bugfix. The first time the section was read, the contents
+ didn't supply an addend.
+
+ * som.c (som_set_reloc_info): Sanity check offset. Do process
+ contents after reading. Tidy section->contents after freeing.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ ubsan: som_is_space null dereference
+ On objcopy of fuzzed file.
+
+ * som.c (som_write_fixups): Exit loop if space sections all
+ processed.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ msan: vms-alpha use-of-uninitialized-value in dst_retrieve_location
+ * vms-alpha.c (dst_define_location): Init any unused entries.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ ubsan: arm-dis.c index out of bounds
+ We are way off in the weeds with this one, and will be printing
+ <UNPREDICTABLE> for S > 10.
+
+ * arm-dis.c (print_insn_cde): Wrap 'T' value.
+
+2022-09-14 Alan Modra <amodra@gmail.com>
+
+ PR29540, R_PPC64_NONE in .rela.dyn when linking Linux vdso
+ PR 29540
+ * elf64-ppc.c (allocate_dynrelocs): Don't alloc space for relocs
+ against discarded sections.
+ (ppc64_elf_size_dynamic_sections): Use standard test for discarded
+ sections.
+ * elf32-ppc.c (allocate_dynrelocs): Don't alloc space for relocs
+ against discarded sections.
+ (ppc_elf_size_dynamic_sections): Use standard test for discarded
+ sections.
+
+2022-09-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-13 Aaron Merey <amerey@redhat.com>
+
+ objdump: '-S' should trigger search for separate debuginfo.
+ Add with_source_code to the command line options that trigger
+ might_need_separate_debug_info and dump_any_debugging. This helps
+ 'objdump -S' download missing files via debuginfod without the need for
+ specifying extra command line options like '-L'.
+
+2022-09-13 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Update gdb.base/so-impl-ld.exp
+ gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
+ epilogue information and that GDB would stop in the } line. This would
+ make clang tests fail like so:
+
+ step^M
+ solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
+ 7|__ return arg*arg;|__|___/* HERE */^M
+ (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
+ next^M
+ main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
+ 22|_ return 0;^M
+ (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
+ next^M
+ 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call
+
+ This patch changes it so solib_main has 2 lines where GDB can stop
+ regardless of compiler choices, and updates the exp file to
+ generically deal with unknown number of steps until leaving that
+ function.
+
+2022-09-13 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: introduce gdb_step_until
+ Currently, GDB's testsuite uses a set amount of step commands to exit
+ functions. This is a problem if a compiler emits different epilogue
+ information from gcc, or emits no epilogue information at all. It was
+ most noticeable if Clang was used to test GDB.
+
+ To fix this unreliability, this commit introduces a new proc that will
+ step the inferior until it is stopped at a line that matches the given
+ regexp, or until it steps too many times - defined as an optional
+ argument. If the line is found, it shows up as a single PASS in the
+ test, and if the line is not found, a single FAIL is emitted.
+
+ This patch only introduces this proc, but does not add it to any
+ existing tests, these will be introduced in the following commit.
+
+2022-09-13 Bruno Larsen <blarsen@redhat.com>
+
+ explicitly test for stderr in gdb.base/dprintf.exp
+ Not all compilers add stderr debug information when compiling a
+ program. Clang, for instance, prefers to add nothing from standard
+ libraries and let an external debug package have this information.
+ Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
+ use dprintf as a call to fprintf(stderrr, ...), like this:
+
+ (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
+ continue
+ Continuing.
+ kickoff 1234
+ also to stderr 1234
+ 'stderr' has unknown type; cast it to its declared type
+ (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)
+
+ To avoid this false positive, we explicitly test to see if
+ the compiler has added information about stderr at all, and abort
+ testing dprintf as an fprintf call if it is unavailable.
+
+2022-09-13 Mark Harmstone <mark@harmstone.com>
+
+ Add pdb archive format
+ Resubmitted with changes in
+ https://sourceware.org/pipermail/binutils/2022-September/122791.html
+ made.
+
+2022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky rm csky_print_registers_info
+ The reason for implementing this interface is that we want to print
+ GPR, PC, EPC, PSR and EPSR when the "info register" command
+ is executed.
+
+ A prev patch has added PC, EPC, PSR and EPSR to reggroup
+ general_group, the purpose has been achieved, so this function is
+ no longer required.
+
+2022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky rm csky_memory_insert/remove_breakpoint
+ Software breakpoints are inserted or removed by the gdb stub via
+ remote protocol, these two functions are no longer needed.
+
+2022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky add unwinder for long branch cases
+ There are two sequences of instructions for long branch:
+ 1. jmpi [pc+4] //insn code: 0xeac00001
+ .long addr
+
+ 2. lrw t1, [pc+8] //insn code: 0xea8d0002
+ jmp t1 //insn code: 0x7834
+ nop //insn code: 0x6c03
+ .long addr
+
+2022-09-13 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdbserver/csky add csky gdbserver support
+ Add new files:
+ gdb/arch/csky.c
+ gdb/arch/csky.h
+ gdb/features/cskyv2-linux.c
+ gdbserver/linux-csky-low.cc
+
+ 1. In gdb/arch/csky.c file, add function "csky_create_target_description()"
+ for csky_target::low_arch_setup(). later, it can be used for csky native gdb.
+
+ 2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include
+ gprs, pc, hi, lo, float, vector and float control registers.
+
+ 3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to
+ get/set registers. The main data structures in asm/ptrace.h are:
+ struct pt_regs {
+ unsigned long tls;
+ unsigned long lr;
+ unsigned long pc;
+ unsigned long sr;
+ unsigned long usp;
+
+ /*
+ * a0, a1, a2, a3:
+ * r0, r1, r2, r3
+ */
+ unsigned long orig_a0;
+ unsigned long a0;
+ unsigned long a1;
+ unsigned long a2;
+ unsigned long a3;
+
+ /*
+ * r4 ~ r13
+ */
+ unsigned long regs[10];
+
+ /* r16 ~ r30 */
+ unsigned long exregs[15];
+
+ unsigned long rhi;
+ unsigned long rlo;
+ unsigned long dcsr;
+ };
+
+ struct user_fp {
+ unsigned long vr[96];
+ unsigned long fcr;
+ unsigned long fesr;
+ unsigned long fid;
+ unsigned long reserved;
+ };
+
+2022-09-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-12 Tom Tromey <tromey@adacore.com>
+
+ Use checked_static_cast in more places
+ I went through all the uses of dynamic_cast<> in gdb, looking for ones
+ that could be replaced with checked_static_cast. This patch is the
+ result. Regression tested on x86-64 Fedora 34.
+
+2022-09-12 Peter Bergner <bergner@linux.ibm.com>
+
+ ppc: Document the -mfuture and -Mfuture options and make them usable
+ The -mfuture and -Mfuture options which are used for adding potential
+ new ISA instructions were not documented. They also lacked a bitmask
+ so new instructions could not be enabled by those options. Fixed.
+
+ binutils/
+ * doc/binutils.texi: Document -Mfuture.
+
+ gas/
+ * config/tc-ppc.c: Document -mfuture
+ * doc/c-ppc.texi: Likewise.
+
+ include/
+ * opcode/ppc.h (PPC_OPCODE_FUTURE): Define.
+
+ opcodes/
+ * ppc-dis.c (ppc_opts) <future>: Use it.
+ * ppc-opc.c (FUTURE): Define.
+
+2022-09-12 Bruno Larsen <blarsen@redhat.com>
+
+ add xfails to gdb.base/complex-parts.exp when testing with clang
+ clang doesn't add encoding to the name of complex variables, only says
+ that the type name is complex, making the relevant tests fail.
+ This patch adds the xfails to the tests that expect the variable name to
+ include it.
+
+2022-09-12 Bruno Larsen <blarsen@redhat.com>
+
+ Fix gdb.base/call-ar-st to work with Clang
+ When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
+ like so:
+
+ print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
+ ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
+ 274 print_int_array(array_i); /* -step1- */
+ (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays
+
+ With GCC we instead see:
+
+ print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
+ 274 print_int_array(array_i); /* -step1- */
+ (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays
+
+ The difference is that with Clang we get:
+
+ array_i=<main.integer_array>, ...
+
+ instead of
+
+ array_i = <integer_array>, ...
+
+ These symbols are local static variables, and "main" is the name of
+ the function they are defined in. GCC instead appends a sequence
+ number to the linkage name:
+
+ $ nm -A call-ar-st.gcc | grep integer_
+ call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968
+
+ $ nm -A call-ar-st.clang | grep integer_
+ call-ar-st:00000000004061a0 b main.integer_array
+
+ This commit changes the testcase to accept both outputs, as they are
+ functionally identical.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
+
+2022-09-12 Bruno Larsen <blarsen@redhat.com>
+
+ fix gdb.base/access-mem-running.exp for clang testing
+ Clang was optimizing global_var away because it was not being used
+ anywhere. this commit fixes that by adding the attribute used it.
+
+ update gdb.base/info-program.exp to not fail with clang
+ The test specifically mentions that it doesn't care where the program
+ stops, however it was still testing for a specific location. The clang
+ compiler emits different line information for epilogue, so GDB reports a
+ different stopping location, depending on the used compiler. With this
+ patch the test works even with clang.
+
+2022-09-12 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
+ Clang organizes the variables differently to gcc in the original version
+ of this code, leading to the following differences when testing
+ p (int*) &dataglobal + 1
+
+ gcc:
+ $16 = (int *) 0x404034 <datalocal>
+
+ clang:
+ $16 = (int *) 0x404034 <dataglobal8>
+
+ However, since the important part of this test doesn't seem to be which
+ symbol is linked, but rather if GDB is correctly increasing the
+ address. This test was changed to actually measure address changes,
+ instead of assuming the ordering and naming of symbols.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-09-12 Martin Storsjö <martin@martin.st>
+
+ ld: pe: Apply review suggestions on the existing exports/imports arrays
+ Use a separate explicit max_exports/imports field, instead of
+ deducing it from the number of allocated elements. Use a named
+ constant for the incremental growth of the array.
+
+ Use bool instead of int for boolean values.
+
+ Remove an unnecessary if statement/scope in the def_file_free
+ function.
+
+ Add more verbose comments about parameters, and about insertion
+ into an array of structs.
+
+ Generally use unsigned integers for all array indices and sizes.
+ The num_exports/imports fields are kept as is as signed integers,
+ since changing them to unsigned would require a disproportionate
+ amount of changes ti pe-dll.c to avoid comparisons between signed
+ and unsigned.
+
+ Simply use xrealloc instead of a check and xmalloc/xrealloc;
+ xrealloc can take NULL as the first parameter (and does a similar
+ check internally). (This wasn't requested in review though,
+ but noticed while working on the code.)
+
+2022-09-12 Martin Storsjö <martin@martin.st>
+
+ ld: pe: Improve performance of object file exclude symbol directives
+ Store the list of excluded symbols in a sorted list, speeding up
+ checking for duplicates when inserting new entries.
+
+ This is done in the same way as is done for exports and imports
+ (while the previous implementation was done with a linked list,
+ based on the implementation for aligncomm).
+
+ When linking object files with excluded symbols, there can potentially
+ be very large numbers of excluded symbols (just like builds with
+ exports can have a large number of exported symbols).
+
+ This improves the link performance somewhat, when linking with large
+ numbers of excluded symbols.
+
+ The later actual use of the excluded symbols within pe-dll.c
+ handles them via an unordered linked list still, though.
+
+2022-09-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix abort in selftest run_on_main_thread with ^C
+ When running selftest run_on_main_thread and pressing ^C, we can run into:
+ ...
+ Running selftest run_on_main_thread.
+ terminate called without an active exception
+
+ Fatal signal: Aborted
+ ...
+
+ The selftest function looks like this:
+ ...
+ static void
+ run_tests ()
+ {
+ std::thread thread;
+
+ done = false;
+
+ {
+ gdb::block_signals blocker;
+
+ thread = std::thread (set_done);
+ }
+
+ while (!done && gdb_do_one_event () >= 0)
+ ;
+
+ /* Actually the test will just hang, but we want to test
+ something. */
+ SELF_CHECK (done);
+
+ thread.join ();
+ }
+ ...
+
+ The error message we see is due to the destructor of thread being called while
+ thread is joinable.
+
+ This is supposed to be taken care of by thread.join (), but the ^C prevents
+ that one from being called, while the destructor is still called.
+
+ Fix this by ensuring thread.join () is called (if indeed required) before the
+ destructor using SCOPE_EXIT.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29549
+
+2022-09-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Support .gdb_index section with TUs in .debug_info
+ The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support
+ .debug_names section with TUs in .debug_info").
+
+ Tested on x86_64-linux.
+
+2022-09-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le
+ In commit cd919f5533c ("[gdb/testsuite] Fix
+ gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp
+ independent of prologue analyzers, using this change:
+ ...
+ - gdb_breakpoint $func
+ + gdb_breakpoint *$func
+ ...
+
+ That however caused a regression on ppc64le. For PowerPC, as described in the
+ ELFv2 ABI, a function can have a global and local entry point.
+
+ Setting a breakpoint on *$func effectively creates a breakpoint for the global
+ entry point, so if the function is entered through the local entry point, the
+ breakpoint doesn't trigger.
+
+ Fix this by reverting commit cd919f5533c, and setting the breakpoint on
+ ${func}_label instead.
+
+ Tested on x86_64-linux and ppc64le-linux.
+
+2022-09-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clang
+ When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run
+ into:
+ ...
+ (gdb) break *compdir_missing__ldir_missing__file_basename^M
+ Breakpoint 2 at 0x400580^M
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, 0x0000000000400580 in \
+ compdir_missing.ldir_missing.file_basename ()^M
+ (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
+ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
+ compdir_missing__ldir_missing__file_basename
+ ...
+
+ The problem is that the test-case uses labels outside functions, which is know
+ to cause problem with clang, as documented in the comment for proc
+ function_range.
+
+ Fix this by using get_func_info instead.
+
+ Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.
+
+2022-09-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: avoid i386_dis_printf()'s staging area for a fair part of output
+ While PR binutils/29483 has now been addressed differently, this
+ originally proposed change still has its merits: Avoiding vsnprintf()
+ for typically far more than half of the overall output results in a 2-3%
+ performance gain in my testing (with debug builds of objdump, libbfd,
+ and libopcodes).
+
+ With that part of output no longer using staging_area[], the array also
+ doesn't need to be quite as large anymore (the largest presently used
+ size is 27, from "64-bit address is disabled").
+
+ While limiting the scope of "res" it became apparent that
+ - no caller cares about the function's return value,
+ - the comment about the return value was wrong,
+ - a particular positive return value would have been meaningless to the
+ caller.
+ Therefore convert the function to return "void" at the same time.
+
+2022-09-12 Nelson Chu <nelson@rivosinc.com>
+
+ RISC-V: PR28509, the default visibility symbol cannot be referenced by R_RISCV_JAL.
+ When generating the shared object, the default visibility symbols may bind
+ externally, which means they will be exported to the dynamic symbol table,
+ and are preemptible by default. These symbols cannot be referenced by the
+ non-pic R_RISCV_JAL and R_RISCV_RVC_JUMP. However, consider that linker
+ may relax the R_RISCV_CALL relocations to R_RISCV_JAL or R_RISCV_RVC_JUMP,
+ if these relocations are relocated to the plt entries, then we won't report
+ error for them. Perhaps we also need the similar checks for the
+ R_RISCV_BRANCH and R_RISCV_RVC_BRANCH relocations.
+
+ After applying this patch, and revert the following glibc patch,
+ riscv: Fix incorrect jal with HIDDEN_JUMPTARGET
+ https://sourceware.org/git/?p=glibc.git;a=commit;h=68389203832ab39dd0dbaabbc4059e7fff51c29b
+
+ I get the expected errors as follows,
+ ld: relocation R_RISCV_RVC_JUMP against `__sigsetjmp' which may bind externally can not be used when making a shared object; recompile with -fPIC
+ ld: relocation R_RISCV_JAL against `exit' which may bind externally can not be used when making a shared object; recompile with -fPIC
+
+ Besides, we also have similar changes for libgcc,
+ RISC-V: jal cannot refer to a default visibility symbol for shared object
+ https://github.com/gcc-mirror/gcc/commit/45116f342057b7facecd3d05c2091ce3a77eda59
+
+ bfd/
+ pr 28509
+ * elfnn-riscv.c (riscv_elf_relocate_section): Report errors when
+ makeing a shard object, and the referenced symbols of R_RISCV_JAL
+ relocations are default visibility. Besides, we should handle most
+ of the cases here, so don't need the unresolvable check later for
+ R_RISCV_JAL and R_RISCV_RVC_JUMP.
+ ld/
+ pr 28509
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+ * testsuite/ld-riscv-elf/lib-nopic-01a.s: Removed.
+ * testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
+ * testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-01.d: New testcase.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-01.s: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-02.d: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-02.s: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-03.d: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-03.s: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-04.d: Likewise.
+ * testsuite/ld-riscv-elf/shared-lib-nopic-04.s: Likewise.
+
+2022-09-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix handling of DW_TAG_unspecified_type
+ Currently, the test-case contained in this patch fails:
+ ...
+ (gdb) p (int) foo ()^M
+ Invalid cast.^M
+ (gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
+ ...
+ because DW_TAG_unspecified_type is translated as void.
+
+ There's some code in read_unspecified_type that marks the type as stub, but
+ that's only active for ada:
+ ...
+ if (cu->lang () == language_ada)
+ type->set_is_stub (true);
+ ...
+
+ Fix this by:
+ - marking the type as a stub for all languages, and
+ - handling the stub return type case in call_function_by_hand_dummy.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29558
+
+2022-09-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-10 Alan Modra <amodra@gmail.com>
+
+ Re: PR29466, APP/NO_APP with linefile
+ It looks like I copied the SIZE init across from
+ binutils/testsuite/config/default.exp without some necessary editing.
+
+ * testsuite/config/default.exp (SIZE): Adjust relative path.
+
+2022-09-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-09 Nick Clifton <nickc@redhat.com>
+
+ Support debuginfo files with empty group sections.
+ PR 29532
+ bfd * elf.c (setup_group): Do not return false if there is no group
+ information available.
+
+ bionutils* objcopy.c (setup_section): Leave group sections intact when
+ creating separate debuginfo files.
+
+2022-09-09 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix vector CSR requirements
+ Vector CSRs are also required on smaller vector subsets.
+
+ Not only that the most of vector CSRs are general purpose (and must be
+ accessible for every vector subsets), current minimum vector subset 'Zve32x'
+ requires fixed point arithmetic, making remaining non-general purpose
+ (fixed point arithmetic only) CSRs mandatory for such subsets.
+
+ So, those CSRs must be accessible from 'Zve32x', not just from 'V'.
+ This commit fixes this issue which caused CSR accessibility warnings.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_csr_address): Change vector CSR
+ requirement from 'V' to 'Zve32x'.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Change vector CSR
+ requirement from 'V' to 'Zve32x'.
+ * testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+
+2022-09-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-08 Carl Love <cel@us.ibm.com>
+
+ Fix hardware watchpoint check in test gdb.base/watchpoint-reuse-slot.exp
+ This test generates 48 failures on Power 9 when testing with HW watchpoints
+ enabled. Note HW watchpoint support is disabled on Power 9 due to a HW bug.
+ The skip_hw_watchpoint_tests proc must be used to correctly determine
+ if the processor supports HW watchpoints.
+
+ This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
+ with the skip_hw_watchpoint_tests check.
+
+ This patch was tested on Power 9, Power 10 and X86-64 with no regressions.
+
+2022-09-08 Nick Clifton <nickc@redhat.com>
+
+ Gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)
+ PR 29559
+ * dwarf2dbg.c (out_debug_info): Place DW_TAG_unspecified_type at
+ the end of the list of children, not at the start of the CU
+ information.
+ * testsuite/gas/elf/dwarf-3-func.d: Update expected output.
+ * testsuite/gas/elf/dwarf-5-func-global.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-func-local.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-func.d: Likewise.
+
+2022-09-08 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdbsupport: Fix config.status dependency
+ Commit 171fba11ab27 ("Make GDBserver abort on internal error in development mode")
+ created a new substitution CONFIG_STATUS_DEPENDENCIES but this is used by
+ Makefile.in (which is not regenerated by that commit). After regenerating
+ it, it is found that CONFIG_STATUS_DEPENDENCIES value is not valid, making
+ gdbsupport fail to build.
+
+ Since the CONFIG_STATUS_DEPENDENCIES value is used in the Makefile, macro
+ substitution must have a Makefile format but commit 171fba11ab27 used shell
+ format "$srcdir/../bfd/development.sh".
+
+ This commit fixes this issue by substituting "$srcdir" (shell format) to
+ "$(srcdir)" (Makefile format). It preserves the dependency as Pedro
+ intended and fixes the build problem.
+
+ It also regenerates corresponding files with the maintainer mode.
+
+ gdbsupport/ChangeLog:
+
+ * configure.ac: Fix config.status dependency.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+2022-09-08 Nick Clifton <nickc@redhat.com>
+
+ Maintainer mode: wrong gettext version?
+ * README-maintainer-mode: Update minimum version of gettext
+ required.
+
+ i686-w64-mingw32-objdump -WL returns incorrect file paths
+ PR 29523
+ * dwarf.c (display_debug_lines_decoded): Correctly handle DWARF-5
+ directory and filename tables.
+
+2022-09-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] xfail gdb.ada/O2_float_param.exp for aarch64 and gcc 7.5.0
+ On aarch64-linux, with gcc 7.5.0, we run into:
+ ...
+ (gdb) frame^M
+ #0 callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...) at \
+ callee.adb:21^M
+ 21 if Val > 200.0 then^M
+ (gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: frame
+ ...
+
+ The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location
+ expression for function entry values" (
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148 ).
+
+ Xfail the test for aarch64 and gcc 7.
+
+ Tested on x86_64-linux and aarch64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29418
+
+2022-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64
+ On aarch64-linux, I run into:
+ ...
+ Breakpoint 2, pck.inspect (obj=0x430eb0 \
+ <system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
+ 17 procedure Inspect (Obj: access Top_T'Class) is^M
+ (gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
+ ...
+ while on x86_64-linux, I see:
+ ...
+ Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
+ 19 null;^M
+ (gdb) PASS: gdb.ada/access_tagged_param.exp: continue
+ ...
+ Note the different line numbers, 17 vs 19.
+
+ The difference comes from the gdbarch_skip_prologue implementation.
+
+ The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
+ back to the architecture-specific prologue analyzer, which correctly skips
+ past the prologue, to address 0x4022f7:
+ ...
+ 00000000004022ec <pck__inspect>:
+ 4022ec: 55 push %rbp
+ 4022ed: 48 89 e5 mov %rsp,%rbp
+ 4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp)
+ 4022f4: 89 75 f4 mov %esi,-0xc(%rbp)
+ 4022f7: 90 nop
+ 4022f8: 90 nop
+ 4022f9: 5d pop %rbp
+ 4022fa: c3 ret
+ ...
+
+ The aarch64_skip_prologue implementation does use gcc line numbers, which are:
+ ...
+ File name Line number Starting address View Stmt
+ pck.adb 17 0x402580 x
+ pck.adb 17 0x402580 1 x
+ pck.adb 19 0x40258c x
+ pck.adb 20 0x402590 x
+ ...
+ and which are represented like this internally in gdb:
+ ...
+ INDEX LINE ADDRESS IS-STMT PROLOGUE-END
+ 0 17 0x0000000000402580 Y
+ 1 17 0x0000000000402580 Y
+ 2 19 0x000000000040258c Y
+ 3 20 0x0000000000402590 Y
+ 4 END 0x00000000004025a0 Y
+ ...
+
+ The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
+ the actual end of the prologue is at 0x40258c:
+ ...
+ 0000000000402580 <pck__inspect>:
+ 402580: d10043ff sub sp, sp, #0x10
+ 402584: f90007e0 str x0, [sp, #8]
+ 402588: b90007e1 str w1, [sp, #4]
+ 40258c: d503201f nop
+ 402590: d503201f nop
+ 402594: 910043ff add sp, sp, #0x10
+ 402598: d65f03c0 ret
+ 40259c: d503201f nop
+ ...
+
+ Note that the architecture-specific prologue analyzer would have gotten this
+ right:
+ ...
+ (gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
+ $2 = 0x40258c
+ ...
+
+ Fix the FAIL by making the test-case more robust against problems in prologue
+ skipping, by setting the breakpoint on line 19 instead.
+
+ Likewise in a few similar test-cases.
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2022-09-07 Luis Machado <luis.machado@arm.com>
+ Tom de Vries <tdevries@suse.de>
+
+ Fix endianness handling for arm record self tests
+ v2:
+
+ - Add 32-bit Arm instruction selftest
+ - Refactored abstract memory reader into abstract instruction reader
+ - Adjusted code to use templated type and to use host endianness as
+ opposed to target endianness.
+
+ The arm record tests handle 16-bit and 32-bit thumb instructions, but the
+ code is laid out in a way that handles the 32-bit thumb instructions as
+ two 16-bit parts.
+
+ This is fine, but it is prone to host-endianness issues given how the two
+ 16-bit parts are stored and how they are accessed later on. Arm is
+ little-endian by default, so running this test with a GDB built with
+ --enable-targets=all and on a big endian host will run into the following:
+
+ Running selftest arm-record.
+ Process record and replay target doesn't support syscall number -2036195
+ Process record does not support instruction 0x7f70ee1d at address 0x0.
+ Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-tdep.c:14482
+
+ It turns out the abstract memory reader class is more generic than it needs to
+ be, and we can simplify the code a bit by assuming we have a simple instruction
+ reader that only reads up to 4 bytes, which is the length of a 32-bit
+ instruction.
+
+ Instead of returning a bool, we return instead the instruction that has been
+ read. This way we avoid having to deal with the endianness conversion, and use
+ the host endianness instead. The Arm selftests can be executed on non-Arm
+ hosts.
+
+ While at it, Tom suggested adding a 32-bit Arm instruction selftest to increase
+ the coverage of the selftests.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29432
+
+2022-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use prototype to call libc functions
+ On openSUSE Tumbleweed (using glibc 2.36), I run into:
+ ...
+ (gdb) print /d (int) munmap (4198400, 4096)^M
+ Invalid cast.^M
+ (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \
+ get integer valueof "(int) munmap (4198400, 4096)"
+ ...
+
+ The problem is that after starting the executable, the symbol has type
+ "void (*) (void)":
+ ...
+ (gdb) p munmap
+ $1 = {<text variable, no debug info>} 0x401030 <munmap@plt>
+ (gdb) start
+ ...
+ (gdb) p munmap
+ $2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap>
+ ...
+ which causes the "Invalid cast" error.
+
+ Looking at the debug info for glibc for symbol __GI_munmap:
+ ...
+ <0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit)
+ <189691> DW_AT_name : ../sysdeps/unix/syscall-template.S
+ <189699> DW_AT_producer : GNU AS 2.39.0
+ <1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <1896af> DW_AT_name : __GI___munmap
+ <1896b3> DW_AT_external : 1
+ <1896b4> DW_AT_low_pc : 0x10cad0
+ <1896bc> DW_AT_high_pc : 37
+ ...
+ that's probably caused by this bit (or similar bits for other munmap aliases).
+
+ This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type
+ tag to DWARF DIEs generated for function symbols").
+
+ Work around this (for say gas 2.39) by explicitly specifying the prototype for
+ munmap.
+
+ Likewise for getpid in a couple of other test-cases.
+
+ Tested on x86_64-linux.
+
+2022-09-07 mengqinggang <mengqinggang@loongson.cn>
+
+ LoongArch: fix gas BFD_RELOC_8/16/24 bug
+ If fixP->fx_subsy is NULL, BFD_RELOC_8/16/24 can't convert to
+ BFD_RELOC_LARCH_xxx.
+
+ gas/config/tc-loongarch.c
+
+2022-09-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-06 Aaron Merey <amerey@redhat.com>
+ Nick Clifton <nickc@redhat.com>
+
+ Add debuginfod support for objdump -S
+ Currently objdump -S is not able to make use files downloaded from debuginfod.
+ This is due to bfd_find_nearest_line_discriminator being unable to locate any
+ separate debuginfo files in the debuginfod cache. Additionally objdump lacked
+ a call to debuginfod_find_source in order to download missing source files.
+
+ Fix this by using bfd_find_nearest_line_with_alt instead of
+ bfd_find_nearest_line_discriminator. Also add a call to
+ debuginfod_find_source in order to download missing source files.
+
+2022-09-06 Aaron Merey <amerey@redhat.com>
+
+ bfd: Add bfd_find_nearest_line_with_alt
+ bfd_find_nearest_line_with_alt functions like bfd_find_nearest_line with
+ the addition of a parameter for specifying the filename of a supplementary
+ debug file such as one referenced by .gnu_debugaltlink or .debug_sup.
+
+ This patch focuses on implementing bfd_find_nearest_line_with_alt
+ support for ELF/DWARF2 .gnu_debugaltlink. For other targets this
+ function simply sets the invalid_operation bfd_error.
+
+2022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdb: add Tsukasa Oi to gdb/MAINTAINERS
+
+2022-09-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move a write after approval entry into the correct place
+ Noticed in passing that an entry in the MAINTAINERS write after
+ approval list was in the wrong place.
+
+2022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gdb: Add non-enum disassembler options
+ This is paired with "opcodes: Add non-enum disassembler options".
+
+ There is a portable mechanism for disassembler options and used on some
+ architectures:
+
+ - ARC
+ - Arm
+ - MIPS
+ - PowerPC
+ - RISC-V
+ - S/390
+
+ However, it only supports following forms:
+
+ - [NAME]
+ - [NAME]=[ENUM_VALUE]
+
+ Valid values for [ENUM_VALUE] must be predefined in
+ disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC
+ architecture, opcodes/arc-dis.c builds valid CPU model list from
+ include/elf/arc-cpu.def.
+
+ In this commit, it adds following format:
+
+ - [NAME]=[ARBITRARY_VALUE] (cannot contain "," though)
+
+ This is identified by NULL value of disasm_option_arg_t.values
+ (normally, this is a non-NULL pointer to a NULL-terminated list).
+
+ gdb/ChangeLog:
+
+ * gdb/disasm.c (set_disassembler_options): Add support for
+ non-enum disassembler options.
+ (show_disassembler_options_sfunc): Likewise.
+
+2022-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Support .debug_names section with TUs in .debug_info
+ When running test-case gdb.cp/cpexprs-debug-types.exp on target board
+ cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with
+ a .debug_names section, but no .debug_types section. For dwarf-5, the TUs
+ are no longer put in a separate unit, but instead they're put in the
+ .debug_info section.
+
+ When loading the executable, the .debug_names section is silently ignored
+ because of this check in dwarf2_read_debug_names:
+ ...
+ if (map->tu_count != 0)
+ {
+ /* We can only handle a single .debug_types when we have an
+ index. */
+ if (per_bfd->types.size () != 1)
+ return false;
+ ...
+ which triggers because per_bfd->types.size () == 0.
+
+ The intention of the check is to make sure we don't have more that one
+ .debug_types section, as can happen in a object file (see PR12984):
+ ...
+ $ grep "\.debug_types" 11.s
+ .section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat
+ .section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat
+ ...
+
+ Fix this by:
+ - changing the check condition to "per_bfd->types.size () > 1", and
+ - handling per_bfd->types.size () == 0.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385
+
+2022-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.dwarf2/debug-names-bad-cu-index.exp
+ Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for
+ commit 2fe9a3c41fa ("[gdb/symtab] Fix bad compile unit index complaint").
+
+ Tested on x86_64-linux.
+
+2022-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.dwarf2/debug-names-tu.exp
+ Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler
+ to specify a .debug_names index with the TU list referring to a TU from the
+ .debug_types section.
+
+ This is intended to produce something similar to:
+ ...
+ $ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4
+ $ gdb-add-index -dwarf-5 a.out
+ ...
+
+ Tested on x86_64-linux.
+
+2022-09-06 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ opcodes: Add non-enum disassembler options
+ This is paired with "gdb: Add non-enum disassembler options".
+
+ There is a portable mechanism for disassembler options and used on some
+ architectures:
+
+ - ARC
+ - Arm
+ - MIPS
+ - PowerPC
+ - RISC-V
+ - S/390
+
+ However, it only supports following forms:
+
+ - [NAME]
+ - [NAME]=[ENUM_VALUE]
+
+ Valid values for [ENUM_VALUE] must be predefined in
+ disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC
+ architecture, opcodes/arc-dis.c builds valid CPU model list from
+ include/elf/arc-cpu.def.
+
+ In this commit, it adds following format:
+
+ - [NAME]=[ARBITRARY_VALUE] (cannot contain "," though)
+
+ This is identified by NULL value of disasm_option_arg_t.values
+ (normally, this is a non-NULL pointer to a NULL-terminated list).
+
+ include/ChangeLog:
+
+ * dis-asm.h (disasm_option_arg_t): Update comment of values
+ to allow non-enum disassembler options.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_riscv_disassembler_options): Support
+ non-enum disassembler options on printing disassembler help.
+ * arc-dis.c (print_arc_disassembler_options): Likewise.
+ * mips-dis.c (print_mips_disassembler_options): Likewise.
+
+2022-09-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim/riscv: Complete tidying up with SBREAK
+ This commit removes SBREAK-related references on the simulator as it's
+ renamed to EBREAK in 2016 (the RISC-V ISA, version 2.1).
+
+ sim/ChangeLog:
+
+ * riscv/sim-main.c (execute_i): Use "ebreak" instead of "sbreak".
+
+2022-09-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-04 Andrew Burgess <aburgess@redhat.com>
+
+ sim/erc32: fix gdb with simulator build
+ In commit:
+
+ commit 7b01c1cc1d111ba0afa51e60fa9842d3b971e2d1
+ Date: Mon Apr 4 22:38:04 2022 +0100
+
+ sim: fixes for libopcodes styled disassembler
+
+ changes were made to the simulator source to handle the new libopcodes
+ disassembler styling API.
+
+ Unfortunately, these changes broke building GDB with the erc32 (sparc)
+ simulator, like this:
+
+ ../src/configure --target=sparc-linux
+ make all-gdb
+ ....
+ /usr/bin/ld: ../sim/erc32/libsim.a(interf.o): in function `sim_open':
+ /tmp/build/sim/../../src/sim/erc32/interf.c:247: undefined reference to `fprintf_styled'
+ collect2: error: ld returned 1 exit status
+
+ The problem is that in commit 7b01c1cc1d11 the fprintf_styled function
+ was added into sis.c. This file is only used when building the 'run'
+ binary, that is, the standalone simulator, and is not included in the
+ libsim.a library.
+
+ Now, the obvious fix would be to move fprintf_styled into libsim.a,
+ however, that turns out to be tricky.
+
+ The erc32 simulator currently has two copies of the function run_sim,
+ one in sis.c, and one in interf.c, both of these copies are global.
+
+ Currently, the 'run' binary links fine, though I suspect this might be
+ pure luck. When I tried moving fprintf_styled into interf.c, I ran
+ into multiple-definition (of run_sim) errors. I suspect that by
+ requiring the linker to pull in fprintf_styled from libsim.a I was
+ changing the order in which symbols were loaded, and the linker was
+ now seeing both copies of run_sim, while currently we only see one
+ copy.
+
+ The ideal solution of course, would be to merge the two similar, but
+ slightly different copies of run_sim, and just use the one copy. Then
+ we could safely move fprintf_styled into interf.c too, and all would
+ be good.
+
+ But I don't have time right now to start debugging the erc32
+ simulator, so I wanted a solution that fixes the build without
+ introducing multiple definition errors.
+
+ The easiest solution I think is to just have two copies of
+ fprintf_styled, one in sis.c, and one in interf.c. Unlike run_sim,
+ these two copies are both static, so we will not run into multiple
+ definition issues with this function. The functions themselves are
+ not very big, so it's not a huge amount of duplicate code.
+
+ I am very aware that this is not an ideal solution, and I would
+ welcome anyone who wants to take on fixing the run_sim problem
+ properly, and then cleanup the fprintf_styled duplication.
+
+2022-09-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-02 Max Filippov <jcmvbkbc@gmail.com>
+
+ xtensa: bfd: fix TLS relocations generated for PIE
+ When generating TLS dynamic relocations the existing xtensa BFD code
+ treats linking to a PIE exactly as linking to a shared object, resulting
+ in generation of wrong relocations for TLS entries. Fix that and add
+ tests.
+
+ bfd/
+ * elf32-xtensa.c (elf_xtensa_check_relocs): Use bfd_link_dll
+ instead of bfd_link_pic. Add elf_xtensa_dynamic_symbol_p test
+ when generating GOT entries.
+ (elf_xtensa_relocate_section): Use bfd_link_dll instead of
+ bfd_link_pic.
+ ld/
+ * testsuite/ld-xtensa/tlspie.dd: New file.
+ * testsuite/ld-xtensa/tlspie.rd: New file.
+ * testsuite/ld-xtensa/tlspie.sd: New file.
+ * testsuite/ld-xtensa/tlspie.td: New file.
+ * testsuite/ld-xtensa/xtensa-linux.exp (TLS PIE transitions):
+ New test.
+
+2022-09-02 Max Filippov <jcmvbkbc@gmail.com>
+
+ xtensa: adjust expected output in ld TLS tests
+ objdump output for l32r opcode was changed in commit b3ea76397a07
+ ("opcodes: xtensa: display loaded literal value"), but xtensa linker TLS
+ relaxation tests weren't adjusted accordingly.
+ readelf output was changed in commit 23356397449a ("Adjust readelf's
+ output so that section symbols without a name as shown with their
+ section name."), but xtensa linker TLS relaxation tests weren't adjusted
+ accordingly.
+ Fix expected output changes in xtensa ld TLS relaxation tests.
+
+ ld/
+ * testsuite/ld-xtensa/tlsbin.dd: Adjust expected output for l32r
+ opcodes.
+ * testsuite/ld-xtensa/tlsbin.rd: Adjust expected output to allow
+ for named section symbols.
+ * testsuite/ld-xtensa/tlspic.dd: Adjust expected output for l32r
+ opcodes.
+ * testsuite/ld-xtensa/tlspic.rd: Adjust expected output to allow
+ for named section symbols.
+
+2022-09-02 Frederic Cambus <fred@statdns.com>
+
+ Add OpenBSD ARM Little Endian BFD support.
+ * config.bfd (arm-*-openbsd*): Restore target.
+
+2022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Print highest address (-1) on the disassembler
+ This patch makes possible to print the highest address (-1) and the addresses
+ related to gp which value is -1. This is particularly useful if the highest
+ address space is used for I/O registers and corresponding symbols are defined.
+ Besides, despite that it is very rare to have GP the highest address, it would
+ be nice because we enabled highest address printing on regular cases.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/dis-addr-topaddr.s: New test for the top
+ address (-1) printing.
+ * testsuite/gas/riscv/dis-addr-topaddr-32.d: Likewise.
+ * testsuite/gas/riscv/dis-addr-topaddr-64.d: Likewise.
+ * testsuite/gas/riscv/dis-addr-topaddr-gp.s: New test for
+ GP-relative addressing when GP is the highest address (-1).
+ * testsuite/gas/riscv/dis-addr-topaddr-gp-32.d: Likewise.
+ * testsuite/gas/riscv/dis-addr-topaddr-gp-64.d: Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (struct riscv_private_data): Add `to_print_addr' to
+ enable printing the highest address.
+ (maybe_print_address): Utilize `to_print_addr'.
+ (riscv_disassemble_insn): Likewise.
+
+2022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: PR29342, Fix RV32 disassembler address computation
+ If either the base register is `zero', `tp' or `gp' and XLEN is 32, an
+ incorrectly sign-extended address is produced when printing. This commit
+ fixes this by fitting an address into a 32-bit value on RV32.
+
+ Besides, H. Peter Anvin discovered that we have wrong address computation
+ for JALR instruction (the initial bug is back in 2018). This commit also
+ fixes that based on the idea of Palmer Dabbelt.
+
+ gas/
+ pr29342
+ * testsuite/gas/riscv/lla32.d: Reflect RV32 address computation fix.
+ * testsuite/gas/riscv/dis-addr-overflow.s: New testcase.
+ * testsuite/gas/riscv/dis-addr-overflow-32.d: Likewise.
+ * testsuite/gas/riscv/dis-addr-overflow-64.d: Likewise.
+ opcodes/
+ pr29342
+ * riscv-dis.c (maybe_print_address): Fit address into 32-bit on RV32.
+ (print_insn_args): Fix JALR address by adding EXTRACT_ITYPE_IMM.
+
+2022-09-02 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add address printer tests with ADDIW
+ Address sequences involving ADDIW/C.ADDIW instructions require special
+ handling to sign-extend lower 32-bits of the original result.
+
+ This commit tests whether this sign-extension works.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/dis-addr-addiw.s: New to test the address
+ computation with sign extension as used in ADDIW/C.ADDIW.
+ * testsuite/gas/riscv/dis-addr-addiw-a.d: Test PC sign bit 0.
+ * testsuite/gas/riscv/dis-addr-addiw-b.d: Test PC sign bit 1.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/dis-addr-addiw-a.d: New test.
+ * testsuite/gas/riscv/dis-addr-addiw-b.d: New test.
+ * testsuite/gas/riscv/dis-addr-addiw.s: New test.
+
+2022-09-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-09-01 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ sim: Update mailing list address
+ The commit bf1102165389 "* MAINTAINERS: Perform some obvious fixups."
+ back in 2009 changed the mailing list address gdb-patches@sources.redhat.com
+ to gdb-patches@sourceware.org.
+
+ This commit does the same to sim/MAINTAINERS.
+
+ sim/ChangeLog:
+
+ * MAINTAINERS: Update mailing list address.
+
+ Change-Id: I56c6bf21a4bddfb35ffc3336ffcba7ff9b39926e
+
+2022-09-01 Nick Clifton <nickc@redhat.com>
+
+ dllwrap, windres and dlltools use mktemp, which should be avoided
+ PR 29534
+ * dllwrap.c: Replace uses of choose_temp_base() with
+ make_temp_file().
+ * dlltool.c: Likewise.
+ * resrc.c: Likewise.
+
+2022-09-01 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/doc: Document the Guile `#:unlimited' keyword
+ Document the Guile `#:unlimited' keyword and deprecate the internal
+ integer representation it corresponds to for integer parameters.
+
+2022-09-01 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/python-config: replace deprecated distutils.sysconfig
+ When running the gdb/configure script on ubuntu 22.04 with
+ python-3.10.4, I see:
+
+ checking for python... no
+ checking for python3... /usr/bin/python3
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
+ from distutils import sysconfig
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
+ from distutils import sysconfig
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
+ from distutils import sysconfig
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
+ from distutils import sysconfig
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
+ from distutils import sysconfig
+ [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
+ from distutils import sysconfig
+ checking for python... yes
+
+ The distutils module is deprecated as per the PEP 632[1] and will be
+ removed in python-3.12.
+
+ This patch migrates gdb/python/python-config.py from distutils.sysconfig
+ to the sysconfig module[2].
+
+ The sysconfig module has has been introduced in the standard library in
+ python 3.2. Given that support for python < 3.2 has been removed by
+ edae3fd6600f: "gdb/python: remove Python 2 support", this patch does not
+ need to support both implementations for backward compatibility.
+
+ Tested on ubuntu-22.04 and ubuntu 20.04.
+
+ [1] https://peps.python.org/pep-0632/
+ [2] https://docs.python.org/3/library/sysconfig.html
+
+ Change-Id: Id0df2baf3ee6ce68bd01c236b829ab4c0a4526f6
+
+2022-09-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-31 Tom Tromey <tromey@adacore.com>
+
+ Fix interpreter-exec crash
+ PR mi/10347 points out that using interpreter-exec inside of a
+ "define" command will crash gdb. The bug here is that
+ gdb_setup_readline doesn't check for the case where instream==nullptr.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10347
+
+2022-08-31 Tom Tromey <tromey@adacore.com>
+
+ Fix "source" with interpreter-exec
+ PR mi/15811 points out that "source"ing a file that uses
+ interpreter-exec will put gdb in a weird state, where the CLI stops
+ working. The bug is that tui_interp::suspend does not unregister the
+ event file descriptor.
+
+ The test case is from Andrew Burgess.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15811
+
+2022-08-31 Tom Tromey <tromey@adacore.com>
+
+ Remove a call to clear_interpreter_hooks
+ mi_interp::resume does not need to call clear_interpreter_hooks,
+ because this is already done by interp_set.
+
+ TUI stdout buffering cleanup
+ The TUI checks against gdb_stdout to decide when to buffer. It seems
+ much cleaner to me to simply record this as an attribute of the stream
+ itself.
+
+ Remove a ui-related memory leak
+ gdb_setup_readline makes new streams and assigns to the various stream
+ members of struct ui. However, these assignments cause the previous
+ values to leak. As far as I can, this code is simply unnecessary and
+ can be removed -- with the exception of the assignment to gdb_stdtarg,
+ which is not initialized anywhere else.
+
+ Remove tui_out_new
+ tui_out_new is just a simple wrapper for 'new' and can be removed,
+ simplifying gdb a tiny bit.
+
+ Use scoped_restore in safe_parse_type
+ This changes safe_parse_type to use scoped_restore rather than
+ explicit assignments.
+
+ Use member initialization in 'struct ui'
+ This changes 'struct ui' to use member initialization. This is
+ simpler to understand.
+
+ Remove two unused members from mi_interp
+ These members of mi_interp aren't used and can be removed.
+
+ Remove obsolete filtering comment
+ top.h has an obsolete comment about the use of _unfiltered.
+
+ Remove the "for moment" comments
+ A few spots setting some gdb output stream variables have a "for
+ moment" comment. These comments aren't useful and I think the moment
+ has passed -- these are permanent now.
+
+ Use ui_out_redirect_pop in more places
+ This changes ui_out_redirect_pop to also perform the redirection, and
+ then updates several sites to use this, rather than explicit
+ redirects.
+
+ Free ui::line_buffer
+ A ui initializes its line_buffer, but never calls buffer_free on it.
+ This patch fixes the oversight. I found this by inspection.
+
+ Remove some dead code
+ This patch removes some dead code and an old FIXME. These no longer
+ seem useful, even for documentation purposes.
+
+ Let ui::input_fd be -1
+ This changes gdb so that, if ui::input_fd is set to -1, then it will
+ not be registered with the event loop. This is useful for the DAP
+ support code I wrote, but as it turns out to also be useful to
+ Insight, it seems best to check it in separately.
+
+2022-08-31 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: better support for fflags and frm registers
+ First, some background on the RISC-V registers fflags, frm, and fcsr.
+
+ These three registers all relate to the floating-point status and
+ control mechanism on RISC-V. The fcsr is the floatint-point control
+ status register, and consists of two parts, the flags (bits 0 to 4)
+ and the rounding-mode (bits 5 to 7).
+
+ The fcsr register is just one of many control/status registers (or
+ CSRs) available on RISC-V. The fflags and frm registers are also
+ CSRs. These CSRs are aliases for the relevant parts of the fcsr
+ register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is
+ an alias for bits 5 to 7 of fcsr.
+
+ This means that a user can change the floating-point rounding mode
+ either, by writing a complete new value into fcsr, or by writing just
+ the rounding mode into frm.
+
+ How this impacts on GDB is like this: a target description could,
+ legitimately include all three registers, fcsr, fflags, and frm. The
+ QEMU target currently does this, and this makes sense. The target is
+ emulating the complete system, and has all three CSRs available, so
+ why not tell GDB about this.
+
+ In contrast, the RISC-V native Linux target only has access to the
+ fcsr. This is because the ptrace data structure that the kernel uses
+ for reading and writing floating point state only contains a copy of
+ the fcsr, after all, this one field really contains both the fflags
+ and frm fields, so why carry around duplicate data.
+
+ So, we might expect that the target description for the RISC-V native
+ Linux GDB would only contain the fcsr register. Unfortunately, this
+ is not the case. The RISC-V native Linux target uses GDB's builtin
+ target descriptions by calling riscv_lookup_target_description, this
+ will then add an fpu feature from gdb/features/riscv, either
+ 32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features
+ include an entry for fcsr, fflags, and frm. This means that GDB
+ expects the target to handle reading and writing these registers. And
+ the RISC-V native Linux target currently doesn't.
+
+ In riscv_linux_nat_target::store_registers and
+ riscv_linux_nat_target::fetch_registers only the fcsr register is
+ handled, this means that, for RISC-V native Linux, the fflags and frm
+ registers always show up as <unavailable> - they are present in the
+ target description, but the target doesn't know how to access the
+ registers.
+
+ A final complication relating to these floating pointer CSRs is which
+ target description feature the registers appear in.
+
+ These registers are CSRs, so it would seem sensible that these
+ registers should appear in the CSR target description feature.
+
+ However, when I first added RISC-V target description support, I was
+ using a RISC-V simulator that didn't support any CSRs other than the
+ floating point related ones. This simulator bundled all the float
+ related CSRs into the fpu target feature. This didn't feel completely
+ unreasonable to me, and so I had GDB check for these registers in
+ either target feature.
+
+ In this commit I make some changes relating to how GDB handles the
+ three floating point CSR:
+
+ 1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This
+ means that the default RISC-V target description (which RISC-V native
+ FreeBSD), and the target descriptions created for RISC-V native Linux,
+ will not include these registers. There's nothing stopping some other
+ target (e.g. QEMU) from continuing to include all three of these CSRs,
+ the code in riscv-tdep.c continues to check for all three of these
+ registers, and will handle them correctly if they are present.
+
+ 2. If a target supplied fcsr, but does not supply fflags and/or frm,
+ then RISC-V GDB will now create two pseudo registers in order to
+ emulate the two missing CSRs. These new pseudo-registers do the
+ obvious thing of just reading and writing the fcsr register.
+
+ 3. With the new pseudo-registers we can no longer make use of the GDB
+ register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
+ These will be the numbers used if the target supplies the registers in
+ its target description, but, if GDB falls back to using
+ pseudo-registers, then new, unique numbers will be used. To handle
+ this I've added riscv_gdbarch_tdep::fflags_regnum and
+ riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
+ compare against these fields.
+
+ When adding the pseudo-register support, it is important that the
+ pseudo-register numbers are calculated after the call to
+ tdesc_use_registers. This is because we don't know the total number
+ of physical registers until after this call, and the psuedo-register
+ numbers must follow on from the real (target supplied) registers.
+
+ I've updated some tests to include more testing of the fflags and frm
+ registers, as well as adding a new test.
+
+2022-08-31 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: Add tdesc_found_register function to tdesc API
+ This commit adds a new function to the target description API within
+ GDB. This new function is not used in this commit, but will be used
+ in the next commit, I'm splitting it out into a separate patch for
+ easier review.
+
+ What I want to do in the next commit is check to see if a target
+ description supplied a particular register, however, the register in
+ question could appear in one of two possible features.
+
+ The new function allows me to ask the tdesc_arch_data whether a
+ register was found and assigned a particular GDB register number once
+ all of the features have been checked. I think this is a much simpler
+ solution than adding code such that, while checking each feature, I
+ spot if the register I'm processing is the one I care about.
+
+ No tests here as the new code is not used, but this code will be
+ exercised in the next commit.
+
+2022-08-31 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: improve (and fix) display of frm field in 'info registers'
+ On RISC-V the FCSR (float control/status register) is split into two
+ parts, FFLAGS (the flags) and FRM (the rounding mode). Both of these
+ two fields are part of the FCSR register, but can also be accessed as
+ separate registers in their own right. And so, we have three separate
+ registers, $fflags, $frm, and $fcsr, with the last of these being the
+ combination of the first two.
+
+ Here's how the bits of FCSR are split between FRM and FFLAGS:
+
+ ,--------- FFLAGS
+ |---|
+ 76543210 <----- FCSR
+ |-|
+ '--------------FRM
+
+ Here's how GDB currently displays these registers:
+
+ (gdb) info registers $fflags $frm $fcsr
+ fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
+ frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
+ fcsr 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
+
+ Notice the 'RD' field which is present in both $fflags and $fcsr.
+ This field contains the value of the FRM field, which makes sense when
+ displaying the $fcsr, but makes no sense when displaying $fflags, as
+ the $fflags doesn't include the FRM field.
+
+ Additionally, the $fcsr already includes an FRM field, so the
+ information in 'RD' is duplicated. Consider this:
+
+ (gdb) set $frm = 0x3
+ (gdb) info registers $fflags $frm $fcsr │
+ fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
+ frm 0x3 FRM:3 [RUP (Round up towards +INF)]
+ fcsr 0x60 RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
+
+ See how the 'RD' field in $fflags still displays 0, while the 'RD' and
+ 'FRM' fields in $fcsr show the same information.
+
+ The first change I propose in this commit is to remove the 'RD'
+ field. After this change the output now looks like this:
+
+ (gdb) info registers $fflags $frm $fcsr
+ fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0
+ frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
+ fcsr 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
+
+ Next, I spotted that the text that goes along with the 'FRM' field was
+ not wrapped in the i18n markers for internationalisation, so I added
+ those.
+
+ Next, I spotted that:
+
+ (gdb) set $frm=0x7
+ (gdb) info registers $fflags $frm $fcsr
+ fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
+ frm 0x7 FRM:3 [RUP (Round up towards +INF)]
+ fcsr 0xe0 RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
+
+ Notice that despite being a 3-bit field, FRM masks to 2-bits.
+ Checking the manual I can see that the FRM field is 3-bits, and is
+ defined for all 8 values. That GDB masks to 2-bits is just a bug I
+ think, so I've fixed this.
+
+ Finally, the 'FRM' text for value 0x7 is wrong. Currently we use the
+ text 'dynamic rounding mode' for value 0x7. However, this is not
+ really correct.
+
+ A RISC-V instruction can either encode the rounding mode within the
+ instruction, or a RISC-V instruction can choose to use a global,
+ dynamic rounding mode.
+
+ So, for the rounding-mode field of an _instruction_ the value 0x7
+ indicates "dynamic round mode", the instruction should defer to the
+ rounding mode held in the FRM field of the $fcsr.
+
+ But it makes no sense for the FRM of $fcsr to itself be set to
+ 0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
+ Control and Status Register" of the RISC-V manual, says that a value
+ of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
+ _its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
+ then an illegal instruction exception is raised.
+
+ And so, I propose changing the text for value 0x7 of the FRM field to
+ be "INVALID[7] (Dynamic rounding mode)". We already use the text
+ "INVALID[5]" and "INVALID[6]" for the two other invalid fields,
+ however, I think adding the extra "Dynamic round mode" hint might be
+ helpful.
+
+ I've added a new test that uses 'info registers' to check what GDB
+ prints for the three registers related to this patch. There is one
+ slight oddity with this test - for the fflags and frm registers, the
+ test accepts both the "normal" output (as described above), but also
+ allows these registers to be reported as '<unavailable>'.
+
+ The reason why I accept <unavailable> is that currently, the RISC-V,
+ native Linux target advertises these registers in its target
+ description, but then doesn't support reading or writing of these
+ registers, this results in the registers being reported as
+ unavailable.
+
+ A later patch in this series will address this issue, and will remove
+ this check for <unavailable>.
+
+2022-08-31 Frederic Cambus <fred@statdns.com>
+
+ Add OpenBSD AArch64 GAS support.
+ * configure.tgt (aarch64*-*-openbsd*): Add target.
+
+2022-08-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, dwarf: create symbols for template tags without names
+ The following GDB behavior was also reported as a GDB bug in
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28396
+
+ I will reiterate the problem a bit and give some more information here.
+ This patch closes the above mentioned bug.
+
+ The DWARF 5 standard 2.23 'Template Parameters' reads:
+
+ A template type parameter is represented by a debugging information
+ entry with the tag DW_TAG_template_type_parameter. A template value
+ parameter is represented by a debugging information entry with the tag
+ DW_TAG_template_value_parameter. The actual template parameter entries
+ appear in the same order as the corresponding template formal
+ parameter declarations in the source progam.
+
+ A type or value parameter entry may have a DW_AT_name attribute, whose
+ value is a null-terminated string containing the name of the
+ corresponding formal parameter.
+
+ So the DW_AT_name attribute for DW_TAG_template_type_parameter and
+ DW_TAG_template_value_parameter is optional.
+
+ Within GDB, creating a new symbol from some read DIE usually requires the
+ presence of a DW_AT_name for the DIE (an exception here is the case of
+ unnamed namespaces or the existence of a linkage name).
+
+ This patch makes the presence of the DW_AT_name for template value/type
+ tags optional, similar to the unnamed namespaces.
+
+ For unnamed namespaces dwarf2_name simply returns the constant string
+ CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a
+ case was added to the switch statement calling the
+ unnamed_template_tag_name helper. Within the scope of parent which
+ the template parameter is a child of, the helper counts the position
+ of the template tag within the unnamed template tags and returns
+ '<unnamedNUMBER>' where NUMBER is its position. This way we end up with
+ unique names within the respective scope of the function/class/struct
+ (these are the only currenltly supported template kinds within GDB and
+ usually the compilers) where we discovered the template tags in.
+
+ While I do not know of a way to bring GCC to emit template tags without
+ names there is one for clang/icpx. Consider the following example
+
+ template<typename A, typename B, typename C>
+ class Foo {};
+
+ template<typename, typename B, typename>
+ class Foo;
+
+ int main () {
+ Foo<double, int, float> f;
+ return 0;
+ }
+
+ The forward declaration for 'Foo' with the missing template type names
+ 'A' and 'C' makes clang emit a bunch of template tags without names:
+
+ ...
+ <2><43>: Abbrev Number: 3 (DW_TAG_variable)
+ <44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8)
+ <47> DW_AT_name : (indirect string, offset: 0x63): f
+ <4b> DW_AT_decl_file : 1
+ <4c> DW_AT_decl_line : 8
+ <4d> DW_AT_type : <0x59>
+ ...
+ <1><59>: Abbrev Number: 5 (DW_TAG_class_type)
+ <5a> DW_AT_calling_convention: 5 (pass by value)
+ <5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float>
+ <5f> DW_AT_byte_size : 1
+ <60> DW_AT_decl_file : 1
+ <61> DW_AT_decl_line : 2
+ <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param)
+ <63> DW_AT_type : <0x76>
+ <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param)
+ <68> DW_AT_type : <0x52>
+ <6c> DW_AT_name : (indirect string, offset: 0x6c): B
+ <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param)
+ <71> DW_AT_type : <0x7d>
+ ...
+
+ Befor this patch, GDB would not create any symbols for the read template
+ tag DIEs and thus lose knowledge about them. Breaking at the return
+ statement and printing f's type would read
+
+ (gdb) ptype f
+ type = class Foo<double, int, float> [with B = int] {
+ <no data fields>
+ }
+
+ After this patch GDB does generate symbols from the DWARF (with their
+ artificial names:
+
+ (gdb) ptype f
+ type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
+ <unnamed1> = float] {
+ <no data fields>
+ }
+
+ The same principle theoretically applies to template functions. Also
+ here, GDB would not record unnamed template TAGs but I know of no visual
+ way to trigger and test this changed behavior. Template functions do
+ not emit a '[with...]' list and their name generation also does not
+ suffer from template tags without names. GDB does not check whether or
+ not a template tag has a name in 'dwarf2_compute_name' and thus, the
+ names of the template functions are created independently of whether or
+ not the template TAGs have a DW_TAT_name attribute. A testcase has
+ been added in the gdb.dwarf2 for template classes and structs.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396
+
+2022-08-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, testsuite: adapt function_range expected name
+ When writing a dwarf testcase for some C++ code I wanted to use the
+ MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
+ to extract the bounds of 'main'.
+
+ However, the macro failed as GDB prints the C++ 'main' with its
+ arguments as 'main(int, char**)' or 'main()'.
+
+ The reason for this is that in read.c::dwarf2_compute_name we call
+ c_type_print_args on C++ functions and append their arguments to the
+ function name. This happens to all C++ functions, but is only visible
+ when the function doesn't have a linkage name.
+
+ An example might make this more clear. Given the following code
+
+ >> cat c.cpp
+ int foo (int a, float b)
+ {
+ return 0;
+ }
+
+ int main (int argc, char **argv)
+ {
+ return 0;
+ }
+
+ which is legal in both languages, C and C++, and compiling it with
+ e.g. clang or gcc will make the disassemble command look like:
+
+ >> clang --version
+ clang version 10.0.0-4ubuntu1
+ ...
+ >> clang -O0 -g ./c.cpp
+ >> gdb -q ./a.out -ex "start"
+ ...
+ (gdb) disassemble main
+ Dump of assembler code for function main(int, char**):
+ 0x0000000000401120 <+0>: push %rbp
+ 0x0000000000401121 <+1>: mov %rsp,%rbp
+ ...
+ 0x0000000000401135 <+21>: ret
+ End of assembler dump.
+ (gdb) disassemble foo
+ Dump of assembler code for function _Z3fooif:
+ 0x0000000000401110 <+0>: push %rbp
+ 0x0000000000401111 <+1>: mov %rsp,%rbp
+ ...
+ 0x000000000040111f <+15>: ret
+ End of assembler dump.
+
+ Note, that main is emitted with its arguments while for foo the linkage
+ name is being printed, as also visible in its DWARF:
+
+ >> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
+ <2b> DW_AT_low_pc : 0x401110
+ <33> DW_AT_high_pc : 0x10
+ <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
+ <39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
+ <3d> DW_AT_name : (indirect string, offset: 0x42): foo
+ <41> DW_AT_decl_file : 1
+ <42> DW_AT_decl_line : 1
+ <43> DW_AT_type : <0x9a>
+
+ Now, let's rename the C++ file and compile it as C:
+
+ >> mv c.cpp c.c
+ >> clang -O0 -g ./c.c
+ >> gdb -q ./a.out -ex "start'
+ ...
+ (gdb) disassemble main
+ Dump of assembler code for function main:
+ 0x0000000000401120 <+0>: push %rbp
+ 0x0000000000401121 <+1>: mov %rsp,%rbp
+ ...
+ 0x0000000000401135 <+21>: ret
+ End of assembler dump.
+ (gdb) disassemble foo
+ Dump of assembler code for function foo:
+ 0x0000000000401110 <+0>: push %rbp
+ 0x0000000000401111 <+1>: mov %rsp,%rbp
+ ...
+ 0x000000000040111f <+15>: ret
+ End of assembler dump.
+
+ Note, for foo we did not get a linkage name emitted in DWARF, so
+ it is printed by its name:
+
+ >> objdump --dwarf=info ./a.out | grep foo -A3 -B3
+ <2b> DW_AT_low_pc : 0x401110
+ <33> DW_AT_high_pc : 0x10
+ <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
+ <39> DW_AT_name : (indirect string, offset: 0x37): foo
+ <3d> DW_AT_decl_file : 1
+ <3e> DW_AT_decl_line : 1
+ <3f> DW_AT_prototyped : 1
+
+ To make the macro and proc work with C++ as well, an optional argument
+ list was added to the regex matching the function name in the
+ disassemble command in function_range. This does not change any used
+ behavior as currently, there exists no C++ test using the proc
+ function_range.
+
+2022-08-31 Aaron Merey <amerey@redhat.com>
+
+ gdb/elfread.c: Use bfd filename instead of objfile->original_name
+ The call to debuginfod_debuginfo_query in elf_symfile_read is given
+ objfile->original_name as the filename to print when downloading the
+ objfile's debuginfo.
+
+ In some cases original_name is prefixed with gdb's working directory
+ even though the objfile is not located in the working directory. This
+ causes debuginfod to display the wrong path of the objfile during a download.
+
+ Fix this by using the objfile's bfd filename instead.
+
+2022-08-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-30 Martin Storsjö <martin@martin.st>
+
+ ld: pe: Fix linking against Microsoft import libraries with multiple DLLs
+ Initially, since c6c37250e98f113755e0d787f7070e2ac80ce77e (in 1999),
+ in order to fix linking against Microsoft import libraries, ld did
+ internally rename members of such libraries. At that point, the
+ criteria for being considered a Microsoft import library was that
+ every archive member had the same name (no regard for exactly what
+ that name was).
+
+ This was later amended in 44dbf3639f127af46d569ad96b6242dfbc4c0a89
+ (in 2003) to allow for Microsoft import libraries with intermixed
+ static object files. At this point, the criteria were extended, so
+ that all members following the first member named *.dll either had
+ the exact same member name, or be named *.obj. (Curiously, this would
+ allow members with any name if it precedes the first one named *.dll.)
+
+ In practice, Microsoft style import libraries can contain
+ members for linking against more than one DLL (built by merging
+ multiple regular import libraries into one).
+
+ Instead of trying to do validation of the whole archive before
+ considering it a Microsoft style import library, relax the criteria
+ for doing the member renaming: If an archive member is named *.dll
+ and it contains .idata sections, assume that that member is a
+ Microsoft import file, and apply the renaming scheme.
+
+ This works for imports for any number of DLLs in the same library,
+ intermixed with other static object files (regardless of their
+ names), and vastly simplifies the code.
+
+ LLVM generates Microsoft style import libraries, and Rust builds
+ seem to bundle up multiple import libraries together with some
+ Rust specific static objects. This fixes linking directly against
+ them with ld.bfd.
+
+2022-08-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: add wrapper around result_of and invoke_result
+ When building with Clang 14 (using gcc 12 libstdc++ headers), I get:
+
+ CXX dwarf2/read.o
+ In file included from /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:94:
+ /home/simark/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:142:21: error: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' is deprecated: use 'std::invoke_result' instead [-Werror,-Wdeprecated-declarations]
+ = typename std::result_of<RangeFunction (RandomIt, RandomIt)>::type;
+ ^
+ /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7122:14: note: in instantiation of function template specialization 'gdb::parallel_for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, (lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5)>' requested here
+ = gdb::parallel_for_each (1, per_bfd->all_comp_units.begin (),
+ ^
+ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/type_traits:2597:9: note: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' has been explicitly marked deprecated here
+ { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result");
+ ^
+ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:120:45: note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST'
+ # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
+ ^
+ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:96:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
+ __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
+ ^
+
+ It complains about the use of std::result_of, which is deprecated in
+ C++17 and removed in C++20:
+
+ https://en.cppreference.com/w/cpp/types/result_of
+
+ Given we'll have to transition to std::invoke_result eventually, make a
+ GDB wrapper to mimimc std::invoke_result, which uses std::invoke_result
+ for C++ >= 17 and std::result_of otherwise. This way, it will be easy
+ to remove the wrapper in the future, just replace gdb:: with std::.
+
+ Tested by building with gcc 12 in -std=c++11 and -std=c++17 mode, and
+ clang in -std=c++17 mode (I did not test fully with clang in -std=c++11
+ mode because there are other unrelated issues).
+
+ Change-Id: I50debde0a3307a7bc67fcf8fceefda51860efc1d
+
+2022-08-30 Tom Tromey <tromey@adacore.com>
+
+ Fix flush for sys.stderr
+ GDB overwrites Python's sys.stdout and sys.stderr, but does not
+ properly implement the 'flush' method -- it only ever will flush
+ stdout. This patch fixes the bug. I couldn't find a straightforward
+ way to write a test for this.
+
+ Fix gdb.flush documentation
+ The gdb.flush documentation does not mention the 'stream' argument in
+ the function signature, only in the description. This patch fixes the
+ oversight.
+
+2022-08-30 Nick Clifton <nickc@redhat.com>
+
+ BFD library: Use entry 0 in directory and filename tables of DWARF-5 debug info.
+ PR 29529
+ * dwarf2.c (struct line_info_table): Add new field:
+ use_dir_and_file_0.
+ (concat_filename): Use new field to help select the correct table
+ slot.
+ (read_formatted_entries): Do not skip entry 0.
+ (decode_line_info): Set new field depending upon the version of
+ DWARF being parsed. Initialise filename based upon the setting of
+ the new field.
+
+2022-08-30 Enze Li <enze.li@hotmail.com>
+
+ gdb: update ranged_breakpoint::print_one_detail in comments
+ The print_one_detail_ranged_breakpoint has been renamed to
+ ranged_breakpoint::print_one_detail in this commit:
+
+ commit ec45bb676c9c69c30783bcf35ffdac8280f3b8bc
+ Date: Sat Jan 15 16:34:51 2022 -0700
+
+ Convert ranged breakpoints to vtable ops
+
+ So their comments should be updated as well.
+
+2022-08-30 Nick Clifton <nickc@redhat.com>
+
+ Add a testcase for PR 29494.
+ PR 29494
+ * testsuite/gas/arm/pr29494.s: New test source file.
+ * testsuite/gas/arm/pr29494.d: New test driver.
+
+2022-08-30 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Fix redefinition of "PACKAGE".
+ Running configure and make in binutils-gdb.
+
+ $ ./configure
+ $ make
+ In file included from ./as.h:37,
+ from ./config/loongarch-lex.l:21,
+ from config/loongarch-lex-wrapper.c:20:
+ ./config.h:206: error: “PACKAGE” redefined [-Werror]
+ #define PACKAGE "gas"
+ ...
+
+ gas/config
+ * loongarch-lex-wrapper.c
+
+2022-08-30 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Zmmul' extension in assembler.
+ Three-part patch set from Tsukasa OI to support zmmul in assembler.
+
+ The 'Zmmul' is a RISC-V extension consisting of only multiply instructions
+ (a subset of 'M' which has multiply and divide instructions).
+
+ bfd/
+ * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zmmul' implied by 'M'.
+ (riscv_supported_std_z_ext): Add 'Zmmul' extension.
+ (riscv_multi_subset_supports): Add handling for new instruction class.
+ gas/
+ * testsuite/gas/riscv/attribute-09.d: Updated implicit 'Zmmul' by 'M'.
+ * testsuite/gas/riscv/option-arch-02.d: Likewise.
+ * testsuite/gas/riscv/m-ext.s: New test.
+ * testsuite/gas/riscv/m-ext-32.d: New test (RV32).
+ * testsuite/gas/riscv/m-ext-64.d: New test (RV64).
+ * testsuite/gas/riscv/zmmul-32.d: New expected output.
+ * testsuite/gas/riscv/zmmul-64.d: Likewise.
+ * testsuite/gas/riscv/m-ext-fail-xlen-32.d: New test (failure
+ by using RV64-only instructions in RV32).
+ * testsuite/gas/riscv/m-ext-fail-xlen-32.l: Likewise.
+ * testsuite/gas/riscv/m-ext-fail-zmmul-32.d: New failure test
+ (RV32 + Zmmul but with no M).
+ * testsuite/gas/riscv/m-ext-fail-zmmul-32.l: Likewise.
+ * testsuite/gas/riscv/m-ext-fail-zmmul-64.d: New failure test
+ (RV64 + Zmmul but with no M).
+ * testsuite/gas/riscv/m-ext-fail-zmmul-64.l: Likewise.
+ * testsuite/gas/riscv/m-ext-fail-noarch-64.d: New failure test
+ (no Zmmul or M).
+ * testsuite/gas/riscv/m-ext-fail-noarch-64.l: Likewise.
+ include/
+ * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZMMUL.
+ ld/
+ * testsuite/ld-riscv-elf/attr-merge-arch-01.d: We don't care zmmul in
+ these testcases, so just replaced m by a.
+ * testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-01b.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p0.s: Renamed.
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p1.s: Renamed.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Updated multiply instructions to zmmul.
+
+2022-08-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix assert in set_length
+ When running the included test-case, we run into:
+ ...
+ (gdb) break _start^M
+ read.h:309: internal-error: set_length: \
+ Assertion `m_length == length' failed.^M
+ ...
+
+ The problem is that while there are two CUs:
+ ...
+ $ readelf -wi debug-names-missing-cu | grep @
+ Compilation Unit @ offset 0x0:
+ Compilation Unit @ offset 0x2d:
+ ...
+ the CU table in the .debug_names section only contains the first one:
+ ...
+ CU table:
+ [ 0] 0x0
+ ...
+
+ The incomplete CU table makes create_cus_from_debug_names_list set the size of
+ the CU at 0x0 to the actual size of both CUs combined.
+
+ This eventually leads to the assert, when we read the actual size from the CU
+ header.
+
+ While having an incomplete CU table in a .debug_names section is incorrect,
+ we need a better failure mode than asserting.
+
+ The easiest way to fix this is to set the length to 0 (meaning: unkown) in
+ create_cus_from_debug_names_list.
+
+ This makes the failure mode to accept the incomplete CU table, but to ignore
+ the missing CU.
+
+ It would be nice to instead reject the .debug_names index, and build a
+ complete CU list, but the point where we find this out is well after
+ dwarf2_initialize_objfile, so it looks rather intrusive to restart at that
+ point.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29453
+
+2022-08-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Declare score-*-* target obsolete
+ I tried out the script gdb/gdb_mbuild.sh, and ran into:
+ ...
+ score-elf ...
+ ... configure --target=score-elf
+ ... make score-elf
+ ... run score-elf
+ score-elf: gdb dumped core
+ Terminated
+ ...
+
+ Gdb runs into this internal error in initialize_current_architecture:
+ ...
+ if (! gdbarch_update_p (info))
+ internal_error (__FILE__, __LINE__,
+ _("initialize_current_architecture: Selection of "
+ "initial architecture failed"));
+ ...
+
+ The call to gdbarch_update_p fails because commit 575b4c298a6 ("gdb: Remove
+ support for S+core") removed support for the architecture.
+
+ Fix this by adding score-*-* to the list of obsolete targets in
+ gdb/configure.tgt, such that we're no longer able to build the configuration:
+ ...
+ *** Configuration score-unknown-elf is obsolete.
+ *** Support has been REMOVED.
+ make: *** [Makefile:12806: configure-gdb] Error 1
+ ...
+
+ Also remove the related line from the "Target Instruction Set Architectures"
+ list in gdb/MAINTAINERS, such that gdb/gdb_mbuild.sh no longer tries to build
+ it.
+
+2022-08-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-28 Alan Modra <amodra@gmail.com>
+
+ PR29494 Trailing jump table on ARM
+ out_inc_line_addr and relax_inc_line_addr are passed INT_MAX as
+ line_delta to flag end of section. This filters its way down to
+ size_inc_line_addr and emit_inc_line_addr. Pass line_delta on to
+ scale_addr_delta where it can be used to omit an unaligned opcode
+ error.
+
+ PR 29494
+ * dwarf2dbg.c (scale_addr_delta): Delete unnecessary forward decl.
+ Add line_delta param. Don't print error at end of section, just
+ round the address down.
+ (size_inc_line_addr, emit_inc_line_addr): Adjust calls.
+
+2022-08-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-27 rupothar <rupesh.potharla@amd.com>
+
+ bfd: Fix minor bug in read_indexed_address function.
+ read_indexed_address function is using offset_size instead of
+ addr_size while reading addrx forms.
+
+2022-08-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: fix gdb::optional compilation with C++11 && _GLIBCXX_DEBUG
+ Similar to 911438f9f4 ("gdbsupport: fix array-view compilation with
+ c++11 && _GLIBCXX_DEBUG"), but for gdb::optional.
+
+ I get this error when building with Clang 14 and -std=c++11:
+
+ CXX agent.o
+ In file included from /home/simark/src/binutils-gdb/gdbsupport/agent.cc:20:
+ In file included from /home/simark/src/binutils-gdb/gdbsupport/common-defs.h:210:
+ In file included from /home/simark/src/binutils-gdb/gdbsupport/common-debug.h:23:
+ /home/simark/src/binutils-gdb/gdbsupport/../gdbsupport/gdb_optional.h:213:5: error: use of this statement in a constexpr function is a C++14 extension [-Werror,-Wc++14-extensions]
+ gdb_assert (this->has_value ());
+ ^
+ /home/simark/src/binutils-gdb/gdbsupport/gdb_assert.h:35:3: note: expanded from macro 'gdb_assert'
+ ((void) ((expr) ? 0 : \
+ ^
+
+ Change-Id: If0cf55607fc9dbd1925ccb97cd9abbf8993ff264
+
+2022-08-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change bpstat_print's kind parameter to target_waitkind
+ Change from int to target_waitkind, which is really what is is. While
+ at it, remove some outdated doc. The return value is described by a
+ relatively self-describing enum, not a numerical value like the doc
+ says.
+
+ Change-Id: Id899c853a857c7891c45e5b1639024067d5b59cd
+
+2022-08-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb, gdbsupport: configure: factor out yes/no/auto value checking
+ Factor out the code that checks that a value is yes/no or yes/no/auto.
+ Add two macros to gdbsupport/common.m4 and use them in gdb/configure.ac
+
+ I inspected the changes to configure. Other than whitespace changes, we
+ have some benign changes to the error messages (one of them had an error
+ actually). There are changes to the --enable-source-highlight and
+ --enable-libbacktrace handling, but setting enable_source_highlight /
+ enable_libbacktrace was not really useful anyway, they already had the
+ right value.
+
+ Change-Id: I92587aec36874309e1605e2d60244649f09a757a
+
+2022-08-26 Alan Modra <amodra@gmail.com>
+
+ PR12265, Compiling ld/ fails on Solaris 8
+ The fail was due to -Werror and headers included by dlfcn.h and
+ elf-bfd.h disagreeing about AT_DCACHEBSIZE and other AT_*. Not a
+ serious problem obviously, since release versions of binutils don't
+ enable -Werror and the defines are not used. Anyway, reduce the
+ number of files that might hit this problem by only including dlfcn.h
+ where it is needed.
+
+ PR 12265
+ * sysdep.h: Don't include dlfcn.h here.
+ * plugin.c: Include it here.
+
+2022-08-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ Allow to document user-defined aliases.
+ Compared to the previous version, this version fixes the comments reported by
+ Tom Tromey and ensures that the 'help some-user-documented-alias'
+ shows the alias definition to ensure the user understands this is an
+ alias even if specifically documented.
+
+ When using 'help ALIASNAME', GDB shows the help of the aliased command.
+ This is a good default behaviour.
+
+ However, GDB alias command allows to define aliases with arguments
+ possibly changing or tuning significantly the behaviour of
+ the aliased command. In such a case, showing the help of the aliased
+ command might not be ideal.
+
+ This is particularly true when defining an alias as a set of
+ nested 'with' followed by a last command to launch, such as:
+ (gdb) alias pp10 = with print pretty -- with print elements 10 -- print
+ Asking 'help pp10' shows the help of the 'with' command, which is
+ not particularly useful:
+ (gdb) help pp10
+ with, pp10, w
+ alias pp10 = with print pretty -- with print elements 10 -- print
+ Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING.
+ Usage: with SETTING [VALUE] [-- COMMAND]
+ ....
+
+ Such an alias can now be documented by the user:
+ (gdb) document pp10
+ >Pretty printing an expressiong, printing 10 elements.
+ >Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
+ >See 'help print' for more information.
+ >end
+ (gdb) help pp10
+ alias pp10 = with print pretty -- with print elements 10 -- print
+ Pretty printing an expressiong, printing 10 elements.
+ Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
+ See 'help print' for more information.
+ (gdb)
+
+ When a user-defined alias is documented specifically, help and apropos
+ use the provided alias documentation instead of the documentation of
+ the aliased command.
+
+ Such a documented alias is also not shown anymore in the help of the
+ aliased command, and the alias is not listed anymore in the help
+ of the aliased command. In particular for cases such as pp10 example above,
+ indicating that pp10 is an alias of the 'with' command is confusing.
+
+2022-08-25 Jan-Benedict Glaw <jbglaw@lug-owl.de>
+
+ sim/aarch64: Fix aarch64_get_CPSR_bits() declaration
+ Noticed while doing mass builds with a very recent GCC:
+
+ /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -DWITH_HW=1 -DHAVE_DV_SOCKSER -DDEFAULT_INLINE=0 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wno-error=maybe-uninitialized -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-parameter-type -Wpointer-sign -Wold-style-declaration -Werror -I. -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64 -I../common -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../common -I../../include -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../include -I../../bfd -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../bfd -I../../opcodes -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../opcodes -I../.. -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../gnulib/import -I../../gnulib/import -g -O2 -c -o cpustate.o -MT cpustate.o -MMD -MP -MF .deps/cpustate.Tpo cpustate.c
+ cpustate.c:270:1: error: conflicting types for 'aarch64_get_CPSR_bits' due to enum/integer mismatch; have 'uint32_t(sim_cpu *, FlagMask)' {aka 'unsigned int(struct _sim_cpu *, FlagMask)'} [-Werror=enum-int-mismatch]
+ 270 | aarch64_get_CPSR_bits (sim_cpu *cpu, FlagMask mask)
+ | ^~~~~~~~~~~~~~~~~~~~~
+ In file included from sim-main.h:30,
+ from cpustate.c:28:
+ cpustate.h:310:20: note: previous declaration of 'aarch64_get_CPSR_bits' with type 'uint32_t(sim_cpu *, uint32_t)' {aka 'unsigned int(struct _sim_cpu *, unsigned int)'}
+ 310 | extern uint32_t aarch64_get_CPSR_bits (sim_cpu *, uint32_t);
+ | ^~~~~~~~~~~~~~~~~~~~~
+ cc1: all warnings being treated as errors
+
+2022-08-25 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Ignore protected visibility in shared libraries on Solaris
+ On x86, the PLT entry in executable may be used as function address for
+ functions in shared libraries. If functions are protected, the function
+ address used in executable can be different from the function address
+ used in shared library. This will lead to incorrect run-time behavior
+ if function pointer equality is needed. By default, x86 linker issues
+ an error in this case.
+
+ On Solaris, linker issued an error for
+
+ struct tm *tb = (kind == CPP_time_kind::FIXED ? gmtime : localtime) (&tt);
+
+ where gmtime is a protected function in libc.so. Use gmtime's PLT entry
+ in executable as function address is safe since function pointer equality
+ isn't needed. Ignore protected visibility in shared libraries on Solaris
+ to disable linker error. If function pointer equality is needed, linker
+ will silently generate executable with incorrect run-time behavior on
+ Solaris.
+
+ PR ld/29512
+ * elf32-i386.c (elf_i386_scan_relocs): Ignore protected
+ visibility in shared libraries on Solaris.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+2022-08-25 Nick Clifton <nickc@redhat.com>
+
+ GAS: Add a return type tag to DWARF DIEs generated for function symbols.
+ PR 29517
+ * dwarf2dbg.c (GAS_ABBREV_COMP_UNIT): New defined constant.
+ (GAS_ABBREV_SUBPROG): New defined constant.
+ (GAS_ABBREV_NO_TYPE): New defined constant.
+ (out_debug_abbrev): Use the new defined constants when emitting
+ abbreviation numbers. Generate an abbreviation for an unspecified
+ type.
+ (out_debug_info): Use the new defined constants when referring to
+ abbreviations. Generate a use of the no_type abbreviation.
+ Reference the use when generating DIEs for functions.
+ * testsuite/gas/elf/dwarf-3-func.d: Update to allow for newly
+ extended output from the assembler.
+ * testsuite/gas/elf/dwarf-5-func-global.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-func-local.d: Likewise.
+ * testsuite/gas/elf/dwarf-5-func.d: Likewise.
+
+ GAS: Allow AArch64 pseudo-ops to accept the command line separator character.
+ PR 29519
+ * config/tc-aarch64.c (s_unreq): Use find_end_of_line().
+ (s_aarch64_cpu): Likewise.
+ (s_aarch64_arch): Likewise.
+ (s_aarch64_arch_extension): Likewise.
+ * testsuite/gas/aarch64/pr29519.d: New test driver file.
+ * testsuite/gas/aarch64/pr29519.s: New test source file.
+
+2022-08-25 Palmer Dabbelt <palmer@rivosinc.com>
+
+ gas: NEWS: Add the RISC-V features for 2.39
+
+ gas: NEWS: Add the RISC-V features for 2.38
+
+ gas: NEWS: Add the RISC-V features for 2.37
+
+ gas: NEWS: Add the RISC-V features for 2.36
+
+ gas: NEWS: Add the RISC-V features for 2.35
+
+ gas: NEWS: Add the RISC-V features for 2.31
+
+2022-08-25 Alan Modra <amodra@gmail.com>
+
+ PR11290, avr-ld "out of range error" is confusing
+ Don't overload bfd_reloc_outofrange with what is really a domain error
+ (target at odd address), or an overflow.
+
+ PR 11290
+ * reloc.c (bfd_reloc_other): Correct comment.
+ * elf32-avr.c (avr_final_link_relocate): Return bfd_reloc_other
+ for unaligned reloc target values. Return bfd_reloc_overflow
+ when stubs are too far away and when R_AVR_LDS_STS_16,
+ R_AVR_PORT6, or R_AVR_PORT5 overflow.
+ (elf32_avr_relocate_section): Report more descriptive relocation
+ errors.
+ * bfd-in2.h: Regenerate.
+
+2022-08-25 Martin Storsjö <martin@martin.st>
+
+ ld: pe: Move the return type to a separate line from the function name
+ This fixes the coding style of an old, preexisting function.
+
+2022-08-25 Alan Modra <amodra@gmail.com>
+
+ PR10372, SH: ld test with sim/sh/run fails always
+ PR 10372
+ * testsuite/ld-sh/start.s: Add _start sym. Use trapa 34. Create
+ an alloc .stack section.
+
+2022-08-25 Alan Modra <amodra@gmail.com>
+
+ Re: LoongArch: ld: Fix bug not generate plt when link a dso
+ Fixes loongarch32-elf +FAIL: medium jirl plt
+
+ * testsuite/ld-loongarch-elf/cmodel.exp: Don't run test when
+ no shared library support.
+
+2022-08-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-24 Martin Storsjö <martin@martin.st>
+
+ ld: pe: Make archive member file extension comparisons case insensitive when cross compiling too
+ On Windows, filename_cmp is case insensitive, but when cross compiling
+ with libraries that may contain members with uppercase file names, we
+ should keep those comparisons case insensitive when running the build
+ tools on other OSes too.
+
+ Also make the check for .def consistent with the other ones, fixing
+ out of bounds reads if file names are shorter than 4 characters.
+
+2022-08-24 Richard Earnshaw <rearnsha@arm.com>
+
+ gas: arm: handle multiple .directives on a single line (PR29519)
+ There's been a long-standing bug in the arm backend where
+ target-specific directives did not correctly handle lines with
+ multiple statements. This patch fixes the issue for all the cases
+ I've been able to find.
+
+ It does result in a slight change in behaviour when errors are
+ encountered: where, previously,
+
+ .cpu arm6 bar
+
+ would result in the error "junk at end of line, first unrecognized
+ character is `b'", we now get "unknown cpu `arm6 bar'", which I think
+ is slightly more helpful anyway. Similar errors are generated for
+ other directives.
+
+2022-08-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: new 'maint print frame-id' command
+ When debugging a certain class of GDB bug, I often end up wanting to
+ know what GDB thinks the frame-id is in a particular frame. It's
+ not too hard to pull this from some debug output, but I thought it
+ might be nice if there was a maintenance command that could tell us.
+
+ This commit adds 'maint print frame-id' which prints the frame-id of
+ the currently selected frame. You can also pass a frame level number
+ to find the frame-id for a specific frame.
+
+ There's a new test too.
+
+2022-08-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: ld: Fix bug not generate plt when link a dso
+ Fix the bug that can not generate func@plt
+ when linking a undefined function with cmodel=medium.
+ Add testcase.
+
+ bfd/
+ * elfnn-loongarch.c
+ ld/testsuite/ld-loongarch-elf/
+ * cmodel-libjirl.dd
+ * cmodel.exp
+ * libjirl.s
+
+2022-08-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-23 Alan Modra <amodra@gmail.com>
+
+ SHT_RELR sh_link and sh_info
+ I don't think it makes any sense for a SHT_RELR section to specify a
+ symbol table with sh_link. SHT_RELR relocations don't use symbols.
+ There is no real need to specify sh_info either, SHT_RELR is not for
+ relocatable object files. Anyway, fuzzers of course don't restrict
+ themselves to even half-sensible objects. So they found a hole in
+ objcopy using a non-alloc SHT_RELR in an ET_EXEC. In that case BFD
+ set up the SHT_RELR section as if it were a SHT_REL against the
+ sh_info target section. When it came to reading in the target section
+ relocs, the count was horribly wrong which caused a buffer overflow.
+
+ * elf.c (bfd_section_from_shdr <SHT_RELR>): Always just make a
+ normal section, don't treat it as a reloc section.
+
+2022-08-23 Alan Modra <amodra@gmail.com>
+
+ Re: bfd_elf_set_group_contents assertion
+ Further to commit 7744e3278b9f.
+
+ * elf.c (bfd_elf_set_group_contents): Restrict loc in loop writing
+ contents, and add another assertion.
+
+2022-08-23 Nick Clifton <nickc@redhat.com>
+
+ Add an option to dlltool to allow the creation of deterministic libraries.
+ PR 29489
+ * dlltool.c (deterministic): New variable.
+ (gen_lib_file): If deterministic is true set the
+ BFD_DETERMINISTIC_OUTPUT flag.
+ (usage): Mention --deterministic-libraries and
+ --non-deterministic-libraries.
+ (long_options): Add new options.
+ (main): Parse new options.
+ * doc/binutils.texi: Document the new options.
+ * NEWS: Mention the new feature.
+
+2022-08-23 Nelson Chu <nelson@rivosinc.com>
+
+ binutils: Updated my email address.
+ binutils/
+ * MAINTAINERS (RISC-V): Updated my email address.
+
+2022-08-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-22 Tom Tromey <tromey@adacore.com>
+
+ Implement target async for Windows
+ This implements target async for Windows. The basic idea is to have
+ the worker thread block in WaitForDebugEvent, then notify the event
+ loop when an event is seen. In a few situations, this blocking
+ behavior is undesirable, so the functions passed to do_synchronously
+ are changed to return a boolean indicating which behavior is needed.
+
+2022-08-22 Tom Tromey <tromey@adacore.com>
+
+ Move some Windows operations to worker thread
+ On Windows, certain debugging APIs can only be called from the thread
+ that started (or attached) to the inferior. Also, there is no way on
+ Windows to wait for a debug event in addition to other events.
+ Therefore, in order to implement target async for Windows, gdb will
+ have to call some functions in a worker thread.
+
+ This patch implements the worker thread and moves the necessary
+ operations there. Target async isn't yet implemented, so this patch
+ does not cause any visible changes.
+
+2022-08-22 Tom Tromey <tromey@adacore.com>
+
+ Avoid crash with Ravenscar tasks
+ When using Ravenscar, gdb can crash if the user sets a breakpoint very
+ early in task startup. This happens because gdb thinks the runtime is
+ initialized, but in practice the particular task isn't sufficiently
+ initialized. This patch avoids the issue by turning an assertion into
+ an early return.
+
+ I tested this using the AdaCore internal test suite. I don't know how
+ to test Ravenscar using the FSF test suite.
+
+2022-08-22 Nick Clifton <nickc@redhat.com>
+
+ Fix compile time warning from Clang about error messages not being printed safely.
+
+ Have readelf warn users if it is asked to decode a LLVM bitcode file or a golang object file.
+ * readelf.c (check_magic_number): New function. Checks the magic
+ bytes at the start of a file. If they are not the ELF format
+ magic values, then attempts to generate a helpful error message.
+ (process_file_header): Call check_magic_number.
+
+2022-08-22 Frederic Cambus <fred@statdns.com>
+
+ Add OpenBSD AArch64 Little Endian BFD support.
+ * config.bfd (aarch64-*-openbsd*): Add target.
+
+2022-08-22 tangxiaolin <tangxiaolin@loongson.cn>
+
+ LoongArch: gas: add support using constant variable in instructions.
+ Instructions that can load immediate support using constant
+ variable like ".equ var, 123 li.w/d resgister, var".
+
+ gas/
+ * config/loongarch-parse.y
+ * config/tc-loongarch.c
+
+ Add four testcases.One is a program using constant variable,
+ one test using label is unsupported, and another two test
+ almost instructions that can load immediate.
+
+ gas/
+ * testsuite/gas/loongarch/li.d
+ * testsuite/gas/loongarch/li.s
+ * testsuite/gas/loongarch/imm_ins_label-fail.d
+ * testsuite/gas/loongarch/imm_ins_label-fail.l
+ * testsuite/gas/loongarch/imm_ins_label-fail.s
+ * testsuite/gas/loongarch/imm_ins.d
+ * testsuite/gas/loongarch/imm_ins.s
+ * testsuite/gas/loongarch/imm_ins_32.d
+ * testsuite/gas/loongarch/imm_ins_32.s
+
+2022-08-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-21 Tom Tromey <tom@tromey.com>
+
+ Fix crash in gdbpy_parse_register_id
+ I noticed that gdbpy_parse_register_id would assert if passed a Python
+ object of a type it was not expecting. The included test case shows
+ this crash. This patch fixes the problem and also changes
+ gdbpy_parse_register_id to be more "Python-like" -- it always ensures
+ the Python error is set when it fails, and the callers now simply
+ propagate the existing exception.
+
+2022-08-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-20 Alan Modra <amodra@gmail.com>
+
+ symbols for bfd_simple_get_relocated_section_contents
+ If symbols are provided by the caller of this function they are
+ passed on to bfd_get_relocated_section_contents. No surprises there.
+ It gets a little weird if they are not provided. In that case they
+ are read from the bfd by _bfd_generic_link_add_symbols, and global
+ symbols are added to the generic linker hash table. Global symbols
+ are not added to the linker hash table if symbols *are* provided. Now
+ the linker hash table symbols are not used by the generic
+ bfd_get_relocated_section_conents, and also not by most target
+ versions when called from bfd_simple_get_relocated_section_contents
+ except for symbols like "_gp". So it mostly doesn't matter whether
+ symbols are in the linker hash table, but it's odd that there is a
+ difference. We could always add them, but I'm inclined to think that
+ is unnecessary work so this patch always leaves them out.
+
+ Also, symbols are canonicalized and written into a malloc'd buffer.
+ The buffer isn't freed, see commit 8e16317ca5eb. I don't know whether
+ that matters any more, but in any case I can't see why we need another
+ copy of the symbols when _bfd_generic_link_read_symbols has already
+ cached symbols.
+
+ * simple.c (bfd_simple_get_relocated_section_contents): If not
+ provided, read symbols via bfd_generic_link_read_symbols. Do
+ not create another copy of symbols. Tidy failure exits.
+ Minor tidy of bfd_get_relocated_section_contents and
+ bfd_get_full_section_contents arguments.
+
+2022-08-20 Alan Modra <amodra@gmail.com>
+
+ Re: Missing linking test case for pe dll using a def file
+ Fixes this when cross-compiling from x86_64-linux
+ x86_64-w64-mingw32 +FAIL: compiling shared lib fastcall/stdcall
+
+ * testsuite/ld-pe/pe-run2-def.exp (test_direct2_link_dll_def):
+ Use CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
+
+2022-08-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-19 Patrick Monnerat <patrick@monnerat.net>
+
+ gdb_do_one_event: use integer test syntax
+ Timeout is an int, not a bool.
+
+2022-08-19 Tom Tromey <tom@tromey.com>
+
+ Remove two initialization functions
+ I noticed a couple of initialization functions that aren't really
+ needed, and that currently require explicit calls in gdb_init. This
+ patch removes these functions, simplifying gdb a little.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-08-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE
+ As Luis pointed out here [1], the AArch64 variant of the test doesn't
+ work on systems that use PIE by default. For example, on this Debian
+ 11:
+
+ $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp"
+ gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC
+ /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4'
+
+ This is because entry-value-typedef-aarch64.S was generated on an old
+ system that does not generate position-independent code by default, but
+ the system the test runs on tries to link the test executable as
+ position-independent. Fix this by regenerating the same binary on the
+ same system as the original one, but with -fPIE this time. Do the same
+ for the amd64 binary, although this one was already position-independent
+ so the generated code doesn't change.
+
+ With this patch applied, the test passes on the Debian 11 AArch64
+ system.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html
+
+ Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144
+
+2022-08-19 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, testsuite: Adapt gdb.base/callfuncs.exp for new clang warning.
+ Clang 15.0.0 enabled the warning for deprecated non-prototype functions
+ by default: https://reviews.llvm.org/D122895
+ Callfuncs.exp is impacted and won't run due to new warnings:
+
+ callfuncs.c:339:5: warning: a function declaration without a prototype is
+ deprecated in all versions of C and is not supported in C2x
+ [-Wdeprecated-non-prototype]
+ int t_float_values (float_arg1, float_arg2)
+
+ This patch disables those warnings with -Wno-deprecated-non-prototype.
+ Removing the test for deprecated syntax would also be an option. But I will
+ leave that up for others to decide/implement.
+
+2022-08-19 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, testsuite: Enable testcases that suppress specific warnings, for icc/icx.
+ To cite gdb.exp:
+ Some C/C++ testcases unconditionally pass -Wno-foo as additional
+ options to disable some warning. That is OK with GCC, because
+ by design, GCC accepts any -Wno-foo option, even if it doesn't
+ support -Wfoo. Clang however warns about unknown -Wno-foo by
+ default, unless you pass -Wno-unknown-warning-option as well.
+ We do that here, so that individual testcases don't have to
+ worry about it.
+
+ This patch adds the same option that already exists for clang for icx and
+ adds the equivalent icc option.
+
+2022-08-19 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Handle variadic arguments
+ According to LoongArch ELF ABI specification [1], variadic arguments
+ are passed in GARs in the same manner as named arguments. And after
+ a variadic argument has been passed on the stack, all future arguments
+ will also be passed on the stack, i.e., the last argument register may
+ be left unused due to the aligned register pair rule. long double data
+ tpye is passed in an aligned GAR pair, the first register in the pair
+ is even-numbered.
+
+ [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
+
+2022-08-19 Alan Modra <amodra@gmail.com>
+
+ loongarch64_pei_vec garbage in objcopy'd relocs
+ Like commit a9c09a3667cc, but for loongarch64.
+
+ * coff-loongarch64.c (SWAP_IN_RELOC_OFFSET): Define.
+ (SWAP_OUT_RELOC_OFFSET): Define.
+
+2022-08-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix bug 29479 Collection fails when built without java support
+ gprofng/ChangeLog
+ 2022-08-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29479
+ * libcollector/collector.c: Add #if defined(GPROFNG_JAVA_PROFILING) for
+ java specific code.
+ * libcollector/unwind.c: Likewise.
+
+2022-08-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result
+ Bug 29374 shows this crash:
+
+ $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out
+ ...
+ /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.
+
+ The backtrace is:
+
+ #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51
+ #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217
+ #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040
+ #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091
+ #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485
+ #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529
+ #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235
+ #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332
+ #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365
+ #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889
+ #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559
+ #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887
+ #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390
+ #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116
+ #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079
+ #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198
+
+ The problem is that the type that gets passed down to
+ dwarf_expr_context::fetch_result (the type of a variable of which we're
+ trying to read the entry value) is a typedef whose size has never been
+ computed yet (check_typedef has never been called on it). As we get in
+ the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len`
+ variable is therefore set to 0, instead of the actual type length. We
+ then call allocate_value on subobj_type, which does call check_typedef,
+ so the length of the typedef gets filled in at that point. We end up
+ passing to the copy function a source array view of length 0 and a
+ target array view of length 4, and the assertion fails.
+
+ Fix this by calling check_typedef on both type and subobj_type at the
+ beginning of fetch_result.
+
+ I tried writing a test for this using the DWARF assembler, but I haven't
+ succeeded. It's possible that we need to get into this specific code
+ path (value_of_dwarf_reg_entry and all) to manage to get to
+ dwarf_expr_context::fetch_result with a typedef type that has never been
+ resolved. In all my attempts, the typedef would always be resolved
+ already, so the bug wouldn't show up.
+
+ As a fallback, I made a gdb.dwarf2 test with compiler-generated .S
+ files. I don't particularly like those, but I think it's better than no
+ test. The .cpp source code is the smallest reproducer I am able to make
+ from the reproducer given in the bug (thanks to Pedro for suggestions on
+ how to minimize it further than I had). Since I tested on both amd64
+ and aarch64, I added versions of the test for these two architectures.
+
+ Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374
+
+2022-08-18 Luis Machado <luis.machado@arm.com>
+
+ [aarch64] Remove handling of ADR/ADRP from prologue analyzer
+ As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html,
+ the aarch64 prologue analyzer considers the adrp instruction in the
+ gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue.
+
+ The function has no prologue though, and it only loads the volatile variable
+ from memory. GDB should not skip any instructions in this case.
+
+ Doing some archaeology, it seems handling for adr/adrp in prologues was
+ included with the original aarch64 port. It might've been an oversight.
+
+ In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips
+ a couple instructions and leaves us in a nice spot where the address to the
+ variable "v" is already in w0. But no prologues exists.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29481
+
+2022-08-18 Tom Tromey <tom@tromey.com>
+
+ Change bookmark allocation
+ This changes how bookmarks are allocated and stored, replacing a
+ linked list with a vector and removing some ALL_* iterator macros.
+ Regression tested on x86-64 Fedora 34.
+
+2022-08-18 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ Add test for AArch64 Scalable Vector Extension
+ It exercises a bug that GDB previously had where it would lose track of
+ some registers when the inferior changed its vector length.
+
+ It also checks that the vg register and the size of the z0-z31 registers
+ correctly reflect the new vector length.
+
+2022-08-18 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
+
+ Fix thread's gdbarch when SVE vector length changes
+ When the inferior program changes the SVE length, GDB can stop tracking
+ some registers as it obtains the new gdbarch that corresponds to the
+ updated length:
+
+ Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44
+ 44 res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0);
+ (gdb) print i
+ $2 = 32
+ (gdb) info registers
+ ⋮
+ [ snip registers x0 to x30 ]
+ ⋮
+ sp 0xffffffffeff0 0xffffffffeff0
+ pc 0xaaaaaaaaa8ac 0xaaaaaaaaa8ac <do_sve_ioctl_test+112>
+ cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ]
+ fpsr 0x0 0
+ fpcr 0x0 0
+ vg 0x8 8
+ tpidr 0xfffff7fcb320 0xfffff7fcb320
+ (gdb) next
+ 45 if (res < 0) {
+ (gdb) info registers
+ ⋮
+ [ snip registers x0 to x30 ]
+ ⋮
+ sp 0xffffffffeff0 0xffffffffeff0
+ pc 0xaaaaaaaaa8cc 0xaaaaaaaaa8cc <do_sve_ioctl_test+144>
+ cpsr 0x200000 [ EL=0 BTYPE=0 SS ]
+ fpsr 0x0 0
+ fpcr 0x0 0
+ vg 0x4 4
+ (gdb)
+
+ Notice that register tpidr disappeared when vg (which holds the vector
+ length) changed from 8 to 4. The tpidr register is provided by the
+ org.gnu.gdb.aarch64.tls feature.
+
+ This happens because the code that searches for a new gdbarch to match the
+ new vector length in aarch64_linux_nat_target::thread_architecture doesn't
+ take into account the features present in the target description associated
+ with the previous gdbarch. This patch makes it do that.
+
+ Since the id member of struct gdbarch_info is now unused, it's removed.
+
+2022-08-18 Ralf Habacker <ralf.habacker@freenet.de>
+
+ Missing linking test case for pe dll using a def file.
+ PR 28362
+ * testsuite/ld-pe/pe-run2-def.exp: New file.
+
+2022-08-18 Patrick Monnerat <patrick@monnerat.net>
+
+ gdbsupport/event-loop: add a timeout parameter to gdb_do_one_event
+ Since commit b2d8657, having a per-interpreter event/command loop is not
+ possible anymore.
+
+ As Insight uses a GUI that has its own event loop, gdb and GUI event
+ loops have then to be "merged" (i.e.: work together). But this is
+ problematic as gdb_do_one_event is not aware of this alternate event
+ loop and thus may wait forever.
+
+ A solution is to delegate GUI events handling to the gdb events handler.
+ Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to
+ implement such a delegation. The Tcl notifier spec requires the event wait
+ function to support a timeout parameter. Unfortunately gdb_do_one_event
+ does not feature such a parameter.
+ This timeout cannot be implemented externally with a gdb timer, because
+ it would become an event by itself and thus can cause a legitimate event to
+ be missed if the timeout is 0.
+ Tcl implements "idle events" that are (internally) triggered only when no
+ other event is pending. For this reason, it can call the event wait function
+ with a 0 timeout quite often.
+
+ This patch implements a wait timeout to gdb_do_one_event. The initial
+ pending events monitoring is performed as before without the possibility
+ to enter a wait state. If no pending event has been found during this
+ phase, a timer is then created for the given timeout in order to re-use
+ the implemented timeout logic and the event wait is then performed.
+ This "internal" timer only limits the wait time and should never be triggered.
+ It is deleted upon gdb_do_one_event exit.
+
+ The new parameter defaults to "no timeout" (-1): as it is used by Insight
+ only, there is no need to update calls from the gdb source tree.
+
+2022-08-18 Patrick Monnerat <patrick@monnerat.net>
+
+ gdb: add Patrick Monnerat to gdb/MAINTAINERS
+
+2022-08-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: move / quiesce pre-386 non-16-bit warning
+ Emitting this warning for every insn, including ones having actual
+ errors, is annoying. Introduce a boolean variable to emit the warning
+ just once on the first insn after .arch may have changed the things, and
+ move the warning to output_insn(). (I didn't want to go as far as
+ checking whether the .arch actually turned off the i386 bit, but doing
+ so would be an option.)
+
+ x86: insert "no error" enumerator in i386_error enumeration
+ The value of zero would better not indicate any error, but rather hit
+ the abort() at the top of the consuming switch().
+
+2022-08-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-17 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Fix PARAM_ZUINTEGER reported for PARAM_ZUINTEGER_UNLIMITED
+ Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER
+ in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.
+
+2022-08-17 Alan Modra <amodra@gmail.com>
+
+ bfd_elf_set_group_contents assertion
+ objcopy of broken SHT_GROUP sections shouldn't write garbage.
+
+ * elf.c (bfd_elf_set_group_contents): If number of entries is
+ unexpected, fill out section with zeros.
+
+2022-08-17 Alan Modra <amodra@gmail.com>
+
+ timeout in mmo_get_symbols
+ Fix mmo_get_byte to return a fail-safe value, not just on the first
+ call with a read error but on subsequent calls too.
+
+ * mmo.c (mmo_get_byte): Return the fail-safe value on every
+ call after a read error.
+
+2022-08-17 Alan Modra <amodra@gmail.com>
+
+ mmo.c leak in mmo_make_section
+ * mmo.c (mmo_make_section): Alloc name using bfd_alloc. Use
+ bfd_error_no_memory.
+ (mmo_decide_section): Check for NULL return from mmo_make_section.
+
+2022-08-17 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow in mmo_scan
+ mmo_get_loc needs to handle arbitrary vma and size chunks. Fuzzers
+ found that it wasn't working so well when the end of chunks were
+ getting close to address wrap-around.
+
+ * mmo.c (mmo_get_loc): Make "size" unsigned. Avoid arithmetic
+ overflow when calculating whether range hits an existing chunk.
+
+2022-08-17 Alan Modra <amodra@gmail.com>
+
+ elf.c tidy
+ Swap params of is_note, so they are section, segment like others used
+ in rewrite_elf_program_header. Whitespace fixes, plus wrapping of
+ overlong lines.
+
+2022-08-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-16 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ bfd: Define ___lc_codepage_func prototype for older MinGW-w64
+ In commit 68e80d96a84282d547f3b3c1234c99009521630c, the usage of
+ ___lc_codepage_func was introduced to determine the current encoding.
+
+ Prior to version 9.0 of MinGW-w64, the function prototype for
+ ___lc_codepage_func was missing and trying to build BFD caused the
+ following error:
+
+ error: implicit declaration of function ‘___lc_codepage_func’
+
+ This changeset adds a conditonal definition of
+ ___lc_codepage_func to allow a sucessful build with MinGW-w64.
+
+2022-08-16 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Add MAX_OPERAND_BUFFER_SIZE
+ When displaying operands, invalid opcodes may overflow operand buffer
+ due to additional styling characters. Each style is encoded with 3
+ bytes. Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and
+ increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles
+ in an operand.
+
+ gas/
+
+ PR binutils/29483
+ * testsuite/gas/i386/i386.exp: Run pr29483.
+ * testsuite/gas/i386/pr29483.d: New file.
+ * testsuite/gas/i386/pr29483.s: Likewise.
+
+ opcodes/
+
+ PR binutils/29483
+ * i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New.
+ (obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE.
+ (staging_area): Likewise.
+ (op_out): Likewise.
+
+2022-08-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: fix gdb.arch/riscv-unwind-long-insn.exp on RV64
+ I noticed that the gdb.arch/riscv-unwind-long-insn.exp test was
+ failing when run on a 64-bit RISC-V target.
+
+ The problem was that GDB was failing to stop after a finish command,
+ and was then running to an unexpected location.
+
+ The reason GDB failed to stop at the finish breakpoint was that the
+ frame-id of the inferior, when we reached the finish breakpoint,
+ didn't match the expected frame-id that was stored on the breakpoint.
+
+ The reason for this mismatch was that the assembler code that is
+ included in this test, was written only taking 32-bit RISC-V into
+ account, as a result, the $fp register was being corrupted, and this
+ was causing the frame-id mismatch.
+
+ Specifically, the $fp register would end up being sign-extended from
+ 32 to 64 bits. If the expected $fp value has some significant bits
+ above bit 31 then the computed and expected frame-ids would not match.
+
+ To fix this I propose merging the two .s files into a single .S file,
+ and making use of preprocessor macros to specialise the file for the
+ correct size of $fp. There are plenty of existing tests that already
+ make use of preprocessor macros in assembler files, so I assume this
+ approach is fine.
+
+ Once I'd decided to make use of preprocessor macros to solve the 32/64
+ bit issue, then I figured I might as well merge the two test assembler
+ files, they only differed by a single instruction.
+
+ With this change in place I now see this test fully passing on 32 and
+ 64 bit RISC-V targets.
+
+2022-08-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix breakpoint script output in gdb.mi/mi-break.exp
+ Commit 9db0d8536dbc ("gdb/mi: fix breakpoint script field output") fixed
+ the output of the script key in the MI breakpoint output, from
+
+ script={"print 10","continue"}
+
+ to
+
+ script=["print 10","continue"]
+
+ However, it missed updating this test case, which still tests for the
+ old (broken) form, causing:
+
+ FAIL: gdb.mi/mi-break.exp: mi-mode=main: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
+ FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
+
+ Update the test to expect the new form.
+
+ Change-Id: I174919d4eea53e96d914ca9bd1cf6f01c8de30b8
+
+2022-08-16 Tom Tromey <tromey@adacore.com>
+
+ Use strwinerror in gdb/windows-nat.c
+ When working on windows-nat.c, it's useful to see an error message in
+ addition to the error number given by GetLastError. This patch moves
+ strwinerror from gdbserver to gdbsupport, and then updates
+ windows-nat.c to use it. A couple of minor changes to strwinerror
+ (constify the return type and use the ARRAY_SIZE macro) are also
+ included.
+
+2022-08-16 Tom Tromey <tom@tromey.com>
+
+ Remove register_gdbarch_init
+ This removes the deprecated register_gdbarch_init in favor a default
+ argument to gdbarch_register. Regression tested on x86-64 Fedora 34.
+
+2022-08-16 Alan Modra <amodra@gmail.com>
+
+ PR29495, rewrite_elf_program_header looping
+ This patch, in order of significance:
+ 1) Replaces some macros with inline functions.
+ 2) Those inline functions catch and avoid arithmetic overflows when
+ comparing addresses.
+ 3) When assigning sections to segments (IS_SECTION_IN_INPUT_SEGMENT)
+ use bed->want_p_paddr_set_to_zero to decide whether lma vs p_paddr
+ or vma vs p_vaddr should be tested. When remapping, use the same
+ test, and use is_note rather than the more restrictive
+ IS_COREFILE_NOTE.
+
+ It's important that the later tests not be more restrictive. If they
+ are it can lead to the situation triggered by the testcases, where a
+ section seemingly didn't fit and thus needed a new mapping. It didn't
+ fit the new mapping either, and this repeated until memory exhausted.
+
+ PR 29495
+ * elf.c (SEGMENT_END, SECTION_SIZE, IS_CONTAINED_BY_VMA): Delete.
+ (IS_CONTAINED_BY_LMA, IS_NOTE, IS_COREFILE_NOTE): Delete.
+ (segment_size, segment_end, section_size): New inline function.
+ (is_contained_by, is_note): Likewise.
+ (rewrite_elf_program_header): Use new functions.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: shorten certain template names
+ Now that we can purge templates, let's use this to improve readability a
+ little by shortening a few of their names, making functionally similar
+ ones also have identical names in their multiple incarnations.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: template-ize certain vector conversion insns
+ Many of the vector conversion insns come with X/Y/Z suffixed forms, for
+ disambiguation purposes in AT&T syntax. All of these gorups follow
+ certain patterns. Introduce "xy" and "xyz" templates to reduce
+ redundancy.
+
+ To facilitate using a uniform name for both AVX and AVX512, further
+ introduce a means to purge a previously defined template: A standalone
+ <name> will be recognized to have this effect.
+
+ Note that in the course of the conversion VFPCLASSPH is properly split
+ to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D} and
+ yielding the intended "ambiguous operand size" diagnostic in Intel mode.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: template-ize vector packed byte/word integer insns
+ Many of the vector integer insns come in byte/word element pairs. Most
+ of these pairs follow certain encoding patterns. Introduce a "bw"
+ template to reduce redundancy.
+
+ Note that in the course of the conversion
+ - the AVX VPEXTRW template which is not being touched needs to remain
+ ahead of the new "combined" ones, as (a) this should be tried first
+ when matching insns against templates and (b) its Load attributes
+ requires it to be first,
+ - this add a benign/meaningless IgnoreSize attribute to the memory form
+ of PEXTRB; it didn't seem worth avoiding this.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-order AVX512 S/G templates
+ The AVX2 gather ones are nicely grouped - do the same for the various
+ AVX512 scatter/gather ones. On the moved lines also convert EVex=<n> to
+ EVex<N>.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: template-ize vector packed dword/qword integer insns
+ Many of the vector integer insns come in dword/qword element pairs. Most
+ of these pairs follow certain encoding patterns. Introduce a "dq"
+ template to reduce redundancy.
+
+ Note that in the course of the conversion
+ - a few otherwise untouched templates are moved, so they end up next to
+ their siblings),
+ - drop an unhelpful Cpu64 from the GPR form of VPBROADCASTQ, matching
+ what we already have for KMOVQ - the diagnostic is better this way for
+ insns with multiple forms (i.e. the same Cpu64 attributes on {,V}MOVQ,
+ {,V}PEXTRQ, and {,V}PINSRQ are useful to keep),
+ - this adds benign/meaningless IgnoreSize attributes to the GPR forms of
+ KMOVD and VPBROADCASTD; it didn't seem worth avoiding this.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ x86: template-ize packed/scalar vector floating point insns
+ The vast majority of vector FP insns comes in single/double pairs. Many
+ pairs follow certain encoding patterns. Introduce an "sd" template to
+ reduce redundancy. Similarly, to further cover similarities between
+ AVX512F and AVX512-FP16, introduce an "sdh" template.
+
+ For element-size Disp8 shift generalize i386-gen's broadcast size
+ determination, allowing Disp8MemShift to be specified without an operand
+ in the affected templated templates. While doing the adjustment also
+ eliminate an unhelpful (lost information) diagnostic combined with a use
+ after free in what is now get_element_size().
+
+ Note that in the course of the conversion
+ - the AVX512F form of VMOVUPD has a stray (leftover) Load attribute
+ dropped,
+ - VMOVSH has a benign IgnoreSize added (the attribute is still strictly
+ necessary for VMOVSD, and necessary for VMOVSS as long as we permit
+ strange combinations like "-march=i286+avx"),
+ - VFPCLASSPH is properly split to separate AT&T and Intel syntax forms,
+ matching VFPCLASSP{S,D}.
+
+2022-08-16 Jan Beulich <jbeulich@suse.com>
+
+ revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"
+ This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which
+ broke i386-gen's emitting of diagnostics. As a replacement to address
+ the original issue of newer gcc no longer splicing lines when dropping
+ the line continuation backslashes, switch to using + as the line
+ continuation character, doing the line splicing in i386-gen.
+
+2022-08-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-15 Alan Modra <amodra@gmail.com>
+
+ PR29362, some binutils memory leaks
+ 2022-08-16 Alan Modra <amodra@gmail.com>
+ Cunlong Li <shenxiaogll@163.com>
+
+ PR 29362
+ * dwarf.c (free_debug_information): New function, extracted..
+ (free_debug_memory): ..from here.
+ (process_debug_info): Use it when before clearing out unit
+ debug_information. Clear all fields.
+ * objcopy.c (delete_symbol_htabs): New function.
+ (main): Call it via xatexit.
+ (copy_archive): Free "dir".
+ * objdump.c (free_debug_section): Free reloc_info.
+
+2022-08-15 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky add unwinder for sigtramp frame when kernel 4.x and later
+ When kernel veriosn >= V4.x, the characteristic values used to
+ determine whether it is a signal function call are:
+ movi r7, 139
+ trap 0
+
+ Registers are saved at (sp + CSKY_SIGINFO_OFFSET + CSKY_SIGINFO_SIZE
+ + CSKY_UCONTEXT_SIGCONTEXT + CSKY_SIGCONTEXT_PT_REGS_TLS). The order
+ is described in csky_linux_rt_sigreturn_init_pt_regs.
+
+2022-08-15 Alan Modra <amodra@gmail.com>
+
+ aarch64_pei_vec
+ I know this target is just a skeleton, but let's not write out relocs
+ with uninitialised garbage.
+
+ * coff-aarch64.c (SWAP_IN_RELOC_OFFSET): Define.
+ (SWAP_OUT_RELOC_OFFSET): Define.
+
+2022-08-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: improve a comment about fcsr, fflags, and frm registers
+ There's a comment in riscv-tdep.c that explains some of the background
+ about how we check for the fcsr, fflags, and frm registers within a
+ riscv target description.
+
+ This comment (and the functionality it describes) relates to how QEMU
+ advertises these registers within its target description.
+
+ Unfortunately, QEMU includes these three registers in both the fpu and
+ crs target description features. To work around this GDB uses one of
+ the register declarations, and ignores the other, this means the GDB
+ user sees a single copy of each register, and things just work.
+
+ When I originally wrote the comment I thought it didn't matter which
+ copy of the register GDB selected, the fpu copy or the csr copy, so
+ long as we just used one of them. The comment reflected this belief.
+
+ Upon further investigation, it turns out I was wrong. GDB has to use
+ the csr copy of the register. If GDB tries to use the register from
+ the fpu feature then QEMU will return an error when GDB tries to read
+ or write the register.
+
+ Luckily, the code within GDB (currently) will always select the csr
+ copy of the register, so nothing is broken, but the comment is wrong.
+ This commit updates the comment to better describe what is actually
+ going on.
+
+ Of course, I should probably also send a patch to QEMU to fix up the
+ target description that is sent to GDB.
+
+2022-08-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/nds32: update features/nds32.c
+ After this commit:
+
+ commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921
+ Date: Wed Sep 15 10:10:46 2021 +0200
+
+ [bfd] Ensure unique printable names for bfd archs
+
+ The printable name field of the default nds32 bfd_arch_info changed
+ from 'n1h' to 'n1'. As a consequence the generated feature file
+ within GDB should have been recreated. Recreate it now.
+
+2022-08-14 Tom Tromey <tom@tromey.com>
+
+ Move decode_location_spec to code_breakpoint
+ breakpoint::decode_location_spec just asserts if called. It turned
+ out to be relatively easy to remove this method from breakpoint and
+ instead move the base implementation to code_breakpoint.
+
+ Change location_spec_to_sals to a method
+ location_spec_to_sals is only ever called for code breakpoints, so
+ make it a protected method there.
+
+ Change breakpoint_re_set_default to a method
+ breakpoint_re_set_default is only ever called from breakpoint re_set
+ methods, so make it a protected method on code_breakpoint.
+
+2022-08-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-13 Alan Modra <amodra@gmail.com>
+
+ PR29482 - strip: heap-buffer-overflow
+ PR 29482
+ * coffcode.h (coff_set_section_contents): Sanity check _LIB.
+
+ asan: NULL dereference in spu_elf_object_p
+ * elf32-spu.c (spu_elf_object_p): Don't dereference NULL
+ shdr->bfd_section.
+
+ ubsan: undefined shift in sign_extend
+ * libhppa.h (sign_extend): Avoid undefined behaviour.
+
+ asan: NULL dereference in som_set_reloc_info
+ * som.c (som_set_reloc_info): Ignore non-existent previous
+ fixup references.
+
+ readelf: print 0x0 as 0, and remove trailing spaces
+ This changes readelf output a little, removing the 0x prefix on hex
+ output when the value is 0, except in cases where a fixed field
+ width is shown. %#010x is not a good replacement for 0x%08x.
+
+ Make dwarf_vma uint64_t
+ This replaces dwarf_vma, dwarf_size_type and dwarf_signed_vma with
+ uint64_t and int64_t everywhere. The patch also gets rid of
+ DWARF_VMA_FMT since we can't use that with uint64_t, and all of the
+ configure support for deciding the flavour of HOST_WIDEST_INT.
+ dwarf_vmatoa also disappears, replacing most uses with one of
+ PRIx64, PRId64 or PRIu64. Printing of size_t and ptrdiff_t values
+ now use %z and %t rather than by casting to unsigned long. Also,
+ most warning messages that used 0x%lx or similar now use %#lx and a
+ few that didn't print the 0x hex prefix now also use %#. The patch
+ doesn't change normal readelf output, except in odd cases where values
+ previously might have been truncated.
+
+ Don't use bfd_vma in readelf.c
+ This replaces bfd_vma with uint64_t in readelf, defines BFD64
+ unconditionally, removes tests of BFD64 and sizeof (bfd_vma), and
+ removes quite a few now unnecessary casts.
+
+ Don't use bfd_size_type in readelf.c and dwarf.c
+ Replacing bfd_size_type with dwarf_size_type or uint64_t is mostly
+ cosmetic. The point of the change is to avoid use of a BFD type
+ in readelf, where we'd like to keep as independent of BFD as
+ possible. Also, the patch is a step towards using standard types.
+
+ Replace elf_vma with uint64_t
+ This patch replaces all uses of elf_vma with uint64_t, removes
+ tests of sizeof (elf_vma), and does a little tidying of
+ byte_get_little_endian and byte_get_big_endian.
+
+2022-08-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
+ When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
+ have:
+ ...
+ (gdb) break compdir_missing__ldir_missing__file_basename^M
+ Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Breakpoint 2, 0x00000000004004c4 in \
+ compdir_missing__ldir_missing__file_basename () \
+ at tmp-dw2-dir-file-name.c:999^M
+ (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
+ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
+ compdir_missing__ldir_missing__file_basename
+ ...
+
+ When trying to set a breakpoint on
+ compdir_missing__ldir_missing__file_basename, the architecture-specific
+ prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
+ ...
+ 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
+ 4004c0: 55 push %rbp
+ 4004c1: 48 89 e5 mov %rsp,%rbp
+ 4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
+ 4004ca: 83 c0 01 add $0x1,%eax
+ 4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
+ 4004d3: 90 nop
+ 4004d4: 5d pop %rbp
+ 4004d5: c3 ret
+ ...
+
+ And because the line table info is rudamentary:
+ ...
+ CU: tmp-dw2-dir-file-name.c:
+ File name Line number Starting address View Stmt
+ tmp-dw2-dir-file-name.c 999 0x4004c0 x
+ tmp-dw2-dir-file-name.c 1000 0x4004d6 x
+ tmp-dw2-dir-file-name.c - 0x4004d6
+ ...
+ the address does not fall at an actual line, so the breakpoint is shown with
+ address, both when setting it and hitting it.
+
+ when running the test-case with aarch64-linux, we have similarly:
+ ...
+ (gdb) break compdir_missing__ldir_missing__file_basename^M
+ Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
+ ...
+ due to the architecture-specific prologue skipper starting at 0x400610 and
+ skipping past two insns, to 0x400618:
+ ...
+ 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
+ 400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
+ 400614: 9100b000 add x0, x0, #0x2c
+ 400618: b9400000 ldr w0, [x0]
+ 40061c: 11000401 add w1, w0, #0x1
+ 400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
+ 400624: 9100b000 add x0, x0, #0x2c
+ 400628: b9000001 str w1, [x0]
+ 40062c: d503201f nop
+ 400630: d65f03c0 ret
+ ...
+
+ But interestingly, the aarch64 architecture-specific prologue skipper is
+ wrong. There is no prologue, and the breakpoint should be set at 0x400610.
+
+ By using "break *compdir_missing__ldir_missing__file_basename"
+ we can get the breakpoint set at 0x400610:
+ ...
+ (gdb) break *compdir_missing__ldir_missing__file_basename^M
+ Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
+ ...
+ and make the test-case independent of prologue analysis.
+
+ This requires us to update the expected patterns.
+
+ The fix ensures that once the aarch64 architecture-specific prologue skipper
+ will be fixed, this test-case won't start failing.
+
+ Tested on x86_64-linux.
+
+2022-08-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-11 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/varobj: Only re-evaluate invalid globals during re_set
+ When doing varobj_re_set, we currently try to recreate floating varobj.
+ This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
+ of varobj_invalidate" to deal with use a after free issue. However
+ since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
+ never have dangling pointers so this all recreation is not strictly
+ needed anymore for floating varobjs.
+
+ This commit proposes to remove this recreation process for floating
+ varobjs.
+
+ Tested on x86_64-linux.
+
+2022-08-11 Tom de Vries <tdevries@suse.de>
+ Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/varobj: Reset varobj after relocations have been computed
+ [This patch is a followup to the discussion in
+ https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]
+
+ PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
+ test when using a compiler which does not produce a PIE executable by
+ default.
+
+ In the testcase, a varobj is created to track a global variable, and
+ then the main binary is reloaded in GDB (using the file command).
+
+ During the load of the new binary, GDB tries to recreate the varobj to
+ track the global in the new binary (varobj_invalidate_iter). At this
+ point, the old process is still in flight. So when we try to access to
+ the value of the global, in a PIE executable we only have access to the
+ unrelocated address (the objfile's text_section_offset () is 0). As a
+ consequence down the line read_value_memory fails to read the unrelated
+ address, so cannot evaluate the value of the global. Note that the
+ expression used to access to the global’s value is valid, so the varobj
+ can be created. When using a non PIE executable, the address of the
+ global GDB knows about at this point does not need relocation, so
+ read_value_memory can access the (old binary’s) value.
+
+ So at this point, in the case of a non-PIE executable the value field is
+ set, while it is cleared in the case of PIE executable. Later when the
+ test issues a "-var-update global_var", the command sees no change in
+ the case of the non-PIE executable, while in the case of the PIE
+ executable install_new_value sees that value changes, leading to a
+ different output.
+
+ This patch makes sure that, as we do for breakpoints, we wait until
+ relocation has happened before we try to recreate varobjs. This way we
+ have a consistent behavior between PIE and non-PIE binaries.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
+
+2022-08-11 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/varobj: Do not invalidate locals in varobj_invalidate_iter
+ The varobj_invalidate_iter function has logic to invalidate any local
+ varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use
+ after free in varobj" all varobj containing references to an objfile are
+ cleared when the objfile goes out of scope. This means that at this
+ point any local varobj seen by varobj_invalidate_iter either has
+ already been invalidated by varobj_invalidate_if_uses_objfile or only
+ contains valid references and there is no reason to invalidate it.
+
+ This patch proposes to remove this unnecessary invalidation and adds a
+ testcase which exercises a scenario where a local varobj can legitimately
+ survive a call to varobj_invalidate_iter.
+
+ At this point the varobj_invalidate and varobj_invalidate_iter seem
+ misnamed since they deal with re-creating invalid objects and do not do
+ invalidation, but this will be fixed in a following patch.
+
+ Tested on x86_64-linux.
+
+2022-08-11 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ ppc/svp64: support svindex instruction
+ https://libre-soc.org/openpower/sv/
+ https://libre-soc.org/openpower/sv/remap/#svindex
+ https://libre-soc.org/openpower/isa/simplev/
+
+ ppc/svp64: support svremap instruction
+ https://libre-soc.org/openpower/sv/
+ https://libre-soc.org/openpower/sv/remap/#svremap
+ https://libre-soc.org/openpower/isa/simplev/
+
+ ppc/svp64: support svshape instruction
+ https://libre-soc.org/openpower/sv/
+ https://libre-soc.org/openpower/sv/remap/#svshape
+ https://libre-soc.org/openpower/isa/simplev/
+
+ ppc/svp64: support svstep instructions
+ https://libre-soc.org/openpower/sv/
+ https://libre-soc.org/openpower/sv/svstep/
+ https://libre-soc.org/openpower/isa/simplev/
+
+ ppc/svp64: support setvl instructions
+ https://libre-soc.org/openpower/sv/
+ https://libre-soc.org/openpower/sv/setvl/
+ https://libre-soc.org/openpower/isa/simplev/
+
+ ppc/svp64: introduce non-zero operand flag
+ svstep and svshape instructions subtract 1 before encoding some of the
+ operands. Obviously zero is not supported for these operands. Whilst
+ PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be
+ incremented, there is no flag which marks the fact that zero values are
+ not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this
+ purpose.
+
+2022-08-11 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ ppc/svp64: support LibreSOC architecture
+ This patch adds support for LibreSOC machine and SVP64 extension flag
+ for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm
+ Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit
+ Prefixed instruction format implementing SV. Funded by NLnet through EU
+ Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly
+ submitted via the OpenPOWER Foundation ISA Working Group via the
+ newly-created External RFC Process.
+
+ For more details, visit https://libre-soc.org.
+
+2022-08-11 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ [Arm] Cleanup arm_m_exception_cache
+ With this change, only valid contents of LR are accepted when unwinding
+ exception frames for m-profile targets.
+
+ If the contents of LR are anything but EXC_RETURN or FNC_RETURN, it
+ will cause GDB to print an error and/or abort unwinding of the frame as
+ it's an invalid state for the unwinder.
+
+ The FNC_RETURN pattern requires Security Extensions to be enabled.
+
+2022-08-11 Fangrui Song <maskray@google.com>
+
+ RISC-V: Remove R_RISCV_GNU_VTINHERIT/R_RISCV_GNU_VTENTRY
+ They were legacy relocation types copied from other ports. The related
+ -fvtable-gc was removed from GCC in 2003.
+
+ The associated assembler directives (.vtable_inherit and .vtable_entry)
+ have never been supported by the RISC-V port. Remove related ld code.
+
+ Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/323
+
+2022-08-11 Alan Modra <amodra@gmail.com>
+
+ PR29466, APP/NO_APP with .linefile
+ Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could
+ result in losing input. If scrubbing results in expansion past the
+ holding capacity of do_scrub_chars output buffer, then do_scrub_chars
+ stashes the extra input for the next call. That call never came
+ because sb_scrub_and_add_sb wrongly decided it was done. Fix that by
+ allowing sb_scrub_and_add_sb to see whether there is pending input.
+ Also allow a little extra space so that in most cases we won't need
+ to resize the output buffer.
+
+ sb_scrub_and_add_sb also limited output to the size of the input,
+ rather than the actual output buffer size. Fixing that resulted in a
+ fail of gas/testsuite/macros/dot with an extra warning: "end of file
+ not at end of a line; newline inserted". OK, so the macro in dot.s
+ really does finish without end-of-line. Apparently the macro
+ expansion code relied on do_scrub_chars returning early. So fix that
+ too by adding a newline if needed in macro_expand_body.
+
+ PR 29466
+ * app.c (do_scrub_pending): New function.
+ * as.h: Declare it.
+ * input-scrub.c (input_scrub_include_sb): Add extra space for
+ two .linefile directives.
+ * sb.c (sb_scrub_and_add_sb): Take into account pending input.
+ Allow output to max.
+ * macro.c (macro_expand_body): Add terminating newline.
+ * testsuite/config/default.exp (SIZE, SIZEFLAGS): Define.
+ * testsuite/gas/macros/app5.d,
+ * testsuite/gas/macros/app5.s: New test.
+ * testsuite/gas/macros/macros.exp: Run it.
+
+2022-08-11 Alan Modra <amodra@gmail.com>
+
+ regen potfiles
+
+2022-08-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/mi: fix breakpoint script field output
+ The "script" field, output whenever information about a breakpoint with
+ commands is output, uses wrong MI syntax.
+
+ $ ./gdb -nx -q --data-directory=data-directory -x script -i mi
+ =thread-group-added,id="i1"
+ =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"}
+ =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}
+ (gdb)
+ -break-info
+ ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]}
+ (gdb)
+
+ In both the =breakpoint-modified and -break-info output, we have:
+
+ script={"aaa","bbb","ccc"}
+
+ According to the output syntax [1], curly braces means tuple, and a
+ tuple contains key=value pairs. This looks like it should be a list,
+ but uses curly braces by mistake. This would make more sense:
+
+ script=["aaa","bbb","ccc"]
+
+ Fix it, keeping the backwards compatibility by introducing a new MI
+ version (MI4), in exactly the same way as was done when fixing
+ multi-locations breakpoint output in [2].
+
+ - Add a fix_breakpoint_script_output uiout flag. MI uiouts will use
+ this flag if the version is >= 4.
+ - Add a fix_breakpoint_script_output_globally variable and the
+ -fix-breakpoint-script-output MI command to set it, if frontends want
+ to use the fixed output for this without using the newer MI version.
+ - When emitting the script field, use list instead of tuple, if we want
+ the fixed output (depending on the two criteria above)
+ -
+
+ [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
+ [2] https://gitlab.com/gnutools/binutils-gdb/-/commit/b4be1b0648608a2578bbed39841c8ee411773edd
+
+ Change-Id: I7113c6892832c8d6805badb06ce42496677e2242
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285
+
+2022-08-10 Andrew Burgess <aburgess@redhat.com>
+
+ objdump: fix extended (256) disassembler colors
+ After commit:
+
+ commit a88c79b77036e4778e70d62081c3cfd1044bb8e3
+ Date: Tue Aug 9 14:57:48 2022 +0100
+
+ Default to enabling colored disassembly if output is to a terminal.
+
+ The 256 extended-color support for --disassembler-color was broken.
+ This is fixed in this commit.
+
+ PR 29457
+ * objdump (objdump_styled_sprintf): Check disassembler_color
+ against an enum value, don't treat it as a bool.
+
+2022-08-10 mga-sc <mark.goncharov@syntacore.com>
+
+ gdb/riscv: implement cannot_store_register gdbarch method
+ The x0 (zero) register is read-only on RISC-V. Implement the
+ cannot_store_register gdbarch method to tell GDB this.
+
+ Without this method GDB will try to write to x0, and relies on the
+ target to ignore such writes. If you are using a target that
+ complains (or throws an error) when writing to x0, this change will
+ prevent this from happening.
+
+ The gdb.arch/riscv-reg-aliases.exp test exercises writing to x0, and
+ will show the errors when using a suitable target.
+
+2022-08-10 Luis Machado <luis.machado@arm.com>
+
+ Disable year 2038 support on 32-bit hosts by default
+ With a recent import of gnulib, code has been pulled that tests and enables
+ 64-bit time_t by default on 32-bit hosts that support it.
+
+ Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
+ doesn't do these checks.
+
+ As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
+ have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
+
+ This will lead to mismatches in the struct stat size, leading to memory
+ corruption and crashes.
+
+ This patch disables the year 2038 check for now, which makes things work
+ reliably again.
+
+ I'd consider this a temporary fix until we have proper bfd checks for the year
+ 2038, if it makes sense. 64-bit hosts seems to be more common these days, so
+ I'm not sure how important it is to have this support enabled and how soon
+ we want to enable it.
+
+ Thoughts?
+
+2022-08-10 Jan Beulich <jbeulich@suse.com>
+
+ gas/Dwarf: properly skip zero-size functions
+ PR gas/29451
+
+ While out_debug_abbrev() properly skips such functions, out_debug_info()
+ mistakenly didn't. It needs to calculate the high_pc expression ahead of
+ time, in order to skip emitting any data for the function if the value
+ is zero.
+
+ The one case which would still leave a zero-size entry is when
+ symbol_get_obj(symp)->size ends up evaluating to zero. I hope we can
+ expect that to not be the case, otherwise we'd need to have a way to
+ post-process .debug_info contents between resolving expressions and
+ actually writing the data out to the file. Even then it wouldn't be
+ entirely obvious in which way to alter the data.
+
+2022-08-10 Alan Modra <amodra@gmail.com>
+
+ PR29462, internal error in relocate, at powerpc.cc:10796
+ Prior to the inline plt call support (commit 08be322439), the only
+ local syms with plt entries were local ifunc symbols. There shouldn't
+ be stubs for other local symbols so don't look for them. The patch
+ also fixes minor bugs in get_reference_flags; Many relocs are valid
+ only for ppc64 and a couple only for ppc32.
+
+ PR 29462
+ * powerpc.cc (Target_powerpc::Relocate::relocate): Rename
+ use_plt_offset to pltcal_to_direct, invert logic. For relocs
+ not used with inline plt sequences against local symbols, only
+ look for stubs when the symbol is an ifunc.
+ (Target_powerpc::Scan::get_reference_flags): Correct reloc
+ handling for relocs not valid for both 32-bit and 64-bit.
+
+2022-08-10 Youling Tang <tangyouling@loongson.cn>
+
+ bfd: Add support for LoongArch64 EFI (efi-*-loongarch64).
+ This adds support for efi-loongarch64 by virtue of adding a new PEI target
+ pei-loongarch64. This is not a full target and only exists to support EFI at
+ this time.
+
+ This means that this target does not support relocation processing and is mostly
+ a container format. This format has been added to elf based loongarch64 targets
+ such that efi images can be made natively on Linux.
+
+ However this target is not valid for use with gas but only with objcopy.
+
+ We should't limit addresses to 32-bits for 64-bit vma, otherwise there will be
+ "RVA truncated" error when using objcopy on loongarch64.
+
+ With these changes the resulting file is recognized as an efi image.
+
+ Any magic number is based on the Microsoft PE specification [1].
+
+ The test results are as follows:
+ $ make check-binutils RUNTESTFLAGS='loongarch64.exp'
+ PASS: Check if efi app format is recognized
+
+ $ objdump -h -f tmpdir/loongarch64copy.o
+ tmpdir/loongarch64copy.o: file format pei-loongarch64
+ architecture: Loongarch64, flags 0x00000132:
+ EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED
+ start address 0x0000000000000000
+
+ Sections:
+ Idx Name Size VMA LMA File off Algn
+ 0 .text 0000003c 00000000200000b0 00000000200000b0 00000200 2**2
+ CONTENTS, ALLOC, LOAD, READONLY, CODE
+
+ [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
+
+ bfd:
+ * .gitignore (pe-loongarch64igen.c): New.
+ * Makefile.am (pei-loongarch64.lo, pe-loongarch64igen.lo, pei-loongarch64.c,
+ pe-loongarch64igen.c): Add support.
+ * Makefile.in: Likewise.
+ * bfd.c (bfd_get_sign_extend_vma): Add pei-loongarch64.
+ * coff-loongarch64.c: New file.
+ * coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
+ coff_write_object_contents) Add loongarch64 (loongarch64_pei_vec) support.
+ * config.bfd: Likewise.
+ * configure: Likewise.
+ * configure.ac: Likewise.
+ * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
+ GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
+ GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
+ GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
+ GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
+ GET_PDATA_ENTRY, _bfd_peLoongArch64_bfd_copy_private_bfd_data_common,
+ _bfd_peLoongArch64_bfd_copy_private_section_data,
+ _bfd_peLoongArch64_get_symbol_info, _bfd_peLoongArch64_only_swap_filehdr_out,
+ _bfd_peLoongArch64_print_private_bfd_data_common,
+ _bfd_peLoongArch64i_final_link_postscript,
+ _bfd_peLoongArch64i_only_swap_filehdr_out, _bfd_peLoongArch64i_swap_aouthdr_in,
+ _bfd_peLoongArch64i_swap_aouthdr_out, _bfd_peLoongArch64i_swap_aux_in,
+ _bfd_peLoongArch64i_swap_aux_out, _bfd_peLoongArch64i_swap_lineno_in,
+ _bfd_peLoongArch64i_swap_lineno_out, _bfd_peLoongArch64i_swap_scnhdr_out,
+ _bfd_peLoongArch64i_swap_sym_in, _bfd_peLoongArch64i_swap_sym_out,
+ _bfd_peLoongArch64i_swap_debugdir_in, _bfd_peLoongArch64i_swap_debugdir_out,
+ _bfd_peLoongArch64i_write_codeview_record,
+ _bfd_peLoongArch64i_slurp_codeview_record,
+ _bfd_peLoongArch64_print_ce_compressed_pdata): New.
+ * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
+ _bfd_XXi_swap_scnhdr_out, pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
+ _bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
+ Support COFF_WITH_peLoongArch64,
+ * pei-loongarch64.c: New file.
+ * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
+ Support COFF_WITH_peLoongArch64.
+ (jtab): Add dummy entry that traps.
+ * targets.c (loongarch64_pei_vec): New.
+
+ binutils
+ * testsuite/binutils-all/loongarch64/loongarch64.exp: New file.
+ * testsuite/binutils-all/loongarch64/pei-loongarch64.d: New test.
+ * testsuite/binutils-all/loongarch64/pei-loongarch64.s: New test.
+
+ include
+ * coff/loongarch64.h: New file.
+ * coff/pe.h (IMAGE_FILE_MACHINE_LOONGARCH64): New.
+
+2022-08-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv/testsuite: fix failures in gdb.arch/riscv-reg-aliases.exp
+ When running on a native RISC-V Linux target I currently see failures
+ in the gdb.arch/riscv-reg-aliases.exp test like this:
+
+ set $ft0.float = 501
+ (gdb) PASS: gdb.arch/riscv-reg-aliases.exp: write non-zero value to ft0
+ p/d $ft0.float
+ $263 = 1140490240
+ (gdb) FAIL: gdb.arch/riscv-reg-aliases.exp: read ft0 after non-zero write to ft0
+
+ This test started failing after this commit:
+
+ commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
+ Date: Thu Feb 17 13:43:59 2022 -0700
+
+ Change how "print/x" displays floating-point value
+
+ The problem is that when 501 is written to $ft0.float the value is
+ converted to floating point format and stored in the register. Prior
+ to the above commit printing with /x and /d would first extract the
+ value as a float, and then convert the value to an integer for
+ display. After the above commit GDB now uses the raw register value
+ when displaying /x and /d, and so we see this behaviour:
+
+ (gdb) info registers $ft0
+ ft0 {float = 501, double = 5.6347704700123827e-315} (raw 0x0000000043fa8000)
+ (gdb) p/f $ft0.float
+ $1 = 501
+ (gdb) p/d $ft0.float
+ $2 = 1140490240
+ (gdb) p/x $ft0.float
+ $3 = 0x43fa8000
+
+ To fix this test I now print the float registers using the /f format
+ rather than /d. With this change the test now passes.
+
+2022-08-09 Stepan Nemec <stepnem@gmail.com>
+
+ Another gas manual typo correction.
+
+ Fix typos in assembler documentation.
+
+2022-08-09 Feiyang Chen <chenfeiyang@loongson.cn>
+
+ gdb/gdbserver: LoongArch: Improve implementation of fcc registers
+ The current implementation of the fcc register is referenced to the
+ user_fp_state structure of the kernel uapi [1].
+
+ struct user_fp_state {
+ uint64_t fpr[32];
+ uint64_t fcc;
+ uint32_t fcsr;
+ };
+
+ But it is mistakenly defined as a 64-bit fputype register, resulting
+ in a confusing output of "info register".
+
+ (gdb) info register
+ ...
+ fcc {f = 0x0, d = 0x0} {f = 0, d = 0}
+ ...
+
+ According to "Condition Flag Register" in "LoongArch Reference Manual"
+ [2], there are 8 condition flag registers of size 1. Use 8 registers of
+ uint8 to make it easier for users to view the fcc register groups.
+
+ (gdb) info register
+ ...
+ fcc0 0x1 1
+ fcc1 0x0 0
+ fcc2 0x0 0
+ fcc3 0x0 0
+ fcc4 0x0 0
+ fcc5 0x0 0
+ fcc6 0x0 0
+ fcc7 0x0 0
+ ...
+
+ [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h
+ [2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register
+
+2022-08-09 Nick Clifton <nickc@redhat.com>
+
+ Default to enabling colored disassembly if output is to a terminal.
+ PR 29457
+ * objdump.c (disassembler_color): Change type to an enum.
+ (disassembler_extended_color): Remove.
+ (usage): Update.
+ (objdump_color_for_assembler_style): Update.
+ (main): Update initialisation of disassembler_color. If not
+ initialised via a command line option, set based upon terminal
+ output.
+ * doc/binutils.texi: Update description of disassmbler-color
+ option.
+ * testsuite/binutils-all/arc/objdump.exp: Add
+ --disassembler-color=off option when disassembling.
+ * testsuite/binutils-all/arm/objdump.exp: Likewise.
+
+2022-08-09 Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
+
+ Fix-for-multiple-thread-detection-in-AIX.
+ In AIX multiple threads were not added. This patch is a fix for the same
+
+ When we create a pthread debug session we have callbacks to read
+ symbols and memory. One of those call backs is pdc_read_data.
+
+ Before we come into aix-thread wait() we switch to no thread and
+ therefore the current thread is null.
+
+ When we get into pdc_read_data we have a dependency that we need to
+ be in the correct current thread that has caused an event of new
+ thread, inorder to read memory.
+
+ Hence we switch to the correct thread.
+
+ This is done by passing the pid in the pthdb_user_t user_current_pid
+ parameter in every call back.
+
+2022-08-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/debug-names.exp
+ When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I
+ run into:
+ ...
+ (gdb) maint info symtabs^M
+ ...
+ ERROR: internal buffer is full.
+ UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab
+ ...
+
+ Fix this by simplifying the test-case to print _start rather running to it.
+
+ Tested on x86_64-linux.
+
+2022-08-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/riscv: use register name enum values in riscv-linux-nat.c
+ There were a few places where we were using integer values rather than
+ the RISCV_*_REGNUM constants defined in riscv-tdep.h. This commit
+ replaces 0 with RISCV_ZERO_REGNUM and 32 with RISCV_PC_REGNUM in a few
+ places.
+
+ There should be no user visible changes after this commit.
+
+2022-08-09 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: adjust MOVQ to/from SReg attributes
+ It is unclear to me why the corresponding MOV (no Q suffix) can be
+ issued without REX.W, but MOVQ has to have that prefix (bit). Add
+ NoRex64 and in exchange drop Size64.
+
+ x86: adjust MOVSD attributes
+ The non-SSE2AVX form of the SIMD variant of the instruction needlessly
+ has the (still multi-purpose) IgnoreSize attribute. All other similar
+ SSE2 insns use NoRex64 instead. Make this consistent, noting that the
+ SSE2AVX form can't have the same change made - there the memory operand
+ doesn't at the same time permit RegXMM (which logic uses when deciding
+ whether a Q suffix is okay outside of 64-bit mode).
+
+ x86: fold AVX VGATHERDPD / VPGATHERDQ
+ While the other three variants each differ in attributes and hence can't
+ be folded, these two pairs actually can be (and were previously
+ overlooked). This effectively matches their AVX512VL counterparts, which
+ are also expressed as a single template.
+
+ x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insns
+ While the x/y/z suffix isn't necessary to use in this case, it is still
+ odd that these forms don't support broadcast (unlike their AVX512F /
+ AVX512DQ counterparts). The lack thereof can e.g. make macro-ized
+ programming more difficult.
+
+ x86/Intel: split certain AVX512-FP16 VCVT*2PH templates
+ One more place where pre-existing templates should have been taken as a
+ basis: In Intel syntax we want to consistently issue an "ambiguous
+ operand size" error when a size-less memory operand is specified for an
+ insn where register use alone isn't sufficient for disambiguation.
+
+2022-08-09 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky fix build error in ubuntu20_04
+ build error in: https://builder.sourceware.org/buildbot/#/builders/170/builds/246
+ ...
+ ../../binutils-gdb/gdb/csky-linux-tdep.c: In function ‘void
+ csky_supply_fregset(const regset*, regcache*, int, const void*, size_t)’:
+ ../../binutils-gdb/gdb/csky-linux-tdep.c:194:18: error: format ‘%ld’
+ expects argument of type ‘long int’, but argument 2 has type ‘size_t’
+ {aka ‘unsigned int’} [-Werror=format=]
+ 194 | warning (_("Unknow size %ld of section .reg2, can not get
+ value"
+ |
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 195 | " of float registers."), len);
+ ...
+
+ Fix it via using %s vs pulongest suggested by Tom.
+
+2022-08-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-08 Tom Tromey <tromey@adacore.com>
+
+ Fix regression from gdbarch registry change
+ The gdbarch registry patch introduced a regression that could cause a
+ crash when opening files in gdb. The bug is that, previously, the
+ solib ops would default to current_target_so_ops; but the patch
+ changed this code to default to nullptr. This patch fixes the bug by
+ reintroducing the earlier behavior. This is PR gdb/29449.
+
+ I managed to reproduce the bug with a riscv-elf build and then
+ verified that this fixes the problem.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29449
+
+2022-08-08 Martin Liska <mliska@suse.cz>
+
+ add splay tree for info_ptr -> CU mapping
+ While using perf top for MozillaThunderbird I noticed quite some slow
+ dissably call with source code involved. E.g.
+
+ time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C /usr/lib64/thunderbird/libxul.so
+
+ took 2.071s and I noticed quite some time is spent in
+ find_abstract_instance:
+
+ 33.46% objdump objdump [.] find_abstract_instance
+ 18.22% objdump objdump [.] arange_add
+ 13.77% objdump objdump [.] read_attribute_value
+ 4.82% objdump objdump [.] comp_unit_maybe_decode_line_info
+ 3.10% objdump libc.so.6 [.] __memset_avx2_unaligned_erms
+
+ where linked list of CU is iterated when searing for where info_ptr
+ belongs to:
+
+ : 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
+ 0.00 : 4c61f7: mov 0x10(%rbx),%rax
+ 0.00 : 4c61fb: test %rax,%rax
+ 0.00 : 4c61fe: je 4c6215 <find_abstract_instance+0x365>
+ : 3453 if (info_ptr >= u->info_ptr_unit && info_ptr < u->end_ptr)
+ 0.00 : 4c6200: cmp 0x60(%rax),%rdx
+ 83.20 : 4c6204: jb 4c620c <find_abstract_instance+0x35c>
+ 0.00 : 4c6206: cmp 0x78(%rax),%rdx
+ 6.89 : 4c620a: jb 4c6270 <find_abstract_instance+0x3c0>
+ : 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
+ 0.00 : 4c620c: mov 0x10(%rax),%rax
+ 7.90 : 4c6210: test %rax,%rax
+ 0.00 : 4c6213: jne 4c6200 <find_abstract_instance+0x350>
+
+ The following scan can be replaced with search in a splay tree and with
+ that I can get to 1.5s and there are other symbols where the difference
+ is even bigger.
+
+ bfd/ChangeLog:
+
+ PR 29081
+ * dwarf2.c (struct addr_range): New.
+ (addr_range_intersects): Likewise.
+ (splay_tree_compare_addr_range): Likewise.
+ (splay_tree_free_addr_range): Likewise.
+ (struct dwarf2_debug_file): Add comp_unit_tree.
+ (find_abstract_instance): Use the splay tree when searching
+ for a info_ptr.
+ (stash_comp_unit): Insert to the splay tree.
+ (_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree.
+
+2022-08-08 Martin Liska <mliska@suse.cz>
+
+ dwarf: use find_abstract_instance for vars and DW_AT_specification
+ The following simple test case fails when dwz is used:
+
+ $ cat demo.C
+ namespace std {
+ enum { _S_fixed, _S_floatfield = _S_fixed };
+ struct {
+ struct {};
+ }
+ __ioinit;
+ }
+
+ int main() {
+ return 0;
+ }
+
+ $ g++ demo.C -g && cp a.out b.out && dwz -m xxx.so a.out b.out && objdump -S a.out >/dev/null
+ objdump: DWARF error: could not find variable specification at offset 0x3d3
+
+ As seen the reference is defined in xxx.so shared part:
+
+ $ eu-readelf -w -N a.out | grep -A3 -B3 3d3
+ decl_column (data1) 11
+ sibling (ref_udata) [ 387]
+ [ 387] variable abbrev: 30
+ specification (GNU_ref_alt) [ 3d3]
+ location (exprloc)
+ [ 0] addr 0x404019
+ [ 396] subprogram abbrev: 32
+
+ $ eu-readelf -w -N a.out | less
+
+ ...
+
+ Compilation unit at offset 920:
+ Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
+ Unit type: partial (3)
+ ...
+ [ 3d3] variable abbrev: 31
+ name (strp) "__ioinit"
+ decl_file (data1) demo.C (10)
+ decl_line (data1) 6
+ decl_column (data1) 3
+ type (ref_udata) [ 3c4]
+ declaration (flag_present) yes
+
+ With the patch the same output is emitted as before usage of dwz.
+
+ bfd/ChangeLog:
+
+ PR 29442
+ * dwarf2.c (struct varinfo): Use const char * type.
+ (scan_unit_for_symbols): Call find_abstract_instance for
+ DW_AT_specification for variables that can be in a different CU
+ (e.g. done by dwz)
+
+2022-08-08 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ Mach-O: i18n enablement on some error messages.
+ * config/obj-macho.c (obj_mach_o_get_section_names): Wrap two
+ string literals within with gettext macro.
+
+2022-08-08 Martin Liska <mliska@suse.cz>
+
+ ld: fix NEWS typos
+ ld/ChangeLog:
+
+ * NEWS: Fix 2 typos.
+
+2022-08-08 Nick Clifton <nickc@redhat.com>
+
+ Add a link to the NEWS files in the release announcement email.
+
+2022-08-08 Jiangshuai Li <jiangshuai_li@linux.alibaba.com>
+
+ gdb/csky support .reg2 for kernel 4.x and later
+ When kernel's version >= 4.x, the size of .reg2 section will be 400.
+ Contents of .reg2 are {
+ unsigned long vr[96];
+ unsigned long fcr;
+ unsigned long fesr;
+ unsigned long fid;
+ unsigned long reserved;
+ };
+
+ VR[96] means: (vr0~vr15) + (fr16~fr31), each Vector register is
+ 128-bits, each Float register is 64 bits, the total size is
+ (4*96).
+
+ In addition, for fr0~fr15, each FRx is the lower 64 bits of the
+ corresponding VRx. So fr0~fr15 and vr0~vr15 regisetrs use the same
+ offset.
+
+2022-08-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with gcc 4.8.5
+ When building with gcc 4.8.5, I run into:
+ ...
+ user-regs.c:85:1: error: could not convert \
+ ‘{0l, (& builtin_user_regs.gdb_user_regs::first)}’ from \
+ ‘<brace-enclosed initializer list>’ to ‘gdb_user_regs’
+ };
+ ^
+ ...
+
+ Fix this by removing the initialization and handling regs.last == nullptr in
+ append_user_reg.
+
+ Tested on x86_64-linux.
+
+2022-08-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix assert in read_addrmap_from_aranges
+ When loading the debug-names-duplicate-cu executable included in this
+ test-case, we run into:
+ ...
+ (gdb) file debug-names-duplicate-cu^M
+ Reading symbols from debug-names-duplicate-cu...^M
+ src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \
+ Assertion `insertpair.second' failed.^M
+ ...
+
+ This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix
+ .debug_aranges duplicate offset warning").
+
+ The assert triggers because the CU table in the .debug_names section contains
+ a duplicate:
+ ...
+ Version 5
+ Augmentation string: 47 44 42 00 ("GDB")
+ CU table:
+ [ 0] 0x0
+ [ 1] 0x0
+ ...
+
+ Fix this by rejecting the .debug_names index:
+ ...
+ (gdb) file debug-names-duplicate-cu^M
+ Reading symbols from debug-names-duplicate-cu...^M
+ warning: Section .debug_names has duplicate entry in CU table, \
+ ignoring .debug_names.^M
+ ...
+
+ Likewise for the case where the CU table is not sorted by increasing offset.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29436
+
+2022-08-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add support for .debug_names in dwarf assembler
+ Add:
+ - support for a per-module .debug_names section in the dwarf assembler, and
+ - a test-case excercising this new functionality.
+
+ A per-module .debug_names section needs to have an entry in the CU list for
+ each CU in the module, which is made more difficult by two things:
+ - linking in other objects, which may contain additional CUs
+ (typically the case on openSUSE), and
+ - adding dummy CUs in the dwarf assembler.
+ We handle this by:
+ - compiling with -nostartfiles (so the test-case contains _start rather than
+ main), and
+ - disabling the dummy CU generation for the test-case.
+
+ I've kept things simple by having the test-case specify the hash value, rather
+ than adding that functionality in the dwarf assembler.
+
+ Also I've kept the bucket count to 1, which makes it trivial to satisfy the
+ requirement that "the symbol is entered into a bucket whose index is the hash
+ value modulo bucket_count".
+
+ The readelf dump of the .debug_names section from the test-case looks like:
+ ...
+ Version 5
+ Augmentation string: 47 44 42 00 ("GDB")
+ CU table:
+ [ 0] 0x0
+
+ TU table:
+
+ Foreign TU table:
+
+ Used 1 of 1 bucket.
+ Out of 2 items there are 1 bucket clashes (longest of 1 entries).
+
+ Symbol table:
+ [ 0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
+ [ 1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
+ ...
+
+ Tested on x86_64-linux.
+
+2022-08-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-06 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow in _bfd_error_handler
+ On coff_slurp_symbol_table printing "unrecognized storage class"
+ for a symbol error. If the symbol name is the last string in its
+ section and not terminated, we run off the end of the buffer.
+
+ * coffgen.c (build_debug_section): Terminate the section with
+ an extra 0.
+
+2022-08-06 Alan Modra <amodra@gmail.com>
+
+ asan: segfault in coff_write_auxent_fname
+ More fuzzed input file nonsense.
+
+ * coffgen.c (coff_write_symbol): Don't call coff_write_auxent_fname
+ when extrap is NULL.
+
+2022-08-06 Alan Modra <amodra@gmail.com>
+
+ msan: bfd_mach_o_layout_commands use of uninitialised value
+ Catches fuzzed input with unterminated strings that later run off the
+ end of their buffers when calling strlen.
+
+ * mach-o.c: Use size_t vars where approprite.
+ (bfd_mach_o_alloc_and_read): Add "extra" param. Allocate that
+ much extra and clear. Update all callers, those that set up
+ strings with one extra byte.
+
+2022-08-06 Alan Modra <amodra@gmail.com>
+
+ objcopy section alignment
+ bfd_set_section_alignment currently always returns true. This patch
+ changes it to return false on silly alignment values, avoiding yet
+ another way to trigger ubsan errors like coffcode.h:3192:12: runtime
+ error: shift exponent 299 is too large for 32-bit type 'int'. We'll
+ catch that one in objcopy.c:setup_sections. However, setup_sections
+ gives up on other setup operations that are necessary even after an
+ error of some sort. Change that to keep going, which might change the
+ error message but that shouldn't matter in the least.
+
+ bfd/
+ * section.c (bfd_set_section_alignment): Return false and
+ don't set alignment_power for stupidly large alignments.
+ * bfd-in2.h: Regenerate.
+ * coffcode.h (coff_compute_section_file_positions): Don't use
+ an int constant when calculating alignment.
+ binutils/
+ * objcopy.c (setup_section): Keep on going after hitting
+ non-fatal errors.
+
+2022-08-06 Alan Modra <amodra@gmail.com>
+
+ ubsan: som.c undefined shift in som_set_reloc_info
+ Do the shift using unsigned variables to avoid UB on << 8.
+
+ * som.c (som_set_reloc_info): Make v unsigned. Localise some
+ variables to their blocks.
+
+2022-08-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-05 Alan Modra <amodra@gmail.com>
+
+ Get rid of BFD_VMA_FMT
+ Remove the BFD_VMA_FMT defines in bfd.h and configure support.
+
+ * bfd-in.h (BFD_VMA_FMT): Don't define.
+ * configure.ac (BFD_INT64_FMT): Remove configure test.
+ * configure.com: Likewise.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Regenerate.
+ * configure: Regenerate.
+
+2022-08-05 Alan Modra <amodra@gmail.com>
+
+ Don't use BFD_VMA_FMT in gdb and sim
+ Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with
+ PRIx64 and casts to promote bfd_vma to uint64_t. The one file using
+ BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the
+ warning message is fixed.
+
+2022-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build breaker in language.c with gcc 7.5.0
+ When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into:
+ ...
+ gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’:
+ gdb/language.c:921:8: error: use of deleted function \
+ ‘language_arch_info::language_arch_info(const language_arch_info&)’
+ struct language_gdbarch
+ ^~~~~~~~~~~~~~~~
+ In file included from gdbsupport/common-defs.h:104:0,
+ from gdb/defs.h:28,
+ from gdb/language.c:31:
+ gdb/language.h:95:28: note: declared here
+ DISABLE_COPY_AND_ASSIGN (language_arch_info);
+ ^
+ include/ansidecl.h:342:3: note: in definition of macro \
+ ‘DISABLE_COPY_AND_ASSIGN’
+ TYPE (const TYPE&) = delete; \
+ ^~~~
+ gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’:
+ gdb/language.c:936:22: note: synthesized method ‘constexpr \
+ language_gdbarch::language_gdbarch()’ first required here
+ l = new struct language_gdbarch;
+ ^~~~~~~~~~~~~~~~
+ ...
+
+ This seems to be fixed by this change in the struct language_gdbarch
+ definition:
+ ...
+ - struct language_arch_info arch_info[nr_languages] {};
+ + struct language_arch_info arch_info[nr_languages];
+ ...
+
+ Tested on x86_64-linux.
+
+2022-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add unit test for gdb::sequential_for_each
+ With commit 18a5766d09c ("[gdbsupport] Add sequential_for_each") I added a
+ drop-in replacement for gdb::parallel_for_each, but there's nothing making
+ sure that the two remain in sync.
+
+ Extend the unit test for gdb::parallel_for_each to test both.
+
+ Do this using a slightly unusual file-self-inclusion. Doing so keep things
+ readable and maintainable, and avoids macrofying functions.
+
+ Tested on x86_64-linux.
+
+2022-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Use task size in parallel_for_each in dwarf2_build_psymtabs_hard
+ In dwarf2_build_psymtabs_hard, we use a parallel_for_each to distribute CUs
+ over threads.
+
+ Ensuring a fair distribution over the worker threads and main thread in terms
+ of number of CUs might not be the most efficient way, given that CUs can vary
+ in size.
+
+ Fix this by using per_cu->get_length () as the task size.
+
+ I've used this experiment to verify the performance impact:
+ ...
+ $ for n in $(seq 1 10); do \
+ time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
+ 2>&1 \
+ | grep "real:"; \
+ done
+ ...
+ and without the patch got:
+ ...
+ real: 4.71
+ real: 4.88
+ real: 4.29
+ real: 4.30
+ real: 4.65
+ real: 4.27
+ real: 4.27
+ real: 4.27
+ real: 4.75
+ real: 4.41
+ ...
+ and with the patch:
+ ...
+ real: 3.68
+ real: 3.81
+ real: 3.80
+ real: 3.68
+ real: 3.75
+ real: 3.69
+ real: 3.69
+ real: 3.74
+ real: 3.67
+ real: 3.74
+ ...
+ so that seems a reasonable improvement.
+
+ With parallel_for_each_debug set to true, we get some more detail about
+ the difference in behaviour. Without the patch we have:
+ ...
+ Parallel for: n_elements: 2818
+ Parallel for: minimum elements per thread: 1
+ Parallel for: elts_per_thread: 704
+ Parallel for: elements on worker thread 0 : 705
+ Parallel for: elements on worker thread 1 : 705
+ Parallel for: elements on worker thread 2 : 704
+ Parallel for: elements on worker thread 3 : 0
+ Parallel for: elements on main thread : 704
+ ...
+ and with the patch:
+ ...
+ Parallel for: n_elements: 2818
+ Parallel for: total_size: 1483674865
+ Parallel for: size_per_thread: 370918716
+ Parallel for: elements on worker thread 0 : 752 (size: 371811790)
+ Parallel for: elements on worker thread 1 : 360 (size: 371509370)
+ Parallel for: elements on worker thread 2 : 1130 (size: 372681710)
+ Parallel for: elements on worker thread 3 : 0 (size: 0)
+ Parallel for: elements on main thread : 576 (size: 367671995)
+ ...
+
+ Tested on x86_64-linux.
+
+2022-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Add task size parameter in parallel_for_each
+ Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use
+ the task size to distribute similarly-sized chunks to the threads.
+
+ Tested on x86_64-linux.
+
+2022-08-05 Pedro Alves <pedro@palves.net>
+
+ Introduce gdb::make_function_view
+ This adds gdb::make_function_view, which lets you create a function
+ view from a callable without specifying the function_view's template
+ parameter. For example, this:
+
+ auto lambda = [&] (int) { ... };
+ auto fv = gdb::make_function_view (lambda);
+
+ instead of:
+
+ auto lambda = [&] (int) { ... };
+ gdb::function_view<void (int)> fv = lambda;
+
+ It is particularly useful if you have a template function with an
+ optional function_view parameter, whose type depends on the function's
+ template parameters. Like:
+
+ template<typename T>
+ void my_function (T v, gdb::function_view<void(T)> callback = nullptr);
+
+ For such a function, the type of the callback argument you pass must
+ already be a function_view. I.e., this wouldn't compile:
+
+ auto lambda = [&] (int) { ... };
+ my_function (1, lambda);
+
+ With gdb::make_function_view, you can write the call like so:
+
+ auto lambda = [&] (int) { ... };
+ my_function (1, gdb::make_function_view (lambda));
+
+ Unit tests included.
+
+ Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64
+ GNU/Linux, and running the unit tests.
+
+ Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626
+
+2022-08-05 Nick Clifton <nickc@redhat.com>
+
+ Update following 2.39 release
+
+2022-08-05 Alan Modra <amodra@gmail.com>
+
+ asan: ppc64_elf_get_synthetic_symtab heap buffer overflow
+ Fuzzed input files with sizes of .dynamic not a multiple of dynamic
+ tag size can result in reading past the end of the buffer with the
+ current simple checks. Fix that, and use the same check in other
+ files that process input object .dynamic section. (There is no need
+ for buffer overflow checks in the linker's generated .dynamic
+ section.)
+
+ * elf32-ppc.c (ppc_elf_get_synthetic_symtab): Sanity check
+ .dynamic content buffer reads.
+ * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
+ * elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Likewise.
+ * elf.c (_bfd_elf_print_private_bfd_data): Simplify .dynamic
+ buffer sanity checks.
+ * elflink.c (elf_link_add_object_symbols): Avoid possible UB
+ subtracting sizeof_dyn from pointer.
+
+2022-08-05 Alan Modra <amodra@gmail.com>
+
+ Sanity check loc_offsets index
+ Fixes a segfault found by the fuzzers.
+
+ * dwarf.c (fetch_indexed_value): Return -1 on error.
+ (read_and_display_attr_value): Don't display string when
+ fetch_indexed_value returns an error. Sanity check loc_offsets
+ index.
+
+2022-08-05 Jan Beulich <jbeulich@suse.com>
+
+ binutils/Dwarf: avoid "shadowing" of glibc function name
+ As before: Old enough glibc has an (unguarded) declaration of index()
+ in string.h, which triggers a "shadows a global declaration" warning.
+
+2022-08-05 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ gas: fix a testcase broken by new ZSTD support
+ The commit 1369522f36eece1b37139a81f7f2139ba3915172 ("Recognize the new ELF
+ compression type for ZSTD.") added the new ELF compression type but it
+ accidentally broke a GAS testcase. Since testing for the section type
+ "2048" (SHF_COMPRESSED) is not going to be portable in the long term, it
+ now tests SHF_LINK_ORDER ("128") instead.
+
+ Using SHF_LINK_ORDER (with possibly sh_link == 0) is an idea by Jan Beulich.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/elf/section10.s: Use SHF_LINK_ORDER to test
+ mixed numeric and alpha values.
+ * testsuite/gas/elf/section10.d: Reflect the change above.
+
+2022-08-05 Nick Clifton <nickc@redhat.com>
+
+ When gas/read.c calls mbstowcs with a NULL destination, it should set size to 0
+ PR 29447
+ * read.c (read_symbol_name): Pass 0 as the length parameter when
+ invoking mbstowc in order to check the validity of a wide string.
+
+2022-08-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add debug_{exp,val}
+ When debugging cc1 I heavily rely on simple one-parameter debug functions
+ that allow me to inspect a variable of a common type, like:
+ - debug_generic_expr
+ - debug_gimple_stmt
+ - debug_rtx
+ and I miss similar functions in gdb.
+
+ Add functions to dump variables of types 'value' and 'expression':
+ - debug_exp, and
+ - debug_val.
+
+ Tested on x86_64-linux, by breaking on varobj_create, and doing:
+ ...
+ (gdb) call debug_exp (var->root->exp.get ())
+ &"Operation: OP_VAR_VALUE\n"
+ &" Block symbol:\n"
+ &" Symbol: aaa\n"
+ &" Block: 0x2d064f0\n"
+ (gdb)
+ ...
+ and:
+ ...
+ (gdb) call debug_val (value)
+ &"5"
+ (gdb)
+ ...
+
+2022-08-05 Luca Boccassi <bluca@debian.org>
+
+ Add gold support for --package-metadata option.
+ Following the same format as the implementation in ld:
+ 9e2bb0cb5e74aed4158f08495534922d7108f928
+
+ Generate a .note.package FDO package metadata ELF note, following
+ the spec: https://systemd.io/ELF_PACKAGE_METADATA/
+
+ If the jansson library is available at build time (and it is explicitly
+ enabled), link ld to it, and use it to validate that the input is
+ correct JSON, to avoid writing garbage to the file. The
+ configure option --enable-jansson has to be used to explicitly enable
+ it (error out when not found). This allows bootstrappers (or others who
+ are not interested) to seamlessly skip it without issues.
+
+ elfcpp/
+ * elfcpp.h: Add FDO_PACKAGING_METADATA note type.
+
+ gold/
+ * Makefile.am: Add jansson flags and libraries.
+ * configure.ac: Check for jansson library.
+ * layout.cc (Layout::create_notes): Call create_package_metadata().
+ (Layout::create_package_metadata): New function.
+ * layout.h (Layout::create_package_metadata): New function.
+ (Layout::package_metadata_note_): New data member.
+ * options.h (class General_options): Add --package-metadata option.
+ * testsuite/Makefile.am (object_unittest): Add jansson libraries.
+ (binary_unittest): Likewise.
+ (leb128_unittest): Likewise.
+ (overflow_unittest): Likewise.
+ (package_metadata_test): New test.
+ * testsuite/package_metadata_main.c: New test source.
+
+2022-08-05 Cary Coutant <ccoutant@gmail.com>
+
+ Recognize the new ELF compression type for ZSTD.
+ There is more work to be done to actually support compression and
+ decompression using the zstd library, but I will leave that to the
+ champions of the new compression option.
+
+ binutils/
+ * binutils/readelf.c (process_section_headers): Add support for
+ ELFCOMPRESS_ZSTD.
+
+2022-08-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-04 Tom Tromey <tom@tromey.com>
+
+ Use registry in gdbarch
+ gdbarch implements its own registry-like approach. This patch changes
+ it to instead use registry.h. It's a rather large patch but largely
+ uninteresting -- it's mostly a straightforward conversion from the old
+ approach to the new one.
+
+ The main benefit of this change is that it introduces type safety to
+ the gdbarch registry. It also removes a bunch of code.
+
+ One possible drawback is that, previously, the gdbarch registry
+ differentiated between pre- and post-initialization setup. This
+ doesn't seem very important to me, though.
+
+2022-08-04 Tom Tromey <tom@tromey.com>
+
+ Allow registry to refer to const types
+ So far, the registry hasn't been used to refer to a 'const' type, but
+ this changes with the gdbarch change. This patch arranges to let the
+ registry store a pointer-to-const, by removing const in the 'set'
+ method.
+
+ Use new and delete for gdbarch
+ This changes gdbarch to use new and delete.
+
+ Use bool in gdbarch
+ This changes gdbarch to use bool for initialized_p.
+
+2022-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix .debug_aranges in gdb.dwarf2/fission-loclists.S
+ When running test-case gdb.dwarf2/fission-loclists.exp, I noticed:
+ ...
+ warning: Section .debug_aranges in fission-loclists has duplicate \
+ debug_info_offset 0x8f, ignoring .debug_aranges.^M
+ ...
+
+ Fix this by removing the duplicate .debug_aranges entry.
+
+ Tested on x86_64-linux.
+
+2022-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix ERROR in gdb.base/watchpoint-unaligned.exp
+ In PR23888 an error is reported:
+ ...
+ ERROR: tcl error sourcing watchpoint-unaligned.exp.
+ ERROR: expected boolean value but got ""
+ while executing
+ "if {$wpnum} {
+ ...
+
+ This presumably happens when:
+ - skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported
+ - gdb fails to set a hw watchpoint and instead sets a sw watchpoint
+
+ That particular situation is handled for arm:
+ ...
+ -re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" {
+ if {[istarget "arm*-*-*"]} {
+ untested $test
+ set wpnum 0
+ }
+ }
+ ...
+ but not for any other targets so wpnum remains "", triggering the ERROR.
+
+ Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9
+ add test for HW watchpoint support."), but it's still possible for other
+ targets.
+
+ Fix this by:
+ - initializing wpnum to 0 instead of ""
+ - signalling the failure to set a hw watchpoint by a fail
+
+ Tested on x86_64-linux, also by adding:
+ ...
+ gdb_test_no_output "set can-use-hw-watchpoints 0"
+ ...
+ and verifying that it triggers the fail.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23888
+
+2022-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix gdb.base/large-frame.exp for aarch64
+ On aarch64, I run into:
+ ...
+ FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace
+ ...
+
+ The problem is that the architecture-specific prologue analyzer fails to
+ handle the first two insns in the prologue properly:
+ ...
+ 0000000000400610 <func>:
+ 400610: d2880210 mov x16, #0x4010
+ 400614: cb3063ff sub sp, sp, x16
+ 400618: a9007bfd stp x29, x30, [sp]
+ 40061c: 910003fd mov x29, sp
+ 400620: 910043a0 add x0, x29, #0x10
+ 400624: 97fffff0 bl 4005e4 <blah>
+ ...
+ so we get:
+ ...
+ $ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func"
+ Breakpoint 1 at 0x400614
+ ...
+
+ Fix this by:
+ - fixing the support for the first insn to extract the immediate operand, and
+ - adding support for the second insn,
+ such that we have:
+ ...
+ Breakpoint 1 at 0x400624
+ ...
+ Note that we're overshooting by one insn (0x400620 is the first insn after the
+ prologue), but that's a pre-existing problem.
+
+ Tested on aarch64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29408
+
+2022-08-04 Alan Modra <amodra@gmail.com>
+
+ Don't use BFD_VMA_FMT in binutils
+ BFD_VMA_FMT can't be used in format strings that need to be
+ translated, because the translation won't work when the type of
+ bfd_vma differs from the machine used to compile .pot files. We've
+ known about this for a long time, but patches slip through review.
+
+ So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64,
+ PRIu64, PRIx64 or PRIo64 and SCN variants for scanf. The patch is
+ mostly mechanical, the only thing requiring any thought is casts
+ needed to preserve PRId64 output from bfd_vma values, or to preserve
+ one of the unsigned output formats from bfd_signed_vma values.
+
+2022-08-04 Alan Modra <amodra@gmail.com>
+
+ Re: Get rid of fprintf_vma and sprintf_vma
+ Commit f493c2174e messed the formatting in linker map files,
+ particularly for 32-bit builds where a number of tests using map files
+ regressed. I should have noticed the BFD64 conditional printing of
+ spaces to line up output due to the original %V printing hex vmas with
+ 16 digits when BFD64 and 8 digits when not. Besides that, it is nicer
+ to print 32-bit vmas for 32-bit targets. So change %V back to be
+ target dependent, now using bfd_sprintf_vma. Since minfo doesn't
+ return the number of chars printed, that means some places that
+ currently use %V must instead sprintf to a buffer in order to find the
+ length printed.
+
+ * ldmisc.h (print_spaces): Declare.
+ (print_space): Change to a macro.
+ * ldmisc.c (vfinfo): Use bfd_sprintf_vma for %V. Tidy %W case.
+ (print_space): Delete.
+ (print_spaces): New function.
+ * emultempl/aix.em (print_symbol): Use print_spaces.
+ * ldctor.c (ldctor_build_sets): Likewise.
+ * ldmain.c (add_archive_element): Likewise.
+ * ldlang.c (print_one_symbol, lang_print_asneeded): Likewise.
+ (print_output_section_statement, print_data_statement): Likewise.
+ (print_reloc_statement, print_padding_statement): Likewise.
+ (print_assignment): Likewise. Also replace %V printing of vmas
+ with printing to a buffer in order to properly format output.
+ (print_input_section, lang_one_common): Likewise.
+
+2022-08-04 Alan Modra <amodra@gmail.com>
+
+ MIPS: Use R_MIPS_REL16 for BFD_RELOC_16
+ R_MIPS_REL16 isn't a pc-relative reloc as the name might indicate.
+
+ * elf64-mips.c (mips_reloc_map): Map BFD_RELOC_16 to R_MIPS_REL16.
+ * elfn32-mips.c (mips_reloc_map): Likewise.
+
+2022-08-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-03 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Reset alignment for each PT_LOAD segment
+ Reset alignment for each PT_LOAD segment to avoid using alignment from
+ the previous PT_LOAD segment.
+
+ bfd/
+
+ PR ld/29435
+ * elf.c (assign_file_positions_for_load_sections): Reset
+ alignment for each PT_LOAD segment.
+
+ ld/
+
+ PR ld/29435
+ * testsuite/ld-elf/pr29435.d: New file.
+ * testsuite/ld-elf/pr29435.s: Likewise.
+
+2022-08-03 Tom Tromey <tom@tromey.com>
+
+ Use unique_ptr to destroy per-bfd object
+ In some cases, the objfile owns the per-bfd object. This is yet
+ another object that can sometimes be destroyed before the registry is
+ destroyed, possibly reslting in a use-after-free. Also, I noticed
+ that the condition for deleting the object is not the same as the
+ condition used to create it -- so it could possibly result in a memory
+ leak in some situations. This patch fixes the problem by introducing
+ a new unique_ptr that holds this object when necessary.
+
+ Use auto_obstack in objfile
+ This changes objfile to use an auto_obstack. This helps prevent
+ use-after-free bugs, because it ensures that anything allocated on the
+ objfile obstack will live past the point at which the registry object
+ is destroyed.
+
+ Use gdb_bfd_ref_ptr in objfile
+ This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to
+ removing some manual memory management, this fixes a use-after-free
+ that was introduced by the registry rewrite series. The issue there
+ was that, in some cases, registry shutdown could refer to memory that
+ had already been freed. This help fix the bug by delaying the
+ destruction of the BFD reference (and thus the per-bfd object) until
+ after the registry has been shut down.
+
+2022-08-03 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29410 - Argument " 0." isn't numeric in numeric gt (>)
+ gprofng/Changelog:
+ 2022-08-02 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29410
+ * gp-display-html/gp-display-html.in: Remove non-breaking spaces.
+
+2022-08-03 Alan Modra <amodra@gmail.com>
+
+ Fix a conflict between the linker's need to rename some PE format input libraries and the BFD library's file caching mechanism.
+ PR 29389
+ bfd * bfd.c (BFD_CLOSED_BY_CACHE): New bfd flag.
+ * cache.c (bfd_cache_delete): Set BFD_CLOSED_BY_DELETE on the
+ closed bfd.
+ (bfd_cache_lookup_worker): Clear BFD_CLOSED_BY_DELETE on the newly
+ reopened bfd.
+ * opncls.c (bfd_set_filename): Refuse to change the name of a bfd
+ that has been closed by bfd_cache_delete. Mark changed bfds as
+ uncacheable.
+ * bfd-in2.h: Regenerate.
+
+ ld * ldlang.h (lang_input_statement_struct): Add sort_key field.
+ * emultempl/pe.em (after_open): If multiple import libraries refer
+ to the same bfd, store their names in the sort_key field.
+ * emultempl/pep.em (after_open): Likewise.
+ * ldlang.c (sort_filename): New function. Returns the filename to
+ be used when sorting input files.
+ (wild_sort): Use the sort_filename function.
+
+2022-08-03 Enze Li <enze.li@hotmail.com>
+
+ gdb/amd64: clean up unused variable
+ When building with clang 15, I got this,
+
+ CXX amd64-tdep.o
+ amd64-tdep.c:1410:13: error: variable 'insn' set but not used[-Werror,-Wunused-but-set-variable]
+ gdb_byte *insn = insn_details->raw_insn + modrm_offset;
+ ^
+ 1 error generated.
+
+ The function that uses this variable has been removed in this commit,
+
+ commit 870f88f7551b0f2d6aaaa36fb684b5ff8f468107
+ Date: Mon Apr 18 13:16:27 2016 -0400
+
+ remove trivialy unused variables
+
+ Fix this by removing unused variable.
+
+ Tested by rebuilding on x86_64-linux with clang 15 and gcc 12.
+
+2022-08-03 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Fix regression in varobj recreation
+ Commit bc20e562ec0 "Fix use after free in varobj" introduced a
+ regression. This commit makes sure that the varobj object does not
+ keeps stale references to object being freed when we unload an objfile.
+ This includes the "valid_block" field which is reset to nullptr if the
+ pointed to block is tied to an objfile being freed.
+
+ However, at some point varobj_invalidate_iter might try to recreate
+ varobjs tracking either floating or globals. Varobj tracking globals
+ are identified as having the "valid_block" field set nullptr, but as
+ bc20e562ec0 might clear this field, we have lost the ability to
+ distinguish between varobj referring to globals and non globals.
+
+ Fix this by introducing a "global" flag which tracks if a given varobj
+ was initially created as tracking a global.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
+
+2022-08-03 Alan Modra <amodra@gmail.com>
+
+ Re: PE objdump -x
+ All of these buffer overrun tests are better written as a comparison
+ against size remaining, due to ISO C 9899 standard 6.5.2 para 8
+ regarding adding a constant to a pointer:
+
+ "If both the pointer operand and the result point to elements of the
+ same array object, or one past the last element of the array object,
+ the evaluation shall not produce an overflow; otherwise, the behavior
+ is undefined."
+
+ So "ex_dta + 4" might be undefined behaviour, if you interpret "the
+ array object" in this case to be the malloc'd section contents!
+
+ * pei-x86_64.c (pex64_get_unwind_info): Tidy sanity checks.
+ (pex64_xdata_print_uwd_codes): Likewise.
+
+2022-08-03 Jan Beulich <jbeulich@suse.com>
+
+ x86: improve/shorten vector zeroing-idiom optimization conditional
+ - Drop the rounding type check: We're past template matching, and none
+ of the involved insns support embedded rounding.
+ - Drop the extension opcode check: None of the involved opcodes have
+ variants with it being other than None.
+ - Instead check opcode space, even if just to be on the safe side going
+ forward.
+ - Reduce the number of comparisons by folding two groups.
+
+ x86: properly mark i386-only insns
+ Just like all Size64 insns are marked Cpu64, all Size32 insns ought to
+ be marked Cpu386.
+
+ x86: also use D for MOVBE
+ First of all rename the meanwhile misleading Opcode_SIMD_FloatD, as it
+ has also been used for KMOV* and BNDMOV. Then simplify the condition
+ selecting which form if "reversing" to use - except for the MOV to/from
+ control/debug/test registers all extended opcode space insns use bit 0
+ (rather than bit 1) to indicate the direction (from/to memory) of an
+ operation. With that, D can simply be set on the first of the two
+ templates, while the other can be dropped.
+
+2022-08-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-03 Cary Coutant <ccoutant@gmail.com>
+
+ Add ELFCOMPRESS_ZSTD.
+ include/elf/
+ * common.h: Add ELFCOMPRESS_ZSTD.
+
+2022-08-02 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Correct the return type of the have_regset method.
+ During the development of 40c23d880386d6e8202567eaa2a6b041feb1a652,
+ the return value of fbsd_nat_target::have_regset was changed from a
+ simple boolean to returning the size of the register set. The
+ comments and callers were all updated for this change, but the actual
+ return type was accidentally left as a bool. This change fixes the
+ return type to be a size_t.
+
+ Current callers of this only checked the value against 0 and thus
+ still worked correctly.
+
+2022-08-02 Jan Beulich <jbeulich@suse.com>
+
+ ELF: emit symbol table when there are relocations
+ Even when there are no symbols (e.g. all relocations being against
+ absolute values), a symbol table (with just the first placeholder entry)
+ needs to be emitted. Otherwise tools like objdump won't properly process
+ the relocations. The respective checks in assign_section_numbers() and
+ _bfd_elf_compute_section_file_positions() support also this view. Oddly
+ enough so far HAS_RELOC was only set when reading in an object file, but
+ not when generating one anew; the flag would only have been cleared when
+ no relocations were found (anymore).
+
+ While there also amend the affected function's leading comment to also
+ mention gas.
+
+2022-08-02 Matthew Malcomson <hardenedapple@gmail.com>
+
+ ld: aarch64: Adjust TLS relaxation condition
+ In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we
+ choose whether to perform a relaxation to an IE access model or an LE
+ access model based on whether the symbol itself is marked as local (i.e.
+ `h == NULL`).
+
+ This is problematic in two ways. The first is that sometimes a global
+ dynamic access can be relaxed to an initial exec access when creating a
+ shared library, and if that happens on a local symbol then we currently
+ relax it to a local exec access instead. This usually does not happen
+ since we only relax an access if aarch64_can_relax_tls returns true and
+ aarch64_can_relax_tls does not have the same problem. However, it can
+ happen when we have seen both an IE and GD access on the same symbol.
+ This case is exercised in the newly added testcase tls-relax-gd-ie-2.
+
+ The second problem is that deciding based on whether the symbol is local
+ misses the case when the symbol is global but is still non-interposable
+ and known to be located in the executable. This happens on all global
+ symbols in executables.
+ This case is exercised in the newly added testcase tls-relax-ie-le-4.
+
+ Here we adjust the condition we base our relaxation on so that we relax
+ to local-exec if we are creating an executable and the relevant symbol
+ we're accessing is stored inside that executable.
+
+ -- Updating tests for new relaxation criteria
+
+ Many of the tests added to check our relaxation to IE were implemented
+ by taking advantage of the fact that we did not relax a global symbol
+ defined in an executable.
+
+ Since a global symbol defined in an executable is still not
+ interposable, we know that a TLS version of such a symbol will be in the
+ main TLS block. This means that we can perform a stronger relaxation on
+ such symbols and relax their accesses to a local-exec access.
+
+ Hence we have to update all tests that relied on the older suboptimal
+ decision making.
+
+ The two cases when we still would want to relax a general dynamic access
+ to an initial exec one are:
+ 1) When in a shared library and accessing a symbol which we have already
+ seen accessed with an initial exec access sequence.
+ 2) When in an executable and accessing a symbol defined in a shared
+ library.
+
+ Both of these require shared library support, which means that these
+ tests are now only available on targets with that.
+
+ I have chosen to switch the existing testcases from a plain executable
+ to one dynamically linked to a shared object as that doesn't require
+ changing the testcases quite so much (just requires accessing a
+ different variable rather than requiring adding another code sequence).
+
+ The tls-relax-all testcase was an outlier to the above approach, since
+ it included a general dynamic access to both a local and global symbol
+ and inspected for the difference accordingly.
+
+2022-08-02 Matthew Malcomson <hardenedapple@gmail.com>
+
+ ld: aarch64: Update test linker scripts relocs.ld and relocs-ilp32.ld
+ The updates are to ensure that the .data section exists. This means
+ that we always have a data section. That means that we don't create a
+ RWX segment and avoid the corresponding warning.
+
+ We get this warning when testing aarch64-none-elf with -mcmodel=tiny.
+ N.b. this changes quite a few testcases from fail to pass.
+
+2022-08-02 Victor Do Nascimento <Victor.DoNascimento@arm.com>
+
+ arm: Add cfi expression support for ra_auth_code
+ This patch extends assembler support for the use of register names to
+ allow for pseudo-registers, e.g. ra_auth_code register.
+ This is done particularly with CFI directives in mind, allowing for
+ expressions of the type:
+
+ .cfi_register ra_auth_code, 12
+
+ gas/Changelog:
+
+ * config/tc-arm.c (tc_arm_regname_to_dw2regnum): Add
+ REG_TYPE_PSEUDO handling.
+ * testsuite/gas/arm/cfi-pacbti-m-readelf.d: New.
+ * testsuite/gas/arm/cfi-pacbti-m.s: New.
+
+2022-08-02 Victor Do Nascimento <Victor.DoNascimento@arm.com>
+
+ arm: Use DWARF numbering convention for pseudo-register representation
+ This patch modifies the internal `struct reg_entry' numbering of DWARF
+ pseudo-registers to match values assigned in DWARF standards (see "4.1
+ DWARF register names" in [1])so ra_auth_code goes from 12 to 143 and
+ amends the unwinder .save directive-processing code to correctly handle
+ mixed register-type save directives.
+
+ The mechanism for splitting the register list is also re-written to
+ comply with register ordering on push statements, being that registers
+ are stored on the stack in numerical order, with the lowest numbered
+ register at the lowest address [2].
+
+ Consequently, the parsing of the hypothetical directive
+
+ .save{r4-r7, r10, ra_auth_core, lr}
+
+ has been changed such as rather than producing
+
+ .save{r4-r7, r10}
+ .save{ra_auth_code}
+ .save{lr}
+
+ as was the case with previous implementation, now produces:
+
+ .save{lr}
+ .save{ra_auth_code}
+ .save{r4-r7, r10}
+
+ [1] <https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst>
+ [2] <https://developer.arm.com/documentation/dui0473/j/arm-and-thumb-instructions/push>
+
+ gas/Changelog:
+
+ * config/tc-arm.c (REG_RA_AUTH_CODE): New.
+ (parse_dot_save): Likewise.
+ (parse_reg_list): Remove obsolete code.
+ (reg_names): Set ra_auth_code to 143.
+ (s_arm_unwind_save): Handle core and pseudo-register lists via
+ parse_dot_save.
+ (s_arm_unwind_save_mixed): Deleted.
+ (s_arm_unwind_save_pseudo): Handle one register at a time.
+ * testsuite/gas/arm/unwind-pacbti-m-readelf.d: Fix test.
+ * testsuite/gas/arm/unwind-pacbti-m.d: Likewise.
+
+2022-08-02 Alan Modra <amodra@gmail.com>
+
+ PE objdump -x
+ objdump -x on PE executables produces lots of "xdata section corrupt"
+ and "corrupt unwind data" warnings, and refuses to dump that info. It
+ turns out that the sanity checks were bad, not the data. Fix them.
+
+ * pei-x86_64.c (pex64_get_unwind_info): Correct buffer overrun
+ sanity checks.
+ (pex64_xdata_print_uwd_codes): Similarly.
+
+2022-08-02 Jan Beulich <jbeulich@suse.com>
+
+ x86: XOP shift insns don't really allow B suffix
+ By mistake it was permitted to be used from the very introduction of XOP
+ support.
+
+2022-08-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-08-01 Martin Storsjö <martin@martin.st>
+
+ ld: Support the -exclude-symbols option via COFF def files, with the EXCLUDE_SYMBOLS keyword
+ This was requested in review.
+
+ ld: Add support for a new option, -exclude-symbols, in COFF object file directives
+ This maps to the same as ld's --exclude-symbols command line option,
+ but allowing specifying the option via directives embedded in the
+ object files instead of passed manually on the command line.
+
+2022-08-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix .debug_aranges duplicate offset warning
+ The function read_addrmap_from_aranges contains code to issue a warning:
+ ...
+ if (!insertpair.second)
+ {
+ warning (_("Section .debug_aranges in %s has duplicate "
+ "debug_info_offset %s, ignoring .debug_aranges."),
+ objfile_name (objfile), sect_offset_str (per_cu->sect_off));
+ return false;
+ }
+ ...
+ but the warning is in fact activated when all_comp_units has duplicate
+ entries, which is very misleading.
+
+ Fix this by:
+ - adding a test-case that should trigger the warning,
+ - replacing the current implementation of the warning with an
+ assert that all_comp_units should not contain duplicates, and
+ - properly re-implementing the warning, such that it is triggered
+ by the test-case.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381
+
+2022-08-01 Jan Beulich <jbeulich@suse.com>
+
+ x86: SKINIT with operand needs IgnoreSize
+ Without it in 16-bit mode a pointless operand size prefix would be
+ emitted.
+
+2022-08-01 WANG Xuerui <git@xen0n.name>
+
+ opcodes: LoongArch: add "ret" instruction to reduce typing
+ This syntactic sugar is present in both classical and emerging
+ architectures, like Alpha, SPARC and RISC-V, and assembler macros
+ doing the same thing can already be found in the wild e.g. [1], proving
+ the feature's popularity. It's better to provide support directly in the
+ assembler so downstream users wouldn't have to re-invent this over and
+ over again.
+
+ [1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/loongarch/sysdep.h;h=c586df819cd90;hb=HEAD#l28
+
+2022-08-01 WANG Xuerui <git@xen0n.name>
+
+ opcodes: LoongArch: make all non-native jumps desugar to canonical b{lt/ge}[u] forms
+ Also re-order the jump/branch opcodes while at it, so that insns are
+ sorted in ascending order according to opcodes, and the label form
+ preceding the real definition.
+
+2022-08-01 Alan Modra <amodra@gmail.com>
+
+ Get rid of fprintf_vma and sprintf_vma
+ These two macros print either a 16 digit hex number or an 8 digit
+ hex number. Unfortunately they depend on both target and host, which
+ means that the output for 32-bit targets may be either 8 or 16 hex
+ digits.
+
+ Replace them in most cases with code that prints a bfd_vma using
+ PRIx64. In some cases, deliberately lose the leading zeros.
+ This change some output, notably in base/offset fields of m68k
+ disassembly which I think looks better that way, and in error
+ messages. I've kept leading zeros in symbol dumps (objdump -t)
+ and in PE header dumps.
+
+ bfd/
+ * bfd-in.h (fprintf_vma, sprintf_vma, printf_vma): Delete.
+ * bfd-in2.h: Regenerate.
+ * bfd.c (bfd_sprintf_vma): Don't use sprintf_vma.
+ (bfd_fprintf_vma): Don't use fprintf_vma.
+ * coff-rs6000.c (xcoff_reloc_type_tls): Don't use sprintf_vma.
+ Instead use PRIx64 to print bfd_vma values.
+ (xcoff_ppc_relocate_section): Likewise.
+ * cofflink.c (_bfd_coff_write_global_sym): Likewise.
+ * mmo.c (mmo_write_symbols_and_terminator): Likewise.
+ * srec.c (srec_write_symbols): Likewise.
+ * elf32-xtensa.c (print_r_reloc): Similarly for fprintf_vma.
+ * pei-x86_64.c (pex64_dump_xdata): Likewise.
+ (pex64_bfd_print_pdata_section): Likewise.
+ * som.c (som_print_symbol): Likewise.
+ * ecoff.c (_bfd_ecoff_print_symbol): Use bfd_fprintf_vma.
+ opcodes/
+ * dis-buf.c (perror_memory, generic_print_address): Don't use
+ sprintf_vma. Instead use PRIx64 to print bfd_vma values.
+ * i386-dis.c (print_operand_value, print_displacement): Likewise.
+ * m68k-dis.c (print_base, print_indexed): Likewise.
+ * ns32k-dis.c (print_insn_arg): Likewise.
+ * ia64-gen.c (_opcode_int64_low, _opcode_int64_high): Delete.
+ (opcode_fprintf_vma): Delete.
+ (print_main_table): Use PRIx64 to print opcode.
+ binutils/
+ * od-macho.c: Replace all uses of printf_vma with bfd_printf_vma.
+ * objcopy.c (copy_object): Don't use sprintf_vma. Instead use
+ PRIx64 to print bfd_vma values.
+ (copy_main): Likewise.
+ * readelf.c (CHECK_ENTSIZE_VALUES): Likewise.
+ (dynamic_section_mips_val): Likewise.
+ (print_vma): Don't use printf_vma. Instead use PRIx64 to print
+ bfd_vma values.
+ (dump_ia64_vms_dynamic_fixups): Likewise.
+ (process_version_sections): Likewise.
+ * rddbg.c (stab_context): Likewise.
+ gas/
+ * config/tc-i386.c (offset_in_range): Don't use sprintf_vma.
+ Instead use PRIx64 to print bfd_vma values.
+ (md_assemble): Likewise.
+ * config/tc-mips.c (load_register, macro): Likewise.
+ * messages.c (as_internal_value_out_of_range): Likewise.
+ * read.c (emit_expr_with_reloc): Likewise.
+ * config/tc-ia64.c (note_register_values): Don't use fprintf_vma.
+ Instead use PRIx64 to print bfd_vma values.
+ (print_dependency): Likewise.
+ * listing.c (list_symbol_table): Use bfd_sprintf_vma.
+ * symbols.c (print_symbol_value_1): Use %p to print pointers.
+ (print_binary): Likewise.
+ (print_expr_1): Use PRIx64 to print bfd_vma values.
+ * write.c (print_fixup): Use %p to print pointers. Don't use
+ fprintf_vma.
+ * testsuite/gas/all/overflow.l: Update expected output.
+ * testsuite/gas/m68k/mcf-mov3q.d: Likewise.
+ * testsuite/gas/m68k/operands.d: Likewise.
+ * testsuite/gas/s12z/truncated.d: Likewise.
+ ld/
+ * deffilep.y (def_file_print): Don't use fprintf_vma. Instead
+ use PRIx64 to print bfd_vma values.
+ * emultempl/armelf.em (gld${EMULATION_NAME}_finish): Don't use
+ sprintf_vma. Instead use PRIx64 to print bfd_vma values.
+ * emultempl/pe.em (gld${EMULATION_NAME}_finish): Likewise.
+ * ldlang.c (lang_map): Use %V to print region origin.
+ (lang_one_common): Don't use sprintf_vma.
+ * ldmisc.c (vfinfo): Don't use fprintf_vma or sprintf_vma.
+ * pe-dll.c (pe_dll_generate_def_file): Likewise.
+ gdb/
+ * remote.c (remote_target::trace_set_readonly_regions): Replace
+ uses of sprintf_vma with bfd_sprintf_vma.
+
+2022-08-01 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Set defaults to exec stack 0.
+
+2022-08-01 Alan Modra <amodra@gmail.com>
+
+ libctf: Avoid use of uninitialised variables
+ * ctf-link.c (ctf_link_add_ctf_internal): Don't free uninitialised
+ pointers.
+
+2022-08-01 Alan Modra <amodra@gmail.com>
+
+ PR29348, BFD_VMA_FMT wrong
+ There is a problem with my commit 0e3c1eebb2, which replaced
+ bfd_uint64_t with uint64_t: Some hosts typedef int64_t to long long
+ even when long is the same size as long long. That confuses the code
+ choosing one of "l", "ll", or "I64" for BFD_VMA_FMT, and results in
+ warnings.
+
+ Write a direct configure test for the printf int64_t style instead.
+ This removes the last use of BFD_HOST_64BIT_LONG, so delete that.
+ Note that the changes to configure.com are pure guesswork.
+
+ PR 29348
+ * bfd-in.h (BFD_HOST_64BIT_LONG): Don't define.
+ (BFD_VMA_FMT): Define using BFD_INT64_FMT when 64-bit.
+ (bfd_vma, bfd_signed_vma): Move comments to 64-bit typedefs.
+ * configure.ac (BFD_HOST_64BIT_LONG): Delete.
+ (BFD_INT64_FMT): New config test.
+ * configure.com: Update similarly.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Regenerate.
+ * configure: Regenerate.
+
+2022-08-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/literals.exp with aarch64
+ On aarch64-linux, I run into:
+ ...
+ (gdb) print 16#ffffffffffffffff#^M
+ $7 = 18446744073709551615^M
+ (gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff#
+ ...
+ while on x86_64-linux instead, I get:
+ ...
+ (gdb) print 16#ffffffffffffffff#^M
+ $7 = -1^M
+ (gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff#
+ ...
+
+ We can easily reproduce this on x86_64-linux using:
+ ...
+ $ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \
+ -ex "print 16#ffffffffffffffff#"
+ $1 = -1
+ $ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \
+ -ex "print 16#ffffffffffffffff#"
+ $1 = 18446744073709551615
+ ...
+
+ With i386, we have:
+ ...
+ (gdb) p int_bits
+ $3 = 32
+ (gdb) p long_bits
+ $4 = 32
+ (gdb) p long_long_bits
+ $5 = 64
+ ...
+ and so in processInt we hit the fits-in-unsigned-long-long case where we use
+ as type long long:
+ ...
+ /* Note: Interprets ULLONG_MAX as -1. */
+ yylval.typed_val.type = type_long_long (par_state);
+ ...
+
+ With aarch64, we have instead:
+ ...
+ (gdb) p int_bits
+ $1 = 32
+ (gdb) p long_bits
+ $2 = 64
+ (gdb) p long_long_bits
+ $3 = 64
+ ...
+ and so in processInt we hit the fits-in-unsigned-long case where we use
+ as type unsigned long:
+ ...
+ yylval.typed_val.type
+ = builtin_type (par_state->gdbarch ())->builtin_unsigned_long;
+ ...
+
+ It's not clear why for ada we're using long long for the
+ fits-in-unsigned-long-long case.
+
+ Fix this by using unsigned long long for the fits-in-unsigned-long-long case,
+ meaning the new reference output is 18446744073709551615 instead of -1.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416
+
+2022-07-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: add macros test for source files compiled in various ways
+ Using different ways of passing source file paths to compilers results n
+ different file and directory paths in the line header. For example:
+
+ - gcc foo.c
+ - gcc ./foo.c
+ - gcc ../cwd/foo.c
+ - gcc $PWD/foo.c
+
+ Because of this, GDB sometimes failed to look up macros. The previous
+ patch fixed that as much as possible. This patch adds the corresponding
+ tests.
+
+ Add both a DWARF assembler-based test and a regular test. The DWARF
+ assembled-based one tests some hard-coded debug info based on what I
+ have observed some specific versions of gcc and clang generate. We want
+ to make sure that GDB keeps handling all these cases correctly, even if
+ it's not always clear whether they are really valid DWARF. Also, they
+ will be tested no matter what the current target compiler is for a given
+ test run.
+
+ The regular test is compiled using the target compiler, so it may help
+ find bugs when testing against some other toolchains than what was used
+ to generate the DWARF assembler-based test.
+
+ For the DWARF assembler-based test, add to testsuite/lib/dwarf.exp the
+ necessary code to generate a DWARF5 .debug_macro section. The design of
+ the new procs is based on what was done for rnglists and loclists.
+
+ To test against a specific compiler one can use this command, for
+ example:
+
+ $ make check TESTS="gdb.base/macro-source-path.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang --target_board unix/gdb:debug_flags=-gdwarf-5"
+
+ Change-Id: Iab8da498e57d10cc2a3d09ea136685d9278cfcf6
+
+2022-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove code to prepend comp dir in buildsym_compunit::start_subfile
+ The bit of code removed by this patch was introduced to fix the same
+ kind of problem that the previous patch fixes. That is, to try to match
+ existing subfiles when different name forms are used to refer to a same
+ file.
+
+ The thread for the patch that introduced this code is:
+
+ https://pi.simark.ca/gdb-patches/45F8CBDF.9090501@hq.tensilica.com/
+
+ The important bits are that the compiler produced a compilation unit
+ with:
+
+ DW_AT_name : test.c
+ DW_AT_comp_dir : /home/maxim/W/BadgerPass/PR_14999
+
+ and DWARF v2 line table with:
+
+ The Directory Table:
+ /home/maxim/W/BadgerPass/PR_14999
+
+ The File Name Table:
+ Entry Dir Time Size Name
+ 1 1 1173897037 152 test.c
+
+ Because the main symtab was created with only DW_AT_name, it was named
+ "test.c". And because the path built from the line header contained the
+ "directory" part, it was "/home/maxim/W/BadgerPass/PR_14999/test.c".
+ Because of this mismatch, thing didn't work, so they added this code to
+ prepend the compilation directory to the existing subfile names, so that
+ this specific case would work.
+
+ With the changes done earlier in this series, where subfiles are
+ identified using the "most complete path possible", this case would be
+ handled. The main subfile's would be
+ "/home/maxim/W/BadgerPass/PR_14999/test.c" from the start
+ (DW_AT_comp_dir + DW_AT_name). It's not so different from some DWARF 5
+ cases actually, which make the compilation directory explicit in the
+ line table header.
+
+ I therefore think that this code is no longer needed. It does feel like
+ a quick hack to make one specific case work, and we have a more general
+ solution now. Also, this code was introduced to work around a problem
+ in the DWARF debug info or the DWARF debug info reader. In general, I
+ think it's preferable for these hacks to be located in the specific
+ debug info reader code, rather than in the common code.
+
+ Even though this code was added to work around a DWARF reader problem,
+ it's possible that some other debug info reader has started taking
+ advantage of this code in the mean time. It's very difficult to
+ know or verify, but I think the likelyhood is quite small, so I'm
+ proposing to get rid of it to simplify things a little bit.
+
+ Change-Id: I710b8ec0d449d1b110d67ddf9fcbdb2b37108306
+
+2022-07-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add "id" fields to identify symtabs and subfiles
+ Printing macros defined in the main source file doesn't work reliably
+ using various toolchains, especially when DWARF 5 is used. For example,
+ using the binaries produced by either of these commands:
+
+ $ gcc --version
+ gcc (GCC) 11.2.0
+ $ ld --version
+ GNU ld (GNU Binutils) 2.38
+ $ gcc test.c -g3 -gdwarf-5
+
+ $ clang --version
+ clang version 13.0.1
+ $ clang test.c -gdwarf-5 -fdebug-macro
+
+ I get:
+
+ $ ./gdb -nx -q --data-directory=data-directory a.out
+ (gdb) start
+ Temporary breakpoint 1 at 0x111d: file test.c, line 6.
+ Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out
+
+ Temporary breakpoint 1, main () at test.c:6
+ 6 return ZERO;
+ (gdb) p ZERO
+ No symbol "ZERO" in current context.
+
+ When starting to investigate this (taking the gcc-compiled binary as an
+ example), we see that GDB fails to look up the appropriate macro scope
+ when evaluating the expression. While stopped in
+ macro_lookup_inclusion:
+
+ (top-gdb) p name
+ $1 = 0x62100011a980 "test.c"
+ (top-gdb) p source.filename
+ $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c"
+
+ `source` is the macro_source_file that we would expect GDB to find.
+ `name` comes from the symtab::filename field of the symtab we are
+ stopped in. GDB doesn't find the appropriate macro_source_file because
+ the name of the macro_source_file doesn't match exactly the name of the
+ symtab.
+
+ The name of the main symtab comes from the compilation unit's
+ DW_AT_name, passed to the buildsym_compunit's constructor:
+
+ https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630
+
+ The contents of DW_AT_name, in this case, is "test.c". It is typically
+ (what I witnessed all compilers do) the same string that was passed to
+ the compiler on the command-line.
+
+ The name of the macro_source_file comes from the line number program
+ header's file table, from the call to the line_header::file_file_name
+ method:
+
+ https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65
+
+ line_header::file_file_name prepends the directory path that the file
+ entry refers to, in the file table (if the file name is not already
+ absolute). In this case, the file name is "test.c", appended to the
+ directory "/home/simark/build/binutils-gdb-one-target/gdb".
+
+ Because the symtab's name is not created the same way as the
+ macro_source_file's name is created, we get this mismatch. GDB fails to
+ find the appropriate macro scope for the symtab, and we can't print
+ macros when stopped in that symtab.
+
+ To make this work, we must ensure that paths produced in these two ways
+ end up identical. This can be tricky because of the different ways a
+ path can be passed to the compiler by the user.
+
+ Another thing to consider is that while the main symtab's name (or
+ subfile, before it becomes a symtab) is created using DW_AT_name, the
+ main symtab is also referred to using its entry in the line table
+ header's file table, when processing the line table. We must therefore
+ ensure that the same name is produced in both cases, so that a call to
+ "start_subfile" for the main subfile will correctly find the
+ already-created subfile, created by buildsym_compunit's constructor. If
+ we fail to do that, things still often work, because of a fallback: the
+ watch_main_source_file_lossage method. This method determines that if
+ the main subfile has no symbols but there exists another subfile with
+ the same basename (e.g. "test.c") that does have symbols, it's probably
+ because there was some filename mismatch. So it replaces the main
+ subfile with that other subfile. I think that heuristic is useful as a
+ last effort to work around any bug or bad debug info, but I don't think
+ we should design things such as to rely on it. It's a heuristic, it can
+ get things wrong. So in my search for a fix, it is important that given
+ some good debug info, we don't end up relying on that for things to
+ work.
+
+ A first attempt at fixing this was to try to prepend the compilation
+ directory here or not prepend it there. In practice, because of all the
+ possible combinations of debug info the compilers produce, it was not
+ possible to get something that would produce reliable, consistent paths.
+
+ Another attempt at fixing this was to make both macro_source_file
+ objects and symtab objects use the most complete form of path possible.
+ That means to prepend directories at least until we get an absolute
+ path. In theory, we should end up with the same path in all cases.
+ This generally worked, but because it changed the symtab names, it
+ resulted in user-visible changes (for example, paths to source files in
+ Breakpoint hit messages becoming always absolute). I didn't find this
+ very good, first because there is a "set filename-display" setting that
+ lets the user control how they want the paths to be displayed, and that
+ would suddenly make this setting completely ineffective (although even
+ today, it is a bit dependent on the debug info). Second, it would
+ require a good amount of testsuite tweaks to make tests accept these
+ suddenly absolute paths.
+
+ This new patch is a slight variation of that: it adds a new field called
+ "filename_for_id" in struct symtab and struct subfile, next to the
+ existing filename field. The goal is to separate the internal ids used
+ for finding objects from the names used for presentation. This field is
+ used for identifying subfiles, symtabs and macro_source_files
+ internally. For DWARF symtabs, this new field is meant to contain the
+ "most complete possible" path, as discussed above. So for a given file,
+ it must always be in the same form, everywhere. The existing
+ symtab::filename field remains the one used for printing to the user, so
+ there shouldn't be any change in how paths are printed.
+
+ Changes in the core symtab files are:
+
+ - Add "name_for_id" and "filename_for_id" fields to "struct subfile"
+ and "struct symtab", next to existing "name" and "filename" fields.
+ - Make buildsym_compunit::buildsym_compunit and
+ buildsym_compunit::start_subfile accept a "name_for_id" parameter
+ next to the existing "name" ones.
+ - Make buildsym_compunit::start_subfile use "name_for_id" for looking
+ up existing subfiles. This is the key thing for making calls
+ to start_subfile for the main source file look up the existing
+ subfile successfully, and avoid relying on
+ watch_main_source_file_lossage.
+ - Make sal_macro_scope pass "filename_for_id", rather than "filename",
+ to macro_lookup_inclusion. This is the key thing to making the
+ lookup work and macro printing work.
+
+ Changes in the DWARF files are:
+
+ - Make line_header::file_file_name return the "most complete possible"
+ name. The only pre-existing user of this method is the macro code,
+ to give the macro_source_file objects their name. And we now want
+ them to have this "most complete possible" name, which will match the
+ corresponding symtab's "filename_for_id".
+ - Make dwarf2_cu::start_compunit_symtab pass the "most complete
+ possible" name for the main symtab's "filename_for_id". In this
+ context, where the info comes from the compilation unit's DW_AT_name
+ / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if
+ DW_AT_name is not already absolute.
+ - Change dwarf2_start_subfile to build a name_for_id for the subfile
+ being started. The simplest way is to re-use
+ line_header::file_file_name, since the callers always have a
+ file_entry handy. This ensures that it will get the exact same path
+ representation as the macro code does, for the same file (since it
+ also uses line_header::file_file_name).
+ - Update calls to allocate_symtab to pass the "name_for_id" from the
+ subfile.
+
+ Tests exercising all this are added by the following patch.
+
+ Of all the cases I tried, the only one I found that ends up relying on
+ watch_main_source_file_lossage is the following one:
+
+ $ clang --version
+ clang version 13.0.1
+ Target: x86_64-pc-linux-gnu
+ Thread model: posix
+ InstalledDir: /usr/bin
+ $ clang ./test.c -g3 -O0 -gdwarf-4
+ $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out
+ ...
+ [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c
+ [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
+ [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c
+ [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c)
+ [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile
+
+ As we can see, there are two forms used for "test.c", one with a "." and
+ one without. This comes from the fact that the compilation unit DIE
+ contains:
+
+ DW_AT_name ("test.c")
+ DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb")
+
+ without a ".", and the line table for that file contains:
+
+ include_directories[ 1] = "."
+ file_names[ 1]:
+ name: "test.c"
+ dir_index: 1
+
+ When assembling the filename from that entry, we get a ".".
+
+ It is a bit unexpected that the main filename resulting from the line
+ table header does not match exactly the name in the compilation unit.
+ For instance, gcc uses "./test.c" for the DW_AT_name, which gives
+ identical paths in the compilation unit and in the line table header.
+
+ Similarly, with DWARF 5:
+
+ $ clang ./test.c -g3 -O0 -gdwarf-5
+
+ clang create two entries that refer to the same file but are of in a different
+ form.
+
+ include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb"
+ include_directories[ 1] = "."
+ file_names[ 0]:
+ name: "test.c"
+ dir_index: 0
+ file_names[ 1]:
+ name: "test.c"
+ dir_index: 1
+
+ The first file name produces a path without a "." while the second does.
+ This is not caught by watch_main_source_file_lossage, because of
+ dwarf_decode_lines that creates a symtab for each file entry in the line
+ table. It therefore appears as "non-empty" to
+ watch_main_source_file_lossage. This results in two symtabs:
+
+ (gdb) maintenance info symtabs
+ { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
+ { ((struct compunit_symtab *) 0x62100011aca0)
+ debugformat DWARF 5
+ producer clang version 13.0.1
+ name test.c
+ dirname /home/simark/build/binutils-gdb-one-target/gdb
+ blockvector ((struct blockvector *) 0x621000129ec0)
+ user ((struct compunit_symtab *) (null))
+ { symtab test.c ((struct symtab *) 0x62100011ad20)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ { symtab ./test.c ((struct symtab *) 0x62100011ad60)
+ fullname (null)
+ linetable ((struct linetable *) 0x621000129ef0)
+ }
+ }
+ }
+
+ I am not sure what is the consequence of this, but this is also what
+ happens before my patch, so I think its acceptable to leave it as-is.
+
+ To handle these two cases nicely, I think we will need a function that
+ removes the unnecessary "." from path names, something that can be done
+ later.
+
+ Finally, I made a change in find_file_and_directory is necessary to
+ avoid breaking test
+
+ gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42
+
+ Without that change, we would get:
+
+ (gdb) info source
+ Current source file is /dir/d/dw2-compdir-oldgcc42.S
+ Compilation directory is /dir/d
+
+ whereas the expected result is:
+
+ (gdb) info source
+ Current source file is dw2-compdir-oldgcc42.S
+ Compilation directory is /dir/d
+
+ This test was added here:
+
+ https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html
+
+ Long story short, GCC <= 4.2 apparently had a bug where it would
+ generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S")
+ and no DW_AT_comp_dir. The line table has one entry with filename
+ "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0
+ normally refers to the compilation unit's comp dir, but it is
+ non-existent in this case.
+
+ This caused some symtab lookup problems, and to work around them, some
+ workaround was added, which today reads as:
+
+ if (res.get_comp_dir () == nullptr
+ && producer_is_gcc_lt_4_3 (cu)
+ && res.get_name () != nullptr
+ && IS_ABSOLUTE_PATH (res.get_name ()))
+ res.set_comp_dir (ldirname (res.get_name ()));
+
+ Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432
+
+ It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no
+ DW_AT_comp_dir and DW_AT_name is absolute.
+
+ Prior to my patch, a subfile would get created with filename
+ "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get
+ created with filename "dw2-compdir-oldgcc42.S" from the line table's
+ file table. Then watch_main_source_file_lossage would kick in and merge
+ them, keeping only the "dw2-compdir-oldgcc42.S" one:
+
+ [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S)
+ [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile
+
+ And so "info source" would show "dw2-compdir-oldgcc42.S" as the
+ filename.
+
+ With my patch applied, but without the change in
+ find_file_and_directory, both DW_AT_name and the line table would try to
+ start a subfile with the same filename_for_id, and there was no need for
+ watch_main_source_file_lossage - which is what we want:
+
+ [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)
+ [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S
+ [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S)
+
+ But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming
+ from DW_AT_name, gets created first, it wins, and the symtab ends up
+ with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows
+ "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks.
+
+ This is not wrong per-se, after all DW_AT_name is
+ "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the
+ current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile
+ a file passing "/an/absolute/path.c", DW_AT_name typically contains (at
+ least with GCC) "/an/absolute/path.c" and GDB tells you that the source
+ file is "/an/absolute/path.c". But we can also keep the existing
+ behavior fairly easily with a little change in find_file_and_directory.
+ When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now
+ modify the name to just keep the file part. The result is coherent with
+ what compilers do when you compile a file by just passing its filename
+ ("gcc path.c -g"):
+
+ DW_AT_name ("path.c")
+ DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb")
+
+ With this change, filename_for_id is still the full name,
+ "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile /
+ symtab (what ends up shown by "info source") is just
+ "dw2-compdir-oldgcc42.S", and that makes the test happy.
+
+ Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
+
+2022-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf: pass a file_entry to line_header::file_file_name
+ In the following patch, there will be some callers of file_file_name
+ that will already have access to the file_entry object for which they
+ want the file name. It would be inefficient to have them pass an index,
+ only for line_header::file_file_name to re-lookup the same file_entry
+ object. Change line_header::file_file_name to accept a file_entry
+ object reference, instead of an index to look up.
+
+ I think this change makes sense in any case. Callers that have an index
+ can first obtain a file_entry using line_header::file_name_at or
+ line_header::file_names.
+
+ When passing a file_entry object, we can assume that the file_entry's
+ index is valid, unlike when passing an index. So, push the special case
+ about an invalid index to the sole current caller of file_file_name,
+ macro_start_file. I think that error belongs there anyway, since it
+ specifically talks about "bad file number in macro information".
+
+ This requires recording the file index in the file_entry structure, so
+ add that.
+
+ Change-Id: Ic6e44c407539d92b7863d7ba82405ade17f384ad
+
+2022-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/dwarf: pass compilation directory to line header
+ The following patch changes line_header::file_file_name to prepend the
+ compilation directory to the file name, if needed. For that, the line
+ header needs to know about the compilation directory. Prepare for that
+ by adding a constructor that takes it as a parameter, and passing the
+ value down everywhere needed. Add a second constructor for the special
+ case of building a line_header for doing a hash table lookup, since that
+ case doesn't require a compilation directory value.
+
+ Change-Id: Iba3ba0293e4e2d13a64b257cf9a3094684d54330
+
+2022-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add debug prints in buildsym.c
+ Add a few debug prints in buildsym.c that were helpful to me in writing
+ this series.
+
+ Change-Id: If10a818feaee3ce1b78a2a254013b62dd578002b
+
+2022-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce symtab_create_debug_printf
+ Introduce symtab_create_debug_printf and symtab_create_debug_printf_v,
+ to print the debug messages enabled by "set debug symtab-create".
+
+ Change-Id: I442500903f72d4635c2dd9eaef770111f317dc04
+
+2022-07-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/convvar_comp.exp with broken debug info
+ On aarch64-linux I run into this failure with gcc 7.5.0:
+ ...
+ (gdb) print $item.started^M
+ $1 = (-5312, 65535, 4202476)^M
+ (gdb) FAIL: gdb.ada/convvar_comp.exp: print $item.started
+ ...
+
+ The test-case expects (0, 0, 0), but we're getting another value due to
+ incorrect location information.
+
+ Work around this by:
+ - first printing the value, and then
+ - verifying that the convenience variable matches the printed value.
+
+ I've verified that the test-case still checks what it should by disabling
+ the fix from commit cc0e770c0d0 ("memory error printing component of record
+ from convenience variable") and observing the test-case fail.
+
+ Tested on x86_64-linux and aarch64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29420
+
+2022-07-29 Alan Modra <amodra@gmail.com>
+
+ Re: PR16005, avr linker crash on a particular instruction sequence with --relax
+ The last patch wasn't so clever. The contents in fact have already
+ been read, just not cached where relax_delete_bytes expects them.
+ relax_delete_bytes also modifies relocs and syms, so they should be
+ cached too.
+
+ PR 16005
+ * elf32-avr.c (elf32_avr_relax_delete_bytes): Revert last change.
+ (elf32_avr_relax_section): Cache contents, relocs and syms
+ before calling relax_delete_bytes.
+
+2022-07-29 Andrew Burgess <aburgess@redhat.com>
+
+ libopcodes/aarch64: add support for disassembler styling
+ This commit enables disassembler styling for AArch64. After this
+ commit it is possible to have objdump style AArch64 disassembler
+ output (using --disassembler-color option). Once the required GDB
+ patches are merged, GDB will also style the disassembler output.
+
+ The changes to support styling are mostly split between two files
+ opcodes/aarch64-dis.c and opcodes/aarch64-opc.c.
+
+ The entry point for the AArch64 disassembler can be found in
+ aarch64-dis.c, this file handles printing the instruction mnemonics,
+ and assembler directives (e.g. '.byte', '.word', etc). Some operands,
+ mostly relating to assembler directives are also printed from this
+ file. This commit changes all of this to pass through suitable
+ styling information.
+
+ However, for most "normal" instructions, the instruction operands are
+ printed using a two step process. From aarch64-dis.c, in the
+ print_operands function, the function aarch64_print_operand is called,
+ this function is in aarch64-opc.c, and converts an instruction operand
+ into a string. Then, back in print_operands (aarch64-dis.c), the
+ operand string is printed.
+
+ Unfortunately, the string returned by aarch64_print_operand can be
+ quite complex, it will include syntax elements, like '[' and ']', in
+ addition to register names and immediate values. In some cases, a
+ single operand will expand into what will appear (to the user) as
+ multiple operands separated with a ','.
+
+ This makes the task of styling more complex, all these different
+ components need to by styled differently, so we need to get the
+ styling information out of aarch64_print_operand in some way.
+
+ The solution that I propose here is similar to the solution that I
+ used for the i386 disassembler.
+
+ Currently, aarch64_print_operand uses snprintf to write the operand
+ text into a buffer provided by the caller.
+
+ What I propose is that we pass an extra argument to the
+ aarch64_print_operand function, this argument will be a structure, the
+ structure contains a callback function and some state.
+
+ When aarch64_print_operand needs to format part of its output this can
+ be done by using the callback function within the new structure, this
+ callback returns a string with special embedded markers that indicate
+ which mode should be used for each piece of text. Back in
+ aarch64-dis.c we can spot these special style markers and use this to
+ split the disassembler output up and apply the correct style to each
+ piece.
+
+ To make aarch64-opc.c clearer a series of new static functions have
+ been added, e.g. 'style_reg', 'style_imm', etc. Each of these
+ functions formats a piece of text in a different style, 'register' and
+ 'immediate' in this case.
+
+ Here's an example taken from aarch64-opc.c of the new functions in
+ use:
+
+ snprintf (buf, size, "[%s, %s]!",
+ style_reg (styler, base),
+ style_imm (styler, "#%d", opnd->addr.offset.imm));
+
+ The aarch64_print_operand function is also called from the assembler
+ to aid in printing diagnostic messages. Right now I have no plans to
+ add styling to the assembler output, and so, the callback function
+ used in the assembler ignores the styling information and just returns
+ an plain string.
+
+ I've used the source files in gas/testsuite/gas/aarch64/ for testing,
+ and have manually gone through and checked that the styling looks
+ reasonable, however, I'm not an AArch64 expert, so it is possible that
+ the odd piece is styled incorrectly. Please point out any mistakes
+ I've made.
+
+ With objdump disassembler color turned off, there should be no change
+ in the output after this commit.
+
+2022-07-29 Nick Clifton <nickc@redhat.com>
+
+ Stop the linker from complaining about unrecognised DW_FORM-rnglistx and DW_FORM_loclistx format attributes.
+ PR 29424
+ * dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and
+ DW_FORM_loclistx.
+
+2022-07-29 Alan Modra <amodra@gmail.com>
+
+ PR16005, avr linker crash on a particular instruction sequence with --relax
+ It's possible for relax_delete_bytes to be called with section
+ contents NULL, as demonstrated by the testcase in this PR.
+
+ PR 16005
+ * elf32-avr.c (elf32_avr_relax_delete_bytes): Get section contents
+ if not already available.
+
+2022-07-29 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop stray NoRex64 from KeyLocker insns
+ It's entirely unclear why some of the KeyLocker insns had NoRex64 on
+ them - there's nothing here which could cause emission of REX.W (except
+ of course a user-specified "rex.w", which we ought to honor anyway).
+
+2022-07-29 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: re-work PR gas/27217 fix
+ The original approach has resulted in anomalies when . is involved in an
+ operand of one of the affected insns. We cannot leave . unresolved, or
+ else it'll be resolved at the end of assembly, then pointing to the
+ address of a section rather than at the insn of interest. Undo part of
+ the original change and instead check whether a relocation cannot be
+ omitted in md_apply_fix().
+
+ By resolving the expressions again, equates (see the adjustment of the
+ respective testcase) will now be evaluated, and hence relocations
+ against absolute addresses be emitted. This ought to be okay as long as
+ the equates aren't global (and hence can't be overridden). If a need
+ for such arises, quite likely the only way to address this would be to
+ invent yet another expression evaluation mode, leaving everything
+ _except_ . un-evaluated.
+
+ There's a further anomaly in how transitive equates are handled. In
+
+ .set x, 0x12345678
+ .eqv bar, x
+ foo:
+ adrp x0, x
+ add x0, x0, :lo12:x
+
+ adrp x0, bar
+ add x0, x0, :lo12:bar
+
+ the first two relocations are now against *ABS*:0x12345678 (as said
+ above), whereas the latter two relocations would be against x. (Before
+ the change here, the first two relocations are against x and the latter
+ two against bar.) But this is an issue seen elsewhere as well, and would
+ likely require adjustments in the target-independent parts of the
+ assembler instead of trying to hack around this for every target.
+
+2022-07-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411]
+ As discussed in PR ld/29411, the ld warning
+
+ [...] has a LOAD segment with RWX permissions
+
+ needs to be disabled on all SPARC targets, not just Solaris/SPARC: the
+ .plt section is required to be RWX by the 32-bit SPARC ELF psABI and the
+ 64-bit SPARC Compliance Definition 2.4.1. Given that ld only supports
+ SPARC ELF targets, this patch implements this.
+
+ Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11.
+
+ 2022-07-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ ld:
+ PR ld/29411
+ * configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all
+ sparc targets. Expand comment.
+
+2022-07-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/killed-outside.exp on aarch64
+ On aarch64 (and likewise on arm), I run into:
+ ...
+ (gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
+ Executing on target: kill -9 11516 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 11516^M
+ continue^M
+ Continuing.^M
+ Unable to fetch general registers: No such process.^M
+ (gdb) [Thread 0xfffff7d511e0 (LWP 11518) exited]^M
+ ^M
+ Program terminated with signal SIGKILL, Killed.^M
+ The program no longer exists.^M
+ FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
+ ...
+ due to a mismatch between the actual "No such process" line and the expected
+ one:
+ ...
+ set no_such_process_msg "Couldn't get registers: No such process\."
+ ...
+
+ Fix this by updating the regexp.
+
+ Tested on aarch64-linux, and x86_64-linux.
+
+2022-07-29 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add `OP_V' to .insn named opcodes
+ This commit adds `OP_V' (OP-V: vector instruction opcode for now
+ ratified `V' extension) to .insn opcode name list. Although vector
+ instruction encoding is not implemented in `.insn' directive, it will
+ help future implementation of custom vector `.insn'.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (opcode_name_list): Add `OP_V'.
+ * testsuite/gas/riscv/insn.s: Add testcase.
+ * testsuite/gas/riscv/insn.d: Likewise.
+ * testsuite/gas/riscv/insn-dwarf.d: Reflect insn.s update.
+
+2022-07-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-28 Tom Tromey <tom@tromey.com>
+
+ Remove some unneeded checks in Guile code
+ The Guile code generally checks to see if an htab is non-null before
+ destroying it. However, the registry code already ensures this, so we
+ can change these checks to asserts and simplify the code a little.
+
+ Change registry to use less memory
+ The registry code creates "registry_data" objects that hold the free
+ function and the index; then the registry keys refer to this object.
+ However, only the index is really useful, and now that registries have
+ a private implementation, just the index can be stored and we can
+ reduce the memory use of registries a little bit. This also
+ simplifies the code somewhat.
+
+2022-07-28 Tom Tromey <tom@tromey.com>
+
+ Rewrite registry.h
+ This rewrites registry.h, removing all the macros and replacing it
+ with relatively ordinary template classes. The result is less code
+ than the previous setup. It replaces large macros with a relatively
+ straightforward C++ class, and now manages its own cleanup.
+
+ The existing type-safe "key" class is replaced with the equivalent
+ template class. This approach ended up requiring relatively few
+ changes to the users of the registry code in gdb -- code using the key
+ system just required a small change to the key's declaration.
+
+ All existing users of the old C-like API are now converted to use the
+ type-safe API. This mostly involved changing explicit deletion
+ functions to be an operator() in a deleter class.
+
+ The old "save/free" two-phase process is removed, and replaced with a
+ single "free" phase. No existing code used both phases.
+
+ The old "free" callbacks took a parameter for the enclosing container
+ object. However, this wasn't truly needed and is removed here as
+ well.
+
+2022-07-28 Tom Tromey <tom@tromey.com>
+
+ Remove some unused functions from guile code
+ The guile code has a couple of unused functions that touch on the
+ registry API. This patch removes them.
+
+2022-07-28 Tom Tromey <tom@tromey.com>
+
+ Change allocation of type-copying hash table
+ When an objfile is destroyed, types that are still in use and
+ allocated on that objfile are copied. A temporary hash map is created
+ during this process, and it is allocated on the destroyed objfile's
+ obstack -- which normally is fine, as that is going to be destroyed
+ shortly anyway.
+
+ However, this approach requires that the objfile be passed to registry
+ destruction, and this won't be possible in the rewritten registry.
+ This patch changes the copied type hash table to simply use the heap
+ instead. It also removes the 'objfile' parameter from
+ copy_type_recursive, to make this all more clear.
+
+ This patch also fixes an apparent bug in copy_type_recursive.
+ Previously it was copying the dynamic property list to the dying
+ objfile's obstack:
+
+ - = copy_dynamic_prop_list (&objfile->objfile_obstack,
+
+ However I think this is incorrect -- that obstack is about to be
+ destroyed.
+
+2022-07-28 Tom Tromey <tom@tromey.com>
+
+ Change address_space to use new and delete
+ This changes address_space to use new and delete, and makes some other
+ small C++-ification changes as well, like changing address_space_num
+ to be a method.
+
+ This patch was needed for the subsequent patch to rewrite the registry
+ system.
+
+2022-07-28 Simon Farre <simon.farre.cx@gmail.com>
+
+ gdb/python: Add BreakpointLocation type
+ PR python/18385
+
+ v7:
+ This version addresses the issues pointed out by Tom.
+
+ Added nullchecks for Python object creations.
+
+ Changed from using PyLong_FromLong to the gdb_py-versions.
+
+ Re-factored some code to make it look more cohesive.
+
+ Also added the more safe Python reference count decrement PY_XDECREF,
+ even though the BreakpointLocation type is never instantiated by the
+ user (explicitly documented in the docs) decrementing < 0 is made
+ impossible with the safe call.
+
+ Tom pointed out that using the policy class explicitly to decrement a
+ reference counted object was not the way to go, so this has instead been
+ wrapped in a ref_ptr that handles that for us in blocpy_dealloc.
+
+ Moved macro from py-internal to py-breakpoint.c.
+
+ Renamed section at the bottom of commit message "Patch Description".
+
+ v6:
+ This version addresses the points Pedro gave in review to this patch.
+
+ Added the attributes `function`, `fullname` and `thread_groups`
+ as per request by Pedro with the argument that it more resembles the
+ output of the MI-command "-break-list". Added documentation for these attributes.
+
+ Cleaned up left overs from copy+paste in test suite, removed hard coding
+ of line numbers where possible.
+
+ Refactored some code to use more c++-y style range for loops
+ wrt to breakpoint locations.
+
+ Changed terminology, naming was very inconsistent. Used a variety of "parent",
+ "owner". Now "owner" is the only term used, and the field in the
+ gdb_breakpoint_location_object now also called "owner".
+
+ v5:
+
+ Changes in response to review by Tom Tromey:
+ - Replaced manual INCREF/DECREF calls with
+ gdbpy_ref ptrs in places where possible.
+ - Fixed non-gdb style conforming formatting
+ - Get parent of bploc increases ref count of parent.
+ - moved bploc Python definition to py-breakpoint.c
+
+ The INCREF of self in bppy_get_locations is due
+ to the individual locations holding a reference to
+ it's owner. This is decremented at de-alloc time.
+
+ The reason why this needs to be here is, if the user writes
+ for instance;
+
+ py loc = gdb.breakpoints()[X].locations[Y]
+
+ The breakpoint owner object is immediately going
+ out of scope (GC'd/dealloced), and the location
+ object requires it to be alive for as long as it is alive.
+
+ Thanks for your review, Tom!
+
+ v4:
+ Fixed remaining doc issues as per request
+ by Eli.
+
+ v3:
+ Rewritten commit message, shortened + reworded,
+ added tests.
+
+ Patch Description
+
+ Currently, the Python API lacks the ability to
+ query breakpoints for their installed locations,
+ and subsequently, can't query any information about them, or
+ enable/disable individual locations.
+
+ This patch solves this by adding Python type gdb.BreakpointLocation.
+ The type is never instantiated by the user of the Python API directly,
+ but is produced by the gdb.Breakpoint.locations attribute returning
+ a list of gdb.BreakpointLocation.
+
+ gdb.Breakpoint.locations:
+ The attribute for retrieving the currently installed breakpoint
+ locations for gdb.Breakpoint. Matches behavior of
+ the "info breakpoints" command in that it only
+ returns the last known or currently inserted breakpoint locations.
+
+ BreakpointLocation contains 7 attributes
+
+ 6 read-only attributes:
+ owner: location owner's Python companion object
+ source: file path and line number tuple: (string, long) / None
+ address: installed address of the location
+ function: function name where location was set
+ fullname: fullname where location was set
+ thread_groups: thread groups (inferiors) where location was set.
+
+ 1 writeable attribute:
+ enabled: get/set enable/disable this location (bool)
+
+ Access/calls to these, can all throw Python exceptions (documented in
+ the online documentation), and that's due to the nature
+ of how breakpoint locations can be invalidated
+ "behind the scenes", either by them being removed
+ from the original breakpoint or changed,
+ like for instance when a new symbol file is loaded, at
+ which point all breakpoint locations are re-created by GDB.
+ Therefore this patch has chosen to be non-intrusive:
+ it's up to the Python user to re-request the locations if
+ they become invalid.
+
+ Also there's event handlers that handle new object files etc, if a Python
+ user is storing breakpoint locations in some larger state they've
+ built up, refreshing the locations is easy and it only comes
+ with runtime overhead when the Python user wants to use them.
+
+ gdb.BreakpointLocation Python type
+ struct "gdbpy_breakpoint_location_object" is found in python-internal.h
+
+ Its definition, layout, methods and functions
+ are found in the same file as gdb.Breakpoint (py-breakpoint.c)
+
+ 1 change was also made to breakpoint.h/c to make it possible
+ to enable and disable a bp_location* specifically,
+ without having its LOC_NUM, as this number
+ also can change arbitrarily behind the scenes.
+
+ Updated docs & news file as per request.
+
+ Testsuite: tests the .source attribute and the disabling of
+ individual locations.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
+
+
+ Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
+
+2022-07-28 yaowenbin <yaowenbin1@huawei.com>
+
+ gdb/gdb_mbuild.sh: use return instead of continue to avoid shellcheck error
+ Fix:
+
+ In gdb_mbuild.sh line 174:
+ continue
+ ^------^ SC2104 (error): In functions, use return instead of continue.
+
+ Change-Id: I5ce95b01359c5cfbb1612f2f48b80bfeea66c96c
+
+2022-07-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: check for the makeinfo version
+ gprofng/ChangeLog
+ 2022-07-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29368
+ * configure.ac: Check for the makeinfo version.
+ * configure: Rebuild.
+
+2022-07-26 Keith Seitz <keiths@redhat.com>
+
+ gdb/linux_nat: Write memory using ptrace if /proc/pid/mem is not writable
+ Commit 05c06f318fd9a112529dfc313e6512b399a645e4 enabled GDB to access
+ memory while threads are running. It did this by accessing
+ /proc/PID/task/LWP/mem.
+
+ Unfortunately, this interface is not implemented for writing in older
+ kernels (such as RHEL6). This means that GDB is unable to insert
+ breakpoints on these hosts:
+
+ $ ./gdb -q gdb -ex start
+ Reading symbols from gdb...
+ Temporary breakpoint 1 at 0x40fdd5: file ../../src/gdb/gdb.c, line 28.
+ Starting program: /home/rhel6/fsf/linux/gdb/gdb
+ Warning:
+ Cannot insert breakpoint 1.
+ Cannot access memory at address 0x40fdd5
+
+ (gdb)
+
+ Before this patch, linux_proc_xfer_memory_partial (previously called
+ linux_proc_xfer_partial) would return TARGET_XFER_EOF if the write to
+ /proc/PID/mem failed. [More specifically, linux_proc_xfer_partial
+ would not "bother for one word," but the effect is the essentially
+ same.]
+
+ This status was checked by linux_nat_target::xfer_partial, which would
+ then fallback to using ptrace to perform the operation.
+
+ This is the specific hunk that removed the fallback:
+
+ - xfer = linux_proc_xfer_partial (object, annex, readbuf, writebuf,
+ - offset, len, xfered_len);
+ - if (xfer != TARGET_XFER_EOF)
+ - return xfer;
+ + return linux_proc_xfer_memory_partial (readbuf, writebuf,
+ + offset, len, xfered_len);
+ + }
+
+ return inf_ptrace_target::xfer_partial (object, annex, readbuf, writebuf,
+ offset, len, xfered_len);
+
+ This patch makes linux_nat_target::xfer_partial go straight to writing
+ memory via ptrace if writing via /proc/pid/mem is not possible in the
+ running kernel, enabling GDB to insert breakpoints on these older
+ kernels. Note that a recent patch changed the return status from
+ TARGET_XFER_EOF to TARGET_XFER_E_IO.
+
+ Tested on {unix,native-gdbserver,native-extended-gdbserver}/-m{32,64}
+ on x86_64, s390x, aarch64, and ppc64le.
+
+ Change-Id: If1d884278e8c4ea71d8836bedd56e6a6c242a415
+
+2022-07-26 Pedro Alves <pedro@palves.net>
+
+ gdb/linux-nat: Check whether /proc/pid/mem is writable
+ Probe whether /proc/pid/mem is writable, by using it to write to a GDB
+ variable. This will be used in the following patch to avoid falling
+ back to writing to inferior memory with ptrace if /proc/pid/mem _is_
+ writable.
+
+ Change-Id: If87eff0b46cbe5e32a583e2977a9e17d29d0ed3e
+
+2022-07-26 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Handle the function return value
+ According to LoongArch ELF ABI specification [1], handle the function
+ return value of various types.
+
+ [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_return_values
+
+2022-07-26 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Fix code style issues
+ Fix some code style issues suggested by Tom Tromey and Andrew Burgess,
+ thank you.
+
+ (1) Put an introductory comment to explain the purpose for some functions.
+
+ (2) Modify the the attribute code to make it portable.
+
+ (3) Remove globals and pass pointers to locals.
+
+ (4) Remove "*" in the subsequent comment lines.
+
+ (5) Put two spaces before "{" and "}".
+
+2022-07-26 Nick Clifton <nickc@redhat.com>
+
+ Stop the linker from complaining about RWX segments in sparc-solaris targets.
+ PR 29411
+ * configure.tgt (ac_default_ld_warn_rwx_segments): Disable for
+ sparc-solaris configurations.
+
+2022-07-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.opt/inline-small-func.exp with clang
+ When running test-case gdb.opt/inline-small-func.exp with clang 12.0.1, I run
+ into:
+ ...
+ gdb compile failed, /usr/bin/ld: inline-small-func0.o: in function `main':
+ inline-small-func.c:21: undefined reference to `callee'
+ clang-12.0: error: linker command failed with exit code 1 \
+ (use -v to see invocation)
+ UNTESTED: gdb.opt/inline-small-func.exp: failed to prepare
+ ...
+
+ Fix this by using __attribute__((always_inline)).
+
+ Tested on x86_64-linux.
+
+2022-07-26 Alan Modra <amodra@gmail.com>
+
+ PowerPC32 ld test fails with --enable-targets=all
+ Three pppc32 ld tests fail when spe support is included in the linker
+ due to this snippet in ld/emulparams/elf32ppc.sh.
+
+ if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then
+ DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*)
+ PROVIDE (__spe_handle = .);
+ *(.data.spehandle)
+ . += 4 * (DEFINED (__spe_handle) || . != 0);}"
+ fi
+
+ * testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present.
+ * testsuite/ld-powerpc/tlsexe32no.r: Likewise.
+ * testsuite/ld-powerpc/tlsso32.r: Likewise.
+
+2022-07-26 Enze Li <enze.li@hotmail.com>
+
+ gdb/hurd: pass memory_tagged as false to find_memory_region_ftype
+ I tried building GDB on GNU/Hurd, and ran into this error:
+
+ CXX gnu-nat.o
+ gnu-nat.c: In member function ‘virtual int gnu_nat_target::find_memory_regions(find_memory_region_ftype, void*)’:
+ gnu-nat.c:2620:21: error: too few arguments to function
+ 2620 | (*func) (last_region_address,
+ | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
+ 2621 | last_region_end - last_region_address,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2622 | last_protection & VM_PROT_READ,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2623 | last_protection & VM_PROT_WRITE,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2624 | last_protection & VM_PROT_EXECUTE,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2625 | 1, /* MODIFIED is unknown, pass it as true. */
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2626 | data);
+ | ~~~~~
+ gnu-nat.c:2635:13: error: too few arguments to function
+ 2635 | (*func) (last_region_address, last_region_end - last_region_address,
+ | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2636 | last_protection & VM_PROT_READ,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2637 | last_protection & VM_PROT_WRITE,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2638 | last_protection & VM_PROT_EXECUTE,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2639 | 1, /* MODIFIED is unknown, pass it as true. */
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 2640 | data);
+ | ~~~~~
+ make[2]: *** [Makefile:1926: gnu-nat.o] Error 1
+
+ This is because in this commit:
+
+ commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
+ Date: Thu Mar 31 11:42:35 2022 +0100
+
+ [AArch64] MTE corefile support
+
+ Added a new argument to find_memory_region_ftype, but did not pass it to
+ the function in gnu-nat.c. Fix this by passing memory_tagged as false.
+
+ As Luis pointed out, similar bugs may also appear on FreeBSD and NetBSD,
+ and I have reproduced them on both systems. This patch fixes them
+ incidentally.
+
+ Tested by rebuilding on GNU/Hurd, FreeBSD/amd64 and NetBSD/amd64.
+
+2022-07-26 Enze Li <enze.li@hotmail.com>
+
+ gdb/netbsd: add missing header file
+ I ran into this error when building GDB on NetBSD:
+
+ CXX netbsd-nat.o
+ netbsd-nat.c: In member function 'virtual bool nbsd_nat_target::info_proc(const char*, info_proc_what)':
+ netbsd-nat.c:314:3: error: 'gdb_argv' was not declared in this scope
+ gdb_argv built_argv (args);
+ ^~~~~~~~
+ netbsd-nat.c:314:3: note: suggested alternative: 'gdbarch'
+ gdb_argv built_argv (args);
+ ^~~~~~~~
+ gdbarch
+ netbsd-nat.c:315:7: error: 'built_argv' was not declared in this scope
+ if (built_argv.count () == 0)
+ ^~~~~~~~~~
+ netbsd-nat.c:315:7: note: suggested alternative: 'buildargv'
+ if (built_argv.count () == 0)
+ ^~~~~~~~~~
+ buildargv
+ gmake[2]: *** [Makefile:1893: netbsd-nat.o] Error 1
+
+ Fix this by adding the missing header file, as it is obvious.
+
+ Tested by rebuilding on NetBSD/amd64.
+
+2022-07-26 Nick Clifton <nickc@redhat.com>
+
+ Updated translations for various sub-directories
+
+2022-07-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: rename gdbarch_tdep struct to fix g++ 4.8 build
+ After the commit:
+
+ commit 08106042d9f5fdff60c129bf33190639f1a98b2a
+ Date: Thu May 19 13:20:17 2022 +0100
+
+ gdb: move the type cast into gdbarch_tdep
+
+ GDB would no longer build using g++ 4.8. The issue appears to be some
+ confusion caused by GDB having 'struct gdbarch_tdep', but also a
+ templated function called 'gdbarch_tdep'. Prior to the above commit
+ the gdbarch_tdep function was not templated, and this compiled just
+ fine. Note that the above commit compiles just fine with later
+ versions of g++, so this issue was clearly fixed at some point, though
+ I've not tried to track down exactly when.
+
+ In this commit I propose to fix the g++ 4.8 build problem by renaming
+ 'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename
+ better represents that the struct is only ever used as a base class,
+ and removes the overloading of the name, which allows GDB to build
+ with g++ 4.8.
+
+ I've also updated the comment on 'struct gdbarch_tdep_base' to fix a
+ typo, and the comment on the 'gdbarch_tdep' function, to mention that
+ in maintainer mode a run-time type check is performed.
+
+2022-07-26 Nick Clifton <nickc@redhat.com>
+
+ Fix indentation in loongarch code, preventing a compile time warning.
+
+2022-07-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/varobj: Fix varobj_invalidate_iter
+ The varobj_invalidate function is meant to be called when restarting a
+ process, and check at this point if some of the previously existing
+ varobj can be recreated in the context of the new process.
+
+ Two kind of varobj are subject to re-creation: global varobj (i.e.
+ varobj which reference a global variable), and floating varobj (i.e.
+ varobj which are always re-evaluated in the context of whatever is
+ the currently selected frame at the time of evaluation).
+
+ However, in the re-creation process, the varobj_invalidate_iter
+ recreates floating varobj as non-floating, due to an invalid parameter.
+ This patches fixes this and adds an assertion to check that if a varobj
+ is indeed recreated, it matches the original varobj "floating" property.
+
+ Another issue is that if at this recreation time the expression watched
+ by the floating varobj is not in scope, then the varobj is marked as
+ invalid. If later the user selects a frame where the expression becomes
+ valid, the varobj remains invalid and this is wrong. This patch also
+ make sure that floating varobj are not invalidated if they cannot be
+ evaluated.
+
+ The last important thing to note is that due to the previous patch, when
+ varobj_invalidate is executed (in the context of a new process), any
+ global var have already been invalidated (this has been done when the
+ objfile it referred to got invalidated). As a consequence,
+ varobj_invalidate tries to recreate vars which are already marked as
+ invalid. This does not entirely feels right, but I keep this behavior
+ for backward compatibility.
+
+ Tested on x86_64-linux
+
+2022-07-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/varobj: Fix use after free in varobj
+ Varobj object contains references to types, variables (i.e. struct
+ variable) and expression. All of those can reference data on an
+ objfile's obstack. It is possible for this objfile to be deleted (and
+ the obstack to be feed), while the varobj remains valid. Later, if the
+ user uses the varobj, this will result in a use-after-free error. With
+ address sanitizer build, this leads to a plain error. For non address
+ sanitizer build we might see undefined behaviour, which manifest
+ themself as assertion failures when accessing data backed by feed
+ memory.
+
+ This can be observed if we create a varobj that refers to ta symbol in a
+ shared library, after either the objfile gets reloaded (using the `file`
+ command) or after the shared library is unloaded (with a call to dlclose
+ for example).
+
+ This patch fixes those issues by:
+
+ - Adding cleanup procedure to the free_objfile observable. When
+ activated this observer clears expressions referencing the objfile
+ being freed, and removes references to blocks belonging to this
+ objfile.
+ - Adding varobj support in the `preserve_values` (gdb.value.c). This
+ ensures that before the objfile is unloaded, any type owned by the
+ objfile referenced by the varobj is replaced by an equivalent type
+ not owned by the objfile. This process is done here instead of in the
+ free_objfile observer in order to reuse the type hash table already
+ used for similar purpose when replacing types of values kept in the
+ value history.
+
+ This patch also makes sure to keep a reference to the expression's
+ gdbarch and language_defn members when the varobj->root->exp is
+ initialized. Those structures outlive the objfile, so this is safe.
+ This is done because those references might be used initialize a python
+ context even after exp is invalidated. Another approach could have been
+ to initialize the python context with default gdbarch and language_defn
+ (i.e. nullptr) if expr is NULL, but since we might still try to display
+ the value which was obtained by evaluating exp when it was still valid,
+ keeping track of the context which was used at this time seems
+ reasonable.
+
+ Tested on x86_64-Linux.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2022-07-26 Pedro Alves <pedro@palves.net>
+
+ MI: mi_runto -pending
+ With the CLI testsuite's runto proc, we can pass "allow-pending" as an
+ option, like:
+
+ runto func allow-pending
+
+ That is currently not possible with MI's mi_runto, however. This
+ patch makes it possible, by adding a new "-pending" option to
+ mi_runto.
+
+ A pending breakpoint shows different MI attributes compared to a
+ breakpoint with a location, so the regexp returned by
+ mi_make_breakpoint isn't suitable. Thus, add a new
+ mi_make_breakpoint_pending proc for pending breakpoints.
+
+ Tweak mi_runto to let it take and pass down arguments.
+
+ Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c
+
+2022-07-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29356 - Execution fails if gprofng is not included in PATH
+ gprofng/Changelog:
+ 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29356
+ * gp-display-html/gp-display-html.in: fixed a problem to execute
+ gp-display-text in case gprofng is not included in the search
+ path.
+
+2022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29392 - Unexpected line format in summary file
+ gprofng/Changelog:
+ 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29392
+ * gp-display-html/gp-display-html.in: modified a regex, plus the
+ code to handle the results; renamed a variable to improve the
+ consistency in naming.
+
+2022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29353 - Fix a lay-out issue in the html disassembly files
+ gprofng/Changelog:
+ 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29353
+ * gp-display-html/gp-display-html.in: fixed a problem in the
+ generation of html for the disassembly where instructions
+ without arguments were not handled correctly.
+
+2022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29352 - Fix the message Hexadecimal number > 0xffffffff non-portable
+ gprofng/Changelog:
+ 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29352
+ * gp-display-html/gp-display-html.in: the hex subroutine from
+ the bigint module is now used.
+
+2022-07-25 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: fix bug 29351 - Move dynamic loading of modules to a later stage
+ gprofng/Changelog:
+ 2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ PR gprofng/29351
+ * gp-display-html/gp-display-html.in: the dynamic loading of
+ modules occurred too early, resulting in the generation of the
+ man page to fail in case a module is missing; the loading part is
+ now done somewhat later in the execution to avoid this problem.
+
+2022-07-25 Kevin Buettner <kevinb@redhat.com>
+
+ set/show python dont-write-bytecode fixes
+ GDB uses the environment variable PYTHONDONTWRITEBYTECODE to
+ determine whether or not to write the result of byte-compiling
+ python modules when the "python dont-write-bytecode" setting
+ is "auto". Simon noticed that GDB's implementation doesn't
+ follow the Python documentation.
+
+ At present, GDB only checks for the existence of this environment
+ variable. That is not sufficient though. Regarding
+ PYTHONDONTWRITEBYTECODE, this document...
+
+ https://docs.python.org/3/using/cmdline.html
+
+ ...says:
+
+ If this is set to a non-empty string, Python won't try to write
+ .pyc files on the import of source modules.
+
+ This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding
+ an empty string check.
+
+ This commit also corrects the set/show command documentation for
+ "python dont-write-bytecode". The current doc was just a copy
+ of that for set/show python ignore-environment.
+
+ During his review of an earlier version of this patch, Eli Zaretskii
+ asked that the help text that I proposed for "set/show python
+ dont-write-bytecode" be expanded. I've done that in addition to
+ clarifying the documentation of this option in the GDB manual.
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: fix invalid use disassemble_info::stream
+ After this commit:
+
+ commit 81384924cdcc9eb2676dd9084b76845d7d0e0759
+ Date: Tue Apr 5 11:06:16 2022 +0100
+
+ gdb: have gdb_disassemble_info carry 'this' in its stream pointer
+
+ The disassemble_info::stream field will no longer be a ui_file*. That
+ commit failed to update one location in py-disasm.c though.
+
+ While running some tests using the Python disassembler API, I
+ triggered a call to gdbpy_disassembler::print_address_func, and, as I
+ had compiled GDB with the undefined behaviour sanitizer, GDB crashed
+ as the code currently (incorrectly) casts the stream field to be a
+ ui_file*.
+
+ In this commit I fix this error.
+
+ In order to test this case I had to tweak the existing test case a
+ little. I also spotted some debug printf statements in py-disasm.py,
+ which I have removed.
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix use of uninitialised gdb_printing_disassembler::m_in_comment
+ Simon pointed out that gdb_printing_disassembler::m_in_comment can be
+ used uninitialised by the Python disassembler API code. This issue
+ was spotted when GDB was built with the undefined behaviour sanitizer,
+ and causes the gdb.python/py-disasm.exp test to fail like this:
+
+ (gdb) PASS: gdb.python/py-disasm.exp: global_disassembler=GlobalPreInfoDisassembler: python add_global_disassembler(GlobalPreInfoDisassembler)
+ disassemble main
+ Dump of assembler code for function main:
+ 0x0000555555555119 <+0>: push %rbp
+ 0x000055555555511a <+1>: mov %rsp,%rbp
+ 0x000055555555511d <+4>: nop
+ /home/user/src/binutils-gdb/gdb/disasm.h:144:12: runtime error: load of value 118, which is not a valid value for type 'bool'
+
+ The problem is that in disasmpy_builtin_disassemble we create a new
+ instance of gdbpy_disassembler, which is a sub-class of
+ gdb_printing_disassembler, however, the m_in_comment field is never
+ initialised.
+
+ This commit fixes the issue by providing a default initialisation
+ value for m_in_comment in disasm.h. As we only ever disassemble a
+ single instruction in disasmpy_builtin_disassemble then we don't need
+ to worry about reseting m_in_comment back to false after the single
+ instruction has been disassembled.
+
+ With this commit the above issue is resolved and
+ gdb.python/py-disasm.exp now passes.
+
+2022-07-25 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Compile 2 CTF tests with -O2
+ When GCC 12 is used to build binutils with -O0, the following 2 tests
+ failed:
+
+ FAIL: Conflicted data syms, partially indexed, stripped, with variables
+ FAIL: Conflicted data syms, partially indexed, stripped
+
+ Compile 2 tests with -O2 to avoid test failures.
+
+ PR ld/29378
+ * testsuite/ld-ctf/data-func-conflicted-vars.d: Compile with -O2.
+ * testsuite/ld-ctf/data-func-conflicted.d: Likewise.
+
+2022-07-25 Pedro Alves <pedro@palves.net>
+
+ struct packed: Add fallback byte array implementation
+ Attribute gcc_struct is not implemented in Clang targeting Windows, so
+ add a fallback standard-conforming implementation based on arrays.
+
+ I ran the testsuite on x86_64 GNU/Linux with this implementation
+ forced, and saw no regressions.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
+
+ Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
+
+2022-07-25 Pedro Alves <pedro@palves.net>
+
+ struct packed: Unit tests and more operators
+ For PR gdb/29373, I wrote an alternative implementation of struct
+ packed that uses a gdb_byte array for internal representation, needed
+ for mingw+clang. While adding that, I wrote some unit tests to make
+ sure both implementations behave the same. While at it, I implemented
+ all relational operators. This commit adds said unit tests and
+ relational operators. The alternative gdb_byte array implementation
+ will come next.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
+
+ Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
+
+2022-07-25 Pedro Alves <pedro@palves.net>
+
+ struct packed: Use gcc_struct on Windows
+ Building GDB on mingw/gcc hosts is currently broken, due to a static
+ assertion failure in gdbsupport/packed.h:
+
+ In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201,
+ from ../../../../../binutils-gdb/gdb/defs.h:28,
+ from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31:
+ ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]':
+ ../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74: required from here
+ ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed
+ 41 | gdb_static_assert (sizeof (packed) == Bytes);
+ | ~~~~~~~~~~~~~~~~^~~~~~~~
+ ../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert'
+ 27 | #define gdb_static_assert(expr) static_assert (expr, "")
+ | ^~~~
+ ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)'
+ 41 | gdb_static_assert (sizeof (packed) == Bytes);
+ | ~~~~~~~~~~~~~~~~^~~~~~~~
+
+
+ The issue is that mingw gcc defaults to "-mms-bitfields", which
+ affects how bitfields are laid out. We can however tell GCC that we
+ want the regular GCC layout instead using attribute gcc_struct.
+
+ Attribute gcc_struct is not implemented in "clang -target
+ x86_64-pc-windows-gnu", so that will need a different fix.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
+
+ Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ binutils-gdb/git: highlight whitespace errors in source files
+ For a long time I've had this in my ~/.gitconfig:
+
+ [core]
+ whitespace = space-before-tab,indent-with-non-tab,trailing-space
+
+ which causes git to show me if I muck up and use spaces instead of
+ tabs, or leave in trailing whitespace. I find this really useful.
+
+ I recently proposed adding something like this to the .gitattributes
+ files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1],
+ however, the question was asked - couldn't this be done at the top
+ level?
+
+ So, in this commit, I propose to update the top-level .gitattributes
+ file, after this commit, any git diff on a C, C++, Expect, or TCL
+ source file, will highlight the following whitespace errors:
+
+ (a) Use a space before a tab at the start of a line,
+
+ (b) Use of spaces where a tab could be used at the start of a line,
+ and
+
+ (c) Any trailing whitespace.
+
+ Errors are only highlighted in the diff on new or modified lines, so
+ you don't get spammed for errors on context lines that you haven't
+ modified.
+
+ The only downside I see to adding this at the top level is if there
+ are any sub-directories that don't follow the tabs/spaces indentation
+ rules very well already, in those directories you'll end up hitting
+ issues any time you edit a line. For GDB we're usually pretty good,
+ so having this highlighting isn't an issue.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html
+
+2022-07-25 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Sync sp with other *sp registers
+ For Arm Cortex-M33 with security extensions, there are 4 different
+ stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security
+ extensions and for other Cortex-M targets, there are 2 different
+ stack pointers (msp and psp).
+
+ With this patch, sp will always be in sync with one of the real stack
+ pointers on Arm targets that contain more than one stack pointer.
+
+2022-07-25 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ gdb/arm: Use if-else if instead of switch
+ As the register numbers for the alternative Arm SP registers are not
+ constant, it's not possible to use switch statement to define the
+ rules. In order to not have a mix, replace the few existing
+ switch statements with regular if-else if statements
+
+2022-07-25 Tom Tromey <tromey@adacore.com>
+
+ Remove dead code from windows_nat_target::detach
+ windows_nat_target::detach has a variable 'detached' that is only set
+ after a call to 'error'. However, this can't happen because 'error'
+ throws an exception.
+
+ This patch removes the dead code.
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle dis_style_sub_mnemonic disassembler style
+ In commit:
+
+ commit 4f46c0bc36471b725de0253bfec1a42a36e2c5c5
+ Date: Mon Jul 4 17:45:25 2022 +0100
+
+ opcodes: add new sub-mnemonic disassembler style
+
+ I added a new disassembler style dis_style_sub_mnemonic, but forgot to
+ add GDB support for this style. Fix this oversight in this commit.
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ libopcodes/ppc: add support for disassembler styling
+ This commit adds disassembler styling to the libopcodes ppc
+ disassembler. This conversion was pretty straight forward, I just
+ converted the fprintf_func calls to fprintf_styled_func calls and
+ added an appropriate style.
+
+ For testing the new styling I just assembled then disassembled the
+ source files in gas/testsuite/gas/ppc and manually checked that the
+ styling looked reasonable.
+
+ I think the only slightly weird case was how things like '4*cr1+eq'
+ are styled. As best I can tell, this construct, used for example in
+ this instruction:
+
+ crand 4*cr1+lt,4*cr1+gt,4*cr1+eq
+
+ is used to access a field of a control register. I initially tried
+ styling this whole construct as a register[1], but during review it
+ was suggested that instead different parts of the text should have
+ different styles. In this commit I propose styling '4*cr1+lt' like
+ this:
+
+ 4 - immediate,
+ * - text,
+ cr1 - register
+ + - text
+ lt - sub-mnemonic
+
+ If the user does not request styled output from objdump, then there
+ should be no change in the disassembler output after this commit.
+
+ [1] https://sourceware.org/pipermail/binutils/2022-July/121771.html
+
+2022-07-25 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes: add new sub-mnemonic disassembler style
+ When adding libopcodes disassembler styling support for AArch64, it
+ feels like the results would be improved by having a new sub-mnemonic
+ style. This will be used in cases like:
+
+ add w16, w7, w1, uxtb #2
+ ^^^^----- Here
+
+ And:
+
+ cinc w0, w1, ne
+ ^^----- Here
+
+ This commit just adds the new style, and prepares objdump to handle
+ the style. A later commit will add AArch64 styling, and will actually
+ make use of the style.
+
+ As this style is currently unused, there should be no user visible
+ changes after this commit.
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Add testcases for new relocate types.
+ gas/testsuite/gas/all/
+ gas.exp
+ gas/testsuite/gas/loongarch/
+ jmp_op.d
+ jmp_op.s
+ macro_op.d
+ macro_op.s
+ macro_op_32.d
+ macro_op_32.s
+ macro_op_large_abs.d
+ macro_op_large_abs.s
+ macro_op_large_pc.d
+ macro_op_large_pc.s
+ reloc.d
+ reloc.s
+
+ ld/testsuite/ld-elf/
+ pr26936.d
+ shared.exp
+ ld/testsuite/ld-loongarch-elf/
+ attr-ifunc-4.c
+ attr-ifunc-4.out
+ disas-jirl.d
+ ifunc.exp
+ jmp_op.d
+ jmp_op.s
+ libnopic-global.s
+ macro_op.d
+ macro_op.s
+ macro_op_32.d
+ macro_op_32.s
+ nopic-global-so.rd
+ nopic-global-so.sd
+ nopic-global.out
+ nopic-global.s
+ nopic-global.sd
+ nopic-global.xd
+ nopic-local.out
+ nopic-local.rd
+ nopic-local.s
+ nopic-local.sd
+ nopic-local.xd
+ nopic-weak-global-so.rd
+ nopic-weak-global-so.sd
+ nopic-weak-global.out
+ nopic-weak-global.s
+ nopic-weak-global.sd
+ nopic-weak-global.xd
+ nopic-weak-local.out
+ nopic-weak-local.rd
+ nopic-weak-local.s
+ nopic-weak-local.sd
+ nopic-weak-local.xd
+ pic.exp
+ pic.ld
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ bfd: Delete R_LARCH_NONE from dyn info of LoongArch.
+ Some R_LARCH_64 in section .eh_frame will to generate
+ R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL
+ from R_LARCH_64 in setction .eh_frame and not generate
+ dynamic relocation for R_LARCH_32_PCREL.
+
+ Add New relocate type R_LARCH_32_PCREL for .eh_frame.
+
+ include/elf/
+ loongarch.h
+
+ bfd/
+ bfd/bfd-in2.h
+ libbfd.h
+ reloc.c
+ elfxx-loongarch.c
+ elfnn-loongarch.c
+
+ gas/config/
+ tc-loongarch.c
+
+ binutils/
+ readelf.c
+
+ ld/testsuite/ld-elf/
+ eh5.d
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Move ifunc info to rela.dyn from rela.plt.
+ Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when
+ loading lazy function (rela.plt section).
+
+ In dynamic programes, move ifunc dynamic relocate info to section
+ srelgot from srelplt.
+
+ bfd/
+ elfnn-loongarch.c
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: gas: Add new reloc types.
+ Generate new relocate types while use new macro insns.
+
+ gas/config/
+ loongarch-lex.h
+ loongarch-parse.y
+ tc-loongarch.c
+ tc-loongarch.h
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch:opcodes: Add new reloc types.
+ opcodes: Replace old insns with news and generate new relocate types
+ while macro insns expanding.
+
+ opcodes/
+ loongarch-opc.c
+
+2022-07-25 liuzhensong <liuzhensong@loongson.cn>
+
+ bfd: Add supported for LoongArch new relocations.
+ Define new reloc types according to linker needs.
+
+ include/elf/
+ loongarch.h
+
+ bfd/
+ bfd-in2.h
+ libbfd.h
+ reloc.c
+ elfnn-loongarch.c
+ elfxx-loongarch.c
+ elfxx-loongarch.h
+
+2022-07-25 Alan Modra <amodra@gmail.com>
+
+ Re: PowerPC64 .branch_lt address
+ On seeing PR29369 my suspicion was naturally on a recent powerpc64
+ change, commit 0ab80031430e. Without a reproducer, I spent time
+ wondering what could have gone wrong, and while I doubt this patch
+ would have fixed the PR, there are some improvements that can be made
+ to cater for user silliness.
+
+ I also noticed that when -z relro -z now sections are created out of
+ order, with .got before .plt in the section headers but .got is laid
+ out at a higher address. That's due to the address expression for
+ .branch_lt referencing SIZEOF(.got) and so calling init_os (which
+ creates a bfd section) for .got before the .plt section is created.
+ Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR
+ which need to reference section vma and lma respectively, SIZEOF can
+ and does cope with a missing bfd section by returning zero for its
+ size, which of course is correct.
+
+ PR 29369
+ * ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF.
+ * emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise
+ .branch_lt address to take into account possible user sections
+ with alignment larger than 8 bytes.
+
+2022-07-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-24 Enze Li <enze.li@hotmail.com>
+
+ gdb/testsuite: add a clear test to py-breakpoint.exp
+ This patch adds a test case to try to clear an internal python
+ breakpoint using the clear command.
+
+ This was suggested by Pedro during a code review of the following
+ commit.
+
+ commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
+ Date: Sun Apr 17 15:09:46 2022 +0800
+
+ gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
+
+ Tested on x86_64 openSUSE Tumbleweed.
+
+2022-07-24 Enze Li <enze.li@hotmail.com>
+
+ gdb/testsuite: rename get_maint_bp_addr and move it to gdb-utils.exp
+ The get_maint_bp_addr procedure will be shared by other test suite, so
+ move it to gdb-utils.exp.
+
+ Following Andrew's suggestion, I renamed get_maint_bp_addr to
+ gdb_get_bp_addr, since it would have handled normal breakpoints in
+ addition to the internal ones. Note that there is still room for
+ improvement in this procedure, which I indicated in comments nearby.
+
+2022-07-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix duplicate CUs in all_comp_units
+ When running test-case gdb.cp/cpexprs-debug-types.exp with target board
+ cc-with-debug-names on a system with gcc 12.1.1 (defaulting to dwarf 5), I
+ run into:
+ ...
+ (gdb) file cpexprs-debug-types^M
+ Reading symbols from cpexprs-debug-types...^M
+ warning: Section .debug_aranges in cpexprs-debug-types has duplicate \
+ debug_info_offset 0x0, ignoring .debug_aranges.^M
+ gdb/dwarf2/read.h:309: internal-error: set_length: \
+ Assertion `m_length == length' failed.^M
+ ...
+
+ The exec contains a .debug_names section, which gdb rejects due to
+ .debug_names containing a list of TUs, while the exec doesn't contain a
+ .debug_types section (which is what you'd expect for dwarf 4).
+
+ Gdb then falls back onto the cooked index, which calls create_all_comp_units
+ to create all_comp_units. However, the failed index reading left some
+ elements in all_comp_units, so we end up with duplicates in all_comp_units,
+ which causes the misleading complaint and the assert.
+
+ Fix this by:
+ - asserting at the start of create_all_comp_units that all_comp_units is empty,
+ as we do in create_cus_from_index and create_cus_from_debug_names, and
+ - cleaning up all_comp_units when failing in dwarf2_read_debug_names.
+
+ Add a similar cleanup in dwarf2_read_gdb_index.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381
+
+2022-07-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: give binaries distinct names in Ada tests
+ Some Ada tests repeat their test sequence with different gnat-encodings,
+ typically "all" and "minimal". However, they give the same name to both
+ binaries, meaning the second run overwrites the binary of the first run.
+ This makes it difficult and confusing when trying to reproduce problems
+ manually with the test artifacts. Change those tests to use unique
+ names for each pass.
+
+ Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88
+
+2022-07-22 Tom Tromey <tromey@adacore.com>
+
+ Change target_ops::async to accept bool
+ This changes the parameter of target_ops::async from int to bool.
+ Regression tested on x86-64 Fedora 34.
+
+ Fix typo in windows-nat.c
+ I noticed a typo in a printf in windows-nat.c. This fixes it.
+
+2022-07-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add empty range unit test for gdb::parallel_for_each
+ Add a unit test that verifies that we can call gdb::parallel_for_each with an
+ empty range.
+
+ Tested on x86_64-linux.
+
+2022-07-22 Alan Modra <amodra@gmail.com>
+
+ PR17122, OSX 10.9 build failure
+ sbrk hasn't been used in binutils/ or ld/ for quite some time (so the
+ PR was fixed a while ago). Tidy up configury.
+
+ PR 17122
+ binutils/
+ * configure.ac: Don't check for sbrk.
+ * sysdep.h (sbrk): Don't supply fallback declaration.
+ * config.in: Regenerate.
+ * configure: Regenerate.
+ ld/
+ * configure.ac: Don't check for sbrk.
+ * config.in: Regenerate.
+ * configure: Regenerate.
+
+2022-07-22 Jiangshuai Li <jiangshuai_li@linux.alibaba-inc.com>
+
+ gdb/csky modify registers list for general_reggroup
+ There are two modification points here:
+ 1. For the debugging of csky architecture, after executing "info register",
+ we hope to print out GPRs, PC and the registers related to exceptions.
+ 2. With tdesc-xml, users can view the register groups described in XML.
+
+2022-07-22 Alan Modra <amodra@gmail.com>
+
+ PR15951, binutils testsuite builds status wrapper unconditionally
+ PR 15951
+ * testsuite/binutils-all/objcopy.exp: Build testglue.o when
+ needs_status_wrapper.
+
+2022-07-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-21 Peter Bergner <bergner@linux.ibm.com>
+
+ Add ChangeLog entry from previous commit
+
+2022-07-21 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Create new MMA instruction masks and use them
+ The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that
+ misses the RC bit/bit 31, so if we disassemble a .long that represents an
+ MMA instruction except that it also has bit 31 set, we will erroneously
+ disassemble it to that MMA instruction. We create new masks defines that
+ contain bit 31 so that doesn't happen anymore.
+
+ opcodes/
+ * ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines.
+ (P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4,
+ xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8,
+ xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp,
+ xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp,
+ xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn,
+ xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.
+
+2022-07-21 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC
+ We can't use the PLT entry as the function address for PIC since the PIC
+ register may not be set up properly for indirect call.
+
+ bfd/
+
+ PR ld/27998
+ * elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF
+ relocation against IFUNC symbol for PIC.
+
+ ld/
+
+ PR ld/27998
+ * testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar.
+ * testsuite/ld-i386/pr27998b.d: Expect a linker error.
+ * testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated.
+ * testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT.
+ * testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: ensure the cast in gdbarch_tdep is valid
+ This commit makes use of gdb::checked_static_cast when casting the
+ generic gdbarch_tdep pointer to a specific sub-class type. This means
+ that, when compiled in developer mode, GDB will validate that the cast
+ is correct.
+
+ In order to use gdb::checked_static_cast the types involved must have
+ RTTI, which is why the gdbarch_tdep base class now has a virtual
+ destructor.
+
+ Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer
+ to the wrong type, then there should be no changes after this commit.
+
+ If any bugs do exist, then GDB will now assert (in a developer build).
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdbsupport: add checked_static_cast
+ This commit was inspired by these mailing list posts:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html
+ https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html
+
+ The idea is to add a new function gdb::checked_static_cast, which can,
+ in some cases, be used as a drop-in replacement for static_cast. And
+ so, if I previously wrote this:
+
+ BaseClass *base = get_base_class_pointer ();
+ DerivedClass *derived = static_cast<DerivedClass *> (base);
+
+ I can now write:
+
+ BaseClass *base = get_base_class_pointer ();
+ DerivedClass *derived = gdb::checked_static_cast<DerivedClass *> (base);
+
+ The requirement is that BaseClass and DerivedClass must be
+ polymorphic.
+
+ The benefit of making this change is that, when GDB is built in
+ developer mode, a run-time check will be made to ensure that `base`
+ really is of type DerivedClass before the cast is performed. If
+ `base` is not of type DerivedClass then GDB will assert.
+
+ In a non-developer build gdb::checked_static_cast is equivalent to a
+ static_cast, and there should be no performance difference.
+
+ This commit adds the support function, but does not make use of this
+ function, a use will be added in the next commit.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Co-Authored-By: Tom Tromey <tom@tromey.com>
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move the type cast into gdbarch_tdep
+ I built GDB for all targets on a x86-64/GNU-Linux system, and
+ then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
+ the binary on the native target. I got this error:
+
+ (gdb) show architecture
+ The target architecture is set to "auto" (currently "i386").
+ (gdb) file /tmp/hello.rv32.exe
+ Reading symbols from /tmp/hello.rv32.exe...
+ (gdb) show architecture
+ The target architecture is set to "auto" (currently "riscv:rv32").
+ (gdb) run
+ Starting program: /tmp/hello.rv32.exe
+ ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
+
+ What's going on here is this; initially the architecture is i386, this
+ is based on the default architecture, which is set based on the native
+ target. After loading the RISC-V executable the architecture of the
+ current inferior is updated based on the architecture of the
+ executable.
+
+ When we "run", GDB does a fork & exec, with the inferior being
+ controlled through ptrace. GDB sees an initial stop from the inferior
+ as soon as the inferior comes to life. In response to this stop GDB
+ ends up calling save_stop_reason (linux-nat.c), which ends up trying
+ to read register from the inferior, to do this we end up calling
+ target_ops::fetch_registers, which, for the x86-64 native target,
+ calls amd64_linux_nat_target::fetch_registers.
+
+ After this I eventually end up in i387_supply_fxsave, different x86
+ based targets will end in different functions to fetch registers, but
+ it doesn't really matter which function we end up in, the problem is
+ this line, which is repeated in many places:
+
+ i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
+
+ The problem here is that the ARCH in this line comes from the current
+ inferior, which, as we discussed above, will be a RISC-V gdbarch, the
+ tdep field will actually be of type riscv_gdbarch_tdep, not
+ i386_gdbarch_tdep. After this cast we are relying on undefined
+ behaviour, in my case I happen to trigger an assert, but this might
+ not always be the case.
+
+ The thing I tried that exposed this problem was of course, trying to
+ start an executable of the wrong architecture on a native target. I
+ don't think that the correct solution for this problem is to detect,
+ at the point of cast, that the gdbarch_tdep object is of the wrong
+ type, but, I did wonder, is there a way that we could protect
+ ourselves from incorrectly casting the gdbarch_tdep object?
+
+ I think that there is something we can do here, and this commit is the
+ first step in that direction, though no actual check is added by this
+ commit.
+
+ This commit can be split into two parts:
+
+ (1) In gdbarch.h and arch-utils.c. In these files I have modified
+ gdbarch_tdep (the function) so that it now takes a template argument,
+ like this:
+
+ template<typename TDepType>
+ static inline TDepType *
+ gdbarch_tdep (struct gdbarch *gdbarch)
+ {
+ struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
+ return static_cast<TDepType *> (tdep);
+ }
+
+ After this change we are no better protected, but the cast is now
+ done within the gdbarch_tdep function rather than at the call sites,
+ this leads to the second, much larger change in this commit,
+
+ (2) Everywhere gdbarch_tdep is called, we make changes like this:
+
+ - i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
+ + i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);
+
+ There should be no functional change after this commit.
+
+ In the next commit I will build on this change to add an assertion in
+ gdbarch_tdep that checks we are casting to the correct type.
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: select suitable thread for gdbarch_adjust_breakpoint_address
+ The three targets that implement gdbarch_adjust_breakpoint_address are
+ arm, frv, and mips. In each of these targets the adjust breakpoint
+ address function does some combination of reading the symbol table, or
+ reading memory at the location the breakpoint could be placed.
+
+ The problem is that performing these actions requires that the current
+ inferior and program space be the one in which the breakpoint will be
+ placed, and this is not currently always the case.
+
+ Consider a GDB session with multiple inferiors. One inferior might be
+ a native target while another could be a remote target of a completely
+ different architecture. Alternatively, if we consider ARM and
+ AArch64, one native inferior might be AArch64, while a second native
+ inferior could be ARM.
+
+ In these cases it is possible, and valid, for a user to have one
+ inferior selected, and place a breakpoint in the other inferior by
+ placing a breakpoint on a particular symbol.
+
+ If this happens, then currently, when
+ gdbarch_adjust_breakpoint_address is called, the wrong inferior (and
+ program space) will be selected, and memory reads, and symbol look
+ ups, will not return the expected results, this could lead to
+ breakpoints being placed in the wrong location.
+
+ There are currently two places where gdbarch_adjust_breakpoint_address
+ is called:
+
+ 1. In infrun.c, in the function handle_step_into_function. In this
+ case, I believe that the correct inferior and program space will
+ already be selected as this is called as part of the stop event
+ handling, so I don't think we need to worry about this case, and
+
+ 2. In breakpoint.c, in the function adjust_breakpoint_address, which
+ is itself called from code_breakpoint::add_location and
+ watch_command_1.
+
+ The watch_command_1 case I don't think we need to worry about, this
+ is for when a local watch expression is created, which can only be
+ in the currently selected inferior, so this case should be fine.
+
+ The code_breakpoint::add_location case is the one that needs fixing,
+ this is what allows a breakpoint to be created between inferiors.
+
+ To fix the code_breakpoint::add_location case, I propose that we pass
+ the "correct" program_space (i.e. the program space in which the
+ breakpoint will be created) to the adjust_breakpoint_address function.
+ Then in adjust_breakpoint_address we can make use of
+ switch_to_program_space_and_thread to switch program_space and
+ inferior before calling gdbarch_adjust_breakpoint_address.
+
+ I discovered this issue while working on a later patch in this
+ series. This later patch will detect when we cast the result of
+ gdbarch_tdep to the wrong type.
+
+ With this later patch in place I ran gdb.multi/multi-arch.exp on an
+ AArch64 target. In this situation, two inferiors are created, an
+ AArch64 inferior, and an ARM inferior. The test selected the AArch64
+ inferior and tries to create a breakpoint in the ARM inferior.
+
+ As a result of this we end up in arm_adjust_breakpoint_address, which
+ calls arm_pc_is_thumb. Before this commit the AArch64 inferior would
+ be current. As a result, all of the checks in arm_pc_is_thumb would
+ fail (they rely on reading symbols from the current program space),
+ and so, at the end of arm_pc_is_thumb we would call
+ arm_frame_is_thumb. However, remember, at this point the current
+ inferior is the AArch64 inferior, so the current frame is an AArch64
+ frame.
+
+ In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls
+ gdbarch_tdep and casts the result to arm_gdbarch_tdep. This is wrong,
+ the tdep field is of type aarch64_gdbarch_tdep. After this we have
+ undefined behaviour.
+
+ With this patch in place, we will have switched to a thread in the ARM
+ program space before calling arm_adjust_breakpoint_address. As a
+ result, we now succeed in looking up the required symbols in
+ arm_pc_is_thumb, and so we never call arm_frame_is_thumb.
+
+ However, in the worst case scenario, if we did end up calling
+ arm_frame_is_thumb, as the current inferior should now be the ARM
+ inferior, the current frame should be an ARM frame, so we still should
+ not hit undefined behaviour.
+
+ I have added an assert to arm_frame_is_thumb.
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mips: rewrite show_mask_address
+ This commit is similar to the previous commit, but in this case GDB is
+ actually relying on undefined behaviour.
+
+ Consider building GDB for all targets on x86-64/GNU-Linux, then doing
+ this:
+
+ (gdb) show mips mask-address
+ Zeroing of upper 32 bits of 64-bit addresses is auto.
+ The 32 bit address mask is set automatically. Currently disabled
+ (gdb)
+
+ The 'show mips mask-address' command ends up in show_mask_address in
+ mips-tdep.c, and this function does this:
+
+ mips_gdbarch_tdep *tdep
+ = (mips_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());
+
+ Later we might pass TDEP to mips_mask_address_p. However, in my
+ example above, on an x86-64 native target, the current target
+ architecture will be an x86-64 gdbarch, and the tdep field within the
+ gdbarch will be of type i386_gdbarch_tdep, not of type
+ mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP
+ is not pointing at what it thinks it is.
+
+ I also think the current output is a little confusing, we appear to
+ have two lines that show the same information, but using different
+ words.
+
+ The first line comes from calling deprecated_show_value_hack, while
+ the second line is printed directly from show_mask_address. However,
+ both of these lines are printing the same mask_address_var value. I
+ don't think the two lines actually adds any value here.
+
+ Finally, none of the text in this function is passed through the
+ internationalisation mechanism.
+
+ It would be nice to remove another use of deprecated_show_value_hack
+ if possible, so this commit does a complete rewrite of
+ show_mask_address.
+
+ After this commit the output of the above example command, still on my
+ x86-64 native target is:
+
+ (gdb) show mips mask-address
+ Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS).
+
+ The 'current architecture is not MIPS' text is only displayed when the
+ current architecture is not MIPS. If the architecture is mips then we
+ get the more commonly seen 'currently "on"' or 'currently "off"', like
+ this:
+
+ (gdb) set architecture mips
+ The target architecture is set to "mips".
+ (gdb) show mips mask-address
+ Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off").
+ (gdb)
+
+ All the text is passed through the internationalisation mechanism, and
+ we only call gdbarch_tdep when we know the gdbarch architecture is
+ bfd_arch_mips.
+
+2022-07-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/arm: move fetch of arm_gdbarch_tdep to a more inner scope
+ This is a small refactor to resolve an issue before it becomes a
+ problem in a later commit.
+
+ Move the fetching of an arm_gdbarch_tdep into a more inner scope
+ within two functions in arm-tdep.c.
+
+ The problem with the current code is that the functions in question
+ are used as the callbacks for two set/show parameters. These set/show
+ parameters are available no matter the current architecture, but are
+ really about controlling an ARM architecture specific setting. And
+ so, if I build GDB for all targets on an x86-64/GNU-Linux system, I
+ can still do this:
+
+ (gdb) show arm fpu
+ (gdb) show arm abi
+
+ After these calls we end up in show_fp_model and arm_show_abi
+ respectively, where we unconditionally do this:
+
+ arm_gdbarch_tdep *tdep
+ = (arm_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());
+
+ However, the gdbarch_tdep() result will only be a arm_gdbarch_tdep if
+ the current architecture is ARM, otherwise the result will actually be
+ of some other type.
+
+ This isn't actually a problem, as in both cases the use of tdep is
+ guarded by a later check that the gdbarch architecture is
+ bfd_arch_arm.
+
+ This commit just moves the call to gdbarch_tdep() after the
+ architecture check.
+
+ In a later commit gdbarch_tdep() will be able to spot when we are
+ casting the result to the wrong type, and this function will trigger
+ assertion failures if things are not fixed.
+
+ There should be not user visible changes after this commit.
+
+2022-07-21 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
+
+ [arm] Rename arm_cache_is_sp_register to arm_is_alternative_sp_register
+ All usages of this helper are really made to check if the register is
+ one of the alternative SP registers (MSP/MSP_S/MSP_NS/PSP/PSP_S/PSP_NS)
+ with the ARM_SP_REGNUM case being handled separately.
+
+2022-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Fix typo in test_python
+ Fix typo in ref_output_0 variable in test_python.
+
+ Tested by running the selftest on x86_64-linux with python 3.11.
+
+2022-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/python] Fix python selftest with python 3.11
+ With python 3.11 I noticed:
+ ...
+ $ gdb -q -batch -ex "maint selftest python"
+ Running selftest python.
+ Self test failed: self-test failed at gdb/python/python.c:2246
+ Ran 1 unit tests, 1 failed
+ ...
+
+ In more detail:
+ ...
+ (gdb) p output
+ $5 = "Traceback (most recent call last):\n File \"<string>\", line 0, \
+ in <module>\nKeyboardInterrupt\n"
+ (gdb) p ref_output
+ $6 = "Traceback (most recent call last):\n File \"<string>\", line 1, \
+ in <module>\nKeyboardInterrupt\n"
+ ...
+
+ Fix this by also allowing line number 0.
+
+ Tested on x86_64-linux.
+
+ This should hopefully fix buildbot builder gdb-rawhide-x86_64.
+
+2022-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Fix type of parallel_for_each_debug
+ When I changed the initialization of parallel_for_each_debug from 0 to false,
+ I forgot to change the type from int to bool. Fix this.
+
+ Tested by rebuilding on x86_64-linux.
+
+2022-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix bad compile unit index complaint
+ I noticed this code in dw2_debug_names_iterator::next:
+ ...
+ case DW_IDX_compile_unit:
+ /* Don't crash on bad data. */
+ if (ull >= per_bfd->all_comp_units.size ())
+ {
+ complaint (_(".debug_names entry has bad CU index %s"
+ " [in module %s]"),
+ pulongest (ull),
+ objfile_name (objfile));
+ continue;
+ }
+ per_cu = per_bfd->get_cu (ull);
+ break;
+ ...
+
+ This code used to DTRT, before we started keeping both CUs and TUs in
+ all_comp_units.
+
+ Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus"
+ instead.
+
+ It's hard to produce a test-case for this, but let's try at least to trigger
+ the complaint somehow. We start out by creating an exec with .debug_types and
+ .debug_names:
+ ...
+ $ gcc -g ~/hello.c -fdebug-types-section
+ $ gdb-add-index -dwarf-5 a.out
+ ...
+ and verify that we don't see any complaints:
+ ...
+ $ gdb -q -batch -iex "set complaints 100" ./a.out
+ ...
+
+ We look at the CU and TU table using readelf -w and conclude that we have
+ nr_cus == 6 and nr_tus == 1.
+
+ Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit
+ case to 6, and we have:
+ ...
+ $ gdb -q -batch -iex "set complaints 100" ./a.out
+ During symbol reading: .debug_names entry has bad CU index 6 [in module a.out]
+ ...
+
+ After this, it still crashes because this code in
+ dw2_debug_names_iterator::next:
+ ...
+ /* Skip if already read in. */
+ if (m_per_objfile->symtab_set_p (per_cu))
+ goto again;
+ ...
+ is called with per_cu == nullptr.
+
+ Fix this by skipping the entry if per_cu == nullptr.
+
+ Now revert the fix and observe that the complaint disappears, so we've
+ confirmed that the fix is required.
+
+ A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed
+ as PR29367.
+
+ Tested on x86_64-linux, with native and target board cc-with-debug-names.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29336
+
+2022-07-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: replace wrong attributes on VCVTDQ2PH{X,Y}
+ A standalone (without SAE) StaticRounding attribute is meaningless, and
+ indeed all other similar insns have ATTSyntax there instead. I can only
+ assume this was some strange copy-and-paste mistake.
+
+ x86/Intel: correct AVX512F scatter insn element sizes
+ I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted
+ operand sizes for AVX512 scatter/gather") giving all AVX512F scatter
+ insns Dword element size. Update testcases (also their gather parts),
+ utilizing that there previously were two identical lines each (for no
+ apparent reason).
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save
+ PR 29390
+ binutils/
+ * dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New.
+ (display_debug_frames): Use them.
+ (init_dwarf_regnames_aarch64): Set is_aarch64.
+ (init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64.
+ (init_dwarf_regnames_by_bfd_arch_and_mach): Likewise.
+ gas/
+ * testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output.
+ * testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise.
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ PR29337, readelf CU/TU mixup in .gdb_index
+ Commit 244e19c79111 changed a number of variables in display_gdb_index
+ to count entries rather than words.
+
+ PR 29337
+ * dwarf.c (display_gdb_index): Correct use of cu_list_elements.
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ PR29370, infinite loop in display_debug_abbrev
+ The PR29370 testcase is a fuzzed object file with multiple
+ .trace_abbrev sections. Multiple .trace_abbrev or .debug_abbrev
+ sections are not a violation of the DWARF standard. The DWARF5
+ standard even gives an example of multiple .debug_abbrev sections
+ contained in groups. Caching and lookup of processed abbrevs thus
+ needs to be done by section and offset rather than base and offset.
+ (Why base anyway?) Or, since section contents are kept, by a pointer
+ into the contents.
+
+ PR 29370
+ * dwarf.c (struct abbrev_list): Replace abbrev_base and
+ abbrev_offset with raw field.
+ (find_abbrev_list_by_abbrev_offset): Delete.
+ (find_abbrev_list_by_raw_abbrev): New function.
+ (process_abbrev_set): Set list->raw and list->next.
+ (find_and_process_abbrev_set): Replace abbrev list lookup with
+ new function. Don't set list abbrev_base, abbrev_offset or next.
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ binutils/dwarf.c: abbrev caching
+ I'm inclined to think that abbrev caching is counter-productive. The
+ time taken to search the list of abbrevs converted to internal form is
+ non-zero, and it's easy to decode the raw abbrevs. It's especially
+ silly to cache empty lists of decoded abbrevs (happens with zero
+ padding in .debug_abbrev), or abbrevs as they are displayed when there
+ is no further use of those abbrevs. This patch stops caching in those
+ cases.
+
+ * dwarf.c (record_abbrev_list_for_cu): Add free_list param.
+ Put abbrevs on abbrev_lists here.
+ (new_abbrev_list): Delete function.
+ (process_abbrev_set): Return newly allocated list. Move
+ abbrev base, offset and size checking to..
+ (find_and_process_abbrev_set): ..here, new function. Handle
+ lookup of cached abbrevs here, and calculate start and end
+ for process_abbrev_set. Return free_list if newly alloc'd.
+ (process_debug_info): Consolidate cached list lookup, new list
+ alloc and processing into find_and_process_abbrev_set call.
+ Free list when not cached.
+ (display_debug_abbrev): Similarly.
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ miscellaneous dwarf.c tidies
+ * dwarf.c: Leading and trailing whitespace fixes.
+ (free_abbrev_list): New function.
+ (free_all_abbrevs): Use the above. Free cu_abbrev_map here too.
+ (process_abbrev_set): Print actual section name on error.
+ (get_type_abbrev_from_form): Add overflow check.
+ (free_debug_memory): Don't free cu_abbrev_map here..
+ (process_debug_info): ..or here. Warn on another case of not
+ finding a neeeded abbrev.
+
+2022-07-21 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: fix build error on 32-bit hosts
+ elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=]
+ 11673 | fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset);
+ | ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~
+ | | |
+ | | bfd_vma {aka long long unsigned int}
+ | long unsigned int
+ | %#llx
+
+ * elf64-ppc.c (dump_stub): Use BFD_VMA_FMT.
+
+2022-07-21 Kevin Buettner <kevinb@redhat.com>
+
+ Wrap python_write_bytecode with HAVE_PYTHON ifdef
+ This commit fixes a build error on machines lacking python headers
+ and/or libraries.
+
+2022-07-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-20 Kevin Buettner <kevinb@redhat.com>
+
+ Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName
+ Python 3.11 deprecates PySys_SetPath and Py_SetProgramName. The
+ PyConfig API replaces these and other functions. This commit uses the
+ PyConfig API to provide equivalent functionality while also preserving
+ support for older versions of Python, i.e. those before Python 3.8.
+
+ A beta version of Python 3.11 is available in Fedora Rawhide. Both
+ Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used
+ Python 3.9. I've tested these changes on Fedora 34, Fedora 36, and
+ rawhide, though complete testing was not possible on rawhide due to
+ a kernel bug. That being the case, I decided to enable the newer
+ PyConfig API by testing PY_VERSION_HEX against 0x030a0000. This
+ corresponds to Python 3.10.
+
+ We could try to use the PyConfig API for Python versions as early as 3.8,
+ but I'm reluctant to do this as there may have been PyConfig related
+ bugs in earlier versions which have since been fixed. Recent linux
+ distributions should have support for Python 3.10. This should be
+ more than adequate for testing the new Python initialization code in
+ GDB.
+
+ Information about the PyConfig API as well as the motivation behind
+ deprecating the old interface can be found at these links:
+
+ https://github.com/python/cpython/issues/88279
+ https://peps.python.org/pep-0587/
+ https://docs.python.org/3.11/c-api/init_config.html
+
+ The v2 commit also addresses several problems that Simon found in
+ the v1 version.
+
+ In v1, I had used Py_DontWriteBytecodeFlag in the new initialization
+ code, but Simon pointed out that this global configuration variable
+ will be deprecated in Python 3.12. This version of the patch no longer
+ uses Py_DontWriteBytecodeFlag in the new initialization code.
+ Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag
+ will no longer be used when building GDB against Python 3.10 or higher.
+ While it's true that both of these global configuration variables are
+ deprecated in Python 3.12, it makes sense to disable their use for
+ gdb builds against 3.10 and higher since those are the versions for
+ which the PyConfig API is now being used by GDB. (The PyConfig API
+ includes different mechanisms for making the same settings afforded
+ by use of the soon-to-be deprecated global configuration variables.)
+
+ Simon also noted that PyConfig_Clear() would not have be called for
+ one of the failure paths. I've fixed that problem and also made the
+ rest of the "bail out" code more direct. In particular,
+ PyConfig_Clear() will always be called, both for success and failure.
+
+ The v3 patch addresses some rebase conflicts related to module
+ initialization . Commit 3acd9a692dd ("Make 'import gdb.events' work")
+ uses PyImport_ExtendInittab instead of PyImport_AppendInittab. That
+ commit also initializes a struct for each module to import. Both the
+ initialization and the call to were moved ahead of the ifdefs to avoid
+ having to replicate (at least some of) the code three times in various
+ portions of the ifdefs.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28668
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29287
+
+2022-07-20 Christopher Di Bella <cjdb@google.com>
+
+ gdb/value.c: add several headers to the include list
+ Building GDB currently fails to build with libc++, because libc++ is
+ stricter about which headers "leak" entities they're not guaranteed
+ to support. The following headers have been added:
+
+ * `<iterator>`, to support `std::back_inserter`
+ * `<utility>`, to support `std::move` and `std::swap`
+ * `<vector>`, to support `std::vector`
+
+ Change-Id: Iaeb15057c5fbb43217df77ce34d4e54446dbcf3d
+
+2022-07-20 Pedro Alves <pedro@palves.net>
+
+ Don't stop all threads prematurely after first step of "step N"
+ In all-stop mode, when the target is itself in non-stop mode (like
+ GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step
+ a thread a number of times:
+
+ (gdb) help step
+ step, s
+ Step program until it reaches a different source line.
+ Usage: step [N]
+ Argument N means step N times (or till program stops for another reason).
+
+ ... GDB prematurely stops all threads after the first step, and
+ doesn't re-resume them for the subsequent N-1 steps. It's as if for
+ the 2nd and subsequent steps, the command was running with
+ scheduler-locking enabled.
+
+ This can be observed with the testcase added by this commit, which
+ looks like this:
+
+ static pthread_barrier_t barrier;
+
+ static void *
+ thread_func (void *arg)
+ {
+ pthread_barrier_wait (&barrier);
+ return NULL;
+ }
+
+ int
+ main ()
+ {
+ pthread_t thread;
+ int ret;
+
+ pthread_barrier_init (&barrier, NULL, 2);
+
+ /* We run to this line below, and then issue "next 3". That should
+ step over the 3 lines below and land on the return statement. If
+ GDB prematurely stops the thread_func thread after the first of
+ the 3 nexts (and never resumes it again), then the join won't
+ ever return. */
+ pthread_create (&thread, NULL, thread_func, NULL); /* set break here */
+ pthread_barrier_wait (&barrier);
+ pthread_join (thread, NULL);
+
+ return 0;
+ }
+
+ The test hangs and times out without the GDB fix:
+
+ (gdb) next 3
+ [New Thread 0x7ffff7d89700 (LWP 525772)]
+ FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout)
+
+ The problem is a core gdb bug.
+
+ When you do "step/stepi/next/nexti N", GDB internally creates a
+ thread_fsm object and associates it with the stepping thread. For the
+ stepping commands, the FSM's class is step_command_fsm. That object
+ is what keeps track of how many steps are left to make. When one step
+ finishes, handle_inferior_event calls stop_waiting and returns, and
+ then fetch_inferior_event calls the "should_stop" method of the event
+ thread's FSM. The implementation of that method decrements the
+ steps-left counter. If the counter is 0, it returns true and we
+ proceed to presenting the stop to the user. If it isn't 0 yet, then
+ the method returns false, indicating to fetch_inferior_event to "keep
+ going".
+
+ Focusing now on when the first step finishes -- we're in "all-stop"
+ mode, with the target in non-stop mode. When a step finishes,
+ handle_inferior_event calls stop_waiting, which itself calls
+ stop_all_threads to stop everything. I.e., after the first step
+ completes, all threads are stopped, before handle_inferior_event
+ returns. And after that, now in fetch_inferior_event, we consult the
+ thread's thread_fsm::should_stop, which as we've seen, for the first
+ step returns false -- i.e., we need to keep_going for another step.
+ However, since the target is in non-stop mode, keep_going resumes
+ _only_ the current thread. All the other threads remain stopped,
+ inadvertently.
+
+ If the target is in non-stop mode, we don't actually need to stop all
+ threads right after each step finishes, and then re-resume them again.
+ We can instead defer stopping all threads until all the steps are
+ completed.
+
+ So fix this by delaying the stopping of all threads until after we
+ called the FSM's "should_stop" method. I.e., move it from
+ stop_waiting, to handle_inferior_events's callers,
+ fetch_inferior_event and wait_for_inferior.
+
+ New test included. Tested on x86-64 GNU/Linux native and gdbserver.
+
+ Change-Id: Iaad50dcfea4464c84bdbac853a89df92ade6ae01
+
+2022-07-20 Alan Modra <amodra@gmail.com>
+
+ Re: opcodes/arc: Implement style support in the disassembler
+ * arc-dis.c (print_insn_arc): Fix thinko.
+
+2022-07-20 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ gas/symbols: introduce md_resolve_symbol
+ Assuming GMSD is a special operand, marked as O_md1, the code:
+
+ .set VREG, GMSD
+ .set REG, VREG
+ extsw REG, 2
+
+ ...fails upon attempts to resolve the value of the symbol. This happens
+ since machine-dependent values are not handled in the giant op switch.
+ We introduce a custom md_resolve_symbol macro; the ports can use this
+ macro to customize the behavior when resolve_symbol_value hits O_md
+ operand.
+
+2022-07-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-19 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Disallow invalid relocations against protected symbols
+ Since glibc 2.36 will issue warnings for copy relocation against
+ protected symbols and non-canonical reference to canonical protected
+ functions, change the linker to always disallow such relocations.
+
+ bfd/
+
+ * elf32-i386.c (elf_i386_scan_relocs): Remove check for
+ elf_has_indirect_extern_access.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+ (elf_x86_64_relocate_section): Remove check for
+ elf_has_no_copy_on_protected.
+ * elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building
+ executable instead of elf_has_no_copy_on_protected.
+ (_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation
+ against non-copyable protected symbol.
+ * elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for
+ elf_has_no_copy_on_protected.
+
+ ld/
+
+ * testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709
+ test.
+ * testsuite/ld-i386/pr17709.rd: Removed.
+ * testsuite/ld-i386/pr17709.err: New file.
+ * testsuite/ld-x86-64/pr17709.rd: Removed.
+ * testsuite/ld-x86-64/pr17709.err: New file.
+ * testsuite/ld-x86-64/pr28875-func.err: Updated.
+ * testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR
+ ld/17709 test. Add tests for function pointer against protected
+ function.
+
+2022-07-19 Fangrui Song <i@maskray.me>
+
+ x86: Make protected symbols local for -shared
+ Call _bfd_elf_symbol_refs_local_p with local_protected==true. This has
+ 2 noticeable effects for -shared:
+
+ * GOT-generating relocations referencing a protected data symbol no
+ longer lead to a GLOB_DAT (similar to a hidden symbol).
+ * Direct access relocations (e.g. R_X86_64_PC32) no longer has the
+ confusing diagnostic below.
+
+ __attribute__((visibility("protected"))) void *foo() {
+ return (void *)foo;
+ }
+
+ // gcc -fpic -shared -fuse-ld=bfd
+ relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object
+
+ The new behavior matches arm, aarch64 (commit
+ 83c325007c5599fa9b60b8d5f7b84842160e1d1b), and powerpc ports, and other
+ linkers: gold and ld.lld.
+
+ Note: if some code tries to use direct access relocations to take the
+ address of foo, the pointer equality will break, but the error should be
+ reported on the executable link, not on the innocent shared object link.
+ glibc 2.36 will give a warning at relocation resolving time.
+
+ With this change, `#define elf_backend_extern_protected_data 1` is no
+ longer effective. Just remove it.
+
+ Remove the test "Run protected-func-1 without PIE" since -fno-pic
+ address taken operation in the executable doesn't work with protected
+ symbol in a shared object by default. Similarly, remove
+ protected-data-1a and protected-data-1b. protected-data-1b can be made
+ working by removing HAVE_LD_PIE_COPYRELOC from GCC
+ (https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).
+
+2022-07-19 Luis Machado <luis.machado@arm.com>
+
+ Reformat gdbarch-components.py to fix deviations
+ Reformat to make sure we have a clean file with no deviations
+ from the expected python code format.
+
+2022-07-19 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] MTE corefile support
+ Teach GDB how to dump memory tags for AArch64 when using the gcore command
+ and how to read memory tag data back from a core file generated by GDB
+ (via gcore) or by the Linux kernel.
+
+ The format is documented in the Linux Kernel documentation [1].
+
+ Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
+ own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
+ of those segments when reading the core file back.
+
+ To save a little bit of space, given MTE tags only take 4 bits, the memory tags
+ are stored packed as 2 tags per byte.
+
+ When reading the data back, the tags are unpacked.
+
+ I've added a new testcase to exercise the feature.
+
+ Build-tested with --enable-targets=all and regression tested on aarch64-linux
+ Ubuntu 20.04.
+
+ [1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
+
+2022-07-19 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Support AArch64 MTE memory tag dumps in core files
+ The Linux kernel can dump memory tag segments to a core file, one segment
+ per mapped range. The format and documentation can be found in the Linux
+ kernel tree [1].
+
+ The following patch adjusts bfd and binutils so they can handle this new
+ segment type and display it accordingly. It also adds code required so GDB
+ can properly read/dump core file data containing memory tags.
+
+ Upon reading, each segment that contains memory tags gets mapped to a
+ section named "memtag". These sections will be used by GDB to lookup the tag
+ data. There can be multiple such sections with the same name, and they are not
+ numbered to simplify GDB's handling and lookup.
+
+ There is another patch for GDB that enables both reading
+ and dumping of memory tag segments.
+
+ Tested on aarch64-linux Ubuntu 20.04.
+
+ [1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
+
+2022-07-19 Luis Machado <luis.machado@arm.com>
+
+ [AArch64] Fix testcase compilation failure
+ Newer distros carry newer headers that contains MTE definitions. Account
+ for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define
+ constants conditionally to prevent compilation failures.
+
+2022-07-19 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Pass -nostdlib to compiler with -r
+ Pass -nostdlib to compiler with -r to avoid unnecessary .o file and
+ libraries.
+
+ PR ld/29377
+ * testsuite/ld-elf/linux-x86.exp: Pass -nostdlib with -r.
+
+2022-07-19 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Properly check invalid relocation against protected symbol
+ Only check invalid relocation against protected symbol defined in shared
+ object.
+
+ bfd/
+
+ PR ld/29377
+ * elf32-i386.c (elf_i386_scan_relocs): Only check invalid
+ relocation against protected symbol defined in shared object.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+ ld/
+
+ PR ld/29377
+ * testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests.
+ * testsuite/ld-elf/pr29377a.c: New file.
+ * testsuite/ld-elf/pr29377b.c: Likewise.
+
+2022-07-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: link libgprofng.so against -lpthread
+ gprofng/ChangeLog
+ 2022-07-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29364
+ * src/Makefile.am (libgprofng_la_LIBADD): Add -lpthread.
+ * src/Makefile.in: Rebuild.
+
+2022-07-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix regression in build and a race condition in autoreconf
+ gprofng/ChangeLog
+ 2022-07-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29338
+ * libcollector/configure.ac (AC_CONFIG_HEADERS): Fix a race condition.
+ * libcollector/configure: Rebuild.
+ * libcollector/Makefile.in: Rebuild.
+ * common/config.h.in: Rebuild.
+ * common/lib-config.h.in: Created by autoreconf.
+
+2022-07-18 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.free_objfile event registry
+ Currently, Python code can use event registries to detect when gdb
+ loads a new objfile, and when gdb clears the objfile list. However,
+ there's no way to detect the removal of an objfile, say when the
+ inferior calls dlclose.
+
+ This patch adds a gdb.free_objfile event registry and arranges for an
+ event to be emitted in this case.
+
+2022-07-18 Pedro Alves <pedro@palves.net>
+
+ Put gdb.base/bt-on-fatal-signal.exp GDB cores in output dir
+ I noticed that gdb.base/bt-on-fatal-signal.exp was contributing four
+ core files to the count of unexpected core files:
+
+ $ make check TESTS="gdb.base/bt-on-fatal-signal.exp"
+
+ === gdb Summary ===
+
+ # of unexpected core files 4
+ # of expected passes 21
+
+ These are GDB core dumps. They are expected, however, because the
+ whole point of the testcase is to crash GDB with a signal.
+
+ Make GDB change its current directory to the output dir just before
+ crashing, so that the core files end up there. The result is now:
+
+ === gdb Summary ===
+
+ # of expected passes 25
+
+ and:
+
+ $ find . -name "core.*"
+ ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1676506.nelson.1657727692
+ ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1672585.nelson.1657727671
+ ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1674833.nelson.1657727683
+ ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1673709.nelson.1657727676
+
+ (Note the test is skipped at the top if on a remote host.)
+
+ Change-Id: I79e4fb2e91330279c7a509930b1952194a72e85a
+
+2022-07-18 Tom Tromey <tromey@adacore.com>
+
+ Remove array typedef assumption for Ada
+ Currently the Ada code assumes that it can distinguish between a
+ multi-dimensional array and an array of arrays by looking for an
+ intervening typedef -- that is, for an array of arrays, there will be
+ a typedef wrapping the innermost array type.
+
+ A recent compiler change removes this typedef, which causes a gdb
+ failure in the internal AdaCore test suite.
+
+ This patch handles this case by checking whether the array type in
+ question has a name.
+
+2022-07-18 Tom Tromey <tromey@adacore.com>
+
+ Remove manual lifetime management from cli_interp
+ cli_interp manually manages its cli_out object. This patch changes it
+ to use a unique_ptr, and also changes cli_uiout to be a private
+ member.
+
+ Remove cli_out_new
+ cli_out_new is just a small wrapper around 'new'. This patch removes
+ it, replacing it with uses of 'new' instead.
+
+ Replace input_interactive_p with a method
+ This replaces the global input_interactive_p function with a new
+ method ui::input_interactive_p.
+
+ Remove ui_register_input_event_handler
+ This patch removes ui_register_input_event_handler and
+ ui_unregister_input_event_handler, replacing them with methods on
+ 'ui'. It also changes gdb to use these methods everywhere, rather
+ than sometimes reaching in to the ui to manage the file descriptor
+ directly.
+
+2022-07-18 Claudiu Zissulescu <claziss@gmail.com>
+
+ opcodes/arc: Implement style support in the disassembler
+ Update the ARC disassembler to supply style information to the
+ disassembler output. The output formatting remains unchanged.
+
+ opcodes/ChangeLog:
+ * disassemble.c (disassemble_init_for_target): Set
+ created_styled_output for ARC based targets.
+ * arc-dis.c (find_format_from_table): Use fprintf_styled_ftype
+ instead of fprintf_ftype throughout.
+ (find_format): Likewise.
+ (print_flags): Likewise.
+ (print_insn_arc): Likewise.
+
+2022-07-18 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Update missing cipher.
+ The ciphers 5,7, and 9 are missing when parsing an assembly
+ instruction leading to errors when those ciphers are
+ used.
+
+ gas/config
+ * tc-arc.c (md_assembly): Update strspn string with the
+ missing ciphers.
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove duplicate of supports_gnuc
+ In commit 9d9dd861e98 ("[gdb/testsuite] Fix regression in
+ step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate
+ of supports_gnuc, which caused:
+ ...
+ DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency
+ ...
+
+ Fix this by removing the duplicate.
+
+ Tested on x86_64-linux.
+
+2022-07-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: look for python, then python 3 at configure time
+ It is possible that a system might have a python3 executable, but no
+ python executable. For example, on my Fedora system the python2
+ package provides /usr/bin/python2, the python3 package provides
+ /usr/bin/python3, and the python-unversioned-command package provides
+ /usr/bin/python, which picks between python2 and python3.
+
+ It is quite possible to only have python3 available on a system.
+
+ Currently, when GDB configures, it looks for a 'python' executable.
+ If non is found then GDB will be built without python support. Or the
+ user needs to configure using --with-python=/usr/bin/python3.
+
+ This commit updates GDB's configure.ac script to first look for
+ 'python', and then 'python3'. Now, on a system that only has a
+ python3 executable, GDB will automatically find, and use that in order
+ to provide python support, no user supplied configure arguments are
+ needed.
+
+ I've tested this on my local machine by removing the
+ python-unversioned-command package, confirming that there is no longer
+ a 'python' executable in my $PATH, and then rebuilding GDB from
+ scratch. GDB with this patch has python support.
+
+2022-07-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct VMOVSH attributes
+ Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by
+ suitable means, which would cause #UD). The memory operand form further
+ was using the wrong Masking value, thus allowing zeroing-masking to be
+ encoded for the store form (which would again cause #UD).
+
+ x86: re-order insn template fields
+ This saves quite a number of shift instructions: The "operands" field
+ can now be retrieved by just masking (no shift), and extracting the
+ "extension_opcode" field now only requires a (signed) right shift, with
+ no prereq left one. (Of course there may be architectures where, in a
+ cross build, there might be no difference at all, e.g. when there are
+ suitable bitfield extraction insns.)
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Improve thread scheduling in parallel_for_each
+ When running a task using parallel_for_each, we get the following
+ distribution:
+ ...
+ Parallel for: n_elements: 7271
+ Parallel for: minimum elements per thread: 10
+ Parallel for: elts_per_thread: 1817
+ Parallel for: elements on worker thread 0 : 1817
+ Parallel for: elements on worker thread 1 : 1817
+ Parallel for: elements on worker thread 2 : 1817
+ Parallel for: elements on worker thread 3 : 0
+ Parallel for: elements on main thread : 1820
+ ...
+
+ Note that there are 4 active threads, and scheduling elts_per_thread on each
+ of those handles 4 * 1817 == 7268, leaving 3 "left over" elements.
+
+ These leftovers are currently handled in the main thread.
+
+ That doesn't seem to matter much for this example, but for say 10 threads and
+ 99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18
+ elements.
+
+ Instead, distribute the left over elements over the worker threads, such that
+ we have:
+ ...
+ Parallel for: elements on worker thread 0 : 1818
+ Parallel for: elements on worker thread 1 : 1818
+ Parallel for: elements on worker thread 2 : 1818
+ Parallel for: elements on worker thread 3 : 0
+ Parallel for: elements on main thread : 1817
+ ...
+
+ Tested on x86_64-linux.
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Allow override of ASAN_OPTIONS in lib/gdb.exp
+ Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp.
+
+ This allows us to override the default detect_leaks=0 setting, by manually
+ doing:
+ ...
+ $ export ASAN_OPTIONS=detect_leaks=1
+ $ make check
+ ...
+
+ Tested on x86_64-linux, by building with -fsanitize=address and running
+ test-case gdb.dwarf2/gdb-add-index.exp with and without
+ "export ASAN_OPTIONS=detect_leaks=1".
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7
+ Since commit 43127ae5714 ("Fix gdb.base/step-indirect-call-thunk.exp") I run
+ into:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option \
+ '-fcf-protection=none'; did you mean '-flto-partition=none'?
+ UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare
+ ...
+
+ The problem is that -fcf-protection is supported starting gcc 8, but I'm using
+ system gcc 7.5.0.
+
+ Fix this by only adding -fcf-protection=none for gcc 8 and later.
+
+ Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1.
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/i386-mpx.exp
+ Since commit c4a3dbaf113 ("Expose current 'print' settings to Python") we
+ have:
+ ...
+ (gdb) print /x $bnd0 = {0x10, 0x20}^M
+ $22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M
+ (gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0
+ ...
+
+ The regexp in the test-case expects "size 17".
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2022-07-18 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Add parallel_for_each_debug
+ Add a parallel_for_each_debug variable, set to false by default.
+
+ With an a.out compiled from hello world, we get with
+ parallel_for_each_debug == true:
+ ...
+ $ gdb -q -batch a.out -ex start
+ ...
+ Parallel for: n_elements: 7271
+ Parallel for: minimum elements per thread: 10
+ Parallel for: elts_per_thread: 1817
+ Parallel for: elements on worker thread 0 : 1817
+ Parallel for: elements on worker thread 1 : 1817
+ Parallel for: elements on worker thread 2 : 1817
+ Parallel for: elements on worker thread 3 : 0
+ Parallel for: elements on main thread : 1820
+
+ Temporary breakpoint 1, main () at /home/vries/hello.c:6
+ 6 printf ("hello\n");
+ ...
+
+ Tested on x86_64-linux.
+
+2022-07-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-15 Aaron Merey <amerey@redhat.com>
+
+ gdb-add-index always generates an error when libdebuginfod wasn't compiled in
+ gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb
+ is not compiled against libdebuginfod this causes an unnecessary error
+ message to be printed to stderr indicating that gdb was not built with
+ debuginfod support.
+
+ Fix this by changing the 'set debuginfod enabled off' command to a
+ no-op when gdb isn't built with libdebuginfod.
+
+2022-07-15 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: modernize gdb.base/maint.exp
+ gdb.base/maint.exp was using several gdb_expect statements, probably
+ because this test case predates the existance of gdb_test_multiple. This
+ commit updates the test case to use gdb_test_multiple, making it more
+ resilient to internal errors and such.
+
+ The only gdb_expect left in the testcase is one that specifically looks
+ for an internal error being triggered as a PASS.
+
+2022-07-15 Tom Tromey <tromey@adacore.com>
+
+ Add 'nibbles' to gdb.print_options
+ When I rebased and updated the print_options patch, I forgot to update
+ print_options to add the new 'nibbles' feature to the result. This
+ patch fixes the oversight. I'm checking this in.
+
+2022-07-15 Carl Love <cel@us.ibm.com>
+
+ PowerPC: Add support for IEEE 128-bit format.
+ The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert
+ in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c. The
+ assert is due to the missing IEEE 128-bit support in file
+ gdb/ppc-sysv-tdep.c.
+
+ The IBM long double was the initial float 128-bit support added by IBM
+ The IEEE 128-bit support, which is similar IBM long double support, was
+ made the default starting with GCC 12. The floating point format
+ differences include the number of bits used to encode the exponent
+ and significand. Also, IBM long double values are passed in a pair of
+ floating point registers. The IEEE 128-bit value is passed in a single
+ vector register.
+
+ This patch fixes the gdb_assert (ok); in function
+ ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT
+ 128-bit type support for PowerPC.
+
+ The patch has been tested on Power 10, ELFv2. It fixes the following list
+ of regression failures on Power 10:
+
+ gdb.base/infcall-nested-structs-c.exp 192
+ gdb.base/infcall-nested-structs-c++.exp 76
+ gdb.base/structs.exp 9
+
+ The patch has been tested on Power 8 BE which is ELFv1.
+
+2022-07-15 Tom Tromey <tromey@adacore.com>
+
+ Add 'summary' mode to Value.format_string
+ This adds a 'summary' mode to Value.format_string and to
+ gdb.print_options. For the former, it lets Python code format values
+ using this mode. For the latter, it lets a printer potentially detect
+ if it is being called in a backtrace with 'set print frame-arguments'
+ set to 'scalars'.
+
+ I considered adding a new mode here to let a pretty-printer see
+ whether it was being called in a 'backtrace' context at all, but I'm
+ not sure if this is really desirable.
+
+2022-07-15 Tom Tromey <tromey@adacore.com>
+
+ Expose current 'print' settings to Python
+ PR python/17291 asks for access to the current print options. While I
+ think this need is largely satisfied by the existence of
+ Value.format_string, it seemed to me that a bit more could be done.
+
+ First, while Value.format_string uses the user's settings, it does not
+ react to temporary settings such as "print/x". This patch changes
+ this.
+
+ Second, there is no good way to examine the current settings (in
+ particular the temporary ones in effect for just a single "print").
+ This patch adds this as well.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
+
+2022-07-15 Carl Love <cel@us.ibm.com>
+
+ PowerPC: fix for gdb.base/eh_return.exp
+ Disable the Traceback Table generation on PowerPC for this test. The
+ Traceback Table consists of a series of bit fields to indicate things like
+ the Traceback Table version, language, and specific information about the
+ function. The Traceback Table is generated following the end of the code
+ for every function by default. The Traceback Table is defined in the
+ PowerPC ELF ABI and is intended to support debuggers and exception
+ handlers. The Traceback Table is displayed in the disassembly of functions
+ by default and is part of the function length. The table is typically
+ interpreted by the disassembler as data represented by .long xxx entries.
+
+ Generation of the Traceback Table is disabled in this test using the
+ PowerPC specific gcc compiler option -mtraceback=no, the xlc option
+ additional_flags-qtable=none and the clang optons
+ -mllvm -xcoff-traceback-table=false. Disabling the Traceback Table
+ generation in this test results in the gdb_test_multiple statement
+ correctly locating the address of the bclr instruction before the statement
+ "End of assembler dump." in the disassembly output.
+
+2022-07-15 Tom Tromey <tromey@adacore.com>
+
+ Run 'black' on gdb
+ Running 'black' on gdb fixed a couple of small issues. This patch is
+ the result.
+
+2022-07-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race in cooked_index_functions::expand_symtabs_matching
+ When building gdb with -fsanitize-threads and running test-case
+ gdb.ada/char_enum_unicode.exp, I run into:
+ ...
+ WARNING: ThreadSanitizer: data race (pid=21301)^M
+ Write of size 8 at 0x7b2000008080 by main thread:^M
+ #0 free <null> (libtsan.so.2+0x4c5e2)^M
+ #1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M
+ #2 convert_between_encodings() charset.c:584^M
+ ...
+ #21 cooked_index_functions::expand_symtabs_matching() read.c:18606
+ ...
+
+ This is fixed by making cooked_index_functions::expand_symtabs_matching wait
+ for the cooked index finalization to be done.
+
+ Tested on x86_64-linux.
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=29311
+ https://sourceware.org/bugzilla/show_bug.cgi?id=29286
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Add sequential_for_each
+ Add a sequential_for_each alongside the parallel_for_each, which can be used
+ as a drop-in replacement.
+
+ This can be useful when debugging multi-threading behaviour, and you want to
+ limit multi-threading in a fine-grained way.
+
+ Tested on x86_64-linux, by using it instead of the parallel_for_each in
+ dwarf2_build_psymtabs_hard.
+
+2022-07-14 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: Document floating-point support for LoongArch
+ Update NEWS and gdb.texinfo to document floating-point support
+ for LoongArch.
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix gdb build with gcc 4.8.5
+ When building gdb with gcc 4.8.5, we run into:
+ ...
+ In file included from /usr/include/c++/4.8/future:43:0,
+ from gdbsupport/thread-pool.h:30,
+ from gdb/dwarf2/cooked-index.h:33,
+ from gdb/dwarf2/read.h:26,
+ from gdb/dwarf2/abbrev-cache.c:21:
+ /usr/include/c++/4.8/atomic: In instantiation of \
+ ‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \
+ packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’:
+ gdb/dwarf2/read.h:332:44: required from here
+ /usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \
+ ‘packed<dwarf_unit_type, 1ul>::packed()’
+ _Tp tmp;
+ ^
+ ...
+
+ Fix this by adding the default constructor for packed.
+
+ Tested on x86_64-linux, with gdb build with gcc 4.8.5.
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Make per_cu->m_lang atomic
+ When building gdb with -fsanitize=thread and running test-case
+ gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race
+ between:
+ ...
+ Read of size 1 at 0x7b2000003010 by thread T4:
+ #0 packed<language, 1ul>::operator language() const packed.h:54
+ #1 dwarf2_per_cu_data::set_lang(language) read.h:363
+ ...
+ and:
+ ...
+ Previous write of size 1 at 0x7b2000003010 by main thread:
+ #0 dwarf2_per_cu_data::set_lang(language) read.h:365
+ ...
+
+ Fix this by making per_cu->m_lang atomic.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Make per_cu->unit_type atomic
+ With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run
+ into a data race between:
+ ...
+ Read of size 1 at 0x7b2000025f0f by main thread:
+ #0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54
+ #1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339
+ ...
+ and:
+ ...
+ Previous write of size 1 at 0x7b2000025f0f by thread T3:
+ #0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341
+ ...
+
+ Fix this by making per_cu->unit_type atomic.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286
+
+2022-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race in ~charset_vector
+ When doing:
+ ...
+ $ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26"
+ ...
+ with a gdb build with -fsanitize=thread I run into a data race:
+ ...
+ WARNING: ThreadSanitizer: data race (pid=30917)
+ Write of size 8 at 0x7b0400004070 by main thread:
+ #0 free <null> (libtsan.so.2+0x4c5e2)
+ #1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17)
+ #2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354)
+ #3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3)
+ #4 <null> <null> (libtsan.so.2+0x32643)
+ #5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a)
+ ...
+
+ The problem is that we're freeing the charset_vector elements in the destructor,
+ which may still be used by a worker thread.
+
+ Fix this by not freeing the charset_vector elements in the destructor.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29311
+
+2022-07-14 Alan Modra <amodra@gmail.com>
+
+ Re: PowerPC: implement md_operand to parse register names
+ I meant to make this change before committing, to let compilers know
+ the code on the false branch of md_parse_name is dead.
+
+ * config/tc-ppc.c (ppc_parse_name): Return void.
+ * config/tc-ppc.h (md_parse_name): Always true.
+ (ppc_parse_name): Update prototype.
+
+2022-07-14 Alan Modra <amodra@gmail.com>
+
+ PowerPC: implement md_operand to parse register names
+ Allows register names to appear in symbol assignments, so for example
+ tocp = %r2
+ mr %r3,tocp
+ now assembles.
+
+ * gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with
+ ARRAY_SIZE.
+ (register_name): Rename to..
+ (md_operand): ..this. Only handle %reg.
+ (cr_names): Rename to..
+ (cr_cond): ..this. Just keep conditions.
+ (ppc_parse_name): Add mode param. Search both cr_cond and
+ pre_defined_registers. Handle absolute and register symbol
+ values here rather than in expr.c:operand().
+ (md_assemble): Don't special case register name matching in
+ operands, except to set cr_operand as appropriate.
+ * gas/config/tc-ppc.h (md_operand): Don't define.
+ (md_parse_name, ppc_parse_name): Update.
+ * read.c (pseudo_set): Copy over entire O_register value.
+ * testsuite/gas/ppc/regsyms.d.
+ * testsuite/gas/ppc/regsyms.s: New test.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+
+2022-07-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-13 Pedro Alves <pedro@palves.net>
+
+ Tighten gdb.threads/no-unwaited-for-left.exp regexps
+ A WIP version of a patch
+ (https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html)
+ resulted in a bug that went unnoticed by the testuite, like so:
+
+ (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread
+ continue
+ Continuing.
+ [New Thread 1251861.1251861]
+ No unwaited-for children left.
+ (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
+ info threads
+ Id Target Id Frame
+ 3 Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
+ 4 Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? ()
+
+ The current thread <Thread ID 1> has terminated. See `help thread'.
+ (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated
+
+ Somehow, above, GDB re-added the zombie leader back before printing
+ "No unwaited-for children left.". The "only thread 3 left, main
+ thread terminated" test should have caught this, but didn't. That is
+ because the test's regexp has a ".*" after the part that matches
+ thread 3. This commit tightens that regexp to catch such a bug. It
+ also tightens the "only main thread left, thread 2 terminated" test's
+ regexp in the same way.
+
+ Change-Id: I8744f327a0aa0e2669d1ddda88247e99b91cefff
+
+2022-07-13 Carl Love <cel@us.ibm.com>
+
+ Fix for gdb.base/stap-probe.c
+ On PowePC, the test fails on a compile error:
+
+ /../binutils-gdb-current/gdb/testsuite/gdb.base/stap-probe.c:107:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'use_xmm_reg'
+ 107 | use_xmm_reg (int val)
+ | ^~~~~~~~~~~
+
+ Where the source code for stap-probe.c is:
+
+ static const char * __attribute__((noinline)) ATTRIBUTE_NOCLONE
+ use_xmm_reg (int val) <-- line 107
+ {
+ ...
+
+ The issue is the ATTRIBUTE_NOCLONE is not defined as an attribute as
+ expected. The #define for ATTRIBUTE_NOCLONE can be found in
+ ../lib/attributes.h.
+
+ This patch adds the missing include statement for the definition of
+ ATTRIBUTE_NOCLONE.
+
+ The patch has been tested and verified on a Power10 system.
+
+2022-07-13 Carl Love <cel@us.ibm.com>
+
+ Add PowerPC support to gdb.cp/call-method-register.cc
+ This patch adds the needed define ASM_REG for PowerPC.
+
+ The patch was run on a Power 10 system. The gdb Summary for the run lists
+ 2 expected passes, no unexpected failures or untested testcases.
+
+ Please let me know if this patch is acceptable for mainline.
+
+ Carl Love
+
+2022-07-13 Carl Love <cel@us.ibm.com>
+
+ Fix gdb.base/step-indirect-call-thunk.exp
+ Due to recent changes in the default value of -fcf-protection for gcc, the
+ test gdb.base/step-indirect-call-thunk.exp fails on Intel X86-64 with the
+ error:
+
+ Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never
+ -mindirect-branch=thunk -mfunction-return=thunk -c -g
+ -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
+ /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c
+ (timeout = 300) builtin_spawn -ignore SIGHUP gcc -fno-stack-protector
+ -fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c
+ -g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
+ /.../binutils-gdb-current/gdb/testsuite/gdb.base/step-indirect-call-thunk.c
+ /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
+ In function 'inc': /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
+ 22:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible
+ 22 | { /* inc.1 */
+
+ As stated in the error message the default "-fcf-protection" and
+ "-mindirect-branch' are in compatible. The fcf-protection argument needs
+ to be "-fcf-protection=none" for the test to compile on Intel.
+
+ The gcc command line "-mindirect-branch' is an Intel specific and will give
+ an error on other platforms. A check for X86 is added so the test will
+ only run on X86 platforms.
+
+ The patch has been tested and verified on Power 10 and Intel X86-64 systems
+ with no regressions.
+
+2022-07-13 Pedro Alves <pedro@palves.net>
+
+ Fix "until LINE" in main, when "until" runs into longjmp
+ With a test like this:
+
+ 1 #include <dlfcn.h>
+ 2 int
+ 3 main ()
+ 4 {
+ 5 dlsym (RTLD_DEFAULT, "FOO");
+ 6 return 0;
+ 7 }
+
+ and then "start" followed by "until 6", GDB currently incorrectly
+ stops inside the runtime loader, instead of line 6. Vis:
+
+ ...
+ Temporary breakpoint 1, main () at until.c:5
+ 4 {
+ (gdb) until 6
+ 0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206
+ 206 dl-error-skeleton.c: No such file or directory.
+ (gdb)
+
+ The problem is related to longjmp handling -- dlsym internally
+ longjmps on error. The testcase can be reduced to this:
+
+ 1 #include <setjmp.h>
+ 2 void func () {
+ 3 jmp_buf buf;
+ 4 if (setjmp (buf) == 0)
+ 5 longjmp (buf, 1);
+ 6 }
+ 7
+ 8 int main () {
+ 9 func ();
+ 10 return 0; /* until to here */
+ 11 }
+
+ and then with "start" followed by "until 10", GDB currently
+ incorrectly stops at line 4 (returning from setjmp), instead of line
+ 10.
+
+ The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in
+ infrun.c fails to find the initiating frame, and so infrun thinks that
+ the longjmp jumped somewhere outer to "until"'s originating frame.
+
+ Here:
+
+ case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME:
+ {
+ struct frame_info *init_frame;
+
+ /* There are several cases to consider.
+
+ 1. The initiating frame no longer exists. In this case we
+ must stop, because the exception or longjmp has gone too
+ far.
+
+ ...
+
+ init_frame = frame_find_by_id (ecs->event_thread->initiating_frame);
+
+ if (init_frame) // this is NULL!
+ {
+ ...
+ }
+
+ /* For Cases 1 and 2, remove the step-resume breakpoint, if it
+ exists. */
+ delete_step_resume_breakpoint (ecs->event_thread);
+
+ end_stepping_range (ecs); // case 1., so we stop.
+ }
+
+ The initiating frame is set by until_break_command ->
+ set_longjmp_breakpoint. The initiating frame is supposed to be the
+ frame that is selected when the command was issued, but
+ until_break_command instead passes the frame id of the _caller_ frame
+ by mistake. When the "until LINE" command is issued from main, the
+ caller frame is the caller of main. When later infrun tries to find
+ that frame by id, it fails to find it, because frame_find_by_id
+ doesn't unwind past main.
+
+ The bug is that we passed the caller frame's id to
+ set_longjmp_breakpoint. We should have passed the selected frame's id
+ instead.
+
+ Change-Id: Iaae1af7cdddf296b7c5af82c3b5b7d9b66755b1c
+
+2022-07-13 Enze Li <enze.li@hotmail.com>
+
+ gdbserver: remove unused variable
+ When building with clang 15, I got this error:
+
+ CXX server.o
+ server.cc:2985:10: error: variable 'new_argc' set but not used [-Werror,-Wunused-but-set-variable]
+ int i, new_argc;
+ ^
+ Remove the unused variable to eliminate the error.
+
+ Tested by rebuilding on x86_64-linux with clang 15.
+
+2022-07-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Make per_cu->set_lang more strict
+ We have in per_cu->set_lang this comment:
+ ...
+ void set_lang (enum language lang)
+ {
+ /* We'd like to be more strict here, similar to what is done in
+ set_unit_type, but currently a partial unit can go from unknown to
+ minimal to ada to c. */
+ ...
+
+ Fix this by not setting m_lang for partial units.
+
+ This requires us to move the m_unit_type initialization to ensure that
+ m_unit_type is initialized before per_cu->m_lang.
+
+ Tested on x86_64-linux, with native and target board cc-with-dwz-m.
+
+2022-07-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-12 Pedro Alves <pedro@palves.net>
+
+ Improve "set scheduler-locking" documentation
+ This improves the "set scheduler-locking" documentation in the GDB
+ manual:
+
+ - Use a table to describe the four available modes.
+
+ - Describe "step" in terms of "on" and "off".
+
+ - Tweak the "replay" mode's description to describe replay first
+ instead of recording, and also mention how the mode behaves during
+ normal execution.
+
+ - Say what is the default mode.
+
+ Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add dwarf2_cu::lang ()
+ The cu->per_cu->lang field was added to carry information from the initial
+ partial symtabs phase to the symtab expansion phase, for the benefit of a
+ particular optimization in process_imported_unit_die.
+
+ Other uses have been added, but since the first phase now has been
+ parallelized, those have become problematic and sources of race conditions.
+
+ Fix this by adding dwarf2_cu::lang () and using it where we can to replace
+ cu->per_cu->lang () with cu->lang ().
+
+ Also assert in dwarf2_cu::lang () that we're not returning language_unknown.
+
+ Tested on x86_64-linux.
+
+2022-07-12 Martin Liska <mliska@suse.cz>
+
+ LTO plugin: sync header file with GCC
+ include/ChangeLog:
+
+ * plugin-api.h (enum ld_plugin_tag): Sync with GCC.
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/record] Support recording of getrandom
+ Add missing support for recording of linux syscall getrandom.
+
+ Tested on x86_64-linux with native and target board unix/-m32.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22081
+
+2022-07-12 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdbserver: LoongArch: Add floating-point support
+ This commit adds floating-point support for LoongArch gdbserver.
+
+ gdb: LoongArch: Add floating-point support
+ This commit adds floating-point support for LoongArch gdb.
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Run two test-cases with ASAN_OPTIONS=verify_asan_link_order=0
+ When building gdb with -fsanitize=address we run into:
+ ...
+ builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \
+ build/gdb/data-directory^M
+ ==10637==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
+ ERROR: GDB process no longer exists
+ ...
+
+ Prevent the ASan runtime error by using
+ ASAN_OPTIONS=verify_asan_link_order=0. This makes both test-cases pass.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29358
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add tsan-suppressions.txt
+ Add a new file tsan-suppressions.txt, to suppress the "unlock unlocked mutex"
+ problem in ncurses, filed in PR29328.
+
+ The file is added to the TSAN_OPTIONS in lib/gdb.exp.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29328
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with gcc 4.8.5
+ When building gdb with gcc 4.8.5, we run into problems due to unconditionally
+ using:
+ ...
+ gdb_static_assert (std::is_trivially_copyable<packed>::value);
+ ...
+ in gdbsupport/packed.h.
+
+ Fix this by guarding the usage with HAVE_IS_TRIVIALLY_COPYABLE.
+
+ Tested by doing a full gdb build with gcc 4.8.5.
+
+2022-07-12 Tom de Vries <tdevries@suse.de>
+
+ Fix -fsanitize=thread for per_cu fields
+ When building gdb with -fsanitize=thread and gcc 12, and running test-case
+ gdb.dwarf2/dwz.exp, we run into a data race between:
+ ...
+ Read of size 1 at 0x7b200000300d by thread T2:^M
+ #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
+ (gdb+0x82ec95)^M
+ ...
+ and:
+ ...
+ Previous write of size 1 at 0x7b200000300d by main thread:^M
+ #0 prepare_one_comp_unit gdb/dwarf2/read.c:23588 (gdb+0x86f973)^M
+ ...
+
+ In other words, between:
+ ...
+ if (this_cu->reading_dwo_directly)
+ ...
+ and:
+ ...
+ cu->per_cu->lang = pretend_language;
+ ...
+
+ Likewise, we run into a data race between:
+ ...
+ Write of size 1 at 0x7b200000300e by thread T4:
+ #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720)
+ ...
+ and:
+ ...
+ Previous read of size 1 at 0x7b200000300e by main thread:
+ #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
+ (gdb+0x82edab)
+ ...
+
+ In other words, between:
+ ...
+ this_cu->unit_type = DW_UT_partial;
+ ...
+ and:
+ ...
+ if (this_cu->reading_dwo_directly)
+ ...
+
+ Likewise for the write to addresses_seen in cooked_indexer::check_bounds and a
+ read from is_dwz in dwarf2_find_containing_comp_unit for test-case
+ gdb.dwarf2/dw2-dir-file-name.exp and target board cc-with-dwz-m.
+
+ The problem is that the written fields are part of the same memory location as
+ the read fields, so executing a read and write in different threads is
+ undefined behavour.
+
+ Making the written fields separate memory locations, using the new
+ struct packed template fixes this.
+
+ The set of fields has been established experimentally to be the
+ minimal set to get rid of this type of -fsanitize=thread errors, but
+ more fields might require the same treatment.
+
+ Looking at the properties of the lang field, unlike dwarf_version it's
+ not available in the unit header, so it will be set the first time
+ during the parallel cooked index reading. The same holds for
+ unit_type, and likewise for addresses_seen.
+
+ dwarf2_per_cu_data::addresses_seen is moved so that the bitfields that
+ currently follow it can be merged in the same memory location as the
+ bitfields that currently precede it, for better packing.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+ Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
+
+2022-07-12 Pedro Alves <pedro@palves.net>
+
+ Introduce struct packed template
+ When building gdb with -fsanitize=thread and gcc 12, and running test-case
+ gdb.dwarf2/dwz.exp, we run into a few data races. For example, between:
+
+ ...
+ Write of size 1 at 0x7b200000300e by thread T4:
+ #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720)
+ ...
+
+ and:
+
+ ...
+ Previous read of size 1 at 0x7b200000300e by main thread:
+ #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
+ (gdb+0x82edab)
+ ...
+
+ In other words, between:
+
+ ...
+ this_cu->unit_type = DW_UT_partial;
+ ...
+
+ and:
+
+ ...
+ if (this_cu->reading_dwo_directly)
+ ...
+
+ The problem is that the written fields are part of the same memory
+ location as the read fields, so executing a read and write in
+ different threads is undefined behavour.
+
+ Making the written fields separate memory locations, like this:
+
+ ...
+ struct {
+ ENUM_BITFIELD (dwarf_unit_type) unit_type : 8;
+ };
+ ...
+
+ fixes it, however that also increases the size of struct
+ dwarf2_per_cu_data, because it introduces padding due to alignment of
+ these new structs, which align on the natural alignment of the
+ specified type of their fields. We can fix that with
+ __attribute__((packed)), like so:
+
+ struct {
+ ENUM_BITFIELD (dwarf_unit_type) unit_type : 8 __attribute__((packed));
+ };
+
+ but to avoid having to write that in several places and add suitable
+ comments explaining how that concoction works, introduce a new struct
+ packed template that wraps/hides this. Instead of the above, we'll be
+ able to write:
+
+ packed<dwarf_unit_type, 1> unit_type;
+
+ Note that we can't change the type of dwarf_unit_type, as that is
+ defined in include/, and shared with other projects, some of those
+ written in C.
+
+ This patch just adds the struct packed type. Following patches will
+ make use of it. One of those patches will want to wrap a struct
+ packed in an std::atomic, like:
+
+ std::atomic<std::packed<language, 1>> m_lang;
+
+ so the new gdbsupport/packed.h header adds some operators to make
+ comparisions between that std::atomic and the type that the wrapped
+ struct packed wraps work, like in:
+
+ if (m_lang == language_c)
+
+ It would be possible to implement struct packed without using
+ __attribute__((packed)), by having it store an array of bytes of the
+ appropriate size instead, however that would make it less convenient
+ to debug GDB. The way it's implemented, printing a struct packed
+ variable just prints its field using its natural type, which is
+ particularly useful if the type is an enum. I believe that
+ __attribute__((packed)) is supported by all compilers that are able to
+ build GDB. Even a few BFD headers use on ATTRIBUTE_PACKED on external
+ types:
+
+ include/coff/external.h: } ATTRIBUTE_PACKED
+ include/coff/external.h:} ATTRIBUTE_PACKED ;
+ include/coff/external.h:} ATTRIBUTE_PACKED ;
+ include/coff/pe.h:} ATTRIBUTE_PACKED ;
+ include/coff/pe.h:} ATTRIBUTE_PACKED;
+ include/elf/external.h:} ATTRIBUTE_PACKED Elf_External_Versym;
+
+ It is not possible to build GDB with MSVC today, but if it could, that
+ would be one compiler that doesn't support this attribute. However,
+ it supports packing via pragmas, so there's a way to cross that bridge
+ if we ever get to it. I believe any compiler worth its salt supports
+ some way of packing.
+
+ In any case, the worse that happens without the attribute is that some
+ types become larger than ideal. Regardless, I've added a couple
+ static assertions to catch such compilers in action:
+
+ /* Ensure size and aligment are what we expect. */
+ gdb_static_assert (sizeof (packed) == Bytes);
+ gdb_static_assert (alignof (packed) == 1);
+
+ Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
+
+2022-07-12 Alan Modra <amodra@gmail.com>
+
+ PowerPC md_end: Don't htab_delete(NULL)
+ It might be possible to hit md_end before md_begin is called, don't
+ segfault if so. Also, remove a useless check.
+
+ * gas/config/tc-ppc.c (insn_calloc): Remove needless overflow
+ check.
+ (ppc_md_end): Check ppc_hash before deleting. Clear ppc_hash.
+
+2022-07-12 Alan Modra <amodra@gmail.com>
+
+ PR29355, ld segfaults with -r/-q and custom-named section .rela*
+ The bug testcase uses an output section named .rel or .rela which has
+ input .data sections mapped to it. The input .data section has
+ relocations. When counting output relocations SHT_REL and SHT_RELA
+ section reloc_count is ignored, with the justification that reloc
+ sections themselves can't have relocations and some backends use
+ reloc_count in reloc sections. However, the test wrongly used the
+ output section type (which normally would match input section type).
+ Fix that. Note that it is arguably wrong for ld to leave the output
+ .rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc
+ sections are written to it, but I'm not going to change that since it
+ might be useful to hand-craft relocs in a data section that is then
+ written to a SHT_REL/SHT_RELA output section.
+
+ PR 29355
+ * elflink.c (bfd_elf_final_link): Use input section type rather
+ than output section type to determine whether to exclude using
+ reloc_count from that section.
+
+2022-07-12 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ gdb/csky complete csky_dwarf_reg_to_regnum
+ For csky arch, the correspondence between Dwarf registers and GDB
+ registers are as follows:
+ dwarf regnos 0~31 ==> gdb regs r0~r31
+ dwarf regno CSKY_HI_REGNUM(36) ==> gdb reg hi
+ dwarf regno CSKY_LO_REGNUM(37) ==> gdb reg hi
+ dwarf regno CSKY_PC_REGNUM(72) ==> gdb reg pc
+ dwarf regnos FV_PSEUDO_REGNO_FIRST(74)~FV_PSEUDO_REGNO_LAST(201)
+ ==>
+ gdb regs s0~s127 (pseudo regs for float and vector regs)
+
+ other dwarf regnos have no corresponding gdb regs to them.
+
+2022-07-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-11 Pedro Alves <pedro@palves.net>
+
+ Always emit =thread-exited notifications, even if silent
+ [Note: the testcased added by this commit depends on
+ https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html,
+ otherwise GDB just crashes when detaching the core]
+
+ Currently, in MI, =thread-created are always emitted, like:
+
+ =thread-group-started,id="i1",pid="195680"
+ =thread-created,id="1",group-id="i1"
+ ...
+
+ but on teardown, if the target uses exit_inferior_silent, then you'll
+ only see the inferior exit notification (thread-group-exited), no
+ notification for threads.
+
+ The core target is one of the few targets that use
+ exit_inferior_silent. Here's an example session:
+
+ -target-select core $corefile
+ =thread-group-started,id="i1",pid="195680"
+ =thread-created,id="1",group-id="i1"
+ ...
+ ^connected,frame=....
+ (gdb)
+ -target-detach
+ =thread-group-exited,id="i1"
+ ^done
+ (gdb)
+
+ This imbalance of emitting =thread-created but then not =thread-exited
+ seems off to me. (And, it complicates changes I want to do to
+ centralize emitting thread exit notifications for the CLI, which is
+ why I'm looking at this.)
+
+ And then, since most other targets use exit_inferior instead of
+ exit_inferior_silent, MI is already emitting =thread-exited
+ notifications when tearing down an inferior, for most targets.
+
+ This commit makes MI always emit the =thread-exited notifications,
+ even for exit_inferior_silent.
+
+ Afterwards, when debugging a core, MI outputs:
+
+ (gdb)
+ -target-detach
+ =thread-exited,id="1",group-id="i1" << new line
+ =thread-group-exited,id="i1"
+ ^done
+ (gdb)
+
+ Surprisingly, there's no MI testcase debugging a core file. This
+ commit adds the first.
+
+ Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4
+
+2022-07-11 Pedro Alves <pedro@palves.net>
+
+ Fix core-file -> detach -> crash (corefiles/29275)
+ After loading a core file, you're supposed to be able to use "detach"
+ to unload the core file. That unfortunately regressed starting with
+ GDB 11, with these commits:
+
+ 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
+ 408f66864a1a - detach in all-stop with threads running
+
+ resulting in a GDB crash:
+
+ ...
+ Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
+ 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
+ 2899 if (proc_target->commit_resumed_state)
+ (top-gdb) bt
+ #0 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
+ #1 0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
+ #2 0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
+ #3 0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
+ #4 0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
+ #5 0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
+ #6 0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699
+
+ The code that crashes looks like:
+
+ static void
+ maybe_set_commit_resumed_all_targets ()
+ {
+ scoped_restore_current_thread restore_thread;
+
+ for (inferior *inf : all_non_exited_inferiors ())
+ {
+ process_stratum_target *proc_target = inf->process_target ();
+
+ if (proc_target->commit_resumed_state)
+ ^^^^^^^^^^^
+
+ With 'proc_target' above being null. all_non_exited_inferiors filters
+ out inferiors that have pid==0. We get here at the end of
+ detach_command, after core_target::detach has already run, at which
+ point the inferior _should_ have pid==0 and no process target. It is
+ clear it no longer has a process target, but, it still has a pid!=0
+ somehow.
+
+ The reason the inferior still has pid!=0, is that core_target::detach
+ just unpushes, and relies on core_target::close to actually do the
+ getting rid of the core and exiting the inferior. The problem with
+ that is that detach_command grabs an extra strong reference to the
+ process stratum target, so the unpush_target inside
+ core_target::detach doesn't actually result in a call to
+ core_target::close.
+
+ Fix this my moving the cleaning up the core inferior to a shared
+ routine called by both core_target::close and core_target::detach. We
+ still need to cleanup the inferior from within core_file::close
+ because there are paths to it that want to get rid of the core without
+ going through detach. E.g., "core-file" -> "run".
+
+ This commit includes a new test added to gdb.base/corefile.exp to
+ cover the "core-file core" -> "detach" scenario.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275
+
+ Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893
+
+2022-07-11 Pedro Alves <pedro@palves.net>
+
+ Fix non-existent "@var{thread-id}" in stop reply descriptions
+ In the description of stop replies, where the "thread" register is
+ explained, and where the fork and vfork stop reasons are detailed,
+ there are references to "@var{thread-id}", but such variable does not
+ actually exist. This commit fixes it.
+
+ Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab
+
+2022-07-11 Luis Machado <luis.machado@arm.com>
+
+ Try a couple PAuth compilation flags for gdb.arch/aarch64-pauth.exp
+ The -msign-return-address switch has been dropped from GCC, but some
+ older compiler may still support it. Make sure we try both
+ -msign-return-address and -mbranch-protection before bailing out when
+ running gdb.arch/aarch64-pauth.exp.
+
+2022-07-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add support for disassembler styling using libopcodes
+ This commit extends GDB to make use of libopcodes styling support
+ where available, currently this is just i386 based architectures, and
+ RISC-V.
+
+ For architectures that don't support styling using libopcodes GDB will
+ fall back to using the Python Pygments package, when the package is
+ available.
+
+ The new libopcodes based styling has the disassembler identify parts
+ of the disassembled instruction, e.g. registers, immediates,
+ mnemonics, etc, and can style these components differently.
+ Additionally, as the styling is now done in GDB we can add settings to
+ allow the user to configure which colours are used right from the GDB
+ CLI.
+
+ There's some new maintenance commands:
+
+ maintenance set libopcodes-styling enabled on|off
+ maintenance show libopcodes-styling
+
+ These can be used to manually disable use of libopcodes styling. This
+ is a maintenance command as it's not anticipated that a user should
+ need to do this. But, this could be useful for testing, or, in some
+ rare cases, a user might want to override the Python hook used for
+ disassembler styling, and then disable libopcode styling so that GDB
+ falls back to using Python. Right now I would consider this second
+ use case a rare situation, which is why I think a maintenance command
+ is appropriate.
+
+ When libopcodes is being used for styling then the user can make use
+ of the following new styles:
+
+ set/show style disassembler comment
+ set/show style disassembler immediate
+ set/show style disassembler mnemonic
+ set/show style disassembler register
+
+ The disassembler also makes use of the 'address' and 'function'
+ styles to style some parts of the disassembler output. I have also
+ added the following aliases though:
+
+ set/show style disassembler address
+ set/show style disassembler symbol
+
+ these are aliases for:
+
+ set/show style address
+ set/show style function
+
+ respectively, and exist to make it easier for users to discover
+ disassembler related style settings. The 'address' style is used to
+ style numeric addresses in the disassembler output, while the 'symbol'
+ or 'function' style is used to style the names of symbols in
+ disassembler output.
+
+ As not every architecture supports libopcodes styling, the maintenance
+ setting 'libopcodes-styling enabled' has an "auto-off" type behaviour.
+ Consider this GDB session:
+
+ (gdb) show architecture
+ The target architecture is set to "auto" (currently "i386:x86-64").
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "on".
+
+ the setting defaults to "on" for architectures that support libopcodes
+ based styling.
+
+ (gdb) set architecture sparc
+ The target architecture is set to "sparc".
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "off" (not supported on architecture "sparc")
+
+ the setting will show as "off" if the user switches to an architecture
+ that doesn't support libopcodes styling. The underlying setting is
+ still "on" at this point though, if the user switches back to
+ i386:x86-64 then the setting would go back to being "on".
+
+ (gdb) maintenance set libopcodes-styling enabled off
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "off".
+
+ now the setting is "off" for everyone, even if the user switches back
+ to i386:x86-64 the setting will still show as "off".
+
+ (gdb) maintenance set libopcodes-styling enabled on
+ Use of libopcodes styling not supported on architecture "sparc".
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "off".
+
+ attempting to switch the setting "on" for an unsupported architecture
+ will give an error, and the setting will remain "off".
+
+ (gdb) set architecture auto
+ The target architecture is set to "auto" (currently "i386:x86-64").
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "off".
+ (gdb) maintenance set libopcodes-styling enabled on
+ (gdb) maintenance show libopcodes-styling enabled
+ Use of libopcodes styling support is "on".
+
+ the user will need to switch back to a supported architecture before
+ they can one again turn this setting "on".
+
+2022-07-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have gdb_disassemble_info carry 'this' in its stream pointer
+ The gdb_disassemble_info class is a wrapper around the libopcodes
+ disassemble_info struct. The 'stream' field of disassemble_info is
+ passed as an argument to the fprintf_func and fprintf_styled_func
+ callbacks when the disassembler wants to print anything.
+
+ Previously, GDB would store a pointer to a ui_file object in the
+ 'stream' field, then, when the disassembler wanted to print anything,
+ the content would be written to the ui_file object. An example of an
+ fprintf_func callback, from gdb/disasm.c is:
+
+ int
+ gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...)
+ {
+ /* Write output to STREAM here. */
+ }
+
+ This is fine, but has one limitation, within the print callbacks we
+ only have access to STREAM, we can't access any additional state
+ stored within the gdb_disassemble_info object.
+
+ Right now this isn't a problem, but in a future commit this will
+ become an issue, how we style the output being written to STREAM will
+ depend on the state of the gdb_disassemble_info object, and this state
+ might need to be updated, depending on what is being printed.
+
+ In this commit I propose changing the 'stream' field of the
+ disassemble_info to carry a pointer to the gdb_disassemble_info
+ sub-class, rather than the stream itself.
+
+ We then have the two sub-classes of gdb_disassemble_info to consider,
+ the gdb_non_printing_disassembler class never cared about the stream,
+ previously, for this class, the stream was nullptr. With the change
+ to make stream be a gdb_disassemble_info pointer, no further updates
+ are needed for gdb_non_printing_disassembler.
+
+ The other sub-class is gdb_printing_disassembler. In this case the
+ sub-class now carries around a pointer to the stream object. The
+ print callbacks are updated to cast the incoming stream object back to
+ a gdb_printing_disassembler, and then extract the stream.
+
+ This is purely a refactoring commit. A later commit will add
+ additional state to the gdb_printing_disassembler, and update the
+ print callbacks to access this state.
+
+ There should be no user visible changes after this commit.
+
+2022-07-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race in per_cu->length
+ With gdb build with -fsanitize=thread and test-case
+ gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data
+ race between:
+ ...
+ Write of size 4 at 0x7b2800002268 by thread T4:^M
+ #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \
+ (gdb+0x82f525)^M
+ ...
+ and this read:
+ ...
+ Previous read of size 4 at 0x7b2800002268 by thread T1:^M
+ #0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \
+ (gdb+0x86e22e)^M
+ ...
+
+ In other words, between this write:
+ ...
+ this_cu->length = cu->header.get_length ();
+ ...
+ and this read:
+ ...
+ && mid_cu->sect_off + mid_cu->length > sect_off))
+ ...
+ of per_cu->length.
+
+ Fix this similar to the per_cu->dwarf_version case, by only setting it if
+ needed, and otherwise verifying that the same value is used. [ Note that the
+ same code is already present in the other cutu_reader constructor. ]
+
+ Move this logic into into a member function set_length to make sure it's used
+ consistenly, and make the field private in order to enforce access through the
+ member functions, and rename it to m_length.
+
+ This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in
+ fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten.
+ For now, allow for that exception.
+
+ While we're at it, make sure that the length is set before read.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29344
+
+2022-07-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Use comp_unit_head::get_length
+ There's a spot in read_comp_units_from_section where we explictly use
+ initial_length_size to get the total length:
+ ...
+ this_cu->length = cu_header.length + cu_header.initial_length_size;
+ ...
+
+ Instead, just use cu_header.get_length ().
+
+ Tested on x86_64-linux.
+
+2022-07-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-10 Luis Machado <luis.machado@arm.com>
+
+ Fix include guard naming for arch/aarch64-mte-linux.h
+ It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.
+
+2022-07-10 Youling Tang <tangyouling@loongson.cn>
+
+ gdbserver: LoongArch: Add orig_a0 processing
+ Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set")
+ introduced orig_a0, similar processing needs to be done in gdbserver.
+
+ At the same time, add orig_a0 related comments.
+
+2022-07-10 Youling Tang <tangyouling@loongson.cn>
+
+ gdbserver: LoongArch: Simplify code with register number macros
+ Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the
+ macro definitions can be used in gdbserver/linux-loongarch-low.cc
+ to simplify the code.
+
+2022-07-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: tc-tic54x.c hash tables
+ Cleaning up the subsym_hash memory is a real pain. Keys and values
+ entered into the table are quite diverse. In some cases the key is
+ allocated and thus needs to be freed, in others the key is a const
+ string. Values are similar, and in some cases not even a string.
+ Tidy this by inserting a new subsym_ent_t that describes key/value
+ type. This meant the math_hash table was no longer needed. The patch
+ also tidies how math functions are called, those that are supposed to
+ return int now no longer return their value in a float.
+
+ * config/tc-tic54x.c (math_hash): Delete.
+ (subsym_proc_entry): Move earlier, make proc a union, merge with..
+ (math_proc_entry): ..this. Delete type.
+ (math_procs): Merge into subsym_procs.
+ (subsym_ent_t): New. Use this type in subsym_hash..
+ (stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here..
+ (md_begin, subsym_create_or_replace, subsym_lookup): ..and here..
+ (subsym_substitute): ..and here. Adjust subsym_proc_entry
+ function calls. Free replacement when not returned.
+ (subsym_get_arg): Adjust subsym_lookup.
+ (free_subsym_ent, subsym_htab_create ): New functions, use when
+ creating subsym_hash.
+ (free_local_label_ent, local_label_htab_create): Similarly.
+ (tic54x_remove_local_label): Delete.
+ (tic54x_clear_local_labels): Simplify.
+ (tic54x_asg): Use notes obstack to dup strings.
+ (tic54x_eval): Likewise.
+ (subsym_ismember): Likewise.
+ (math_cvi, math_int, math_sgn): Return int.
+ (tic54x_macro_start): Decrement macro_level before calling as_fatal.
+ (tic54x_md_end): New function.
+ * config/tc-tic54h.c (tic54x_md_end): Declare.
+ (md_end): Define.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: use notes_calloc in string hash
+ Using notes_calloc means all of the string hash table memory should
+ now be freed before gas exits, even though htab_delete isn't called.
+ This also means that the hash table free_f and del_f must be NULL,
+ because freeing notes obstack memory results in all more recently
+ allocated notes memory being freed too. So hash table resizing won't
+ free any memory, and will be a little faster. Also, htab_delete won't
+ do anything (and be quick about it).
+
+ Since htab_traverse can also resize hash tables (to make another
+ traversal faster if the table is largely empty), stop that happening
+ when only one traversal is done.
+
+ * as.h: Reorder hash.h after symbols.h for notes_calloc decl.
+ * hash.h (str_htab_create): Use notes_calloc. Do not free.
+ * symbols.c (resolve_local_symbol_values): Don't resize
+ during hash table traversal.
+ * config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
+ * config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise.
+ * config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: target string hash tables
+ This allocates entries added to the string hash tables on the notes
+ obstack, so that at least those do not leak. A followup patch will
+ switch over the str_hash allocation to notes_calloc, which is why I
+ haven't implemented deleting all the target string hash tables.
+
+ * config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use
+ notes obstack for string hash table entries.
+ * config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise.
+ * config/tc-h8300.c (md_begin): Likewise.
+ * config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise.
+ * config/tc-nds32.c (nds32_relax_hint): Likewise.
+ * config/tc-riscv.c (riscv_init_csr_hash): Likewise.
+ * config/tc-score.c (s3_insert_reg): Likewise.
+ (s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise.
+ * config/tc-score7.c (s7_build_score_ops_hsh): Likewise.
+ (s7_build_dependency_insn_hsh): Likewise.
+ * config/tc-tic4x.c (tic4x_asg): Likewise.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ arc gas: don't leak arc_opcode_hash memory
+ The arc opcode hash table has entries that have a realloc'd field.
+ This doesn't lend itself to obstack allocation, so freeing must be
+ done with a purpose built hashtab del_f.
+
+ * config/tc-arc.c (arc_opcode_free): New function.
+ (md_begin): Pass the above as del_f to htab_create_alloc.
+ (arc_md_end): New function.
+ * config/tc-arc.h (arc_md_end): Declare.
+ (md_end): Define.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ i386 gas: don't leak op_hash or reg_hash memory
+ This tidies memory used by the two x86 gas string hash tables before
+ exiting. I'm using a two-pronged approach, firstly the obvious call
+ to htab_delete plus telling the libiberty/hashtab.c infrastructure to
+ free tuples generated by str_hash_insert, and secondly putting the x86
+ core_optab memory on the notes obstack. It would be possible to free
+ core_optab memory by using a custom hash table del_f on x86, as I do
+ for arc, but a later patch will move all the string hash memory to the
+ notes obstack.
+
+ * config/tc-i386.c (md_begin): Use notes_alloc for core_optab.
+ (386_md_end): New function.
+ * config/tc-i386.h (386_md_end): Declare.
+ (md_end): Define.
+ * hash.h (str_htab_create): Pass free as del_f.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ ppc gas: don't leak ppc_hash memory
+ * config/tc-ppc.c (insn_obstack): New.
+ (insn_calloc): New function.
+ (ppc_setup_opcodes): Use insn_obstack for ppc_hash.
+ (ppc_md_end): New function.
+ * config/tc-ppc.h (ppc_md_end): Declare
+ (md_end): Define.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas hash.h tidy
+ Only inline functions should be defined in hash.h, there's no benefit
+ in having multiple copies of hash_string_tuple and eq_string_tuple.
+ Also, use the table alloc_f when allocating tuples to be stored, so
+ that these functions are usable with different memory allocation
+ strategies.
+
+ * hash.h (struct string_tuple, string_tuple_t): Move earlier.
+ (string_tuple_alloc): Add table param, allocate using table alloc_f.
+ (str_hash_insert): Adjust to suit. Call table->free_f when
+ entry is not used.
+ (hash_string_tuple, eq_string_tuple): Move to..
+ * hash.c: ..here.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: rename md_end to md_finish
+ Currently md_end is typically used for some final actions rather than
+ freeing memory like other *_end functions. Rename it to md_finish,
+ and rename target implementation. The renaming of target functions
+ makes it possible to find them all with "grep md_finish",
+ eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish.
+ This patch leaves a number of md_end functions unchanged, those that
+ either do nothing or deallocate memory, and calls them late.
+
+ The idea here is that target maintainers implement md_end functions to
+ tidy memory, if anyone cares. Freeing persistent memory in gas is
+ not at all important, except that it can hide more important memory
+ leaks, those that happen once per some frequent gas operation, amongst
+ these unimportant memory leaks.
+
+ * as.c (main): Rename md_end to md_finish.
+ * config/tc-alpha.c, * config/tc-alpha.h,
+ * config/tc-arc.c, * config/tc-arc.h,
+ * config/tc-arm.c, * config/tc-arm.h,
+ * config/tc-csky.c, * config/tc-csky.h,
+ * config/tc-ia64.c, * config/tc-ia64.h,
+ * config/tc-mcore.c, * config/tc-mcore.h,
+ * config/tc-mips.c, * config/tc-mips.h,
+ * config/tc-mmix.c, * config/tc-mmix.h,
+ * config/tc-msp430.c, * config/tc-msp430.h,
+ * config/tc-nds32.c, * config/tc-nds32.h,
+ * config/tc-ppc.c, * config/tc-ppc.h,
+ * config/tc-pru.c, * config/tc-pru.h,
+ * config/tc-riscv.c, * config/tc-riscv.h,
+ * config/tc-s390.c, * config/tc-s390.h,
+ * config/tc-sparc.c, * config/tc-sparc.h,
+ * config/tc-tic4x.c, * config/tc-tic4x.h,
+ * config/tc-tic6x.c, * config/tc-tic6x.h,
+ * config/tc-v850.c, * config/tc-v850.h,
+ * config/tc-xtensa.c, * config/tc-xtensa.h,
+ * config/tc-z80.c, * config/tc-z80.h: Similarly.
+ * output-file.c (output_file_close): Call md_end.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: set up notes obstack earlier
+ So that the notes obstack can be used for persistent storage in
+ parse_args.
+
+ * as.c (parse_args): Use notes_alloc and notes_strdup.
+ (free_notes): New function.
+ (main): Init notes obstack, and arrange to be freed on exit.
+ * read.c (read_begin): Don't init notes obstack.
+ (read_end): Free cond_obstack.
+ * subsegs.c (subsegs_end): Don't free cond_obstack or notes.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: itbl_files
+ itbl_files seems to be debug code. Get rid of it.
+
+ * as.c (struct itbl_file_list): Delete.
+ (itbl_files): Delete.
+ (parse_args): Don't keep itbl_files list.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: free sy_hash, macro_hash and po_hash
+ * macro.c (macro_end): New function.
+ * macro.h (macro_end): Declare.
+ * read.c (read_end, poend): New functions.
+ * read.h (read_end): Declare.
+ * symbols.c (symbol_end): New function.
+ * symbols.h (symbol_end): Declare.
+ * output-file.c (output_file_close): Call new *_end functions.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ dw2gencfi.c: use notes obstack
+ Use notes obstack for dwcfi_hash entries, and free table. Freeing the
+ table makes memory checkers complain more about "definitely lost"
+ memory as we've moved some from the "still reachable" category.
+ That will be fixed with a later patch.
+
+ * dw2gencfi.c (get_debugseg_name): Allocate on notes obstack.
+ (alloc_debugseg_item): Likewise.
+ (dwcfi_hash_find_or_make): Adjust failure path free.
+ (cfi_finish): Delete dwfci_hash.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ expr.c make_expr_symbol: use notes obstack
+ * expr.c (make_expr_symbol): Use notes_alloc.
+
+ read.c assign_symbol: use notes obstack for dummy listing frag
+ * read.c (assign_symbol): Use notes_calloc for dummy_frag.
+
+ read.c s_include: use notes obstack for path
+ * read.c (s_include): Use notes obstack for path mem.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ macro.c: use string hash from hash.h for macro_hash
+ Another case of duplicated hash.h code, the only minor difference
+ being that macro->format_hash was created with 7 entries vs. str_hash
+ with 16 entries.
+
+ * macro.c (macro_init, define_macro): Use str_htab_create.
+ (do_formals, define_macro, macro_expand_body): Use str_hash_insert
+ (macro_expand_body): Use str_hash_find and str_hash_delete.
+ (delete_macro): Likewise.
+ (sub_actual, macro_expand, check_macro): Use str_hash_find.
+ (expand_irp): Use str_htab_create and str_hash_insert.
+ * macro.h (struct macro_struct): Tidy.
+ (struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry),
+ (eq_macro_entry, macro_entry_alloc, macro_entry_find),
+ (struct formal_hash_entry, formal_hash_entry_t),
+ (hash_formal_entry, eq_formal_entry, formal_entry_alloc),
+ (formal_entry_find): Delete.
+ * config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create
+ and str_hash_insert.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ read.c: use string hash from hash.h for po_hash
+ po_hash code duplicates the str_hash code in hash.h for no good reason.
+
+ * read.c (struct po_entry, po_entry_t): Delete.
+ (hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete.
+ (pop_insert): Use str_hash_insert.
+ (pobegin): Use str_htab_create.
+ (read_a_source_file, s_macro): Use str_hash_find.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ free read_symbol_name string
+ read_symbol_name mallocs the string it returns. Free it when done.
+
+ * read.c (read_symbol_name): Free name on error path.
+ * config/tc-ppc.c (ppc_GNU_visibility): Free name returned from
+ read_symbol_name.
+ (ppc_extern, ppc_globl, ppc_weak): Likewise.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: output_file_close
+ This is mostly a tidy with the aim of being able to free
+ out_file_name, but it does fix a possible attempt to unlink the output
+ file twice (not that that matters).
+
+ * as.h (keep_it): New global.
+ * as.c (keep_it): Delete.
+ (close_output_file): Delete, merged into..
+ * output-file.c (output_file_close): ..here. Delete parameter.
+ * output-file.h (output_file_close): Update prototype.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: utility notes memory alloc functions
+ Makes it a little easier to use the notes obstack for persistent
+ storage.
+
+ * as.h (gas_mul_overflow): Define.
+ * symbols.h (notes_alloc, notes_calloc, notes_memdup),
+ (notes_strdup, notes_concat, notes_free): Declare.
+ * symbols.c (notes_alloc, notes_calloc, notes_memdup),
+ (notes_strdup, notes_concat, notes_free): New functions.
+ (save_symbol_name): Use notes_strdup.
+ (symbol_create, local_symbol_make, local_symbol_convert),
+ (symbol_clone, decode_local_label_name): Use notes_alloc.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ gas: arm -mwarn-syms duplicates
+ arm gas is only supposed to warn once per symbol for -mwarn-syms, but
+ doesn't because the str_hash_find added with commit 629310abec88
+ always returns NULL. That's so because the str_hash_insert inserts a
+ NULL value for the key,value pair. Let str_hash_insert do the job
+ instead.
+
+ * config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned
+ logic.
+ * testsuite/gas/arm/pr18347.s: Modify to generate duplicate
+ warning without this patch.
+
+2022-07-09 Alan Modra <amodra@gmail.com>
+
+ Regenerate with automake-1.15.1
+ Until we update the recommended versions of autoconf/automake, files
+ should be regenerated with automake-1.15.1 and autoconf-2.69. That's
+ not because we think those versions are golden, and newer versions are
+ bad. It's simply because maintainers want to be able to update
+ configury files without trouble, and if someone regenerates files with
+ automake-1.16.5 then --enable-maintainer-mode builds will hit errors:
+
+ checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1,
+ configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
+ configure.ac:26: comes from Automake 1.16.5. You should recreate
+ configure.ac:26: aclocal.m4 with aclocal and run automake again.
+ WARNING: 'automake-1.15' is probably too old.
+
+ Correcting this requires regenerating the files by hand.
+
+2022-07-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-08 Tom Tromey <tom@tromey.com>
+
+ Accept gdb.Value in more Python APIs
+ PR python/27000 points out that gdb.block_for_pc will accept a Python
+ integer, but not a gdb.Value. This patch corrects this oversight.
+
+ I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
+ get_addr_from_python instead. I also looked at uses of GDB_PY_LL_ARG,
+ but those seemed relatively unlikely to be useful with a gdb.Value, so
+ I didn't change them. My thinking here is that a Value will typically
+ come from inferior memory, and something like a line number is not too
+ likely to be found this way.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000
+
+2022-07-08 Tom Tromey <tom@tromey.com>
+
+ Handle bool specially in gdb.set_parameter
+ PR python/29217 points out that gdb.parameter will return bool values,
+ but gdb.set_parameter will not properly accept them. This patch fixes
+ the problem by adding a special case to set_parameter.
+
+ I looked at a fix involving rewriting set_parameter in C++. However,
+ this one is simpler.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217
+
+2022-07-08 Ludovic Courtès <ludo@gnu.org>
+
+ [gdb/build] Handle deprecation of scm_install_gmp_memory_functions
+ When building gdb with guile 3.0.8, we run into:
+ ...
+ gdb/guile/guile.c: In function \
+ 'void gdbscm_initialize(const extension_language_defn*)':
+ gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \
+ deprecated [-Werror=deprecated-declarations]
+ 680 | scm_install_gmp_memory_functions = 0;
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ In file included from /usr/include/guile/3.0/libguile.h:128,
+ from gdb/guile/guile-internal.h:30,
+ from gdb/guile/guile.c:36:
+ /usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here
+ 164 | SCM_DEPRECATED int scm_install_gmp_memory_functions;
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ cc1plus: all warnings being treated as errors
+ make[1]: *** [Makefile:1896: guile/guile.o] Error 1
+ ...
+
+ The variable has been deprecated because it no longer has any effect.
+
+ Fix this by disabling the specific deprecation warning.
+
+ Also handle upcoming guile versions > 3.0, in which the variable will be
+ removed, by limiting the usage of the variable to guile versions <= 3.0.
+
+ This does not break anything. The variable was merely used to address a
+ problem present in guile versions <= v3.0.5.
+
+ Note that we don't limit the usage of the variable to guile versions <= 3.0.5,
+ because we want to support f.i. building against 3.0.6 and then using a shared
+ lib with 3.0.5.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994
+
+2022-07-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix assert in process_imported_unit_die
+ When running test-case gdb.dwarf2/dw2-symtab-includes.exp with target board
+ cc-with-debug-names, I run into:
+ ...
+ (gdb) maint expand-symtab dw2-symtab-includes.h^M
+ src/gdb/dwarf2/read.h:311: internal-error: unit_type: \
+ Assertion `m_unit_type != 0' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ ----- Backtrace -----^M
+ FAIL: gdb.dwarf2/dw2-symtab-includes.exp: maint expand-symtab \
+ dw2-symtab-includes.h (GDB internal error)
+ ...
+
+ The assert was recently added in commit 2c474c46943 ("[gdb/symtab] Add get/set
+ functions for per_cu->lang/unit_type").
+
+ The assert is triggered here:
+ ...
+ /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
+ into another compilation unit, at root level. Regard this as a hint,
+ and ignore it. */
+ if (die->parent && die->parent->parent == NULL
+ && per_cu->unit_type () == DW_UT_compile
+ && per_cu->lang () == language_cplus)
+ return;
+ ...
+
+ We're trying to access unit_type / lang which hasn't been set yet.
+
+ Normally, these are set during cooked index creation, but that's not the case
+ when using an index (or using -readnow).
+
+ In other words, this lto binary reading speed optimization only works in the
+ normal use case.
+
+ IWBN to have this working in all use cases, but for now, allow lang () and
+ unit_type () to return language_unknown and 0 here.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29321
+
+2022-07-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p
+ When running test-case gdb.cp/cpexprs-debug-types.exp with target board
+ cc-with-debug-names, I run into:
+ ...
+ (gdb) print base::operator new^M
+ ^M
+ ^M
+ Fatal signal: Segmentation fault^M
+ ----- Backtrace -----^M
+ 0x57ea46 gdb_internal_backtrace_1^M
+ /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M
+ 0x57eae9 _Z22gdb_internal_backtracev^M
+ /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M
+ 0x75b8ad handle_fatal_signal^M
+ /home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M
+ 0x75ba19 handle_sigsegv^M
+ /home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M
+ 0x7f795f46a8bf ???^M
+ 0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M
+ /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M
+ ...
+
+ The problem is in this piece of code in dw2_debug_names_iterator::next:
+ ...
+ case DW_IDX_type_unit:
+ /* Don't crash on bad data. */
+ if (ull >= per_bfd->tu_stats.nr_tus)
+ {
+ complaint (_(".debug_names entry has bad TU index %s"
+ " [in module %s]"),
+ pulongest (ull),
+ objfile_name (objfile));
+ continue;
+ }
+ per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus);
+ break;
+ ...
+
+ The all_comp_units vector (which get_cu accesses) contains both CUs and TUs,
+ with CUs first.
+
+ So to get the nth TU we need the element at "nr_cus + n", but
+ the code uses "nr_tus + n" instead.
+
+ Fix this by using "nr_cus + n".
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29334
+
+2022-07-08 Enze Li <enze.li@hotmail.com>
+
+ gdb: initialize the data_head variable to eliminate compilation warnings
+ On a machine with gcc 12, I get this warning:
+
+ CXX nat/linux-btrace.o
+ In function ‘btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’,
+ inlined from ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29:
+ ../gdb/nat/linux-btrace.c:865:21: warning: ‘data_head’ may be used uninitialized [-Wmaybe-uninitialized]
+ 865 | pevent->last_head = data_head;
+ | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
+ ../gdb/nat/linux-btrace.c: In function ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’:
+ ../gdb/nat/linux-btrace.c:792:9: note: ‘data_head’ was declared here
+ 792 | __u64 data_head, data_tail;
+ | ^~~~~~~~~
+
+ Fix this by initializing the 'data_head' variable.
+
+ Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12.
+
+2022-07-08 Andrew Burgess <aburgess@redhat.com>
+
+ libopcodes/s390: add support for disassembler styling
+ This commit adds disassembler style to the libopcodes s390
+ disassembler. This conversion was pretty straight forward, I just
+ converted the fprintf_func calls to fprintf_styled_func calls and
+ added an appropriate style.
+
+ For testing the new styling I just assembled then disassembled the
+ source files in gas/testsuite/gas/s390 and manually checked that the
+ styling looked reasonable.
+
+ If the user does not request styled output from objdump, then there
+ should be no change in the disassembler output after this commit.
+
+2022-07-08 Nick Clifton <nickc@redhat.com>
+
+ Fix regeneration of ld configure and makefiles
+
+ Update release README with new version numbers
+
+ Update version to 2.39.50 and regenerate files
+
+ Add markers for 2.39 branch
+
+2022-07-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix regression in testing for not yet installed version
+ gprofng/ChangeLog
+ 2022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/Settings.cc (Settings::read_rc): Read environment variable
+ GPROFNG_SYSCONFDIR.
+ * testsuite/lib/Makefile.skel: Export GPROFNG_SYSCONFDIR.
+ * testsuite/gprofng.display/display.exp: Shorten the list of tests.
+
+2022-07-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid
+ Trying to run a simple program (empty main) on AIX, I get:
+
+ (gdb) run
+ Starting program: /scratch/simark/build/gdb/a.out
+ Child process unexpectedly missing: There are no child processes..
+ ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x10ef12a8 gdb_internal_backtrace_1()
+ ../../src/binutils-gdb/gdb/bt-utils.c:122
+ 0x10ef1470 gdb_internal_backtrace()
+ ../../src/binutils-gdb/gdb/bt-utils.c:168
+ 0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*)
+ ../../src/binutils-gdb/gdb/utils.c:396
+ 0x1004d8a8 internal_verror(char const*, int, char const*, char*)
+ ../../src/binutils-gdb/gdb/utils.c:476
+ 0x1004c424 internal_error(char const*, int, char const*, ...)
+ ../../src/binutils-gdb/gdbsupport/errors.cc:55
+ 0x102ab344 find_inferior_pid(process_stratum_target*, int)
+ ../../src/binutils-gdb/gdb/inferior.c:304
+ 0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t)
+ ../../src/binutils-gdb/gdb/inferior.c:318
+ 0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t)
+ ../../src/binutils-gdb/gdb/thread.c:519
+ 0x10319e98 handle_inferior_event(execution_control_state*)
+ ../../src/binutils-gdb/gdb/infrun.c:5532
+ 0x10315544 fetch_inferior_event()
+ ../../src/binutils-gdb/gdb/infrun.c:4221
+ 0x10952e34 inferior_event_handler(inferior_event_type)
+ ../../src/binutils-gdb/gdb/inf-loop.c:41
+ 0x1032640c infrun_async_inferior_event_handler(void*)
+ ../../src/binutils-gdb/gdb/infrun.c:9548
+ 0x10673188 check_async_event_handlers()
+ ../../src/binutils-gdb/gdb/async-event.c:335
+ 0x1066fce4 gdb_do_one_event()
+ ../../src/binutils-gdb/gdbsupport/event-loop.cc:214
+ 0x10001a94 start_event_loop()
+ ../../src/binutils-gdb/gdb/main.c:411
+ 0x10001ca0 captured_command_loop()
+ ../../src/binutils-gdb/gdb/main.c:471
+ 0x10003d74 captured_main(void*)
+ ../../src/binutils-gdb/gdb/main.c:1329
+ 0x10003e48 gdb_main(captured_main_args*)
+ ../../src/binutils-gdb/gdb/main.c:1344
+ 0x10000744 main
+ ../../src/binutils-gdb/gdb/gdb.c:32
+ ---------------------
+ ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n)
+
+ This is due to some bit-rot in the AIX port, still relying on the entry
+ value of inferior_ptid in the wait methods.
+
+ Problem #1 is in rs6000_nat_target::wait, here:
+
+ /* Ignore terminated detached child processes. */
+ if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
+ pid = -1;
+
+ At this point, waitpid has returned an "exited" status for some pid, so
+ pid is non-zero. Since inferior_ptid is set to null_ptid on entry, the
+ pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset
+ pid to -1 and go to waiting again. Since there are not more children to
+ wait for, waitpid then returns -1 so we get here:
+
+ if (pid == -1)
+ {
+ gdb_printf (gdb_stderr,
+ _("Child process unexpectedly missing: %s.\n"),
+ safe_strerror (save_errno));
+
+ /* Claim it exited with unknown signal. */
+ ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
+ return inferior_ptid;
+ }
+
+ We therefore return a "signalled" status with a null_ptid (again,
+ inferior_ptid is null_ptid). This confuses infrun, because if the
+ target returns a "signalled" status, it should be coupled with a ptid
+ for an inferior that exists.
+
+ So, the first step is to fix the snippets above to not use
+ inferior_ptid. In the first snippet, use find_inferior_pid to see if
+ we know the event process. If there is no inferior with that pid, we
+ assume it's a detached child process to we ignore the event. That
+ should be enough to fix the problem, because it should make it so we
+ won't go into the second snippet. But still, fix the second snippet to
+ return an "ignore" status. This is copied from inf_ptrace_target::wait,
+ which is where rs6000_nat_target::wait appears to be copied from in the
+ first place.
+
+ These changes, are not sufficient, as the aix_thread_target, which sits
+ on top of rs6000_nat_target, also relies on inferior_ptid.
+ aix_thread_target::wait, by calling pd_update, assumes that
+ rs6000_nat_target has set inferior_ptid to the appropriate value (the
+ ptid of the event thread), but that's not the case. pd_update
+ returns inferior_ptid - null_ptid - and therefore
+ aix_thread_target::wait returns null_ptid too, and we still hit the
+ assert shown above.
+
+ Fix this by changing pd_activate, pd_update, sync_threadlists and
+ get_signaled_thread to all avoid using inferior_ptid. Instead, they
+ accept as a parameter the pid of the process we are working on.
+
+ With this patch, I am able to run the program to completion:
+
+ (gdb) r
+ Starting program: /scratch/simark/build/gdb/a.out
+ [Inferior 1 (process 11010794) exited normally]
+
+ As well as break on main:
+
+ (gdb) b main
+ Breakpoint 1 at 0x1000036c
+ (gdb) r
+ Starting program: /scratch/simark/build/gdb/a.out
+
+ Breakpoint 1, 0x1000036c in main ()
+ (gdb) c
+ Continuing.
+ [Inferior 1 (process 26083688) exited normally]
+
+ Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9
+
+2022-07-07 Pedro Alves <pedro@palves.net>
+
+ Fix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp
+ The DWARF spec says:
+
+ Any debugging information entry representing the declaration of an object,
+ module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
+ DW_AT_decl_column attributes, each of whose value is an unsigned integer
+ ^^^^^^^^
+ constant.
+
+ Grepping around the DWARF-assembler-based testcases, I noticed that
+ gdb.trace/unavailable-dwarf-piece.exp emits decl_line with
+ DW_FORM_sdata, a signed integer form. This commit tweaks it to use
+ DW_FORM_udata instead.
+
+ Unsurprisingly, this:
+
+ $ make check \
+ TESTS="gdb.trace/unavailable-dwarf-piece.exp" \
+ RUNTESTFLAGS="--target_board=native-gdbserver"
+
+ ... still passes cleanly for me after this change.
+
+ I've noticed this because current llvm-dwarfdump crashed on an
+ ROCm-internal DWARF-assembler-based testcase that incorrectly used
+ signed forms for DW_AT_decl_file/DW_AT_decl_line.
+
+ The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the
+ line numbers with signed forms as "0" instead of crashing. Here's the
+ before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that
+ llvm-dwarfdump version:
+
+ $ diff -up before.txt after.txt
+ --- before.txt 2022-07-07 13:21:28.387690334 +0100
+ +++ after.txt 2022-07-07 13:21:39.379801092 +0100
+ @@ -18,7 +18,7 @@
+ DW_AT_name ("s")
+ DW_AT_byte_size (3)
+ DW_AT_decl_file (0)
+ - DW_AT_decl_line (0)
+ + DW_AT_decl_line (1)
+
+ 0x0000002f: DW_TAG_member
+ DW_AT_name ("a")
+ @@ -41,7 +41,7 @@
+ DW_AT_name ("t")
+ DW_AT_byte_size (3)
+ DW_AT_decl_file (0)
+ - DW_AT_decl_line (0)
+ + DW_AT_decl_line (1)
+
+ 0x00000054: DW_TAG_member
+ DW_AT_name ("a")
+
+ Change-Id: I5c866946356da421ff944019d0eca2607b2b738f
+
+2022-07-07 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Fix typos in code comments
+ "it’s" should be "it's".
+
+2022-07-07 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Add coverage for `print -elements' command
+ We currently have no coverage for the `print -elements ...' command (or
+ `p -elements ...' in the shortened form), so add a couple of test cases
+ mimicking ones using corresponding `set print elements ...' values.
+
+2022-07-07 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement the push_dummy_call gdbarch method
+ According to "Procedure Calling Convention" in "LoongArch ELF ABI
+ specification" [1], implement the push_dummy_call gdbarch method
+ as clear as possible.
+
+ [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention
+
+2022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Added Zfhmin and Zhinxmin.
+ This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and
+ Zhinx extensions, respectively). In the process supporting Zfhmin and
+ Zhinxmin extension, this commit also changes how instructions are
+ categorized considering Zfhmin, Zhinx and Zhinxmin extensions.
+
+ Detailed changes,
+
+ * From INSN_CLASS_ZFH to INSN_CLASS_ZFHMIN:
+
+ flh, fsh, fmv.x.h and fmv.h.x.
+
+ * From INSN_CLASS_ZFH to INSN_CLASS_ZFH_OR_ZHINX:
+
+ fmv.h.
+
+ * From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFH_OR_ZHINX:
+
+ fneg.h, fabs.h, fsgnj.h, fsgnjn.h, fsgnjx.h,
+ fadd.h, fsub.h, fmul.h, fdiv.h, fsqrt.h, fmin.h, fmax.h,
+ fmadd.h, fnmadd.h, fmsub.h, fnmsub.h,
+ fcvt.w.h, fcvt.wu.h, fcvt.h.w, fcvt.h.wu,
+ fcvt.l.h, fcvt.lu.h, fcvt.h.l, fcvt.h.lu,
+ feq.h, flt.h, fle.h, fgt.h, fge.h,
+ fclass.h.
+
+ * From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFHMIN_OR_ZHINXMIN:
+
+ fcvt.s.h and fcvt.h.s.
+
+ * From INSN_CLASS_D_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_D:
+
+ fcvt.d.h and fcvt.h.d.
+
+ * From INSN_CLASS_Q_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_Q:
+
+ fcvt.q.h and fcvt.h.q.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Change implicit
+ subsets. Zfh->Zicsr is not needed and Zfh->F is replaced with
+ Zfh->Zfhmin and Zfhmin->F. Zhinx->Zicsr is not needed and
+ Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and
+ Zhinxmin->Zfinx.
+ (riscv_supported_std_z_ext): Added zfhmin and zhinxmin.
+ (riscv_multi_subset_supports): Rewrite handling for new
+ instruction classes.
+ (riscv_multi_subset_supports_ext): Updated.
+ (riscv_parse_check_conflicts): Change error message to include
+ zfh and zfhmin extensions.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex
+ error handling test.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise.
+ * testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise.
+ * testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d
+ and refactored.
+ * testsuite/gas/riscv/zhinx.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class): Removed INSN_CLASS_ZFH,
+ INSN_CLASS_D_AND_ZFH_INX and INSN_CLASS_Q_AND_ZFH_INX. Added
+ INSN_CLASS_ZFHMIN, INSN_CLASS_ZFHMIN_OR_ZHINXMIN,
+ INSN_CLASS_ZFHMIN_AND_D and INSN_CLASS_ZFHMIN_AND_Q.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Change instruction classes for
+ Zfh and Zfhmin instructions. Fix `fcvt.h.lu' instruction
+ (two operand variant) mask.
+
+2022-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: adjust GPROFNG_VARIANT
+ GPROFNG_VARIANT depends on compiler options, not on $(host).
+
+ gprofng/ChangeLog
+ 2022-07-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29116
+ * libcollector/configure.ac: Adjust GPROFNG_VARIANT.
+ * libcollector/configure: Rebuild.
+
+2022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix disassembling Zfinx with -M numeric
+ This commit fixes floating point operand register names from ABI ones
+ to dynamically set ones.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zfinx-dis-numeric.s: Test new behavior of
+ Zfinx extension and -M numeric disassembler option.
+ * testsuite/gas/riscv/zfinx-dis-numeric.d: Likewise.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_insn): Use dynamically set GPR
+ names to disassemble Zfinx instructions.
+
+2022-07-07 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix requirement handling on Zhinx+{D,Q}
+ This commit fixes how instructions are masked on Zhinx+Z{d,q}inx.
+ fcvt.h.d and fcvt.d.h require ((D&&Zfh)||(Zdinx&&Zhinx)) and
+ fcvt.h.q and fcvt.q.h require ((Q&&Zfh)||(Zqinx&&Zhinx)).
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Fix feature gate
+ on INSN_CLASS_{D,Q}_AND_ZFH_INX.
+ (riscv_multi_subset_supports_ext): Fix feature gate diagnostics
+ on INSN_CLASS_{D,Q}_AND_ZFH_INX.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/fp-zhinx-insns.d: Add Zqinx to -march
+ for proper testing.
+
+2022-07-07 Alan Modra <amodra@gmail.com>
+
+ PR29320, 'struct obstack' declared inside parameter list
+ PR 29320
+ * frags.h: Move declaration of struct obstack..
+ * as.h: ..to here.
+
+2022-07-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-06 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ gprofng: implement a functional gp-display-html
+ This patch enables the first support for the "gprofng display html" command.
+ This command works for C/C++ applications on x86_64. Using one or more gprofng
+ experiment directories as input, a new directory with html files is created.
+ Through the index.html file in this directory, the performance results may be
+ viewed in a browser.
+
+ gprofng/Changelog:
+ 2022-06-28 Ruud van der Pas <ruud.vanderpas@oracle.com>
+
+ * gp-display-html/gp-display-html.in: implement first support for x86_64 and C/C++
+
+2022-07-06 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Copy p_align of PT_GNU_STACK for stack alignment
+ commit 74e315dbfe5200c473b226e937935fb8ce391489
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Mon Dec 13 19:46:04 2021 -0800
+
+ elf: Set p_align to the minimum page size if possible
+
+ may ignore p_align of PT_GNU_STACK when copying ELF program header if
+ the maximum page size is larger than p_align of PT_LOAD segments. Copy
+ p_align of PT_GNU_STACK since p_align of PT_GNU_STACK describes stack
+ alignment, not page size,
+
+ PR binutils/29319
+ * elf.c (copy_elf_program_header): Copy p_align of PT_GNU_STACK
+ for stack alignment.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: make D attribute usable for XOP and FMA4 insns
+ This once again allows to reduce redundancy in (and size of) the opcode
+ table.
+
+ Don't go as far as also making D work on the two 5-operand XOP insns:
+ This would significantly complicate the code, as there the first
+ (immediate) operand would need special treatment in several places.
+
+ Note that the .s suffix isn't being enabled to have any effect, for
+ being deprecated. Whereas neither {load} nor {store} pseudo prefixes
+ make sense here, as the respective operands are inputs (loads) only
+ anyway, regardless of order. Hence there is (as before) no way for the
+ programmer to request the alternative encoding to be used for register-
+ only insns.
+
+ Note further that it is always the first original template which is
+ retained (and altered), to make sure the same encoding as before is
+ used for register-only insns. This has the slightly odd (but pre-
+ existing) effect of XOP register-only insns having XOP.W clear, but FMA4
+ ones having VEX.W set.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold two switch() statements in match_template()
+ I don't see why two of them were introduced (very long ago) using
+ similar fall-through logic.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: fix 3-operand insn reverse-matching
+ The middle operand would have gone entirely unchecked, allowing e.g.
+
+ vmovss %xmm0, %esp, %xmm2
+
+ to assemble successfully, or e.g.
+
+ vmovss %xmm0, $4, %xmm2
+
+ causing an internal error. Alongside dealing with this also drop a
+ related comment, which hasn't been applicable anymore since the
+ introduction of 3-operand patterns with D set (and which perhaps never
+ had been logical to be there, as reverse-matched insns don't make it
+ there in the first place).
+
+2022-07-06 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ Descriptive DWARF operations dump support for DW_AT_rank
+ DW_AT_rank is a dwarf-5 feature.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: introduce a state stack for .arch
+ When using just slightly non-trivial combinations of .arch, it can be
+ quite useful to be able to go back to prior state without needing to
+ re-invoke perhaps many earlier directives and without needing to invoke
+ perhaps many "negative" ones. Like some other architectures allow
+ saving (pushing) and restoring (popping) present/prior state.
+
+ For now require the same .code<N> to be in effect for ".arch pop" that
+ was in effect for the corresponding ".arch push".
+
+ Also change the global "no_cond_jump_promotion" to be bool, to match the
+ new struct field.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: generalize disabling of sub-architectures
+ I never really understood upon what basis ".arch .no*" options were made
+ available. Let's not have any "criteria" at all, and simply allow
+ disabling of all of them. Then we also have all data for a sub-arch in
+ a single place, as we now only need a single table.
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: permit "default" with .arch
+ So far there was no way to reset the architecture to that assembly would
+ start with in the absence of any overrides (command line or directives).
+ Note that for Intel MCU "default" is merely an alias of "iamcu".
+
+ While there also zap a stray @item from the doc section, as noticed
+ when inspecting the generated output (which still has some quirks, but
+ those aren't easy to address without re-flowing almost the entire
+ section).
+
+2022-07-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't leak sub-architecture accumulated strings
+ While it may not be necessary in i386_target_format() (but then setting
+ the variable to NULL also wouldn't be necessary), at least in the other
+ cases strings may already have accumulated.
+
+2022-07-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/exp] Fix internal error when printing C++ pointer-to-member
+ When running the test-case included with this patch, we run into:
+ ...
+ (gdb) print ptm^M
+ $1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
+ Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
+ ...
+ while printing a c++ pointer-to-member.
+
+ Fix this by skipping static fields in cp_find_class_member, such that we have:
+ ...
+ (gdb) print ptm^M
+ $1 = &A::i^M
+ ...
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294
+
+2022-07-05 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.Objfile.is_file attribute
+ Sometimes an objfile comes from memory and not from a file. It can be
+ useful to be able to check this from Python, so this patch adds a new
+ "is_file" attribute.
+
+2022-07-05 Tom Tromey <tromey@adacore.com>
+
+ Make 'import gdb.events' work
+ Pierre-Marie noticed that, while gdb.events is a Python module, it
+ can't be imported. This patch changes how this module is created, so
+ that it can be imported, while also ensuring that the module is always
+ visible, just as it was in the past.
+
+ This new approach required one non-obvious change -- when running
+ gdb.base/warning.exp, where --data-directory is intentionally not
+ found, the event registries can now be nullptr. Consequently, this
+ patch probably also requires
+
+ https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html
+
+ Note that this patch obsoletes
+
+ https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html
+
+2022-07-05 Xi Ruoyao <xry111@xry111.site>
+
+ gdb: LoongArch: add orig_a0 into register set
+ The basic support for LoongArch has been merged into the upstream Linux
+ kernel since 5.19-rc1 on June 5, 2022. This commit adds orig_a0 which
+ is added into struct user_pt_regs [1] to match the upstream kernel, and
+ then the upstream GDB will work with the upstream kernel.
+
+ Note that orig_a0 was added into struct user_pt_regs in the development
+ cycle for merging LoongArch port into the upstream Linux kernel, so
+ earlier kernels (notably, the product kernel with version 4.19 used in
+ distros like UOS and Loongnix) don't have it. Inspect
+ arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
+ To build upstream GDB for a kernel lacking orig_a0, it's necessary to
+ revert this commit locally.
+
+ [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24
+
+2022-07-05 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ Support for location and range lists for split-dwarf and dwarf-5.
+ Adding support for location and range lists for split-dwarf and dwarf-5.
+ Following issues are taken care.
+ 1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx.
+ 2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections.
+
+ * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx
+ and DW_FORM_rnglistx for .dwo files.
+ (process_debug_info): Load .debug_loclists.dwo and
+ .debug_rnglists.dwo if exists.
+ (load_separate_debug_files): Load .debug_loclists and
+ .debug_rnglists if exists.
+ Include 2 entries in debug_displays table.
+ * dwarf.h (enum dwarf_section_display_enum): Include 2 entries.
+
+2022-07-05 Jan Beulich <jbeulich@suse.com>
+
+ x86: introduce fake processor type to mark sub-arch entries in cpu_arch[]
+ This is in preparation of dropping the leading . from the strings.
+
+ While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD
+ entries to near the top.
+
+2022-07-05 Jan Beulich <jbeulich@suse.com>
+
+ x86: macro-ize cpu_arch[] entries
+ Putting individual elements behind macros, besides (imo) improving
+ readability, will make subsequent (and likely also future) changes less
+ intrusive.
+
+ Utilize this right away to pack the table a little more tightly, by
+ converting "skip" to bool and putting it earlier in a group of bitfields
+ together with "len".
+
+2022-07-05 Jan Beulich <jbeulich@suse.com>
+
+ x86: de-duplicate sub-architecture strings accumulation
+ Introduce a helper function to replace 4 instances of similar code. Use
+ reconcat() to cover the previously explicit free().
+
+2022-07-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-04 Nick Clifton <nickc@redhat.com>
+
+ Fix snafu in rust demangler recursion limit code
+
+2022-07-04 Alan Modra <amodra@gmail.com>
+
+ alloc gas seginfo on notes obstack
+ Lots of memory used in gas should go on this obstack. The patch also
+ frees all the gas obstacks on exit, which isn't a completely trivial
+ task.
+
+ * subsegs.c (alloc_seginfo): New function.
+ (subseg_change, subseg_get): Use it.
+ (subsegs_end): New function.
+ * as.h (subsegs_end): Declare.
+ * output-file.c: Include subsegs.h
+ (stash_frchain_obs): New function.
+ (output_file_close): Save obstacks attached to output bfd before
+ closing. Call subsegs_end with the array of obstacks.
+
+2022-07-04 Alan Modra <amodra@gmail.com>
+
+ objcopy: bfd_alloc orelocation
+ This fixes an inconsequential objcopy memory leak. I'd normally
+ ignore reports of leaks like this one, that are merely one block or
+ fewer per section processed, since objcopy soon exits and frees all
+ memory. However I thought it worth providing support for allocating
+ memory on a bfd objalloc in objcopy and other utils.
+
+ PR 29233
+ * bucomm.c (bfd_xalloc): New function.
+ * bucomm.h (bfd_xalloc): Declare.
+ * objcopy.c (copy_relocations_in_section): Use it to allocate
+ array of reloc pointers. Rewrite code stripping relocs to do
+ without extra memory allocation.
+
+2022-07-04 Nick Clifton <nickc@redhat.com>
+
+ Synchronize libbierty sources with gcc.
+
+2022-07-04 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ Modified changes for split-dwarf and dwarf-5.
+ * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit.
+ (display_debug_str_offsets): While dumping .debug_str_offsets.dwo,
+ pass proper str_offsets_base to fetch_indexed_string().
+ (load_separate_debug_files): Skip DWO ID dump for dwarf-5.
+
+2022-07-04 Marcus Nilsson <brainbomb@gmail.com>
+
+ opcodes/avr: Implement style support in the disassembler
+ * disassemble.c: (disassemble_init_for_target): Set
+ created_styled_output for AVR based targets.
+ * avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype
+ instead of fprintf_ftype throughout.
+ (avr_operand): Pass in and fill disassembler_style when
+ parsing operands.
+
+2022-07-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add get/set functions for per_cu->lang/unit_type
+ The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
+ initial value (respectively language_unknown and (dwarf_unit_type)0), which
+ allows us to add certain checks, f.i. checking that that a field is not read
+ before written.
+
+ Add get/set member functions for the two fields as a convenient location to
+ add such checks, make the fields private to enforce using the member
+ functions, and add the m_ prefix.
+
+ Tested on x86_64-linux.
+
+2022-07-04 Jan Beulich <jbeulich@suse.com>
+
+ gas/testsuite: properly exclude aout in all/weakref1u
+ Use the (wider) predicate rather than a triplet. This eliminates the sole
+ i386-msdos failure in the testsuite.
+
+2022-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: fold Disp32S and Disp32
+ The only case where 64-bit code uses non-sign-extended (can also be
+ considered zero-extended) displacements is when an address size override
+ is in place for a memory operand (i.e. particularly excluding
+ displacements of direct branches, which - if at all - are controlled by
+ operand size, and then are still sign-extended, just from 16 bits).
+ Hence the distinction in templates is unnecessary, allowing code to be
+ simplified in a number of places. The only place where logic becomes
+ more complicated is when signed-ness of relocations is determined in
+ output_disp().
+
+ The other caveat is that Disp64 cannot be specified anymore in an insn
+ template at the same time as Disp32. Unlike for non-64-bit mode,
+ templates don't specify displacements for both possible addressing
+ modes; the necessary adjustment to the expected ones has already been
+ done in match_template() anyway (but of course the logic there needs
+ tweaking now). Hence the single template so far doing so is split.
+
+2022-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: restore masking of displacement kinds
+ Commit 7d5e4556a375 rendered the check near the end of what is now
+ i386_finalize_displacement() entirely dead for AT&T mode, since for
+ operands involving a displacement .unspecified will always be set. But
+ the logic there is bogus anyway - Intel syntax operand size specifiers
+ are of no interest there either. The only thing which matters in the
+ "displacement only" determination is .baseindex.
+
+ Of course when masking displacement kinds we should not at the same time
+ also mask off other attributes.
+
+ Furthermore the type mask returned by lex_got() also needs to be
+ adjusted: The only case where we want Disp32 (rather than Disp32S) is
+ when dealing with 32-bit addressing mode in 64-bit code.
+
+2022-07-04 Jan Beulich <jbeulich@suse.com>
+
+ x86-64: improve handling of branches to absolute addresses
+ There are two related problems here: The use of "addr32" on a direct
+ branch would, besides causing a warning, result in operands to be
+ permitted which mistakenly are refused without "addr32". Plus at some
+ point not too long ago I'm afraid it may have been me who regressed the
+ relocation addends emitted for such branches. Correct both problems,
+ adding a testcase to guard against regressing this again.
+
+2022-07-04 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Update Zihintpause extension version
+ Because ratified Zihintpause extension has a version number of 2.0
+ (not 1.0), we should update the number.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Update version
+ number of Zihintpause extension.
+
+2022-07-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix data race on per_cu->dwarf_version
+ When building gdb with -fsanitize=thread and gcc 12, and running test-case
+ gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
+ thread in the same write:
+ ...
+ Write of size 1 at 0x7b200000300c:^M
+ #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
+ (gdb+0x82f3b3)^M
+ ...
+ which is here:
+ ...
+ this_cu->dwarf_version = cu->header.version;
+ ...
+
+ Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
+ this one directly:
+ ...
+ #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
+ #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
+ #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
+ ...
+ and this via the PU import:
+ ...
+ #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
+ sect_offset, bool, bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
+ #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
+ abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
+ #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
+ cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
+ #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
+ (gdb+0x85e68a)^M
+ #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
+ #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
+ #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
+ ...
+
+ Fix this by setting the field earlier, in read_comp_units_from_section.
+
+ The write in cutu_reader::cutu_reader() is still needed, in case
+ read_comp_units_from_section is not used (run the test-case with say, target
+ board cc-with-gdb-index).
+
+ Make the write conditional, such that it doesn't trigger if the field is
+ already set by read_comp_units_from_section. Instead, verify that the
+ field already has the value that we're trying to set it to.
+
+ Move this logic into into a member function set_version (in analogy to the
+ already present member function version) to make sure it's used consistenly,
+ and make the field private in order to enforce access through the member
+ functions, and rename it to m_dwarf_version.
+
+ While we're at it, make sure that the version is set before read, to avoid
+ say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".
+
+ Tested on x86_64-linux.
+
+2022-07-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread
+ When building gdb with -fsanitize=thread, I run into:
+ ...
+ FAIL: gdb.base/early-init-file.exp: check startup version string has style \
+ version
+ ...
+ due to this:
+ ...
+ warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
+ warning: Found custom handler for signal 8 (Floating point exception) \
+ preinstalled.^M
+ warning: Found custom handler for signal 11 (Segmentation fault) \
+ preinstalled.^M
+ Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
+ won't be propagated to spawned programs.^M
+ ...
+ appearing before the "GNU gdb (GDB) $version" line.
+
+ This is similar to the problem fixed by commit f0bbba7886f
+ ("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
+ AddressSanitizer").
+
+ In that commit, the problem was fixed by starting gdb with -quiet, but using
+ that would mean the "GNU gdb (GDB) $version" line that we're trying to check
+ would disappear.
+
+ Fix this instead by updating the regexp to allow the message.
+
+ Tested on x86_64-linux.
+
+2022-07-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-07-01 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/doc: Remove indentation from `print -elements' completion example
+ Remove indentation from the text of the manual after the example here:
+
+ " Completion will in some cases guide you with a suggestion of what
+ kind of argument an option expects. For example:
+
+ (gdb) print -elements <TAB><TAB>
+ NUMBER unlimited
+
+ Here, the option expects a number (e.g., '100'), not literal
+ 'NUMBER'. Such metasyntactical arguments are always presented in
+ uppercase."
+
+ as this is a continuation of the same paragraph.
+
+2022-07-01 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/doc: Remove extraneous spaces from completion examples
+ Completion results are usually different when the operation is applied
+ to a word that is or is not followed by a space. In some cases they are
+ equivalent, however a space would not be produced if completion was used
+ earlier on in the word processed.
+
+ However in the manual we have completion examples given using a space
+ that actually prevents the example from working. E.g.:
+
+ (gdb) info bre <TAB>
+
+ (nothing) and:
+
+ (gdb) info bre <TAB><TAB>
+ Display all 200 possibilities? (y or n)
+
+ as it now goes on to propose the entire symbol table, while:
+
+ (gdb) info bre<TAB>
+ (gdb) info breakpoints
+
+ does the right thing, but is not what is shown in the manual.
+
+ In other cases an extraneous space is used that does not correspond to
+ the actual completion pattern shown, which gives an impression of
+ sloppiness.
+
+ Remove extraneous spaces then from completion examples as appropriate.
+
+2022-07-01 Nick Clifton <nickc@redhat.com>
+
+ Add newline to the end of the rnglists displsy.
+
+2022-07-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-30 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Add `NUMBER' completion to `set' integer commands
+ Fix a completion consistency issue with `set' commands accepting integer
+ values and the special `unlimited' keyword:
+
+ (gdb) complete print -elements
+ print -elements NUMBER
+ print -elements unlimited
+ (gdb)
+
+ vs:
+
+ (gdb) complete set print elements
+ set print elements unlimited
+ (gdb)
+
+ (there is a space entered at the end of both commands, not shown here)
+ which also means if you strike <Tab> with `set print elements ' input,
+ it will, annoyingly, complete to `set print elements unlimited' right
+ away rather than showing a choice between `NUMBER' and `unlimited'.
+
+ Add `NUMBER' then as an available completion for such `set' commands:
+
+ (gdb) complete set print elements
+ set print elements NUMBER
+ set print elements unlimited
+ (gdb)
+
+ Adjust the testsuite accordingly. Also document the feature in the
+ Completion section of the manual in addition to the Command Options
+ section already there.
+
+2022-06-30 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: Expand gdb.cp/mb-ctor.exp to test dynamic allocation
+ When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
+ only tested objects allocated on the stack. This commit adds a couple of
+ dynamic allocations and tests if GDB can stop in it as well.
+
+2022-06-30 Nick Clifton <nickc@redhat.com>
+
+ Fix implementation of readelf's -wE and -wN options,
+ * dwarf.c (dwarf_select_sections_by_name): If the entry's value is
+ zero then clear the corresponding variable.
+ (dwarf_select_sections_by_letters): Likewise.
+ * testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
+ debuginfod tests to fail.
+
+2022-06-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Block SIGTERM in worker threads
+ With gdb build with gcc-12 and -fsanitize=thread, and test-case
+ gdb.base/gdb-sigterm.exp, I run into:
+ ...
+ WARNING: ThreadSanitizer: data race (pid=9722)^M
+ Write of size 4 at 0x00000325bc68 by thread T1:^M
+ #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
+ ...
+ Previous read of size 4 at 0x00000325bc68 by main thread:^M
+ [failed to restore the stack]^M
+ ^M
+ Location is global 'sync_quit_force_run' of size 4 at \
+ 0x00000325bc68 (gdb+0x325bc68)^M
+ ...
+ SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
+ handle_sigterm(int)^M
+ ...
+ and 3 more data races involving handle_sigterm and locations:
+ - active_ext_lang
+ - quit_flag
+ - heap block of size 40
+ (XNEW (async_signal_handler) in create_async_signal_handler)
+
+ This was reported in PR29297.
+
+ The testcase executes a "kill -TERM $gdb_pid", which generates a
+ process-directed signal.
+
+ A process-directed signal can be delivered to any thread, and what we see
+ here is the fallout of the signal being delivered to a worker thread rather
+ than the main thread.
+
+ Fix this by blocking SIGTERM in the worker threads.
+
+ [ I have not been able to reproduce this after it occurred for the first time,
+ so unfortunately I cannot confirm that the patch fixes the problem. ]
+
+ Tested on x86_64-linux, with and without -fsanitize=thread.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297
+
+2022-06-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: fix column widths in MI compatibility table
+ In passing I noticed that the column headings for the table of MI
+ compatibility and breaking changes, were overlapping, at least when
+ the PDF is generated on my machine.
+
+ I propose giving slightly more space to the two version number
+ columns, this prevents the headers overlapping for me.
+
+2022-06-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-29 Pedro Alves <pedro@palves.net>
+
+ Fix GDBserver regression due to change to avoid reading shell registers
+ Simon reported that the recent change to make GDB and GDBserver avoid
+ reading shell registers caused a GDBserver regression, caught with
+ ASan while running gdb.server/non-existing-program.exp:
+
+ $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
+ =================================================================
+ ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
+ WRITE of size 1 at 0x60f0000000e9 thread T0
+ #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
+ #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
+ #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
+ #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+ #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+ #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+ #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)
+
+ 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
+ freed by thread T0 here:
+ #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
+ #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
+ #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
+ #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
+ #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
+ #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
+ #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
+ #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
+ #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+ #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+ #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+
+ previously allocated by thread T0 here:
+ #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
+ #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
+ #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
+ #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
+ #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+ #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+ #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+
+ Above we see that in the non-existing-program case, the process gets
+ deleted before the starting_up flag gets restored to false.
+
+ This happens because startup_inferior calls target_mourn_inferior
+ before throwing an error, and in GDBserver, unlike in GDB, mourning
+ deletes the process.
+
+ Fix this by not using a scoped_restore to manage the starting_up flag,
+ since we should only clear it when startup_inferior doesn't throw.
+
+ Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c
+
+2022-06-29 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Tighten `set print elements' error check
+ Match the whole error message expected to be given rather than omitting
+ the part about the "unlimited" keyword. There's no point in omitting
+ the missing part first, and second with an upcoming change the part in
+ parentheses will no longer be a fixed string, so doing a full match will
+ ensure the algorithm correctly builds the message expected here. Also
+ avoid any wildcard matches.
+
+2022-06-29 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB: Remove extraneous full stops from `set' command error messages
+ With errors given for bad commands such as `set annotate' or `set width'
+ we produce an extraneous full stop within parentheses:
+
+ (gdb) set annotate
+ Argument required (integer to set it to.).
+ (gdb) set width
+ Argument required (integer to set it to, or "unlimited".).
+ (gdb)
+
+ This is grammatically incorrect, so remove the full stop and adjust the
+ testsuite accordingly.
+
+2022-06-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: improve description of --data-disassemble opcodes output
+ Extend the description of the MI command --data-disassemble.
+ Specifically, expand the description of the 'opcodes' field to explain
+ how the bytes are formatted.
+
+2022-06-29 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Only stack S16..S31 when FPU registers are secure
+ The FPCCR.TS bit is used to identify if FPU registers are considered
+ non-secure or secure. If they are secure, then callee saved registers
+ (S16 to S31) are stacked on exception entry or otherwise skipped.
+
+2022-06-29 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/aarch64: split off creation of comment text in disassembler
+ The function aarch64_print_operand (aarch64-opc.c) is responsible for
+ converting an instruction operand into the textual representation of
+ that operand.
+
+ In some cases, a comment is included in the operand representation,
+ though this (currently) only happens for the last operand of the
+ instruction.
+
+ In a future commit I would like to enable the new libopcodes styling
+ for AArch64, this will allow objdump and GDB[1] to syntax highlight
+ the disassembler output, however, having operands and comments
+ combined in a single string like this makes such styling harder.
+
+ In this commit, I propose to extend aarch64_print_operand to take a
+ second buffer. Any comments for the instruction are written into this
+ extra buffer. The two callers of aarch64_print_operand are then
+ updated to pass an extra buffer, and print any resulting comment.
+
+ In this commit no styling is added, that will come later. However, I
+ have adjusted the output slightly. Before this commit some comments
+ would be separated from the instruction operands with a tab character,
+ while in other cases the comment was separated with two single spaces.
+
+ After this commit I use a single tab character in all cases. This
+ means a few test cases needed updated. If people would prefer me to
+ move everyone to use the two spaces, then just let me know. Or maybe
+ there was a good reason why we used a mix of styles, I could probably
+ figure out a way to maintain the old output exactly if that is
+ critical.
+
+ Other than that, there should be no user visible changes after this
+ commit.
+
+ [1] GDB patches have not been merged yet, but have been posted to the
+ GDB mailing list:
+ https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html
+
+2022-06-29 Carl Love <cel@us.ibm.com>
+ Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc
+ When running the gdb.base/break-idempotent.exp test on ppc, I was
+ seeing some test failures (or rather errors), that looked like this:
+
+ (gdb) watch local
+ Hardware watchpoint 2: local
+
+ has_hw_wp_support: Hardware watchpoint detected
+ ERROR: no fileid for gcc2-power8
+ ERROR: Couldn't send delete breakpoints to GDB.
+ ERROR OCCURED: can't read "gdb_spawn_id": no such variable
+ while executing
+ "expect {
+ -i 1000 -timeout 100
+ -re ".*A problem internal to GDB has been detected" {
+ fail "$message (GDB internal error)"
+ gdb_internal_erro..."
+ ("uplevel" body line 1)
+ invoked from within
+
+ What happens is that in break-idempotent.exp we basically do this:
+
+ if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
+ continue
+ }
+
+ # ....
+
+ if {![skip_hw_watchpoint_tests]} {
+ test_break $always_inserted "watch"
+ }
+
+ The problem with this is that skip_hw_watchpoint_tests, includes this:
+
+ if { [istarget "i?86-*-*"]
+ || [istarget "x86_64-*-*"]
+ || [istarget "ia64-*-*"]
+ || [istarget "arm*-*-*"]
+ || [istarget "aarch64*-*-*"]
+ || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
+ || [istarget "s390*-*-*"] } {
+ return 0
+ }
+
+ For powerpc only we call has_hw_wp_support. This is a caching proc
+ that runs a test within GDB to detect if we have hardware watchpoint
+ support or not.
+
+ Unfortunately, to run this test we restart GDB, and when the test has
+ completed, we exit GDB. This means that in break-idempotent.exp, when
+ we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
+ will unexpectedly be exited. When we later call delete_breakpoints we
+ see the errors I reported above.
+
+ The fix is to call skip_hw_watchpoint_tests early, before we start GDB
+ as part of the break-idempotent.exp script, and store the result in a
+ variable, we can then check this variable in the script as needed.
+
+ After this change break-idempotent.exp runs fine on powerpc.
+
+2022-06-29 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop stray NoRex64 from XBEGIN
+ Presumably this being there was a result of taking CALL as a reference
+ when adding the RTM insns. But with No_qSuf the attribute has no effect.
+
+2022-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build when BUILD_MAN is false
+ gprofng/ChangeLog
+ 2022-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29131
+ * gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true.
+ * src/Makefile.am: Likewise.
+ * gp-display-html/Makefile.in: Rebuild.
+ * src/Makefile.in: Rebuild.
+
+2022-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: use $(sysconfdir) instead $(prefix)/etc
+ gprofng/ChangeLog
+ 2022-06-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29191
+ * src/Makefile.am: Use $(sysconfdir) instead $(prefix)/etc.
+ * src/Settings.cc: Likewise.
+ * src/Makefile.in: Rebuild.
+
+2022-06-29 Alan Modra <amodra@gmail.com>
+
+ Re: ld/x86: skip p_align-1 tests with unsuitable compiler
+ commit d0e0f9c87a3e results "ERROR: i586-linux-cc does not exist" if
+ cross-building an i586-linux target without a target compiler
+ installed.
+
+ * testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New.
+ Use it after first testing check_compiler_available.
+
+2022-06-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-28 Pedro Alves <pedro@palves.net>
+
+ gdb+gdbserver/Linux: avoid reading registers while going through shell
+ For every stop, Linux GDB and GDBserver save the stopped thread's PC,
+ in lwp->stop_pc. This is done in save_stop_reason, in both
+ gdb/linux-nat.c and gdbserver/linux-low.cc. However, while we're
+ going through the shell after "run", in startup_inferior, we shouldn't
+ be reading registers, as we haven't yet determined the target's
+ architecture -- the shell's architecture may not even be the same as
+ the final inferior's.
+
+ In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
+ stopped for a breakpoint, and since when going through the shell, no
+ breakpoint is going to hit, we could simply teach save_stop_reason to
+ only record the stop pc when the thread stopped for a breakpoint.
+
+ However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
+ than breakpoint hits (e.g., it's used in tracepoints & the
+ "while-stepping" feature).
+
+ So to avoid GDB vs GDBserver divergence, we apply the same approach to
+ both implementations.
+
+ We set a flag in the inferior (process in GDBserver) whenever it is
+ being nursed through the shell, and when that flag is set,
+ save_stop_reason bails out early. While going through the shell,
+ we'll only ever get process exits (normal or signalled), random
+ signals, and exec events, so nothing is lost.
+
+ Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
+
+2022-06-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix gdb build with -fsanitize=thread and gcc 7
+ When building gdb with system gcc 7.5.0, I run into:
+ ...
+ gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
+ gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
+ [-Werror=return-type]
+ ...
+
+ This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
+ -Wreturn-type warning", which has been fixed in gcc-8.
+
+ Work around this by moving the default return outside the switch.
+
+ Tested on x86_64-linux.
+
+2022-06-28 Clément Chigot <chigot@adacore.com>
+
+ bfd: handle codepage when opening files on MinGW
+ Even if MS docs say that CP_UTF8 should always be used on newer
+ applications, forcing it might produce undefined filename if the
+ encoding isn't UTF-8.
+ MinGW seems to call ___lc_codepage_func() in order to retrieve the
+ current thread codepage.
+
+ bfd/ChangeLog:
+
+ * bfdio.c (_bfd_real_fopen): Retrieve codepage with
+ ___lc_codepage_func() on MinGW.
+
+2022-06-28 Clément Chigot <chigot@adacore.com>
+
+ windres: add quotes around preprocessor cmd if needed
+ This patch ensures that the gcc binary called by windres is quoted if
+ needed. Otherwise, errors can occur if the gcc is under a folder having
+ a name containing a space (eg "Program Files").
+
+ binutils/
+ * resrc.c (DEFAULT_PREPROCESSOR): Split into...
+ (DEFAULT_PREPROCESSOR_CMD): that...
+ (DEFAULT_PREPROCESSOR_ARGS): and that.
+ (look_for_default): Add quotes around the command if needed.
+ (read_rc_file): Adapt to new defines.
+
+2022-06-28 Nick Clifton <nickc@redhat.com>
+
+ Fix the display of the idnex values for DW_FORM_loclistx and DW_FORM_rnglistx. Correct the display of .debug.loclists sections.
+ PR 29267
+ * dwarf.c (display_debug_rnglists): New function, broken out of..
+ (display_debug_ranges): ... here.
+ (read_and_display_attr_value): Correct calculation of index
+ displayed for DW_FORM_loclistx and DW_FORM_rnglistx.
+ * testsuite/binutils-all/x86-64/pr26808.dump: Update expected
+ output.
+
+2022-06-28 Jan Beulich <jbeulich@suse.com>
+
+ ld/x86: skip p_align-1 tests with unsuitable compiler
+ When the compiler doesn't properly arrange for foo's alignment, there's
+ no point even trying these tests. Report the situation as a single
+ "unsupported" test.
+
+2022-06-28 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: align plt_branch stubs
+ plt_branch stubs are similar to plt_call stubs in that they branch
+ via bctr. Align them too.
+
+ bfd/
+ * elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for
+ plt_call stubs.
+ ld/
+ * testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes.
+ * testsuite/ld-powerpc/notoc.d: Likewise.
+ * testsuite/ld-powerpc/notoc.wf: Likewise.
+ * testsuite/ld-powerpc/notoc3.d: Likewise.
+ * testsuite/ld-powerpc/pr23937.d: Likewise.
+
+2022-06-28 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: plt_stub_pad
+ * elf64-ppc.c (plt_stub_pad): Simplify parameters and untangle
+ from plt_stub_size.
+ (ppc_size_one_stub): Call plt_stub_size before plt_stub_pad to
+ provide size. Recalculate size if it might change.
+
+2022-06-28 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: Tidy stub type changes
+ It made sense before I started using separate fields for main type and
+ sub type to add a difference in main type to the type (thus keeping
+ sub type unchanged). Not so much now.
+
+ * elf64-ppc.c (ppc_merge_stub): Simplify stub type change.
+ (ppc_size_one_stub): Likewise.
+
+2022-06-28 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ gdb:csky add pseudo regs for float and vector regs
+ In the existing CSKY architecture, there are at most 32 floating
+ and 16 vector registers. Float registers's count can be configured
+ as 16 or 32. In the future, the vector registers's count may be
+ extended to 32.
+
+ The bit width of floating-point register is 64bits, and the bit
+ width of vector register is 128bit.
+
+ Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower
+ 64 bits of the corresponding VRx.
+
+ Here, we will split each floating-point and vector register to
+ 32bits wide, add the corresponding pseudo registers, and finally
+ use them for the dwarf registers.
+
+ There are 128 pseudo registers in total, s0~s127, including:
+ 1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on.
+ Every two separated pseudo registers correspond to a float register.
+ 2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1,
+ and so on. Every four pseudo registers corresponds to a vector register.
+
+ Therefore, in s64~s127, there are general registers that are not actually
+ used. This part is to prepare for the expansion of vector registers to 32
+
+ Therefore, in s64~s127, half of the registers are actually unused. This
+ part is to prepare for the expansion of the vector register to 32.
+
+2022-06-28 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi>
+
+ PR29293, elfnn-aarch64.c: def_protected member unintialized
+ PR 29293
+ * elfnn-aarch64.c (elfNN_aarch64_link_hash_newfunc): Init def_protected.
+
+2022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Sstc' extension and its CSRs
+ This commit adds "stimecmp / vstimecmp" Extension (Sstc) and its CSRs.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sstc'
+ extension to valid 'S' extension list.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+ 'Sstc' extension. (riscv_csr_address): Add handling for new CSR
+ classes.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+ * testsuite/gas/riscv/csr.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: 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.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (CSR_STIMECMP, CSR_STIMECMPH,
+ CSR_VSTIMECMP, CSR_VSTIMECMPH): New CSR macros.
+
+2022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Sscofpmf' extension with its CSRs
+ This commit adds Count Overflow and Mode-Based Filtering Extension
+ (Sscofpmf) and its CSRs.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sscofpmf'
+ extension to valid 'S' extension list.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+ 'Sscofpmf' extension. (riscv_csr_address): Add handling for new
+ CSR classes.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+ * testsuite/gas/riscv/csr.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: 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.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (CSR_SCOUNTOVF, CSR_MHPMEVENT3H,
+ CSR_MHPMEVENT4H, CSR_MHPMEVENT5H, CSR_MHPMEVENT6H,
+ CSR_MHPMEVENT7H, CSR_MHPMEVENT8H, CSR_MHPMEVENT9H,
+ CSR_MHPMEVENT10H, CSR_MHPMEVENT11H, CSR_MHPMEVENT12H,
+ CSR_MHPMEVENT13H, CSR_MHPMEVENT14H, CSR_MHPMEVENT15H,
+ CSR_MHPMEVENT16H, CSR_MHPMEVENT17H, CSR_MHPMEVENT18H,
+ CSR_MHPMEVENT19H, CSR_MHPMEVENT20H, CSR_MHPMEVENT21H,
+ CSR_MHPMEVENT22H, CSR_MHPMEVENT23H, CSR_MHPMEVENT24H,
+ CSR_MHPMEVENT25H, CSR_MHPMEVENT26H, CSR_MHPMEVENT27H,
+ CSR_MHPMEVENT28H, CSR_MHPMEVENT29H, CSR_MHPMEVENT30H,
+ CSR_MHPMEVENT31H): New CSR macros.
+
+2022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'Smstateen' extension and its CSRs
+ This commit adds State Enable Extension (Smstateen) and its CSRs.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smstateen'
+ extension to valid 'S' extension list.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+ 'Smstateen' extension. (riscv_csr_address): Add handling for
+ new CSR classes.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+ * testsuite/gas/riscv/csr.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: 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.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (CSR_MSTATEEN0, CSR_MSTATEEN1,
+ CSR_MSTATEEN2, CSR_MSTATEEN3, CSR_SSTATEEN0, CSR_SSTATEEN1,
+ CSR_SSTATEEN2, CSR_SSTATEEN3, CSR_HSTATEEN0, CSR_HSTATEEN1,
+ CSR_HSTATEEN2, CSR_HSTATEEN3, CSR_MSTATEEN0H, CSR_MSTATEEN1H,
+ CSR_MSTATEEN2H, CSR_MSTATEEN3H, CSR_HSTATEEN0H, CSR_HSTATEEN1H,
+ CSR_HSTATEEN2H, CSR_HSTATEEN3H): New CSR macros.
+
+2022-06-28 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add new CSR feature gate handling (RV32,H)
+ To support feature gate like Smstateen && H, this commit adds certain
+ CSR feature gate handling. It also changes how RV32-only CSRs are
+ handled for cleanliness.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_csr_address): Add CSR feature gate
+ handling for H. Change handling on RV32.
+
+2022-06-28 Alan Modra <amodra@gmail.com>
+
+ Re: Disable execstack and rwx segments warnings for MIPS targets.
+ PR 29263
+ * configure.ac: Fix typo.
+ * testsuite/ld-elf/elf.exp: Add mips to targets that need
+ --warn-execstack to pass first pr29072 test.
+
+2022-06-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-27 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: update bug numbers from Gnats to bugzilla
+ Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen.
+
+ gdb.base/macscp.exp was referencing bug number 555, and the bug 7660
+ mentions that it used to be 555 on the Gnats system and seems to relate
+ to the issue at hand.
+
+ gdb.base/annota1.exp was referencing bug number 1270, and bug 8375
+ mentions being number 1270 on Gnats, and mentions annota1 specifically,
+ so it seemed pretty obvious.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build breaker with --enable-shared
+ When building gdb with --enable-shared, I run into:
+ ...
+ ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
+ `.rodata' can not be used when making a shared object; recompile with -fPIC
+ ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
+ `inflateResetKeep' in read-only section `.text'
+ collect2: error: ld returned 1 exit status
+ make[3]: *** [libbfd.la] Error 1
+ ...
+
+ This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
+ build with -fsanitize=thread").
+
+ The problem is that a single case statement in configure is shared to handle
+ special requirements for both the host libiberty and host zlib, which has the
+ effect that only one is handled.
+
+ Fix this by handling libiberty and zlib each in its own case statement.
+
+ Build on x86_64-linux, with and without --enable-shared.
+
+ ChangeLog:
+
+ 2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ * configure.ac: Set extra_host_libiberty_configure_flags and
+ extra_host_zlib_configure_flags in separate case statements.
+ * configure: Regenerate.
+
+2022-06-27 Pedro Alves <pedro@palves.net>
+
+ Make GDBserver abort on internal error in development mode
+ Currently, if GDBserver hits some internal assertion, it exits with
+ error status, instead of aborting. This makes it harder to debug
+ GDBserver, as you can't just debug a core file if GDBserver fails an
+ assertion. I've had to hack the code to make GDBserver abort to debug
+ something several times before.
+
+ I believe the reason it exits instead of aborting, is to prevent
+ potentially littering the filesystem of smaller embedded targets with
+ core files. I think I recall Daniel Jacobowitz once saying that many
+ years ago, but I can't be sure. Anyhow, that seems reasonable to me.
+
+ Since we nowadays have a distinction between development and release
+ modes, I propose to make GDBserver abort on internal error if in
+ development mode, while keeping the status quo when in release mode.
+
+ Thus, after this patch, in development mode, you get:
+
+ $ ../gdbserver/gdbserver
+ ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
+ captured_main: Assertion `0' failed.
+ Aborted (core dumped)
+ $
+
+ while in release mode, you'll continue to get:
+
+ $ ../gdbserver/gdbserver
+ ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
+ captured_main: Assertion `0' failed.
+ $ echo $?
+ 1
+
+ I do not think that this requires a separate configure switch.
+
+ A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends
+ up with:
+
+ === gdb Summary ===
+
+ # of unexpected core files 29
+ ...
+
+ for me, of which 8 are GDBserver core dumps, 7 more than without this
+ patch.
+
+ Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
+
+2022-06-27 Nick Clifton <nickc@redhat.com>
+
+ Replace a run-time assertion failure with a warning message when parsing corrupt DWARF data.
+ PR 29289
+ * dwarf.c (display_debug_names): Replace assert with a warning
+ message.
+
+ Fix NULL pointer indirection when parsing corrupt DWARF data.
+ PR 29290
+ * dwarf.c (read_and_display_attr_value): Check that debug_info_p
+ is set before dereferencing it.
+
+ Have gold's File_read::do_read() function check the start parameter
+ PR 23765
+ * fileread.cc (File_read::do_read): Check start parameter before
+ computing number of bytes to read.
+
+2022-06-27 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Unwind Non-Secure callbacks from Secure
+ Without this changeset, the unwinding doesn't take into account
+ Non-Secure to Secure stack unwinding enablement status and
+ doesn't choose the proper SP to do the unwinding.
+
+ This patch only unwinds the stack when Non-Secure to Secure
+ unwinding is enabled, previous SP is set w/r to the current mode
+ (Handler -> msp_s, Thread -> psp_s) and then the Secure stack is
+ unwound. Ensure thumb bit is set in PSR when needed. Also, drop
+ thumb bit from PC if set.
+
+2022-06-27 Nick Clifton <nickc@redhat.com>
+
+ Stop bogus warnings about DWARF indexed string offsets being too big.
+ * dwarf.c (fetch_indexed_string): Do not use length of first table
+ in string section as the length of every table in the section.
+ * testsuite/binutils-all/pr26112.r: Update expected output.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle older python in gdb.python/py-send-packet.py
+ With python 3.4, I run into:
+ ...
+ Traceback (most recent call last):^M
+ File "<string>", line 1, in <module>^M
+ File
+ "outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \
+ run_set_global_var_test^M
+ res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M
+ TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M
+ Error while executing Python code.^M
+ ...
+ while with python 3.6 this works fine.
+
+ The type of addr is <class 'gdb.Value'>, so the first thing to try is whether
+ changing it into a string works:
+ ...
+ addr_str = "%x" % addr
+ res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str)
+ ...
+ which gets us the more detailed:
+ ...
+ TypeError: unsupported operand type(s) for %: 'bytes' and 'str'
+ ...
+
+ Fix this by avoiding the '%' operator in the byte literal, and use instead:
+ ...
+ def xpacket_header (addr):
+ return ("X%x,4:" % addr).encode('ascii')
+ ...
+ res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02")
+ ...
+
+ Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was
+ tested on the gdb-12-branch in combination with python 2.7.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.reverse/i387-env-reverse.exp for -pie
+ When running test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with
+ target board unix/-m32/-fPIE/-pie, we run into:
+ ...
+ (gdb) PASS: gdb.reverse/i387-env-reverse.exp: push st0
+ info register eax^M
+ eax 0x56550000 1448411136^M
+ (gdb) FAIL: gdb.reverse/i387-env-reverse.exp: verify eax == 0x8040000
+ ...
+
+ The problem is that the tested instruction (fstsw) only sets $ax, not $eax.
+
+ Fix this by verifying $ax instead of $eax.
+
+ Tested on x86_64-linux with target boards unix/-m32 and unix/-m32/-fPIE/-pie.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Enable some test-cases for x86_64 -m32
+ When trying to run test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux
+ with target board unix/-m32, it's skipped.
+
+ Fix this by using is_x86_like_target instead of istarget "i?86-*linux*".
+
+ This exposes a number of duplicates, fix those by making the test names unique.
+
+ Likewise in a couple of other test-cases.
+
+ Tested on x86_64-linux with target boards unix/-m32.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Workaround unnecessary .s file with gfortran 4.8
+ After running test-case gdb.fortran/namelist.exp with gfortran 4.8.5, I'm left
+ with:
+ ...
+ $ git sti
+ On branch master
+ Your branch is up to date with 'origin/master'.
+
+ Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+ gdb/testsuite/lib/compiler.s
+
+ nothing added to commit but untracked files present (use "git add" to track)
+ ...
+
+ We're running into PR gcc/60447, which was fixed in gcc 4.9.0.
+
+ Workaround this by first copying the source file to the temp dir, such that
+ the .s file is left there instead:
+ ...
+ $ ls build/gdb/testsuite/temp/<runtest pid>/
+ compiler.c compiler.F90 compiler.s
+ ...
+
+ Tested on x86_64-linux.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Skip gdb.fortran/namelist.exp for gfortran 4.8
+ The test-case gdb.fortran/namelist.exp uses a gfortran feature (emitting
+ DW_TAG_namelist in the debug info) that has been supported since gfortran 4.9,
+ see PR gcc/37132.
+
+ Skip the test for gfortran 4.8 and earlier. Do this using gcc_major_version,
+ and update it to be able to handle "gcc_major_version {gfortran-*} f90".
+
+ Tested on x86_64-linux, with gfortran 4.8.5, 7.5.0, and 12.1.1.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix parsing of .debug_str_offsets header
+ When running test-case gdb.dwarf2/fission-mix.exp with target board dwarf64
+ and gcc-12 (defaulting to DWARF5), I run into:
+ ...
+ (gdb) break func2^M
+ Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \
+ .debug_str.dwo section in CU at offset 0x0 [in module fission-mix]^M
+ (gdb) FAIL: gdb.dwarf2/fission-mix.exp: break func2
+ ...
+
+ The .debug_str_offsets section has version 5, so as per the standard it has
+ it's own header, with initial length and version:
+ ...
+ Contents of the .debug_str_offsets.dwo section (loaded from fission-mix2.dwo):
+
+ Length: 0x1c
+ Version: 0x5
+ Index Offset [String]
+ 0 0 build/gdb/testsuite
+ 1 33 GNU C17
+ 2 8f src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c
+ ...
+
+ But when trying to read the string offset at index 0 in the table (which
+ is 0), we start reading at offset 8, which points in the header, at the last
+ 4 bytes of the initial length (it's 12 bytes because of 64-bit dwarf), as well
+ at the 2-byte version field and 2 bytes of padding, so we get:
+ ...
+ (gdb) p /x str_offset
+ $1 = 0x500000000
+ ...
+ which indeed is an offset that doesn't fit in the .debug_str section.
+
+ The offset 8 is based on reader->cu->header.addr_size:
+ ...
+ static const char *
+ read_dwo_str_index (const struct die_reader_specs *reader, ULONGEST str_index)
+ {
+ ULONGEST str_offsets_base = reader->cu->header.version >= 5
+ ? reader->cu->header.addr_size : 0;
+ ...
+ which doesn't in look in agreement with the standard.
+
+ Note that this happens to give the right answer for 32-bit dwarf and
+ addr_size == 8, because then we have header size ==
+ (initial length (4) + version (2) + padding (2)) == 8.
+
+ Conversely, for 32-bit dwarf and addr_size == 4 (target board unix/-m32)
+ we run into a similar problem. It just happens to not trigger the warning,
+ instead we get the wrong strings, like "func2" for DW_AT_producer and
+ "build/gdb/testsuite" for DW_AT_name of the DW_TAG_compile_unit DIE.
+
+ Fix this by parsing the .debug_str_offsets header in read_dwo_str_index.
+
+ Add a FIXME that we should not parse this for every call.
+
+ Tested on x86_64-linux.
+
+2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix gdbserver build with -fsanitize=thread
+ [ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with
+ -fsanitize=thread"). ]
+
+ When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we
+ run into:
+ ...
+ ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \
+ `__tsan_init' in read-only section `.text'
+ ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \
+ against symbol `__tsan_init' can not be used when making a shared object; \
+ recompile with -fPIC
+ ld: final link failed: bad value
+ collect2: error: ld returned 1 exit status
+ make[1]: *** [libinproctrace.so] Error 1
+ ...
+ which looks similar to what is described in commit 78e49486944 ("[gdb/build]
+ Fix gdbserver build with -fsanitize=address").
+
+ The gdbserver component builds a shared library libinproctrace.so, which uses
+ libiberty and therefore requires the pic variant. The gdbserver Makefile is
+ setup to use this variant, if available, but it's not there.
+
+ Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a
+ component that needs the libiberty pic variant, setting:
+ ...
+ extra_host_libiberty_configure_flags=--enable-shared
+ ...
+
+ Tested on x86_64-linux.
+
+ ChangeLog:
+
+ 2022-06-27 Tom de Vries <tdevries@suse.de>
+
+ * configure.ac: Build libiberty pic variant for gdbserver.
+ * configure: Regenerate.
+
+2022-06-27 Nick Clifton <nickc@redhat.com>
+
+ Disable execstack and rwx segments warnings for MIPS targets.
+ PR 29263
+ * configure.ac: Move HPPA specific code from here...
+ * configure.tgt: ... to here. Add similar code for MIPS.
+ Move code for CRIS, MIPS and HPPA to block at start of file.
+ * configure: Regenerate.
+
+2022-06-27 Jan Beulich <jbeulich@suse.com>
+
+ bfd: prune config.bfd's setting of targ_archs
+ The final "match all" case can take care of a few explicit entries:
+ Purge those. Also move s12z* into proper position (the table is
+ otherwise sorted, after all).
+
+2022-06-27 Jan Beulich <jbeulich@suse.com>
+
+ drop XC16x bits
+ Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved
+ the architecture from the "obsolete but still available" to the
+ "obsolete / support removed" list in config.bfd, making the architecture
+ impossible to enable (except maybe via "enable everything" options").
+
+ Note that I didn't touch */po/*.po{,t} on the assumption that these
+ would be updated by some (half)automatic means.
+
+2022-06-27 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ Fix location list offset address dump under DW_AT_location (dwarf-5)
+ For clang compiled objects with dwarf-5, location list offset address dump
+ under DW_AT_location is corrected, where DW_FORM_loclistx is used. While
+ dumping the location list offset, the address dumped is wrong where it was
+ refering to .debug_addr instead of .debug_loclists
+
+ * dwarf.c (fetch_indexed_value): Add base_address as parameter and
+ use it to access the section offset.
+ (read_and_display_attr_value): Handle DW_FORM_loclistx form separately.
+ Pass loclists_base to fetch_indexed_value().
+
+2022-06-27 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 .branch_lt address
+ .branch_lt is really an extension of .plt, as is .iplt. We'd like all
+ of the PLT sections to be fixed relative to .TOC. after stub sizing,
+ because changes in offset to PLT entries might mean a change in stub
+ sizes. When -z relro, the relro layout does this by laying out
+ sections from the end of the relro segment. So for example, a change
+ in .eh_frame (which happens after stub sizing) will keep the same GOT
+ to PLT offset when -z relro. Not so when -z norelro, because then the
+ usual forward layout of section is done and .got is more aligned than
+ .branch_lt.
+
+ * emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
+ to .got.
+ * testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.
+
+2022-06-27 Alan Modra <amodra@gmail.com>
+
+ -z relro relaxation and ld script SIZEOF
+ A number of targets use assignments like:
+ . = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .);
+ (from i386) in linker scripts to put the end of the relro segment past
+ the header in .got.plt. Examination of testcases like those edited by
+ this patch instead sees the end of the relro segment being placed at
+ the start of .got.plt. For the i386 pie1 test:
+
+ [ 9] .got.plt PROGBITS 00002000 001000 00000c 04 WA 0 0 4
+
+ GNU_RELRO 0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R 0x1
+
+ A map file shows:
+
+ .dynamic 0x0000000000001f90 0x70
+ *(.dynamic)
+ .dynamic 0x0000000000001f90 0x70 tmpdir/pie1.o
+ 0x0000000000001f90 _DYNAMIC
+
+ .got 0x0000000000002000 0x0
+ *(.got)
+ .got 0x0000000000002000 0x0 tmpdir/pie1.o
+ *(.igot)
+ 0x0000000000002ff4 . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0)
+
+ .got.plt 0x0000000000002000 0xc
+ *(.got.plt)
+ .got.plt 0x0000000000002000 0xc tmpdir/pie1.o
+ 0x0000000000002000 _GLOBAL_OFFSET_TABLE_
+
+ The DATA_SEGMENT_RELRO_END value in the map file is weird too. All of
+ this is triggered by SIZEOF (.got.plt) being evaluated wrongly as
+ zero. Fix it by taking into account the action of
+ lang_reset_memory_regions during relaxation.
+
+ * ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset.
+ * ldlang.c (lang_size_sections_1): Don't reset processed_vma here.
+ * testsuite/ld-i386/pie1.d: Adjust to suit.
+ * testsuite/ld-x86-64/pr20830a.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-06-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-25 Fangrui Song <i@maskray.me>
+
+ arm: Define elf_backend_extern_protected_data to 0 [PR 18705]
+ Similar to commit 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2 for aarch64.
+
+ Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce
+ R_ARM_GLOB_DAT but that defeated the purpose of protected visibility
+ as an optimization. Restore the previous behavior (which matches
+ ld.lld) by defining elf_backend_extern_protected_data to 0.
+
+2022-06-25 Tom Tromey <tom@tromey.com>
+
+ Fix corrupt DWARF in dw2-double-set-die-type
+ The dw2-double-set-die-type.exp test case caused an AddressSanitizer
+ failure in the new DWARF scanner.
+
+ The immediate cause was bad DWARF in the test -- in particular, the
+ the sibling attribute here:
+
+ <2><181>: Abbrev Number: 33 (DW_TAG_subprogram)
+ <182> DW_AT_external : 1
+ <183> DW_AT_name : address
+ <18b> DW_AT_type : <0x171>
+ <18f> DW_AT_declaration : 1
+ <190> DW_AT_sibling : <0x1a1>
+ ...
+ <1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type)
+ <1a2> DW_AT_byte_size : 4
+ <1a3> DW_AT_type : <0x1a7>
+
+ ...points to a "sibling" DIE that is at a different child depth.
+
+ Because this test case doesn't really require sibling attributes, this
+ patch fixes the problem by removing them from the test.
+
+ Note that gdb is not generally robust against malformed DWARF.
+ Detecting and compensating for this problem would probably be
+ expensive and, IMO, is better left to some (still hypothetical) DWARF
+ linter.
+
+2022-06-25 Tom Tromey <tom@tromey.com>
+
+ Fix end of CU calculation in cooked_indexer::index_dies
+ cooked_indexer::index_dies incorrect computes the end of the current
+ CU in the .debug_info. This isn't readily testable without writing
+ intentionally corrupt DWARF, but it's apparent through observation: it
+ is currently based on 'info_ptr', which does not always point to the
+ start of the CU. This patch fixes the expression. Tested on x86-64
+ Fedora 34.
+
+2022-06-25 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement loongarch_linux_syscall_next_pc()
+ When FRAME is at a syscall instruction, return the PC of the next
+ instruction to be executed.
+
+ gdb: LoongArch: Define register numbers and clean up code
+ This commit defines register numbers of various important registers,
+ we can use them directly in the related code, and also clean up some
+ code to make them more clear and readable.
+
+2022-06-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-24 Pedro Alves <pedro@palves.net>
+
+ Eliminate TUI/CLI observers duplication
+ For historical reasons, the CLI and the TUI observers are basically
+ exact duplicates, except for the downcast:
+
+ cli:
+ struct cli_interp *cli = as_cli_interp (interp);
+ tui:
+ struct interp *tui = as_tui_interp (interp);
+
+ and how they get at the interpreter's ui_out:
+
+ cli:
+ cli->cli_uiout
+ tui:
+ tui->interp_ui_out ()
+
+ Since interp_ui_out() is a virtual method that also works for the CLI
+ interpreter, and, both the CLI and the TUI interpreters inherit from
+ the same base class (cli_interp_base), we can convert the CLI
+ observers to cast to cli_interp_base instead and use interp_ui_out()
+ too. With that, the CLI observers will work for the TUI interpreter
+ as well. This lets us completely eliminate the TUI observers. That's
+ what this commit does.
+
+ Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0
+
+2022-06-24 Pedro Alves <pedro@palves.net>
+
+ Revert "Delete delete_thread_silent"
+ Turns out we'll be gaining a new use of this function very soon, the
+ incoming AMDGPU port needs it. Let's add it back, as it isn't really
+ hurting anything.
+
+ This reverts commit 39b8a8090ed7e8967ceca3655aa5f3a2ae91219d.
+
+2022-06-24 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Update the value of active sp when base sp changes
+ For Arm Cortex-M33 with security extensions, there are 4 different
+ stacks pointers (msp_s, msp_ns, psp_s, psp_ns).
+ When plain "sp" is updated during unwinding of the stack, the active
+ stack pointer of the 4 stack pointers needs to be kept in sync.
+
+2022-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove unneeded calls to get_compiler_info
+ It is not necessary to call get_compiler_info before calling
+ test_compiler_info, and, after recent commits that removed setting up
+ the gcc_compiled, true, and false globals from get_compiler_info,
+ there is now no longer any need for any test script to call
+ get_compiler_info directly.
+
+ As a result every call to get_compiler_info outside of lib/gdb.exp is
+ redundant, and this commit removes them all.
+
+ There should be no change in what is tested after this commit.
+
+2022-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove global gcc_compiled from gdb.exp
+ After this commit the gcc_compiled global is no longer exported from
+ lib/gdb.exp. In theory we could switch over all uses of gcc_compiled
+ to instead call test_compiler_info directly, however, I have instead
+ added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated
+ the testsuite to call this proc instead of using the global.
+
+ Having a new proc specifically for this task means that we have a
+ single consistent pattern for detecting gcc. By wrapping this logic
+ within a proc that calls test_compiler_info, rather than using the
+ global, means that test scripts don't need to call get_compiler_info
+ before they read the global, simply calling the new proc does
+ everything in one go.
+
+ As a result I've been able to remove the get_compiler_info calls from
+ all the test scripts that I've touched in this commit.
+
+ In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
+ being checked at the top of the script to decide if the whole script
+ should be skipped or not. In these cases I've called the new proc
+ directly and removed all uses of gcc_compiled.
+
+ In other cases, e.g. most of the gdb.base scripts, there were many
+ uses of gcc_compiled. In these cases I set a new global gcc_compiled
+ near the top of the script, and leave the rest of the script
+ unchanged.
+
+ There should be no changes in what is tested after this commit.
+
+2022-06-24 Pedro Alves <pedro@palves.net>
+
+ Include count of unexpected core files in gdb.sum summary
+ If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
+ crash while running the GDB testsuite, and you've setup your machine
+ such that core files are dumped in the current directory instead of
+ being shoved somewhere by abrt, apport, or similar (as you should for
+ proper GDB testing), you'll end up with an unexpected core file in the
+ $build/gdb/testsuite/ directory.
+
+ It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
+ during teardown, and thus such a crash won't be noticed by looking at
+ the gdb.sum file at all. This commit aims at improving that, by
+ including a new "unexpected core files" line in the testrun summary.
+
+ For example, here's what I get on x86-64 Ubuntu 20.04, with this
+ patch:
+
+ === gdb Summary ===
+
+ # of unexpected core files 12 << new info
+ # of expected passes 107557
+ # of unexpected failures 35
+ # of expected failures 77
+ # of unknown successes 2
+ # of known failures 114
+ # of untested testcases 31
+ # of unsupported tests 139
+
+ I have my core pattern setup like this:
+
+ $ cat /proc/sys/kernel/core_pattern
+ core.%e.%p.%h.%t
+
+ That's:
+
+ %e: executable filename
+ %p: pid
+ %h: hostname
+ %t: UNIX time of dump
+
+ and so I get these core files:
+
+ $ ls -1 testsuite/core.*
+ testsuite/core.connect-with-no.216191.nelson.1656002431
+ testsuite/core.connect-with-no.217729.nelson.1656002431
+ testsuite/core.gdb.194247.nelson.1656002423
+ testsuite/core.gdb.226014.nelson.1656002435
+ testsuite/core.gdb.232078.nelson.1656002438
+ testsuite/core.gdb.352268.nelson.1656002441
+ testsuite/core.gdb.4152093.nelson.1656002337
+ testsuite/core.gdb.4154515.nelson.1656002338
+ testsuite/core.gdb.4156668.nelson.1656002339
+ testsuite/core.gdb.4158871.nelson.1656002341
+ testsuite/core.gdb.468495.nelson.1656002444
+ testsuite/core.vgdb.4192247.nelson.1656002366
+
+ where we can see that GDB crashed a number of times, but also
+ Valgrind's vgdb, and a couple testcase programs. Neither of which is
+ good.
+
+ If your core_pattern is just "core" (but why??), then I guess that you
+ may end up with just a single core file in testsuite/. Still, that is
+ one core file too many.
+
+ Above, we see a couple cores for "connect-with-no", which are the
+ result of gdb.server/connect-with-no-symbol-file.exp. This is a case
+ mentioned above -- while the program crashed, that happens during
+ testcase teardown, and it goes unnoticed (without this commit) by
+ gdb.sum results. Vis:
+
+ $ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
+ ...
+ === gdb Summary ===
+
+ # of unexpected core files 2
+ # of expected passes 8
+
+ ...
+ $
+
+ The tests fully passed, but still the testcase program crashed
+ somehow:
+
+ $ ls -1 testsuite/core.*
+ testsuite/core.connect-with-no.941561.nelson.1656003317
+ testsuite/core.connect-with-no.941682.nelson.1656003317
+
+ Against --target_board=native-extended-gdbserver it's even worse. I
+ get:
+
+ # of unexpected core files 26
+
+ and note that when GDBserver hits an assertion failure, it exits with
+ error, instead of crashing with SIGABRT. I think that should be
+ changed, at least on development builds, but that would be for another
+ patch. After such patch, I suspect the number of unexpected cores
+ will be higher, as there are likely teardown GDBserver assertions that
+ we're not noticing.
+
+ I decided to put this new info in the "gdb Summary" section, as that's
+ a place people already are used to looking at, either when looking at
+ the tail of gdb.sum, or when diffing gdb.sum files, and we've already
+ extended this section before, to include the count of DUPLICATE and
+ PATH problems, so there's precedent.
+
+ Implementation-wise, the new line is appended after DejaGnu is
+ finished, with a shell script that is invoked by the Makefile. It is
+ done this way so that serial and parallel testing work the same way.
+ My initial cut at an implementation was in TCL, straight in
+ testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
+ handled, like so:
+
+ @@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
+ $counts(paths,$which)
+ maybe_show_count "# of duplicate test names\t" \
+ $counts(duplicates,$which)
+ +
+ + set cores [glob -nocomplain -directory $::objdir core*]
+ + maybe_show_count "# of unexpected core files\t" \
+ + [llength $cores]
+ }
+
+ But that would only work for serial testing, as in parallel testing,
+ the final gdb.sum is generated by aggregating the results of all the
+ individual gdb.sum files, and dg-extract-results.sh doesn't know about
+ our new summary line. And I don't think that dg-extract-results.sh
+ should be taught about it, since the count of core files is not
+ something that we want to count many times, once per testcase, and
+ then add up the subcounts at the end. Every time we count the core
+ files, we're already counting the final count.
+
+ I considered using the Tcl implementation in serial mode, and the
+ script approach for parallel testing, but that has the obvious
+ downside of implementing and maintaining the same thing twice. In the
+ end, I settled on the script approach for serial mode too, which
+ requires making the "check-single" rule print the tail end of the
+ gdb.sum file, with a side effect being that if you look at the
+ terminal after a run (instead of at the gdb.sum file), you'll see the
+ "gdb Summary" section twice, once without the unexpected core lines
+ printed, and then another with. IMO, this isn't an issue; when
+ testing in parallel mode, if you look at the terminal after "make -jN
+ check", you'll also see multiple "gdb Summary" sections printed.
+
+ Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491
+
+2022-06-24 Pedro Alves <pedro@palves.net>
+
+ Improve core file path detection & put cores in output dir
+ After a testrun, I noticed that I have some kernel-produced cores for
+ testcase programs, under build/gdb/testsuite/, which shouldn't be
+ there:
+
+ $ ls -1 testsuite/core.*
+ testsuite/core.annota1.1274351.nelson.1656004407
+ testsuite/core.annota3.1288474.nelson.1656004414
+ testsuite/core.exitsignal.1240674.nelson.1656004391
+
+ I have my core pattern setup like this:
+
+ $ cat /proc/sys/kernel/core_pattern
+ core.%e.%p.%h.%t
+
+ That's:
+
+ %e: executable filename
+ %p: pid
+ %h: hostname
+ %t: UNIX time of dump
+
+ so it's easy to tell which program produced the core from the core
+ file name.
+
+ From above, we can tell that the corresponding testcases are
+ gdb.base/annota1.exp, gdb.base/annota3.exp and
+ gdb.base/exitsignal.exp.
+
+ At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
+ them to delete the core file. However, that isn't working for me,
+ because said code only looks for cores named exactly either "core" or
+ "core.PID", and my core_pattern doesn't match that.
+
+ Another issue I noticed, is that I have not been running
+ gdb.base/bigcore.exp, for a similar reason. I get:
+
+ Program terminated with signal SIGABRT, Aborted.
+ The program no longer exists.
+ (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
+ UNTESTED: gdb.base/bigcore.exp: can't generate a core file
+
+ But I actually have a core file under the testcase's output dir:
+
+ $ find . -name "core.*"
+ ./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213
+ $
+
+ This commit fixes these things, by adding a find_core_file routine
+ that searches core files in a way that works with my core pattern as
+ well. This then also adds a convenience remove_core routine as a
+ wrapper around find_core_file that removes the found core file.
+
+ In addition, it changes some testcases that expect to have their
+ program dump core, to switch the inferior's cwd to the testcase's
+ output dir, so that the core is dumped there instead of in
+ build/gdb/testsuite/. Some testcases were already doing that, but not
+ all. The idea is that any core file dumped in build/gdb/testsuite/ is
+ an unexpected core file. The next patch will add a count of such
+ unexpected core files to gdb.sum.
+
+ Another change is that the directory changing is now done with "set
+ cwd" instead of with "cd". "set cwd" only affects the inferior cwd,
+ while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd",
+ if GDB dumps core in these testcases, the GDB core dump will still end
+ up in build/gdb/testsuite/, and can thus be detected as an unexpected
+ core.
+
+ Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607
+
+2022-06-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make use of RAII in run_inferior_call
+ In passing I noticed that there are three local variables in
+ run_inferior_call that are used to save, and then restore some state,
+ I think these could all be replaced with a RAII style scoped_restore
+ instead.
+
+ Of the three locals that I've changed, the only one that I believe is
+ now restored in a different location is ui::async, before this commit
+ the async field was restored after a call to either delete_file_handle
+ or ui_register_input_event_handler, and after this commit, the field
+ is restored before these calls. However, I don't believe that either
+ of these functions depend on the value of the async field, so I
+ believe the commit is fine.
+
+ Tested on x86-64/Linux passes with no regressions.
+
+2022-06-24 Pedro Alves <pedro@palves.net>
+
+ Delete delete_thread_silent
+ delete_thread_silent is no longer used anywhere. Delete it.
+
+ Change-Id: Iafcec12339861d5ab2e29c14d7b1f884c9e11c0f
+
+2022-06-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-23 Tom Tromey <tromey@adacore.com>
+
+ Don't declare cli_set_logging
+ cli_set_logging is declared but not defined. It's probably a leftover
+ from whenever interpreters were changed to use inheritance. This
+ patch removes the declaration. Tested by grep and rebuilding.
+
+ Use PyBool_FromLong
+ I noticed a few spots that were explicitly creating new references to
+ Py_True or Py_False. It's simpler here to use PyBool_FromLong, so
+ this patch changes all the places I found.
+
+2022-06-23 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: fix assertion in ppc_build_one_stub with -Os code
+ save_res stubs aren't written in ppc_build_one_stub, their offsets
+ (which are zero) should not be checked.
+
+ * elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets.
+
+2022-06-23 Alan Modra <amodra@gmail.com>
+
+ Re: PowerPC64: stub debug dump
+ Let's show the current stub as well as the previous one. Of interest
+ is the current offset and a new field, id. Check that the build
+ hash table traversal is in the same order as sizing traversal too.
+
+ * elf64-ppc.c (struct ppc_stub_hash_entry): Add id.
+ (struct ppc_link_hash_table): Add stub_id.
+ (stub_hash_newfunc): Init id and symtype.
+ (dump_stub): New function, extracted from..
+ (dump_previous_stub): ..here. Deleted.
+ (ppc_build_one_stub): Sanity check stub id as well as offset.
+ Show current stub as well as previous.
+ (ppc_size_one_stub): Set stub id.
+ (ppc64_elf_size_stubs): Init stub_id before traversal.
+ (ppc64_elf_build_stubs): Likewise.
+
+2022-06-23 Fangrui Song <maskray@google.com>
+
+ aarch64: Allow PC-relative relocations against protected STT_FUNC for -shared
+ __attribute__((visibility("protected"))) void *foo() {
+ return (void *)foo;
+ }
+
+ gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic:
+
+ relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC
+
+ Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress
+ the error. The new behavior matches gold and ld.lld.
+
+ Note: if some code tries to use direct access relocations to take the
+ address of foo (likely due to -fno-pic), the pointer equality will
+ break, but the error should be reported on the executable link, not on
+ the innocent shared object link. glibc 2.36 will give a warning at
+ relocation resolving time.
+
+2022-06-23 Fangrui Song <maskray@google.com>
+
+ aarch64: Define elf_backend_extern_protected_data to 0 [PR 18705]
+ Follow-up to commit 90b7a5df152a64d2bea20beb438e8b81049a5c30
+ ("aarch64: Disallow copy relocations on protected data").
+
+ Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce
+ R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility
+ as an optimization. Restore the previous behavior (which matches
+ ld.lld) by defining elf_backend_extern_protected_data to 0.
+
+2022-06-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-22 Tom Tromey <tromey@adacore.com>
+
+ Use std::string for interpreter_p
+ The global interpreter_p is a manually-managed 'char *'. This patch
+ changes it to be a std::string instead, and removes some erroneous
+ comments.
+
+ Move mi_interpreter to mi-interp.h
+ I noticed that touching interps.h caused a lot of recompilation. I
+ tracked this down to mi-common.h including this file. This patch
+ moves the MI interpreter to mi-interp.h, which cuts down on
+ recompilation when modifying interps.h.
+
+ Use unique_xmalloc_ptr in interp
+ This changes interp::m_name to be a unique_xmalloc_ptr, removing some
+ manual memory management. It also cleans up the initialization of the
+ 'inited' member, and moves the 'private:' and 'public:' keywords to
+ their proper spots.
+
+2022-06-22 Fangrui Song <i@maskray.me>
+
+ aarch64: Disallow copy relocations on protected data
+ If an executable has copy relocations for extern protected data, that
+ can only work if the shared object containing the definition is built
+ with assumptions (a) the compiler emits GOT-generating relocations (b)
+ the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the
+ shared object uses its own definition directly and the executable
+ accesses a stale copy. Note: the GOT relocations defeat the purpose of
+ protected visibility as an optimization, and it turns out this never
+ worked perfectly.
+
+ glibc 2.36 will warn on copy relocations on protected data. Let's
+ produce a warning at link time, matching ld.lld which has been used on
+ many aarch64 OSes.
+
+ Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error.
+ This is to largely due to GCC 5's "x86-64: Optimize access to globals in
+ PIE with copy reloc" which started to use direct access relocations for
+ external data symbols in -fpie mode.
+
+ GCC's aarch64 port does not have the change. Nowadays with most builds
+ switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about
+ copy relocations. So for aarch64 we simply don't check
+ GNU_PROPERTY_NO_COPY_ON_PROTECTED.
+
+2022-06-22 Kumar N, Bhuvanendra <Kavitha.Natarajan@amd.com>
+
+ Binutils support for split-dwarf and dwarf-5
+ * dwarf.c (fetch_indexed_string): Added new parameter
+ str_offsets_base to calculate the string offset.
+ (read_and_display_attr_value): Read DW_AT_str_offsets_base
+ attribute.
+ (process_debug_info): While allocating memory and initializing
+ debug_information, do it for do_debug_info also, if its true.
+ (load_separate_debug_files): Load .debug_str_offsets if exists.
+ * dwarf.h (struct debug_info): Add str_offsets_base field.
+
+2022-06-22 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Reorder the prefixed extensions which are out of order.
+ This patch has been pending for almost a year... However, I noticed that
+ llvm can already re-order the extensions, even if they are out of orders.
+ Not really sure if they can also re-order the single letter extensions,
+ but at least we can do this for the multi-letter extensions in binutils.
+
+ bfd/
+ * elfxx-riscv.c (riscv_parse_prefixed_ext): Removed the code which are
+ used to check the prefixed extension orders.
+ gas/
+ * testsuite/gas/riscv/march-fail-order-x-z.d: Removed since we will help
+ tp reorder the prefixed extensions for now.
+ * testsuite/gas/riscv/march-fail-order-x-z.l: Likewise.
+ * testsuite/gas/riscv/march-fail-order-x.d: Likewise.
+ * testsuite/gas/riscv/march-fail-order-x.l: Likewise.
+ * testsuite/gas/riscv/march-fail-order-z.d: Likewise.
+ * testsuite/gas/riscv/march-fail-order-z.l: Likewise.
+
+2022-06-22 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Use single h extension to control hypervisor CSRs and instructions.
+ According to the picture 28.1 in the current ISA spec, h is no larger the
+ multi-letter extension, it is a single extension after v. Therefore, this
+ patch fix the implementation, and use the single h to control hypervisor
+ CSRs and instructions, which we promised to do before.
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_std_ext): Added h with version 1.0 after v.
+ (riscv_supported_std_h_ext): Removed.
+ (riscv_all_supported_ext): Updated since riscv_supported_std_h_ext is removed.
+ (riscv_prefix_ext_class): Removed RV_ISA_CLASS_H.
+ (parse_config): Updated since riscv_prefix_ext_class is removed.
+ (riscv_recognized_prefixed_ext): Likewise.
+ (riscv_get_default_ext_version): Likewise.
+ (riscv_multi_subset_supports): Handle INSN_CLASS_H for hypervisor instructions.
+ (riscv_multi_subset_supports_ext): Likewise.
+ gas/
+ * config/tc-riscv.c (riscv_csr_class): Added CSR_CLASS_H and CSR_CLASS_H_32 for
+ hypervisor CSRs.
+ (riscv_csr_address): Likewise.
+ * testsuite/gas/riscv/csr-version-1p10.d: Updated since hypervisor CSRs are
+ controlled by single h extension for now.
+ * 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: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+ * testsuite/gas/riscv/h-ext-32.d: Added h to architecture string.
+ * testsuite/gas/riscv/h-ext-64.d: Likewise.
+ * testsuite/gas/riscv/march-fail-single-prefix-h: Removed since h is no
+ longer multi-letter extension.
+ * testsuite/gas/riscv/march-fail-unknown-h.d: Likewise.
+ include/
+ * opcode/riscv-opc.h: Control hypervisor CSRs by h extension, rather than
+ the privileged spec verisons.
+ * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_H.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Control hypervisor instructions by h extension.
+
+2022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add 'H' to canonical extension ordering
+ This commit adds 'H' to canonical extension ordering based on current
+ consensus (not officially ratified as a new ISA specification manual
+ but discussion for software compatibility is made).
+
+ bfd/ChangeLog
+
+ * elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for
+ canonical extension ordering based on current consensus.
+
+2022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Prepare i18n for required ISA extensions
+ Some strings returned by the riscv_multi_subset_supports_ext function
+ contain not just extension names but words like "and" and "or".
+ This commit wraps such strings with the gettext macro (_) for
+ internationalization in the future.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports_ext): Wrap some
+ strings with the gettext macro to prepare future i18n.
+
+2022-06-22 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix inconsistent error message (range)
+ This commit fixes inconsistent error message format involving compressed
+ funct<n> fields. In specific, funct6 had an error message with range
+ 0..2^<n> ("0..64") unlike other funct<n> fields with 0..2^<n>-1
+ (e.g. funct4 with "0..15").
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_ip): Fix inconsistent error message.
+
+2022-06-22 Marcus Nilsson <brainbomb@gmail.com>
+
+ readelf: replace xmalloc with malloc in slurp_relr_relocs
+ Using xmalloc makes the null check redundant since failing allocation
+ will exit the program. Instead use malloc and let the error be
+ conveyed up the call chain.
+
+2022-06-22 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: stub debug dump
+ powerpc64le-linux-ld is failing the assertion in ppc_build_one_stub,
+ again apparently, which means a stub will overwrite the tail of a
+ previous stub. The difficulty with debugging these issues is that
+ it's not a problem with the stub that triggers the assertion, but the
+ previous stub in that section. This patch keeps track of the last
+ stub and adds a debug dump. Hopefully that will help.
+
+ * elf64-ppc.c (enum _ppc64_sec_type): Add sec_stub.
+ (struct _ppc64_elf_section_data): Add u.last_ent.
+ (dump_previous_stub): New function.
+ (ppc_build_one_stub): Keep track of previous stub, and dump it
+ when finding an overlapping stub.
+
+2022-06-22 Alan Modra <amodra@gmail.com>
+
+ PR29270, DW_FORM_udata signed output
+ PR 29270
+ * dwarf.c (read_and_display_attr_value): Output DW_FORM_udata
+ as unsigned.
+
+2022-06-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-21 Nick Alcock <nick.alcock@oracle.com>
+
+ ld: regenerate configure after recent misgeneration
+ Things work again after this.
+
+ ld/ChangeLog:
+
+ * configure: Regenerate.
+
+2022-06-21 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: tests: prune warnings from compiler output
+ We were failing to call prune_warnings appropriately, leading to
+ false-positive test failures on some platforms (observed on
+ sparclinux).
+
+ libctf/ChangeLog:
+
+ * testsuite/lib/ctf-lib.exp: Prune warnings from compiler and
+ linker output.
+ * testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise,
+ and ar output too.
+
+2022-06-21 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: avoid mingw warning
+ A missing paren led to an intended cast to avoid dependence on the size
+ of size_t in one argument of ctf_err_warn applying to the wrong type by
+ mistake.
+
+ libctf/ChangeLog:
+
+ * ctf-serialize.c (ctf_write_mem): Fix cast.
+
+2022-06-21 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: fix linking together multiple objects derived from the same source
+ Right now, if you compile the same .c input repeatedly with CTF enabled
+ and different compilation flags, then arrange to link all of these
+ together, then things misbehave in various ways. libctf may conflate
+ either inputs (if the .o files have the same name, say if they are
+ stored in different .a archives), or per-CU outputs when conflicting
+ types are found: the latter can lead to entirely spurious errors when
+ it tries to produce multiple per-CU outputs with the same name
+ (discarding all but the last, but then looking for types in the earlier
+ ones which have just been thrown away).
+
+ Fixing this is multi-pronged. Both inputs and outputs need to be
+ differentiated in the hashtables libctf keeps them in: inputs with the
+ same cuname and filename need to be considered distinct as long as they
+ have different associated CTF dicts, and per-CU outputs need to be
+ considered distinct as long as they have different associated input
+ dicts. Right now there is nothing tying the two together other than the
+ CU name: fix this by introducing a new field in the ctf_dict_t named
+ ctf_link_in_out, which (for input dicts) points to the associated per-CU
+ output dict (if any), and for output dicts points to the associated
+ input dict. At creation time the name used is completely arbitrary:
+ it's only important that it be distinct if CTF dicts are distinct. So,
+ when a clash is found, adjust the CU name by sticking the number of
+ elements in the input on the end. At output time, the CU name will
+ appear in the linked object, so it matters a little more that it look
+ slightly less ugly: in conflicting cases, append an incrementing
+ integer, starting at 0.
+
+ This naming scheme is not very helpful, but it's hard to see what else
+ we can do. The input .o name may be the same. The input .a name is not
+ even visible to ctf_link, and even *that* might be the same, because
+ .a's can contain many members with the same name, all of which
+ participate in the link. All we really know is that the two have
+ distinct dictionaries with distinct types in them, and at least this way
+ they are all represented, any any symbols, variables etc referring to
+ those types are accurately stored.
+
+ (As a side-effect this also fixes a use-after-free and double-free when
+ errors are found during variable or symbol emission.)
+
+ Use the opportunity to prevent a couple of sources of problems, to wit
+ changing the active CU mappings when a link has already been done
+ (no effect on ld, which doesn't use CU mappings at all), and causing
+ multiple consecutive ctf_link's to have the same net effect as just
+ doing the last one (no effect on ld, which only ever does one
+ ctf_link) rather than having the links be a sort of half-incremental
+ not-really-intended mess.
+
+ libctf/ChangeLog:
+
+ PR libctf/29242
+ * ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New.
+ * ctf-dedup.c (ctf_dedup_emit_type): Set it.
+ * ctf-link.c (ctf_link_add_ctf_internal): Set the input
+ CU name uniquely when clashes are found.
+ (ctf_link_add): Document what repeated additions do.
+ (ctf_new_per_cu_name): New, come up with a consistent
+ name for a new per-CU dict.
+ (ctf_link_deduplicating): Use it.
+ (ctf_create_per_cu): Use it, and ctf_link_in_out, and set
+ ctf_link_in_out properly. Don't overwrite per-CU dicts with
+ per-CU dicts relating to different inputs.
+ (ctf_link_add_cu_mapping): Prevent per-CU mappings being set up
+ if we already have per-CU outputs.
+ (ctf_link_one_variable): Adjust ctf_link_per_cu call.
+ (ctf_link_deduplicating_one_symtypetab): Likewise.
+ (ctf_link_empty_outputs): New, delete all the ctf_link_outputs
+ and blank out ctf_link_in_out on the corresponding inputs.
+ (ctf_link): Clarify the effect of multiple ctf_link calls.
+ Empty ctf_link_outputs if it already exists rather than
+ having the old output leak into the new link. Fix a variable
+ name.
+ * testsuite/config/default.exp (AR): Add.
+ (OBJDUMP): Likewise.
+ * testsuite/libctf-regression/libctf-repeat-cu.exp: New test.
+ * testsuite/libctf-regression/libctf-repeat-cu*: Main program,
+ library, and expected results for the test.
+
+2022-06-21 Kevin Buettner <kevinb@redhat.com>
+
+ Document how GDB searches for files when using -s, -e, and -se options
+ GDB's documentation of the 'file' command says:
+
+ If you do not specify a directory and the file is not found in the
+ GDB working directory, GDB uses the environment variable PATH as a
+ list of directories to search, just as the shell does when looking
+ for a program to run.
+
+ The same is true for files specified via commandline options -s, -e,
+ and -se.
+
+ This commit adds a cross reference to the file command for these options.
+
+2022-06-21 Nick Clifton <nickc@redhat.com>
+
+ Binutils support for dwarf-5 (location and range lists related)
+ * dwarf.h (struct debug_info): Add rnglists_base field.
+ * dwarf.c (read_and_display_attr_value): Read attribute DW_AT_rnglists_base.
+ (display_debug_rnglists_list): While handling DW_RLE_base_addressx,
+ DW_RLE_startx_endx, DW_RLE_startx_length items, pass the proper parameter
+ value to fetch_indexed_addr(), i.e. fetch the proper entry in .debug_addr section.
+ (display_debug_ranges): Add rnglists_base to the .debug_rnglists base address.
+ (load_separate_debug_files): Load .debug_addr section, if exists.
+
+ Default to disabling the linker warnings about execstack and RWX segments if the target is the HPPA architecture.
+ PR 29263
+ * configure.ac (ac_default_ld_warn_execstack): Default to 'no' for
+ HPPA targets.
+ (ac_default_ld_warn_rwx_segments): Likewise.
+ * configure: Regenerate.
+ * testsuite/ld-elf/elf.exp: Add the --warn-execstack command line
+ option to the command line when running execstack tests for the
+ HPPA target.
+
+2022-06-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-20 Tom Tromey <tromey@adacore.com>
+
+ Move finish_print out of value_print_options
+ 'finish_print' does not really belong in value_print_options -- this
+ is consulted only when deciding whether or not to print a value, and
+ never during the course of printing. This patch removes it from the
+ structure and makes it a static global in infcmd.c instead.
+
+ Tested on x86-64 Fedora 34.
+
+2022-06-20 Alan Modra <amodra@gmail.com>
+
+ PR29262, memory leak in pr_function_type
+ PR 29262
+ * prdbg.c (pr_function_type): Free "s" on failure path.
+
+ PR29261, memory leak in parse_stab_struct_fields
+ PR 29261
+ * stabs.c (parse_stab_struct_fields): Free "fields" on failure path.
+
+2022-06-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-18 Tom Tromey <tom@tromey.com>
+
+ Fix assertion failure in copy_type
+ PR exp/20630 points out a simple way to cause an assertion failure in
+ copy_type -- but this was found in the wild a few times as well.
+
+ copy_type only works for objfile-owned types, but there isn't a deep
+ reason for this. This patch fixes the bug by updating copy_type to
+ work for any sort of type.
+
+ Better would perhaps be to finally implement type GC, but I still
+ haven't attempted this.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20630
+
+2022-06-18 Tomoaki Kawada <kawada@kmckk.co.jp>
+
+ Fix the sorting algorithm for reloc entries
+ The optimized insertion sort algorithm in `elf_link_adjust_relocs`
+ incorrectly assembled "runs" from unsorted entries and inserted them to an
+ already-sorted prefix, breaking the loop invariants of insertion sort.
+ This commit updates the run assembly loop to break upon encountering a
+ non-monotonic change in the sort key.
+
+ PR 29259
+ bfd/
+ * elflink.c (elf_link_adjust_relocs): Ensure run being inserted
+ is sorted.
+ ld/
+ * testsuite/ld-elf/pr29259.d,
+ * testsuite/ld-elf/pr29259.s,
+ * testsuite/ld-elf/pr29259.t: New test.
+
+2022-06-18 Enze Li <enze.li@hotmail.com>
+
+ gdb/python: Export nibbles to python layer
+ This patch makes it possible to allow Value.format_string() to return
+ nibbles output.
+
+ When we set the parameter of nibbles to True, we can achieve the
+ displaying binary values in groups of every four bits.
+
+ Here's an example:
+ (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True))
+ 0100 1100 1110
+ (gdb)
+
+ Note that the parameter nibbles is only useful if format='t' is also used.
+
+ This patch also includes update to the relevant testcase and
+ documentation.
+
+ Tested on x86_64 openSUSE Tumbleweed.
+
+2022-06-18 Enze Li <enze.li@hotmail.com>
+
+ gdb/doc: Documentation for the new print command
+ Document the new command "print nibbles" and add a NEWS entry.
+
+2022-06-18 Enze Li <enze.li@hotmail.com>
+
+ gdb: Add new 'print nibbles' feature
+ Make an introduction of a new print setting that can be set by 'set
+ print nibbles [on|off]'. The default value if OFF, which can be changed
+ by user manually. Of course, 'show print nibbles' is also included in
+ the patch.
+
+ The new feature displays binary values by group, with four bits per
+ group. The motivation for this work is to enhance the readability of
+ binary values.
+
+ Here's a GDB session before this patch is applied.
+ (gdb) print var_a
+ $1 = 1230
+ (gdb) print/t var_a
+ $2 = 10011001110
+
+ With this patch applied, we can use the new print setting to display the
+ new form of the binary values.
+ (gdb) print var_a
+ $1 = 1230
+ (gdb) print/t var_a
+ $2 = 10011001110
+ (gdb) set print nibbles on
+ (gdb) print/t var_a
+ $3 = 0100 1100 1110
+
+ Tested on x86_64 openSUSE Tumbleweed.
+
+2022-06-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-17 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: NEWS: Move LoongArch gdbserver to the correct section
+ commit e5ab6af52d38 ("gdbserver: Add LoongArch/Linux support")
+ was merged into the master since GDB 12, so we should put the
+ news in the "Changes since GDB 12" section.
+
+ Thanks Tom Tromey for your correction [1], sorry for that.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-June/190122.html
+
+2022-06-17 Alan Modra <amodra@gmail.com>
+
+ PR29256, memory leak in obj_elf_section_name
+ When handling section names in quotes obj_elf_section_name calls
+ demand_copy_C_string, which puts the name on the gas notes obstack.
+ Such strings aren't usually freed, since obstack_free frees all more
+ recently allocated objects as well as its arg. When handling
+ non-quoted names, obj_elf_section_name mallocs the name. Due to the
+ mix of allocation strategies it isn't possible for callers to free
+ names, if that was desirable. Partially fix this by always creating
+ names on the obstack, which is more efficient anyway. (You still
+ can't obstack_free on error paths due to the xtensa
+ tc_canonicalize_section_name.) Also remove a couple of cases where
+ the name is dup'd for no good reason as far as I know.
+
+ PR 29256
+ * config/obj-elf.c (obj_elf_section_name): Create name on notes
+ obstack.
+ (obj_elf_attach_to_group): Don't strdup group name.
+ (obj_elf_section): Likewise.
+ (obj_elf_vendor_attribute): Use xmemdup0 rather than xstrndup.
+
+2022-06-17 Alan Modra <amodra@gmail.com>
+
+ PR29255, memory leak in make_tempdir
+ PR 29255
+ * bucomm.c (make_tempdir, make_tempname): Free template on all
+ failure paths.
+
+ PR29254, memory leak in stab_demangle_v3_arg
+ PR 29254
+ * stabs.c (stab_demangle_v3_arg): Free dt on failure path.
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Fix GDB build with GCC 4.8 & 4.9
+ With gcc 4.8/4.9, we run into this build failure (and other similar
+ ones):
+
+ /home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’
+ struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN};
+ ^
+
+ The issue is that at around the GCC 4.8/4.9 era, a default member
+ initializer prevented the struct from being an aggregate, so you
+ cannot use aggregate initialization on them. That rule changed after
+ GCC 4.9 and GCC 5 & later uses new rules.
+
+ Fix this by not using aggregate initialization for struct line_offset.
+ The default member initization already leaves line_offset as {0,
+ LINE_OFFSET_UNKNOWN}, so initialization to those values can just go
+ away. The remaining cases are of the form {0, LINE_OFFSET_NONE}, and
+ those cases can be better rewritten to delay setting the sign field
+ until we know we have a valid offset.
+
+ Change-Id: I0506ea4a83c5fa2f15e159569db68b3b0a7509b4
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Convert set_location_spec_string to a method
+ This converts set_location_spec_string to a method of location_spec,
+ and makes the location_spec::as_string field protected, renaming it to
+ m_as_string along the way.
+
+ Change-Id: Iccfb1654e9fa7808d0512df89e775f9eacaeb9e0
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Convert location_spec_to_string to a method
+ This converts location_spec_to_string to a method of location_spec,
+ simplifying the code using it, as it no longer has to use
+ std::unique_ptr::get().
+
+ Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Convert location_spec_type to a method
+ This converts location_spec_type to location_spec::type().
+
+ Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Convert location_spec_empty_p to a method
+ This converts location_spec_empty_p to a method of location_spec,
+ simplifying users, as they no longer have to use
+ std::unique_ptr::get().
+
+ Change-Id: I83381a729896f12e1c5a1b4d6d4c2eb1eb6582ff
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Eliminate copy_location_spec
+ copy_location_spec is just a wrapper around location_spec::clone(), so
+ remove it and call clone() directly. This simplifies users, as they
+ no longer have to use std::unique_ptr::get().
+
+ Change-Id: I8ce8658589460b98888283b306b315a5b8f73976
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ Eliminate the two-level data structures behind location_specs
+ Currently, there's the location_spec hierarchy, and then some
+ location_spec subclasses have their own struct type holding all their
+ data fields.
+
+ I.e., there is this:
+
+ location_spec
+ explicit_location_spec
+ linespec_location_spec
+ address_location_spec
+ probe_location_spec
+
+ and then these separate types:
+
+ explicit_location
+ linespec_location
+
+ where:
+
+ explicit_location_spec
+ has-a explicit_location
+ linespec_location_spec
+ has-a linespec_location
+
+ This patch eliminates explicit_location and linespec_location,
+ inlining their members in the corresponding location_spec type.
+
+ The location_spec subclasses were the ones currently defined in
+ location.c, so they are moved to the header. Since the definitions of
+ the classes are now visible, we no longer need location_spec_deleter.
+
+ Some constructors that are used for cloning location_specs, like:
+
+ explicit explicit_location_spec (const struct explicit_location *loc)
+
+ ... were converted to proper copy ctors.
+
+ In the process, initialize_explicit_location is eliminated, and some
+ functions that returned the "data type behind a locspec", like
+ get_linespec_location are converted to downcast functions, like
+ as_linespec_location_spec.
+
+ Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
+
+2022-06-17 Pedro Alves <pedro@palves.net>
+
+ event_location -> location_spec
+ Currently, GDB internally uses the term "location" for both the
+ location specification the user input (linespec, explicit location, or
+ an address location), and for actual resolved locations, like the
+ breakpoint locations, or the result of decoding a location spec to
+ SaLs. This is expecially confusing in the breakpoints module, as
+ struct breakpoint has these two fields:
+
+ breakpoint::location;
+ breakpoint::loc;
+
+ "location" is the location spec, and "loc" is the resolved locations.
+
+ And then, we have a method called "locations()", which returns the
+ resolved locations as range...
+
+ The location spec type is presently called event_location:
+
+ /* Location we used to set the breakpoint. */
+ event_location_up location;
+
+ and it is described like this:
+
+ /* The base class for all an event locations used to set a stop event
+ in the inferior. */
+
+ struct event_location
+ {
+
+ and even that is incorrect... Location specs are used for finding
+ actual locations in the program in scenarios that have nothing to do
+ with stop events. E.g., "list" works with location specs.
+
+ To clean all this confusion up, this patch renames "event_location" to
+ "location_spec" throughout, and then all the variables that hold a
+ location spec, they are renamed to include "spec" in their name, like
+ e.g., "location" -> "locspec". Similarly, functions that work with
+ location specs, and currently have just "location" in their name are
+ renamed to include "spec" in their name too.
+
+ Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
+
+2022-06-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with -Werror=format-truncation
+ gprofng/ChangeLog
+ 2022-06-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * configure.ac: Remove -Wno-format-truncation.
+ * src/Makefile.am: Likewise.
+ * configure: Rebuild.
+ * src/Makefile.in: Rebuild.
+ * common/hwctable.c: Fix -Werror=format-truncation errors.
+ * src/ipc.cc: Likewise.
+ * src/parse.cc: Likewise.
+
+2022-06-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix have_mpx test
+ When testing on openSUSE Leap 15.4 I ran into this FAIL:
+ ...
+ FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
+ ...
+ and likewise for all the other mpx tests.
+
+ The problem is that have_mpx is supposed to return 0, but it doesn't because
+ it tries to match this output:
+ ...
+ builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
+ No MPX support^M
+ No MPX support^M
+ ...
+ using:
+ ...
+ && ![string equal $output "No MPX support\r\n"]]
+ ...
+
+ Fix this by matching using a regexp instead.
+
+ Tested on x86_64-linux.
+
+2022-06-16 Alan Modra <amodra@gmail.com>
+
+ use of uninitialised value in input_file_open
+ Triggered by a file containing just "#N" or "#A". fgets when hitting
+ EOF before reading anything returns NULL and does not write to buf.
+ strchr (buf, '\n') then is reading from uninitialised memory.
+
+ * input-file.c (input_file_open): Don't assume buf contains
+ zero string terminator when fgets returns NULL.
+
+2022-06-16 Alan Modra <amodra@gmail.com>
+
+ Always free matching vector from bfd_check_format_matches
+ At least one place calling list_matching_formats failed to free the
+ "matching" vector from bfd_check_format_matches afterwards. Fix that
+ by calling free inside list_matching_formats.
+
+ binutils/
+ * bucomm.c (list_matching_formats): Free arg.
+ * addr2line.c (process_file): Adjust to suit.
+ * ar.c (open_inarch, ranlib_touch): Likewise.
+ * coffdump.c (main): Likewise.
+ * nm.c (display_archive, display_file): Likewise.
+ * objcopy.c (copy_file): Likewise.
+ * objdump.c (display_object_bfd): Likewise.
+ * size.c (display_bfd): Likewise.
+ * srconv.c (main): Likewise.
+ ld/
+ * ldlang.c (load_symbols): Free "matching".
+
+2022-06-16 Alan Modra <amodra@gmail.com>
+
+ Revert "Revert "Fix fbsd core matching""
+ This reverts commit 476288fa2bddecf0f0e13dee826a076309bf01fe.
+
+2022-06-16 Alan Modra <amodra@gmail.com>
+
+ Restore readelf -wF
+ Commit 94585d6d4495 resulted in readelf -wF failing with
+ Unrecognized debug letter option 'F'
+
+ binutils/
+ * dwarf.c (debug_dump_long_opts): Add letter.
+ (debug_option_table): New, replacing..
+ (opts_table, letter_table): ..these.
+ (dwarf_select_sections_by_names): Adjust to suit. Set
+ do_debug_frames outside of loop.
+ (dwarf_select_sections_by_letters): Similarly.
+ gas/
+ * testsuite/gas/i386/ehinterp.d: Use readelf -wF.
+
+2022-06-16 Alan Modra <amodra@gmail.com>
+
+ PR29250, readelf erases CIE initial register state
+ PR 29250
+ binutils/
+ * dwarf.c (display_debug_frames): Set col_type[reg] on sizing
+ pass over FDE to cie->col_type[reg] if CIE specifies reg.
+ Handle DW_CFA_restore and DW_CFA_restore_extended on second
+ pass using the same logic. Remove unnecessary casts. Don't
+ call frame_need_space on second pass over FDE.
+ gas/
+ * testsuite/gas/i386/ehinterp.d,
+ * testsuite/gas/i386/ehinterp.s: New test.
+ * testsuite/gas/i386/i386.exp: Run it.
+
+2022-06-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-15 Sergei Trofimovich <siarheit@google.com>
+
+ sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184]
+ Noticed format mismatch when attempted to build gdb on i686-linux-gnu
+ in --enable-64-bit-bfd mode:
+
+ sim/../../sim/cris/sim-if.c:576:28:
+ error: format '%lx' expects argument of type 'long unsigned int',
+ but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=]
+ 576 | sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx",
+ | ^~~~~~~~~~~~~~~~~~~
+ 577 | interp_load_addr, interpsiz);
+ | ~~~~~~~~~
+ | |
+ | bfd_size_type {aka long long unsigned int}
+
+ While at it fixed format string for time-related types.
+
+2022-06-15 Tom Tromey <tromey@adacore.com>
+
+ Check for listeners in emit_exiting_event
+ I noticed that emit_exiting_event does not check whether there are any
+ listeners before creating the event object. All other event emitters
+ do this, so this patch updates this one as well.
+
+2022-06-15 Tom Tromey <tom@tromey.com>
+
+ Add to documentation of Python 'dont_repeat' method
+ PR python/28533 points out that the Python 'dont_repeat' documentation
+ is a bit ambiguous about when the method ought to be called. This
+ patch spells it out.
+
+2022-06-15 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Make sp alias for one of the other stack pointers
+ For Cortex-M targets, SP register is never detached from msp or
+ psp, it always has the same value as one of them. Let GDB treat
+ ARM_SP_REGNUM as an alias similar to what is done in hardware.
+
+2022-06-15 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Track msp and psp
+ For Arm Cortex-M33 with security extensions, there are 4 different
+ stack pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible
+ with earlier Cortex-M derivates, the msp and psp registers are
+ aliases for one of the 4 real stack pointer registers.
+
+ These are the combinations that exist:
+ sp -> msp -> msp_s
+ sp -> msp -> msp_ns
+ sp -> psp -> psp_s
+ sp -> psp -> psp_ns
+
+ This means that when the GDB client is to show the value of "msp",
+ the value should always be equal to either "msp_s" or "msp_ns".
+ Same goes for "psp".
+
+ To add a bit more context; GDB does not really use the register msp
+ (or psp) internally, but they are part of the set of registers which
+ are provided by the target.xml file. As a result, they will be part
+ of the set of registers printed by the "info r" command.
+
+ Without this particular patch, GDB will hit the assert in the bottom
+ of arm_cache_get_sp_register function.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121
+
+2022-06-15 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Fetch initial sp value prior to compare
+ For Arm Cortex-M33 with security extensions, there are 4 different
+ stack pointers (msp_s, msp_ns, psp_s, psp_ns). In order to
+ identify the active one, compare the values of the different
+ stacks. The value of the initial sp register needs to be fetched to
+ perform this comparison.
+
+2022-06-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: unify two dis_asm_read_memory functions in disasm.c
+ After the recent restructuring of the disassembler code, GDB has ended
+ up with two identical class static functions, both called
+ dis_asm_read_memory, with identical implementations.
+
+ My first thought was to move these out of their respective classes,
+ and just make them global functions, then I'd only need a single
+ copy.
+
+ And maybe that's the right way to go. But I disliked that by doing
+ that I loose the encapsulation of the method with the corresponding
+ disassembler class.
+
+ So, instead, I placed the static method into its own class, and had
+ both the gdb_non_printing_memory_disassembler and gdb_disassembler
+ classes inherit from this new class as an additional base-class.
+
+ In terms of code generated, I don't think there's any significant
+ difference with this approach, but I think this better reflects how
+ the function is closely tied to the disassembler.
+
+ There should be no user visible changes after this commit.
+
+2022-06-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: refactor the non-printing disassemblers
+ This commit started from an observation I made while working on some
+ other disassembler patches, that is, that the function
+ gdb_buffered_insn_length, is broken ... sort of.
+
+ I noticed that the gdb_buffered_insn_length function doesn't set up
+ the application data field if the disassemble_info structure.
+
+ Further, I noticed that some architectures, for example, ARM, require
+ that the application_data field be set, see gdb_print_insn_arm in
+ arm-tdep.c.
+
+ And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
+ likely crash. Which is why I said only "sort of" broken. Right now
+ we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
+ broken yet?
+
+ Anyway to prove to myself that there was a problem here I extended the
+ disassembler self tests in disasm-selftests.c to include a test of
+ gdb_buffered_insn_length. As I run the test for all architectures, I
+ do indeed see GDB crash for ARM.
+
+ To fix this we need gdb_buffered_insn_length to create a disassembler
+ that inherits from gdb_disassemble_info, but we also need this new
+ disassembler to not print anything.
+
+ And so, I introduce a new gdb_non_printing_disassembler class, this is
+ a disassembler that doesn't print anything to the output stream.
+
+ I then observed that both ARC and S12Z also create non-printing
+ disassemblers, but these are slightly different. While the
+ disassembler in gdb_non_printing_disassembler reads the instruction
+ from a buffer, the ARC and S12Z disassemblers read from target memory
+ using target_read_code.
+
+ And so, I further split gdb_non_printing_disassembler into two
+ sub-classes, gdb_non_printing_memory_disassembler and
+ gdb_non_printing_buffer_disassembler.
+
+ The new selftests now pass, but otherwise, there should be no user
+ visible changes after this commit.
+
+2022-06-15 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: implement the print_insn extension language hook
+ This commit extends the Python API to include disassembler support.
+
+ The motivation for this commit was to provide an API by which the user
+ could write Python scripts that would augment the output of the
+ disassembler.
+
+ To achieve this I have followed the model of the existing libopcodes
+ disassembler, that is, instructions are disassembled one by one. This
+ does restrict the type of things that it is possible to do from a
+ Python script, i.e. all additional output has to fit on a single line,
+ but this was all I needed, and creating something more complex would,
+ I think, require greater changes to how GDB's internal disassembler
+ operates.
+
+ The disassembler API is contained in the new gdb.disassembler module,
+ which defines the following classes:
+
+ DisassembleInfo
+
+ Similar to libopcodes disassemble_info structure, has read-only
+ properties: address, architecture, and progspace. And has methods:
+ __init__, read_memory, and is_valid.
+
+ Each time GDB wants an instruction disassembled, an instance of
+ this class is passed to a user written disassembler function, by
+ reading the properties, and calling the methods (and other support
+ methods in the gdb.disassembler module) the user can perform and
+ return the disassembly.
+
+ Disassembler
+
+ This is a base-class which user written disassemblers should
+ inherit from. This base class provides base implementations of
+ __init__ and __call__ which the user written disassembler should
+ override.
+
+ DisassemblerResult
+
+ This class can be used to hold the result of a call to the
+ disassembler, it's really just a wrapper around a string (the text
+ of the disassembled instruction) and a length (in bytes). The user
+ can return an instance of this class from Disassembler.__call__ to
+ represent the newly disassembled instruction.
+
+ The gdb.disassembler module also provides the following functions:
+
+ register_disassembler
+
+ This function registers an instance of a Disassembler sub-class
+ as a disassembler, either for one specific architecture, or, as a
+ global disassembler for all architectures.
+
+ builtin_disassemble
+
+ This provides access to GDB's builtin disassembler. A common
+ use case that I see is augmenting the existing disassembler output.
+ The user code can call this function to have GDB disassemble the
+ instruction in the normal way. The user gets back a
+ DisassemblerResult object, which they can then read in order to
+ augment the disassembler output in any way they wish.
+
+ This function also provides a mechanism to intercept the
+ disassemblers reads of memory, thus the user can adjust what GDB
+ sees when it is disassembling.
+
+ The included documentation provides a more detailed description of the
+ API.
+
+ There is also a new CLI command added:
+
+ maint info python-disassemblers
+
+ This command is defined in the Python gdb.disassemblers module, and
+ can be used to list the currently registered Python disassemblers.
+
+2022-06-15 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: add extension language print_insn hook
+ This commit is setup for the next commit.
+
+ In the next commit I will add a Python API to intercept the print_insn
+ calls within GDB, each print_insn call is responsible for
+ disassembling, and printing one instruction. After the next commit it
+ will be possible for a user to write Python code that either wraps
+ around the existing disassembler, or even, in extreme situations,
+ entirely replaces the existing disassembler.
+
+ This commit does not add any new Python API.
+
+ What this commit does is put the extension language framework in place
+ for a print_insn hook. There's a new callback added to 'struct
+ extension_language_ops', which is then filled in with nullptr for Python
+ and Guile.
+
+ Finally, in the disassembler, the code is restructured so that the new
+ extension language function ext_lang_print_insn is called before we
+ delegate to gdbarch_print_insn.
+
+ After this, the next commit can focus entirely on providing a Python
+ implementation of the new print_insn callback.
+
+ There should be no user visible change after this commit.
+
+2022-06-15 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: add new base class to gdb_disassembler
+ The motivation for this change is an upcoming Python disassembler API
+ that I would like to add. As part of that change I need to create a
+ new disassembler like class that contains a disassemble_info and a
+ gdbarch. The management of these two objects is identical to how we
+ manage these objects within gdb_disassembler, so it might be tempting
+ for my new class to inherit from gdb_disassembler.
+
+ The problem however, is that gdb_disassembler has a tight connection
+ between its constructor, and its print_insn method. In the
+ constructor the ui_file* that is passed in is replaced with a member
+ variable string_file*, and then in print_insn, the contents of the
+ member variable string_file are printed to the original ui_file*.
+
+ What this means is that the gdb_disassembler class has a tight
+ coupling between its constructor and print_insn; the class just isn't
+ intended to be used in a situation where print_insn is not going to be
+ called, which is how my (upcoming) sub-class would need to operate.
+
+ My solution then, is to separate out the management of the
+ disassemble_info and gdbarch into a new gdb_disassemble_info class,
+ and make this class a parent of gdb_disassembler.
+
+ In arm-tdep.c and mips-tdep.c, where we used to cast the
+ disassemble_info->application_data to a gdb_disassembler, we can now
+ cast to a gdb_disassemble_info as we only need to access the gdbarch
+ information.
+
+ Now, my new Python disassembler sub-class will still want to print
+ things to an output stream, and so we will want access to the
+ dis_asm_fprintf functionality for printing.
+
+ However, rather than move this printing code into the
+ gdb_disassemble_info base class, I have added yet another level of
+ hierarchy, a gdb_printing_disassembler, thus the class structure is
+ now:
+
+ struct gdb_disassemble_info {};
+ struct gdb_printing_disassembler : public gdb_disassemble_info {};
+ struct gdb_disassembler : public gdb_printing_disassembler {};
+
+ In a later commit my new Python disassembler will inherit from
+ gdb_printing_disassembler.
+
+ The reason for adding the additional layer to the class hierarchy is
+ that in yet another commit I intend to rewrite the function
+ gdb_buffered_insn_length, and to do this I will be creating yet more
+ disassembler like classes, however, these will not print anything,
+ thus I will add a gdb_non_printing_disassembler class that also
+ inherits from gdb_disassemble_info. Knowing that that change is
+ coming, I've gone with the above class hierarchy now.
+
+ There should be no user visible changes after this commit.
+
+2022-06-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: convert gdbpy_err_fetch to use gdbpy_ref
+ Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
+ removes the need for manual reference count management, and allows the
+ destructor to be removed.
+
+ There should be no functional change after this commit.
+
+ I think this cleanup is worth doing on its own, however, in a later
+ commit I will want to copy instances of gdbpy_err_fetch, and switching
+ to using gdbpy_ref means that I can rely on the default copy
+ constructor, without having to add one that handles the reference
+ counts, so this is good preparation for that upcoming change.
+
+2022-06-15 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop print_operand_value()'s "hex" parameter
+ For quite some time all callers have been passing 1 / true. While there
+ fold the final oappend_with_style() calls.
+
+2022-06-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build for gcc < 11
+ When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into:
+ ...
+ In file included from ../bfd/bfd.h:46:0,
+ from gdb/defs.h:37,
+ from gdb/debuginfod-support.c:19:
+ gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’:
+ gdb/../include/diagnostics.h:42:3: error: unknown option after \
+ ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
+ _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option))
+ ^
+ gdb/../include/diagnostics.h:80:3: note: in expansion of macro \
+ ‘DIAGNOSTIC_IGNORE’
+ DIAGNOSTIC_IGNORE ("-Wstringop-overread")
+ ^~~~~~~~~~~~~~~~~
+ gdb/debuginfod-support.c:201:4: note: in expansion of macro \
+ ‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’
+ DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
+ ^
+ ...
+
+ The problem is that the warning -Wstringop-overread has been introduced for
+ gcc 11, and we can only tell gcc to ignore if it knows about it.
+
+ Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in
+ diagnostics.c with '#if __GNUC__ >= 11'.
+
+ Tested on x86_64-linux, by completing a build.
+
+2022-06-15 Alan Modra <amodra@gmail.com>
+
+ PR29230, segv in lookup_symbol_in_variable_table
+ The PR23230 testcase uses indexed strings without specifying
+ SW_AT_str_offsets_base. In this case we left u.str with garbage (from
+ u.val) which then led to a segfault when attempting to access the
+ string. Fix that by clearing u.str. The patch also adds missing
+ sanity checks in the recently committed read_indexed_address and
+ read_indexed_string functions.
+
+ PR 29230
+ * dwarf2.c (read_indexed_address): Return uint64_t. Sanity check idx.
+ (read_indexed_string): Use uint64_t for str_offset. Sanity check idx.
+ (read_attribute_value): Clear u.str for indexed string forms when
+ DW_AT_str_offsets_base is not yet read or missing.
+
+2022-06-15 Mark Wielaard <mark@klomp.org>
+
+ gdb: Always suppress stringop-overread warning in debuginfod-support.c
+ Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11
+ on hppa produces a spurious warning for stringop-overread in
+ debuginfod_is_enabled for url_view. Just always suppress it on all
+ arches.
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=29198
+
+ gdb/ChangeLog:
+
+ * debuginfod-support.c (debuginfod_is_enabled): Always use
+ DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.
+
+2022-06-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng docs: provide help for <rate> == <interval>
+ The help message from 'gprofng collect app -h', in
+ the section on <rate> == <interval>, had a dangling
+ reference to a non-existent manpage. Provide basic
+ info, including reasons for caution.
+
+ gprofng docs: mention HTML / PDF in the gprofng README
+ The HTML and PDF formats are described in the gprofng tutorial (info
+ topic "Other Document Formats"). In addition, describe them in the
+ README because: they are important; they are easily searchable; and the
+ README is primarily oriented to the person who is installing gprofng,
+ who may differ from the person who follows a user tutorial.
+
+2022-06-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with -Werror=format-security
+ gprofng/ChangeLog
+ 2022-06-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/28968
+ * src/src/Hist_data.cc (print_row): Make param const.
+ * src/src/Hist_data.h (print_row): Likewise.
+ * src/src/Print.h: Remove unused functions and variables.
+ * src/Print.cc: Fix -Werror=format-security errors.
+ * src/parse.cc: Likewise.
+
+2022-06-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp
+ When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with
+ python 3.4, I occasionally run into:
+ ...
+ Expecting: ^(-pycmd dct[^M
+ ]+)?(\^done,result={hello="world",times="42"}[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -pycmd dct^M
+ ^done,result={times="42",hello="world"}^M
+ (gdb) ^M
+ FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output)
+ ...
+
+ The problem is that the data type used here in py-mi-cmd.py:
+ ...
+ elif argv[0] == "dct":
+ return {"result": {"hello": "world", "times": 42}}
+ ...
+ is a dictionary, and only starting version 3.6 are dictionaries insertion
+ ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a
+ fixed order.
+
+ Fix this by allowing the alternative order.
+
+ Tested on x86_64-linux.
+
+2022-06-14 Tom Tromey <tromey@adacore.com>
+
+ Implement lazy FPU initialization for ravenscar
+ Some ravenscar runtimes implement lazy FPU handling. On these
+ runtimes, the FPU is only initialized when a task tries to use it.
+ Furthermore, the FP registers aren't automatically saved on a task
+ switch -- instead, the save is deferred until the new task tries to
+ use the FPU. Furthermore, each task's context area has a flag
+ indicating whether the FPU has been initialized for this task.
+
+ This patch teaches GDB to understand this implementation. When
+ fetching or storing registers, GDB now checks to see whether the live
+ FP registers should be used. If not, the task's saved FP registers
+ will be used if the task has caused FPU initialization.
+
+ Currently only AArch64 uses this code. bb-runtimes implements this
+ for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.
+
+2022-06-14 Tom Tromey <tromey@adacore.com>
+
+ Reimplement ravenscar registers using tables
+ Currently, the ravenscar-thread implementation for each architecture
+ is written by hand. However, these are actually written by
+ copy-paste. It seems better to switch to a table-driven approach.
+
+ The previous code also fetched all registers whenever any register was
+ requested. This is corrected in the new implementation.
+
+2022-06-14 Tom Tromey <tromey@adacore.com>
+
+ Fix bugs in aarch64-ravenscar-thread.c
+ We found a few bugs in aarch64-ravenscar-thread.c.
+
+ First, some of the register offsets were incorrect. The "bb-runtimes"
+ file for this runtime had the wrong offsets in comments, which GDB
+ took to be correct. However, those comments didn't account for
+ alignment. This patch adjusts the offsets.
+
+ Next, the "FPU Saved field" is not a register -- it is an
+ implementation detail of the runtime. This is removed.
+
+ Finally, I think the FP registers are actually named V0-V31, and the
+ "Q" names are pseudo-registers. This patch fixes the comment.
+
+2022-06-14 Tom Tromey <tromey@adacore.com>
+
+ Allow 'interrupt -a' in all-stop mode
+ PR gdb/17160 points out that "interrupt -a" errors in all-stop mode,
+ but there's no good reason for this. This patch removes the error.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17160
+
+2022-06-14 Youling Tang <tangyouling@loongson.cn>
+
+ gdbserver: Add LoongArch/Linux support
+ Implement LoongArch/Linux support, including XML target description
+ handling based on features determined, GPR regset support, and software
+ breakpoint handling.
+
+ In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
+ and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
+ set to yes.
+
+ With this patch on LoongArch:
+
+ $ make check-gdb TESTS="gdb.server/server-connect.exp"
+ [...]
+ # of expected passes 18
+ [...]
+
+2022-06-14 Tom de Vries <tdevries@suse.de>
+
+ Revert "Fix fbsd core matching"
+ This reverts commit a7e29f797cecd5a2f73c27838b09eae1f1b6c657.
+
+ I accidentally pushed this, so revert.
+
+2022-06-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp
+ With gcc-12 and target board unix/-m32, we run into:
+ ...
+ (gdb) ^M
+ Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
+ ]+)?(\^done,name="A_String_Access",numchild="1",.*[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -var-create A_String_Access * A_String_Access^M
+ ^error,msg="Value out of range."^M
+ (gdb) ^M
+ FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
+ ...
+
+ What happens is easier to understand if we take things out of the mi context:
+ ...
+ $ gdb -q -batch \
+ outputs/gdb.ada/mi_var_access/mi_access \
+ -ex "b mi_access.adb:19" \
+ -ex run \
+ -ex "p A_String_Access"
+ ...
+ Breakpoint 1, mi_access () at mi_access.adb:19
+ 19 A_String : String (3 .. 5) := "345"; -- STOP
+ $1 = (pck.string_access) <error reading variable: Value out of range.>
+ ...
+ while with target board unix we have instead:
+ ...
+ $1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks>
+ ...
+
+ The var-create command samples the value of the variable at a location where
+ the variable is not yet initialized, and with target board unix we
+ accidentally hit a valid address, but with target board unix/-m32 that's not
+ the case.
+
+ Fix the FAIL by accepting the error message.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28464
+
+2022-06-14 Alan Modra <amodra@gmail.com>
+
+ Fix fbsd core matching
+ On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote:
+ > On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote:
+ > > Hi,
+ > >
+ > > With an --enable-targets=all build and target board unix/-m32 I run into a
+ > > FAIL in test-case gdb.base/corefile.exp:
+ > > ...
+ > > (gdb) file outputs/gdb.base/corefile/corefile^M
+ > > Reading symbols from outputs/gdb.base/corefile/corefile...^M
+ > > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M
+ > > warning: core file may not match specified executable file.^M
+ > > [New LWP 12011]^M
+ > > Core was generated by `outputs/gdb.base/corefile/co'.^M
+ > > Program terminated with signal SIGABRT, Aborted.^M
+ > > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
+ > > ...
+ > >
+ > > The warning is there because of this mismatch between core and exec:
+ > > ...
+ > > (gdb) p core_bfd->xvec
+ > > $3 = (const struct bfd_target *) 0x20112a0 <i386_elf32_fbsd_vec>
+ > > (gdb) p exec_bfd->xvec
+ > > $4 = (const struct bfd_target *) 0x2010b00 <i386_elf32_vec>
+ > > ...
+ > >
+ > > In the exec case, the detected architecture is i386_elf32_vec because this bit
+ > > of code in elfcode.h:elf_object_p():
+ > > ...
+ > > if (ebd->elf_machine_code != EM_NONE
+ > > && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi
+ > > && ebd->elf_osabi != ELFOSABI_NONE)
+ > > goto got_wrong_format_error;
+ > > ...
+ > > prevents i386_elf32_fbsd from matching.
+ > >
+ > > Fix the core matching by copying that code to elfcore.h:elf_core_file_p().
+ > >
+ > > Tested on x86_64-linux.
+ > >
+ > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227
+ > >
+ > > Any comments?
+
+ Looks good.
+
+ > Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over
+ > time and is a bit rotted. I suspect that all of changes made in commit 0aabe54e6222
+ > that added these lines in elfcode.h (along with several other changes) need to
+ > be applied to this function in elfcore.h, not just adding these lines.
+
+ Yes, the commit 0aabe54e6222 changes likely should go in too. I'm a
+ little wary of adding all the sanity checks to elf_core_file_p since
+ that might result in some core files not being recognised at all. For
+ example, despite the FIXME I'd guess leaving out the EI_VERSION check
+ was deliberate. The following seems reasonable to me. Please test.
+
+2022-06-14 Kavitha Natarajan <kavitha.natarajan@amd.com>
+
+ Debug support for global alias variable
+ Starting with (future) Clang 15 (since
+ https://reviews.llvm.org/D120989), Clang emits the DWARF information
+ of global alias variables as DW_TAG_imported_declaration. However,
+ GDB does not handle it. It incorrectly always reads this tag as
+ C++/Fortran imported declaration (type alias, namespace alias and
+ Fortran module). This commit adds support to handle this tag as an
+ alias variable.
+
+ This change fixes the failures in the gdb.base/symbol-alias.exp
+ testcase with current git Clang. This testcase is also updated to
+ test nested (recursive) aliases.
+
+2022-06-14 Alan Modra <amodra@gmail.com>
+
+ BFD_RELOC_MIPS_16
+ MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation,
+ since R_MIPS_16 specifies a 16-bit field in a 32-bit word.
+ BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data
+ directives, expects fixups to operate on the whole of a 16-bit word.
+
+ This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd
+ reloc that is used to generate R_MIPS_16. BFD_RELOC_16 is handled in
+ md_apply_fix for cases where the fixup can be applied at assembly
+ time. Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object
+ file relocation, and thus .half, .hword, .short and .dc.w must be
+ resolved at assembly time. BFD_RELOC_MIPS_REL16 is removed by this
+ patch since it isn't used.
+
+ PR 3243
+ PR 26542
+ * reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16.
+ * elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16.
+ * elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16.
+ * elfn32-mips.c (mips_reloc_map): Likewise.
+ * libbfd.h: Regenerate.
+ * bfd-in2.h: Regenerate.
+ gas/
+ * config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16.
+ (macro_build): Likewise.
+ (mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16.
+ (md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done.
+ ld/
+ * testsuite/ld-mips-elf/reloc-local-overflow.d,
+ * testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite.
+
+2022-06-14 Alan Modra <amodra@gmail.com>
+
+ Correct R_MIPS_16 n32 howto
+ If the howto is actually used, an all-zero dst_mask will result in
+ unchanged section contents on attempting to apply R_MIPS_16.
+
+ * elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct
+ dst_mask.
+
+2022-06-14 Alan Modra <amodra@gmail.com>
+
+ asan: applying zero offset to NULL pointer
+ * dwarf.c (fetch_indexed_string): Move initialisation of "curr"
+ and "end" after checking for missing section.
+
+2022-06-14 Alan Modra <amodra@gmail.com>
+
+ gas dwarf2dbg.c tidy
+ Make it a little more obvious that remap_debug_filename returns an
+ allocated string (that should be freed) by returning a char * rather
+ than const char *. Free a few missed cases in dwarf2dbg.c, and free
+ other memory allocated in dwarf2dbg.c. Also remove static
+ initialisation of variables and initialise in dwarf2_init instead,
+ in order to ensure gas state is saner for oss-fuzz.
+
+ * remap.c (remap_debug_filename): Remove const from return.
+ * as.h (remap_debug_filename): Update prototype.
+ * config/obj-elf.c (obj_elf_ident): Simplify free of
+ remap_debug_filename output.
+ * stabs.c (stabs_generate_asm_file): Likewise.
+ * dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't
+ initialise statically..
+ (dwarf2_init): ..do so here, along with most other static vars.
+ (assign_file_to_slot): Don't set files_allocated until we
+ succeed in allocating memory.
+ (purge_generated_debug): Add bool param, free more stuff if true.
+ (dwarf2_directive_filename): Adjust purge_generated_debug call.
+ (process_entries): Don't free line_entry here..
+ (dwarf2_cleanup): ..do so here instead, new function.
+ (dwarf2_finish): Call dwarf2_cleanup. When chaining together
+ subseg line entries, unhook entries from old subseg list.
+ (dwarf2_directive_loc): Free remap_debug_filename string.
+ (out_dir_and_file_list): Likewise.
+ (out_debug_str): Likewise.
+
+2022-06-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo
+ When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo
+ installed, I run into:
+ ...
+ (gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call
+ step^M
+ __tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \
+ ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M
+ 45 {^M
+ (gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW
+ ...
+
+ The problem is that the step is expected to step over the call to tcsetattr,
+ but due to glibc debuginfo being installed, we step into the call.
+
+ Fix this by using next instead of step.
+
+ Tested on x86_64-linux.
+
+2022-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Avoid warnings in cooked_{read,write}_test for m68hc11
+ With --enable-targets=all we have:
+ ...
+ $ gdb -q -batch -ex "maint selftest"
+ ...
+ Running selftest regcache::cooked_read_test::m68hc11.
+ warning: No frame soft register found in the symbol table.
+ Stack backtrace will not work.
+ Running selftest regcache::cooked_read_test::m68hc12.
+ warning: No frame soft register found in the symbol table.
+ Stack backtrace will not work.
+ Running selftest regcache::cooked_read_test::m68hc12:HCS12.
+ warning: No frame soft register found in the symbol table.
+ Stack backtrace will not work.
+ ...
+
+ Likewise for regcache::cooked_write_test.
+
+ The warning has no use in the selftest context.
+
+ Fix this by skipping the specific selftests.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29224
+
+2022-06-13 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Deal with atomic sequence
+ We can't put a breakpoint in the middle of a ll/sc atomic sequence,
+ so look for the end of the sequence and put the breakpoint there.
+
+2022-06-13 Sam James <sam@gentoo.org>
+
+ gdb: don't use bashism in configure test
+ Results in configure output like:
+ ```
+ checking for X... no
+ /var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator
+ checking whether to use babeltrace... auto
+ ```
+
+ ... when /bin/sh is provided by a POSIX-compliant shell, like dash,
+ instead of bash.
+
+2022-06-13 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ gdb:csky add support target-descriptions for CSKY arch
+ Registers in CSKY architecture included:
+ 1. 32 gprs
+ 2. 16 ars (alternative gprs used for quick interrupt)
+ 3. hi, lo, pc
+ 4. fr0~fr31, fcsr, fid, fesr
+ 5. vr0~vr15
+ 6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank)
+
+ For register names:
+ Except over control registers, other registers, like gprs, hi, lo ...
+ are fixed names. Among the 32*32 control registers, some used registers
+ will have fixed names, others will have a default name "cpxcry". 'x'
+ refers to bank, y refers index in the bank(a control register in bank
+ 4 with index 14 will has a default name cp4cr14).
+
+ For register numbers in GDB:
+ We assign a fixed number to each register in GDB, like:
+ r0~r31 with 0~31
+ hi, lo with 36, 37
+ fpu/vpu with 40~71
+ ...
+ described in function csky_get_supported_register_by_index().
+
+ Function csky_get_supported_tdesc_registers_count():
+ To calculate the total number of registers that GDB can analyze,
+ including those with fixed names and those with default register names.
+
+ Function csky_get_supported_register_by_index():
+ To find a supported struct csky_supported_tdesc_register, return a
+ struct include name with regnum via index.
+
+ Arrays csky_supported_tdesc_feature_names[]:
+ Include all supported feature names in tdesc-xmls.
+
+ We use the information described above to load the register description
+ file of the target from the stub. When loading, do a little check that
+ whether the register description file contains SP, LR and PC.
+
+2022-06-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle quotes in gdb_py_module_available
+ On openSUSE Leap 42.3 with python 3.4, I run into:
+ ...
+ (gdb) python import pygments^M
+ Traceback (most recent call last):^M
+ File "<string>", line 1, in <module>^M
+ ImportError: No module named 'pygments'^M
+ Error while executing Python code.^M
+ (gdb) FAIL: gdb.base/style.exp: python import pygments
+ ERROR: unexpected output from python import
+ ...
+ because gdb_py_module_available doesn't handle the single quotes around the
+ module name in the ImportError.
+
+ Fix this by allowing the single quotes.
+
+ Tested on x86_64-linux.
+
+2022-06-13 Jan Beulich <jbeulich@suse.com>
+
+ x86: fix incorrect indirection
+ Commit 384e201e5aec ("x86: properly initialize struct instr_info
+ instance(s)") was based on an improperly refreshed patch. Correct the
+ oversight.
+
+2022-06-13 Jan Beulich <jbeulich@suse.com>
+
+ x86: replace global scratch buffer
+ With its movement to the stack, and with the subsequent desire to
+ initialize the entire instr_info instances, this has become doubly
+ inefficient. Individual users have better knowledge of how big a buffer
+ they need, and in a number of cases going through an intermediate buffer
+ can be avoided altogether.
+
+ Having got confirmation that it wasn't intentional to print memory
+ operand displacements with inconsistent style, print_displacement() is
+ now using dis_style_address_offset consistently (eliminating the need
+ for callers to pass in a style).
+
+ While touching print_operand_value() also convert its "hex" parameter to
+ bool. And while altering (and moving) oappend_immediate(), fold
+ oappend_maybe_intel_with_style() into its only remaining caller. Finally
+ where doing adjustments, use snprintf() in favor of sprintf().
+
+2022-06-13 Jan Beulich <jbeulich@suse.com>
+
+ x86: avoid string copy when swapping Vex.W controlled operands
+ Now that op_out[] is an array of pointers, there's no need anymore to
+ copy strings. Simply swap the pointers.
+
+2022-06-13 Jan Beulich <jbeulich@suse.com>
+
+ x86: shrink prefix related disassembler state fields
+ By changing the values used for "artificial" prefix values,
+ all_prefixes[] can be shrunk to array of unsigned char. All that
+ additionally needs adjusting is the printing of possible apparently
+ standalone prefixes when recovering from longjmp(): Simply check
+ whether any prefixes were successfully decoded, to avoid converting
+ opcode bytes matching the "artificial" values to prefix mnemonics.
+
+ Similarly by re-arranging the bits assigned to PREFIX_* mask values
+ we can fit all segment register masks in a byte and hence shrink
+ active_seg_prefix to unsigned char.
+
+ Somewhat similarly with last_*_prefix representing offsets into the
+ opcode being disassembled, signed char is sufficient to hold all possible
+ values.
+
+2022-06-13 Jan Beulich <jbeulich@suse.com>
+
+ x86: properly initialize struct instr_info instance(s)
+ Commit 39fb369834a3 ("opcodes: Make i386-dis.c thread-safe") introduced
+ a lot of uninitialized data. Alan has in particular observed ubsan
+ taking issue with the loop inverting the order of operands, where
+ op_riprel[] - an array of bool - can hold values other than 0 or 1.
+
+ Move instantiation of struct instr_info into print_insn() (thus having
+ just a single central point), and make use of C99 dedicated initializers
+ to fill fields right in the initializer where possible. This way all
+ fields not explicitly initialized will be zero-filled, which in turn
+ allows dropping of some other explicit initialization later in the
+ function or in ckprefix(). Additionally this removes a lot of
+ indirection, as all "ins->info" uses can simply become "info".
+
+ Make one further arrangement though, to limit the amount of data needing
+ (zero)initializing on every invocation: Convert the op_out structure
+ member to just an array of pointers, with the actual arrays living
+ inside print_insn() (and, as befoe, having just their 1st char filled
+ with nul).
+
+ While there, instead of adjusting print_insn()'s forward declaration,
+ arrange for no such declaration to be needed in the first place.
+
+2022-06-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-12 Tom Tromey <tom@tromey.com>
+
+ Fix self-test failure in addrmap
+ Mark pointed out that my recent addrmap C++-ficiation changes caused a
+ regression in the self-tests. This patch fixes the problem by
+ updating this test not to allocate the mutable addrmap on an obstack.
+
+ Remove psymtab_addrmap
+ While working on addrmaps, I noticed that psymtab_addrmap is no longer
+ needed now. It was introduced in ancient times as an optimization for
+ DWARF, but no other symbol reader was ever updated to use it. Now
+ that DWARF does not use psymtabs, it can be deleted.
+
+ Use malloc for mutable addrmaps
+ Mutable addrmaps currently require an obstack. This was probably done
+ to avoid having to call splay_tree_delete, but examination of the code
+ shows that all mutable obstacks have a limited lifetime -- now it's
+ simple to treat them as ordinary C++ objects, in some cases
+ stack-allocating them, and have a destructor to make the needed call.
+ This patch implements this change.
+
+ Remove addrmap::create_fixed
+ addrmap::create_fixed is just a simple wrapper for 'new', so remove it
+ in favor of uses of 'new'.
+
+ Remove addrmap_create_mutable
+ This removes addrmap_create_mutable in favor of using 'new' at the
+ spots where the addrmap is created.
+
+ Remove addrmap wrapper functions
+ This removes the various addrmap wrapper functions in favor of simple
+ method calls on the objects themselves.
+
+ Move addrmap classes to addrmap.h
+ This moves the addrmap class definitions to addrmap.h. This is safe
+ to do now that the contents are private.
+
+ Privacy for addrmap_mutable
+ This changes addrmap_mutable so that its data members are private.
+
+ Privacy for addrmap_fixed
+ This changes addrmap_fixed so that its data members are private.
+ It also makes struct addrmap_transition private as well.
+
+ Use inheritance for addrmap
+ This is a simply C++-ification of the basics of addrmap: it uses
+ virtual methods rather than a table of function pointers, and it
+ changes the concrete implementations to be subclasses.
+
+2022-06-12 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Trivial fixes to Cygwin build after 8fea1a81
+ * Remove a stray semicolon
+ * Restore dropped nullptr program argument in use of create_process() under CYGWIN
+
+ Simplify __USEWIDE
+ Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not
+ defined for Cygwin 1.5. After that, it's always defined if __CYGWIN__
+ is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.
+
+ Simplify cygwin_buf_t
+ Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was
+ defined as char for Cygwin 1.5. After that, it's always wchar_t, so
+ just use that.
+
+2022-06-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-10 Tom Tromey <tom@tromey.com>
+
+ Fix warning-avoidance initialization in xcoffread.c
+ With the registry rewrite series, on Fedora 34, I started seeing this
+ error in xcoffread.c:
+
+ ../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’:
+ ../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized]
+ 948 | union internal_auxent fcn_aux_saved = main_aux;
+ | ^~~~~~~~~~~~~
+ ../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here
+ 933 | union internal_auxent main_aux;
+ | ^~~~~~~~
+
+ I don't know why this error started suddenly... that seems weird,
+ because it's not obviously related to the changes I made.
+
+ Looking into it, it seems this line was intended to avoid a similar
+ warning -- but since 'main_aux' is uninitialized at the point where it
+ is used, this fix was incomplete.
+
+ This patch avoids the warning by initializing using "{}". I'm
+ checking this in.
+
+2022-06-10 Carl Love <cel@us.ibm.com>
+
+ Fix comparison of unsigned long int to int in record_linux_system_call.
+ The if statement in case gdb_sys_ioctl in function
+ record_linux_system_call in file gdb/linux-record.c is as follows:
+
+ if (tmpulongest == tdep->ioctl_FIOCLEX
+ || tmpulongest == tdep->ioctl_FIONCLEX
+ ....
+ || tmpulongest == tdep->ioctl_TCSETSW
+ ...
+ }
+
+ The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415. The variable
+ ioctl_TCSETW is defined in gdb/linux-record.h as an int. The TCSETW value
+ has the MSB set to one so it is a negative integer. The comparison of the
+ unsigned long value tmpulongest to a negative integer value for
+ ioctl_TCSETSW fails.
+
+ This patch changes the declarations for the ioctl_* values in struct
+ linux_record_tdep to unsigned long to fix the comparisons between
+ tmpulongest and the tdep->ioctl_* values.
+
+ An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify
+ the gdb record_linux_system_call() if statement for the ioctl TCSETSW
+ succeeds.
+
+ This patch has been tested on Power 10 and Intel with no test failures.
+
+2022-06-10 Carl Love <cel@us.ibm.com>
+
+ PowerPC, correct the gdb ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF.
+ Some of the ioctl numbers are based on the size of kernel termios structure.
+ Currently the PowerPC GDB definitions are "hard coded" into the ioctl
+ number.
+
+ The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
+ defined in gdb/ppc-linux-tdep.c as:
+
+ record_tdep->ioctl_TCGETS = 0x403c7413;
+ record_tdep->ioctl_TCSETS = 0x803c7414;
+ record_tdep->ioctl_TCSETSW = 0x803c7415;
+ record_tdep->ioctl_TCSETSF = 0x803c7416;
+
+ Where the termios structure size is in hex digits [5:4] as 0x3c.
+
+ The definition for the PowerPC termios structure is given in:
+ arch/powerpc/include/uapi/asm/termbits.h
+
+ The size of the termios data structure in this file is 0x2c not 0x3c.
+
+ This patch changes the hex digits for the size of the PowerPC termios size
+ in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
+ This patch also changes the hard coding to generate the number based on a
+ it easier to update the ioctl numbers.
+
+2022-06-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove definition of true/false from gdb_compiler_info
+ Since pretty much forever the get_compiler_info function has included
+ these lines:
+
+ # Most compilers will evaluate comparisons and other boolean
+ # operations to 0 or 1.
+ uplevel \#0 { set true 1 }
+ uplevel \#0 { set false 0 }
+
+ These define global variables true (to 1) and false (to 0).
+
+ It seems odd to me that these globals are defined in
+ get_compiler_info, I guess maybe the original thinking was that if a
+ compiler had different true/false values then we would detect it there
+ and define true/false differently.
+
+ I don't think we should be bundling this logic into get_compiler_info,
+ it seems weird to me that in order to use $true/$false a user needs to
+ first call get_compiler_info.
+
+ It would be better I think if each test script that wants these
+ variables just defined them itself, if in the future we did need
+ different true/false values based on compiler version then we'd just
+ do:
+
+ if { [test_compiler_info "some_pattern"] } {
+ # Defined true/false one way...
+ } else {
+ # Defined true/false another way...
+ }
+
+ But given the current true/false definitions have been in place since
+ at least 1999, I suspect this will not be needed any time soon.
+
+ Given that the definitions of true/false are so simple, right now my
+ suggestion is just to define them in each test script that wants
+ them (there's not that many). If we ever did need more complex logic
+ then we can always add a function in gdb.exp that sets up these
+ globals, but that seems overkill for now.
+
+ There should be no change in what is tested after this commit.
+
+2022-06-10 Luis Machado <luis.machado@arm.com>
+
+ Document the ARM_CC_FOR_TARGET testsuite variable
+ This variable is useful when exercising AArch64 multi-arch support (debugging
+ 32-bit AArch32 executables).
+
+ Unfortunately it isn't well documented. This patch adds information about it
+ and explains how to use it.
+
+2022-06-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix XPASS with gcc-12 in gdb.base/vla-struct-fields.exp
+ With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp:
+ ...
+ (gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M
+ $7 = 1^M
+ (gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object
+ ...
+
+ Fix this by limiting the xfailing to gcc-11 and earlier. Also, limit the
+ xfailing to the equality test.
+
+ Tested on x86_64-linux.
+
+2022-06-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix timeout in gdb.ada/ghost.exp
+ On openSUSE Tumbleweed with gcc-12, I run into a timeout:
+ ...
+ (gdb) print value^M
+ Multiple matches for value^M
+ [0] cancel^M
+ [1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \
+ character) return character at a-strmap.adb:599^M
+ [2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M
+ [3] system.object_reader.value (<ref> system.object_reader.object_symbol) \
+ return system.object_reader.uint64 at s-objrea.adb:2279^M
+ [4] system.traceback.symbolic.value (system.address) return string at \
+ s-trasym.adb:200^M
+ > FAIL: gdb.ada/ghost.exp: print value (timeout)
+ print ghost_value^M
+ Argument must be choice number^M
+ (gdb) FAIL: gdb.ada/ghost.exp: print ghost_value
+ ...
+
+ Fix this by prefixing value (as well as the other printed values) with the
+ package name:
+ ...
+ (gdb) print pck.value^M
+ ...
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29055
+
+2022-06-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-09 Tom Tromey <tromey@adacore.com>
+
+ Minor fix to Python breakpoint event documentation
+ I noticed that the Python event documentation referred to the event's
+ "breakpoint" field as a function, whereas it is actually an attribute.
+ This patch fixes the error.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/aarch64: fix 32-bit arm compatibility
+ GDB's ability to run 32-bit ARM processes on an AArch64 native target
+ is currently broken. The test gdb.multi/multi-arch.exp currently
+ fails with a timeout.
+
+ The cause of these problems is the following three functions:
+
+ aarch64_linux_nat_target::thread_architecture
+ aarch64_linux_nat_target::fetch_registers
+ aarch64_linux_nat_target::store_registers
+
+ What has happened, over time, is that these functions have been
+ modified, forgetting that any particular thread (running on the native
+ target) might be an ARM thread, or might be an AArch64 thread.
+
+ The problems always start with a line similar to this:
+
+ aarch64_gdbarch_tdep *tdep
+ = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch);
+
+ The problem with this line is that if 'inf->gdbarch' is an ARM
+ architecture, then gdbarch_tdep will return a pointer to an
+ arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object. The
+ result of the above cast will, as a consequence, be undefined.
+
+ In aarch64_linux_nat_target::thread_architecture, after the undefined
+ cast we then proceed to make use of TDEP, like this:
+
+ if (vq == tdep->vq)
+ return inf->gdbarch;
+
+ Obviously at this point the result is undefined, but, if this check
+ returns false we then proceed with this code:
+
+ struct gdbarch_info info;
+ info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64);
+ info.id = (int *) (vq == 0 ? -1 : vq);
+ return gdbarch_find_by_info (info);
+
+ As a consequence we will return an AArch64 gdbarch object for our ARM
+ thread! Things go downhill from there on.
+
+ There are similar problems, with similar undefined behaviour, in the
+ fetch_registers and store_registers functions.
+
+ The solution is to make use of a check like this:
+
+ if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32)
+
+ If the word size is 32 then we know we have an ARM architecture. We
+ just need to make sure that we perform this check before trying to
+ read the tdep field.
+
+ In aarch64_linux_nat_target::thread_architecture a little reordering,
+ and the addition of the above check allows us to easily avoid the
+ undefined behaviour.
+
+ For fetch_registers and store_registers I made the decision to split
+ each of the functions into two new helper functions, and so
+ aarch64_linux_nat_target::fetch_registers now calls to either
+ aarch64_fetch_registers or aarch32_fetch_registers, and there's a
+ similar change for store_registers.
+
+ One thing I had to decide was whether to place the new aarch32_*
+ functions into the aarch32-linux-nat.c file. In the end I decided to
+ NOT place the functions there, but instead leave them in
+ aarch64-linux-nat.c, my reasoning was this:
+
+ The existing functions in that file are shared from arm-linux-nat.c
+ and aarch64-linux-nat.c, this generic code to support 32-bit ARM
+ debugging from either native target.
+
+ In contrast, the two new aarch32 functions I have added _only_ make
+ sense when debugging on an AArch64 native target. These function
+ shouldn't be called from arm-linux-nat.c at all, and so, if we places
+ the functions into aarch32-linux-nat.c, the functions would be built
+ into a 32-bit ARM GDB, but never used.
+
+ With that said, there's no technical reason why they couldn't go in
+ aarch32-linux-nat.c, so if that is preferred I'm happy to move them.
+
+ After this commit the gdb.multi/multi-arch.exp passes.
+
+2022-06-09 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Document and fix exception stack offsets
+ Add a description of exception entry context stacking and fix next
+ frame offset (at 0xA8 relative to R0 location) as well as FPU
+ registers ones (starting at 0x68 relative to R0).
+
+ gdb/arm: Simplify logic for updating addresses
+ Small performance improvement by fetching previous SP value only
+ once before the loop and reuse it to avoid fetching at every
+ iteration.
+
+2022-06-09 Pedro Alves <pedro@palves.net>
+
+ Fix ARM_CC_FOR_TARGET handling
+ The previous patch that introduced the arm_cc_for_target procedure
+ moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
+ to tell tcl that ARM_CC_FOR_TARGET is a global. As a result,
+ specifying ARM_CC_FOR_TARGET on the command line actually does
+ nothing. This fixes it.
+
+ Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153
+
+2022-06-09 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb/arm: Terminate unwinding when LR is 0xffffffff
+ ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states
+ that LR is set to 0xffffffff on reset.
+
+ ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set
+ to 0xffffffff on warm reset if Main Extension is implemented,
+ otherwise the value is unknown.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: solve problems with compiler_info caching
+ After this commit:
+
+ commit 44d469c5f85a4243462b8966722dafa62b602bf5
+ Date: Tue May 31 16:43:44 2022 +0200
+
+ gdb/testsuite: add Fortran compiler identification to GDB
+
+ Some regressions were noticed:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html
+
+ The problem is associated with how compiler_info variable is cached
+ between calls to get_compiler_info.
+
+ Even before the above commit, get_compiler_info supported two
+ language, C and C++. Calling get_compiler_info would set the global
+ compiler_info based on the language passed as an argument to
+ get_compiler_info, and, in theory, compiler_info would not be updated
+ for the rest of the dejagnu run.
+
+ This obviously is slightly broken behaviour. If the first call to
+ get_compiler_info was for the C++ language then compiler_info would be
+ set based on the C++ compiler in use, while if the first call to
+ get_compiler_info was for the C language then compiler_info would be
+ set based on the C compiler.
+
+ This probably wasn't very noticable, assuming a GCC based test
+ environment then in most cases the C and C++ compiler would be the
+ same version.
+
+ However, if the user starting playing with CC_FOR_TARGET or
+ CXX_FOR_TARGET, then they might not get the behaviour they expect.
+
+ Except, to make matters worse, most of the time, the user probably
+ would get the behaviour they expected .... except when they didn't!
+ I'll explain:
+
+ In gdb.exp we try to avoid global variables leaking between test
+ scripts, this is done with the help of the two procs
+ gdb_setup_known_globals and gdb_cleanup_globals. All known globals
+ are recorded before a test script starts, and then, when the test
+ script ends, any new globals are deleted.
+
+ Normally, compiler_info is only set as a result of a test script
+ calling get_compiler_info or test_compiler_info. This means that the
+ compiler_info global will not exist when the test script starts, but
+ will exist when the test script end, and so, the compiler_info
+ variable is deleted at the end of each test.
+
+ This means that, in reality, the compiler_info is recalculated once
+ for each test script, hence, if a test script just checks on the C
+ compiler, or just checks on the C++ compiler, then compiler_info will
+ be correct and the user will get the behaviour they expect.
+
+ However, if a single test script tries to check both the C and C++
+ compiler versions then this will not work (even before the above
+ commit).
+
+ The situation is made worse be the behaviour or the load_lib proc.
+ This proc (provided by dejagnu) will only load each library once.
+ This means that if a library defines a global, then this global would
+ normally be deleted at the end of the first test script that includes
+ the library.
+
+ As future attempts to load the library will not actually reload it,
+ then the global will not be redefined and would be missing for later
+ test scripts that also tried to load that library.
+
+ To work around this issue we override load_lib in gdb.exp, this new
+ version adds all globals from the newly loaded library to the list of
+ globals that should be preserved (not deleted).
+
+ And this is where things get interesting for us. The library
+ trace-support.exp includes calls, at the file scope, to things like
+ is_amd64_regs_target, which cause get_compiler_info to be called.
+ This means that after loading the library the compiler_info global is
+ defined.
+
+ Our override of load_lib then decides that this new global has to be
+ preserved, and adds it to the gdb_persistent_globals array.
+
+ From that point on compiler_info will never be recomputed!
+
+ This commit addresses all the caching problems by doing the following:
+
+ Change the compiler_info global into compiler_info_cache global. This
+ new global is an array, the keys of this array will be each of the
+ supported languages, and the values will be the compiler version for
+ that language.
+
+ Now, when we call get_compiler_info, if the compiler information for
+ the specific language has not been computed, then we do that, and add
+ it to the cache.
+
+ Next, compiler_info_cache is defined by calling
+ gdb_persistent_global. This automatically adds the global to the list
+ of persistent globals. Now the cache will not be deleted at the end
+ of each test script.
+
+ This means that, for a single test run, we will compute the compiler
+ version just once for each language, this result will then be cached
+ between test scripts.
+
+ Finally, the legacy 'gcc_compiled' flag is now only set when we call
+ get_compiler_info with the language 'c'. Without making this change
+ the value of 'gcc_compiled' would change each time a new language is
+ passed to get_compiler_info. If the last language was e.g. Fortran,
+ then gcc_compiled might be left false.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: handle errors better in test_compiler_info
+ Now that get_compiler_info might actually fail (if the language is not
+ handled), then we should try to handle this failure better in
+ test_compiler_info.
+
+ After this commit, if get_compiler_info fails then we will return a
+ suitable result depending on how the user called test_compiler_info.
+
+ If the user does something like:
+
+ set version [test_compiler_info "" "unknown-language"]
+
+ Then test_compiler_info will return an empty string. My assumption is
+ that the user will be trying to match 'version' against something, and
+ the empty string hopefully will not match.
+
+ If the user does something like:
+
+ if { [test_compiler_info "some_pattern" "unknown-language"] } {
+ ....
+ }
+
+ Then test_compiler_info will return false which seems the obvious
+ choice.
+
+ There should be no change in the test results after this commit.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: make 'c' default language for get/test compiler info
+ This commit is a minor cleanup for the two functions (in gdb.exp)
+ get_compiler_info and test_compiler_info.
+
+ Instead of using the empty string as the default language, and just
+ "knowing" that this means the C language. Make this explicit. The
+ language argument now defaults to "c" if not specified, and the if
+ chain in get_compiler_info that checks the language not explicitly
+ handles "c" and gives an error for unknown languages.
+
+ This is a good thing, now that the API appears to take a language, if
+ somebody does:
+
+ test_compiler_info "xxxx" "rust"
+
+ to check the version of the rust compiler then we will now give an
+ error rather than just using the C compiler and leaving the user
+ having to figure out why they are not getting the results they
+ expect.
+
+ After a little grepping, I think the only place we were explicitly
+ passing the empty string to either get_compiler_info or
+ test_compiler_info was in gdb_compile_shlib_1, this is now changed to
+ pass "c" as the default language.
+
+ There should be no changes to the test results after this commit.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove get_compiler_info calls from gdb.exp and dwarf.exp
+ We don't need to call get_compiler_info before calling
+ test_compiler_info; test_compiler_info includes a call to
+ get_compiler_info.
+
+ This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
+ removing some unneeded calls to get_compiler_info. We could do the
+ same cleanup throughout the testsuite, but I'm leaving that for
+ another day.
+
+ There should be no change in the test results after this commit.
+
+2022-06-09 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: use test_compiler_info in gcc_major_version
+ The procedure gcc_major_version was earlier using the global variable
+ compiler_info to retrieve gcc's major version. This is discouraged and
+ (as can be read in a comment in compiler.c) compiler_info should be
+ local to get_compiler_info and test_compiler_info.
+
+ The preferred way of getting the compiler string is via calling
+ test_compiler_info without arguments. Gcc_major_version was changed to
+ do that.
+
+2022-06-09 Yvan Roux <yvan.roux@foss.st.com>
+
+ gdb: add Yvan Roux to gdb/MAINTAINERS
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve duplicate test names in gdb.threads/tls.exp
+ While running the gdb.threads/tls.exp test with a GDB configured
+ without Python, I noticed some duplicate test names.
+
+ This is caused by a call to skip_python_tests that is within a proc
+ that is called multiple times by the test script. Each call to
+ skip_python_tests results in a call to 'unsupported', and this causes
+ the duplicate test names.
+
+ After this commit we now call skip_python_tests just once and place
+ the result into a variable. Now, instead of calling skip_python_tests
+ multiple times, we just check the variable.
+
+ There should be no change in what is tested after this commit.
+
+2022-06-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve duplicate test name in gnu_vector.exp
+ While testing on AArch64 I spotted a duplicate test name in the
+ gdb.base/gnu_vector.exp test.
+
+ This commit adds a 'with_test_prefix' to resolve the duplicate.
+
+ While I was in the area I updated a 'gdb_test_multiple' call to make
+ use of $gdb_test_name.
+
+ There should be no change in what is tested after this commit.
+
+2022-06-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make throw_perror_with_name static
+ The throw_perror_with_name function is not used outside of utils.c
+ right now. And as perror_with_name is just a wrapper around
+ throw_perror_with_name, then any future calls would be to
+ perror_with_name.
+
+ Lets make throw_perror_with_name static.
+
+ There should be no user visible changes after this commit.
+
+2022-06-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove trailing '.' from perror_with_name calls
+ I ran into this error while working on AArch64 GDB:
+
+ Unable to fetch VFP registers.: Invalid argument.
+
+ Notice the '.:' in the middle of this error message.
+
+ This is because of this call in aarch64-linux-nat.c:
+
+ perror_with_name (_("Unable to fetch VFP registers."));
+
+ The perror_with_name function take a string, and adds ': <message>' to
+ the end the string, so I don't think the string that we pass to
+ perror_with_name should end in '.'.
+
+ This commit removes all of the trailing '.' characters from
+ perror_with_name calls, which give more readable error messages.
+
+ I don't believe that any of these errors are tested in the
+ testsuite (after a little grepping).
+
+2022-06-08 Tom Tromey <tom@tromey.com>
+
+ Move CU queue to dwarf2_per_objfile
+ The CU queue is a member of dwarf2_per_bfd, but it is only used when
+ expanding CUs. Also, the dwarf2_per_objfile destructor checks the
+ queue -- however, if the per-BFD object is destroyed first, this will
+ not work. This was pointed out Lancelot as fallout from the patch to
+ rewrite the registry system.
+
+ This patch avoids this problem by moving the queue to the per-objfile
+ object.
+
+2022-06-08 Tom Tromey <tom@tromey.com>
+
+ Change allocation of m_dwarf2_cus
+ m_dwarf2_cus manually manages the 'dwarf2_cu' pointers it owns. This
+ patch simplifies the code by changing it to use unique_ptr.
+
+2022-06-08 Andrew Burgess <aburgess@redhat.com>
+
+ libopcodes: extend the styling within the i386 disassembler
+ The i386 disassembler is pretty complex. Most disassembly is done
+ indirectly; operands are built into buffers within a struct instr_info
+ instance, before finally being printed later in the disassembly
+ process.
+
+ Sometimes the operand buffers are built in a different order to the
+ order in which they will eventually be printed.
+
+ Each operand can contain multiple components, e.g. multiple registers,
+ immediates, other textual elements (commas, brackets, etc).
+
+ When looking for how to apply styling I guess the ideal solution would
+ be to move away from the operands being a single string that is built
+ up, and instead have each operand be a list of "parts", where each
+ part is some text and a style. Then, when we eventually print the
+ operand we would loop over the parts and print each part with the
+ correct style.
+
+ But it feels like a huge amount of work to move from where we are
+ now to that potentially ideal solution. Plus, the above solution
+ would be pretty complex.
+
+ So, instead I propose a .... different solution here, one that works
+ with the existing infrastructure.
+
+ As each operand is built up, piece be piece, we pass through style
+ information. This style information is then encoded into the operand
+ buffer (see below for details). After this the code can continue to
+ operate as it does right now in order to manage the set of operand
+ buffers.
+
+ Then, as each operand is printed we can split the operand buffer into
+ chunks at the style marker boundaries, with each chunk being printed
+ with the correct style.
+
+ For encoding the style information I use a single character, currently
+ \002, followed by the style encoded as a single hex digit, followed
+ again by the \002 character.
+
+ This of course relies on there not being more than 16 styles, but that
+ is currently true, and hopefully will remain true for the foreseeable
+ future.
+
+ The other major concern that has arisen around this work is whether
+ the escape character could ever be encountered in output naturally
+ generated by the disassembler. If this did happen then the escape
+ characters would be stripped from the output, and the wrong styling
+ would be applied.
+
+ However, I don't believe that this is currently a problem.
+ Disassembler content comes from a number of sources. First there's
+ content that copied directly from the i386-dis.c file, this is things
+ like register names, and other syntax elements (brackets, commas,
+ etc). We can easily check that the i386-dis.c file doesn't contain
+ our special character.
+
+ The next source of content are immediate operands. The text for these
+ operands is generated by calls into libc. By selecting a
+ non-printable character we can be confident that this is not something
+ that libc will generate as part of an immediate representation.
+
+ The other output that appears to be from the disassembler is operands
+ that contain addresses and (possibly) symbol names. It is quite
+ possible that a symbol name might contain any special character we
+ could imagine, so is this a problem?
+
+ I don't think it is, we don't actually print address and symbol
+ operands through the disassembler, instead, the disassembler calls
+ back to the user (objdump, gdb, etc) to print the address and symbol
+ on its behalf. This content is printed directly to the output stream,
+ it does not pass through the i386 disassembler output buffers. As a
+ result, we never check this particular output for styling escape
+ characters.
+
+ In some (not very scientific) benchmarking on my machine,
+ disassembling a reasonably large (142M) shared library, I'm not seeing
+ any significant slow down in disassembler speed with this change.
+
+ Most instructions are now being fully syntax highlighted when I
+ disassemble using the --disassembler-color=extended-color option. I'm
+ sure that there are probably still a few corner cases that need fixing
+ up, but we can come back to them later I think.
+
+ When disassembler syntax highlighting is not being used, then there
+ should be no user visible changes after this commit.
+
+2022-06-08 Carl Love <cel@us.ibm.com>
+
+ Fix gdb.arch/powerpc-power7.exp isel disassembly output.
+ The following commit changes the output format for the isel instruction on
+ PowerPC.
+
+ commit dd4832bf3efc1bd1797a6b9188260692b8b0db52 Introduces error in test
+ Author: Dmitry Selyutin <ghostmansd@gmail.com>
+ Date: Tue May 24 13:46:35 2022 +0000
+
+ opcodes: introduce BC field; fix isel
+
+ Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
+ field present in binutils sources. Also, per 1.6.2, BC has the same
+ semantics as BA and BB fields, so this should keep the same flags and
+ mask, only with the different offset.
+
+ opcodes/
+ * ppc-opc.c
+ (BC): Define new field, with the same definition as CRB field,
+ but with the PPC_OPERAND_CR_BIT flag present.
+ gas/
+ * testsuite/gas/ppc/476.d: Update.
+ * testsuite/gas/ppc/a2.d: Update.
+ * testsuite/gas/ppc/e500.d: Update.
+ * testsuite/gas/ppc/power7.d: Update.
+ <snip>
+ --- a/gas/testsuite/gas/ppc/476.d
+ +++ b/gas/testsuite/gas/ppc/476.d
+ @@ -209,7 +209,7 @@ Disassembly of section \.text:
+ .*: (7c 20 07 8c|8c 07 20 7c) ici 1
+ .*: (7c 03 27 cc|cc 27 03 7c) icread r3,r4
+ .*: (50 83 65 36|36 65 83 50) rlwimi r3,r4,12,20,27
+ -.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,28
+ +.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,4\*cr7\+lt
+
+ The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
+ on Power 7, Power 8, Power 9 and Power 10.
+
+ This patch updates the regression test gdb.arch/powerpc-power7.exp with
+ the new expected output for the isel instruction.
+
+ The patch has been tested on Power 7 and Power 10 to verify the patch fixes
+ the test.
+
+2022-06-08 Pedro Alves <pedro@palves.net>
+
+ aarch64: Add fallback if ARM_CC_FOR_TARGET not set
+ On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
+ compiler to use when testing gdb.multi/multi-arch.exp and
+ gdb.multi/multi-arch-exec.exp. If you don't set it, then those
+ testcases don't run.
+
+ I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.
+
+ This commit adds a fallback. If ARM_CC_FOR_TARGET is not set, and
+ testing for Linux, try arm-linux-gnueabi-gcc,
+ arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
+ compilers, making sure that the produced executable runs on the target
+ machine before claiming that the compiler produces useful executables.
+
+ Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ Don't encode reloc.size
+ I expect the encoded reloc.size field originally came from aout
+ r_length ecoding, but somehow went wrong for 64-bit relocs (which
+ should have been encoded as 3). Toss all that out, just use a byte
+ size instead. The changes outside of reloc.c in this patch should
+ make the code independent of how reloc.size is encoded.
+
+ * reloc.c (struct reloc_howto_struct): Increase size field by
+ one bit. Comment.
+ (HOWTO_RSIZE): Don't encode size.
+ (bfd_get_reloc_size): Adjust, and make it an inline function.
+ (read_reloc, write_reloc): Adjust.
+ * bfd-in2.h: Regenerate.
+ * aout-ns32k.c: Include libbfd.h.
+ (put_reloc): Don't use howto->size directly. Calculate r_length
+ using bfd_log2 and bfd_get_reloc_size.
+ * aoutx.h (swap_std_reloc_out): Likewise.
+ (aout_link_reloc_link_order): Likewise.
+ * i386lynx.c (swap_std_reloc_out
+ * mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out
+ * pdp11.c (aout_link_reloc_link_order
+ * coff-arm.c (coff_arm_reloc): Don't use howto->size directly,
+ use bfd_get_reloc_size instead and adjust switch cases.
+ * coff-i386.c (coff_i386_reloc): Similarly.
+ * coff-x86_64.c (coff_amd64_reloc): Likewise.
+ * cpu-ns32k.c (do_ns32k_reloc): Likewise.
+ * elf32-arc.c (arc_do_relocation): Likewise.
+ * elf32-arm.c (elf32_arm_final_link_relocate): Likewise.
+ * elf32-bfin.c (bfin_bfd_reloc): Likewise.
+ * elf32-cr16.c (cr16_elf_final_link_relocate): Likewise.
+ * elf32-cris.c (cris_elf_pcrel_reloc): Likewise.
+ * elf32-crx.c (crx_elf_final_link_relocate): Likewise.
+ * elf32-csky.c (csky_elf_relocate_section): Likewise.
+ * elf32-d10v.c (extract_rel_addend, insert_rel_addend): Likewise.
+ * elf32-i386.c (elf_i386_relocate_section): Likewise.
+ * elf32-m32r.c (m32r_elf_generic_reloc): Likewise.
+ * elf32-nds32.c (nds32_elf_generic_reloc): Likewise.
+ * syms.c (_bfd_stab_section_find_nearest_line): Likewise.
+ * coff-rs6000.c (xcoff_ppc_relocate_section): Adjust howto.size.
+ * coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ bfin reloc offset checks
+ These all ought to use bfd_reloc_offset_in_range. In particular, replace
+ the check using howto->size + 1u.
+
+ * elf32-bfin.c (bfin_pcrel24_reloc): Use bfd_reloc_offset_in_range.
+ (bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc),
+ (bfin_final_link_relocate): Likewise.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ Revert reloc howto nits
+ The "HOWTO size encoding" patch put 1 as the HOWTO size arg for
+ numerous howtos that are unused, describe dynamic relocs, are markers,
+ or otherwise are special purpose reloc howtos that don't care about
+ the size. The idea was to ensure no howto changed by inspecting
+ object files. Revert those changes, making them zero size.
+
+ * coff-alpha.c: Give special purpose reloc howtos a size of zero.
+ * coff-mcore.c, * elf-hppa.h, * elf-m10300.c, * elf32-arm.c,
+ * elf32-csky.c, * elf32-m32c.c, * elf32-m68k.c, * elf32-mep.c,
+ * elf32-mips.c, * elf32-ppc.c, * elf32-rx.c, * elf32-s390.c,
+ * elf32-spu.c, * elf32-tic6x.c, * elf32-tilepro.c, *elf32-vax.c,
+ * elf32-xtensa.c, * elf64-alpha.c, * elf64-mips.c,
+ * elf64-mmix.c, * elf64-ppc.c, * elf64-s390.c, * elfn32-mips.c,
+ * elfxx-loongarch.c, * elfxx-riscv.c, * elfxx-sparc.c,
+ * elfxx-tilegx.c, * som.c, * vms-alpha.c: Likewise.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ HOWTO size encoding
+ This changes the HOWTO macro to encode the howto.size field from a
+ value given in bytes. This of course requires editing all target
+ uses of HOWTO, a major pain, but makes it a little nicer to specify
+ new target HOWTOs. Object files before/after this patch are
+ unchanged in .data and .rodata.
+
+ bfd/
+ * reloc.c (HOWTO_RSIZE): Encode size in bytes.
+ (EMPTY_HOWTO): Adjust to keep it all zero.
+ * aout-ns32k.c, * aoutx.h, * coff-alpha.c, * coff-arm.c,
+ * coff-i386.c, * coff-mcore.c, * coff-mips.c, * coff-rs6000.c,
+ * coff-sh.c, * coff-tic30.c, * coff-tic4x.c, * coff-tic54x.c,
+ * coff-x86_64.c, * coff-z80.c, * coff-z8k.c, * coff64-rs6000.c,
+ * elf-hppa.h, * elf-m10200.c, * elf-m10300.c, * elf32-arc.c,
+ * elf32-arm.c, * elf32-avr.c, * elf32-bfin.c, * elf32-cr16.c,
+ * elf32-cris.c, * elf32-crx.c, * elf32-csky.c, * elf32-d10v.c,
+ * elf32-d30v.c, * elf32-dlx.c, * elf32-epiphany.c,
+ * elf32-fr30.c, * elf32-frv.c, * elf32-ft32.c, * elf32-gen.c,
+ * elf32-h8300.c, * elf32-i386.c, * elf32-ip2k.c, * elf32-iq2000.c,
+ * elf32-lm32.c, * elf32-m32c.c, * elf32-m32r.c, * elf32-m68hc11.c,
+ * elf32-m68hc12.c, * elf32-m68k.c, * elf32-mcore.c, * elf32-mep.c,
+ * elf32-metag.c, * elf32-microblaze.c, * elf32-mips.c,
+ * elf32-moxie.c, * elf32-msp430.c, * elf32-mt.c, * elf32-nds32.c,
+ * elf32-nios2.c, * elf32-or1k.c, * elf32-pj.c, * elf32-ppc.c,
+ * elf32-pru.c, * elf32-rl78.c, * elf32-rx.c, * elf32-s12z.c,
+ * elf32-s390.c, * elf32-score.c, * elf32-score7.c,
+ * elf32-sh-relocs.h, * elf32-spu.c, * elf32-tic6x.c,
+ * elf32-tilepro.c, * elf32-v850.c, * elf32-vax.c,
+ * elf32-visium.c, * elf32-wasm32.c, * elf32-xc16x.c,
+ * elf32-xgate.c, * elf32-xstormy16.c, * elf32-xtensa.c,
+ * elf32-z80.c, * elf64-alpha.c, * elf64-bpf.c, * elf64-gen.c,
+ * elf64-mips.c, * elf64-mmix.c, * elf64-nfp.c, * elf64-ppc.c,
+ * elf64-s390.c, * elf64-x86-64.c, * elfn32-mips.c,
+ * elfnn-aarch64.c, * elfxx-ia64.c, * elfxx-loongarch.c,
+ * elfxx-mips.c, * elfxx-riscv.c, * elfxx-sparc.c,
+ * elfxx-tilegx.c, * mach-o-aarch64.c, * mach-o-arm.c,
+ * mach-o-i386.c, * mach-o-x86-64.c, * pdp11.c, * reloc.c,
+ * som.c, * vms-alpha.c: Adjust all uses of HOWTO.
+ * bfd-in2.h: Regenerate.
+ include/
+ * elf/arc-reloc.def: Adjust all uses of HOWTO.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ HOWTO_RSIZE
+ Define a helper macro for HOWTO.
+
+ * reloc.c (HOWTO_RSIZE): Define.
+ (HOWTO): Use it.
+ * bfd-in2.h: Regenerate.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ elf64-nfp reloc fix
+ These are all dummy howtos, there is no reason one of them should
+ have partial_inplace true.
+
+ * elf64-nfp.c (elf_nfp_howto_table <R_NFP_IMMED_LO16_I_B>): Don't
+ set partial_inplace.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ coff-z80 reloc howto fixes
+ Mostly cosmetic unless attempting to link coff-z80 into another output
+ format.
+
+ * coff-z80.c (howto_table <R_IMM24, R_WORD0, R_WORD1>): Correct size.
+ (extra_case): Use bfd_{get,put}_24 when applying R_IMM24.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ NONE reloc fixes
+ Make them all zero size standard do-nothing howtos.
+
+ * elf32-csky.c (csky_elf_howto_table <R_CKCORE_NONE>): Correct howto.
+ * elf32-ft32.c (ft32_elf_howto_table <R_FT32_NONE>): Likewise.
+ * elf32-gen.c (dummy): Likewise.
+ * elf32-nds32.c (none_howto): Likewise.
+ * elf32-nios2.c (elf_nios2_r2_howto_table_rel <R_NIOS2_NONE>):
+ Likewise.
+ * elf32-pru.c (elf_pru_howto_table_rel <R_PRU_NONE>): Likewise.
+ * elf32-v850.c (v800_elf_howto_table <R_V810_NONE>): Likewise.
+ * elf64-gen.c (dummy): Likewise.
+ * elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_NONE): Likewise.
+ * elfxx-mips.c (none_howto): Likewise.
+ * reloc.c (none_howto): Likewise.
+
+2022-06-08 Alan Modra <amodra@gmail.com>
+
+ asan: double free sb_kill
+ oss-fuzz hits a flaky crash with a double-free. I think this is due
+ to gas static state not being reinitialised between testcases, a bug
+ with oss-fuzz not gas. Anyway, this patch should avoid the problem.
+
+ * input-scrub.c (input_scrub_push): Move init of sb_index..
+ (input_scrub_reinit): ..to here.
+
+2022-06-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-07 Tom Tromey <tromey@adacore.com>
+
+ Use subclasses of windows_process_info
+ This changes windows_process_info to use virtual methods for its
+ callbacks, and then changes the two clients of this code to subclass
+ this class to implement the methods.
+
+ I considered using CRTP here, but that would require making the new
+ structures visible to the compilation of of nat/windows-nat.c. This
+ seemed like a bit of a pain, so I didn't do it.
+
+ This change then lets us change all the per-inferior globals to be
+ members of the new subclass. Note that there can still only be a
+ single inferior -- currently there's a single global of the new type.
+ This is just another step toward possibly implementing multi-inferior
+ for Windows.
+
+ It's possible this could be cleaned up further... ideally I'd like to
+ move more of the data into the base class. However, because gdb
+ supports Cygwin and gdbserver does not, and because I don't have a way
+ to build or test Cygwin, larger refactorings are difficult.
+
+2022-06-07 Tom Tromey <tromey@adacore.com>
+
+ Turn some windows-nat.c static functions into methods
+ This patch turns some windows-nat.c static functions into methods on
+ windows_nat_target. This avoids having to reference the
+ windows_nat_target singleton in some more spots -- a minor code
+ cleanup.
+
+ Allow ASLR to be disabled on Windows
+ On Windows, it is possible to disable ASLR when creating a process.
+ This patch adds code to do this, and hooks it up to gdb's existing
+ disable-randomization feature. Because the Windows documentation
+ cautions that this isn't available on all versions of Windows, the
+ CreateProcess wrapper function is updated to make the attempt, and
+ then fall back to the current approach if it fails.
+
+ Introduce wrapper for CreateProcess
+ This is a small refactoring that introduces a wrapper for the Windows
+ CreateProcess function. This is done to make the next patch a bit
+ simpler.
+
+2022-06-07 Enze Li <enze.li@hotmail.com>
+
+ Update my email address in gdb/MAINTAINERS
+
+2022-06-07 Tom Tromey <tromey@adacore.com>
+
+ Constify solib_name_from_address
+ I noticed that solib_name_from_address returned a non-const string,
+ but it's more appropriate to return const. This patch implements
+ this. Tested by rebuilding.
+
+2022-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/rust] Add missing _() for error call
+ In commit 1390b65a1b9 ("[gdb/rust] Fix literal truncation") I forgot to add
+ _() around a string using in an error call.
+
+ Fix this by adding the missing _().
+
+ Tested on x86_64-linux.
+
+2022-06-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Allow frv::fr300 in selftests
+ In skip_arch in gdb/selftest-arch.c we skip architecture fr300 because of
+ PR20946, but the PR has been fixed by commit 0ae60c3ef45 ("Prevent an abort in
+ the FRV disassembler if the target bfd name is unknown.") in Januari 2017.
+
+ Remove the skipping of frv::fr300.
+
+ Tested on x86_64-linux.
+
+2022-06-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-06 Tom Tromey <tromey@adacore.com>
+
+ Consolidate "Python API" sections in NEWS
+ I noticed that the gdb NEWS file had two "Python API" sections in
+ "Changes since GDB 12". This patch consolidates the two. I chose to
+ preserve the second one, first because it is longer, and second
+ because I felt that user command changes should come before API
+ changes.
+
+ Simplify varobj "change" logic
+ varobj used to store 'print_value' as a C string, where NULL was a
+ valid value, and so it had logic to handle this situation. However,
+ at some point this was changed to be a std::string, and so the code
+ can be simplified in this spot.
+
+2022-06-06 Tom Tromey <tromey@adacore.com>
+
+ Remove "-break-insert -r" tests
+ PR mi/14270 points out that mi-break.exp has some tests for an
+ unimplemented "-r" switch for "-break-insert". This switch was never
+ implemented, and is not documented -- though it is mentioned in a
+ comment in the documentation. This patch removes the test and the doc
+ comment.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14270
+
+2022-06-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Name arch selftests more clearly
+ When running some all archs selftest I get:
+ ...
+ $ gdb -q -batch -ex "maint selftest unpack_field_as_long"
+ Running selftest unpack_field_as_long::A6.
+ ...
+
+ By now I know that A6 is an arc architecture, but for others that's less
+ clear.
+
+ Fix this by using unpack_field_as_long::arc::A6 instead.
+
+ This then introduces redundant names like arm::arm, so try to avoid those,
+ though I'm not entirely convinced that that's worth the trouble.
+
+ This introduces the following new names:
+ ...
+ +Running selftest unpack_field_as_long::am33_2::am33-2.
+ +Running selftest unpack_field_as_long::arc::A6.
+ +Running selftest unpack_field_as_long::arc::A7.
+ +Running selftest unpack_field_as_long::arc::EM.
+ +Running selftest unpack_field_as_long::arc::HS.
+ +Running selftest unpack_field_as_long::arm::ep9312.
+ +Running selftest unpack_field_as_long::arm::iwmmxt.
+ +Running selftest unpack_field_as_long::arm::iwmmxt2.
+ +Running selftest unpack_field_as_long::arm::xscale.
+ +Running selftest unpack_field_as_long::bpf::xbpf.
+ +Running selftest unpack_field_as_long::frv::fr400.
+ +Running selftest unpack_field_as_long::frv::fr450.
+ +Running selftest unpack_field_as_long::frv::fr500.
+ +Running selftest unpack_field_as_long::frv::fr550.
+ +Running selftest unpack_field_as_long::frv::simple.
+ +Running selftest unpack_field_as_long::frv::tomcat.
+ +Running selftest unpack_field_as_long::iq2000::iq10.
+ +Running selftest unpack_field_as_long::m32c::m16c.
+ +Running selftest unpack_field_as_long::mep::c5.
+ +Running selftest unpack_field_as_long::mep::h1.
+ +Running selftest unpack_field_as_long::nds32::n1.
+ +Running selftest unpack_field_as_long::nds32::n1h.
+ +Running selftest unpack_field_as_long::nds32::n1h_v2.
+ +Running selftest unpack_field_as_long::nds32::n1h_v3.
+ +Running selftest unpack_field_as_long::nds32::n1h_v3m.
+ +Running selftest unpack_field_as_long::z80::ez80-adl.
+ +Running selftest unpack_field_as_long::z80::ez80-z80.
+ +Running selftest unpack_field_as_long::z80::gbz80.
+ +Running selftest unpack_field_as_long::z80::r800.
+ +Running selftest unpack_field_as_long::z80::z180.
+ ...
+
+ Tested on x86_64-linux.
+
+2022-06-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Enable some more print_one_insn selftests
+ In print_one_insn_test we have this cluster of skipped tests:
+ ...
+ case bfd_arch_ia64:
+ case bfd_arch_mep:
+ case bfd_arch_mips:
+ case bfd_arch_tic6x:
+ case bfd_arch_xtensa:
+ return;
+ ...
+
+ Enable some of these, and document in more detail why they're enabled or
+ skipped.
+
+ Likewise, document bfd_arch_or1k because it's an odd case.
+
+ Tested on x86_64-linux.
+
+2022-06-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix maint selftest -v print_one_insn
+ When running the print_one_insn selftests with -v, I get:
+ ...
+ $ gdb -q -batch -ex "maint selftest -v print_one_insn"
+ Running selftest print_one_insn::A6.
+ .shor 0x783eRunning selftest print_one_insn::A7.
+ trap_s 0x1Running selftest print_one_insn::ARC600.
+ .shor 0x783eRunning selftest print_one_insn::ARC601.
+ Running selftest print_one_insn::ARC700.
+ trap_s 0x1Running selftest print_one_insn::ARCv2.
+ trap_s 0x1Running selftest print_one_insn::EM.
+ trap_s 0x1Running selftest print_one_insn::HS.
+ trap_s 0x1Running selftest print_one_insn::Loongarch32.
+ ...
+
+ The insn is written to gdb_stdout, and there is code in the selftest to add a
+ newline after the insn, which writes to stream().
+
+ The stream() ui_file points into a string buffer, which the disassembler uses
+ before writing to gdb_stdout, so writing into it after the disassembler has
+ finished has no effect.
+
+ Fix this by using gdb_stdlog and debug_printf (which is what the unit test
+ infrastructure itself uses) instead, such that we have:
+ ...
+ Running selftest print_one_insn::A6.
+ .shor 0x783e
+ Running selftest print_one_insn::A7.
+ trap_s 0x1
+ Running selftest print_one_insn::ARC600.
+ .shor 0x783e
+ Running selftest print_one_insn::ARC601.
+ Running selftest print_one_insn::ARC700.
+ trap_s 0x1
+ Running selftest print_one_insn::ARCv2.
+ trap_s 0x1
+ Running selftest print_one_insn::Loongarch32.
+ ...
+
+ Note: I've also removed the printing of arch_name, which would give
+ us otherwise the redundant:
+ ...
+ Running selftest print_one_insn::A6.
+ arc .shor 0x783e
+ Running selftest print_one_insn::A7.
+ arc trap_s 0x1
+ ...
+
+ Tested on x86_64-linux.
+
+2022-06-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add missing skip_python_tests call in py-doc-reformat.exp
+ In commit:
+
+ commit 51e8dbe1fbe7d8955589703140ca5eba7b4f1bd7
+ Date: Mon May 16 19:26:54 2022 +0100
+
+ gdb/python: improve formatting of help text for user defined commands
+
+ the test that was added (gdb.python/py-doc-reformat.exp) was missing a
+ call to skip_python_tests. As a result, this test would fail for any
+ GDB built within Python support.
+
+ This commit adds a call to skip_python_tests.
+
+2022-06-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-05 Tom Tromey <tom@tromey.com>
+
+ Remove obsolete Python 2 comment
+ I found a comment that referred to Python 2, but that is now obsolete
+ -- the code it refers to is gone. I'm checking in this patch to
+ remove the comment.
+
+ There's a similar comment elsewhere, but I plan to remove that one in
+ another patch I'm going to submit shortly.
+
+2022-06-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-04 Alan Modra <amodra@gmail.com>
+
+ asan: null dereference in coff_count_linenumbers
+ * coffgen.c (coff_count_linenumbers): Don't segfault when asymbol
+ the_bfd is NULL.
+
+ asan: uninitialised write in bfd_mach_o_write_contents
+ * mach-o.c (bfd_mach_o_write_contents): Always set
+ bfd_mach_o_dyld_info_command *_off fields.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Fix literal truncation
+ Make sure we error out on overflow instead of truncating in all cases.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/m2] Fix UB and literal truncation
+ Rewrite parse_number to use ULONGEST instead of LONGEST, to fix UB errors as
+ mentioned in PR29163.
+
+ Furthermore, make sure we error out on overflow instead of truncating in all
+ cases.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29163
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/rust] Fix literal truncation
+ Make sure we error out on overflow instead of truncating in all cases.
+
+ I've used as overflow string: "Integer literal is too large", based
+ on what I found at
+ <rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs
+ but perhaps someone has a better idea.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/pascal] Fix literal truncation
+ Make sure we error out on overflow instead of truncating in all cases.
+
+ The current implementation of parse_number contains a comment about PR16377,
+ but that's related to C-like languages. In absence of information of whether
+ the same fix is needed for pascal, take the conservative approach and keep
+ behaviour for decimals unchanged.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/go] Fix literal truncation
+ Make sure we error out on overflow instead of truncating in all cases.
+
+ The current implementation of parse_number contains a comment about PR16377,
+ but that's related to C-like languages. In absence of information of whether
+ the same fix is needed for go, take the conservative approach and keep
+ behaviour for decimals unchanged.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/fortran] Fix literal truncation
+ As mentioned in commit 5b758627a18 ("Make gdb.base/parse_number.exp test all
+ architectures"):
+ ...
+ There might be a bug that 32-bit fortran truncates 64-bit values to
+ 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
+ ...
+
+ More concretely, we have:
+ ...
+ $ for arch in i386:x86-64 i386; do \
+ gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \
+ -ex "p /x 0xffffffffffffffff"; \
+ done
+ The target architecture is set to "i386:x86-64".
+ $1 = 0xffffffffffffffff
+ The target architecture is set to "i386".
+ $1 = 0xffffffff
+ ...
+
+ Fix this by adding a range check in parse_number in gdb/f-exp.y.
+
+ Furthermore, make sure we error out on overflow instead of truncating in all
+ other cases.
+
+ Tested on x86_64-linux.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/c] Fix type of 2147483648 and literal truncation
+ [ Assuming arch i386:x86-64, sizeof (int) == 4,
+ sizeof (long) == sizeof (long long) == 8. ]
+
+ Currently we have (decimal for 0x80000000):
+ ...
+ (gdb) ptype 2147483648
+ type = unsigned int
+ ...
+
+ According to C language rules, unsigned types cannot be used for decimal
+ constants, so the type should be long instead (reported in PR16377).
+
+ Fix this by making sure the type of 2147483648 is long.
+
+ The next interesting case is (decimal for 0x8000000000000000):
+ ...
+ (gdb) ptype 9223372036854775808
+ type = unsigned long
+ ...
+
+ According to the same rules, unsigned long is incorrect.
+
+ Current gcc uses __int128 as type, which is allowed, but we don't have that
+ available in gdb, so the strict response here would be erroring out with
+ overflow.
+
+ Older gcc without __int128 support, as well as clang use an unsigned type, but with
+ a warning. Interestingly, clang uses "unsigned long long" while gcc uses
+ "unsigned long", which seems the better choice.
+
+ Given that the compilers allow this as a convience, do the same in gdb
+ and keep type "unsigned long", and make this explicit in parser and test-case.
+
+ Furthermore, make sure we error out on overflow instead of truncating in all
+ cases.
+
+ Tested on x86_64-linux with --enable-targets=all.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16377
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Test more values in gdb.base/parse_numbers.exp
+ Currently we only test value 0xffffffffffffffff in test-case
+ gdb.base/parse_numbers.exp.
+
+ Test more interesting values, both in decimal and hex format, as well as
+ negative decimals for language modula-2.
+
+ This results in an increase in total tests from 15572 to 847448 (55 times
+ more tests).
+
+ Balance out the increase in runtime by reducing the number of architectures
+ tested: only test one architecture per sizeof longlong/long/int/short
+ combination, while keeping the possibility intact to run with all
+ architectures (through setting a variable in the test-case)
+
+ Results in slight reduction of total tests: 15572 -> 13853.
+
+ Document interesting cases in the expected results:
+ - wrapping from unsigned to signed
+ - truncation
+ - PR16377: using unsigned types to represent decimal constants in C
+
+ Running the test-case with a gdb build with -fsanitize=undefined, we trigger
+ two UB errors in the modula-2 parser, filed as PR29163.
+
+ Tested on x86_64-linux with --enable-targets=all.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix ERROR in gdb.ctf/funcreturn.exp
+ On openSUSE Tumbleweed (with gcc-12, enabling ctf tests) I run into:
+ ...
+ ERROR: tcl error sourcing src/gdb/testsuite/gdb.ctf/funcreturn.exp.
+ ERROR: tcl error code NONE
+ ERROR: Unexpected arguments: \
+ {print v_double_func} \
+ {[0-9]+ = {double \(\)} 0x[0-9a-z]+.*} \
+ {print double function} \
+ }
+ ...
+
+ The problem is a curly brace as fourth argument to gdb_test, which errors out
+ due to recently introduced more strict argument checking in gdb_test.
+
+ Fix the error by removing the brace.
+
+ Though this fixes the error for me, due to PR29160 I get only FAILs, so I can't
+ claim proper testing on x86_64-linux.
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/manythreads.exp with check-read1
+ When running test-case gdb.threads/manythreads.exp with check-read1, I ran
+ into this hard-to-reproduce FAIL:
+ ...
+ [New Thread 0x7ffff7318700 (LWP 31125)]^M
+ [Thread 0x7ffff7321700 (LWP 31124) exited]^M
+ [New T^C^M
+ ^M
+ Thread 769 "manythreads" received signal SIGINT, Interrupt.^M
+ [Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M
+ 0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
+ ...
+
+ The matching in the failing gdb_test_multiple is done in an intricate way,
+ trying to pass on some order and fail on another order.
+
+ Fix this by rewriting the regexps to match one line at most, and detecting
+ invalid order by setting and checking state variables.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29177
+
+2022-06-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix warning in print_one_insn::ez80-adl
+ When running selftest print_one_insn::ez80-adl we run into this warning:
+ ...
+ Running selftest print_one_insn::ez80-adl.
+ warning: Unable to determine inferior's software breakpoint type: couldn't
+ find `_break_handler' function in inferior. Will be used default software \
+ breakpoint instruction RST 0x08.
+ ...
+
+ Fix this by explicitly handling bfd_arch_z80 in print_one_insn_test.
+
+ Tested on x86_64-linux.
+
+2022-06-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-03 Tom Tromey <tromey@adacore.com>
+
+ Use bool for evregpy_no_listeners_p
+ I noticed that evregpy_no_listeners_p should return a bool. This
+ patch makes this change. I'm checking it in.
+
+2022-06-03 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow in _bfd_mips_elf_section_from_shdr
+ * elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Sanity check
+ intopt.size and remaining bytes in section for reginfo.
+
+2022-06-03 Alan Modra <amodra@gmail.com>
+
+ Re: ubsan: undefined shift in frag_align_code
+ This one needs the same fix too.
+
+ * config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed
+ integer overflow.
+
+2022-06-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix warning in foreach_arch selftests
+ When running the selftests, I run into:
+ ...
+ $ gdb -q -batch -ex "maint selftest"
+ ...
+ Running selftest execute_cfa_program::aarch64:ilp32.
+ warning: A handler for the OS ABI "GNU/Linux" is not built into this
+ configuration of GDB. Attempting to continue with the default aarch64:ilp32
+ settings.
+ ...
+ and likewise for execute_cfa_program::i8086 and
+ execute_cfa_program::ia64-elf32.
+
+ The warning can easily be reproduced outside the selftests by doing:
+ ...
+ $ gdb -q -batch -ex "set arch aarch64:ilp32"
+ ...
+ and can be prevented by first doing "set osabi none".
+
+ Fix the warning by setting osabi to none while doing selftests that iterate
+ over all architectures.
+
+ This causes a regression in the print_one_insn selftests for the ARC
+ architecture.
+
+ The problem is pre-existing, and can be demonstrated (already without this
+ patch) using:
+ ...
+ $ gdb -q -batch -ex "set osabi none" -ex "maint selftest print_one_insn::A6"
+ Running selftest print_one_insn::A6.
+ Self test failed: Cannot access memory at address 0x0
+ Ran 1 unit tests, 1 failed
+ $
+ ...
+
+ For ARC, we use the generic case in print_one_insn_test, containing this code:
+ ...
+ int kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
+ ...
+ insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
+ ...
+
+ The problem is that with osabi linux we trigger:
+ ...
+ static int
+ arc_linux_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
+ {
+ return trap_size;
+ }
+ ...
+ but with osabi none:
+ ...
+ arc_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
+ {
+ size_t length_with_limm = gdb_insn_length (gdbarch, *pcptr);
+ ...
+ which needs access to memory, and will consequently fail.
+
+ Fix this in print_one_insn_test, in the default case, by iterating over
+ supported osabi's to makes sure we trigger arc_linux_breakpoint_kind_from_pc
+ which will give us a usable instruction to disassemble.
+
+ Tested on x86_64-linux.
+
+2022-06-03 Tom de Vries <tdevries@suse.de>
+
+ Revert "[gdb] Fix warning in foreach_arch selftests"
+ This reverts commit fc18b1c5afd ("[gdb] Fix warning in foreach_arch
+ selftests").
+
+ The commit introduced regressions for an --enable-targets=all build:
+ ...
+ Running selftest print_one_insn::A6.^M
+ Self test failed: Cannot access memory at address 0x0^M
+ ...
+ and while investigating those I realized that the commit fc18b1c5afd
+ complicates things by trying to set the current osabi.
+
+ So, revert the patch in preparation for a simpler solution.
+
+ Tested on x86_64-linux.
+
+2022-06-03 Jan Beulich <jbeulich@suse.com>
+
+ x86: exclude certain ISA extensions from v3/v4 ISA
+ Like TBM and LWP, XOP and FMA4 also shouldn't be included in v3.
+
+ Like AVX512-4VNNIW, AVX512-4FMAPS also shouldn't be included in v4.
+
+2022-06-03 Roland McGrath <mcgrathr@google.com>
+
+ gdb: LoongArch: Remove nonportable #include
+ Don't use gregset.h in *-tdep.c since it's not usable on
+ hosts that don't have <sys/procfs.h>. It's not needed by
+ this file, and should only be needed by *-nat.c files.
+
+2022-06-03 Alan Modra <amodra@gmail.com>
+
+ Re: asan: mips_gprel_reloc segfault
+ Similarly for the elf mips support.
+
+ * elf32-mips.c (mips_elf_final_gp): Don't segfault on symbols
+ in any of the bfd_is_const_section sections.
+ * elf64-mips.c (mips_elf64_final_gp): Likewise.
+ * elfn32-mips.c (mips_elf_final_gp): Likewise.
+
+2022-06-03 Alan Modra <amodra@gmail.com>
+
+ asan: mips_gprel_reloc segfault
+ Not just the undefined section has a NULL owner, the absolute section
+ has too. Which means we can't find output_bfd for __gp. Also, may as
+ well test directly for output_bfd == NULL.
+
+ * coff-mips.c (mips_gprel_reloc): Don't segfault on any of
+ bfd_is_const_section sections.
+
+2022-06-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Detect change instead of init in gdb.mi/mi-var-block.exp
+ On openSUSE Tumbleweed with target board unix/-m32, I run into:
+ ...
+ PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2
+ Expecting: ^(-var-update \*[^M
+ ]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"},
+ {name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -var-update *^M
+ ^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output)
+ ...
+
+ The problem is that the test-case attempts to detect a change in the cb
+ variable caused by this initialization:
+ ...
+ void
+ do_block_tests ()
+ {
+ int cb = 12;
+ ...
+ but that only works if the stack location happens to be unequal to 12 before
+ the initialization.
+
+ Fix this by first initializing to 0, and then changing the value to 12:
+ ...
+ - int cb = 12;
+ + int cb = 0;
+ + cb = 12;
+ ...
+ and detecting that change.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29195
+
+2022-06-02 Eli Zaretskii <eliz@gnu.org>
+
+ Rearrange and slightly reword the "Location Specification" section
+ This rearranges and changes the wording of the "Location
+ Specification" section of the GDB manual in minor ways.
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for "main"
+ "main" is redeclared with a different type in maint.c. I think this
+ might have come from my first gdb patch, many many years ago. While I
+ wonder if this profiling code is actually useful at all any more, in
+ the meantime it's simple to fix the declaration.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings for "struct coff_symbol"
+ "struct coff_symbol" is defined in multiple .c files, causing ODR
+ warnings. This patch renames just the xcoffread.c type.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings for "struct insn_decode_record_t"
+ "struct insn_decode_record_t" is defined in multiple .c files, causing
+ ODR warnings. This patch renames the types, and removes the use of
+ "typedef" here -- this is a C-ism that's no longer needed.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings for "struct insn_info"
+ "struct insn_info" is defined in multiple .c files, causing ODR
+ warnings. This patch renames the type in z80-tdep.c, leaving the
+ other one alone.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings from overlay constants
+ Some overlay-related constants are duplicated in z80-tdep.c, causing
+ ODR warnings. This patch renames just the z80-specific ones.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for "enum string_repr_result"
+ "enum string_repr_result" is defined in multiple .c files, causing ODR
+ warnings. This patch renames the types.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for "struct find_targ_sec_arg"
+ "struct find_targ_sec_arg" is defined in multiple .c files, causing
+ ODR warnings. This patch renames the types.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for "struct stack_item"
+ "struct stack_item" is defined in multiple .c files, causing ODR
+ warnings. This patch renames these types.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for "struct instruction_type"
+ "struct instruction_type" is defined in multiple .c files, causing an
+ ODR warning. This patch renames the types.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for struct ext_link_map
+ This renames the solib-dsbt.c copy of "struct ext_link_map" to avoid
+ an ODR warning.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warning for struct field_info
+ This renames one of the instance of "struct field_info" to avoid an
+ ODR warning.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings for struct nextfield
+ "struct nextfield" is defined in multiple places in GDB. This patch
+ renames just the stabs one, leaving the DWARF one untouched.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ ODR warnings for struct symloc
+ "struct symloc" is defined in multiple spots in gdb, causing ODR
+ warnings. This patch renames these.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tom Tromey <tromey@adacore.com>
+
+ Fix ODR warning in observable.h
+ observable.h triggers an ODR warning because this line:
+
+ extern observable<struct target_ops */* target */> target_changed;
+
+ ... may be the only declaration of "struct target_ops" in scope
+ (depending on the particular .c file) -- and this declares it in a
+ namespace, resulting in confusion.
+
+ This patch fixes the problem by adding a forward declaration.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement the software_single_step gdbarch method
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/branch-to-self.exp"
+
+ there exist the following failed testcases:
+
+ FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout)
+ FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout)
+ FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)
+
+ Implement the software_single_step gdbarch method to decode the current
+ branch instruction and determine the address of the next instruction on
+ LoongArch to fix the above failed testcases.
+
+2022-06-02 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ gdb: Do not add empty sections to the section map
+ From: Ulrich Weigand <ulrich.weigand@de.ibm.com>
+
+ build_objfile_section_table () creates four synthetic sections per
+ objfile, which are collected by update_section_map () and passed to
+ std::sort (). When there are a lot of objfiles, for example, when
+ debugging JITs, the presence of these sections slows down the sorting
+ significantly.
+
+ The output of update_section_map () is used by find_pc_section (),
+ which can never return any of these sections: their size is 0, so they
+ cannot be accepted by bsearch_cmp ().
+
+ Filter them (and all the other empty sections) out in
+ insert_section_p (), which is used only by update_section_map ().
+
+2022-06-02 Jon Turney <jon.turney@dronecode.org.uk>
+
+ Fix a new warning on Cygwin
+ > ../../gdb/windows-nat.c: In function ‘windows_solib* windows_make_so(const char*, LPVOID)’:
+ > ../../gdb/windows-nat.c:714:12: error: declaration of ‘char name [512]’ shadows a parameter [-Werror=shadow=compatible-local]
+ > 714 | char name[SO_NAME_MAX_PATH_SIZE];
+ > | ^~~~
+ > ../../gdb/windows-nat.c:655:30: note: shadowed declaration is here
+ > 655 | windows_make_so (const char *name, LPVOID load_addr)
+ > | ~~~~~~~~~~~~^~~~
+
+ Fix Cygwin build after 85b25bd9
+ Fix Cygwin build after 85b25bd9 ("Simplify windows-nat.c solib handling").
+
+ Fix Cygwin build after 0578e87f
+ Fix Cygwin build after 0578e87f ("Remove some globals from
+ nat/windows-nat.c"). Update code under ifdef __CYGWIN__ for globals
+ moved to members of struct windows_process_info.
+
+ Fix Cygwin build after fcab5839
+ Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows
+ in gdbserver"). That change moves code from gdb/windows-nat.c to
+ gdb/nat/windows-nat.c, but doesn't add the required typedefs and
+ includes for parts of that code under ifdef __CYGWIN__.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ Re: ubsan: signed integer overflow in atof_generic
+ Oops.
+
+ * atof-generic.c: Include limits.h.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ ubsan: signed integer overflow in atof_generic
+ Fix the signed overflows by using unsigned variables and detect
+ overflow at BUG! comment.
+
+ * atof-generic.c (atof_generic): Avoid signed integer overflow.
+ Return ERROR_EXPONENT_OVERFLOW if exponent overflows a long.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ asan: uninit write _bfd_ecoff_write_object_contents
+ * ecoff.c (_bfd_ecoff_write_object_contents): zalloc reloc_buff.
+
+ asan: null deref in coff_write_relocs
+ * coffcode.h (coff_write_relocs): Don't deref NULL howto.
+
+ ubsan: undefined shift in frag_align_code
+ * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed integer
+ overflow.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ gas read_a_source_file #APP processing
+ This fixes some horrible code using do_scrub_chars. What we had ran
+ text through do_scrub_chars twice, directly in read_a_source_file and
+ again via the input_scrub_include_sb call. That's silly, and since
+ do_scrub_chars is a state machine, possibly wrong. More silliness is
+ evident in the temporary malloc'd buffer for do_scrub_chars output,
+ which should have been written directly to sbuf.
+
+ So, get rid of the do_scrub_chars call and support functions, leaving
+ scrubbing to input_scrub_include_sb. I did wonder about #NO_APP
+ overlapping input_scrub_next_buffer buffers, but that should only
+ happen if the string starts in one file and finishes in another.
+
+ * read.c (scrub_string, scrub_string_end): Delete.
+ (scrub_from_string): Delete.
+ (read_a_source_file): Rewrite #APP processing.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ sb_scrub_and_add_sb not draining input string buffer
+ It is possible for sb_scrub_and_add_sb to not consume all of the input
+ string buffer. If this happens for reasons explained in the comment,
+ do_scrub_chars can leave pointers to the string buffer for the next
+ call. This patch fixes that by ensuring the input is drained. Note
+ that the behaviour for an empty string buffer is also changed,
+ avoiding another do_scrub_chars bug where empty input and single char
+ sized output buffers could result in a write past the end of the
+ output.
+
+ sb.c (sb_scrub_and_add_sb): Loop until all of input sb is
+ consumed.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow in dwarf2_directive_filename
+ Seen with .file 4294967289 "xxx.c"
+
+ * dwarf2dbg.c (assign_file_to_slot): Catch more cases of integer
+ overflow. Make param i an unsigned int.
+
+2022-06-02 Alan Modra <amodra@gmail.com>
+
+ asan: NULL deref in scan_unit_for_symbols
+ Since commit b43771b045 it has been possible to look up addresses
+ that match a unit with errors, since ranges are added to a trie while
+ the unit is being parsed. On error, parse_comp_unit leaves
+ first_child_die_ptr NULL which results in a NULL info_ptr being passed
+ to scan_unit_for_symbols. Fix this by setting unit->error.
+
+ Also wrap some overlong lines, and fix some formatting errors.
+
+ * dwarf2.c: Formatting.
+ (parse_comp_unit): Set unit->error on err_exit path.
+
+2022-06-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix warning in foreach_arch selftests
+ When running the selftests, I run into:
+ ...
+ $ gdb -q -batch -ex "maint selftest"
+ ...
+ Running selftest execute_cfa_program::aarch64:ilp32.
+ warning: A handler for the OS ABI "GNU/Linux" is not built into this
+ configuration of GDB. Attempting to continue with the default aarch64:ilp32
+ settings.
+ ...
+ and likewise for execute_cfa_program::i8086 and
+ execute_cfa_program::ia64-elf32.
+
+ The warning can easily be reproduced outside the selftests by doing:
+ ...
+ $ gdb -q -batch -ex "set arch aarch64:ilp32"
+ ...
+ and can be prevented by first doing "set osabi none".
+
+ Fix the warning by setting osabi to none while doing selftests that iterate
+ over all architectures.
+
+ Tested on x86_64-linux.
+
+2022-06-01 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.current_language and gdb.Frame.language
+ This adds the gdb.current_language function, which can be used to find
+ the current language without (1) ever having the value "auto" or (2)
+ having to parse the output of "show language".
+
+ It also adds the gdb.Frame.language, which can be used to find the
+ language of a given frame. This is normally preferable if one has a
+ Frame object handy.
+
+2022-06-01 Yvan Roux <yvan.roux@foss.st.com>
+
+ [arm] Don't use special treatment for PC
+ In an exception frame the PC register is extracted from the stack
+ just like other base registers, so there is no need for a special
+ treatment.
+
+ [arm] Add support for FPU registers in prologue unwinder
+ The prologue unwinder had support for FPU registers, but only to
+ calculate the correct offset on the stack, the values were not saved.
+
+2022-06-01 Yvan Roux <yvan.roux@foss.st.com>
+
+ [arm] d0..d15 are 64-bit each, not 32-bit
+ When unwinding the stack, the floating point registers d0 to d15
+ need to be handled as double words, not words.
+
+ Only the first 8 registers have been confirmed fixed with this patch
+ on a STM32F407-DISC0 board, but the upper 8 registers on Cortex-M33
+ should be handled in the same way.
+
+ The test consisted of running a program compiled with float-abi=hard.
+ In the main function, a function taking a double as an argument was
+ called. After the function call, a hardware timer was used to
+ trigger an interrupt.
+
+ In the debug session, a breakpoint was set in the function called
+ from main to verify the content of the registers using "info float"
+ and another breakpoint in the interrupt handler was used to check
+ the same registers using "info float" on frame 2 (the frame just
+ before the dummy frame created for the signal handler in gdb).
+
+2022-06-01 Yvan Roux <yvan.roux@foss.st.com>
+
+ [arm] Cleanup: use hex for offsets
+ Changed offset from decimal to hex to match architecture reference
+ manual terminology and keep coherency with the rest of the code.
+
+2022-06-01 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ gdb:csky save fpu and vdsp info to struct csky_gdbarch_tdep
+ First, add three variables fpu_abi, fpu_hardfp and vdsp_version
+ to csky_gdbarch_tdep. They will be initialized from info.abfd in
+ cskg_gdbarch_init.
+
+ Now, they are just used to find a candidate among the list of pre-declared
+ architectures
+
+ Later, they will be used in gdbarch_return_value and gdbarch_push_dummy_call
+ for funtions described below:
+ fpu_abi: to check if the bfd is using VAL_CSKY_FPU_ABI_HARD or
+ VAL_CSKY_FPU_ABI_SOFT
+ fpu_hardfp: to check if the bfd is using VAL_CSKY_FPU_HARDFP_SINGLE
+ or VAL_CSKY_FPU_HARDFP_DOUBLE
+ vdsp_version: to check if a function is returned with CSKY_VRET_REGNUM
+
+2022-06-01 Alan Modra <amodra@gmail.com>
+
+ Re: use libiberty xmalloc in bfd/doc/chew.c
+ We can't use libiberty.a in chew. libiberty is a host library, chew
+ a build program. Partly revert commit 7273d78f3f7a, instead define
+ local versions of the libiberty functions. ansidecl.h also isn't
+ needed.
+
+ * doc/chew.c: Don't include libiberty.h or ansidecl.h.
+ (xmalloc, xrealloc, xstrdup): New functions.
+ * doc/local.mk (LIBIBERTY): Don't define or use.
+ * Makefile.in: Regenerate.
+
+2022-06-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-06-01 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Properly handle IFUNC function pointer reference
+ Update
+
+ commit 68c4956b1401de70173848a6bdf620cb42fa9358
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Tue Apr 26 09:08:54 2022 -0700
+
+ x86: Properly handle function pointer reference
+
+ to properly handle IFUNC function pointer reference. Since IFUNC symbol
+ value is only known at run-time, set pointer_equality_needed for IFUNC
+ function pointer reference in PDE so that it will be resolved to its PLT
+ entry directly.
+
+ bfd/
+
+ PR ld/29216
+ * elf32-i386.c (elf_i386_scan_relocs): Set pointer_equality_needed
+ for IFUNC function pointer reference in PDE.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+ ld/
+
+ PR ld/29216
+ * testsuite/ld-ifunc/ifunc.exp: Run PR ld/29216 test.
+ * testsuite/ld-ifunc/pr29216.c: New file.
+
+2022-05-31 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Ajdust more tests for opcodes/i386: remove trailing whitespace
+ This fixes:
+
+ FAIL: Build ifunc-1a with -z ibtplt
+ FAIL: Build ifunc-1a with PIE -z ibtplt
+ FAIL: Build libno-plt-1b.so
+ FAIL: No PLT (dynamic 1a)
+ FAIL: No PLT (dynamic 1b)
+ FAIL: No PLT (dynamic 1c)
+ FAIL: No PLT (static 1d)
+ FAIL: No PLT (PIE 1e)
+ FAIL: No PLT (PIE 1f)
+ FAIL: No PLT (PIE 1g)
+ FAIL: No PLT (dynamic 1h)
+ FAIL: No PLT (dynamic 1i)
+ FAIL: No PLT (static 1j)
+
+ * ld-i386/libno-plt-1b.dd: Remove trailing whitespaces.
+ * ld-i386/no-plt-1a.dd: Likewise.
+ * ld-i386/no-plt-1b.dd: Likewise.
+ * ld-i386/no-plt-1c.dd: Likewise.
+ * ld-i386/no-plt-1d.dd: Likewise.
+ * ld-i386/no-plt-1e.dd: Likewise.
+ * ld-i386/no-plt-1f.dd: Likewise.
+ * ld-i386/no-plt-1g.dd: Likewise.
+ * ld-i386/no-plt-1h.dd: Likewise.
+ * ld-i386/no-plt-1i.dd: Likewise.
+ * ld-i386/no-plt-1j.dd: Likewise.
+ * ld-i386/plt-main-ibt.dd: Likewise.
+ * ld-i386/plt-pie-ibt.dd: Likewise.
+
+2022-05-31 Tom Tromey <tom@tromey.com>
+
+ Use unique_ptr for objfiles
+ A while back, I changed objfiles to be held via a shared_ptr. The
+ idea at the time was that this was a step toward writing to the index
+ cache in the background, and this would let gdb keep a reference alive
+ to do so. However, since then we've rewritten the DWARF reader, and
+ the new index can do this without requiring a shared pointer -- in
+ fact there are patches pending to implement this.
+
+ This patch switches objfile management to unique_ptr, which makes more
+ sense now.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: fixup common-block.exp for intel compilers
+ The order in which the variables in info common and info locals are
+ displayed is compiler (and dwarf) dependent. While all symbols should
+ be displayed the order is not fixed.
+
+ I added a gdb_test_multiple that lets ifx and ifort pass in cases where
+ only the order differs.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers
+ When value-printing a pointer within GDB by default GDB will look for
+ defined symbols residing at the address of the pointer. For the given
+ test the Intel/LLVM compiler stacks both display a symbol associated
+ with a printed pointer while the gnu stack does not. This leads to
+ failures in the test when running the test with CC_FOR_TARGET='clang'
+ CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'"
+
+ (gdb) b 37
+ (gdb) r
+ (gdb) f 6
+ (gdb) info args
+ a = 1
+ b = 2
+ c = 3
+ d = 4 + 5i
+ f = 0x419ed0 "abcdef"
+ g = 0x4041a0 <.BSS4>
+
+ or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'"
+
+ (gdb) b 37
+ (gdb) r
+ (gdb) f 6
+ (gdb) info args
+ a = 1
+ b = 2
+ c = 3
+ d = 4 + 5i
+ f = 0x52eee0 "abcdef"
+ g = 0x4ca210 <mixed_func_1a_$OBJ>
+
+ For the compiled binary the Intel/LLVM compilers both decide to move the
+ local variable g into the .bss section of their executable. The gnu
+ stack will keep the variable locally on the stack and not define a
+ symbol for it.
+
+ Since the behavior for Intel/LLVM is actually expected I adapted the
+ testcase at this point to be a bit more allowing for other outputs.
+ I added the optional "<SYMBOLNAME>" to the regex testing for g.
+
+ The given changes reduce the test fails for Intel/LLVM stack by 4 each.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
+ While testing mixed-lang-stack I realized that valgrind actually
+ complained about a double free in the test.
+
+ All done
+ ==2503051==
+ ==2503051== HEAP SUMMARY:
+ ==2503051== in use at exit: 0 bytes in 0 blocks
+ ==2503051== total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated
+ ==2503051==
+ ==2503051== All heap blocks were freed -- no leaks are possible
+ ==2503051==
+ ==2503051== For lists of detected and suppressed errors, rerun with: -s
+ ==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+
+ Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an
+ object "derived_type obj" goes on the stack which is then passed-by-value
+ (so copied) to mixed_func_1g. The default copy-ctor will be called but,
+ since derived_type contains a heap allocated string and the copy
+ constructor is not implemented it will only be able to shallow copy the
+ object. Right after each of the functions the object gets freed - on the
+ other hand the d'tor of derived_type actually is implemented and calls
+ free on the heap allocated string which leads to a double free. Instead
+ of obeying the rule of 3/5 I just got rid of all that since it does not
+ serve the test. The string is now just a const char* = ".." object
+ member.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: allow additional completions in module.exp
+ For ifort, ifx, and flang the tests "complete modm" and "complete
+ modmany" fail. This is because all three emit additional completion
+ suggestions. These additional suggestions have their origin in symbols
+ emitted by the compilers which can also be completed from the respective
+ incomplete word (modm or modmany). For this specific example gfortran
+ does not emit any additional symbols.
+
+ For example, in this test the linkage name for var_a in ifx is
+ "modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
+ Since modmany_mp_var_a can be completed from modm and also modmany they
+ will get displayed, while gfortran's symbol starts with "__" and thus will
+ be ignored (it cannot be a completion of a word starting with "m").
+
+ Similar things happen in flang and ifort. Some example output is shown
+ below:
+
+ FLANG
+ (gdb) complete p modm
+ p modmany
+ p modmany::var_a
+ p modmany::var_b
+ p modmany::var_c
+ p modmany::var_i
+ p modmany_
+
+ IFX/IFORT
+ (gdb) complete p modm
+ p modmany
+ p modmany._
+ p modmany::var_a
+ p modmany::var_b
+ p modmany::var_c
+ p modmany::var_i
+ p modmany_mp_var_a_
+ p modmany_mp_var_b_
+ p modmany_mp_var_c_
+ p modmany_mp_var_i_
+
+ GFORTRAN
+ (gdb) complete p modm
+ p modmany
+ p modmany::var_a
+ p modmany::var_b
+ p modmany::var_c
+ p modmany::var_i
+
+ I want to emphasize: for Fortran (and also C/C++) the complete command
+ does not actually check whether its suggestions make sense - all it does
+ is look for any symbol (in the minimal symbols, partial symbols etc.)
+ that a given substring can be completed to (meaning that the given substring
+ is the beginning of the symbol). One can easily produce a similar
+ output for the gfortran compiled executable. For this look at the
+ slightly modified "complete p mod" in gfortran:
+
+ (gdb) complete p mod
+ p mod1
+ p mod1::var_const
+ ...
+ p mod_1.c
+ p modcounter
+ p mode_t
+ p modf
+ ...
+ p modify_ldt
+ p modmany
+ p modmany::var_a
+ p modmany::var_b
+ p modmany::var_c
+ p modmany::var_i
+ p module
+ p module.f90
+ p module_entry
+ p moduse
+ p moduse::var_x
+ p moduse::var_y
+
+ Many of the displayed symbols do not actually work with print:
+
+ (gdb) p mode_t
+ Attempt to use a type name as an expression
+ (gdb) p mod_1.c
+ No symbol "mod_1" in current context.
+ (gdb)
+
+ I think that in the given test the output for gfortran only looks nice
+ "by chance" rather than is actually expected. Expected is any output
+ that also contains the completions
+
+ p modmany
+
+ p modmany::var_a
+ p modmany::var_b
+ p modmany::var_c
+ p modmany::var_i
+
+ while anythings else can be displayed as well (depending on the
+ compiler and its emitted symbols).
+
+ This, I'd consider all three outputs as valid and expected - one is just
+ somewhat lucky that gfortran does not produce any additional symbols that
+ got matched.
+
+ The given patch improves test performance for all three compilers
+ by allowing additional suggested completions inbetween and after
+ the two given blocks in the test. I did not allow additional print
+ within the modmany_list block since the output is ordered alphabetically
+ and there should normally not appear any additional symbols there.
+
+ For flang/ifx/ifort I each see 2 failures less (which are exactly the two
+ complete tests).
+
+ As a side note and since I mentioned C++ in the beginning: I also tried
+ the gdb.cp/completion.exp. The output seems a bit more reasonable,
+ mainly since C++ actually has a demangler in place and linkage symbols
+ do not appear in the output of complete. Still, with a poor enough
+ to-be-completed string one can easily produce similar results:
+
+ (gdb) complete p t
+ ...
+ p typeinfo name for void
+ p typeinfo name for void const*
+ p typeinfo name for void*
+ p typeinfo name for wchar_t
+ p typeinfo name for wchar_t const*
+ p typeinfo name for wchar_t*
+ p t *** List may be truncated, max-completions reached. ***
+ (gdb) p typeinfo name for void*
+ No symbol "typeinfo" in current context.
+ (gdb) complete p B
+ p BACK_SLASH
+ p BUF_FIRST
+ p BUF_LAST
+ ...
+ p Base
+ p Base::Base()
+ p Base::get_foo()
+ p bad_key_err
+ p buf
+ p buffer
+ p buffer_size
+ p buflen
+ p bufsize
+ p build_charclass.isra
+ (gdb) p bad_key_err
+ No symbol "bad_key_err" in current context.
+
+ (compiled with gcc/g++ and breaking at main).
+
+ This patch is only about making the referenced test more 'fair' for the
+ other compilers. Generally, I find the behavior of complete a bit
+ confusing and maybe one wants to change this at some point but this
+ would be a bigger task.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: fix info-types for intel compilers
+ This info-types.exp test case had a few issues that this patch fixes.
+
+ First, the emitted symbol character(kind=1)/character*1 (different
+ compilers use different naming converntions here) which is checkedin the
+ test is not actually expected given the test program. There is no
+ variable of that type in the test. Still, gfortran emits it for every
+ Fortran program there is. The reason is the way gfortran handles Fortran's
+ named main program. It generates a wrapper around the Fortran program
+ that is quite similar to a C main function. This C-like wrapper has
+ argc and argv arguments for command line argument passing and the argv
+ pointer type has a base type character(kind=1) DIE emitted at CU scope.
+
+ Given the program
+
+ program prog
+ end program prog
+
+ the degbug info gfortran emits looks somewhat like
+
+ <0><c>: Abbrev Number: 3 (DW_TAG_compile_unit)
+ ...
+ <1><2f>: Abbrev Number: 4 (DW_TAG_subprogram)
+ <30> DW_AT_external : 1
+ <30> DW_AT_name : (indirect string, ...): main
+ ...
+ <2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter)
+ <52> DW_AT_name : (indirect string, ...): argc
+ ...
+ <2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
+ <5e> DW_AT_name : (indirect string, ...): argv
+ ...
+ <62> DW_AT_type : <0x77>
+ ...
+ <2><6a>: Abbrev Number: 0
+ ...
+ <1><77>: Abbrev Number: 6 (DW_TAG_pointer_type)
+ <78> DW_AT_byte_size : 8
+ <79> DW_AT_type : <0x7d>
+ <1><7d>: Abbrev Number: 2 (DW_TAG_base_type)
+ <7e> DW_AT_byte_size : 1
+ <7f> DW_AT_encoding : 8 (unsigned char)
+ <80> DW_AT_name : (indirect string, ...): character(kind=1)
+ <1><84>: Abbrev Number: 7 (DW_TAG_subprogram)
+ <85> DW_AT_name : (indirect string, ...): prog
+ ...
+
+ Ifx and flang do not emit any debug info for a wrapper main method so
+ the type is missing here. There was the possibility of actually adding
+ a character*1 type variable to the Fortran executable, but both, ifx and
+ gfortran chose to emit this variable's type as a DW_TAG_string_type of
+ length one (instead of a character(kind=1), or whatever the respective
+ compiler naming convention is). While string types are printed as
+ character*LENGHT in the fortran language part (e.g. when issuing a
+ 'ptype') they do not generate any symbols inside GDB. In read.c it says
+
+ /* These dies have a type, but processing them does not create
+ a symbol or recurse to process the children. Therefore we can
+ read them on-demand through read_type_die. */
+
+ So they did not add any output to 'info types'. Only flang did emit a
+ character type here.
+ As adding a type would have a) not solved the problem for ifx and would
+ have b) somehow hidden the curious behavior of gfortran, instead, the
+ check for this character type was chagened to optional with the
+ check_optional_entry to allow for the symbols's absence and to allow
+ flang and ifx to pass this test as well.
+
+ Second, the line checked for s1 was hardcoded as 37 in the test. Given
+ that the type is actually defined on line 41 (which is what is emitted by
+ ifx) it even seems wrong. The line check for s1 was changed to actually
+ check for 41 and a gfortran bug has been filed here
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
+
+ The test is now marked as xfail for gfortran.
+
+ Third, the whole test of checking for the 'Type s1' in info types seemed
+ questionable. The type s1 is declared iside the scope of the Fortran
+ program info_types_test. Its DIE however is emitted as a child of the
+ whole compilation unit making it visible outside of the program's scope.
+ The 'info types' command checks for types stored in the GLOBAL_BLOCK,
+ or STATIC_BLOCKm wgucm according to block.h
+
+ The GLOBAL_BLOCK contains all the symbols defined in this compilation
+ whose scope is the entire program linked together.
+ The STATIC_BLOCK contains all the symbols whose scope is the
+ entire compilation excluding other separate compilations.
+
+ so for gfortran, the type shows up in the output of 'info types'. For
+ flang and ifx on the other hand this is not the case. The two compilers
+ emit the type (correctly) as a child of the Fortran program, thus not
+ adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK. A bug has
+ been opened for the gfortran scoping issue:
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
+
+ While the most correct change might have been removing the check for s1,
+ the change made here was to only check for this type in case of gfortran
+ being used as the compiler, as this check also covers the declaration
+ line issue mentioned above. A comment was added to maybe remove this
+ check once the scoping issue is resolved (and it starts to fail with
+ newer gfortran versions). The one used to test these changes was 13.0.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite/lib: add check_optional_entry for GDBInfoSymbols
+ There was already a similar functionality for the GDBInfoModuleSymbols.
+ This just extends the GDBInfoSymbols. We will use this feature in a
+ later commit to make a testcase less GNU specific and more flexible for
+ other compilers.
+
+ Namely, in gdb.fortran/info-types.exp currenlty
+ GDBInfoSymbols::check_entry is used to verify and test the output of the
+ info symbols command. The test, however was written with gfortran as a
+ basis and some of the tests are not fair with e.g. ifx and ifort as
+ they test for symbols that are not actually required to be emitted. The
+ lines
+ GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
+ and
+ GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
+
+ check for types that are either not used in the source file (character1)
+ or should not be emitted by the compiler at global scope (s1) thus no
+ appearing in the info symbols command. In order to fix this we will
+ later use the newly introduced check_optional_entry over check_entry.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort
+ In order for ifx and ifort to emit all debug entries, even for unused
+ parameters in modules we have to define the '-debug-parameters all' flag.
+
+ This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis
+ The test was earlier not using the compiler dependent type print system
+ in fortran.exp. I changed this. It should generally improve the test
+ performance for different compilers. For ifx and gfortran I do not see
+ any failures.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ testsuite, fortran: add required external keyword
+ Currenlty, ifx/ifort cannot compile the given executable as it is not
+ valid Fortran. It is missing the external keyword on the
+ no_arg_subroutine. Gfortran compiles the example but this is actually
+ a bug and there is an open gcc ticket for this here:
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
+
+ Adding the keyword does not change the gfortran compiling of the example.
+ It will, however, prevent a future fail once 50377 has been addressed.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: disable charset.exp for intel compilers
+ The test specifically tests for the Fortran CHARACTER(KIND=4) which is
+ not available in ifx/ifort.
+
+ Since the other characters are also printed elsewhere, we disable this
+ test for the unsupported compilers.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: rename intel next gen c/cpp compilers
+ The name for icx and icpx in the testsuite was earlier set to 'intel-*'
+ by the compiler identification. This commit changes this to 'icx-*'.
+
+ Note, that currently these names are not used within the testsuite so no
+ tests have to be adapted here.
+
+2022-05-31 Cristian Sandu <cristian.sandu@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: add Fortran compiler identification to GDB
+ This commit adds a separate Fortran compiler identification mechanism to
+ the testsuite, similar to the existing one for C/C++. Before this
+ change, the options and version for the Fortran compiler specified when
+ running the testsuite with F90_FOR_TARGET set, was detected via its
+ respective C compiler. So running the testsuite as
+
+ make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx
+
+ or even
+
+ make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx
+
+ would use the gcc compiler inside the procedures get_compiler_info and
+ test_compiler_info to identify compiler flags and the compiler version.
+ This could sometimes lead to unpredictable outputs. It also limited
+ testsuite execution to combinations where C and Fortran compiler would
+ come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
+ clang/flang ..). This commit enables GDB to detect C and Fortran
+ compilers independently of each other.
+
+ As most/nearly all Fortran compilers have a mechanism for preprocessing
+ files in a C like fashion we added the exact same meachnism that already
+ existed for C/CXX. We let GDB preprocess a file with the compilers
+ Fortran preprocessor and evaluate the preprocessor defined macros in that
+ file.
+
+ This enables GDB to properly run heterogeneous combinations of C and
+ Fortran compilers such as
+
+ CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'
+
+ or enables one to run the testsuite without specifying a C compiler as in
+
+ make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
+ make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'
+
+ On the other hand this also requires one to always specify a
+ identification mechanism for Fortran compilers in the compiler.F90 file.
+
+ We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
+ IFORT, and ARMFLANG for now.
+
+ Classic and LLVM flang were each tested with their latest releases on
+ their respective release pages. Both get recognized by the new compiler
+ identification and we introduced the two names flang-classic and
+ flang-llvm to distinguish the two. While LLVM flang is not quite mature
+ enough yet for running the testsuite we still thought it would be a good
+ idea to include it already. For this we added a case for the fortran_main
+ procedure. LLVM flang uses 'MAIN__' as opposed to classic flang which
+ uses 'MAIN_' here.
+
+ We did not have the possibility to test ARMFLANG - the versioning scheme
+ here was extracted from its latest online documentation.
+
+ We changed the test_compiler_info procedure to take another optional
+ argument, the language string, which will be passed though to the
+ get_compiler_info procedure. Passing 'f90' or 'c++' here will then
+ trigger the C++/Fortran compiler identification within
+ get_compiler_info. The latter procedure was extended to also handle
+ the 'f90' argument (similarly to the already existing 'c++' one).
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: move getting_compiler_info to front of gdb_compile
+ The procedure gdb_compile queries its options via
+
+ [lsearch -exact $options getting_compiler_info]
+
+ to check whether or not it was called in with the option
+ getting_compiler_info. If it was called with this option it would
+ preprocess some test input to try and figure out the actual compiler
+ version of the compiler used. While doing this we cannot again try to
+ figure out the current compiler version via the 'getting_compiler_info'
+ option as this would cause infinite recursion. As some parts of the
+ procedure do recursively test for the compiler version to e.g. set
+ certain flags, at several places gdb_compile there are checks for the
+ getting_compiler_info option needed.
+
+ In the procedure, there was already a variable 'getting_compiler_info'
+ which was set to the result of the 'lsearch' query and used instead of
+ again and again looking for getting_compiler_info in the procedure
+ options. But, this variable was actually set too late within the code.
+ This lead to a mixture of querying 'getting_compiler_info' or
+ doing an lserach on the options passed to the procedure.
+
+ I found this inconsistent and instead moved the variable
+ getting_compiler_info to the front of the procedure. It is set to true
+ or false depending on whether or not the argument is found in the
+ procedure's options (just as before) and queried instead of doing an
+ lsearch on the procedure options in the rest of the procedure.
+
+2022-05-31 Felix Willgerodt <felix.willgerodt@intel.com>
+ Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: Fix fortran types for Intel compilers.
+ Newer Intel compilers emit their dwarf type name in a slightly different
+ format. Therefore, this needs adjustment to make more tests pass in the
+ Fortran testsuite.
+
+2022-05-31 Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
+
+ gdb/testsuite: Use -module option for Intel Fortran compilers
+ The '-J' option is not supported in Intel compilers (ifx and ifort).
+ The Intel version of the flag is '-module' which serves the same purpose.
+
+2022-05-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: remove F77_FOR_TARGET support
+ The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
+ procedure were removed in this commit
+
+ commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
+ Author: Tom Tromey <tromey@redhat.com>
+ Date: Wed Jun 29 17:50:47 2011 +0000
+
+ over 10 years ago. The last .f files in the testsuite by now are all
+ being compiled by passing 'f90' to the GDB compile, thus only actually
+ using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
+ Gfortran in this case is backwards compatible with most f77 code as
+ claimed on gcc.gnu.org/fortran.
+
+ The reason we'd like to get rid of this now is, that we'll be
+ implementing a Fortran compiler identification mechanism, similar to the
+ C/Cpp existing ones. It would be using the Fortran preprocessor macro
+ defines to identify the Fortran compiler version at hand. We found it
+ inconsequent to only implement this for f90 but, on the other hand, f77
+ seems deprecated. So, with this commit we remove the remaining lines for
+ its support.
+
+2022-05-31 Pedro Alves <pedro@palves.net>
+
+ Improve clear command's documentation
+ Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
+
+ Change-Id: I9440052fd28f795d6f7c93a4576beadd21f28885
+
+2022-05-31 Pedro Alves <pedro@palves.net>
+
+ Clarify why we unit test matching symbol names with 0xff characters
+ In the name matching unit tests in gdb/dwarf2/read.c, explain better
+ why we test symbols with \377 / 0xff characters (Latin1 'ÿ').
+
+ Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e
+
+2022-05-31 Pedro Alves <pedro@palves.net>
+
+ Improve break-range's documentation
+ Change-Id: Iac26e1d2e7d8dc8a7d9516e6bdcc5c3fc4af45c8
+
+ Explicitly mention yet-unloaded shared libraries in location spec examples
+ Change-Id: I05639ddb3bf620c7297b57ed286adc3aa926b7b6
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ sparc64 segfault in finish_dynamic_symbol
+ SYMBOL_REFERENCES_LOCAL can return true for undefined symbols. This
+ can result in a segfault when running sparc64 ld/testsuite/ld-vsb
+ tests that expect a failure.
+
+ * elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't
+ access u.def.section on non-default visibility undefined symbol.
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ ia64 gas: Remove unnecessary init
+ The whole struct is cleared by alloc_record.
+
+ * config/tc-ia64.c (output_prologue, output_prologue_gr): Don't
+ zero r.record.r.mask.
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ v850_elf_set_note prototype
+ v850_elf_set_note is declared using an unsigned int note param in
+ elf32-v850.h but defined with enum c850_notes note in elf32-v850.c.
+ Current mainline gcc is warning about this. Huh.
+
+ * elf32-v850.c (v850_elf_set_note): Make "note" param an
+ unsigned int.
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ Import libiberty from gcc
+ PR 29200
+ include/
+ * ansidecl.h,
+ * demangle.h: Import from gcc.
+ libiberty/
+ * cp-demangle.c,
+ * testsuite/demangle-expected: Import from gcc.
+
+2022-05-31 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve duplicate test name in gdb.trace/signal.exp
+ Spotted a duplicate test name in gdb.trace/signal.exp, resolved in
+ this commit by making use of 'with_test_prefix'.
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ Ajdust more tests for opcodes/i386: remove trailing whitespace
+ git commit 202be274a4 also missed adjusting a few testsuite files.
+ This fixes
+ i686-vxworks +FAIL: VxWorks shared library test 1
+ i686-vxworks +FAIL: VxWorks executable test 1 (dynamic)
+
+2022-05-31 Alan Modra <amodra@gmail.com>
+
+ Trailing spaces in objdump -r header
+ git commit 202be274a4 went a little wild in removing trailing spaces
+ in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing
+ x86_64-w64-mingw32 +FAIL: i386 secrel reloc
+ x86_64-w64-mingw32 +FAIL: i386 secidx reloc
+
+ I could have just replaced the trailing space, but let's fix the
+ objdump output instead. Touches lots of testsuite files.
+
+2022-05-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-30 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix gdb.trace/signal.exp on x86
+ Patch
+
+ 202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands")
+
+ causes this regression:
+
+ FAIL: gdb.trace/signal.exp: find syscall insn in kill
+
+ It's because the test still expects to match a whitespace after the
+ instruction, which the patch mentioned above removed. Remove the
+ whitespaces for the regexp.
+
+ Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428
+
+2022-05-30 Pedro Alves <pedro@palves.net>
+
+ gdb/manual: Introduce location specs
+ The current "Specify Location" section of the GDB manual starts with:
+
+ "Several @value{GDBN} commands accept arguments that specify a location
+ of your program's code."
+
+ And then, such commands are documented as taking a "location"
+ argument. For example, here's a representative subset:
+
+ @item break @var{location}
+ @item clear @var{location}
+ @item until @var{location}
+ @item list @var{location}
+ @item edit @var{location}
+ @itemx info line @var{location}
+ @item info macros @var{location}
+ @item trace @var{location}
+ @item info scope @var{location}
+ @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
+
+ The issue here is that "location" isn't really correct for most of
+ these commands. Instead, the "location" argument is really a
+ placeholder that represent an umbrella term for all of the
+ "linespecs", "explicit location", and "address location" input
+ formats. GDB parses these and then finds the actual code locations
+ (plural) in the program that match. For example, a "location"
+ specified like "-function func" will actually match all the code
+ locations in the program that correspond to the address/file/lineno of
+ all the functions named "func" in all the loaded programs and shared
+ libraries of all the inferiors. A location specified like "-function
+ func -label lab" matches all the addresses of C labels named "lab" in
+ all functions named "func". Etc.
+
+ This means that several of the commands that claim they accept a
+ "location", actually end up working with multiple locations, and the
+ manual doesn't explain that all that well. In some cases, the command
+ will work with all the resolved locations. In other cases, the
+ command aborts with an error if the location specification resolves to
+ multiple locations in the program. In other cases, GDB just
+ arbitrarily and silently picks whatever is the first resolved code
+ location (which sounds like should be improved).
+
+ To clarify this, I propose we use the term "Location Specification",
+ with shorthand "locaction spec", when we're talking about the user
+ input, the argument or arguments that is/are passed to commands to
+ instruct GDB how to find locations of interest. This is distinct from
+ the actual code locations in the program, which are what GDB finds
+ based on the user-specified location spec. Then use "location
+ specification or the shorter "location spec" thoughout instead of
+ "location" when we're talking about the user input.
+
+ Thus, this commit does the following:
+
+ - renames the "Specify Location" section of the manual to "Location
+ Specifications".
+
+ - It then introduces the term "Location Specification", with
+ corresponding shorthand "location spec", as something distinct from
+ an actual code location in the program. It explains what a concrete
+ code location is. It explains that a location specification may be
+ incomplete, and that may match multiple code locations in the
+ program, or no code location at all. It gives examples. Some
+ pre-existing examples were moved from the "Set Breaks" section, and
+ a few new ones that didn't exist yet were added. I think it is
+ better to have these centralized in this "Location Specification"
+ section, since all the other commands that accept a location spec
+ have an xref that points there.
+
+ - Goes through the manual, and where "@var{location}" was used for a
+ command argument, updated it to say "@var{locspec}" instead. At the
+ same time, tweaks the description of the affected commands to
+ describe what happens when the location spec resolves to more than
+ one location. Most commands just did not say anything about that.
+
+ One command -- "maint agent -at @var{location}" -- currently says it
+ accepts a "location", suggesting it can accept address and explicit
+ locations too, but that's incorrect. In reality, it only accepts
+ linespecs, so fix it accordingly.
+
+ One MI command -- "-trace-find line" -- currently says it accepts a
+ "line specification", but it can accept address and explicit
+ locations too, so fix it accordingly.
+
+ Special thanks goes to Eli Zaretskii for reviews and rewording
+ suggestions.
+
+ Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
+
+2022-05-30 Luis Machado <luis.machado@arm.com>
+
+ Move 64-bit BFD files from ALL_TARGET_OBS to ALL_64_TARGET_OBS
+ Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
+ properly.
+
+ --
+
+ loongarch-tdep.o: In function `loongarch_gdbarch_init':
+ binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
+ loongarch-tdep.o: In function `loongarch_fetch_instruction':
+ binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
+ loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
+ binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
+ binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
+ binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
+ binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
+ binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
+ binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'
+
+ --
+
+ Given the list of 64-bit BFD files in
+ opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
+ ALL_TARGET_OBS list is including files that should be included in
+ ALL_64_TARGET_OBS instead.
+
+ This patch accomplishes this and enables a 32-bit build with
+ "--enable-targets=all --disable-sim" to complete.
+
+ Moving the bpf, tilegx and loongarch files to the correct list means GDB can
+ find the correct disassembler function instead of finding a null pointer.
+
+ We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
+ make a 32-bit build with "--enable-targets=all" complete correctly
+
+2022-05-30 Luis Machado <luis.machado@arm.com>
+
+ Fix failing test for armeb-gnu-eabi
+ The following test fails on the armeb-gnu-eabi target:
+
+ FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension
+
+ This patch adjusts the expected output for big endian.
+
+2022-05-30 Alan Modra <amodra@gmail.com>
+
+ Use a union to avoid casts in bfd/doc/chew.c
+ This fixes -Wpedantic warnings in chew.c. Conversion between function
+ and object pointers is not guaranteed. They can even be different
+ sizes, not that we're likely to encounter build machines like that
+ nowadays.
+
+ PR 29194
+ * doc/chew.c (pcu): New union typedef.
+ (dict_type, pc): Use it here. Adjust uses of pc.
+ (add_to_definition): Make "word" param a pcu. Adjust all uses
+ of function.
+ (stinst_type): Delete.
+
+2022-05-30 Alan Modra <amodra@gmail.com>
+
+ use libiberty xmalloc in bfd/doc/chew.c
+ Catch out of memory.
+
+ * doc/chew.c: Include libibery.h.
+ (init_string_with_size, nextword): Replace malloc with xmalloc.
+ (newentry, add_to_definition): Likewise.
+ (catchar, catbuf): Replace realloc with xrealloc.
+ (add_intrinsic): Replace strdup with xstrdup.
+ * doc/local.mk (LIBIBERTY): Define.
+ (chew): Link against libiberty.
+ * Makefile.in: Regenerate.
+
+2022-05-30 Alan Modra <amodra@gmail.com>
+
+ Update K&R functions in bfd/doc/chew.c
+ * doc/chew.c: Update function definitions to ISO C, remove
+ now unnecessary prototypes.
+
+2022-05-30 Alan Modra <amodra@gmail.com>
+
+ Reorganise bfd/doc/chew.c a little
+ This also removes some unused variables, and deletes support for the
+ "var" keyword which isn't used and was broken. (No means to set
+ variables, and add_var used push_number inconsistent with its use
+ elsewhere.)
+
+ * doc/chew.c: Move typedefs before variables, variables before
+ functions.
+ (die): Move earlier.
+ (word_type, sstack, ssp): Delete.
+ (dict_type): Delete var field.
+ (add_var): Delete.
+ (compile): Remove "var" support.
+
+2022-05-30 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Add zhinx extension supports.
+ The zhinx extension is a sub-extension in zfinx, corresponding to
+ zfh extension but use GPRs instead of FPRs.
+
+ This patch expanded the zfh insn class define, since zfh and zhinx
+ use the same opcodes, thanks for Nelson's works.
+
+ changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
+ "riscv_multi_subset_supports_ext".
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
+ (riscv_multi_subset_supports_ext): New extensions.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/fp-zhinx-insns.d: New test.
+ * testsuite/gas/riscv/fp-zhinx-insns.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class): New INSN classes.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Modify INSN_CLASS.
+
+2022-05-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: improve formatting of help text for user defined commands
+ Consider this command defined in Python (in the file test-cmd.py):
+
+ class test_cmd (gdb.Command):
+ """
+ This is the first line.
+ Indented second line.
+ This is the third line.
+ """
+
+ def __init__ (self):
+ super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)
+
+ def invoke (self, arg, from_tty):
+ print ("In test-cmd")
+
+ test_cmd()
+
+ Now, within a GDB session:
+
+ (gdb) source test-cmd.py
+ (gdb) help test-cmd
+
+ This is the first line.
+ Indented second line.
+ This is the third line.
+
+ (gdb)
+
+ I think there's three things wrong here:
+
+ 1. The leading blank line,
+ 2. The trailing blank line, and
+ 3. Every line is indented from the left edge slightly.
+
+ The problem of course, is that GDB is using the Python doc string
+ verbatim as its help text. While the user has formatted the help text
+ so that it appears clear within the .py file, this means that the text
+ appear less well formatted when displayed in the "help" output.
+
+ The same problem can be observed for gdb.Parameter objects in their
+ set/show output.
+
+ In this commit I aim to improve the "help" output for commands and
+ parameters.
+
+ To do this I have added gdbpy_fix_doc_string_indentation, a new
+ function that rewrites the doc string text following the following
+ rules:
+
+ 1. Leading blank lines are removed,
+ 2. Trailing blank lines are removed, and
+ 3. Leading whitespace is removed in a "smart" way such that the
+ relative indentation of lines is retained.
+
+ With this commit in place the above example now looks like this:
+
+ (gdb) source ~/tmp/test-cmd.py
+ (gdb) help test-cmd
+ This is the first line.
+ Indented second line.
+ This is the third line.
+ (gdb)
+
+ Which I think is much neater. Notice that the indentation of the
+ second line is retained. Any blank lines within the help text (not
+ leading or trailing) will be retained.
+
+ I've added a NEWS entry to note that there has been a change in
+ behaviour, but I didn't update the manual. The existing manual is
+ suitably vague about how the doc string is used, so I think the new
+ behaviour is covered just as well by the existing text.
+
+2022-05-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init
+ Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
+ string in cmdpy_init (when creating a custom GDB command in Python).
+ I think this is all pretty straight forward, the only slight weirdness
+ is the removal of the call to free toward the end of this function.
+
+ Prior to this commit, if an exception was thrown after the GDB command
+ was created then we would (I think) end up freeing the documentation
+ string even though the command would remain registered with GDB, which
+ would surely lead to undefined behaviour.
+
+ After this commit we release the doc string at the point that we hand
+ it over to the command creation routines. If we throw _after_ the
+ command has been created within GDB then the doc string will be left
+ live. If we throw during the command creation itself (either from
+ add_prefix_cmd or add_cmd) then it is up to those functions to free
+ the doc string (I suspect we don't, but I think in general the
+ commands are pretty bad at cleaning up after themselves, so I don't
+ think this is a huge problem).
+
+2022-05-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with -mx32
+ gprofng/ChangeLog
+ 2022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/28983
+ PR gprofng/29143
+ * src/Experiment.cc (write_header): Fix argument for ctime.
+ Fix -Wformat= warnings.
+ * src/Dbe.cc: Likewise.
+ * src/DwarfLib.h: Fix [-Wsign-compare] warnings.
+ * src/Experiment.h: Likewise.
+ * src/ipc.cc: Fix -Wformat= warnings.
+
+2022-05-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-27 Tom Tromey <tom@tromey.com>
+
+ Fix crash with "maint print arc"
+ Luis noticed that "maint print arc" would crash, because the command
+ handler did not find "show" in the command name, violating an
+ invariant. This patch fixes the bug by changing the registration to
+ use add_basic_prefix_cmd instead.
+
+2022-05-27 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/i386: remove trailing whitespace from insns with zero operands
+ While working on another patch[1] I had need to touch this code in
+ i386-dis.c:
+
+ ins->obufp = ins->mnemonicendp;
+ for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
+ oappend (ins, " ");
+ oappend (ins, " ");
+ (*ins->info->fprintf_styled_func)
+ (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);
+
+ What this code does is add whitespace after the instruction mnemonic
+ and before the instruction operands.
+
+ The problem I ran into when working on this code can be seen by
+ assembling this input file:
+
+ .text
+ nop
+ retq
+
+ Now, when I disassemble, here's the output. I've replaced trailing
+ whitespace with '_' so that the issue is clearer:
+
+ Disassembly of section .text:
+
+ 0000000000000000 <.text>:
+ 0: 90 nop
+ 1: c3 retq___
+
+ Notice that there's no trailing whitespace after 'nop', but there are
+ three spaces after 'retq'!
+
+ What happens is that instruction mnemonics are emitted into a buffer
+ instr_info::obuf, then instr_info::mnemonicendp is setup to point to
+ the '\0' character at the end of the mnemonic.
+
+ When we emit the whitespace, this is then added starting at the
+ mnemonicendp position. Lets consider 'retq', first the buffer is
+ setup like this:
+
+ 'r' 'e' 't' 'q' '\0'
+
+ Then we add whitespace characters at the '\0', converting the buffer
+ to this:
+
+ 'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'
+
+ However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
+ initially, the buffer is setup like this:
+
+ 'x' 'c' 'h' 'g' '\0'
+
+ Then in NOP_Fixup we spot that we have an instruction that is an alias
+ for 'nop', and adjust the buffer to this:
+
+ 'n' 'o' 'p' '\0' '\0'
+
+ The second '\0' is left over from the original buffer contents.
+ However, when we rewrite the buffer, we don't afjust mnemonicendp,
+ which still points at the second '\0' character.
+
+ Now, when we insert whitespace we get:
+
+ 'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'
+
+ Notice the whitespace is inserted after the first '\0', so, when we
+ print the buffer, the whitespace is not printed.
+
+ The fix for this is pretty easy, I can change NOP_Fixup to adjust
+ mnemonicendp, but now a bunch of tests start failing, we now produce
+ whitespace after the 'nop', which the tests don't expect.
+
+ So, I could update the tests to expect the whitespace....
+
+ ...except I'm not a fan of trailing whitespace, so I'd really rather
+ not.
+
+ Turns out, I can pretty easily update the whitespace emitting code to
+ spot instructions that have zero operands and just not emit any
+ whitespace in this case. So this is what I've done.
+
+ I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
+ probably a good thing, though this is not really required any more.
+
+ I've then updated all the tests that I saw failing to adjust the
+ expected patterns to account for the change in whitespace.
+
+ [1] https://sourceware.org/pipermail/binutils/2022-April/120610.html
+
+2022-05-27 Alan Modra <amodra@gmail.com>
+
+ Replace bfd_hostptr_t with uintptr_t
+ bfd_hostptr_t is defined as a type large enough to hold either a long
+ or a pointer. It mostly appears in the coff backend code in casts.
+ include/coff/internal.h struct internal_syment and union
+ internal_auxent have the only uses in data structures, where
+ comparison with include/coff/external.h and other code reveals that
+ the type only needs to be large enough for a 32-bit integer or a
+ pointer. That should mean replacing with uintptr_t is OK.
+
+ Remove much of BFD_HOST configury
+ This patch removes the definition of bfd_uint64_t and bfd_int64_t as
+ well as most BFD_HOST_* which are now unused.
+
+ Remove use of bfd_uint64_t and similar
+ Requiring C99 means that uses of bfd_uint64_t can be replaced with
+ uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
+ BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
+ and tidies a few places that print 64-bit values.
+
+2022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with --disable-shared
+ gprofng/ChangeLog
+ 2022-05-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * libcollector/configure.ac: Use AC_MSG_WARN instead of AC_MSG_ERROR
+ * libcollector/configure: Rebuild.
+
+2022-05-27 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: allow MASM representation of embedded rounding / SAE
+ MASM doesn't support the separate operand form; the modifier belongs
+ after the instruction instead. Accept this form alongside the original
+ (now legacy) one. Short of having access to a MASM version to actually
+ check in how far "after the instruction" is a precise statement in their
+ documentation, allow both that and the SDM mandated form where the
+ modifier is on the last register operand (with a possible immediate
+ operand following).
+
+ Sadly the split out function, at least for the time being, needs to cast
+ away constness at some point, as the two callers disagree in this
+ regard.
+
+ Adjust some, but not all of the testcases.
+
+2022-05-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: re-work AVX512 embedded rounding / SAE
+ As a preparatory step to allowing proper non-operand forms of specifying
+ embedded rounding / SAE, convert the internal representation to non-
+ operand form. While retaining properties (and in a few cases perhaps
+ providing more meaningful diagnostics), this means doing away with a few
+ hundred standalone templates, thus - as a nice side effect - reducing
+ memory consumption / cache occupancy.
+
+ x86/Intel: adjust representation of embedded rounding / SAE
+ MASM doesn't consider {sae} and alike a separate operand; it is attached
+ to the last register operand instead, just like spelled out by the SDM.
+ Make the disassembler follow this first, before also adjusting the
+ assembler (such that it'll be easy to see that the assembler change
+ doesn't alter generated code).
+
+2022-05-27 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: allow MASM representation of embedded broadcast
+ MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
+ DWORD PTR) and alike are to be used there instead. Accept these forms
+ alongside the original (now legacy) ones.
+
+ Acceptance of the original {1to<n>} operand suffix is retained both for
+ backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
+ conversions with shrinking element sizes. I have no insight (yet) into
+ how MASM expects those to be disambiguated.
+
+ Adjust some, but not all of the testcases.
+
+2022-05-27 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: adjust representation of embedded broadcast
+ MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
+ DWORD PTR) and alike are to be used there instead. Make the disassembler
+ follow this first, before also adjusting the assembler (such that it'll
+ be easy to see that the assembler change doesn't alter generated code).
+
+ For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes
+ the original {1to<n>} operand suffix is retained, to disambiguate
+ output. I have no insight (yet) into how MASM expects those to be
+ disambiguated.
+
+2022-05-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fix build with -mx32
+ gprofng/ChangeLog
+ 2022-05-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/28983
+ * libcollector/libcol_util.h (__collector_getsp, __collector_getfp,
+ __collector_getpc): Adapt for build with -mx32
+ * libcollector/heaptrace.c: Fix -Wpointer-to-int-cast warnings.
+ * libcollector/hwprofile.h: Likewise.
+ * libcollector/mmaptrace.c: Likewise.
+ * libcollector/synctrace.c: Likewise.
+ * libcollector/unwind.c: Likewise.
+
+2022-05-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-27 Hans-Peter Nilsson <hp@axis.com>
+
+ ld: cris*-elf: Default to --no-warn-rwx-segment
+ ld:
+ configure.tgt (cris-*-*, crisv32-*-* sans *-aout and *-linux): Unless
+ specified through the --enable-* -option, default to
+ --no-warn-rwx-segment.
+
+ Change-Id: I846bcd3e6762da807b17215a9fe337461ea0d710
+
+2022-05-27 Hans-Peter Nilsson <hp@axis.com>
+
+ cris: bfd: Correct default to no execstack
+ In the now-historical CRIS glibc port, the default stack permission
+ was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the
+ gcc port only emits the executable-stack marker when needed; when
+ emitting code needing it. In other words, the binutils setting
+ mismatches. It doesn't matter much, except being confusing and
+ defaulting to "off" is more sane.
+
+ ld:
+
+ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0
+ for cris*-*-*.
+
+ bfd:
+ * elf32-cris.c (elf_backend_default_execstack): Define to 0.
+
+ Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396
+
+2022-05-26 John Baldwin <jhb@FreeBSD.org>
+
+ aarch64-fbsd-nat: Move definition of debug_regs_probed under HAVE_DBREG.
+ This fixes the build on older FreeBSD systems without support for
+ hardware breakpoints/watchpoints.
+
+2022-05-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Change psymbol_functions::require_partial_symbols to partial_symbols
+ The previous patch ensured that partial symbols are read before calling
+ most of the quick_function's methods.
+
+ The psymbol_functions class has the require_partial_symbols method which
+ serves this exact purpose, and does not need to do it anymore.
+
+ This patch renames this method to partial_symbols and makes it an accessor
+ which asserts that partial symbols have been read at this point.
+
+ Regression tested on x86_64-linux.
+
+2022-05-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Require psymtab before calling quick_functions in objfile
+ The recent DWARF indexer rewrite introduced a regression when debugging
+ a forking program.
+
+ Here is a way to reproduce the issue (there might be other ways, but one
+ is enough and this one mimics the situation we encountered). Consider a
+ program which forks, and the child loads a shared library and calls a
+ function in this shared library:
+
+ if (fork () == 0)
+ {
+ void *solib = dlopen (some_solib, RTLD_NOW);
+ void (*foo) () = dlsym (some_solib, "foo");
+ foo ();
+ }
+
+ Suppose that this program is compiled without debug info, but the shared
+ library it loads has debug info enabled.
+
+ When debugging such program with the following options:
+
+ - set detach-on-fork off
+ - set follow-fork-mode child
+
+ we see something like:
+
+ (gdb) b foo
+ Function "foo" not defined.
+ Make breakpoint pending on future shared library load? (y or [n]) y
+ Breakpoint 1 (foo) pending.
+ (gdb) run
+ Starting program: a.out
+ [Attaching after process 19720 fork to child process 19723]
+ [New inferior 2 (process 19723)]
+ [Switching to process 19723]
+
+ Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
+ (gdb) list
+
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ 0x55a278f77d76 gdb_internal_backtrace_1
+ ../../gdb/bt-utils.c:122
+ 0x55a278f77f83 _Z22gdb_internal_backtracev
+ ../../gdb/bt-utils.c:168
+ 0x55a27940b83b handle_fatal_signal
+ ../../gdb/event-top.c:914
+ 0x55a27940bbb1 handle_sigsegv
+ ../../gdb/event-top.c:987
+ 0x7effec0343bf ???
+ /build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
+ 0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv
+ /usr/include/c++/9/bits/unique_ptr.h:154
+ 0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv
+ /usr/include/c++/9/bits/unique_ptr.h:361
+ 0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile
+ ../../gdb/dwarf2/read.c:3164
+ 0x55a279afb93e _ZN7objfile23find_last_source_symtabEv
+ ../../gdb/symfile-debug.c:139
+ 0x55a279aa3040 _Z20select_source_symtabP6symtab
+ ../../gdb/source.c:365
+ 0x55a279aa22a1 _Z34set_default_source_symtab_and_linev
+ ../../gdb/source.c:268
+ 0x55a27903c44c list_command
+ ../../gdb/cli/cli-cmds.c:1185
+ 0x55a279051233 do_simple_func
+ ../../gdb/cli/cli-decode.c:95
+ 0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci
+ ../../gdb/cli/cli-decode.c:2514
+ 0x55a279c3b0ba _Z15execute_commandPKci
+ ../../gdb/top.c:660
+ 0x55a27940a6c3 _Z15command_handlerPKc
+ ../../gdb/event-top.c:598
+ 0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
+ ../../gdb/event-top.c:797
+ 0x55a279caf401 tui_command_line_handler
+ ../../gdb/tui/tui-interp.c:278
+ 0x55a279409098 gdb_rl_callback_handler
+ ../../gdb/event-top.c:230
+ 0x55a279ed5df2 rl_callback_read_char
+ ../../../readline/readline/callback.c:281
+ 0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept
+ ../../gdb/event-top.c:188
+ 0x55a279408de7 gdb_rl_callback_read_char_wrapper
+ ../../gdb/event-top.c:205
+ 0x55a27940a061 _Z19stdin_event_handleriPv
+ ../../gdb/event-top.c:525
+ 0x55a27a23771e handle_file_event
+ ../../gdbsupport/event-loop.cc:574
+ 0x55a27a237f5f gdb_wait_for_event
+ ../../gdbsupport/event-loop.cc:700
+ 0x55a27a235d81 _Z16gdb_do_one_eventv
+ ../../gdbsupport/event-loop.cc:237
+ 0x55a2796c2ef0 start_event_loop
+ ../../gdb/main.c:418
+ 0x55a2796c3217 captured_command_loop
+ ../../gdb/main.c:478
+ 0x55a2796c717b captured_main
+ ../../gdb/main.c:1340
+ 0x55a2796c7217 _Z8gdb_mainP18captured_main_args
+ ../../gdb/main.c:1355
+ 0x55a278d0b381 main
+ ../../gdb/gdb.c:32
+ ---------------------
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ The first issue observed is in the message printed when hitting the
+ breakpoint. It says that there was a break in the .so file as if there
+ was no debug info associated with it, but there is. Later, if we try to
+ display the source where the execution stopped, we have a segfault.
+
+ Note that not having the debug info on the main binary is not strictly
+ required to encounter some issues, it only is to encounter the segfault.
+ If the main binary has debug information, GDB shows some source form the
+ main binary, unrelated to where we stopped.
+
+ The core of the issue is that GDB never loads the psymtab for the
+ library. It is not loaded when we first see the .so because in case of
+ detach-on-fork off, follow-fork-mode child, infrun.c sets
+ child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading
+ as much as possible. If we compare to what was done to handle this
+ before the new indexer was activated, the psymatb construction for the
+ shared library was done under
+ psymbol_functions::expand_symtabs_matching:
+
+ bool
+ psymbol_functions::expand_symtabs_matching (...)
+ {
+ for (partial_symtab *ps : require_partial_symbols (objfile))
+ ...
+ }
+
+ The new indexer's expand_symtabs_matching callback does not have a call
+ to the objfile's require_partial_symbols, so if the partial symbol table
+ is not loaded at this point, there is no mechanism to fix this.
+
+ Instead of requiring each implementation of the quick_functions to check
+ that partial symbols have been read, I think it is safer to enforce this
+ when calling the quick functions. The general pattern for calling the
+ quick functions is:
+
+ for (auto *iter : qf)
+ iter->the_actual_method_call (...)
+
+ This patch proposes to wrap the access of the `qf` field with an accessor
+ which ensures that partial symbols have been read before iterating:
+ qf_require_partial_symbols. All calls to quick functions are updated
+ except:
+
+ - quick_functions::dump
+ - quick_functions::read_partial_symbols (from
+ objfile::require_partial_symbols)
+ - quick_functions::can_lazily_read_symbols and quick_functions::has_symbols
+ (from objfile::has_partial_symbols)
+
+ Regression tested on x86_64-gnu-linux.
+
+ Change-Id: I39a13a937fdbaae613a5cf68864b021000554546
+
+2022-05-26 Tom Tromey <tom@tromey.com>
+
+ Fix crash in new DWARF indexer
+ PR gdb/29128 points out a crash in the new DWARF index code. This
+ happens if the aranges for a CU claims a PC, but the symtab that is
+ created during CU expansion does not actually contain the PC. This
+ can only occur due to bad debuginfo, but at the same time, gdb should
+ not crash.
+
+ This patch fixes the bug and further merges some code into
+ dwarf2_base_index_functions. This merger helps prevent the same issue
+ from arising from the other index implementations.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29128
+
+2022-05-26 Tom Tromey <tromey@adacore.com>
+
+ Finalize each cooked index separately
+ After DWARF has been scanned, the cooked index code does a
+ "finalization" step in a worker thread. This step combines all the
+ index entries into a single master list, canonicalizes C++ names, and
+ splits Ada names to synthesize package names.
+
+ While this step is run in the background, gdb will wait for the
+ results in some situations, and it turns out that this step can be
+ slow. This is PR symtab/29105.
+
+ This can be sped up by parallelizing, at a small memory cost. Now
+ each index is finalized on its own, in a worker thread. The cost
+ comes from name canonicalization: if a given non-canonical name is
+ referred to by multiple indices, there will be N canonical copies (one
+ per index) rather than just one.
+
+ This requires changing the users of the index to iterate over multiple
+ results. However, this is easily done by introducing a new "chained
+ range" class.
+
+ When run on gdb itself, the memory cost seems rather low -- on my
+ current machine, "maint space 1" reports no change due to the patch.
+
+ For performance testing, using "maint time 1" and "file" will not show
+ correct results. That approach measures "time to next prompt", but
+ because the patch only affects background work, this shouldn't (and
+ doesn't) change. Instead, a simple way to make gdb wait for the
+ results is to set a breakpoint.
+
+ Before:
+
+ $ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
+ -ex 'break main' /tmp/gdb
+ Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
+ 2.00
+
+ After:
+
+ $ /bin/time -f%e ./gdb/gdb -nx -q -batch \
+ -ex 'break main' /tmp/gdb
+ Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
+ 0.65
+
+ Regression tested on x86-64 Fedora 34.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
+
+2022-05-26 Alan Modra <amodra@gmail.com>
+
+ bit-rot in target before_parse function
+ Copy initialisation over from the elf.em before_parse. Commit
+ ba951afb999 2022-05-03 changed behaviour on arm and score regarding
+ exec stack. This patch restores the previous behaviour.
+
+ * emultempl/aarch64elf.em (before_parse): Init separate_code,
+ warn_execstack, no_warn_rwx_segments and default_execstack.
+ * emultempl/armelf.em (before_parse): Likewise.
+ * emultempl/scoreelf.em (before_parse): Likewise.
+ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return
+ true for arm and nacl.
+
+2022-05-26 Richard Earnshaw <rearnsha@arm.com>
+
+ arm: avoid use of GNU builtin function in s_arm_unwind_save_mixed
+ Whilst reviewing Luis' proposed change to s_arm_unwind_save_mixed
+ yesterday I noticed that we were making use of __builting_clzl
+ directly within the main function, which is not guaranteed to be
+ portable. Whilst studying the code further, I also realized that it
+ could be rewritten without using it and also reworked to remove a lot
+ of unnecessary iterations steps. So this patch does that (and also
+ removes the source of the warning that Luis was trying to fix).
+ Finally, with the rewrite we can also simplify the caller of this
+ routine as the new version can handle all the cases directly.
+
+ * config/tc-arm.c (s_arm_unwind_save_mixed): Rewrite without
+ using __builtin_clzl.
+ (s_arm_unwind_save): Simplify logic for simple/mixed register saves.
+
+2022-05-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/linux-nat: xfer_memory_partial return E_IO on error
+ When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters
+ an error and return -1, linux_proc_xfer_memory_partial return
+ TARGET_XFER_EOF.
+
+ I think it should return TARGET_XFER_E_IO in this case. TARGET_XFER_EOF
+ is returned when pread64/pwrite64/read/frite returns 0, which indicates
+ that the address space is gone and the whole process has exited or
+ execed.
+
+ This patch makes this change.
+
+ Regression tested on x86_64-linux-gnu.
+
+ Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221
+
+2022-05-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: prefer gdb_test in gdb.dwarf2/calling-convention
+ Since ed01945057c "Make gdb_test's question non-optional if specified",
+ if the question and response parameters are given to gdb_test, the
+ framework enforces that GDB asks the question. Before this patch, tests
+ needed to use gdb_test_multiple to enforce this.
+
+ This patch updates the gdb.dwarf2/calling-convention.exp testcase to use
+ gdb_test to check that GDB asks a question. This replaces the more
+ complicated gdb_test_multiple based implementation.
+
+ Tested on x86_64-gnu-linux.
+
+ Change-Id: I7216e822ca68f2727e0450970097d74c27c432fe
+
+2022-05-26 Potharla, Rupesh <Rupesh.Potharla@amd.com>
+
+ bfd: Add Support for DW_FORM_strx* and DW_FORM_addrx*
+
+2022-05-26 Luca Boccassi <bluca@debian.org>
+
+ ld: add --package-metadata
+ Generate a .note.package FDO package metadata ELF note, following
+ the spec: https://systemd.io/ELF_PACKAGE_METADATA/
+
+ If the jansson library is available at build time (and it is explicitly
+ enabled), link ld to it, and use it to validate that the input is
+ correct JSON, to avoid writing garbage to the file. The
+ configure option --enable-jansson has to be used to explicitly enable
+ it (error out when not found). This allows bootstrappers (or others who
+ are not interested) to seamlessly skip it without issues.
+
+2022-05-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-26 Natarajan, Kavitha <Kavitha.Natarajan@amd.com>
+
+ Re: Add bionutils support for DWARF v5's DW_OP_addrx
+ Testsuite files belonging to commit 3ac9da49378c.
+
+2022-05-25 Pedro Alves <pedro@palves.net>
+
+ Show enabled locations with disabled breakpoint parent as "y-"
+ Currently, breakpoint locations that are enabled while their parent
+ breakpoint is disabled are displayed with "y" in the Enb colum of
+ "info breakpoints":
+
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 1 breakpoint keep n <MULTIPLE>
+ 1.1 y 0x00000000000011b6 in ...
+ 1.2 y 0x00000000000011c2 in ...
+ 1.3 n 0x00000000000011ce in ...
+
+ Such locations won't trigger a break, so to avoid confusion, show "y-"
+ instead. For example:
+
+ (gdb) info breakpoints
+ Num Type Disp Enb Address What
+ 1 breakpoint keep n <MULTIPLE>
+ 1.1 y- 0x00000000000011b6 in ...
+ 1.2 y- 0x00000000000011c2 in ...
+ 1.3 n 0x00000000000011ce in ...
+
+ The "-" sign is inspired on how the TUI represents breakpoints on the
+ left side of the source window, with "b-" for a disabled breakpoint.
+
+ Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09
+
+2022-05-25 Natarajan, Kavitha <Kavitha.Natarajan@amd.com>
+
+ Add bionutils support for DWARF v5's DW_OP_addrx.
+
+2022-05-25 Pedro Alves <pedro@palves.net>
+
+ gdb: Fix DUPLICATE and PATH regressions throughout
+ The previous patch to add -prompt/-lbl to gdb_test introduced a
+ regression: Before, you could specify an explicit empty message to
+ indicate you didn't want to PASS, like so:
+
+ gdb_test COMMAND PATTERN ""
+
+ After said patch, gdb_test no longer distinguishes
+ no-message-specified vs empty-message, so tests that previously would
+ be silent on PASS, now started emitting PASS messages based on
+ COMMAND. This in turn introduced a number of PATH/DUPLICATE
+ violations in the testsuite.
+
+ This commit fixes all the regressions I could see.
+
+ This patch uses the new -nopass feature introduced in the previous
+ commit, but tries to avoid it if possible. Most of the patch fixes
+ DUPLICATE issues the usual way, of using with_test_prefix or explicit
+ unique messages.
+
+ See previous commit's log for more info.
+
+ In addition to looking for DUPLICATEs, I also looked for cases where
+ we would now end up with an empty message in gdb.sum, due to a
+ gdb_test being passed both no message and empty command. E.g., this
+ in gdb.ada/bp_reset.exp:
+
+ gdb_run_cmd
+ gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*"
+
+ was resulting in this in gdb.sum:
+
+ PASS: gdb.ada/bp_reset.exp:
+
+ I fixed such cases by passing an explicit message. We may want to
+ make such cases error out.
+
+ Tested on x86_64 GNU/Linux, native and native-extended-gdbserver. I
+ see zero PATH cases now. I get zero DUPLICATEs with native testing
+ now. I still see some DUPLICATEs with native-extended-gdbserver, but
+ those were preexisting, unrelated to the gdb_test change.
+
+ Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
+
+2022-05-25 Pedro Alves <pedro@palves.net>
+
+ Add -nopass option to gdb_test/gdb_test_multiple
+ The previous patch to add -prompt/-lbl to gdb_test introduced a
+ regression: Before, you could specify an explicit empty message to
+ indicate you didn't want to PASS, like so:
+
+ gdb_test COMMAND PATTERN ""
+
+ After said patch, gdb_test no longer distinguishes
+ no-message-specified vs empty-message, so tests that previously would
+ be silent on PASS, now started emitting PASS messages based on
+ COMMAND. This in turn introduced a number of PATH/DUPLICATE
+ violations in the testsuite.
+
+ I think that not issuing a PASS should be restricted to only a few
+ cases -- namely in shared routines exported by gdb.exp, which happen
+ to use gdb_test internally. In tests that iterate an unknown number
+ of tests exercising some racy scenario. In the latter case, if we
+ emit PASSes for each iteration, we run into the situation where
+ different testsuite runs emit a different number of PASSes.
+
+ Thus, this patch preserves the current behavior, and, instead, adds a
+ new "-nopass" option to gdb_test and gdb_test_no_output. Compared to
+ the old way of supressing PASS with an empty message, this has the
+ advantage that you can specify a FAIL message that is distinct from
+ the command string, and, it's also more explicit.
+
+ Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
+
+2022-05-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix RV32Q conflict
+ This commit makes RV32 + 'Q' extension (version 2.2 or later) not
+ conflicting since this combination is no longer prohibited by the
+ specification.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_check_conflicts): Remove conflict
+ detection that prohibits RV32Q on 'Q' version 2.2 or later.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/march-fail-rv32iq.d: Removed.
+ * testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
+ * testsuite/gas/riscv/march-fail-rv32iq2p0.d: New test
+ showing RV32IQ fails on 'Q' extension version 2.0.
+ * testsuite/gas/riscv/march-fail-rv32iq2p0.l: Likewise.
+ * testsuite/gas/riscv/march-fail-rv32iq2.d: Likewise.
+ * testsuite/gas/riscv/march-fail-rv32iq-isa-2p2.d: New test
+ showing RV32IQ fails on ISA specification version 2.2.
+ * testsuite/gas/riscv/march-ok-rv32iq2p2.d: New test
+ showing RV32IQ succesds on 'Q' extension version 2.2.
+ * testsuite/gas/riscv/march-ok-rv32iq-isa-20190608.d: New test
+ showing RV32IQ succesds on ISA specification 20190608.
+
+2022-05-25 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ opcodes: introduce BC field; fix isel
+ Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
+ field present in binutils sources. Also, per 1.6.2, BC has the same
+ semantics as BA and BB fields, so this should keep the same flags and
+ mask, only with the different offset.
+
+ opcodes/
+ * ppc-opc.c
+ (BC): Define new field, with the same definition as CRB field,
+ but with the PPC_OPERAND_CR_BIT flag present.
+ gas/
+ * testsuite/gas/ppc/476.d: Update.
+ * testsuite/gas/ppc/a2.d: Update.
+ * testsuite/gas/ppc/e500.d: Update.
+ * testsuite/gas/ppc/power7.d: Update.
+
+2022-05-25 Dmitry Selyutin <ghostmansd@gmail.com>
+
+ ppc: extend opindex to 16 bits
+ With the upcoming SVP64 extension[0] to PowerPC architecture, it became
+ evident that PowerPC operand indices no longer fit 8 bits. This patch
+ switches the underlying type to uint16_t, also introducing a special
+ typedef so that any future extension goes even smoother.
+
+ [0] https://libre-soc.org
+
+ include/
+ * opcode/ppc.h (ppc_opindex_t): New typedef.
+ (struct powerpc_opcode): Use it.
+ (PPC_OPINDEX_MAX): Define.
+ gas/
+ * write.h (struct fix): Increase size of fx_pcrel_adjust.
+ Reorganise.
+ * config/tc-ppc.c (insn_validate): Use ppc_opindex_t for operands.
+ (md_assemble): Likewise.
+ (md_apply_fix): Likewise. Mask fx_pcrel_adjust with PPC_OPINDEX_MAX.
+ (ppc_setup_opcodes): Adjust opcode index assertion.
+ opcodes/
+ * ppc-dis.c (skip_optional_operands): Use ppc_opindex_t for
+ operand pointer.
+ (lookup_powerpc, lookup_prefix, lookup_vle, lookup_spe2): Likewise.
+ (print_insn_powerpc): Likewise.
+
+2022-05-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with clang
+ When running test-case gdb.opt/clobbered-registers-O2.exp with clang 12.0.1, I
+ get:
+ ...
+ (gdb) run ^M
+ Starting program: clobbered-registers-O2 ^M
+ ^M
+ Program received signal SIGSEGV, Segmentation fault.^M
+ gen_movsd (operand0=<optimized out>, operand1=<optimized out>) at \
+ clobbered-registers-O2.c:31^M
+ 31 return *start_sequence(operand0, operand1);^M
+ (gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: runto: run to start_sequence
+ ...
+
+ The problem is that the breakpoint in start_sequence doesn't trigger, because:
+ - the call to start_sequence in gen_movsd is optimized away, despite the
+ __attribute__((noinline)), so the actual function start_sequence doesn't get
+ called, and
+ - the debug info doesn't contain inlined function info, so there's only one
+ breakpoint location.
+
+ Adding noclone and noipa alongside the noinline attribute doesn't fix this.
+
+ Adding the clang-specific attribute optnone in start_sequence does, but since
+ it inhibits all optimization, that's not a preferred solution in a gdb.opt
+ test-case, and it would work only for clang and not other compilers that
+ possibly have the same issue.
+
+ Fix this by moving functions start_sequence and gen_movsd into their own
+ files, as a way of trying harder to enforce noinline/noipa/noclone.
+
+ Tested on x86_64-linux.
+
+2022-05-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with gcc-12
+ When running test-case gdb.opt/clobbered-registers-O2.exp with gcc-12, I run
+ into:
+ ...
+ (gdb) PASS: gdb.opt/clobbered-registers-O2.exp: backtracing
+ print operand0^M
+ $1 = (unsigned int *) 0x7fffffffd070^M
+ (gdb) print *operand0^M
+ $2 = 4195541^M
+ (gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: print operand0
+ ...
+
+ The problem is that starting gcc-12, the assignments to x and y in main are
+ optimized away:
+ ...
+ int main(void)
+ {
+ unsigned x, y;
+
+ x = 13;
+ y = 14;
+ return (int)gen_movsd (&x, &y);
+ ...
+
+ Fix this by making x and y volatile.
+
+ Note that the test-case intends to check the handling of debug info for
+ optimized code in function gen_movsd, so inhibiting optimization in main
+ doesn't interfere with that.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29161
+
+2022-05-24 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Define LOONGARCH_LINUX_NUM_GREGSET as 45
+ LOONGARCH_LINUX_NUM_GREGSET should be defined as 45 (32 + 1 + 1 + 11)
+ due to reserved 11 for extension in glibc, otherwise when execute:
+
+ make check-gdb TESTS="gdb.base/corefile.exp"
+
+ there exists the following failed testcase:
+
+ (gdb) core-file /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
+ [New LWP 7742]
+ warning: Unexpected size of section `.reg/7742' in core file.
+ Core was generated by `/home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
+ Program terminated with signal SIGABRT, Aborted.
+ warning: Unexpected size of section `.reg/7742' in core file.
+ #0 0x000000fff76f4e24 in raise () from /lib/loongarch64-linux-gnu/libc.so.6
+ (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
+
+2022-05-24 Christophe Lyon <christophe.lyon@arm.com>
+
+ AArch64: add support for DFP (Decimal Floating point)
+ This small patch adds support for TYPE_CODE_DECFLOAT in
+ aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate,
+ so that GDB for AArch64 knows how to pass DFP parameters and how to
+ read DFP results when calling a function.
+
+ Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH,
+ all of GDB's DFP tests pass.
+
+2022-05-24 Christophe Lyon <christophe.lyon@arm.com>
+
+ Merge config/ changes from GCC, to enable DFP on AArch64
+ 2022-04-28 Christophe Lyon <christophe.lyon@arm.com>
+
+ config/
+ * dfp.m4 (enable_decimal_float): Enable BID for AArch64.
+
+ libdecnumber/
+ * configure: Regenerate.
+
+2022-05-24 Alan Modra <amodra@gmail.com>
+
+ PR29171, invalid read causing SIGSEGV
+ The fix here is to pass "section" down to read_and_display_attr_value.
+ The test in read_and_display_attr_value is a little bit of hardening.
+
+ PR 29171
+ * dwarf.c (display_debug_macro, display_debug_names): Pass section
+ to read_and_display_attr_value2.
+ (read_and_display_attr_value): Don't attempt to check for .dwo
+ section name when section is NULL.
+
+2022-05-24 Alan Modra <amodra@gmail.com>
+
+ PR29170, divide by zero displaying fuzzed .debug_names
+ PR 29170
+ * dwarf.c (display_debug_names): Don't attempt to display bucket
+ clashes when bucket count is zero.
+
+ PR29169, invalid read displaying fuzzed .gdb_index
+ PR 29169
+ * dwarf.c (display_gdb_index): Combine sanity checks. Calculate
+ element counts, not word counts.
+
+2022-05-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-23 John Baldwin <jhb@FreeBSD.org>
+
+ Tweak the std::hash<> specialization for aarch64_features.
+ Move the specialization into an explicit std namespace to workaround a
+ bug in older compilers. GCC 6.4.1 at least fails to compile the previous
+ version with the following error:
+
+ gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
+
+ struct std::hash<aarch64_features>
+
+2022-05-23 John Baldwin <jhb@FreeBSD.org>
+
+ Fix loongarch_iterate_over_regset_sections for non-native targets.
+ Define a constant for the number of registers stored in a register set
+ and use this with register_size to compute the size of the
+ general-purpose register set in core dumps.
+
+ This also fixes the build on hosts such as FreeBSD that do not define
+ an elf_gregset_t type.
+
+2022-05-23 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement the iterate_over_regset_sections gdbarch method
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/auxv.exp"
+
+ there exist the following unsupported and failed testcases:
+
+ UNSUPPORTED: gdb.base/auxv.exp: gcore
+ FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump
+ FAIL: gdb.base/auxv.exp: info auxv on native core dump
+ FAIL: gdb.base/auxv.exp: matching auxv data from live and core
+ UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump
+ UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore
+
+ we can see the following messages in gdb/testsuite/gdb.log:
+
+ gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore
+ Target does not support core file generation.
+ (gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore
+
+ In order to fix the above issues, implement the iterate_over_regset_sections
+ gdbarch method to iterate over core file register note sections on LoongArch.
+
+ By the way, with this patch, the failed testcases in gdb.base/corefile.exp
+ and gdb.base/gcore.exp can also be fixed.
+
+2022-05-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix -prompt handling in gdb_test
+ With check-read1 I run into:
+ ...
+ [infrun] maybe_set_commit_resumed_all_targets: not requesting
+ commit-resumed for target native, no resumed threads^M
+ (gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue
+ [infrun] fetch_inferior_event: exit^M
+ ...
+
+ The problem is that proc gdb_test doesn't pass down the -prompt option to proc
+ gdb_test_multiple, due to a typo making this lappend without effect:
+ ...
+ set opts {}
+ lappend "-prompt $prompt"
+ ...
+
+ Fix this by actually appending to opts.
+
+ Tested on x86_64-linux.
+
+2022-05-23 Tom de Vries <tdevries@suse.de>
+
+ [gdbsupport] Fix UB in print-utils.cc:int_string
+ When building gdb with -fsanitize=undefined, I run into:
+ ...
+ (gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on
+ maint print symbols^M
+ print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \
+ be represented in type 'long int'; cast to an unsigned type to negate this \
+ value to itself
+ (gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols
+ ...
+
+ By running in a debug session, we find that this happens during printing of:
+ ...
+ typedef system.storage_elements.storage_offset: \
+ range -9223372036854775808 .. 9223372036854775807;
+ ...
+ Possibly, an ada test-case could be created that exercises this in isolation.
+
+ The problem is here in int_string, where we negate a val with type LONGEST:
+ ...
+ return decimal2str ("-", -val, width);
+ ...
+
+ Fix this by, as recommend, using "-(ULONGEST)val" instead.
+
+ Tested on x86_64-linux.
+
+2022-05-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/exp] Fix UB in scalar_binop
+ When building gdb with -fsanitize=undefined, I run into:
+ ...
+ $ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)"
+ src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \
+ 0 - -9223372036854775808 cannot be represented in type 'long int'
+ $1 = -9223372036854775808
+ ...
+
+ Fix this by performing the substraction in scalar_binop using unsigned types.
+
+ Tested on x86_64-linux.
+
+2022-05-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Fix gdb.ada/dynamic-iface.exp with gcc 7
+ This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8:
+ ...
+ (gdb) print obj^M
+ $1 = (n => 3, a => "ABC", value => 93)^M
+ (gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface
+ ...
+ but fails with gcc 7:
+ ...
+ (gdb) print obj^M
+ $1 = ()^M
+ (gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface
+ ...
+
+ More concretely, we have trouble finding the type of obj. With gcc 8:
+ ...
+ $ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj"
+ ...
+ type = <ref> new concrete.intermediate with record
+ value: integer;
+ end record
+ ...
+ and with gcc 7:
+ ...
+ type = <ref> tagged record null; end record
+ ...
+
+ The translation from tagged type to "full view" type happens in
+ ada_tag_value_at_base_address, where we hit this code:
+ ...
+ /* Storage_Offset'Last is used to indicate that a dynamic offset to
+ top is used. In this situation the offset is stored just after
+ the tag, in the object itself. */
+ if (offset_to_top == last)
+ {
+ struct value *tem = value_addr (tag);
+ tem = value_ptradd (tem, 1);
+ tem = value_cast (ptr_type, tem);
+ offset_to_top = value_as_long (value_ind (tem));
+ }
+ ...
+ resulting in an offset_to_top for gcc 8:
+ ...
+ (gdb) p offset_to_top
+ $1 = -16
+ ...
+ and for gcc 7:
+ ...
+ (gdb) p offset_to_top
+ $1 = 16
+ ...
+
+ The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple
+ changes]") which mentions this change.
+
+ There's some code right after the code quoted above that deals with this
+ change:
+ ...
+ else if (offset_to_top > 0)
+ {
+ /* OFFSET_TO_TOP used to be a positive value to be subtracted
+ from the base address. This was however incompatible with
+ C++ dispatch table: C++ uses a *negative* value to *add*
+ to the base address. Ada's convention has therefore been
+ changed in GNAT 19.0w 20171023: since then, C++ and Ada
+ use the same convention. Here, we support both cases by
+ checking the sign of OFFSET_TO_TOP. */
+ offset_to_top = -offset_to_top;
+ }
+ ...
+ but it's not activated because of the 'else'.
+
+ Fix this by removing the 'else'.
+
+ Tested on x86_64-linux, with gcc 7.5.0.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057
+
+2022-05-23 Mark Harmstone <mark@harmstone.com>
+
+ ld: use definitions in generate_reloc rather than raw literals
+
+2022-05-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Skip language auto in gdb.base/parse_number.exp
+ In test-case gdb.base/parse_number.exp, we skip architecture auto in the
+ $supported_archs loop, to prevent duplicate testing.
+
+ Likewise, skip language auto and its alias local in the $::all_languages
+ loop. This reduces the number of tests from 17744 to 15572.
+
+ Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-05-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-22 Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
+
+ Accept functions with DW_AT_linkage_name present
+ Currently GDB is not able to debug (Binary generated with Clang) variables
+ present in shared/private clause of OpenMP Task construct. Please note that
+ LLVM debugger LLDB is able to debug.
+
+ In case of OpenMP, compilers generate artificial functions which are not
+ present in actual program. This is done to apply parallelism to block of
+ code.
+
+ For non-artifical functions, DW_AT_name attribute should contains the name
+ exactly as present in actual program.
+ (Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices)
+ Since artificial functions are not present in actual program they not having
+ DW_AT_name and having DW_AT_linkage_name instead should be fine.
+
+ Currently GDB is invalidating any function not havnig DW_AT_name which is why
+ it is not able to debug OpenMP (Clang).
+
+ It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name
+ is absent.
+
+2022-05-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Rename base_breakpoint -> code_breakpoint
+ Even after the previous patches reworking the inheritance of several
+ breakpoint types, the present breakpoint hierarchy looks a bit
+ surprising, as we have "breakpoint" as the superclass, and then
+ "base_breakpoint" inherits from "breakpoint". Like so, simplified:
+
+ breakpoint
+ base_breakpoint
+ ordinary_breakpoint
+ internal_breakpoint
+ momentary_breakpoint
+ ada_catchpoint
+ exception_catchpoint
+ tracepoint
+ watchpoint
+ catchpoint
+ exec_catchpoint
+ ...
+
+ The surprising part to me is having "base_breakpoint" being a subclass
+ of "breakpoint". I'm just refering to naming here -- I mean, you'd
+ expect that it would be the top level baseclass that would be called
+ "base".
+
+ Just flipping the names of breakpoint and base_breakpoint around
+ wouldn't be super great for us, IMO, given we think of every type of
+ *point as a breakpoint at the user visible level. E.g., "info
+ breakpoints" shows watchpoints, tracepoints, etc. So it makes to call
+ the top level class breakpoint.
+
+ Instead, I propose renaming base_breakpoint to code_breakpoint. The
+ previous patches made sure that all code breakpoints inherit from
+ base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts
+ nicely with a watchpoint also being typically known as a "data
+ breakpoint".
+
+ After this commit, the resulting hierarchy looks like:
+
+ breakpoint
+ code_breakpoint
+ ordinary_breakpoint
+ internal_breakpoint
+ momentary_breakpoint
+ ada_catchpoint
+ exception_catchpoint
+ tracepoint
+ watchpoint
+ catchpoint
+ exec_catchpoint
+ ...
+
+ ... which makes a lot more sense to me.
+
+ I've left this patch as last in the series in case people want to
+ bikeshed on the naming.
+
+ "code" has a nice property that it's exactly as many letters as
+ "base", so this patch didn't require any reindentation. :-)
+
+ Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Test "set multiple-symbols on" creating multiple breakpoints
+ To look for code paths that lead to create_breakpoints_sal creating
+ multiple breakpoints, I ran the whole testsuite with this hack:
+
+ --- a/gdb/breakpoint.c
+ +++ b/gdb/breakpoint.c
+ @@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch,
+ int from_tty,
+ int enabled, int internal, unsigned flags)
+ {
+ - if (canonical->pre_expanded)
+ - gdb_assert (canonical->lsals.size () == 1);
+ + gdb_assert (canonical->lsals.size () == 1);
+
+ surprisingly, the assert never failed...
+
+ The way to get to create_breakpoints_sal with multiple lsals is to use
+ "set multiple-symbols ask" and then select multiple options from the
+ menu, like so:
+
+ (gdb) set multiple-symbols ask
+ (gdb) b overload1arg
+ [0] cancel
+ [1] all
+ [2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg()
+ [3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char)
+ [4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double)
+ [5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float)
+ [6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int)
+ [7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long)
+ [8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short)
+ [9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char)
+ [10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char)
+ [11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int)
+ [12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long)
+ [13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short)
+ > 2-3
+ Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107.
+ Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110.
+ warning: Multiple breakpoints were set.
+ Use the "delete" command to delete unwanted breakpoints.
+
+ ... which would trigger the assert.
+
+ This commit makes gdb.cp/ovldbreak.exp test this scenario. It does
+ that by making set_bp_overloaded take a list of expected created
+ breakpoints rather than just one breakpoint. It converts the
+ procedure to use gdb_test_multiple instead of send_gdb/gdb_expect
+ along the way.
+
+ Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make sure momentary breakpoints are always thread-specific
+ This adds a new ctor to momentary_breakpoints with a few parameters
+ that are always necessary for momentary breakpoints.
+
+ In particular, I noticed that set_std_terminate_breakpoint doesn't
+ make the breakpoint be thread specific, which looks like a bug to me.
+
+ The point of that breakpoint is to intercept std::terminate calls that
+ happen as result of the called thread throwing an exception that won't
+ be caught by the dummy frame. If some other thread calls
+ std::terminate, IMO, it's no different from some other thread calling
+ exit/_exit, for example.
+
+ Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Momentary breakpoints should have no breakpoint number
+ Momentary breakpoints have no breakpoint number, their breakpoint
+ number should be always 0, to avoid constantly incrementing (or
+ decrementing) the internal breakpoint count.
+
+ Indeed, set_momentary_breakpoint installs the created breakpoint
+ without a number.
+
+ However, momentary_breakpoint_from_master incorrectly gives an
+ internal breakpoint number to the new breakpoint. This commit fixes
+ that.
+
+ Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Add/tweak intro comments of struct breakpoint and several subclasses
+ This tweaks the intro comments of the following classes:
+
+ internal_breakpoint
+ momentary_breakpoint
+ breakpoint
+ base_breakpoint
+ watchpoint
+ catchpoint
+
+ Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Move add_location(sal) to base_breakpoint
+ After the previous patches, only base_breakpoint subclasses use
+ add_location(sal), so we can move it to base_breakpoint (a.k.a. base
+ class for code breakpoints).
+
+ This requires a few casts here and there, but always at spots where
+ you can see from context what the breakpoint's type actually is.
+
+ I inlined new_single_step_breakpoint into its only caller exactly for
+ this reason.
+
+ I did try to propagate more use of base_breakpoint to avoid casts, but
+ that turned out unwieldy for this patch.
+
+ Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Move common bits of catchpoint/exception_catchpoint to breakpoint's ctor
+ Move common bits of catchpoint and exception_catchpoint to
+ breakpoint's ctor, to avoid duplicating code.
+
+ Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make catchpoint inherit breakpoint, eliminate init_raw_breakpoint
+ struct catchpoint's ctor currently calls init_raw_breakpoint, which is
+ a bit weird, as that ctor-like function takes a sal argument, but
+ catchpoints don't have code locations.
+
+ Instead, make struct catchpoint's ctor add the catchpoint's dummy
+ location using add_dummy_location.
+
+ init_raw_breakpoint uses add_location under the hood, and with a dummy
+ sal it would ultimately use the breakpoint's gdbarch for the
+ location's gdbarch, so replace the references to loc->gdbarch (which
+ is now NULL) in syscall_catchpoint to references to the catchpoint's
+ gdbarch.
+
+ struct catchpoint's ctor was the last user of init_raw_breakpoint, so
+ this commit eliminates the latter.
+
+ Since catchpoint locations aren't code locations, make struct
+ catchpoint inherit struct breakpoint instead of base_breakpoint. This
+ let's us delete the tracepoint::re_set override too.
+
+ Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make breakpoint_address_bits look at the location kind
+ Software watchpoints allocate a special dummy location using
+ software_watchpoint_add_no_memory_location, and then
+ breakpoint_address_bits checks whether the location is that special
+ location to decide whether the location has a meaninful address to
+ print.
+
+ Introduce a new bp_loc_software_watchpoint location kind, and make
+ breakpoint_address_bits use bl_address_is_meaningful instead, which
+ returns false for bp_loc_other, which is in accordance with we
+ document for bp_location::address:
+
+ /* (... snip ...) Valid for all types except
+ bp_loc_other. */
+ CORE_ADDR address = 0;
+
+ Rename software_watchpoint_add_no_memory_location to
+ add_dummy_location, and simplify it. This will be used by catchpoints
+ too in a following patch.
+
+ Note that neither "info breakpoints" nor "maint info breakpoints"
+ actually prints the addresses of watchpoints, but I think it would be
+ useful to do so in "maint info breakpoints". This approach let's us
+ implement that in the future.
+
+ Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make exception_catchpoint inherit base_breakpoint instead of catchpoint
+ exception_catchpoint is really a code breakpoint, with locations set
+ by sals, re-set like other code breakpoints, etc., so make it inherit
+ base_breakpoint.
+
+ This adds a bit of duplicated code to exception_catchpoint's ctor
+ (copied from struct catchpoint's ctor), but it will be eliminated in a
+ following patch.
+
+ Change-Id: I9fbb2927491120e9744a4f5e5cb5e6870ca07009
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location}
+ This commit makes set_momentary_breakpoint allocate the breakpoint
+ type without relying on set_raw_breakpoint, and similarly,
+ momentary_breakpoint_from_master not rely on
+ set_raw_breakpoint_without_location. This will let us convert
+ init_raw_breakpoint to a ctor in a following patch.
+
+ The comment about set_raw_breakpoint being used in gdbtk sources is
+ stale. gdbtk no longer uses it.
+
+ Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Refactor set_internal_breakpoint / internal_breakpoint ctor
+ This moves initialization of internal_breakpoint's breakpoint fields
+ to internal_breakpoint's ctor, and stops using
+ new_breakpoint_from_type for internal_breakpoint breakpoints.
+
+ Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Convert init_ada_exception_catchpoint to a ctor
+ Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I
+ presume so it can call the static describe_other_breakpoints function.
+ I think this is a dependency inversion.
+ init_ada_exception_catchpoint, being code specific to Ada catchpoints,
+ should be in ada-lang.c, and describe_other_breakpoints, a core
+ function, should be exported.
+
+ And then, we can convert init_ada_exception_catchpoint to an
+ ada_catchpoint ctor.
+
+ Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make ada_catchpoint_location's owner ctor parameter be ada_catchpoint
+ This commit changes ada_catchpoint_location's ctor from:
+
+ ada_catchpoint_location (breakpoint *owner)
+
+ to:
+
+ ada_catchpoint_location (ada_catchpoint *owner)
+
+ just to make the code better document intention.
+
+ To do this, we need to move the ada_catchpoint_location type's
+ definition to after ada_catchpoint is defined, otherwise the compiler
+ doesn't know that ada_catchpoint is convertible to struct breakpoint.
+
+ Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ init_breakpoint_sal -> base_breakpoint::base_breakpoint
+ This converts init_breakpoint_sal to a base_breakpoint constructor.
+
+ It removes a use of init_raw_breakpoint.
+
+ To avoid manually adding a bunch of parameters to
+ new_breakpoint_from_type, and manually passing them down to the
+ constructors of a number of different base_breakpoint subclasses, make
+ new_breakpoint_from_type a variable template function.
+
+ Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Remove "internal" parameter from a couple functions
+ None of init_breakpoint_sal, create_breakpoint_sal, and
+ strace_marker_create_breakpoints_sal make use of their "internal"
+ parameter, so remove it.
+
+ Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ More breakpoint_ops parameter elimination
+ Remove breakpoint_ops parameters from a few functions that don't need
+ it.
+
+ Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make a few functions work with base_breakpoint instead of breakpoint
+ This makes tracepoints inherit from base_breakpoint, since their
+ locations are code locations. If we do that, then we can eliminate
+ tracepoint::re_set and tracepoint::decode_location, as they are doing
+ the same as the base_breakpoint implementations.
+
+ With this, all breakpoint types created by new_breakpoint_from_type
+ are code breakpoints, i.e., base_breakpoint subclasses, and thus we
+ can make it return a base_breakpoint pointer.
+
+ Finally, init_breakpoint_sal can take a base_breakpoint pointer as
+ "self" pointer too. This will let us convert this function to a
+ base_breakpoint ctor in a following patch.
+
+ Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ ranged_breakpoint: move initialization to ctor
+ Move initialization of ranged_breakpoint's fields to its ctor.
+
+ Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ ranged_breakpoint: use install_breakpoint
+ This commit replaces a chunk of code in break_range_command by an
+ equivalent call to install_breakpoint.
+
+ Change-Id: I31c06cabd36f5be91740aab029265f678aa78e35
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ ranged_breakpoint: don't use init_raw_breakpoint
+ ranged_breakpoint's ctor already sets the breakpoint's type to
+ bp_hardware_breakpoint.
+
+ Since this is a "regular" breakpoint, b->pspace should remain NULL.
+
+ Thus, the only thing init_raw_breakpoint is needed for, is to add the
+ breakpoint's location. Do that directly.
+
+ Change-Id: I1505de94c3919881c2b300437e2c0da9b05f76bd
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ Make structs breakpoint/base_breakpoint/catchpoint be abstract
+ You should never instanciate these types directly.
+
+ Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f
+
+2022-05-20 Pedro Alves <pedro@palves.net>
+
+ add_location_to_breakpoint -> breakpoint::add_location
+ Make add_location_to_breakpoint be a method of struct breakpoint.
+
+ A patch later in the series will move this to base_breakpoint, but for
+ now, it needs to be here.
+
+ Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129
+
+2022-05-20 Carl Love <cel@us.ibm.com>
+
+ PowerPC: Make test gdb.arch/powerpc-power10.exp Endian independent.
+ The .quad statement stores the 64-bit hex value in Endian order. When used
+ to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad
+ statement stores the 32-bit suffix followed by the 32-bit prefix rather
+ than the expected order of prefix word followed by the suffix word. GDB
+ fetches 32-bits at a time when disassembling instructions. The disassembly
+ on BE gets messed up since GDB fetches the suffix first and interprets it
+ as a word instruction not a prefixed instruction. When gdb fetches the
+ prefix part of the instruction, following the initial suffix word, gdb
+ associates the prefix word incorrectly with the following 32-bits as the
+ suffix for the instruction when in fact it is the following instruction.
+
+ For example on BE we have two prefixed instructions stored using the
+ .quad statement as follows:
+
+ addr word GDB action
+ ---------------------------------------------
+ 1 suffix inst A <- GDB interprets as a word instruction
+ 2 prefix inst A <- GDB uses this prefix with
+
+ 3 suffix inst B <- this suffix rather than the suffix at addr 1.
+ 4 prefix inst B
+
+ This patch changes the .quad statement into two .longs to explicitly store
+ the prefix followed by the suffix of the instruction.
+
+ The patch rearranges the instructions to put all of the word instructions
+ together followed by the prefix instructions for clarity.
+
+ The patch has been tested on Power 10 and Power 7 BE and LE to verify
+ the change works as expected.
+
+2022-05-20 Tom Tromey <tromey@adacore.com>
+
+ Remove obsolete text from documentation
+ The documentation says that -enable-pretty-printing is experimental in
+ 7.0 and may change -- that's long enough ago that I think we can say
+ that this text is no longer correct or useful.
+
+2022-05-20 Nick Clifton <nickc@redhat.com>
+
+ Stop readekf and objdump from aggressively following links.
+ * dwarf.c (dwarf_select_sections_by_names): Return zero if no
+ sections were selected.
+ (dwarf_select_sections_by_letters): Likewise.
+ * dwarf.h: (dwarf_select_sections_by_names): Update prototype.
+ (dwarf_select_sections_by_letters): Update prototype.
+ * objdump.c (might_need_separate_debug_info): New function.
+ (dump_bfd): Call new function before attempting to load separate
+ debug info files.
+ (main): Do not enable dwarf section dumping for -WK or -WN.
+ * readelf.c (parse_args): Do not enable dwarf section dumping for
+ -wK or -wN.
+ (might_need_separate_debug_info): New function.
+ (process_object): Call new function before attempting to load
+ separate debug info files.
+ * testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
+ debuginfod tests to pass.
+ * testsuite/binutils-all/objdump.Wk: Add extra regexps.
+ * testsuite/binutils-all/readelf.k: Add extra regexps.
+
+2022-05-20 Jia-Wei Chen <jiawei@iscas.ac.cn>
+
+ RISC-V: Update zfinx implement with zicsr.
+ Update zfinx implement with zicsr, fix missing fcsr use by zfinx.
+ add zicsr imply by zfinx.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c: New imply.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/csr-insns-pseudo-zfinx.d: New test.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c: Update insn class.
+
+2022-05-20 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove RV128-only fmv instructions
+ As fmv.x.q and fmv.q.x instructions are RV128-only (not RV64-only),
+ it should be removed until RV128 support for GNU Binutils is required
+ again.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/fmv.x.q-rv64-fail.d: New failure test.
+ * testsuite/gas/riscv/fmv.x.q-rv64-fail.l: Likewise.
+ * testsuite/gas/riscv/fmv.x.q-rv64-fail.s: Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_FMV_X_Q, MASK_FMV_X_Q,
+ MATCH_FMV_Q_X, MASK_FMV_Q_X): Remove RV128-only instructions.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Remove RV128-only instructions.
+
+2022-05-20 Aditya Vidyadhar Kamath <ADITYA.VIDYADHAR.KAMATH@ibm.com>
+
+ Fix non-pointer type compilation error in aix-thread.c
+ In aix-thread.c we use ms->value_address () to get the symbol address.
+ This triggers the following compiler error...
+
+ base operand of '->' has non-pointer type 'bound_minimal_symbol'
+
+ ... because ms is not a pointer.
+
+ This commit fixes this error by using ms.value_address () instead.
+
+2022-05-20 Steinar H. Gunderson <sesse@google.com>
+
+ add a trie to map quickly from address range to compilation unit
+ When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line()
+ becomes a hotspot, as perf wants to get line number information
+ (for inline-detection purposes) for each and every sample. In Chromium
+ in particular (the content_shell binary), this entails going through
+ 475k address ranges, which takes a long time when done repeatedly.
+
+ Add a radix-256 trie over the address space to quickly map address to
+ compilation unit spaces; for content_shell, which is 1.6 GB when some
+ (but not full) debug information turned is on, we go from 6 ms to
+ 0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
+ speedup.
+
+ There is a modest RAM increase of 180 MB in this binary (the existing
+ linked list over ranges uses about 10 MB, and the entire perf job uses
+ between 2–3 GB for a medium-size profile); for smaller binaries with few
+ ranges, there should be hardly any extra RAM usage at all.
+
+2022-05-20 Alan Modra <amodra@gmail.com>
+
+ Tidy warn-execstack handling
+ Make ld and bfd values consistent by swapping values 0 and 2 in
+ link_info.warn_execstack. This has the benefit of making the value an
+ "extended" boolean, with 0 meaning no warning, 1 meaning warn, other
+ values a conditional warning.
+
+ Yes, this patch introduces fails on arm/aarch64. Not a problem with
+ this patch but an arm/aarch64 before_parse problem.
+
+ bfd/
+ * elflink.c (bfd_elf_size_dynamic_sections): Adjust
+ warn_execstack test.
+ include/
+ * bfdlink.h (warn_execstack): Swap 0 and 2 meaning.
+ ld/
+ * configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0,
+ 1, 2 consistent with link_info.warn_execstack.
+ * ld.texi: Typo fixes.
+ * lexsup.c (parse_args): Adjust setting of link_info.warn_execstack.
+ (elf_static_list_options): Adjust help message conditions.
+ * configure: Regenerate.
+
+2022-05-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-19 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ arm: Fix system register fpcxt_ns and fpcxt_s naming convention.
+ The current assembler accepts system registers FPCXTNS and FPCXTS for Armv8.1-M
+ Mainline Instructions VSTR, VLDR, VMRS and VMSR.
+ Assembler should be also allowing FPCXT_NS, fpcxt_ns, fpcxtns, FPCXT_S, fpcxt_s
+ and fpcxts. This patch fixes the issue.
+
+2022-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: use @value{GDBP} in 'info pretty-printer' example
+ Update the 'info pretty-printer' example in the manual to make use of
+ @value{GDBP} instead of hard-coding '(gdb)'.
+
+2022-05-19 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: make use of group/end group in 'info pretty-printers' example
+ The 'info pretty-printers' example is pretty long and consists of many
+ commands and their output.
+
+ Currently, when the pdf manual is generated this example spans a
+ page-break, with the page-break falling part way through some example
+ output from GDB.
+
+ This commit breaks up the example using @group .... @end group, within
+ each group is a single GDB command and all its output.
+
+ Now, when the pdf manual is created, the page-break is placed after
+ the output of one GDB command, and before the subsequent command, this
+ looks much nicer.
+
+2022-05-19 Nikolaos Chatzikonstantinou <nchatz314@gmail.com>
+
+ gdb/doc: fix inconsistent info pretty-printer example
+ The example for 'info pretty-printer' in the manual passes an
+ object-regexp in some cases, but presents output as though no
+ object-regexp was passed.
+
+ This commit fixes the two mistakes, in one case, fixing the output to
+ filter based on object-regexp, and in the other, to remove the
+ object-regexp from the command and leave all the output.
+
+2022-05-19 Nick Clifton <nickc@redhat.com>
+
+ Fix potentially uninitialised variables in the Windows tools
+
+2022-05-19 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: Support displaced stepping on LoongArch
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/async-shell.exp"
+
+ we can see the following message in gdb/testsuite/gdb.sum:
+
+ UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping
+
+ modify support_displaced_stepping to support displaced stepping
+ on LoongArch.
+
+ With this patch:
+
+ PASS: gdb.base/async-shell.exp: run &
+ PASS: gdb.base/async-shell.exp: shell echo foo
+ PASS: gdb.base/async-shell.exp: interrupt
+ PASS: gdb.base/async-shell.exp: process stopped
+
+ I did the following tests that use support_displaced_stepping
+ with this patch on LoongArch, there is no failed testcases.
+
+ loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.*
+ gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.base/step-over-no-symbols.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.base/step-over-syscall.exp: if {$displaced == "on" && ![support_displaced_stepping]} {
+ gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] {
+ gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.threads/interrupt-while-step-over.exp: if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } {
+ gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
+
+2022-05-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: fix path_join crash with -std=c++17 and -D_GLIBCXX_DEBUG
+ When building GDB with -std=c++17 and -D_GLIBCXX_DEBUG=1, I get:
+
+ $ ./gdb -nx --data-directory=data-directory -q -ex "maint selftest path_join"
+ /usr/include/c++/11.2.0/string_view:233: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
+
+ The problem is that we're passing an empty string_view to
+ IS_ABSOLUTE_PATH. IS_ABSOLUTE_PATH accesses [0] on that string_view,
+ which is out-of-bounds.
+
+ The reason this is not seen with -std less than c++17 is that our local
+ copy of string_view (used with C++ < 17) does not have the assert in
+ operator[], as that wouldn't work in a constexpr method:
+
+ https://gitlab.com/gnutools/binutils-gdb/-/blob/5890af36e5112bcbb8d7555e63570f68466e6944/gdbsupport/gdb_string_view.h#L180
+
+ IS_ABSOLUTE_PATH is normally used with null-terminated string. It's
+ fine to pass an empty null-terminated string to IS_ABSOLUTE_PATH,
+ because index 0 in such a string is valid. But not with an empty
+ string_view.
+
+ Fix that by avoiding the "call" to IS_ABSOLUTE_PATH if the string_view
+ is empty.
+
+ Change-Id: Idf4df961b63f513b3389235e93814c02b89ea32e
+
+2022-05-19 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: force emission of ILP32-dependent relocs
+ Like the placeholder types added in 04dfe7aa5217 ("Arm64: follow-on to
+ PR gas/27217 fix"), these are also placeholders which are subsequently
+ resolved (albeit later, hence this being a separate issue). As for the
+ resolved types 1 is returned, these pseudo-relocs should also have 1
+ returned to force retaining of the [eventual] relocations. This is also
+ spelled out individually for each of them in md_apply_fix().
+
+2022-05-19 Jan Beulich <jbeulich@suse.com>
+
+ COFF: use hash for string table also when copying / stripping
+ Otherwise the string table may grow and hence e.g. change a final binary
+ (observed with PE/COFF ones) even if really there's no change. Doing so
+ in fact reduces the overall amount of code, and in particular the number
+ of places which need to remain in sync.
+
+ Afaics there's no real equivalent to the "traditional_format" field used
+ when linking, so hashing is always enabled when copying / stripping.
+
+2022-05-19 Jan Beulich <jbeulich@suse.com>
+
+ COFF/PE: keep linker version during objcopy / strip
+ Neither of the tools is really a linker, so whatever was originally
+ recorded should be retained rather than being overwritten by these
+ tools' versions.
+
+ COFF/PE: don't leave zero timestamp after objcopy / strip
+ Fill the timestamp field suitably for _bfd_XXi_only_swap_filehdr_out().
+ Instead of re-arranging the present if(), fold this logic with that of
+ copying the optional header.
+
+2022-05-19 Jan Beulich <jbeulich@suse.com>
+
+ COFF: make objcopy / strip honor --keep-file-symbols
+ So far this option had no effect when used together with e.g.
+ --strip-debug. Set BSF_FILE on these symbols to change that.
+
+ While altering this also join two adjacent blocks of case labeled
+ statements with identical code.
+
+2022-05-19 Jan Beulich <jbeulich@suse.com>
+
+ don't over-align file positions of PE executable sections
+ When a sufficiently small alignment was specified via --file-alignment,
+ individual section alignment shouldn't affect placement within the file.
+ This involves first of all clearing D_PAGED for images when section and
+ file alignment together don't permit paging of the image. The involved
+ comparison against COFF_PAGE_SIZE in turn helped point out (through a
+ compiler warning) that 'page_size' should be of unsigned type (as in
+ particular FileAlignment is). This yet in turn pointed out a dubious
+ error condition (which is being deleted).
+
+ For the D_PAGED case I think the enforced file alignment may still be
+ too high, but I'm wary of changing that logic without knowing of
+ possible corner cases.
+
+ Furthermore file positions in PE should be independent of the alignment
+ recorded in section headers anyway. Otherwise there are e.g. anomalies
+ following commit 6f8f6017a0c4 ("PR27567, Linking PE files adds alignment
+ section flags to executables") in that linking would use information a
+ subsequent processing step (e.g. stripping) wouldn't have available
+ anymore, and hence a binary could change in that 2nd step for no actual
+ reason. (Similarly stripping a binary linked with a linker pre-dating
+ that commit would change the binary again when stripping it a 2nd time.)
+
+2022-05-19 Yvan Roux <yvan.roux@foss.st.com>
+
+ _bfd_real_fopen should not use ccs parameter on Windows
+ PR 25713
+ * bfdio.c (_bfd_real_fopen): Delete ccs string.
+
+2022-05-19 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix canonical extension order (K and J)
+ This commit fixes canonical extension order to follow the RISC-V ISA
+ Manual draft-20210402-1271737 or later.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
+ prefix to be placed before "J".
+
+2022-05-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-18 John Baldwin <jhb@FreeBSD.org>
+
+ Use aarch64_features to describe register features in target descriptions.
+ Replace the sve bool member of aarch64_features with a vq member that
+ holds the vector quotient. It is zero if SVE is not present.
+
+ Add std::hash<> specialization and operator== so that aarch64_features
+ can be used as a key with std::unordered_map<>.
+
+ Change the various functions that create or lookup aarch64 target
+ descriptions to accept a const aarch64_features object rather than a
+ growing number of arguments.
+
+ Replace the multi-dimension tdesc_aarch64_list arrays used to cache
+ target descriptions with unordered_maps indexed by aarch64_feature.
+
+2022-05-18 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: follow-on to PR gas/27217 fix
+ PR gas/27217
+
+ Prior to trying to address PR gas/28888 I noticed anomalies in how
+ certain insns would / wouldn't be affected in similar ways.
+
+ Commit eac4eb8ecb26 ("Fix a problem assembling AArch64 sources when a
+ relocation is generated against a symbol that has a defined value") had
+ two copy-and-paste mistakes, passing the wrong type to
+ aarch64_force_reloc().
+
+ It further failed to add placeholder relocation types to that function's
+ block of case labels leading to a return of 1. While not of interest for
+ aarch64_force_relocation() (these placeholders are resolved right in
+ parse_operands()), calls to aarch64_force_reloc() happen before that
+ resolution would take place.
+
+2022-05-18 Nick Clifton <nickc@redhat.com>
+
+ Fix compile time warning building gold with Clang-14.
+ * int_encoding.cc (get_length_as_unsigned_LEB_128): Remove
+ current_length variable.
+
+2022-05-18 Victor Do Nascimento <victor.donascimento@arm.com>
+
+ oops - forgot changelog entry for the previous delta.
+
+ arm: Add unwind support for mixed register lists
+ * config/tc-arm.c (parse_reg_list): Add handling of mixed register
+ types.
+ (reg_names): Enumerate pseudoregister according to mapped physical
+ register number.
+ (s_arm_unwind_save_pseudo): Modify function signature.
+ (s_arm_unwind_save_core): Likewise.
+ (s_arm_unwind_save_mixed): New function.
+ (s_arm_unwind_save): Generate register list mask to pass to nested
+ functions.
+ * testsuite/gas/arm/unwind-pacbti-m.s: Expand test for mixed
+ register type lists.
+ * testsuite/gas/arm/unwind-pacbti-m.d: Likewise.
+ * testsuite/gas/arm/unwind-pacbti-m-readelf.d: Likewise.
+
+2022-05-18 Carl Love <cel@us.ibm.com>
+
+ PowerPC: bp-permanent.exp, kill-after-signal fix
+ Fix changes that didn't make it into commit:
+ dd9cd55e990bcc9f8448cac38d242d53974b3604.
+
+ Fix missing -wrap on gdb_test_multiple in gdb.base/kill-after-signal.exp
+ that is causing regression test on x86_64-linux with taskset -c 0.
+
+2022-05-18 Yichao Yu <yyc1992@gmail.com>
+
+ [AArch64] Return the regnum for PC (32) on aarch64
+ This will allow the unwind info to explicitly specify a different value
+ for the return address from the link register.
+ Such usage, although uncommon, is valid and useful for signal frames.
+ It is also supported by aadwarf64 from ARM (Note 9 in [1]).
+
+ Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html
+
+ [1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
+
+2022-05-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: shrink op_riprel
+ It is only ever initialized from a boolean, so it as well as related
+ variables' types can simply be bool and there's no masking to 32 bits
+ needed in set_op().
+
+2022-05-18 Nick Clifton <nickc@redhat.com>
+
+ Add a --no-weak option to nm.
+ PR 29135
+ * nm.c (non_weak): New variable.
+ (filter_symbols): When non-weak is true, ignore weak symbols.
+ (long_options): Add --no-weak.
+ (usage): Mention --no-weak.
+ (main): Handle -W/--no-weak.
+ * doc/binutils.texi: Document new feature.
+ * NEWS: Mention the new feature.
+ * testsuite/binutils-all/nm.exp: Add test of new feature.
+ * testsuite/binutils-all/no-weak.s: New test source file.
+
+2022-05-18 Pedro Alves <pedro@palves.net>
+
+ Support -prompt and -lbl in gdb_test
+ This teaches gdb_test to forward the -prompt and -lbl options to
+ gdb_test_multiple.
+
+ The option parsing is done with parse_args.
+
+ As a cleanup, instead of using llength and lindex to get at the
+ positional arguments, use lassign, and check whether the corresponding
+ variable is empty.
+
+ Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use
+ gdb_test -prompt/-lbl instead of gdb_test_multiple as examples.
+
+ Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0
+
+2022-05-18 Luis Machado <luis.machado@arm.com>
+
+ Remove unused DWARF PAUTH registers
+ The AARCH64_DWARF_PAUTH_DMASK and AARCH64_DWARF_PAUTH_CMASK DWARF registers
+ never made their way into the aadwarf64. The following patch removes these
+ constants and their use.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26295
+
+2022-05-18 Luis Machado <luis.machado@arm.com>
+
+ Rename PAUTH_RA_STATE to RA_SIGN_STATE
+ The aadwarf64 [1] names this register RA_SIGN_STATE, so update the code to use
+ the same name.
+
+ [1] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
+
+2022-05-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Simplify unknown lang testing in gdb.base/parse_number.exp
+ Move testing of language unknown out of the $supported_archs loop in
+ gdb.base/parse_number.exp. This reduces total amount of tests from 18466 to
+ 17744.
+
+ Tested on x86_64-linux.
+
+2022-05-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use hex_for_lang in gdb.base/parse_number.exp
+ In gdb.base/parse_number.exp, add a new proc hex_for_lang that formats a hex
+ number appropriately for a given language.
+
+ Tested on x86_64-linux.
+
+2022-05-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Add gdb/syscalls/update-linux-from-src.sh
+ Add a new script gdb/syscalls/update-linux-from-src.sh, that can be used to
+ generate *-linux.xml.in files from linux kernel sources, like so:
+ ...
+ $ ./update-linux-from-src.sh ~/upstream/linux-stable.git
+ Skipping aarch64-linux.xml.in, no syscall.tbl
+ Generating amd64-linux.xml.in
+ Skipping arm-linux.xml.in, use arm-linux.py instead
+ Skipping bfin-linux.xml.in, no longer supported
+ Generating i386-linux.xml.in
+ Generating mips-n32-linux.xml.in
+ Generating mips-n64-linux.xml.in
+ Generating mips-o32-linux.xml.in
+ Generating ppc64-linux.xml.in
+ Generating ppc-linux.xml.in
+ Generating s390-linux.xml.in
+ Generating s390x-linux.xml.in
+ Generating sparc64-linux.xml.in
+ Generating sparc-linux.xml.in
+ ...
+
+ Update *-linux.xml.in and *-linux.xml using linux kernel tag v5.18-rc6.
+
+2022-05-18 Tamar Christina <tamar.christina@arm.com>
+
+ AArch64: Enable FP16 by default for Armv9-A.
+ In Armv9-A SVE is mandatory, and for SVE FP16 is mandatory. This fixes a disconnect
+ between GCC and binutils where GCC has FP16 on by default and gas doesn't.
+
+ include/ChangeLog:
+
+ 2022-05-16 Tamar Christina <tamar.christina@arm.com>
+
+ * opcode/aarch64.h (AARCH64_ARCH_V9_FEATURES): Add AARCH64_FEATURE_F16.
+
+2022-05-18 Jan Beulich <jbeulich@suse.com>
+
+ gas: avoid octal numbers being accepted when processing .linefile
+ Compilers would put decimal numbers there, so I think we should treat
+ finding octal numbers the same as finding bignums - ignore them as
+ actually being comments of some very specific form.
+
+2022-05-18 Jan Beulich <jbeulich@suse.com>
+
+ gas: avoid bignum related errors when processing .linefile
+ Any construct which to the scrubber looks like a C preprocessor
+ line/file "directive" is converted to .linefile, but the amount of
+ checking the scrubber does is minimal (albeit it does let through only
+ decimal digits for the line part of the contruct). Since the scrubber
+ conversion is further tied to # being a line comment character, anything
+ which upon closer inspection turns out not to be a line/file "directive"
+ is supposed to be treated as a comment, i.e. ignored. Therefore we
+ cannot use get_absolute_expression(), as this may raise errors. Open-
+ code the function instead, treating everything not resulting in
+ O_constant as a comment as well.
+
+ Furthermore also bounds-check the parsed value. This bounds check tries
+ to avoid implementation defined behavior (which may be the raising of an
+ implementation defined signal), but for now makes the assumption that
+ int has less than 64 bits. The way bfd_signed_vma (which is what offsetT
+ aliases) is defined in bfd.h for the BFD64 case I cannot really see a
+ clean way of avoiding this assumption. Omitting the #ifdef, otoh, would
+ risk "condition is always false" warnings by compilers.
+
+ Convert get_linefile_number() to return bool at this occasion as well.
+
+2022-05-18 Jan Beulich <jbeulich@suse.com>
+
+ gas: fold do_repeat{,_with_expander}()
+ do_repeat_with_expander() already deals with the "no expander" case
+ quite fine, so there's really little point having two functions. What it
+ lacks compared with do_repeat() is a call to sb_build(), which can
+ simply be moved (and the then redundant sb_new() be avoided). Along with
+ this moving also flip if the main if()'s condition such that the "no
+ expander" case is handled first.
+
+ gas: don't ignore .linefile inside false conditionals
+ When assembling code previously pre-processed by a C compiler, long
+ enough comments may have been collapsed into "# <line> <file>"
+ constructs. If we skip these, line numbers (and possibly even file
+ names) will be off / wrong in both diagnostics and debug info.
+
+ gas: simplify ignore_input()
+ First of all convert to switch(), in preparation of adding another
+ directive here which may not be ignored. While doing so drop dead code:
+ A string the first two characters of which do not match "if" also wont
+ match "ifdef" or "ifndef".
+
+ gas: tweak .irp and alike file/line handling for M68K/MRI
+ In commit 2ee1792bec22 ("gas: further adjust file/line handling for .irp
+ and alike") I neglected the need to omit the leading . in M68K/MRI mode.
+
+2022-05-18 Xi Ruoyao <xry111@mengyan1223.wang>
+
+ gold: don't invoke IA32 syscall in x86_64 assembly testcase
+ pr17704a_test.s is a x86_64 assembly file, but it invokes IA32 exit
+ syscall with "int 0x80". This causes a segfault on kernels with
+ CONFIG_IA32_EMULATION disabled.
+
+ gold/
+
+ * testsuite/pr17704a_test.s (_start): Invoke x86_64 exit syscall
+ instead of its IA32 counterpart.
+
+2022-05-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-17 Nikolaos Chatzikonstantinou <nchatz314@gmail.com>
+
+ Fix typo in info page
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.python/py-connection.exp with remote targets
+ After the patch to make gdb_test's question non-optional when
+ specified, gdb.python/py-connection.exp started failing like so:
+
+ $ make check TESTS="gdb.python/py-connection.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+ (gdb) PASS: gdb.python/py-connection.exp: info connections while the connection is still around
+ disconnect^M
+ Ending remote debugging.^M
+ (gdb) FAIL: gdb.python/py-connection.exp: kill the inferior
+
+ The problem is that "disconnect" when debugging with the native target
+ asks the user whether to kill the program, while with remote targets,
+ it doesn't.
+
+ Fix it by explicitly killing before disconnecting.
+
+ Tested with --target_board unix, native-gdbserver, and native-extended-gdbserver.
+
+ Change-Id: Icd85015c76deb84b71894715d43853c1087eba0b
+
+2022-05-17 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, btrace: Throw an error for empty recordings when replaying starts.
+ This makes record_btrace_start_replaying() more consistent, as it already
+ errors out e.g. on a recording with only gaps.
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ Make gdb_test's question non-optional if specified
+ gdb_test supports handling scenarios where GDB asks a question before
+ finishing handling some command. The full prototype of gdb_test is:
+
+ # gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE
+
+ However, QUESTION is a question that GDB _may_ ask, not one that GDB
+ _must_ ask:
+
+ # QUESTION is a question GDB may ask in response to COMMAND, like
+ # "are you sure?"
+ # RESPONSE is the response to send if QUESTION appears.
+
+ If GDB doesn't raise the question, the test still passes.
+
+ I think that this is a misfeature. If GDB regresses and stops asking
+ a question, the testsuite won't notice. So I think that if a QUESTION
+ is specified, gdb_test should ensure it comes out of GDB.
+
+ Running the testsuite exposed a number of tests that pass
+ QUESTION/RESPONSE to GDB, but no question comes out. The previous
+ commits fixed them all, so this commit changes gdb_test's behavior.
+
+ A related issue is that gdb_test doesn't enforce that if you specify
+ QUESTION, that you also specify RESPONSE. I.e., you should pass 1, 2,
+ 3, or 5 arguments to gdb_test, but never 4, or more than 5. Making
+ gdb_test detect bogus arguments actually regressed some testcases,
+ also all fixed in previous commits.
+
+ Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ gdb.base/skip.exp: Don't abuse gdb_test's question support
+ gdb.base/skip.exp abuses gdb_test's support for answering a GDB
+ question to do this:
+
+ # With gcc 9.2.0 we jump once back to main before entering foo here.
+ # If that happens try to step a second time.
+ gdb_test "step" "foo \\(\\) at.*" "step 3" \
+ "main \\(\\) at .*\r\n$gdb_prompt " "step"
+
+ After a patch later in this series, gdb_test will FAIL if GDB does NOT
+ issue the question, so this test would start failing on older GCCs.
+
+ Switch to using gdb_test_multiple instead. There are three spots in
+ the file that have the same pattern, and they're actually in a
+ sequence of commands that is repeated those 3 times. Factor all that
+ out to a procedure.
+
+ I don't have gcc 9.2 handy, but I do have gcc 6.5, and that one is
+ affected as well, so update the comment.
+
+ Change-Id: If0a7e3cdf5191b4eec95ce0c8845c3a4d801c39e
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ Avoid having to unload file in gdb.server/connect-with-no-symbol-file.exp
+ gdb.server/connect-with-no-symbol-file.exp's connect_no_symbol_file
+ does:
+
+ gdb_test "file" ".*" "discard symbol table" \
+ {Discard symbol table from `.*'\? \(y or n\) } "y"
+
+ A following patch will make gdb_test expect the question out of GDB if
+ one is passed down as argument to gdb_test. With that, this test
+ starts failing. This is because connect_no_symbol_file is called in a
+ loop, and the first time around, there's a loaded file, so "file" asks
+ the "Discard symbol table ... ?" question, while in the following
+ iterations there's no file, so there's no question.
+
+ Fix this by not loading a file into GDB in the first place.
+
+ Change-Id: I810c036b57842c4c5b47faf340466b0d446d1abc
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ Fix bogus gdb_test invocations
+ A following patch will make gdb_test error out if bogus arguments are
+ passed, which exposed bugs in a few testcases:
+
+ - gdb.python/py-parameter.exp, passing a spurious "1" as extra
+ parameter, resulting in:
+
+ ERROR: Unexpected arguments: {set test-file-param bar.txt} {The name of the file has been changed to bar.txt} {set new file parameter} 1
+
+ - gdb.python/py-xmethods.exp, a missing test message, resulting in
+ the next gdb_test being interpreted as message, question and
+ response! With the enforcing patch, this was caught with:
+
+ ERROR: Unexpected arguments: {p g.mul<char>('a')} {From Python G<>::mul.*} gdb_test {p g_ptr->mul<char>('a')} {From Python G<>::mul.*} {after: g_ptr->mul<char>('a')}
+
+ - gdb.base/pointers.exp, missing a quote.
+
+ Change-Id: I66f2db4412025a64121db7347dfb0b48240d46d4
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ gdb.base/scope.exp: Remove bogus gdb_test questions
+ This test is abusing the QUESTION/RESPONSE feature to send an
+ alternative command to GDB if the first command fails. Like so:
+
+ gdb_test "print 'scope0.c'::filelocal" \
+ "\\\$$decimal = 1" "print 'scope0.c'::filelocal at main" \
+ "No symbol \"scope0.c\" in current context.*" \
+ "print '$srcdir/$subdir/scope0.c'::filelocal"
+
+ So if 'scope0.c' doesn't work, we try again with
+ '$srcdir/$subdir/scope0.c'. I strongly suspect this is really an
+ obsolete test. I think that if '$srcdir/$subdir/scope0.c' works, then
+ 'scope0.c' should have worked too, thus I'd think that if we pass due
+ to the question path, then it's a bug. So just remove the question
+ part passed to gdb_test.
+
+ Change-Id: I2acc99285f1d519284051b49693b5441fbdfe3cd
+
+2022-05-17 Pedro Alves <pedro@palves.net>
+
+ Remove gdb_test questions that GDB doesn't ask
+ Change-Id: Ib2616dc883e9dc9ee100f6c86d83a921a0113c16
+
+2022-05-17 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Added half-precision floating-point v1.0 instructions.
+ bfd/
+ * elfxx-riscv.c (riscv_implicit_subsets): Added implicit f
+ and zicsr for zfh.
+ (riscv_supported_std_z_ext): Added default v1.0 version for zfh.
+ (riscv_multi_subset_supports): Handle INSN_CLASS_ZFH,
+ INSN_CLASS_D_AND_ZFH and INSN_CLASS_Q_AND_ZFH.
+ gas/
+ * config/tc-riscv.c (FLT_CHARS): Added "hH".
+ (macro): Expand Pseudo M_FLH and M_FSH.
+ (riscv_pseudo_table): Added .float16 directive.
+ * testsuite/gas/riscv/float16-be.d: New testcase for .float16.
+ * testsuite/gas/riscv/float16-le.d: Likewise.
+ * testsuite/gas/riscv/float16.s: Likewise.
+ * testsuite/gas/riscv/fp-zfh-insns.d: New testcase for zfh.
+ * testsuite/gas/riscv/fp-zfh-insns.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Added MASK and MATCH encodings for zfh.
+ * opcode/riscv.h: Added INSN_CLASS and pseudo macros for zfh.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Added zfh instructions.
+
+2022-05-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-16 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ IBM zSystems: Fix left-shifting negative PCRel32 values (PR gas/29152)
+ s390_insert_operand ()'s val, min and max are encoded PCRel32 values
+ and need to be left-shifted by 1 before being shown to the user.
+ Left-shifting negative values is undefined behavior in C, but the
+ current code does not try to prevent it, causing UBSan to complain.
+
+ Fix by casting the values to their unsigned equivalents before
+ shifting.
+
+2022-05-16 Pedro Alves <pedro@palves.net>
+
+ Reindent gdbsupport/event-loop.cc:handle_file_event
+ The handle_file_event function has a few unnecessary {} lexical
+ blocks, presumably because they were originally if blocks, and the
+ conditions were removed, or something along those lines.
+
+ Remove the unnecessary blocks, and reindent.
+
+ Change-Id: Iaecbe5c9f4940a80b81dbbc42e51ce506f6aafb2
+
+2022-05-16 Pedro Alves <pedro@palves.net>
+
+ gdbsupport/event-loop.cc: simplify !HAVE_POLL paths
+ gdbsupport/event-loop.cc throughout handles the case of use_poll being
+ true on a system where HAVE_POLL is not defined, by calling
+ internal_error if that situation ever happens.
+
+ Simplify this by moving the "use_poll" global itself under HAVE_POLL,
+ so that it's way more unlikely to ever end up in such a situation.
+ Then, move the code that checks the value of use_poll under HAVE_POLL
+ too, and remove the internal_error calls. Like, from:
+
+ if (use_poll)
+ {
+ #ifdef HAVE_POLL
+ // poll code
+ #else
+ internal_error (....);
+ #endif /* HAVE_POLL */
+ }
+ else
+ {
+ // select code
+ }
+
+ to
+
+ #ifdef HAVE_POLL
+ if (use_poll)
+ {
+ // poll code
+ }
+ else
+ #endif /* HAVE_POLL */
+ {
+ // select code
+ }
+
+ While at it, make use_poll be a bool. The current code is using
+ unsigned char most probably to save space, but I don't think it really
+ matters here.
+
+ Co-Authored-By: Youling Tang <tangyouling@loongson.cn>
+ Change-Id: I0dd74fdd4d393ccd057906df4cd75e8e83c1cdb4
+
+2022-05-16 Eli Zaretskii <eliz@gnu.org>
+
+ gdb: Fix typo in last change in gdb.texinfo
+
+ gdb: Document the 'metadata' styling in GDB displays.
+ The 'metadata' styling was never documented in the GDB manual.
+ This fills that gap.
+
+2022-05-16 Tom Tromey <tromey@adacore.com>
+
+ Fix Ada exception regression on Windows
+ The breakpoint c++-ification series introduced another bug in Ada --
+ it caused "catch exception" and related commands to fail on Windows.
+ The problem is that the re_set method calls the wrong superclass
+ method, so the breakpoint doesn't get correctly re-set when the
+ runtime offsets change. This patch fixes the problem.
+
+2022-05-16 Bruno Larsen <blarsen@redhat.com>
+
+ gdb/testsuite: fix "continue outside of loop" TCL errors
+ Many test cases had a few lines in the beginning that look like:
+
+ if { condition } {
+ continue
+ }
+
+ Where conditions varied, but were mostly in the form of ![runto_main] or
+ [skip_*_tests], making it quite clear that this code block was supposed
+ to finish the test if it entered the code block. This generates TCL
+ errors, as most of these tests are not inside loops. All cases on which
+ this was an obvious mistake are changed in this patch.
+
+2022-05-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-13 Tom Tromey <tromey@adacore.com>
+
+ Remove unused field cooked_index::m_start
+ cooked_index::m_start is unused and can be removed. I think this was
+ a leftover from a previous approach in the index finalization code,
+ and then when rewriting it I forgot to remove it.
+
+ Tested by rebuilding.
+
+2022-05-13 Tom Tromey <tromey@adacore.com>
+
+ Implement pid_to_exec_file for Windows in gdbserver
+ I noticed that gdbserver did not implement pid_to_exec_file for
+ Windows, while gdb did implement it. This patch moves the code to
+ nat/windows-nat.c, so that it can be shared. This makes the gdbserver
+ implementation trivial.
+
+ Remove windows_process_info::id
+ I noticed that windows_process_info::id is only used by gdbserver, and
+ not really necessary. This patch removes it.
+
+ Constify target_pid_to_exec_file
+ This changes target_pid_to_exec_file and target_ops::pid_to_exec_file
+ to return a "const char *". I couldn't build many of these targets,
+ but did examine the code by hand -- also, as this only affects the
+ return type, it's normally pretty safe. This brings gdb and gdbserver
+ a bit closer, and allows for the removal of a const_cast as well.
+
+ Put corefile-run.core into test subdirectory
+ I noticed that corefile-run.core ends up in the 'runtest' directory.
+ It's better, when at all possible, for test files to end up in the
+ test's designated subdirectory. This patch makes this change.
+
+2022-05-13 Tom Tromey <tromey@adacore.com>
+
+ Do not double-read minimal symbols for PE COFF
+ This changes coffread.c to avoid re-reading minimal symbols when
+ possible. This only works when there are no COFF symbols to be read,
+ but at least for my mingw builds of gdb, this seems to be the case.
+
+ Tested using the AdaCore internal test suite on Windows. I also did
+ some local builds to ensure that no warnings crept in.
+
+2022-05-13 Pedro Alves <pedro@palves.net>
+
+ Fix "gdb --write" with core files
+ If you load a core file into GDB with the --write option, or "set
+ write on" (equivalent), and then poke memory expecting it to patch the
+ core binary, you'll notice something odd -- the write seems to
+ succeed, but in reality, it doesn't. The value you wrote doesn't
+ persist. Like so:
+
+ $ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
+ [New LWP 615986]
+ Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
+ Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+ #0 0x0000555555555131 in ?? ()
+ (gdb) p *(unsigned char *)0x0000555555555131 = 1
+ $1 = 1 '\001'
+ (gdb) p *(unsigned char *)0x0000555555555131
+ $2 = 185 '\271'
+ (gdb)
+
+ Diffing hexdumps of before/after patching, reveals that a "0x1" was
+ actually written somewhere in the file. The problem is that the "0x1"
+ was written at the wrong offset in the file...
+
+ That happens because _bfd_elf_set_section_contents does this to seek
+ to the section's offset:
+
+ pos = hdr->sh_offset + offset;
+ if (bfd_seek (abfd, pos, SEEK_SET) != 0
+ || bfd_bwrite (location, count, abfd) != count)
+ return false;
+
+ ... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
+ incorrect. The reason 'hdr->sh_offset' is zero is that
+ kernel-generated core files normally don't even have a section header
+ table (gdb-generated ones do, but that's more an accident than a
+ feature), and indeed elf_core_file_p doesn't even try to read sections
+ at all:
+
+ /* Core files are simply standard ELF formatted files that partition
+ the file using the execution view of the file (program header table)
+ rather than the linking view. In fact, there is no section header
+ table in a core file.
+
+ The process status information (including the contents of the general
+ register set) and the floating point register set are stored in a
+ segment of type PT_NOTE. We handcraft a couple of extra bfd sections
+ that allow standard bfd access to the general registers (.reg) and the
+ floating point registers (.reg2). */
+
+ bfd_cleanup
+ elf_core_file_p (bfd *abfd)
+
+ Changing _bfd_elf_set_section_contents from:
+
+ pos = hdr->sh_offset + offset;
+
+ to:
+
+ pos = section->filepos + offset;
+
+ fixes it. If we do that however, the tail end of
+ _bfd_elf_set_section_contents ends up as a copy of
+ _bfd_generic_set_section_contents, so just call the latter, thus
+ eliminating some duplicate code.
+
+ New GDB testcase included, which exercises both patching an executable
+ and patching a core file. Patching an executable already works
+ without this fix, because in that case BFD reads in the sections
+ table. Still, we had no testcase for that yet. In fact, we have no
+ "set write on" testcases at all, this is the first one.
+
+ Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
+ Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
+
+2022-05-13 Alan Modra <amodra@gmail.com>
+
+ Import libiberty from gcc
+
+ sim: remove use of PTR
+ PTR will soon disappear from ansidecl.h. Remove uses in sim. Where
+ a PTR cast is used in assignment or function args to a void* I've
+ simply removed the unnecessary (in C) cast rather than replacing with
+ (void *).
+
+2022-05-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-13 Alan Modra <amodra@gmail.com>
+
+ gdb: remove use of PTR
+ PTR will disappear from ansidecl.h and libiberty on the next import
+ from gcc. Remove current uses in gdb.
+
+2022-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/break-f-std-string.cc with older gcc
+ When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3
+ with system gcc 7.5.0, I run into:
+ ...
+ (gdb) whatis /r std::string^M
+ No symbol "string" in namespace "std".^M
+ (gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \
+ whatis /r std::string
+ ...
+ The same for gcc 8.2.1, but it passes with gcc 9.3.1.
+
+ At source level (as we can observe in the .ii file with -save-temps) we have
+ indeed:
+ ...
+ namespace std {
+ namespace __cxx11 {
+ typedef basic_string<char> string;
+ }
+ }
+ ...
+ while with gcc 9.3.1, we have instead:
+ ...
+ namespace std {
+ namespace __cxx11 {
+ ...
+ }
+ typedef basic_string<char> string;
+ }
+ ...
+ due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs
+ outside __cxx11 namespace").
+
+ Fix this by adding the missing typedef for gcc version 5 (the first version to
+ have the dual abi) to 8 (the last version missing aforementioned gcc commit).
+
+ Tested on x86_64-linux, with:
+ - system gcc 7.5.0
+ - gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1
+ - clang 8.0.1, 12.0.1
+
+2022-05-12 Alan Modra <amodra@gmail.com>
+
+ Fix an illegal memory access when creating DLLs.
+ PR 29006
+ * pe-dll.c (dll_name): Delete, replacing with..
+ (dll_filename): ..this, moved earlier in file.
+ (generate_edata): Delete parameters. Don't set up dll_name here..
+ (pe_process_import_defs): ..instead set up dll_filename and
+ dll_symname here before returning.
+ (dll_symname_len): Delete write-only variable.
+ (pe_dll_generate_implib): Don't set up dll_symname here.
+
+2022-05-12 Mark Wielaard <mark@klomp.org>
+
+ gdb: Workaround stringop-overread warning in debuginfod-support.c on powerpc64
+ Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a
+ spurious warning for stringop-overread in debuginfod_is_enabled
+ for url_view. Also suppress it on powerpc64.
+
+ gdb/ChangeLog:
+
+ * debuginfod-support.c (debuginfod_is_enabled): Use
+ DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64.
+
+2022-05-12 Luis Machado <luis.machado@arm.com>
+
+ Make gdb.ada/float-bits.exp more generic
+ There are assumptions in the test about the long double format
+ being used. While the results are OK for i387 128-bit long doubles, it
+ is not correct for IEEE quad 128-bit long doubles.
+
+ Also, depending on the target (64-bit/32-bit), long doubles may not
+ be available at all. And it may be the case that the compiler for a 64-bit
+ target doesn't support 128-bit long doubles, but GDB might still support it
+ internally.
+
+ Lastly, not every long double format has invalid values. Some formats
+ consider all values as valid floating point numbers.
+
+ These divergences cause the following FAIL's on aarch64/arm:
+
+ FAIL: gdb.ada/float-bits.exp: print val_long_double
+ FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
+
+ With the above in mind, extend the test a little so it behaves well on
+ different architectures and so it works with different long double
+ formats.
+
+ Main changes:
+
+ - Use long double values appropriate for the long double format.
+ - Test long double assignment to compiler-generated long
+ double variables.
+ - Test long double assignment to GDB internal variables.
+
+ Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
+
+2022-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Improve gdb/syscalls/update-linux.sh
+ Fix two things in update-linux.sh:
+ - remove use of unnecessary tmp file
+ - inline gen-header.py into update-linux.sh
+
+ Tested on x86_64-linux.
+
+2022-05-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on aarch64
+ On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I
+ run into:
+ ...
+ (gdb) run ^M
+ Starting program: dw2-out-of-range-end-of-seq ^M
+ ^M
+ Program received signal SIGILL, Illegal instruction.^M
+ main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M
+ 1 /* This testcase is part of GDB, the GNU debugger.^M
+ (gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main
+ ...
+
+ There are two problems here:
+ - the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the
+ breakpoint pointing in the middle of an insn
+ - the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the
+ test-case uses 'main_label' as the address of the first and only valid entry
+ in the line table, and:
+ - on aarch64-linux, there's no prologue, so main_label and main coincide,
+ while
+ - on x86_64-linux, there's a prologue, so main_label is different from main.
+
+ Fix these problems by:
+ - eliminating the use of "DW_LNS_advance_pc 1", and using
+ "DW_LNE_set_address $main_end" instead, and
+ - eliminating the use of main_label, using "DW_LNE_set_address $main_start"
+ instead.
+
+ Tested on both x86_64-linux and aarch64-linux.
+
+2022-05-12 Alan Modra <amodra@gmail.com>
+
+ cgen: increase buffer for hash_insn_list
+ As was done for hash_insn_array in commit d3d1cc7b13b4.
+
+ * cgen-dis.c (hash_insn_list): Increase size of buf. Assert
+ size is large enough.
+
+2022-05-12 Alan Modra <amodra@gmail.com>
+
+ PR29142, segv in ar with empty archive and libdeps specified
+ PR 29142
+ * ar.c (main): Properly handle libdeps for zero file_count.
+
+2022-05-12 Alan Modra <amodra@gmail.com>
+
+ Re: IBM zSystems: Accept (. - 0x100000000) PCRel32 operands
+ The new test failed on s390-linux due to bfd_sprintf_vma trimming
+ output to 32 bits for 32-bit targets. The test was faulty anyway,
+ expecting zero as the min end of the range is plainly wrong, but
+ that's what you get if you cast min to int.
+
+ * config/tc-s390.c (s390_insert_operand): Print range error using
+ PRId64.
+ * testsuite/gas/s390/zarch-z900-err.l: Correct expected output.
+
+2022-05-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/catch-syscall.exp with --with-expat=no
+ When doing a gdb build with --with-expat=no, I run into:
+ ...
+ (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+ continue to breakpoint: before pipe call
+ catch syscall pipe^M
+ Unknown syscall name 'pipe'.^M
+ (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+ catch syscall pipe
+ catch syscall pipe2^M
+ Unknown syscall name 'pipe2'.^M
+ (gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+ catch syscall pipe2
+ continue^M
+ Continuing.^M
+ [Detaching after vfork from child process 18538]^M
+ [Inferior 1 (process 18537) exited normally]^M
+ (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
+ ...
+
+ This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle
+ pipe2 syscall in gdb.base/catch-syscall.exp").
+
+ Fix this by using pipe/pipe2 syscall numbers instead.
+
+ Tested on x86_64-linux.
+
+2022-05-11 Nick Clifton <nickc@redhat.com>
+
+ nm: use -U as an alias for --defines-only, in line with llvm-nm
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/catch-syscall.exp without --enable-targets
+ When doing a gdb build without --enable-targets, I run into:
+ ...
+ (gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \
+ s390:31-bit vs s390:64-bit: set architecture s390:64-bit
+ delete breakpoints^M
+ (gdb) info breakpoints^M
+ No breakpoints or watchpoints.^M
+ (gdb) break -qualified main^M
+ No symbol table is loaded. Use the "file" command.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main
+ ...
+
+ The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove
+ target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no
+ longer is called at the end of test_catch_syscall_multi_arch.
+
+ Fix this by moving "clean_restart $binfile" back to
+ test_catch_syscall_multi_arch.
+
+ Tested on x86_64-linux.
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/maint.exp on powerpc64le
+ On powerpc64le-linux, I ran into:
+ ...
+ FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
+ ...
+
+ The problem is that:
+ - the "Cooked index in use" line occurs twice in the gdb output:
+ - once for exec maint, and
+ - once for "Object file system-supplied DSO".
+ - the matching of the second "Cooked index in use" also consumes
+ the "Symtabs:" string, and consequently the corresponding
+ clause does not trigger and $symtabs remains 0.
+
+ Fix this by limiting the output of the command to the exec.
+
+ Tested on x86_64-linux and powerpcle-linux.
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Update syscalls/{ppc64,ppc}-linux.xml
+ Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove target limits in gdb.base/catch-syscall.exp
+ In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
+ test for supported targets using istarget, like so:
+ ...
+ if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
+ ...
+ } elseif { [istarget "powerpc-*-linux*"] \
+ || [istarget "powerpc64*-linux*"] } {
+ ...
+ ...
+ but the tests excercised there can all be executed if gdb is configured with
+ --enable-targets=all.
+
+ Rewrite the proc to iterate over all cases, and check if the test is supported
+ by trying "set arch $arch1" and "set arch $arch2".
+
+ Tested on x86_64-linux, with:
+ - a gdb build with --enable-targets=all, and
+ - a gdb build build with my usual --enable-targets setting (too long to
+ include here) which means the sparc vs sparc:v9 case is unsupported.
+
+2022-05-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/record] Handle statx system call
+ When running test-case gdb.reverse/fstatat-reverse.exp with target board
+ unix/-m32 on openSUSE Tumbleweed, I run into:
+ ...
+ (gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2
+ continue^M
+ Continuing.^M
+ Process record and replay target doesn't support syscall number 383^M
+ Process record: failed to record execution log.^M
+ ^M
+ Program stopped.^M
+ 0xf7fc5555 in __kernel_vsyscall ()^M
+ (gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
+ ...
+
+ The problems is that while with native we're trying to record these syscalls
+ (showing strace output):
+ ...
+ openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
+ newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0
+ ...
+ with unix/-m32 we have instead:
+ ...
+ openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
+ statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \
+ {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \
+ stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0
+ ...
+ and statx is not supported.
+
+ Fix this by adding support for recording syscall statx.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28461
+
+2022-05-11 Alan Modra <amodra@gmail.com>
+
+ opcodes cgen: remove use of PTR
+ Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted,
+ due to failure of bpf to compile with that patch applied.
+
+ .../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
+ 57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
+ plus other similar errors.
+
+ cpu/
+ * mep.opc (print_tpreg, print_spreg): Delete unnecessary
+ forward declarations. Replace PTR with void *.
+ * mt.opc (print_dollarhex, print_pcrel): Delete forward decls.
+ opcodes/
+ * bpf-desc.c, * bpf-dis.c, * cris-desc.c,
+ * epiphany-desc.c, * epiphany-dis.c,
+ * fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c,
+ * ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c,
+ * lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c,
+ * m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c,
+ * mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c,
+ * xc16x-desc.c, * xc16x-dis.c,
+ * xstormy16-desc.c, * xstormy16-dis.c: Regenerate.
+
+2022-05-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-10 Youling Tang <tangyouling@loongson.cn>
+
+ gdb: mips: Fix large-frame.exp test case failure
+ $ objdump -d outputs/gdb.base/large-frame/large-frame-O2
+ 0000000120000b20 <func>:
+ 120000b20: 67bdbff0 daddiu sp,sp,-16400
+ 120000b24: ffbc4000 sd gp,16384(sp)
+ 120000b28: 3c1c0002 lui gp,0x2
+ 120000b2c: 679c8210 daddiu gp,gp,-32240
+ 120000b30: 0399e02d daddu gp,gp,t9
+ 120000b34: df998058 ld t9,-32680(gp)
+ 120000b38: ffbf4008 sd ra,16392(sp)
+ 120000b3c: 0411ffd8 bal 120000aa0 <blah>
+ ...
+
+ The disassembly of the above func function shows that we may use
+ instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n",
+ "daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue
+ function to fix the large-frame.exp test case.
+
+ Before applying the patch:
+
+ backtrace
+ #0 blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24
+ #1 0x0000000120000b44 in func ()
+ Backtrace stopped: frame did not save the PC
+ (gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace
+
+ # of expected passes 5
+ # of unexpected failures 1
+
+ After applying the patch:
+
+ # of expected passes 6
+
+2022-05-10 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Use GDB style to check readbuf and writebuf
+ The GDB style is to write 'if (readbuf != nullptr)', and the same for
+ writebuf.
+
+2022-05-10 Tom Tromey <tromey@adacore.com>
+
+ Fix --disable-threading build
+ PR build/29110 points out that GDB fails to build on mingw when the
+ "win32" thread model is in use. It turns out that the Fedora cross
+ tools using the "posix" thread model, which somehow manages to support
+ std::future, whereas the win32 model does not.
+
+ While looking into this, I found that the configuring with
+ --disable-threading will also cause a build failure.
+
+ This patch fixes this build by introducing a compatibility wrapper for
+ std::future.
+
+ I am not able to test the win32 thread model build, but I'm going to
+ ask the reporter to try this patch.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110
+
+2022-05-10 Pedro Alves <pedro@palves.net>
+
+ Fix "b f(std::string)" when current language is C
+ If you try to set a breakpoint at a function such as "b
+ f(std::string)", and the current language is C, the breakpoint fails
+ to be set, like so:
+
+ (gdb) set language c
+ break f(std::string)
+ Function "f(std::string)" not defined.
+ Make breakpoint pending on future shared library load? (y or [n]) n
+ (gdb)
+
+ The problem is that the code in GDB that expands the std::string
+ typedef hits this in c-typeprint.c:
+
+ /* If we have "typedef struct foo {. . .} bar;" do we want to
+ print it as "struct foo" or as "bar"? Pick the latter for
+ C++, because C++ folk tend to expect things like "class5
+ *foo" rather than "struct class5 *foo". We rather
+ arbitrarily choose to make language_minimal work in a C-like
+ way. */
+ if (language == language_c || language == language_minimal)
+ {
+ if (type->code () == TYPE_CODE_UNION)
+ gdb_printf (stream, "union ");
+ else if (type->code () == TYPE_CODE_STRUCT)
+ {
+ if (type->is_declared_class ())
+ gdb_printf (stream, "class ");
+ else
+ gdb_printf (stream, "struct ");
+ }
+ else if (type->code () == TYPE_CODE_ENUM)
+ gdb_printf (stream, "enum ");
+ }
+
+ I.e., std::string is expanded to "class std::..." instead of just
+ "std::...", and then the "f(class std::..." symbol doesn't exist.
+
+ Fix this by making cp-support.c:inspect_type print the expanded
+ typedef type using the language of the symbol whose type we're
+ expanding the typedefs for -- in the example in question, the
+ "std::string" typedef symbol, which is a C++ symbol.
+
+ Use type_print_raw_options as it seems to me that in this scenario we
+ always want raw types, to match the real symbol names.
+
+ Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
+ breakpoint at "f(std::string)" in both C and C++.
+
+ Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10 Pedro Alves <pedro@palves.net>
+
+ Always pass an explicit language down to c_type_print
+ The next patch will want to do language->print_type(type, ...), to
+ print a type in a given language, avoiding a dependency on the current
+ language. That doesn't work correctly currently, however, because
+ most language implementations of language_defn::print_type call
+ c_print_type without passing down the language. There are two
+ overloads of c_print_type, one that takes a language, and one that
+ does not. The one that does not uses the current language, defeating
+ the point of calling language->print_type()...
+
+ This commit removes the c_print_type overload that does not take a
+ language, and adjusts the codebase throughout to always pass down a
+ language. In most places, there's already an enum language handy.
+ language_defn::print_type implementations naturally pass down
+ this->la_language. In a couple spots, like in ada-typeprint.c and
+ rust-lang.c there's no enum language handy, but the code is written
+ for a specific language, so we just hardcode the language.
+
+ In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
+ here, and we don't have an enum language handy, so I made it use the
+ current language, just like today. Can always be improved later.
+
+ Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10 Pedro Alves <pedro@palves.net>
+
+ Fix "b f(std::string)", always use DMGL_VERBOSE
+ Currently, on any remotely modern GNU/Linux system,
+ gdb.cp/no-dmgl-verbose.exp fails like so:
+
+ break 'f(std::string)'
+ Function "f(std::string)" not defined.
+ (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
+ break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
+ Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
+ (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined
+
+ This testcase was added back in 2011, here:
+
+ [patch] Remove DMGL_VERBOSE
+ https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html
+
+ Back then, the testcase would pass cleanly. It turns out that the
+ reason it fails today is that the testcase is exercising something in
+ GDB that only makes sense if the program is built for the pre-C++11
+ libstc++ ABI. Back then the C++11 ABI didn't exist yet, but nowadays,
+ you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
+ ABI. See "Dual ABI" in the libstdc++ manual, at
+ <https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
+
+ If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
+ ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.
+
+ So why is it that setting a breakpoint at "f(std::string)" fails with
+ modern ABI, but passes with old ABI?
+
+ This is where libiberty demangler's DMGL_VERBOSE option comes in. The
+ Itanium ABI mangling scheme has a shorthand form for std::string (and
+ some other types). See
+ <https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:
+
+ "In addition, the following catalog of abbreviations of the form "Sx" are used:
+
+ <substitution> ::= St # ::std::
+ <substitution> ::= Sa # ::std::allocator
+ <substitution> ::= Sb # ::std::basic_string
+ <substitution> ::= Ss # ::std::basic_string < char,
+ ::std::char_traits<char>,
+ ::std::allocator<char> >
+ <substitution> ::= Si # ::std::basic_istream<char, std::char_traits<char> >
+ <substitution> ::= So # ::std::basic_ostream<char, std::char_traits<char> >
+ <substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
+ "
+
+ When the libiberty demangler encounters such a abbreviation, by
+ default, it expands it to the user-friendly typedef "std::string",
+ "std::iostream", etc.. If OTOH DMGL_VERBOSE is specified, the
+ abbreviation is expanded to the underlying, non-typedefed fullname
+ "std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
+ etc. as documented in the Itanium ABI, and pasted above. You can see
+ the standard abbreviations/substitutions in
+ libiberty/cp-demangle.c:standard_subs.
+
+ Back before Jan's patch in 2011, there were parts of GDB that used
+ DMGL_VERBOSE, and others that did not, leading to mismatches. The
+ solution back then was to stop using DMGL_VERBOSE throughout.
+
+ GDB has code in place to let users set a breakpoint at a function with
+ typedefs in its parameters, like "b f(uint32_t)". Demangled function
+ names as they appear in the symbol tables almost (more on this is in a
+ bit) never have typedefs in them, so when processing "b f(uint32_t)"
+ GDB first replaces "uint32_t" for its underlying type, and then sets a
+ breakpoint on the resulting prototype, in this case "f(unsigned int)".
+
+ Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
+ mangled name of a function such as "void f(std::string)" that was
+ mangled using the standard abbreviations mentioned above really as:
+
+ "void f(std::string)".
+
+ For example, the mangled name of "void f(std::string)" if you compile
+ with old pre-C++11 ABI is "_Z1fSs". That uses the abbreviation "Ss",
+ so if you demangle that without DMGL_VERBOSE, you get:
+
+ $ echo "_Z1fSs" | c++filt --no-verbose
+ f(std::string)
+
+ while with DMGL_VERBOSE you'd get:
+
+ $ echo "_Z1fSs" | c++filt
+ f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+ If, when the user sets a breakpoint at "f(std::string)", GDB would
+ replace the std::string typedef for its underlying type using the same
+ mechanism I mentioned for the "f(uint32_t)" example above, then GDB
+ would really try to set a breakpoint at "f(std::basic_string<char,
+ std::char_traits<char>, std::allocator<char> >)", and that would fail,
+ as the function symbol GDB knows about for that function, given no
+ DMGL_VERBOSE, is "f(std::string)".
+
+ For this reason, the code that expands typedefs in function parameter
+ names has an exception for std::string (and other standard
+ abbreviation types), such that "std::string" is never
+ typedef-expanded.
+
+ And here lies the problem when you try to do "b f(std::string)" with a
+ program compiled with the C++11 ABI. In that case, std::string
+ expands to a different underlying type, like so:
+
+ f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+ and this symbol naturally mangles differently, as:
+
+ _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
+
+ and then because this doesn't use the shorthand mangling abbreviation
+ for "std::string" anymore, it always demangles as:
+
+ f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+ Now, when using the C++11 ABI, and you set a breakpoint at
+ "f(std::string)", GDB's typedefs-in-parameters expansion code hits the
+ exception for "std::string" and doesn't expand it, so the breakpoint
+ fails to be inserted, because the symbol that exists is really the
+
+ f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+ one, not "f(std::string)".
+
+ So to fix things for C++11 ABI, clearly we need to remove the
+ "std::string" exception from the typedef-in-parameters expansion
+ logic. If we do just that, then "b f(std::string)" starts working
+ with the C++11 ABI.
+
+ However, if we do _just_ that, and nothing else, then we break
+ pre-C++11 ABI...
+
+ The solution is then to in addition switch GDB to always use
+ DMGL_VERBOSE. If we do this, then pre-C++11 ABI symbols works the
+ same as C++11 ABI symbols overall -- the demangler expands the
+ standard abbreviation for "std::string" as "std::basic_string<char,
+ std::char_traits<char>, std::allocator<char> >" and letting GDB expand
+ the "std::string" typedef (etc.) too is no longer a problem.
+
+ To avoid getting in the situation where some parts of GDB use
+ DMGL_VERBOSE and others not, this patch adds wrappers around the
+ demangler's entry points that GDB uses, and makes those force
+ DMGL_VERBOSE.
+
+ The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
+ ensure that DMGL_VERBOSE doesn't creep back in:
+
+ gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
+ {Function ".*" not defined\.} \
+ "DMGL_VERBOSE-demangled f(std::string) is not defined"
+
+ This obviously no longer makes sense to have, since we now depend on
+ DMGL_VERBOSE. So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
+ new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
+ sure that setting a breakpoint at "f(std::string)" works. It
+ exercises both pre-C++11 ABI and C++11 ABI.
+
+ Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: fix testsuite regressions for unix/-m32 board
+ This commit fixes two regressions introduced by
+ 891e4190ba705373eec7b374209478215fff5401.
+
+ Reason for the failures was, that on a 32 bit machine the maximum
+ array length as well as the maximum allocatable memory for arrays
+ (in bytes) both seem to be limited by the maximum value of a 4
+ byte (signed) Fortran integer. This lead to compiler errors/unexpected
+ behavior when compiling/running the test with the -m32 board. This
+ behavior is compiler dependent and can differ for different compiler
+ implementations, but generally, it seemed like a good idea to simply
+ avoid such situations.
+
+ The affected tests check for GDB's overflow behavior when using KIND
+ parameters with GDB implemented Fortran intrinsic functions. If these
+ KIND parameters are too small to fit the actual intrinsic function's
+ result, an overflow is expected. This was done for 1, 2, and 4
+ byte overflows. The last one caused problems, as it tried to allocate
+ arrays of length/byte-size bigger than the 4 byte signed integers which
+ would then be used with the LBOUND/UBOUND/SIZE intrinsics.
+
+ The tests were adapted to only execute the 4 byte overflow tests when
+ running on targets with 64 bit. For this, the compiled tests evaluate the
+ byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING
+ module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the
+ C_SIZEOF a Fortran 2008 extension. Both have been implemented in their
+ respective compilers for while (e.g. C_SIZEOF is available since
+ gfortran 4.6). If this byte size evaluates to less than 8 we skip the
+ 4 byte overflow tests in the compiled tests of size.f90 and
+ lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we skip
+ the 4 byte overflow tests if the procedure is_64_target evaluates to false.
+
+ In size.f90, additionally, the to-be-allocated amount of bytes did not
+ fit into 4 byte signed integers for some of the arrays, as it was
+ approximately 4 times the maximum size of a 4 byte signed integer. We
+ adapted the dimensions of the arrays in question as the meaningfulness
+ of the test does not suffer from this.
+
+ With this patch both test run fine with the unix/-m32 board and
+ gcc/gfortran (9.4) as well as the standard board file.
+
+ We also thought about completely removing the affected test from the
+ testsuite. We decided against this as the 32 bit identification comes
+ with Fortran 2008 and removing tests would have decreased coverage.
+
+ A last change that happened with this patch was due to gfortran's and
+ ifx's type resolution when assigning big constants to Fortran Integer*8
+ variables. Before the above changes this happened in a parameter
+ statement. Here, both compilers happily accepted a line like
+
+ integer*8, parameter :: var = 2147483647 + 5.
+
+ After this change the assignment is not done as a parameter
+ anymore, as this triggered compile time overflow errors. Instead,
+ the assignment is done dynamically, depending on the kind of machine one
+ is on. Sadly, just changing this line to
+
+ integer*8 :: var
+ var = 2147483647 + 5
+
+ does not work with ifx (or flang for that matter, they behave similarly
+ here). It will create an integer overflow in the addition as ifx deduces
+ the type the additon is done in as Integer*4. So var will actually
+ contain the value -2147483644 after this. The lines
+
+ integer*8 :: var
+ var = 2147483652
+
+ on the other hand fail to compile with gfortran (9.4.0) as the compiler
+ identifies an Integer overflow here. Finally, to make this work with
+ all three compilers an additional parameter has been introduced
+
+ integer*8, parameter :: helper = 2147483647
+ integer*8 :: var
+ var = helper + 5.
+
+ This works on all 3 compilers as expected.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054
+
+2022-05-10 Pedro Alves <pedro@palves.net>
+
+ Move non-dependent gdb::observers::observable::visit_state outside template
+ The other day, while looking at the symbols that end up in a GDB
+ index, I noticed that the gdb::observers::observable::visit_state enum
+ class appears a number of times:
+
+ $ grep VISIT gdb-index-symbol-names.txt
+ gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED
+ gdb::observers::observable<bpstat*, int>::visit_state::VISITED
+ gdb::observers::observable<bpstat*, int>::visit_state::VISITING
+ gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED
+ gdb::observers::observable<breakpoint*>::visit_state::VISITED
+ gdb::observers::observable<breakpoint*>::visit_state::VISITING
+ gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED
+ gdb::observers::observable<char const*, char const*>::visit_state::VISITED
+ gdb::observers::observable<char const*, char const*>::visit_state::VISITING
+ gdb::observers::observable<char const*>::visit_state::NOT_VISITED
+ gdb::observers::observable<char const*>::visit_state::VISITED
+ gdb::observers::observable<char const*>::visit_state::VISITING
+ gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED
+ gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED
+ gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING
+ gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED
+ gdb::observers::observable<frame_info*, int>::visit_state::VISITED
+ gdb::observers::observable<frame_info*, int>::visit_state::VISITING
+ gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED
+ gdb::observers::observable<gdbarch*>::visit_state::VISITED
+ gdb::observers::observable<gdbarch*>::visit_state::VISITING
+ gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED
+ gdb::observers::observable<gdb_signal>::visit_state::VISITED
+ gdb::observers::observable<gdb_signal>::visit_state::VISITING
+ [... snip ...]
+
+ $ grep VISIT gdb-index-symbol-names.txt | wc -l
+ 72
+
+ enum class visit_state is defined inside the class template
+ observable, but it doesn't have to be, as it does not depend on the
+ template parameters. This commit moves it out, so that only one such
+ type exists. This reduces the size of a -O0 -g3 build for me by
+ around 0.6%, like so:
+
+ $ du -b gdb.before gdb.after
+ 164685280 gdb.before
+ 163707424 gdb.fixed
+
+ and codesize by some 0.5%.
+
+ Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e
+
+2022-05-10 Nick Clifton <nickc@redhat.com>
+
+ Fix compiling binutils/resbin.c with Clang version 14
+
+2022-05-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: include percentages in default metrics list
+ gprofng/ChangeLog
+ 2022-05-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * src/gprofng.rc: Include percentages in default metrics list.
+
+2022-05-10 Alan Modra <amodra@gmail.com>
+
+ gprof: remove use of PTR
+ * basic_blocks.c: Replace uses of PTR with void * throughout.
+ * cg_arcs.c: Likewise.
+ * cg_print.c: Likewise.
+ * hist.c: Likewise.
+ * source.h: Likewise.
+ * symtab.c: Likewise.
+
+ gas: remove use of PTR
+ * config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR.
+
+2022-05-10 Alan Modra <amodra@gmail.com>
+
+ opcodes: remove use of PTR
+ The non-cgen parts of opcodes.
+
+ * cr16-dis.c (print_arg): Replace PTR with void *.
+ * crx-dis.c (print_arg): Likewise.
+ * rl78-dis.c (print_insn_rl78_common): Don't use PTR cast.
+ * rx-dis.c (print_insn_rx): Likewise.
+ * visium-dis.c (print_insn_visium): Likewise.
+ * z8k-dis.c (print_insn_z8k): Likewise.
+
+2022-05-10 Alan Modra <amodra@gmail.com>
+
+ bfd: remove use of PTR
+ * coffcode.h (coff_write_object_contents): Don't cast to PTR.
+ * elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR
+ and PARAMS.
+ (csky_allocate_dynrelocs): Don't use PTR cast.
+ * elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace
+ PTR with void *.
+ * elf32-visium.c (visium_elf_howto_parity_reloc): Likewise.
+ * elfxx-ia64.c (ia64_elf_reloc): Likewise.
+ * plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise.
+
+ include: remove use of PTR
+ * hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *.
+ (HTAB_DELETED_ENTRY): Likewise.
+
+2022-05-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-09 Ilya Leoshkevich <iii@linux.ibm.com>
+
+ IBM zSystems: Accept (. - 0x100000000) PCRel32 operands
+ as does not accept instructions like brasl %r0,.-0x100000000, because
+ of two problems with the generic overflow check:
+
+ 1. PCRel32 operands are signed, but are treated as unsigned.
+
+ 2. The allowed range for these operands is [-(1 << 32), (1 << 32) - 1],
+ and not [-(1 << 31), (1 << 31) - 1].
+
+ Fix both by disabling the generic overflow check - it's not needed,
+ because s390_insert_operand () performs its own.
+
+ gas/
+
+ * config/tc-s390.c (md_gather_operands): Set fx_no_overflow.
+ * testsuite/gas/s390/s390.exp: Add zarch-z900-err.
+ * testsuite/gas/s390/esa-z900.d: New test.
+ * testsuite/gas/s390/esa-z900.s: New test.
+ * testsuite/gas/s390/zarch-z900-err.l: New test.
+ * testsuite/gas/s390/zarch-z900-err.s: New test.
+
+2022-05-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix occasional failure in gdb.mi/mi-multi-commands.exp
+ In bug PR gdb/29036, another failure was reported for the test
+ gdb.mi/mi-multi-commands.exp. This test sends two commands to GDB as
+ a single write, and then checks that both commands are executed.
+
+ The problem that was encountered here is that the output of the first
+ command, which looks like this:
+
+ ^done,value="\"FIRST COMMAND\""
+
+ Is actually produced in parts, first the '^done' is printed, then the
+ ',value="\"FIRST COMMAND\"" is printed.
+
+ What was happening is that some characters from the second command
+ were being echoed after the '^done' had been printed, but before the
+ value part had been printed. To avoid this issue I've relaxed the
+ pattern that checks for the first command a little. With this fix in
+ place the occasional failure in this test is no longer showing up.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29036
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Update syscalls/{amd64,i386}-linux.xml
+ - Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py.
+ - Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and
+ update-netbsd.sh).
+ - Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in.
+ - Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile.
+
+ In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect:
+ ...
+ - <syscall name="madvise1" number="220"/>
+ - <syscall name="getdents64" number="221"/>
+ - <syscall name="fcntl64" number="222"/>
+ + <syscall name="getdents64" number="220"/>
+ + <syscall name="fcntl64" number="221"/>
+ ...
+
+ I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are
+ correct.
+
+ Tested on x86_64-linux.
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add gdb/syscalls/Makefile
+ Add a Makefile in gdb/syscalls that can be used to translate
+ gdb/syscalls/*.xml.in into gdb/syscalls/*.xml.
+
+ Calling make reveals that bfin-linux.xml is missing, so add it.
+
+ Tested on x86_64-linux.
+
+2022-05-09 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement the return_value gdbarch method
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/async.exp"
+
+ there exist the following failed testcases:
+
+ FAIL: gdb.base/async.exp: finish& (timeout)
+ FAIL: gdb.base/async.exp: jump& (timeout)
+ FAIL: gdb.base/async.exp: until& (timeout)
+ FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error)
+
+ we can see the following messages in gdb/testsuite/gdb.log:
+
+ finish&
+ Run till exit from #0 foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9
+ (gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+
+ In order to fix the above failed testcases, implement the return_value
+ gdbarch method on LoongArch.
+
+2022-05-09 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix for gdb.base/eof-exit.exp test failures
+ This fix relates to PR gdb/29032, this makes the test more stable by
+ ensuring that the Ctrl-D is only sent once the prompt has been
+ displayed. This issue was also discussed on the mailing list here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html
+
+ The problem identified in the bug report is that sometimes the Ctrl-D
+ (that the test sends to GDB) arrives while GDB is processing a
+ command. When this happens the Ctrl-D is handled differently than if
+ the Ctrl-D is sent while GDB is waiting for input at a prompt.
+
+ The original intent of the test was that the Ctrl-D be sent while GDB
+ was waiting at a prompt, and that is the case the occurs most often,
+ but, when the Ctrl-D arrives during command processing, then GDB will
+ ignore the Ctrl-D, and the test will fail.
+
+ This commit ensures the Ctrl-D is always sent while GDB is waiting at
+ a prompt, which makes this test stable.
+
+ But, that still leaves an open question, what should happen when the
+ Ctrl-D arrives while GDB is processing a command? This commit doesn't
+ attempt to answer that question, which is while bug PR gdb/29032 will
+ not be closed once this commit is merged.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Make btrace maintainer entry more clear
+ Do:
+ ...
+ -record btrace <name> <email>
+ +record
+ + btrace <name> <email>
+ ...
+ to clarify that the listed maintainer is only maintainer of the btrace part of
+ record.
+
+2022-05-09 Martin Liska <mliska@suse.cz>
+
+ ansidecl.h: sync from GCC
+ include/ChangeLog:
+
+ * ansidecl.h: Sync from GCC.
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Support catch syscall pipe2 for i386
+ With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run
+ into:
+ ...
+ (gdb) catch syscall pipe2^M
+ Unknown syscall name 'pipe2'.^M
+ (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2
+ ...
+
+ Fix this by:
+ - adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and
+ - regenerating gdb/syscalls/i386-linux.xml using
+ "xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in".
+
+ Tested on x86_64-linux with native and unix/-m32.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle pipe2 syscall in gdb.base/catch-syscall.exp
+ When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
+ I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ ^M
+ Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \
+ syscall pipe has returned
+ ...
+
+ The current glibc on Tumbleweed is 2.35, which contains commit
+ "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
+ is used instead of syscall pipe.
+
+ Fix this by detecting whether syscall pipe or pipe2 is used before running the
+ tests.
+
+ Tested on x86_64-linux, specifically on:
+ - openSUSE Tumbleweed (with glibc 2.35), and
+ - openSUSE Leap 15.3 (with glibc 2.31).
+
+ On openSUSE Tumbleweed + target board unix/-m32, this exposes:
+ ...
+ (gdb) catch syscall pipe2^M
+ Unknown syscall name 'pipe2'.^M
+ ...
+ which will be fixed in a folllow-up patch.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Handle pipe2 syscall for amd64
+ When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
+ I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ Process record and replay target doesn't support syscall number 293^M
+ Process record: failed to record execution log.^M
+ ^M
+ Program stopped.^M
+ 0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
+ ...
+
+ The current glibc on Tumbleweed is 2.35, which contains commit
+ "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
+ is used in stead of syscall pipe.
+
+ There is already support added for syscall pipe2 for aarch64 (which only has
+ syscall pipe2, not syscall pipe), so enable the same for amd64, by:
+ - adding amd64_sys_pipe2 in enum amd64_syscall
+ - translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall
+
+ Tested on x86_64-linux, specifically on:
+ - openSUSE Tumbleweed (with glibc 2.35), and
+ - openSUSE Leap 15.3 (with glibc 2.31).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.tui/scroll.exp with read1
+ When running test-case gdb.tui/scroll.exp, I get:
+ ...
+ Box Dump (80 x 8) @ (0, 0):
+ 0 $17 = 16
+ 1 (gdb) p 17
+ 2 $18 = 17
+ 3 (gdb) p 18
+ 4 $19 = 18
+ 5 (gdb) p 19
+ 6 $20 = 19
+ 7 (gdb)
+ PASS: gdb.tui/scroll.exp: check cmd window in flip layout
+ ...
+ but with check-read1 I get instead:
+ ...
+ Box Dump (80 x 8) @ (0, 0):
+ 0 (gdb) 15
+ 1 (gdb) p 16
+ 2 $17 = 16
+ 3 (gdb) p 17
+ 4 $18 = 17
+ 5 (gdb) p 18
+ 6 $19 = 18
+ 7 (gdb) p 19
+ FAIL: gdb.tui/scroll.exp: check cmd window in flip layout
+ ...
+
+ The "p 19" command is handled by Term::command, which sends the command and then
+ does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which:
+ - matches the line with "(gdb) p 19", and
+ - tries to match the following prompt "(gdb) "
+
+ The problem is that scrolling results in reissuing output before the "(gdb) p
+ 19", and the second matching triggers on that. Consequently, wait_for no
+ longer translates gdb output into screen actions, and the screen does not
+ reflect the result of "p 19".
+
+ Fix this by using a new proc wait_for_region_contents, which in contrast to
+ wait_for can handle a multi-line regexp.
+
+ Tested on x86_64-linux with make targets check and check-read1.
+
+2022-05-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/casts.exp with -m32
+ When running test-case gdb.cp/casts.exp with target board unix/-m32, I run
+ into:
+ ...
+ (gdb) print (unsigned long long) &gd == gd_value^M
+ $31 = false^M
+ (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
+ ...
+
+ With some additional printing, we can see in more detail why the comparison
+ fails:
+ ...
+ (gdb) print /x &gd^M
+ $31 = 0xffffc5c8^M
+ (gdb) PASS: gdb.cp/casts.exp: print /x &gd
+ print /x (unsigned long long)&gd^M
+ $32 = 0xffffc5c8^M
+ (gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd
+ print /x gd_value^M
+ $33 = 0xffffffffffffc5c8^M
+ (gdb) PASS: gdb.cp/casts.exp: print /x gd_value
+ print (unsigned long long) &gd == gd_value^M
+ $34 = false^M
+ (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
+ ...
+
+ The gd_value is set by this assignment:
+ ...
+ unsigned long long gd_value = (unsigned long long) &gd;
+ ...
+
+ The problem here is directly casting from a pointer to a non-pointer-sized
+ integer.
+
+ Fix this by adding an intermediate cast to std::uintptr_t.
+
+ Tested on x86_64-linux with native and target board unix/-m32.
+
+2022-05-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle init errors in gdb.mi/user-selected-context-sync.exp
+ In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into:
+ ...
+ (gdb) builtin_spawn -pty^M
+ new-ui mi /dev/pts/5^M
+ New UI allocated^M
+ (gdb) =thread-group-added,id="i1"^M
+ (gdb) ERROR: MI channel failed
+ warning: Error detected on fd 11^M
+ thread 1.1^M
+ Unknown thread 1.1.^M
+ (gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \
+ test_cli_inferior: reset selection to thread 1.1
+ ...
+ with many more UNRESOLVED following.
+
+ The ERROR is a common problem, filed as
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28561 .
+
+ But the many UNRESOLVEDs are due to not checking whether the setup as done in
+ the test_setup function succeeds or not.
+
+ Fix this by:
+ - making test_setup return an error upon failure
+ - handling test_setup error at the call site
+ - adding a "setup done" pass/fail to be turned into an unresolved
+ in case of error during setup.
+
+ Tested on x86_64-linux, by manually triggering the error in
+ mi_gdb_start_separate_mi_tty.
+
+2022-05-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/catch_ex_std.exp with remote-gdbserver-on-localhost
+ When running test-case gdb.ada/catch_ex_std.exp on target board
+ remote-gdbserver-on-localhost, I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ [Inferior 1 (process 15656) exited with code 0177]^M
+ (gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main
+ Remote debugging from host ::1, port 49780^M
+ /home/vries/foo: error while loading shared libraries: libsome_package.so: \
+ cannot open shared object file: No such file or directory^M
+ ...
+
+ Fix this by adding the usual shared-library + remote-target helper
+ "gdb_load_shlib $sofile".
+
+ Tested on x86_64-linux with native and target board
+ remote-gdbserver-on-localhost.
+
+2022-05-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with check-readmore
+ When running test-case gdb.threads/fork-plus-threads.exp with check-readmore,
+ I run into:
+ ...
+ [Inferior 11 (process 7029) exited normally]^M
+ [Inferior 1 (process 6956) exited normally]^M
+ FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
+ inferior 1 exited (timeout)
+ ...
+
+ The problem is that the regexp consuming the "Inferior exited normally"
+ messages:
+ - consumes more than one of those messages at a time, but
+ - counts only one of those messages.
+
+ Fix this by adopting a line-by-line approach, which deals with those messages
+ one at a time.
+
+ Tested on x86_64-linux with native, check-read1 and check-readmore.
+
+2022-05-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-07 Tom Tromey <tom@tromey.com>
+
+ Fix "catch syscall"
+ Simon pointed out that some recent patches of mine broke "catch
+ syscall". Apparently I forgot to finish the conversion of this code
+ when removing init_catchpoint. This patch completes the conversion
+ and fixes the bug.
+
+2022-05-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/readline: fix extra 'quit' message problem
+ After these two commits:
+
+ commit 4fb7bc4b147fd30b781ea2dad533956d0362295a
+ Date: Mon Mar 7 13:49:21 2022 +0000
+
+ readline: back-port changes needed to properly detect EOF
+
+ commit 91395d97d905c31ac38513e4aaedecb3b25e818f
+ Date: Tue Feb 15 17:28:03 2022 +0000
+
+ gdb: handle bracketed-paste-mode and EOF correctly
+
+ It was observed that, if a previous command is selected at the
+ readline prompt using the up arrow key, then when the command is
+ accepted (by pressing return) an unexpected 'quit' message will be
+ printed by GDB. Here's an example session:
+
+ (gdb) p 123
+ $1 = 123
+ (gdb) p 123
+ quit
+ $2 = 123
+ (gdb)
+
+ In this session the second 'p 123' was entered not by typing 'p 123',
+ but by pressing the up arrow key to select the previous command. It
+ is important that the up arrow key is used, typing Ctrl-p will not
+ trigger the bug.
+
+ The problem here appears to be readline's EOF detection when handling
+ multi-character input sequences. I have raised this issue on the
+ readline mailing list here:
+
+ https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html
+
+ a solution has been proposed here:
+
+ https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html
+
+ This patch includes a test for this issue as well as a back-port of
+ (the important bits of) readline commit:
+
+ commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1
+ Date: Wed May 4 11:18:04 2022 -0400
+
+ fix for setting RL_STATE_EOF in callback mode
+
+ That commit also includes some updates to the readline documentation
+ and tests that I have not included in this commit.
+
+ With this commit in place the unexpected 'quit' messages are resolved.
+
+2022-05-07 Alan Modra <amodra@gmail.com>
+
+ Fix multiple ubsan warnings in i386-dis.c
+ Commit 39fb369834a3 "opcodes: Make i386-dis.c thread-safe" introduced
+ a number of casts to bfd_signed_vma that cause undefined behaviour
+ with a 32-bit libbfd. Revert those changes.
+
+ * i386-dis.c (OP_E_memory): Do not cast disp to bfd_signed_vma
+ for negation.
+ (get32, get32s): Don't use bfd_signed_vma here.
+
+2022-05-07 Alan Modra <amodra@gmail.com>
+
+ Re: Fix new linker testsuite failures due to rwx segment test problems
+ Fix it some more.
+
+ bfd/
+ * elfnn-loongarch.c: Remove commented out elf_backend_* defines.
+ ld/
+ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Match
+ arm*. Delete loongarch.
+
+2022-05-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-07 Carl Love <cel@us.ibm.com>
+
+ PowerPC fix for gdb.server/sysroot.exp
+ On PowerPC, the stop in the printf function is of the form:
+
+ Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6
+
+ On other architectures the output looks like:
+
+ Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6
+
+ The following patch modifies the printf test by matchine any character
+ starting immediately after the printf. The test now works for PowerPC
+ output as well as the output from other architectures.
+
+ The test has been run on a Power 10 system and and Intel x86_64 system.
+
+2022-05-06 Nick Clifton <nickc@redhat.com>
+
+ Fix new linker testsuite failures due to rwx segment test problems
+
+2022-05-06 Tom Tromey <tom@tromey.com>
+
+ Introduce catchpoint class
+ This introduces a catchpoint class that is used as the base class for
+ all catchpoints. init_catchpoint is rewritten to be a constructor
+ instead.
+
+ This changes the hierarchy a little -- some catchpoints now inherit
+ from base_breakpoint whereas previously they did not. This isn't a
+ problem, as long as re_set is redefined in catchpoint.
+
+2022-05-06 Tom Tromey <tom@tromey.com>
+
+ Add initializers to tracepoint
+ This adds some initializers to tracepoint. I think right now these
+ may not be needed, due to obscure rules about zero initialization.
+ However, this will change in the next patch, and anyway it is clearer
+ to be explicit.
+
+ Remove init_raw_breakpoint_without_location
+ This removes init_raw_breakpoint_without_location, replacing it with a
+ constructor on 'breakpoint' itself. The subclasses and callers are
+ all updated.
+
+ Disable copying for breakpoint
+ It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN.
+ This patch does this.
+
+ Add constructor to exception_catchpoint
+ This adds a constructor to exception_catchpoint and simplifies the
+ caller.
+
+ Add constructor to syscall_catchpoint
+ This adds a constructor to syscall_catchpoint and simplifies the
+ caller.
+
+ Add constructor to signal_catchpoint
+ This adds a constructor to signal_catchpoint and simplifies the
+ caller.
+
+ Add constructor to solib_catchpoint
+ This adds a constructor to solib_catchpoint and simplifies the caller.
+
+ Add constructor to fork_catchpoint
+ This adds a constructor to fork_catchpoint and simplifies the caller.
+
+ Remove unnecessary line from catch_exec_command_1
+ catch_exec_command_1 clears the new catchpoint's "exec_pathname"
+ field, but this is already done by virtue of calling "new".
+
+ Constify breakpoint::print_recreate
+ This constifies breakpoint::print_recreate.
+
+ Constify breakpoint::print_mention
+ This constifies breakpoint::print_mention.
+
+ Constify breakpoint::print_one
+ This constifies breakpoint::print_one.
+
+ Constify breakpoint::print_it
+ This constifies breakpoint::print_it. Doing this pointed out some
+ code in ada-lang.c that can be simplified a little as well.
+
+ Move works_in_software_mode to watchpoint
+ works_in_software_mode is only useful for watchpoints. This patch
+ moves it from breakpoint to watchpoint, and changes it to return bool.
+
+ Boolify breakpoint::explains_signal
+ This changes breakpoint::explains_signal to return bool.
+
+ Remove breakpoint::ops
+ The breakpoint::ops field is set but never used. This removes it.
+
+ Change print_recreate_thread to a method
+ This changes print_recreate_thread to be a method on breakpoint. This
+ function is only used as a helper by print_recreate methods, so I
+ thought this transformation made sense.
+
+2022-05-06 Carl Love <cel@us.ibm.com>
+
+ PowerPC: bp-permanent.exp, kill-after-signal fix
+ The break point after the stepi on Intel is the entry point of the user
+ signal handler function test_signal_handler. The code at the break point
+ looks like:
+
+ 0x<hex address> <test_signal_handler>: endbr64
+
+ On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
+ after the stepi is in the vdso code inserted by the kernel. The code at the
+ breakpoint looks like:
+
+ 0x<hex address> <__kernel_start_sigtramp_rt64>: bctrl
+
+ This is different from other architectures. As discussed below, recent
+ kernel changes involving the vdso for PowerPC have been made changes to the
+ signal handler code flow. PowerPC is now stopping in function
+ __kernel_start_sigtramp_rt64. PowerPC now requires an additional stepi to
+ reach the user signal handler unlike other architectures.
+
+ The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
+ kernel that is older than Linux 5.9.
+
+ The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:
+
+ commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
+ powerpc/64/signal: Balance return predictor stack in signal trampoline
+
+ An additional change to the PowerPC 64 signal handler was made in Linux
+ kernel version 5.11-rc7 :
+
+ commit id: 24321ac668e452a4942598533d267805f291fdc9
+ powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
+
+ The first kernel change, puts code into the user space signal handler (in
+ the vdso) as a performance optimization to prevent the call/return stack
+ from getting out of balance. The patch ensures that the entire
+ user/kernel/vdso cycle is balanced with the addition of the "brctl"
+ instruction.
+
+ The second patch, fixes the semantics of __kernel_sigtramp_rt64(). A new
+ symbol is introduced to serve as the jump target from the kernel to the
+ trampoline which now consists of two parts.
+
+ The above changes for PowerPC signal handler, causes gdb to stop in the
+ kernel code not the user signal handler as expected. The kernel dispatches
+ to the vdso code which in turn calls into the signal handler. PowerPC is
+ special in that the kernel is using a vdso instruction (bctrl) to enter the
+ signal handler.
+
+ I do not have access to a system with the first patch but not the second. I did
+ test on Power 9 with the Linux 5.15.0-27-generic kernel. Both tests fail on
+ this Power 9 system. The two tests also fail on Power 10 with the Linux
+ 5.14.0-70.9.1.el9_0.ppc64le kernel.
+
+ The following patch fixes the issue by checking if gdb stopped at "signal
+ handler called". If gdb stopped there, the tests verifies gdb is in the kernel
+ function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
+ user signal handler. With the patch below, the tests run without errors on both
+ the Power 9 and Power 10 systems with out any failures.
+
+2022-05-06 Alan Modra <amodra@gmail.com>
+
+ bfd targmatch.h makefile rule
+ I hit this just now with a make -j build after touching config.bfd.
+ mv: cannot stat 'targmatch.new': No such file or directory
+ make[2]: *** [Makefile:2336: targmatch.h] Error 1
+ make[2]: *** Waiting for unfinished jobs....
+
+ Fix that by not removing the target of the rule, a practice that seems
+ likely to cause parallel running of the rule recipe. The bug goes
+ back to 1997, the initial c0734708814c commit.
+
+ * Makefile.am (targmatch.h): rm the temp file, not targmatch.h.
+ * Makefile.in: Regenerate.
+
+2022-05-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/locexpr-data-member-location.exp with nopie
+ When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
+ target board unix/-fno-PIE/-no-pie/-m32 I run into:
+ ...
+ (gdb) step^M
+ 26 return 0;^M
+ (gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
+ ...
+
+ The problem is that the test-case tries to mimic some gdb_compile_shlib
+ behaviour using:
+ ...
+ set flags {additional_flags=-fpic debug}
+ get_func_info foo $flags
+ ...
+ but this doesn't work with the target board setting, because we end up doing:
+ ...
+ gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
+ -o func_addr23029.x
+ ...
+ while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.
+
+ Consequently, the address for foo determined by get_func_info doesn't match
+ the actual address of foo.
+
+ Fix this by printing the address of foo using the result of gdb_compile_shlib.
+
+2022-05-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use gdb::function_view for gdbarch_iterate_over_objfiles_in_search_order callback
+ A rather straightforward patch to change an instance of callback +
+ void pointer to gdb::function_view, allowing pasing lambdas that
+ capture, and eliminating the need for the untyped pointer.
+
+ Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
+
+2022-05-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: use $host instead $target
+ By mistake, $target was used instead of $host to configure the gprogng build.
+
+ gprofng/ChangeLog
+ 2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29113
+ PR gprofng/29116
+ * configure.ac: Use $host instead $target.
+ * libcollector/configure.ac: Likewise.
+ * configure: Rebuild.
+ * libcollector/configure: Rebuild.
+
+2022-05-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make regcache's cooked_write_test selftest work with native-extended-gdbserver board
+ Running
+
+ $ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
+
+ I get some failures:
+
+ Running selftest regcache::cooked_write_test::i386.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i386:intel.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i386:x64-32.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i386:x86-64.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M
+ Self test failed: target already pushed^M
+ Running selftest regcache::cooked_write_test::i8086.^M
+ Self test failed: target already pushed^M
+
+ This is because the native-extended-gdbserver automatically connects GDB
+ to a GDBserver on startup, and therefore pushes a remote target on the
+ initial inferior. cooked_write_test is currently written in a way that
+ errors out if the current inferior has a process_stratum_target pushed.
+
+ Rewrite it to use scoped_mock_context, so it doesn't depend on the
+ current inferior (the current one upon entering the function).
+
+ Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad
+
+2022-05-05 Luis Machado <luis.machado@arm.com>
+
+ Move TILE-Gx files to TARGET64_LIBOPCODES_CFILES
+ TILE-Gx is a 64-bit core, so we should include those files in the
+ TARGET64_LIBOPCODES_CFILES as opposed to TARGET32_LIBOPCODES_CFILES.
+
+ Don't define ARCH_cris for BFD64
+ I believe it is a mistake to define ARCH_cris when BFD64 is defined. It is
+ a 32-bit architecture, so should be placed outside of the BFD64 block.
+
+2022-05-05 Xi Ruoyao <xry111@mengyan1223.wang>
+
+ loongarch: Don't check ABI flags if no code section
+ Various packages (glib and gtk4 for example) produces data-only objects
+ using `ld -r -b binary` or `objcopy`, with no elf header flags set. But
+ these files also have no code sections, so they should be compatible
+ with all ABIs.
+
+ bfd/
+ * elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data):
+ Skip ABI checks if the input has no code sections.
+
+ Reported-by: Wu Xiaotian <yetist@gmail.com>
+ Suggested-by: Wang Xuerui <i@xen0n.name>
+
+2022-05-05 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM zSystems: mgrk, mg first operand requires register pair
+ opcodes/
+
+ * s390-opc.c (INSTR_RRF_R0RER): New instruction type.
+ (MASK_RRF_R0RER): Define mask for new instruction type.
+ * s390-opc.txt: Use RRF_R0RER for mgrk and RXY_RERRD for mg.
+
+2022-05-05 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Check NULL pointer before setting ref_real
+ PR ld/29086
+ * linker.c (bfd_wrapped_link_hash_lookup): Check NULL pointer
+ before setting ref_real.
+
+2022-05-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-05 H.J. Lu <hjl.tools@gmail.com>
+
+ LTO: Handle __real_SYM reference in IR
+ When an IR symbol SYM is referenced in IR via __real_SYM, its resolution
+ should be LDPR_PREVAILING_DEF, not PREVAILING_DEF_IRONLY, since LTO
+ doesn't know that __real_SYM should be resolved by SYM.
+
+ bfd/
+
+ PR ld/29086
+ * linker.c (bfd_wrapped_link_hash_lookup): Mark SYM is referenced
+ via __real_SYM.
+
+ include/
+
+ PR ld/29086
+ * bfdlink.h (bfd_link_hash_entry): Add ref_real.
+
+ ld/
+
+ PR ld/29086
+ * plugin.c (get_symbols): Resolve SYM definition to
+ LDPR_PREVAILING_DEF for __real_SYM reference.
+ * testsuite/ld-plugin/lto.exp: Run PR ld/29086 test.
+ * testsuite/ld-plugin/pr29086.c: New file.
+
+2022-05-04 Alan Modra <amodra@gmail.com>
+
+ cris bfd config
+ cris support will be built into a 32-bit bfd if using --enable-targets=all
+ on a 32-bit host, so we may as well make targmatch.h include cris.
+
+ * config.bfd (cris): Remove #idef BFD64.
+
+2022-05-04 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 check_relocs
+ Tidy the dynamic reloc handling code in check_relocs, removing
+ leftover comments and code from when check_relocs was called as each
+ object file was read in.
+
+ * elf64-ppc.c (ppc64_elf_check_relocs): Tidy dynamic reloc
+ handling code.
+ (dec_dynrel_count): Do the same here.
+
+2022-05-04 Tom Tromey <tromey@adacore.com>
+
+ Fix crash when creating index from index
+ My patches yesterday to unify the DWARF index base classes had a bug
+ -- namely, I did the wholesale dynamic_cast-to-static_cast too hastily
+ and introduced a crash. This can be seen by trying to add an index to
+ a file that has an index, or by running a test like gdb-index-cxx.exp
+ using the cc-with-debug-names.exp target board.
+
+ This patch fixes the crash by introducing a new virtual method and
+ removing some of the static casts.
+
+2022-05-04 Luis Machado <luis.machado@arm.com>
+
+ Fix build failure for aarch64 gdbserver
+ We're missing an argument.
+
+2022-05-04 Mark Wielaard <mark@klomp.org>
+
+ gdb: Workaround stringop-overread warning in debuginfod-support.c on s390x
+ For some reason g++ 11.2.1 on s390x produces a spurious warning for
+ stringop-overread in debuginfod_is_enabled for url_view. Add a new
+ DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning.
+
+ include/ChangeLog:
+
+ * diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New
+ macro.
+
+ gdb/ChangeLog:
+
+ * debuginfod-support.c (debuginfod_is_enabled): Use
+ DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x.
+
+2022-05-04 Pedro Alves <pedro@palves.net>
+
+ Fix GDBserver Aarch64 Linux regression
+ Luis noticed that the recent changes to gdbserver to make it track
+ process and threads independently regressed a few gdb.multi/*.exp
+ tests for aarch64-linux.
+
+ We started seeing the following internal error for
+ gdb.multi/multi-target-continue.exp for example:
+
+ Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M
+ Error in re-setting breakpoint 2: Remote connection closed^M
+ ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.
+
+ A backtrace looks like:
+
+ #0 thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120
+ #1 0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31
+ #2 0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194
+ #3 0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=<optimized out>, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226
+ #4 0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226
+ #5 check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862
+ #6 0x0000aaaaaaacc660 in read_inferior_memory (memaddr=<optimized out>, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93
+ #7 0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071
+ #8 gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048
+ #9 0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307
+ #10 handle_serial_event (err=<optimized out>, client_data=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520
+ #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700
+ #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596
+ #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237
+ #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518
+ #15 captured_main (argc=4, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998
+ #16 0x0000aaaaaaab66dc in main (argc=<optimized out>, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084
+
+ This sequence of functions is invoked due to a series of conditions:
+
+ 1 - The probe-based breakpoint mechanism failed (for some reason) so ...
+
+ 2 - ... gdbserver has to know what type of architecture it is dealing
+ with so it can pick the right breakpoint kind, so it wants to
+ check if we have a 64-bit target.
+
+ 3 - To determine the size of a register, we currently fetch the
+ current thread's register cache, and the current thread pointer
+ is now nullptr.
+
+ In #3, the current thread is nullptr because gdb_read_memory clears it
+ on purpose, via set_desired_process, exactly to expose code relying on
+ the current thread when it shouldn't. It was always possible to end
+ up in this situation (when the current thread exits), but it was
+ harder to reproduce before.
+
+ This commit fixes it by tweaking is_64bit_tdesc to look at the current
+ process's tdesc instead of the current thread's tdesc.
+
+ Note that the thread's tdesc is itself filled from the process's
+ tdesc, so this should be equivalent:
+
+ struct regcache *
+ get_thread_regcache (struct thread_info *thread, int fetch)
+ {
+ struct regcache *regcache;
+
+ regcache = thread_regcache_data (thread);
+
+ ...
+ if (regcache == NULL)
+ {
+ struct process_info *proc = get_thread_process (thread);
+
+ gdb_assert (proc->tdesc != NULL);
+
+ regcache = new_register_cache (proc->tdesc);
+ set_thread_regcache_data (thread, regcache);
+ }
+ ...
+
+ Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc
+
+2022-05-04 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/remote: send qSymbol to all inferiors on startup
+ start_remote_1 calls remote_check_symbols after things are set up to
+ give the remote side a chance to look up symbols. One call to
+ remote_check_symbols sets the "general thread", if needed, and sends one
+ qSymbol packet. However, a remote target could have more than one
+ process on initial connection, and this would send a qSymbol for only
+ one of these processes.
+
+ Change it to iterate on all the target's inferiors and send a qSymbol
+ packet for each one.
+
+ I tested this by changing gdbserver to spawn two processes on startup:
+
+ diff --git a/gdbserver/server.cc b/gdbserver/server.cc
+ index 33c42714e72..9b682e9f85f 100644
+ --- a/gdbserver/server.cc
+ +++ b/gdbserver/server.cc
+ @@ -3939,6 +3939,7 @@ captured_main (int argc, char *argv[])
+
+ /* Wait till we are at first instruction in program. */
+ target_create_inferior (program_path.get (), program_args);
+ + target_create_inferior (program_path.get (), program_args);
+
+ /* We are now (hopefully) stopped at the first instruction of
+ the target process. This assumes that the target process was
+
+ Instead of hacking GDBserver, it should also be possible to test this by
+ starting manually two inferiors on an "extended-remote" connection,
+ disconnecting from GDBserver (with the disconnect command), and
+ re-connecting.
+
+ I was able to see qSymbol being sent for each inferior:
+
+ [remote] Sending packet: $Hgp828dc.828dc#1f
+ [remote] Packet received: OK
+ [remote] Sending packet: $qSymbol::#5b
+ [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
+ [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
+ [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
+ [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
+ [remote] Packet received: OK
+ [remote] Sending packet: $Hgp828dd.828dd#21
+ [remote] Packet received: OK
+ [remote] Sending packet: $qSymbol::#5b
+ [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
+ [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
+ [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
+ [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
+ [remote] Packet received: OK
+
+ Note that there would probably be more work to be done to fully support
+ this scenario, more things that need to be done for each discovered
+ inferior instead of just for one.
+
+ Change-Id: I21c4ecf6367391e2e389b560f0b4bd906cf6472f
+
+2022-05-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/remote: iterate on pspace inferiors in remote_new_objfile
+ Commit 152a17495663 ("gdb: prune inferiors at end of
+ fetch_inferior_event, fix intermittent failure of
+ gdb.threads/fork-plus-threads.exp") broke some tests with the
+ native-gdbserver board, such as:
+
+ (gdb) PASS: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : vfork: break marker
+ continue^M
+ Continuing.^M
+ terminate called after throwing an instance of 'gdb_exception_error'^M
+
+ I can manually reproduce the issue by running (just the commands that
+ the test does as a one liner):
+
+ $ ./gdb -q --data-directory=data-directory \
+ testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork \
+ -ex "tar rem | ../gdbserver/gdbserver - testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork" \
+ -ex "b main" \
+ -ex c \
+ -ex "d 1" \
+ -ex "set displaced-stepping off" \
+ -ex "b *0x7ffff7d7ac5a if main == 0" \
+ -ex "set detach-on-fork off" \
+ -ex "set follow-fork-mode child" \
+ -ex c \
+ -ex "inferior 1" \
+ -ex "b marker" \
+ -ex c
+
+ ... where 0x7ffff7d7ac5a is the exact address of the vfork syscall
+ (which can be found by looking at gdb.log).
+
+ The important part of the above is that a vfork syscall creates inferior
+ 2, then inferior 2 executes until exit, then we switch back to inferior
+ 1 and try to resume it.
+
+ The uncaught exception happens here:
+
+ #4 0x00005596969d81a9 in error (fmt=0x559692da9e40 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.")
+ at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43
+ #5 0x0000559695af6f66 in remote_target::putpkt_binary (this=0x617000038080, buf=0x559692da4380 "qSymbol::", cnt=9) at /home/simark/src/binutils-gdb/gdb/remote.c:9560
+ #6 0x0000559695af6aaf in remote_target::putpkt (this=0x617000038080, buf=0x559692da4380 "qSymbol::") at /home/simark/src/binutils-gdb/gdb/remote.c:9518
+ #7 0x0000559695ab50dc in remote_target::remote_check_symbols (this=0x617000038080) at /home/simark/src/binutils-gdb/gdb/remote.c:5141
+ #8 0x0000559695b3cccf in remote_new_objfile (objfile=0x0) at /home/simark/src/binutils-gdb/gdb/remote.c:14600
+ #9 0x0000559693bc52a9 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:61
+ #10 0x0000559693bb2848 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:111
+ #11 0x0000559693b8dddf in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffe0bae0590: 0x0) at /usr/include/c++/11.2.0/bits/std_function.h:291
+ #12 0x00005596956374b2 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x61b0000167f8, __args#0=0x0) at /usr/include/c++/11.2.0/bits/std_function.h:560
+ #13 0x0000559695633c64 in gdb::observers::observable<objfile*>::notify (this=0x55969ef5c480 <gdb::observers::new_objfile>, args#0=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
+ #14 0x0000559695df6cc2 in clear_symtab_users (add_flags=...) at /home/simark/src/binutils-gdb/gdb/symfile.c:2873
+ #15 0x000055969574c263 in program_space::~program_space (this=0x6120000c8a40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/progspace.c:154
+ #16 0x0000559694fc086b in delete_inferior (inf=0x61700003bf80) at /home/simark/src/binutils-gdb/gdb/inferior.c:205
+ #17 0x0000559694fc341f in prune_inferiors () at /home/simark/src/binutils-gdb/gdb/inferior.c:390
+ #18 0x0000559695017ada in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4293
+ #19 0x0000559694f629e6 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:41
+ #20 0x0000559695b3b0e3 in remote_async_serial_handler (scb=0x6250001ef100, context=0x6170000380a8) at /home/simark/src/binutils-gdb/gdb/remote.c:14466
+ #21 0x0000559695c59eb7 in run_async_handler_and_reschedule (scb=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:138
+ #22 0x0000559695c5a42a in fd_event (error=0, context=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:189
+ #23 0x00005596969d9ebf in handle_file_event (file_ptr=0x60700005af40, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:574
+ #24 0x00005596969da7fa in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:700
+ #25 0x00005596969d8539 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212
+
+ If I enable "set debug infrun" just before the last continue, we see:
+
+ (gdb) continue
+ Continuing.
+ [infrun] clear_proceed_status_thread: 965604.965604.0
+ [infrun] proceed: enter
+ [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [infrun] start_step_over: enter
+ [infrun] start_step_over: stealing global queue of threads to step, length = 0
+ [infrun] operator(): step-over queue now empty
+ [infrun] start_step_over: exit
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
+ [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] reset: reason=proceeding
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+ [infrun] proceed: exit
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] do_target_wait: Found 2 inferiors, starting at #1
+ [infrun] random_pending_event_thread: None found.
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 965604.965604.0 [Thread 965604.965604],
+ [infrun] print_target_wait_results: status->kind = VFORK_DONE
+ [infrun] handle_inferior_event: status->kind = VFORK_DONE
+ [infrun] context_switch: Switching context from 0.0.0 to 965604.965604.0
+ [infrun] handle_vfork_done: not waiting for a vfork-done event
+ [infrun] start_step_over: enter
+ [infrun] start_step_over: stealing global queue of threads to step, length = 0
+ [infrun] operator(): step-over queue now empty
+ [infrun] start_step_over: exit
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
+ [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+ terminate called after throwing an instance of 'gdb_exception_error'
+
+ What happens is:
+
+ - After doing the "continue" on inferior 1, the remote target gives us
+ a VFORK_DONE event. The core ignores it and resumes inferior 1.
+ - Since prune_inferiors is now called after each handled event, in
+ fetch_inferior_event, it is called after we handled that VFORK_DONE
+ event and resumed inferior 1.
+ - Inferior 2 is pruned, which (see backtrace above) causes its program
+ space to be deleted, which clears the symtabs for that program space,
+ which calls the new_objfile observable and remote_new_objfile
+ observer (with a nullptr objfile, to indicate that the previously
+ loaded symbols have been discarded), which calls
+ remote_check_symbols.
+
+ remote_check_symbols is the function that sends the qSymbol packet, to
+ let the remote side ask for symbol addresses. The problem is that the
+ remote target is working in all-stop / sync mode and is currently
+ resumed. It has sent a vCont packet to resume the target and is waiting
+ for a stop reply. It can't send any packets in the mean time. That
+ causes the exception to be thrown.
+
+ This wasn't a problem before, when prune_inferiors was called in
+ normal_stop, because it was always called at a time the target was not
+ resumed.
+
+ An important observation here is that the new_objfile observable is
+ invoked for a change in inferior 2's program space (inferior 2's program
+ space is the current program space). Inferior 2 isn't bound to any
+ process on the remote side (it has exited, that's why it's being
+ pruned). It doesn't make sense to try to send a qSymbol packet for a
+ process that doesn't exist on the remote side. remote_check_symbols
+ actually attempts to avoid that:
+
+ /* The remote side has no concept of inferiors that aren't running
+ yet, it only knows about running processes. If we're connected
+ but our current inferior is not running, we should not invite the
+ remote target to request symbol lookups related to its
+ (unrelated) current process. */
+ if (!target_has_execution ())
+ return;
+
+ The problem here is that while inferior 2's program space is the current
+ program space, inferior 1 is the current inferior. So the check above
+ passes, since inferior has execution. We therefore try to send a
+ qSymbol packet for inferior 1 in reaction to a change in inferior 2's
+ program space, that's wrong.
+
+ This exposes a conceptual flaw in remote_new_objfile. The "new_objfile"
+ event concerns a specific program space, which can concern multiple
+ inferiors, as inferiors can share a program space. We shouldn't
+ consider the current inferior at all, but instead all inferiors bound to
+ the affected program space. Especially since the current inferior can
+ be unrelated to the current program space at that point.
+
+ To be clear, we are in this state because ~program_space sets itself as
+ the current program space, but there is no more inferior having that
+ program space to switch to, inferior 2 has already been unlinked.
+
+ To fix this, make remote_new_objfile iterate on all inferiors bound to
+ the affected program space. Remove the target_has_execution check from
+ remote_check_symbols, replace it with an assert. All callers must
+ ensure that the current inferior has execution before calling it.
+
+ Change-Id: Ica643145bcc03115248290fd310cadab8ec8371c
+
+2022-05-04 Jan Beulich <jbeulich@suse.com>
+
+ Dwarf: rename yet another instance of "index"
+ As before, on sufficiently old glibc this conflicts with a global
+ identifier in the library headers. While there also zap the unusual
+ padding by blanks.
+
+2022-05-04 Martin Liska <mliska@suse.cz>
+
+ LTO plugin: sync header file with GCC
+ include/ChangeLog:
+
+ * plugin-api.h (enum ld_plugin_tag): Sync with GCC.
+
+2022-05-04 Alan Modra <amodra@gmail.com>
+
+ PowerPC32 treatment of absolute symbols
+ As already done for PowerPC64, fix dynamic relocs for absolute symbols.
+ The patch also tidies the dynamic reloc handling code in check_relocs,
+ removing leftover comments and code from when check_relocs was called
+ as each object file was read in.
+
+ bfd/
+ * elf32-ppc.c (ppc_elf_check_relocs): Set isym and ifunc earlier.
+ Rearrange tests for dynamic relocs, handling absolute symbols.
+ (allocate_dynrelocs): Don't allocate dynamic relocs for locally
+ defined absolute symbols.
+ (ppc_elf_size_dynamic_sections): Similarly.
+ (ppc_elf_relocate_section): Similarly.
+ ld/
+ * testsuite/ld-powerpc/abs32-pie.d,
+ * testsuite/ld-powerpc/abs32-pie.r,
+ * testsuite/ld-powerpc/abs32-reloc.s,
+ * testsuite/ld-powerpc/abs32-shared.d,
+ * testsuite/ld-powerpc/abs32-shared.r,
+ * testsuite/ld-powerpc/abs32-static.d,
+ * testsuite/ld-powerpc/abs32-static.r: New tests.
+ * testsuite/ld-powerpc/powerpc.exp: Run them.
+
+2022-05-04 John Baldwin <jhb@FreeBSD.org>
+
+ gdbserver: Fix build after adding tls feature to arm tdesc.
+
+2022-05-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-04 John Baldwin <jhb@FreeBSD.org>
+
+ NEWS: Add a note for TLS support on FreeBSD/arm and FreeBSD/Aarch64.
+
+ Read the tpidr register from NT_ARM_TLS on Linux.
+
+ gdbserver: Read the tpidr register from NT_ARM_TLS on Linux.
+
+ Read the tpidr register from NT_ARM_TLS core dump notes on Linux Aarch64.
+
+ Fetch the NT_ARM_TLS register set for native FreeBSD/Aarch64 processes.
+ This permits resolving TLS variables.
+
+ Support TLS variables on FreeBSD/Aarch64.
+ Derive the pointer to the DTV array from the tpidr register.
+
+ Read the tpidr register from NT_ARM_TLS core dump notes on FreeBSD/Aarch64.
+
+ Add an aarch64-tls feature which includes the tpidr register.
+
+ Fetch the NT_ARM_TLS register set for native FreeBSD/arm processes.
+ This permits resolving TLS variables.
+
+ Support TLS variables on FreeBSD/arm.
+ Derive the pointer to the DTV array from the tpidruro register.
+
+ Read the tpidruro register from NT_ARM_TLS core dump notes on FreeBSD/arm.
+
+ Add an arm-tls feature which includes the tpidruro register from CP15.
+
+ fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET.
+ FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
+ operations to fetch a register set named by an ELF note type. These
+ helper routines provide helpers to check for a register set's
+ existence, fetch registers for a register set, and store registers to
+ a register set.
+
+2022-05-03 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Regenerate aclocal.m4 with automake 1.15.1
+ * aclocal.m4: Regenerate with automake 1.15.1.
+
+2022-05-03 Pedro Alves <pedro@palves.net>
+
+ gdbserver: track current process as well as current thread
+ The recent commit 421490af33bf ("gdbserver/linux: Access memory even
+ if threads are running") caused a regression in
+ gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I
+ somehow missed. Like so:
+
+ (gdb) print global_var
+ Cannot access memory at address 0x555555558010
+ (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1)
+
+ The problem starts with GDB telling GDBserver to select a thread, via
+ the Hg packet, which GDBserver complies with, then that thread exits,
+ and GDB, without knowing the thread is gone, tries to write to memory,
+ through the context of the previously selected Hg thread.
+
+ GDBserver's GDB-facing memory access routines, gdb_read_memory and
+ gdb_write_memory, call set_desired_thread to make GDBserver re-select
+ the thread that GDB has selected with the Hg packet. Since the thread
+ is gone, set_desired_thread returns false, and the memory access
+ fails.
+
+ Now, to access memory, it doesn't really matter which thread is
+ selected. All we should need is the target process. Even if the
+ thread that GDB previously selected is gone, and GDB does not yet know
+ about that exit, it shouldn't matter, GDBserver should still know
+ which process that thread belonged to.
+
+ Fix this by making GDBserver track the current process separately,
+ like GDB also does. Add a new set_desired_process routine that is
+ similar to set_desired_thread, but just sets the current process,
+ leaving the current thread as NULL. Use it in the GDB-facing memory
+ read and write routines, to avoid failing if the selected thread is
+ gone, but the process is still around.
+
+ Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd
+
+2022-05-03 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
+ When testing gdb.threads/access-mem-running-thread-exit.exp with
+ --target_board=native-extended-gdbserver, we get:
+
+ Running gdb.threads/access-mem-running-thread-exit.exp ...
+ FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
+ WARNING: Timed out waiting for EOF in server after monitor exit
+
+ === gdb Summary ===
+
+ # of expected passes 3
+ # of unexpected failures 1
+ # of unsupported tests 1
+
+ The problem is that the testcase spawns a second inferior with
+ -no-connection, and then runto_main does "run", which fails like so:
+
+ (gdb) run
+ Don't know how to run. Try "help target".
+ (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
+
+ That "run" above failed because native-extended-gdbserver forces "set
+ auto-connect-native-target off", to prevent testcases from mistakenly
+ running programs with the native target, which would exactly be the
+ case here.
+
+ Fix this by letting the second inferior share the first inferior's
+ connection everywhere except on targets that do reload on run (e.g.,
+ --target_board=native-gdbserver).
+
+ Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add some additional thread status debug output
+ While working on this patch:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html
+
+ I found it really useful to print the executing/resumed status of all
+ threads (or all threads in a particular inferior) at various
+ places (e.g. when a new inferior is started, when GDB attaches, etc).
+
+ This debug was originally part of the above patch, but I wanted to
+ rewrite this as a separate patch and move the code into a new function
+ in infrun.h, which is what this patch does.
+
+ Unless 'set debug infrun on' is in effect, then there should be no
+ user visible changes after this commit.
+
+2022-05-03 Nick Clifton <nickc@redhat.com>
+
+ Add a linker warning when creating potentially dangerous executable segments. Add tests, options to disabke and configure switches to choose defaults.
+
+ Fix potential arithmetic overflow in the linker's plugin handling code.
+ PR 29101
+ * libdep_plugin.c (get_libdeps): Check for overflow when computing
+ amount of memory to allocate.
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ objdump: fix styled printing of addresses
+ Previous work to add styled disassembler output missed a case in
+ objdump_print_addr, which is fixed in this commit.
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: small cleanup in mi-break-qualified.exp
+ It is not necessary to pass an empty string to mi_gdb_start, passing
+ the empty string is equivalent to passing no arguments, which is what
+ we do everywhere else (that we don't need to specify an actual
+ argument).
+
+ The only place we use 'mi_gdb_start ""' is in
+ gdb.mi/mi-break-qualified.exp, so in this commit I just replace that
+ with a call to 'mi_gdb_start' - just for consistency.
+
+ There should be no change in what is tested after this commit.
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: change mi_gdb_start to take a list of flags
+ After this previous commit I was thinking about the API of
+ mi_gdb_start. I felt that the idea of passing flags as separate
+ arguments and using 'args' to gather these into a list, though clever,
+ was not an intuitive API.
+
+ In this commit I modify mi_gdb_start so that it expects a single
+ argument, which should be a list of flags. Thus, where we previously
+ would have said:
+
+ mi_gdb_start separate-mi-tty separate-inferior-tty
+
+ We would now say:
+
+ mi_gdb_start { separate-mi-tty separate-inferior-tty }
+
+ However, it turns out we never actually call mi_gdb_start passing two
+ arguments in this way at all. We do in some places do this:
+
+ mi_gdb_start separate-inferior-tty
+
+ But that's fine, a single string like this works equally well as a
+ single item list, so this will not need updating.
+
+ There is also one place where we do this:
+
+ eval mi_gdb_start $start_ops
+
+ where $start_ops is a list that might contains 0, 1, or 2 items. The
+ eval here is used to expand the $start_ops list so mi_gdb_start sees
+ the list contents as separate arguments. In this case we just need to
+ drop the use of eval.
+
+ I think that the new API is more intuitive, but others might
+ disagree, in which case I can drop this change.
+
+ There should be no change in what is tested after this commit.
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver board
+ When running with the native-extended-gdbserver board, I currently see
+ one failure in gdb.mi/mi-exec-run.exp:
+
+ FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
+
+ In this test the MI interface should be started in a separate tty,
+ which means we should have a CLI tty and an MI tty, however, this is
+ not happening. Instead GDB is just started in MI mode and there is no
+ CLI tty.
+
+ The test script tries to switch between the CLI an MI terminals and
+ look for some expected output on each, however, as there is no CLI
+ terminal the expected output never arrives, and the test times out.
+
+ It turns out that this is not a GDB problem, rather, this is an issue
+ with argument passing within the test script.
+
+ The proc default_mi_gdb_start expects to take a set of flags (strings)
+ as arguments, each of flag is expected to be a separate argument. The
+ default_mi_gdb_start proc collects all its arguments into a list using
+ the special 'args' parameter name, and then iterates over this list to
+ see which flags were passed.
+
+ In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
+ are also gathered into the 'args' parameter list, but are then
+ expanded back to be separate arguments using the eval trick, i.e.:
+
+ proc mi_gdb_start { args } {
+ return [eval default_mi_gdb_start $args]
+ }
+
+ This ensures that when we arrive in default_mi_gdb_start each flag is
+ a separate argument, rather than appearing as a single list containing
+ all arguments.
+
+ When using the native-extended-gdbserver board however, the file
+ boards/native-extended-gdbserver.exp is loaded, and this file replaces
+ the default mi_gdb_start with its own version.
+
+ This new mi_gdb_start also gathers the arguments into an 'args' list,
+ but forgets to expand the arguments out using the eval trick.
+
+ As a result, when using the native-extended-gdbserver board, by the
+ time we get to default_mi_gdb_start, we end up with the args list
+ containing a single item, which is a list containing all the arguments
+ the user passed.
+
+ What this means is that if the user passes two arguments, then, in
+ default_mi_gdb_start, instead of seeing two separate arguments, we see
+ a single argument made by concatenating the two arguments together.
+
+ The only place this is a problem is in the test mi-exec-run.exp,
+ which (as far as I can see) is the only test where we might try to
+ pass both arguments at the same time. Currently we think we passed
+ both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
+ arguments were passed.
+
+ This commit fixes the problem by making use of the eval trick within
+ the native-extended-gdbserver version of mi_gdb_start. After this,
+ the FAIL listed at the top of this message is resolved.
+
+2022-05-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver
+ When running the gdb.mi/mi-exec-run.exp test using the
+ native-extended-gdbserver I see failures like this:
+
+ FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
+ FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
+ FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
+
+ There's a race condition here, so you might see a slightly different
+ set of failures, but I always see some from the 'run failure detected'
+ test.
+
+ NOTE: I also see an additional test failure:
+
+ FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
+
+ but that is a completely different issue, and is not being addressed
+ in this commit.
+
+ The problem for the 'run failure detected' test is that we end up
+ in gdb_expect looking for output from two spawn-ids, one from
+ gdbserver, and one from gdb. We're looking for one output pattern
+ from each spawn-id, and for the test to pass we need to see both
+ patterns.
+
+ Now, if gdb exits then this is a test failure (this would indicate gdb
+ crashing, which is bad), so we have an eof pattern associated with
+ the gdb spawn-id.
+
+ However, in this particular test we expect gdbserver to fail to
+ execute the binary (the test binary is set non-executable), and so we
+ get an error message from gdbserver (which matches the pattern), and
+ then gdbserver exits, this is expected.
+
+ The problem is that after spotting the pattern from gdbserver, we
+ often see the eof from gdbserver before we see the pattern from gdb.
+ If this happens then we drop out of the gdb_expect without ever seeing
+ the pattern from gdb, and fail the test.
+
+ In this commit, I place the spawn-id of gdbserver into a global
+ variable, and then use this global variable as the -i option within
+ the gdb_expect.
+
+ Now, once we have seen the expected pattern on the gdbserver spawn-id,
+ the global variable is cleared. After this the gdb_expect no longer
+ checks the gdbserver spawn-id for additional output, and so never sees
+ the eof event. This leaves the gdb_expect running, which allows the
+ pattern from gdb to be seen, and for the test to pass.
+
+ I now see no failures relating to 'run failure detected'.
+
+2022-05-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/align.exp with gcc 12.1 / 11.3
+ Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
+ ...
+ align.cc:29:23: error: invalid application of 'alignof' to a void type^M
+ 29 | unsigned a_void = alignof (void);^M
+ | ^~~~~~~~~~~~~~^M
+ ...
+
+ Fix this by using __alignof__ instead.
+
+ Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.
+
+2022-05-02 Aaron Merey <amerey@redhat.com>
+
+ gdb/debuginfod: Whitespace-only URL should disable debuginfod
+ Currently debuginfod is disabled when the string of server URLs
+ is unset or set to be the empty string (via the $DEBUGINFOD_URLS
+ environment variable or the 'set debuginfod urls' gdb command).
+
+ Extend this functionality so that a whitespace-only URL also disables
+ debuginfod.
+
+ Modify a testcase to verify that a whitespace-only URL disables
+ debuginfod.
+
+2022-05-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove type_wanted parameter from a few functions
+ The type_wanted value, passed down to the create_sals_from_location
+ callback, is never used. Remove it.
+
+ Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c
+
+2022-05-02 Simon Marchi <simon.marchi@efficios.com>
+
+ gnulib: update to bd11400942d6
+ Update the gnulib import to fixes these issues:
+
+ - GDB build with clang + glibc < 2.33.
+
+ https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d6a07b4dc21b3118727743142c678858df442853
+ https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00072.html
+
+ With glibc < 2.33, gnulib (since relatively recently) enables a
+ replacement for free (see gnulib/import/m4/free.m4). In that path,
+ clang shows this error:
+
+ make[2]: Entering directory '/home/smarchi/build/binutils-gdb-clang/gdbsupport'
+ CXX agent.o
+ In file included from /home/smarchi/src/binutils-gdb/gdbsupport/agent.cc:20:
+ In file included from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:95:
+ ../gnulib/import/string.h:636:19: error: exception specification in declaration does not match previous declaration
+ _GL_EXTERN_C void free (void *) throw ();
+ ^
+ ../gnulib/import/stdlib.h:737:17: note: expanded from macro 'free'
+ # define free rpl_free
+ ^
+ ../gnulib/import/stdlib.h:739:1: note: previous declaration is here
+ _GL_FUNCDECL_RPL (free, void, (void *ptr));
+ ^
+ ../gnulib/import/sys/select.h:251:23: note: expanded from macro '_GL_FUNCDECL_RPL'
+ _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes)
+ ^
+ <scratch space>:139:1: note: expanded from here
+ rpl_free
+ ^
+
+ The gnulib commit mentioned fixes the exception specification of `free`.
+
+ - GDB build on RHEL 7:
+
+ CC libgnu_a-openat-proc.o
+ In file included from /usr/include/string.h:633,
+ from ./string.h:41,
+ from ../../../binutils-gdb/gnulib/import/openat-proc.c:30:
+ ./string.h:1105:1: error: expected identifier or '(' before '__extension__'
+ 1105 | _GL_FUNCDECL_SYS (strndup, char *,
+ | ^~~~~~~~~~~~~~~~
+
+ https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
+ https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00075.html
+
+ Change-Id: Ibd51302feece6f385d0c53e0d08921b5d95e2776
+
+2022-05-02 Tom Tromey <tromey@adacore.com>
+
+ Fix Ada catchpoint regression
+ The breakpoint C++-ification series introduced a regression for Ada
+ catchpoints. Specifically, commit 2b5ab5b8 ("Convert base breakpoints
+ to vtable ops") caused these to start failing. I didn't notice this
+ because testing Ada using a Linux distro compiler requires installing
+ the GNAT debuginfo, which I hadn't done.
+
+ This patch fixes the problem. I'm checking it in.
+
+2022-05-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-05-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.multi/attach-no-multi-process.exp with check-readmore
+ When running test-case gdb.multi/attach-no-multi-process.exp with
+ check-readmore, I get:
+ ...
+ (gdb) attach 13411^M
+ Attaching to Remote target^M
+ No unwaited-for children left.^M
+ (gdb) Reading symbols from attach-no-multi-process...^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/ld-linux-x86-64.so.2...^M
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
+ 0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
+ FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
+ attach to the program via remote (timeout)
+ ...
+
+ The problem is that the attach output is matched using gdb_test, which uses
+ the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is
+ not the last available output.
+
+ Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so
+ without the '$' anchor.
+
+ Tested on x86_64-linux with native, check-read1 and check-readmore.
+
+2022-05-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-30 Thomas Hebb <tommyhebb@gmail.com>
+
+ opcodes: don't assume ELF in riscv, csky, rl78, mep disassemblers
+ Currently, the get_disassembler() implementations for riscv, csky, and
+ rl78--and mep_print_insn() for mep--access ELF variants of union fields
+ without first checking that the bfd actually represents an ELF. This
+ causes undefined behavior and crashes when disassembling non-ELF files
+ (the "binary" BFD, for example). Fix that.
+
+2022-04-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Remove create_breakpoints_sal_default
+ create_breakpoints_sal_default is just a simple wrapper, so remove it.
+
+ Remove allocate_bp_location
+ allocate_bp_location is just a small wrapper for a method call, so
+ inline it everywhere.
+
+ Constify breakpoint_ops
+ Now that all breakpoint_ops are statically initialized, they can all
+ be made const.
+
+ Remove breakpoint ops initialization
+ initialize_breakpoint_ops does not do much any more, so remove it in
+ favor of statically-initialize objects.
+
+ Remove vtable_breakpoint_ops
+ There's no need to have vtable_breakpoint_ops any more, so remove it
+ in favor of base_breakpoint_ops.
+
+ Remove most fields from breakpoint_ops
+ At this point, all implementations of breakpoints use the vtable. So,
+ we can now remove most function pointers from breakpoint_ops and
+ switch to using methods directly in the callers. Only the two "static
+ virtual" methods remain in breakpoint_ops.
+
+ Remove breakpoint_ops from init_catchpoint
+ init_catchpoint is only ever passed a single breakpoint_ops pointer,
+ so remove the parameter.
+
+ Remove breakpoint_ops from init_ada_exception_breakpoint
+ init_ada_exception_breakpoint is only ever passed a single
+ breakpoint_ops structure, so remove the parameter.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Merge probe and ordinary tracepoints
+ Right now, probe tracepoints are handled by a separate ops object.
+ However, they differ only in a small way from ordinary tracepoints,
+ and furthermore can be distinguished by their event location.
+
+ This patch merges the two cases, just as was done for breakpoints.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Merge probe and ordinary breakpoints
+ Right now, probe breakpoints are handled by a separate ops object.
+ However, they differ only in a small way from ordinary breakpoints,
+ and furthermore can be distinguished by their "probe" object.
+
+ This patch merges the two cases. This avoids having to introduce a
+ new bp_ constant (which can be quite subtle to do correctly) and a new
+ subclass.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Remove bkpt_base_breakpoint_ops
+ An earlier patch removed the last use of bkpt_base_breakpoint_ops, so
+ remove the object entirely.
+
+ Convert static marker tracepoints to vtable ops
+ This converts static marker tracepoints to use vtable_breakpoint_ops.
+
+ Add bp_static_marker_tracepoint
+ Because the actual construction of a breakpoint is buried deep in
+ create_breakpoint, at present it's necessary to have a new bp_
+ enumerator constant any time a new subclass is needed. Static marker
+ tracepoints are one such case, so this patch introduces
+ bp_static_marker_tracepoint and updates various spots to recognize it.
+
+ Convert ranged breakpoints to vtable ops
+ This converts ranged breakpoints to use vtable_breakpoint_ops. This
+ requires introducing a new ranged_breakpoint type, but this is
+ relatively simple because ranged breakpoints can only be created by
+ break_range_command.
+
+ Convert dprintf to vtable ops
+ This converts dprintf to use vtable_breakpoint_ops.
+
+ Convert Ada catchpoints to vtable ops
+ This converts Ada catchpoints to use vtable_breakpoint_ops.
+
+ Convert ordinary breakpoints to vtable ops
+ This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
+ Recall that an ordinary breakpoint is both the kind normally created
+ by users, and also a base class used by other classes.
+
+ Change inheritance of dprintf
+ The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops,
+ except it's written out explicitly -- and, importantly, there's
+ nothing that bpkt_breakpoint_ops overrides that dprintf does not.
+ This changes dprintf to simply inherit directly, and updates struct
+ dprintf_breakpoint to reflect the change as well.
+
+ Convert momentary breakpoints to vtable ops
+ This converts momentary breakpoints to use vtable_breakpoint_ops.
+
+ Convert internal breakpoints to vtable ops
+ This converts internal breakpoints to use vtable_breakpoint_ops.
+
+ Convert break-catch-throw to vtable ops
+ This converts break-catch-throw.c to use vtable_breakpoint_ops.
+
+ Convert base breakpoints to vtable ops
+ This converts base breakpoints to use vtable_breakpoint_ops.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Add some new subclasses of breakpoint
+ This adds a few new subclasses of breakpoint. The inheritance
+ hierarchy is chosen to reflect what's already present in
+ initialize_breakpoint_ops -- it mirrors the way that the _ops
+ structures are filled in.
+
+ This patch also changes new_breakpoint_from_type to create the correct
+ sublcass based on bptype. This is important due to the somewhat
+ inverted way in which create_breakpoint works; and in particular later
+ patches will change some of these entries.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Convert tracepoints to vtable ops
+ This converts tracepoints to use vtable_breakpoint_ops.
+
+ Convert watchpoints to vtable ops
+ This converts watchpoints and masked watchpoints. to use
+ vtable_breakpoint_ops. For masked watchpoints, a new subclass must be
+ introduced, and watch_command_1 is changed to create one.
+
+ Convert break-catch-load to vtable ops
+ This converts break-catch-load.c to use vtable_breakpoint_ops.
+
+ Convert break-catch-fork to vtable ops
+ This converts break-catch-fork.c to use vtable_breakpoint_ops.
+
+ Convert break-catch-exec to vtable ops
+ This converts break-catch-exec.c to use vtable_breakpoint_ops.
+
+ Convert break-catch-syscall to vtable ops
+ This converts break-catch-syscall.c to use vtable_breakpoint_ops.
+
+ Convert break-catch-sig to use vtable ops
+ This converts break-catch-sig.c to use vtable_breakpoint_ops.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Add a vtable-based breakpoint ops
+ This adds methods to struct breakpoint. Each method has a similar
+ signature to a corresponding function in breakpoint_ops, with the
+ exceptions of create_sals_from_location and create_breakpoints_sal,
+ which can't be virtual methods on breakpoint -- they are only used
+ during the construction of breakpoints.
+
+ Then, this adds a new vtable_breakpoint_ops structure and populates it
+ with functions that simply forward a call from breakpoint_ops to the
+ corresponding virtual method. These are all done with lambdas,
+ because they are just a stepping stone -- by the end of the series,
+ this structure will be deleted.
+
+2022-04-29 Tom Tromey <tom@tromey.com>
+
+ Return bool from breakpoint_ops::print_one
+ This changes breakpoint_ops::print_one to return bool, and updates all
+ the implementations and the caller. The caller is changed so that a
+ NULL check is no longer needed -- something that will be impossible
+ with a real method.
+
+ Delete some unnecessary wrapper functions
+ This patch deletes a few unnecessary wrapper functions from
+ breakpoint.c.
+
+ Add an assertion to clone_momentary_breakpoint
+ This adds an assertion to clone_momentary_breakpoint. This will
+ eventually be removed, but in the meantime is is useful for helping
+ convince oneself that momentary breakpoints will always use
+ momentary_breakpoint_ops. This understanding will help when cleaning
+ up the code later.
+
+ Boolify print_solib_event
+ Change print_solib_event to accept a bool parameter and update the
+ callers.
+
+ Move "catch load" to a new file
+ The "catch load" code is reasonably self-contained, and so this patch
+ moves it out of breakpoint.c and into a new file, break-catch-load.c.
+ One function from breakpoint.c, print_solib_event, now has to be
+ exposed, but this seems pretty reasonable.
+
+2022-04-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: assertion in gprofng/src/Expression.cc:139
+ gprofng/ChangeLog
+ 2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29102
+ * src/Expression.h: Remove fixupValues.
+ * src/Expression.cc (Expression::copy): Fix a bug.
+
+2022-04-29 Tom Tromey <tromey@adacore.com>
+
+ De-duplicate .gdb_index
+ This de-duplicates variables and types in .gdb_index, making the new
+ index closer to what gdb generated before the new DWARF scanner
+ series. Spot-checking the resulting index for gdb itself, it seems
+ that the new scanner picks up some extra symbols not detected by the
+ old one. I tested both the new and old versions of gdb on both new
+ and old versions of the index, and startup time in all cases is
+ roughly the same (it's worth noting that, for gdb itself, the index no
+ longer provides any benefit over the DWARF scanner). So, I think this
+ fixes the size issue with the new index writer.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-04-29 Tom Tromey <tromey@adacore.com>
+
+ Fix .debug_names regression with new indexer
+ At AdaCore, we run the internal gdb test suite in several modes,
+ including one using the .debug_names index. This caught a regression
+ caused by the new DWARF indexer.
+
+ First, the psymtabs-based .debug_names generator was completely wrong.
+ However, to avoid making the rewrite series even bigger (fixing the
+ writer will also require rewriting the .debug_names reader), it
+ attempted to preserve the weirdness.
+
+ However, this was not done properly. For example the old writer did
+ this:
+
+ - case STRUCT_DOMAIN:
+ - return DW_TAG_structure_type;
+
+ The new code, instead, simply preserves the actual DWARF tag -- but
+ this makes future lookups fail, because the .debug_names reader only
+ looks for DW_TAG_structure_type.
+
+ This patch attempts to revert to the old behavior in the writer.
+
+2022-04-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/infrun: make fetch_inferior_event restore thread if exited or signalled
+ Commit 152a1749566 ("gdb: prune inferiors at end of
+ fetch_inferior_event, fix intermittent failure of
+ gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related
+ test failures, such as:
+
+ info inferiors^M
+ Num Description Connection Executable ^M
+ * 1 process 634972 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
+ 2 process 634975 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
+ (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors
+ inferior 2^M
+ [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M
+ [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M
+ #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M
+ (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2
+ continue^M
+ Continuing.^M
+ [Inferior 2 (process 634975) exited normally]^M
+ [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M
+ (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end
+ break callee^M
+ Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M
+ (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee
+
+ What happens here is:
+
+ - inferior 2 is selected
+ - we continue, leading to inferior 2's exit
+ - we set breakpoint, expect 2 locations, but only one location is
+ resolved
+
+ Reading between the lines, we understand that inferior 2 got pruned,
+ when it shouldn't have been.
+
+ The issue can be reproduced by hand with:
+
+ $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun"
+ ...
+ Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14
+ 14 int v = 5;
+ [New inferior 2 (process 637627)]
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+ 17 if (pid == 0) /* set breakpoint here */
+ [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]
+ [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))]
+ #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6
+ (gdb) continue
+ Continuing.
+ [infrun] clear_proceed_status_thread: 637627.637627.0
+ [infrun] proceed: enter
+ [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [infrun] start_step_over: enter
+ [infrun] start_step_over: stealing global queue of threads to step, length = 0
+ [infrun] operator(): step-over queue now empty
+ [infrun] start_step_over: exit
+ [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
+ [infrun] proceed: resuming 637627.637627.0
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7
+ [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0
+ [infrun] infrun_async: enable=1
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
+ [infrun] reset: reason=proceeding
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
+ [infrun] proceed: exit
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] do_target_wait: Found 2 inferiors, starting at #1
+ [infrun] random_pending_event_thread: None found.
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 637627.637627.0 [process 637627],
+ [infrun] print_target_wait_results: status->kind = EXITED, exit_status = 0
+ [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0
+ [Inferior 2 (process 637627) exited normally]
+ [infrun] stop_waiting: stop_waiting
+ [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1
+ [infrun] stop_all_threads: pass=0, iterations=0
+ [infrun] stop_all_threads: 637624.637624.0 not executing
+ [infrun] stop_all_threads: pass=1, iterations=1
+ [infrun] stop_all_threads: 637624.637624.0 not executing
+ [infrun] stop_all_threads: done
+ [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1
+ [Switching to Thread 0x7ffff7c9a740 (LWP 637624)]
+ [infrun] infrun_async: enable=0
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+ (gdb) [infrun] fetch_inferior_event: exit
+ (gdb) info inferiors
+ Num Description Connection Executable
+ * 1 process 637624 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork
+ (gdb) i th
+ Id Target Id Frame
+ * 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17
+
+ After handling the EXITED event for inferior 2, inferior 2 should have
+ stayed the current inferior, which should have prevented it from getting
+ pruned. When debugging, we find that when getting at the
+ prune_inferiors call, the current inferior is inferior 1. Further
+ debugging shows that prior to the call to
+ clean_up_just_stopped_threads_fsms, the current inferior is inferior 2,
+ and after, it's inferior 1. Then, back in fetch_inferior_event, the
+ restore_thread object is disabled, due to:
+
+ /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the
+ previously selected thread is gone. We have two
+ choices - switch to no thread selected, or restore the
+ previously selected thread (now exited). We chose the
+ later, just because that's what GDB used to do. After
+ this, "info threads" says "The current thread <Thread
+ ID 2> has terminated." instead of "No thread
+ selected.". */
+ if (!non_stop
+ && cmd_done
+ && ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED)
+ restore_thread.dont_restore ();
+
+ So in the end, inferior 1 stays current, and inferior 2 gets wrongfully
+ pruned.
+
+ I'd say clean_up_just_stopped_threads_fsms is the culprit here. It
+ actually attempts to restore the event_thread to be current at the end,
+ after the loop (I presume the current thread on entry is always supposed
+ to be the event thread). But in this case, the event is of kind EXITED,
+ and ecs->event_thread is not set, so the current inferior isn't
+ restored.
+
+ Fix that by using scoped_restore_current_thread. If there is no current
+ thread, scoped_restore_current_thread will still restore the current
+ inferior, and that's what we want.
+
+ Random note: the thread_info object for inferior 2's thread is never
+ freed. It is held (by refcount) by the restore_thread object in
+ fetch_inferior_event, while the inferior's thread list gets cleared, in
+ the exit event processing. When the refcount reaches 0 (when the
+ restore_thread object is destroyed), there's nothing that actually
+ deletes the thread_info object. And I think that nothing in GDB points
+ to it anymore, so it leaks. I don't want to fix that in this patch, but
+ thought it would be good to mention it, in case somebody has an idea for
+ how to fix that.
+
+ Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8
+
+2022-04-29 Pedro Alves <pedro@palves.net>
+
+ Slightly tweak and clarify target_resume's interface
+ The current target_resume interface is a bit odd & non-intuitive.
+ I've found myself explaining it a couple times the recent past, while
+ reviewing patches that assumed STEP/SIGNAL always applied to the
+ passed in PTID. It goes like this today:
+
+ - if the passed in PTID is a thread, then the step/signal request is
+ for that thread.
+
+ - otherwise, if PTID is a wildcard (all threads or all threads of
+ process), the step/signal request is for inferior_ptid, and PTID
+ indicates which set of threads run free.
+
+ Because GDB always switches the current thread to "leader" thread
+ being resumed/stepped/signalled, we can simplify this a bit to:
+
+ - step/signal are always for inferior_ptid.
+
+ - PTID indicates the set of threads that run free.
+
+ Still not ideal, but it's a minimal change and at least there are no
+ special cases this way.
+
+ That's what this patch does. It renames the PTID parameter to
+ SCOPE_PTID, adds some assertions to target_resume, and tweaks
+ target_resume's description. In addition, it also renames PTID to
+ SCOPE_PTID in the remote and linux-nat targets, and simplifies their
+ implementation a little bit. Other targets could do the same, but
+ they don't have to.
+
+ Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
+
+2022-04-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-28 Tom Tromey <tromey@adacore.com>
+
+ Fix libinproctrace.so build on PPC
+ The recent gnulib import caused a build failure of libinproctrace.so
+ on PPC:
+
+ alloc.c:(.text+0x20): undefined reference to `rpl_malloc'
+ alloc.c:(.text+0x70): undefined reference to `rpl_realloc'
+
+ This patch fixes the problem using the same workaround that was
+ previously used for free.
+
+2022-04-28 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Properly handle function pointer reference
+ Update
+
+ commit ebb191adac4ab45498dec0bfaac62f0a33537ba4
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Wed Feb 9 15:51:22 2022 -0800
+
+ x86: Disallow invalid relocation against protected symbol
+
+ to allow function pointer reference and make sure that PLT entry isn't
+ used for function reference due to function pointer reference.
+
+ bfd/
+
+ PR ld/29087
+ * elf32-i386.c (elf_i386_scan_relocs): Don't set
+ pointer_equality_needed nor check non-canonical reference for
+ function pointer reference.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+ ld/
+
+ PR ld/29087
+ * testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests.
+ * testsuite/ld-x86-64/protected-func-3.c: New file.
+
+2022-04-28 Tom Tromey <tom@tromey.com>
+
+ Check OBJF_NOT_FILENAME in DWARF index code
+ The DWARF index code currently uses 'stat' to see if an objfile
+ represents a real file. However, I think it's more correct to check
+ OBJF_NOT_FILENAME instead.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-04-28 Tom Tromey <tromey@adacore.com>
+
+ Remove "typedef enum ..."
+ I noticed a few spots in GDB that use "typedef enum". However, in C++
+ this isn't as useful, as the tag is automatically entered as a
+ typedef. This patch removes most uses of "typedef enum" -- the
+ exceptions being in some nat-* code I can't compile, and
+ glibc_thread_db.h, which I think is more or less a copy of some C code
+ from elsewhere.
+
+ Tested by rebuilding.
+
+2022-04-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix nullptr dereference in block::ranges()
+ This commit:
+
+ commit f5cb8afdd297dd68273d98a10fbfd350dff918d8
+ Date: Sun Feb 6 22:27:53 2022 -0500
+
+ gdb: remove BLOCK_RANGES macro
+
+ introduces a potential nullptr dereference in block::ranges, this is
+ breaking most tests, e.g. gdb.base/break.exp is failing for me.
+
+ In the above patch BLOCK_CONTIGUOUS_P is changed from this:
+
+ #define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \
+ || BLOCK_NRANGES (bl) <= 1)
+
+ to this:
+
+ #define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \
+ || (bl)->ranges ().size () == 1)
+
+ So, before the commit we checked for the block ranges being nullptr,
+ but afterwards we just call block::ranges() in all cases.
+
+ The problem is that block::ranges() looks like this:
+
+ /* Return a view on this block's ranges. */
+ gdb::array_view<blockrange> ranges ()
+ { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); }
+
+ where m_ranges is:
+
+ struct blockranges *m_ranges;
+
+ And so, we see that the nullptr check has been lost, and we might end
+ up dereferencing a nullptr.
+
+ My proposed fix is to move the nullptr check into block::ranges, and
+ return an explicit empty array_view if m_ranges is nullptr.
+
+ After this, everything seems fine again.
+
+2022-04-28 Stefan Liebler <stli@linux.ibm.com>
+
+ s390: Add DT_JMPREL pointing to .rela.[i]plt with static-pie
+ In static-pie case, there are IRELATIVE-relocs in
+ .rela.iplt (htab->irelplt), which will later be grouped
+ to .rela.plt. On s390, the IRELATIVE relocations are
+ always located in .rela.iplt - even for non-static case.
+ Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added
+ to the dynamic section even if htab->srelplt->size == 0.
+ See _bfd_elf_add_dynamic_tags in bfd/elflink.c.
+
+ bfd/
+ elf64-s390.c (elf_s390_size_dynamic_sections):
+ Enforce DT_JMPREL via htab->elf.dt_jmprel_required.
+
+2022-04-28 Stefan Liebler <stli@linux.ibm.com>
+
+ s390: Avoid dynamic TLS relocs in PIE
+ No dynamic relocs are needed for TLS defined in an executable, the
+ TP relative offset is known at link time.
+
+ Fixes
+ FAIL: Build pr22263-1
+
+ bfd/
+ PR ld/22263
+ * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll
+ instead of bfd_link_pic for TLS.
+ (elf_s390_check_relocs): Likewise.
+ (allocate_dynrelocs): Likewise.
+ (elf_s390_relocate_section): Likewise.
+
+2022-04-28 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: impose an ordering on conflicting types
+ When two types conflict and they are not types which can have forwards
+ (say, two arrays of different sizes with the same name in two different
+ TUs) the CTF deduplicator uses a popularity contest to decide what to
+ do: the type cited by the most other types ends up put into the shared
+ dict, while the others are relegated to per-CU child dicts.
+
+ This works well as long as one type *is* most popular -- but what if
+ there is a tie? If several types have the same popularity count,
+ we end up picking the first we run across and promoting it, and
+ unfortunately since we are working over a dynhash in essentially
+ arbitrary order, this means we promote a random one. So multiple
+ runs of ld with the same inputs can produce different outputs!
+ All the outputs are valid, but this is still undesirable.
+
+ Adjust things to use the same strategy used to sort types on the output:
+ when there is a tie, always put the type that appears in a CU that
+ appeared earlier on the link line (and if there is somehow still a tie,
+ which should be impossible, pick the type with the lowest type ID).
+
+ Add a testcase -- and since this emerged when trying out extern arrays,
+ check that those work as well (this requires a newer GCC, but since all
+ GCCs that can emit CTF at all are unreleased this is probably OK as
+ well).
+
+ Fix up one testcase that has slight type ordering changes as a result
+ of this change.
+
+ libctf/ChangeLog:
+
+ * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
+ cd_output_first_gid to break ties.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
+ * testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
+ * testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
+ * testsuite/ld-ctf/array-extern.d: New test, using...
+ * testsuite/ld-ctf/array-extern.c: ... this.
+ * testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
+ changes.
+
+2022-04-28 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: add a comment explaining how to use ctf_*open
+ Specifically, tell users what to pass to those functions that accept raw
+ section content, since it's fairly involved and easy to get wrong.
+ (.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab).
+
+ include/ChangeLog:
+
+ * ctf-api.h (ctf_*open): Improve comment.
+
+2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: test suite problems
+ gprofng/ChangeLog
+ 2022-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29065
+ * testsuite/lib/Makefile.skel: Search parent dir for libs too.
+
+2022-04-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove BLOCKVECTOR_MAP macro
+ Replace with equivalent methods.
+
+ Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
+
+2022-04-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: constify addrmap_find
+ addrmap_find shouldn't need to modify the addrmap, so constify the
+ addrmap parameter. This helps for the following patch, where getting
+ the map of a const blockvector will return a const addrmap.
+
+ Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macros
+ Replace with calls to blockvector::blocks, and the appropriate method
+ call on the returned array_view.
+
+ Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_ENTRY_PC macro
+ Replace with equivalent method.
+
+ Change-Id: I0e033095e7358799930775e61028b48246971a7d
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_CONTIGUOUS_P macro
+ Replace with an equivalent method.
+
+ Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_RANGE macro
+ Replace with access through the block::ranges method.
+
+ Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_NRANGES macro
+ Replace with range for loops.
+
+ Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_RANGES macro
+ Replace with an equivalent method on struct block.
+
+ Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_RANGE_{START,END} macros
+ Replace with equivalent methods on blockrange.
+
+ Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_NAMESPACE macro
+ Replace with equivalent methods.
+
+ Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_MULTIDICT macro
+ Replace with equivalent methods.
+
+ Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_SUPERBLOCK macro
+ Replace with equivalent methods.
+
+ Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_FUNCTION macro
+ Replace with equivalent methods.
+
+ Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
+
+2022-04-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove BLOCK_{START,END} macros
+ Replace with equivalent methods.
+
+ Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
+
+2022-04-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-27 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Disable 2 tests with large memory requirement
+ gas/
+
+ * testsuite/gas/i386/i386.exp: Disable rept.
+
+ ld/
+
+ * testsuite/ld-x86-64/x86-64.exp: Disable pr17618.
+
+2022-04-27 Pedro Alves <pedro@palves.net>
+
+ Make gdb.base/parse_number.exp test all architectures
+ There are some subtle differences between architectures, like the size
+ of a "long" type, and this isn't currently accounted for in
+ gdb.base/parse_number.exp.
+
+ For example, on aarch64 a long type is 8 bytes, whereas a long type is
+ 4 bytes for x86_64. This causes the following FAIL's:
+
+ FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff
+ FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff
+
+ There are some fortran-specific divergences as well, where 32-bit
+ architectures show "unsigned int" for both 32-bit and 64-bit integers
+ and 64-bit architectures show "unsigned int" and "unsigned long" for
+ 32-bit and 64-bit integers.
+
+ There might be a bug that 32-bit fortran truncates 64-bit values to
+ 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
+
+ Here's what we get for aarch64:
+
+ (gdb) ptype 0xffffffff
+ type = unsigned int
+ (gdb) ptype 0xffffffffffffffff
+ type = unsigned long
+ (gdb) p sizeof (0xffffffff)
+ $1 = 4
+ (gdb) p sizeof (0xffffffffffffffff)
+ quit
+ $2 = 8
+ (gdb) ptype 0xffffffff
+ type = unsigned int
+ (gdb) ptype 0xffffffffffffffff
+ type = unsigned long
+
+ And for arm:
+
+ (gdb) ptype 0xffffffff
+ type = unsigned int
+ (gdb) ptype 0xffffffffffffffff
+ quit
+ type = unsigned long long
+ (gdb) p sizeof (0xffffffff)
+ quit
+ $1 = 4
+ (gdb) p sizeof (0xffffffffffffffff)
+ quit
+ $2 = 8
+ (gdb) ptype 0xffffffff
+ type = unsigned int
+ (gdb) ptype 0xffffffffffffffff
+ type = unsigned long
+
+ This patch...
+
+ * Makes the testcase iterate over all architectures, thus covering all
+ the different combinations of types/sizes every time.
+
+ * Adjusts the expected values and types based on the sizes of long
+ long, long and int.
+
+ A particularly curious architecture is s12z, which has 32-bit long
+ long, and thus no way to represent 64-bit integers in C-like
+ languages.
+
+ Co-Authored-By: Luis Machado <luis.machado@arm.com>
+ Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
+
+2022-04-27 Tom Tromey <tromey@adacore.com>
+
+ Fix gdbserver build for x86-64 Windows
+ I broke the gdbserver build on x86-64 Windows a little while back.
+ Previously, I could not build this configuration, but today I found
+ out that if I configure with:
+
+ --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
+
+ using the Fedora 34 tools, it will in fact build. I'm not certain,
+ but maybe the gnulib update helped with this.
+
+ This patch fixes the build. I'm checking it in.
+
+2022-04-27 John Baldwin <jhb@FreeBSD.org>
+
+ Create pseudo sections for NT_ARM_TLS notes on FreeBSD.
+ bfd/ChangeLog:
+
+ * elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes.
+
+2022-04-27 Christophe Lyon <christophe.lyon@arm.com>
+
+ gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add unwind-secure-frames command
+ This patch makes use of the support for several stack pointers
+ introduced by the previous patch to switch between them as needed
+ during unwinding.
+
+ It introduces a new 'unwind-secure-frames' arm command to enable/disable
+ mode switching during unwinding. It is enabled by default.
+
+ It has been tested using an STM32L5 board (with cortex-m33) and the
+ sample applications shipped with the STM32Cube development
+ environment: GTZC_TZSC_MPCBB_TrustZone in
+ STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC.
+
+ The test consisted in setting breakpoints in various places and check
+ that the backtrace is correct: SecureFault_Callback (Non-secure mode),
+ __gnu_cmse_nonsecure_call (before and after the vpush instruction),
+ SecureFault_Handler (Secure mode).
+
+ This implies that we tested only some parts of this patch (only MSP*
+ were used), but remaining parts seem reasonable.
+
+2022-04-27 Christophe Lyon <christophe.lyon@arm.com>
+
+ gdb/arm: Add support for multiple stack pointers on Cortex-M
+ Armv8-M architecture with Security extension features four stack pointers
+ to handle Secure and Non-secure modes.
+
+ This patch adds support to switch between them as needed during
+ unwinding, and replaces all updates of cache->prev_sp with calls to
+ arm_cache_set_prev_sp.
+
+2022-04-27 Christophe Lyon <christophe.lyon@arm.com>
+
+ gdb/arm: Introduce arm_cache_init
+ This patch is a preparation for the rest of the series and adds two
+ arm_cache_init helper functions. It updates every place that updates
+ cache->saved_regs to call the helper instead.
+
+ gdb/arm: Define MSP and PSP registers for M-Profile
+ This patch removes the hardcoded access to PSP in
+ arm_m_exception_cache() and relies on the definition with the XML
+ descriptions.
+
+2022-04-27 Christophe Lyon <christophe.lyon@arm.com>
+
+ gdb/arm: Fix prologue analysis to support vpush
+ While working on adding support for Non-secure/Secure modes unwinding,
+ I noticed that the prologue analysis lacked support for vpush, which
+ is used for instance in the CMSE stub routine.
+
+ This patch updates thumb_analyze_prologue accordingly, adding support
+ for vpush of D-registers.
+
+2022-04-27 Enze Li <lienze2010@hotmail.com>
+
+ gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.exp
+ Tom and Simon feedback that there is a test failing in this commit:
+
+ commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
+ Date: Sun Apr 17 15:09:46 2022 +0800
+
+ gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
+
+ Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I
+ fixed the nit in this patch. The root of the problem is not correctly
+ matching the presentation of internal breakpoints.
+
+ In addition, as Pedro pointed out, the original testcase is not portable
+ in some methods, so this patch fixes this issue and some other
+ improvements.
+
+ Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
+
+2022-04-27 Jan Beulich <jbeulich@suse.com>
+
+ x86: VFPCLASSSH is Evex.LLIG
+ This also was mistakenly flagged as Evex.128.
+
+2022-04-27 Nick Clifton <nickc@redhat.com>
+
+ Fix potential buffer overruns when creating DLLs.
+ PR 29006
+ * pe-dll.c (make_head): Use asprintf to allocate and populate a
+ buffer containing the temporary name.
+ (make_tail, make_one, make_singleton_name_thunk): Likewise.
+ (make_import_fixup_mark, make_import_fixup_entry): Likewise.
+ (make_runtime_pseudo_reloc): Likewise.
+ (pe_create_runtime_relocator_reference): Likewise.
+
+2022-04-27 Alan Modra <amodra@gmail.com>
+
+ Revert pr29072 lto test changes
+ Revert commit 65daf5bed6 testsuite changes in ld-plugin/. -z isn't
+ supported for non-ELF targets, and isn't needed since we now prune the
+ exec stack warning (commit 333cd559ba).
+
+ PR 29072
+
+2022-04-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: use with_cwd where possible
+ I learned about with_cwd today. I spotted a few spots that could use
+ it, to make the code more robust.
+
+ Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
+
+2022-04-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-26 Carl Love <cel@us.ibm.com>
+
+ GDB PowerPC record test cases for ISA 2.06 and ISA 3.1
+ This patch adds PowerPC specific tests to verify recording of various
+ instructions. The first test case checks the ISA 2.06 lxvd2x instruction.
+ The second test case tests several of the ISA 3.01 instructions. Specifically,
+ it checks the word and prefixed instructions and some of the Matrix
+ Multiply Assist (MMA) instructions.
+
+ The patch has been run on both Power 10 and Power 9 to verify the ISA
+ 2.06 test case runs on both platforms without errors. The ISA 3.1 test
+ runs without errors on Power 10 and is skipped as expected on Power 9.
+
+2022-04-26 Carl Love <cel@us.ibm.com>
+
+ Add recording support for the ISA 3.1 PowerPC instructions.
+ This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC
+ gdb instruction recording routines. Case statement entries are added to a
+ number of the existing routines for recording the 32-bit word instructions.
+ A few new functions were added to handle the new word instructions. The 64-bit
+ prefix instructions are all handled by a set of new routines. The function
+ ppc_process_prefix_instruction() is the primary function to handle the
+ prefixed instructions. It calls additional functions to handle specific
+ sets of prefixed instructions. These new functions are:
+ ppc_process_record_prefix_vsx_d_form(),
+ ppc_process_record_prefix_store_vsx_ds_form(),
+ ppc_process_record_prefix_op34(),
+ ppc_process_record_prefix_op33(),
+ ppc_process_record_prefix_op32(),
+ ppc_process_record_prefix_store(),
+ ppc_process_record_prefix_op59_XX3(),
+ ppc_process_record_prefix_op42().
+
+2022-04-26 Tom Tromey <tromey@adacore.com>
+
+ Handle encoding failures in Windows thread names
+ Internally at AdaCore, we noticed that the new Windows thread name
+ code could fail. First, it might return a zero-length string, but in
+ gdb conventions it should return nullptr instead. Second, an encoding
+ failure could wind up showing replacement characters to the user; this
+ is confusing and not useful; it's better to recognize such errors and
+ simply discard the name. This patch makes both of these changes.
+
+2022-04-26 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Pass -z noexecstack to linker tests
+ PR ld/29072
+ * testsuite/ld-i386/i386.exp: Pass -z noexecstack to gotpc1
+ and property-6.
+
+2022-04-26 John Baldwin <jhb@FreeBSD.org>
+
+ bsd-kvm: Fix build after recent changes to path handling functions.
+ Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to
+ std::string rather than simple char * pointers freed by xfree.
+
+2022-04-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make some random Python files Python 3-compatible
+ I noticed that these files failed to format with Black, because they use
+ print without parenthesis (which isn't Python 3 compatible).
+
+ I don't know if these files are still relevant, but the change is
+ trivial, so here it is.
+
+ Change-Id: I116445c2b463486016f824d32effffc915b60766
+
+2022-04-26 Carl Love <cel@us.ibm.com>
+
+ PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp and gdb.arch/vsx-regs.exp
+ The format for printing the floating point values was changed by commit:
+
+ commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
+ Author: Tom Tromey <tromey@adacore.com>
+ Date: Thu Feb 17 13:43:59 2022 -0700
+
+ Change how "print/x" displays floating-point value
+
+ Currently, "print/x" will display a floating-point value by first
+ casting it to an integer type. This yields weird results like:
+
+ (gdb) print/x 1.5
+ $1 = 0x1
+ ...
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
+
+ The above change results in 417 regression test failures since the expected
+ Power vector register output no longer match.
+
+ This patch updates the expected Altivec floating point register prints to
+ the hexadecimal format for both big endian and little endian systems. The
+ patch also fixes a formatting isue with the decimal_vector expected value
+ assign statements.
+
+ The expected VSX vector_register1, vector_register1_vr, vector_register2,
+ vector_register2_vr variables are updated to include the new float128 entry.
+ Additionally, the comment in the vsx expect file about the initialization
+ of the vs registers is updated.
+
+ The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
+
+2022-04-26 John Baldwin <jhb@FreeBSD.org>
+
+ gdbsupport/pathstuff.h: #include <array> explicitly for std::array<>
+ This fixes build breakage using clang with libc++ on FreeBSD where
+ std::array<> is not yet declared when used by the path_join variadic
+ function template.
+
+2022-04-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-25 Tom Tromey <tromey@adacore.com>
+
+ Do not put linkage names into .gdb_index
+ This changes the .gdb_index writer to skip linkage names. This was
+ always done historically (though somewhat implicitly).
+
+2022-04-25 Nick Clifton <nickc@redhat.com>
+
+ Emit a note warning the user that creating an executable stack because of a missing .note.GNU-stack section is deprecated.
+ PR 29072
+ bfd * elflink.c (bfd_elf_size_dynamic_sections): Display a note to the
+ user that the current ehaviour of creating an executable stack
+ because of a missing .note.GNU-stack section is deprecated and
+ will be changed in a future release.
+
+ binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter
+ out notes about the executable stacjk behaviour beign deprecated.
+
+ ld * testsuite/ld-elf/pr29072.b.warn: Update to include the note
+ about the linker's behaviour being depreccated.
+
+2022-04-25 rupothar <rupesh.potharla@amd.com>
+
+ gdb/fortran: Support for assumed rank zero
+ If a variable is passed to function in FORTRAN as an argument the
+ variable is treated as an array with rank zero. GDB currently does
+ not support the case for assumed rank 0. This patch provides support
+ for assumed rank 0 and updates the testcase as well.
+
+ Without patch:
+ Breakpoint 1, arank::sub1 (a=<error reading variable:
+ failed to resolve dynamic array rank>) at assumedrank.f90:11
+ 11 PRINT *, RANK(a)
+ (gdb) p a
+ failed to resolve dynamic array rank
+ (gdb) p rank(a)
+ failed to resolve dynamic array rank
+
+ With patch:
+ Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11
+ 11 PRINT *, RANK(a)
+ (gdb) p a
+ $1 = 0
+ (gdb) p rank(a)
+ $2 = 0
+
+2022-04-25 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/infrun: assert !step_over_info_valid_p in restart_threads
+ While working in gdb/infrun.c:restart_threads, I was wondering what are
+ the preconditions to call the function. It seems to me that
+ !step_over_info_valid_p should be a precondition (i.e. if we are doing
+ an inline step over breakpoint, we do not want to resume non stepping
+ threads as one of them might miss the breakpoint which is temporally
+ disabled).
+
+ To convince myself that this is true, I have added an assertion to
+ enforce this, and got one regression in the testsuite:
+
+ FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error)
+
+ This call to restart_threads originates from handle_vfork_done which
+ does not check if a step over is active when restarting other threads:
+
+ if (target_is_non_stop_p ())
+ {
+ scoped_restore_current_thread restore_thread;
+
+ insert_breakpoints ();
+ restart_threads (event_thread, event_thread->inf);
+ start_step_over ();
+ }
+
+ In this patch, I propose to:
+ - Call start_step_over before restart_threads. If a step over is already
+ in progress (as it is the case in the failing testcase),
+ start_step_over return immediately, and there is no point in restarting
+ all threads just to stop them right away for a step over breakpoint.
+ - Only call restart_threads if no step over is in progress at this
+ point.
+
+ In this patch, I also propose to keep the assertion in restart_threads
+ to help enforce this precondition, and state it explicitly.
+
+ I have also checked all other places which call restart_threads, and
+ they all seem to check that there is no step over currently active
+ before doing the call.
+
+ As for infrun-related things, I am never completely sure I did not miss
+ something. So as usual, all feedback and thoughts are very welcome.
+
+ Tested on x86_64-linux-gnu.
+
+ Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37
+
+2022-04-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move setbuf calls out of gdb_readline_no_editing_callback
+ After this commit:
+
+ commit d08cbc5d3203118da5583296e49273cf82378042
+ Date: Wed Dec 22 12:57:44 2021 +0000
+
+ gdb: unbuffer all input streams when not using readline
+
+ Issues were reported with some MS-Windows hosts, see the thread
+ starting here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html
+
+ Filed in bugzilla as: PR mi/29002
+
+ The problem seems to be that calling setbuf on terminal file handles
+ is not always acceptable, see this mail for more details:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html
+
+ This commit does two things, first moving the setbuf calls out of
+ gdb_readline_no_editing_callback so that we don't end up calling
+ setbuf so often.
+
+ Then, for MS-Windows hosts, we don't call setbuf for terminals, this
+ appears to resolve the issues that have been reported.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
+
+2022-04-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: handle_no_resumed: only update thread list of event target
+ When running:
+
+ $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+
+ I get:
+
+ target remote localhost:2347^M
+ Remote debugging using localhost:2347^M
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
+ Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M
+ 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
+ (gdb) continue^M
+ Continuing.^M
+ Cannot execute this command while the target is running.^M
+ Use the "interrupt" command to stop the target^M
+ and then try again.^M
+ (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started
+
+ The test does:
+
+ - Connect to a remote target with inferior 2, continue and stop on the
+ all_started function
+ - Connect to a separate remote target / GDBserver instance with inferior 1,
+ continue and (expect to) stop on the all_started function
+
+ The failure seen above happens when trying to continue inferior 1.
+
+ What happens is:
+
+ - GDB tells inferior 1's remote target to continue
+ - We go into fetch_inferior_event, try to get an event at random from
+ the targets
+ - do_target_wait happens to pick inferior 2's target
+ - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense:
+ inferior 2 is stopped, that target has no resumed thread
+ - handle_no_resumed tries to update the thread list of all targets:
+
+ for (auto *target : all_non_exited_process_targets ())
+ {
+ switch_to_target_no_thread (target);
+ update_thread_list ();
+ }
+
+ - When trying to update the thread list of inferior 1's target, it hits
+ the "Cannot execute this command while the target is running" error.
+ This target is working in "remote all-stop" mode, and it is currently
+ waiting for a stop reply, so it can't send packets to update the
+ thread list at this time.
+
+ To handle the problem described in the comment in handle_no_resumed, I
+ don't think it is necessary to update the thread list of all targets,
+ but only the event target. That comment describes a kind of race
+ condition where some target reports a breakpoint hit for a thread and
+ then its last remaining resumed thread exits, so sends a "no resumed"
+ event. If we ended up resuming the thread that hit a breakpoint, we
+ want to ignore the "no resumed" and carry on.
+
+ But I don't really see why we need to update the thread list on the
+ other targets. I can't really articulate this, it's more a gut feeling,
+ maybe I just fail to imagine the situation where this is needed. But
+ here is the patch anyway, so we can discuss it. The patch changes
+ handle_no_resumed to only update the thread list of the event target.
+ This fixes the test run shown above.
+
+ The way I originally tried to fix this was to make
+ remote_target::update_thread_list return early if the target is
+ currently awaiting a stop reply, since there's no way it can update the
+ thread list at that time. But that felt more like papering over the
+ problem. I then thought that we probably shouldn't be asking the target
+ to update the thread list unnecessarily.
+
+ Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58
+
+2022-04-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver/linux: free process_info_private and arch_process_info when failing to attach
+ Running
+
+ $ ../gdbserver/gdbserver --once --attach :1234 539436
+
+ with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents
+ attaching) shows that we fail to free some platform-specific objects
+ tied to the process_info (process_info_private and arch_process_info):
+
+ Direct leak of 32 byte(s) in 1 object(s) allocated from:
+ #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+ #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
+ #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
+ #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426
+ #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
+ #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
+ #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
+ #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
+ #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)
+
+ Indirect leak of 56 byte(s) in 1 object(s) allocated from:
+ #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+ #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
+ #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
+ #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723
+ #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428
+ #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
+ #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
+ #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
+ #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
+ #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)
+
+ Those objects are deleted by linux_process_target::mourn, but that is
+ not called if we fail to attach, we only call remove_process. I
+ initially fixed this by making linux_process_target::attach call
+ linux_process_target::mourn on failure (before calling error). But this
+ isn't done anywhere else (including in GDB) so it would just be
+ confusing to do things differently here.
+
+ Instead, add a linux_process_target::remove_linux_process helper method
+ (which calls remove_process), and call that instead of remove_process in
+ the Linux target. Move the free-ing of the extra data from the mourn
+ method to that new method.
+
+ Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85
+
+2022-04-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle bracketed-paste-mode and EOF correctly
+ This commit replaces an earlier commit that worked around the issues
+ reported in bug PR gdb/28833.
+
+ The previous commit just implemented a work around in order to avoid
+ the worst results of the bug, but was not a complete solution. The
+ full solution was considered too risky to merge close to branching GDB
+ 12. This improved fix has been applied after GDB 12 branched. See
+ this thread for more details:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
+
+ This commit replaces this earlier commit:
+
+ commit 74a159a420d4b466cc81061c16d444568e36740c
+ Date: Fri Mar 11 14:44:03 2022 +0000
+
+ gdb: work around prompt corruption caused by bracketed-paste-mode
+
+ Please read that commit for a full description of the bug, and why is
+ occurs.
+
+ In this commit I extend GDB to use readline's rl_deprep_term_function
+ hook to call a new function gdb_rl_deprep_term_function. From this
+ new function we can now print the 'quit' message, this replaces the
+ old printing of 'quit' in command_line_handler. Of course, we only
+ print 'quit' in gdb_rl_deprep_term_function when we are handling EOF,
+ but thanks to the previous commit (to readline) we now know when this
+ is.
+
+ There are two aspects of this commit that are worth further
+ discussion, the first is in the new gdb_rl_deprep_term_function
+ function. In here I have used a scoped_restore_tmpl to disable the
+ readline global variable rl_eof_found.
+
+ The reason for this is that, in rl_deprep_terminal, readline will
+ print an extra '\n' character before printing the escape sequence to
+ leave bracketed paste mode. You might then think that in the
+ gdb_rl_deprep_term_function function, we could simply print "quit" and
+ rely on rl_deprep_terminal to print the trailing '\n'. However,
+ rl_deprep_terminal only prints the '\n' when bracketed paste mode is
+ on. If the user has turned this feature off, no '\n' is printed.
+ This means that in gdb_rl_deprep_term_function we need to print
+ "quit" when bracketed paste mode is on, and "quit\n" when bracketed
+ paste mode is off.
+
+ We could absolutely do that, no problem, but given we know how
+ rl_deprep_terminal is implemented, it's easier (I think) to just
+ temporarily clear rl_eof_found, this prevents the '\n' being printed
+ from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can
+ now always print "quit\n" and this works for all cases.
+
+ The second issue that should be discussed is backwards compatibility
+ with older versions of readline. GDB can be built against the system
+ readline, which might be older than the version contained within GDB's
+ tree. If this is the case then the system readline might not contain
+ the fixes needed to support correctly printing the 'quit' string.
+
+ To handle this situation I have retained the existing code in
+ command_line_handler for printing 'quit', however, this code is only
+ used now if the version of readline we are using doesn't not include
+ the required fixes. And so, if a user is using an older version of
+ readline, and they have bracketed paste mode on, then they will see
+ the 'quit' sting printed on the line below the prompt, like this:
+
+ (gdb)
+ quit
+
+ I think this is the best we can do when someone builds GDB against an
+ older version of readline.
+
+ Using a newer version of readline, or the patched version of readline
+ that is in-tree, will now give a result like this in all cases:
+
+ (gdb) quit
+
+ Which is what we want.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22 Andrew Burgess <aburgess@redhat.com>
+
+ readline: back-port changes needed to properly detect EOF
+ This commit is a partial back-port of this upstream readline commit:
+
+ commit 002d31aa5f5929eb32d0e0e2e8b8d35d99e59961
+ Author: Chet Ramey <chet.ramey@case.edu>
+ Date: Thu Mar 3 11:11:47 2022 -0500
+
+ add rl_eof_found to public API; fix pointer aliasing problems \
+ with history-search-backward; fix a display problem with \
+ runs of invisible characters at the end of a physical \
+ screen line
+
+ I have only pulled in the parts of this commit that relate to the new
+ rl_eof_found global, and the RL_STATE_EOF state flag. These changes
+ are needed in order to fix PR cli/28833, and are discussed in this
+ thread to the bug-readline mailing list:
+
+ https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
+
+ The above commit is not yet in any official readline release, but my
+ hope is that now it has been merged into the readline tree it should
+ be safe enough to back port this fix to GDB's tree.
+
+ At some point in the future we will inevitably want to roll forward
+ the version of readline that we maintain in the binutils-gdb
+ repository. When that day comes the changes in this commit can be
+ replaced with the latest upstream readline code, as I have not changed
+ the meaning of this code at all from what is in upstream readline.
+
+ This commit alone does not fix the PR cli/28833 issue, for that see
+ the next commit, which changes GDB itself.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: improved EOF handling when using readline 7
+ In this commit:
+
+ commit a6b413d24ccc5d76179bab866834e11fd6fec294
+ Date: Fri Mar 11 14:44:03 2022 +0000
+
+ gdb: work around prompt corruption caused by bracketed-paste-mode
+
+ a change was made to GDB to work around bug PR gdb/28833. The
+ consequence of this work around is that, when bracketed paste mode is
+ enabled in readline, and GDB is quit by sending EOF, then the output
+ will look like this:
+
+ (gdb)
+ quit
+
+ The ideal output, which is what we get when bracketed paste mode is
+ off, is this:
+
+ (gdb) quit
+
+ The reason we need to make this change is explained in the original
+ commit referenced above. What isn't mentioned in the above commit, is
+ that the change that motivated this work around was only added in
+ readline 8, older versions of readline don't require the change.
+
+ In later commits in this series I will add a fix to GDB's in-tree copy
+ of readline (this fix is back-ported from upstream readline), and then
+ I will change GDB so that, when using the (patched) in-tree readline,
+ we can have the ideal output in all cases.
+
+ However, GDB can be built against the system readline. When this is
+ done, and the system readline is version 8, then we will still have to
+ use the work around (two line) style output.
+
+ But, if GDB is built against the system readline, and the system
+ readline is an older version 7 readline, then there's no reason why we
+ can't have the ideal output, after all, readline 7 doesn't include the
+ change that we need to work around.
+
+ This commit changes GDB so that, when using readline 7 we get the
+ ideal output in all cases. This change is trivial (a simple check
+ against the readline version number) so I think this should be fine to
+ include.
+
+ For testing this commit, you need to configure GDB including the
+ '--with-system-readline' flag, and build GDB on a system that uses
+ readline 7, for example 'Ubuntu 18.04'. Then run the test
+ 'gdb.base/eof-exit.exp', you should expect everything to PASS.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp
+ This test sometimes fail like this:
+
+ info threads^M
+ Id Target Id Frame ^M
+ 11.12 process 2270719 Couldn't get registers: No such process.^M
+ (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left
+ [Inferior 11 (process 2270719) exited normally]^M
+ info inferiors^M
+ Num Description Connection Executable ^M
+ * 1 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
+ 11 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
+ (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited)
+
+ I can get it to fail quite reliably by pinning it to a core:
+
+ $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp"
+
+ The previous attempt at fixing this was:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html
+
+ What we see is part due to a possible unfortunate ordering of events
+ given by the kernel, and what could be considered a bug in GDB.
+
+ The test program makes a number of forks, waits them all, then exits.
+ Most of the time, GDB will get and process the exit event for inferior 1
+ after the exit events of all the children. But this is not guaranteed.
+ After the last child exits and is waited by the parent, the parent can
+ exit quickly, such that GDB collects from the kernel the exit events for
+ the parent and that child at the same time. It then chooses one event
+ at random, which can be the event for the parent. This will result in
+ the parent appearing to exit before its child. There's not much we can
+ do about it, so I think we have to adjust the test to cope.
+
+ After expect has seen the "exited normally" notification for inferior 1,
+ it immediately does an "info thread" that it expects to come back empty.
+ But at this point, GDB might not have processed inferior 11's (the last
+ child) exit event, so it will look like there is still a thread. Of
+ course that thread is dead, we just don't know it yet. But that makes
+ the "no thread" test fail. If the test waited just a bit more for the
+ "exited normally" notification for inferior 11, then the list of threads
+ would be empty.
+
+ So, first change, make the test collect all the "exited normally"
+ notifications for all inferiors before proceeding, that should ensure we
+ see an empty thread list. That would fix the first FAIL above.
+
+ However, we would still have the second FAIL, as we expect inferior 11
+ to not be there, it should have been deleted automatically. Inferior 11
+ is normally deleted when prune_inferiors is called. That is called by
+ normal_stop, which is only called by fetch_inferior_event only if the
+ event thread completed an execution command FSM (thread_fsm). But the
+ FSM for the continue command completed when inferior 1 exited. At that
+ point inferior 11 was not prunable, as it still had a thread. When
+ inferior 11 exits, prune_inferiors is not called.
+
+ I think that can be considered a GDB bug. From the user point of view,
+ there's no reason why in one case inferior 11 would be deleted and not
+ in the other case.
+
+ This patch makes the somewhat naive change to call prune_inferiors in
+ fetch_inferior_event, so that it is called in this case. It is placed
+ at this particular point in the function so that it is called after the
+ user inferior / thread selection is restored. If it was called before
+ that, inferior 11 wouldn't be pruned, because it would still be the
+ current inferior.
+
+ Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272
+
+2022-04-22 Tom Tromey <tromey@adacore.com>
+
+ Un-break the coff-pe-read.c build
+ This fixes a build breakage in my recent coff-pe-read.c change.
+
+ I'm sorry about this. I don't understand how it happened, because I
+ definitely built and tested the series on Windows, and I didn't change
+ it before pushing. Something must have gone wrong on the Windows
+ build, but I don't know what. I'll investigate and and re-test to be
+ sure.
+
+2022-04-22 Tom Tromey <tromey@adacore.com>
+
+ More const use and alloca avoidance in coff-pe-read.c
+ This changes another function in coff-pe-read.c to use 'const' more,
+ and to avoid the use of alloca by instead using std::string.
+
+ Use std::string in coff-pe-read.c
+ coff-pe-read.c uses xsnprintf and alloca, but using std::string is
+ better, and just as easy. In general I think alloca is something to
+ be avoided, and unbounded uses especially so.
+
+ Remove a const-removing cast from coff-pe-read.c
+ coff-pe-read.c casts away const at one spot, but this is easily
+ replaced by calling bfd_get_filename directly in a couple of debugging
+ prints.
+
+ Simplify BFD section iteration in coff-pe-read.c
+ coff-pe-read.c iterates over BFD sections using bfd_map_over_sections,
+ but it's much simpler to use a for-each loop. This allows for the
+ removal of helper functions and types.
+
+2022-04-22 Tom Tromey <tromey@adacore.com>
+
+ Fix method naming bug in new DWARF indexer
+ Pedro pointed out that gdb-add-index is much slower with the new DWARF
+ indexer. He also noticed that, in some cases, the generated
+ .gdb_index would have the wrong fully-qualified name for a method.
+
+ I tracked this down to a bug in the indexer. If a type could have
+ methods but was marked as a declaration, the indexer was ignoring it.
+ However, this meant that the internal map to find the qualified name
+ was not updated for this container.
+
+2022-04-22 Christoph Muellner <cmuellner@gcc.gnu.org>
+
+ RISC-V: Add missing DECLARE_INSNs for Zicbo{m,p,z}
+ The recently added support for the Zicbo{m,p,z} extensions did not
+ include DECLARE_INSN() declarations for the instructions.
+ These declarations are needed by GDB's instruction detection code.
+ This patch adds them.
+
+2022-04-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-21 Carl Love <cel@us.ibm.com>
+
+ Fix for gdb.base/solib-search.exp test.
+ The variable right_lib_flags is not being set correctly to define RIGHT.
+ The value RIGHT is needed to force the address of the library functions
+ lib1_func3 and lib2_func4 to occur at different address in the wrong and
+ right libraries.
+
+ With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur
+ at different addresses the test runs correctly on Powerpc.
+
+ The test needs the lib2 addresses to be different in the right and
+ wrong cases. That is the point of introducing function lib2_spacer
+ with the ifdef RIGHT compiler directive.
+
+ On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the
+ dynamic linker to move the addresses of the library. You can also get
+ the same effect on PowerPC but you must use a value much larger than
+ 8192.
+
+ The key thing is that the test was not properly setting RIGHT to
+ defined to get the lib2_spacer function on Intel and Powerpc.
+
+ Without the patch, we have the Intel backtrace for the bad libraries:
+
+ backtrace
+ #0 break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30
+ #1 0x00007ffff7fae156 in ?? ()
+ #2 0x00007fffffffc150 in ?? ()
+ #3 0x00007ffff7fbb156 in ?? ()
+ #4 0x00007fffffffc160 in ?? ()
+ #5 0x00007ffff7fae146 in ?? ()
+ #6 0x00007fffffffc170 in ?? ()
+ #7 0x00007ffff7fbb146 in ?? ()
+ #8 0x00007fffffffc180 in ?? ()
+ #9 0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+ (gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection)
+
+ The backtrace on Intel with the good libraries is:
+
+ backtrace
+ #0 break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30
+ #1 0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49
+ #2 0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49
+ #3 0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30
+ #4 0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30
+ #5 0x0000555555555156 in main () at /...solib-search.c:23
+ (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
+ PASS: gdb.base/solib-search.exp: backtrace (with right libs)
+
+ In one case the backtrace is correct and the other it
+ is wrong on Intel. This is due to the fact that the ARRAY_SIZE caused
+ the dynamic linker to move the library function addresses around. I
+ believe it has to do with the default size of the data and code
+ sections used by the dynamic linker.
+
+ So without the patch the backtrace on PowerPC looks like:
+
+ backtrace
+ #0 break_here () at /.../solib-search.c:30
+ #1 0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49
+ #2 0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49
+ #3 0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30
+ #4 0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30
+ #5 0x000000001000074c in main () at /.../solib-search.c:23
+
+ for both the good and bad libraries.
+
+ The patch fixes defining RIGHT in solib-search-lib1.c and solib-search-
+ lib2.c. Note, without the patch the lib1_spacer and lib2_spacer
+ functions do not show up in the object dump of the Intel or Powerpc
+ libraries as it should. The patch fixes that by making sure RIGHT gets
+ defined.
+
+ Now with the patch the backtrace for the bad library on PowerPC looks
+ like:
+
+ backtrace
+ #0 break_here () at /.../solib-search.c:30
+ #1 0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so
+ Backtrace stopped: frame did not save the PC
+
+ And the backtrace for the good libraries on PowerPC looks like:
+
+ backtrace
+ #0 break_here () at /.../solib-search.c:30
+ #1 0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49
+ #2 0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49
+ #3 0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30
+ #4 0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30
+ #5 0x000000001000074c in main () at /.../solib-search.c:23
+ (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
+ PASS: gdb.base/solib-search.exp: backtrace (with right libs)
+
+ The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not
+ sufficient to cause the dymanic linker to allocate the libraries at
+ different addresses. I don't claim to understand the specifics of how
+ the dynamic linker works and what the default size is for the data and
+ code sections are. My guess is by default PowerPC allocates a larger
+ data size by default, which is large enough to hold array[8192]. The
+ default size of the data section allocated by the dynamic linker on
+ Intel is not large enough to hold array[8192] thus causing the code
+ section on Intel to have to move when the large array is defined.
+
+ Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause
+ the library addresses to occur at different addresses as the larger
+ data section forces the code section to a different address. That was
+ actually my original fix for the program until I spoke with Doug Evans
+ who originally wrote the test. Doug noticed that RIGHT was not getting
+ defined as he originally intended in the test.
+
+ With the patch to fix the definition of RIGHT, PowerPC has a bad and a
+ good backtrace because the address of lib1_func3 and lib2_func4 both
+ move because lib1_spacer and lib2_spacer are now defined
+ before lib1_func3 and lib2_func4.
+
+ Without the patch, the lib1_spacer and lib2_spacer function doesn't show
+ up in the binary for the correct or incorrect library on Intel or PowerPC.
+ With the patch, RIGHT gets defined as originally intended for the test on
+ both architectures and lib1_spacer and lib2_spacer function show up in the
+ binaries on both architectures changing the other function addresses as
+ intended thus causing the test work as intended on PowerPC.
+
+2022-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf: remove line_header::header_length field
+ This can be a local in dwarf_decode_line_header.
+
+ Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af
+
+2022-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/dwarf: remove line_header::total_length field
+ This doesn' have to be a field, it can simply be a local variable in
+ dwarf_decode_line_header. Name the local variable "unit_length", since
+ that's what the field in called in DWARF 4 and 5. It's always easier to
+ follow the code with the standard on the side when we use the same
+ terminology.
+
+ Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633
+
+2022-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix "set temporary breakpoint" DUPLICATEs
+ Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at
+ expected location") introduced some DUPLICATEs in MI tests using
+ mi_continue_to_line, for example:
+
+ DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint
+
+ These test names were previously differentiated by the location passed
+ to mi_continue_to_line. Since the location can contain a path, that
+ commit removed the location from the test name, in favor of a hardcoded
+ string "set temporary breakpoint", hence removing the differentiator.
+
+ mi_continue_to_line receives a "test" parameter, containing a test
+ name. Add a "with_test_prefix" with that name, so that all tests
+ recorded during mi_continue_to_line have this in their name.
+
+ mi_continue_to_line passes that "test" string to mi_get_stop_line, that
+ is a bit superfluous. mi_get_stop_line only uses that string in case of
+ failures (it doesn't record a pass if everything goes fine). Since it's
+ not crucial, just remove it, and adjust all callers.
+
+ Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate
+ the multiple calls to mi_run_inline_test (which calls
+ mi_continue_to_line).
+
+ Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74
+
+2022-04-21 Tom Tromey <tromey@adacore.com>
+
+ Always use dwarf2_initialize_objfile
+ Internally we noticed that some tests would fail like so on Windows:
+
+ warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
+
+ Debugging showed that, in fact, a second CU was being created at this
+ offset. We tracked this down to the fact that, while the ELF reader
+ is careful to re-use the per-BFD data, other readers are not, and
+ could re-read the DWARF data multiple times.
+
+ However, since the change to allow an objfile to have multiple "quick
+ symbol" implementations, there's no reason for this approach -- it's
+ safe and easy for all symbol readers to reuse the per-BFD data when
+ reading DWARF.
+
+ This patch implements this idea, simplifying dwarf2_build_psymtabs and
+ making it private, and then switching to dwarf2_initialize_objfile as
+ the sole way to start the DWARF reader.
+
+ Note that, while I think the call to dwarf2_build_frame_info in
+ machoread.c is also obsolete, I haven't attempted to remove it here.
+
+2022-04-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix 'remote show FOO-packet' aliases
+ The following behaviour was observed in GDB:
+
+ (gdb) show remote X-packet
+ Support for the `p' packet is auto-detected, currently unknown.
+
+ Note the message mentions the 'p' packet. This is a regression since
+ this commit:
+
+ commit 8579fd136a614985bd27f20539c7bb7c5a51287d
+ Date: Mon Nov 8 14:58:46 2021 +0000
+
+ gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
+
+ Before this commit the behaviour was:
+
+ (gdb) show remote X-packet
+ Support for the `X' packet is auto-detected, currently unknown.
+
+ The problem was caused by a failed attempt to ensure that some
+ allocated strings were deleted when GDB exits. The code in the above
+ commit attempted to make use of 'static' to solve this problem,
+ however, the solution was just wrong.
+
+ In this new commit I instead allocate a static vector into which all
+ the allocated strings are stored, this ensures the strings are
+ released when GDB exits (which makes output from tools like valgrind
+ cleaner), but each string within the vector can be unique, which fixes
+ the regression.
+
+2022-04-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add path_join function
+ In this review [1], Eli pointed out that we should be careful when
+ concatenating file names to avoid duplicated slashes. On Windows, a
+ double slash at the beginning of a file path has a special meaning. So
+ naively concatenating "/" and "foo/bar" would give "//foo/bar", which
+ would not give the desired results. We already have a few spots doing:
+
+ if (first_path ends with a slash)
+ path = first_path + second_path
+ else
+ path = first_path + slash + second_path
+
+ In general, I think it's nice to avoid superfluous slashes in file
+ paths, since they might end up visible to the user and look a bit
+ unprofessional.
+
+ Introduce the path_join function that can be used to join multiple path
+ components together (along with unit tests).
+
+ I initially wanted to make it possible to join two absolute paths, to
+ support the use case of prepending a sysroot path to a target file path,
+ or the prepending the debug-file-directory to a target file path. But
+ the code in solib_find_1 shows that it is more complex than this anyway
+ (for example, when the right hand side is a Windows path with a drive
+ letter). So I don't think we need to support that case in path_join.
+ That also keeps the implementation simpler.
+
+ Change a few spots to use path_join to show how it can be used. I
+ believe that all the spots I changed are guarded by some checks that
+ ensure the right hand side operand is not an absolute path.
+
+ Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also
+ ran the new unit-test there.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html
+
+ Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
+
+2022-04-21 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb_spawn_attach_cmdline: use unsupported instead of untested
+ In a previous commit (b750766ac96: gdb/testsuite: Introduce and use
+ gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB
+ attach to the process because of ptrace restrictions (operation not
+ permitted), the proc issues UNTESTED. This should really be
+ UNSUPPORTED, as it is done in gdb_attach.
+
+ This patch fixes this oversight.
+
+ Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d
+
+2022-04-21 Enze Li <lienze2010@hotmail.com>
+
+ gdb/testsuite: add binary testcases to py-format-string.exp
+ We currently only test decimal and hexadecimal for the
+ gdb.Value.format_string() interface, this patch adds testcases for
+ binary format.
+
+ Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
+
+2022-04-21 Pedro Alves <pedro@palves.net>
+
+ gdb.debuginfod/fetch_src_and_symbols.exp: Fix "notice empty URL" test
+ The gdb_test_multiple pattern for the "notice empty URL" test in
+ gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt.
+ Fix it by using -re -wrap.
+
+ Also, by using "confirm off", the message GDB prints if Debuginfod
+ downloading is available doesn't contain "Enable debuginfod" any
+ longer. E.g.:
+
+ ~~~
+ (gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
+ Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
+
+ This GDB supports auto-downloading debuginfo from the following URLs:
+ <http://localhost:123>
+ Enable debuginfod for this session? (y or [n])
+ ~~~
+
+ ~~~
+ (gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
+ Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
+
+ This GDB supports auto-downloading debuginfo from the following URLs:
+ <http://127.0.0.1:8000>
+ <127.0.0.1:8000>
+ Debuginfod has been disabled.
+ To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
+ (No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols)
+ (gdb)
+ ~~~
+
+ I handled that correctly in the other tests that use test_urls, but
+ had forgotten to update the "notice empty URL" one.
+
+ Change-Id: I00040c83466e1494b3875574eb009c571a1504bf
+
+2022-04-21 Alan Modra <amodra@gmail.com>
+
+ prune .note.GNU-stack warning from testsuite
+ binutils/
+ * testsuite/lib/binutils-common.exp (prune_warnings_extra): Remove
+ .note.GNU-stack warning.
+ (run_dump_test): Call prune_warnings for ld and objcopy output.
+ ld/
+ * testsuite/ld-elf/elf.exp: Disable prune_warnings_extra temporarily
+ around test for absent .note.GNU-stack
+ * testsuite/ld-cris/globsymw2.s,
+ * testsuite/ld-cris/warn3.d: Modify "is not implemented" message
+ to avoid dejagnu prune_warnings.
+
+ ld testsuite xcoff XPASS
+ * testsuite/ld-scripts/defined5.d: Don't xfail xcoff targets.
+
+ Delete unused COFF gas macro
+ * config/obj-coff.h (sy_obj): Don't define.
+ (OBJ_SYMFIELD_TYPE): Revise comments.
+
+2022-04-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-20 Aaron Merey <amerey@redhat.com>
+
+ gdb/debuginfod: Prevent out_of_range exception
+ Trailing whitespace in the string of debuginfod URLs causes an
+ out_of_range exception during the printing of URLs for the first
+ use notice.
+
+ To fix this, stop printing URLs when the substring to be printed
+ consists only of whitespace.
+
+ Also add first use notice testcases.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2022-04-20 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: Introduce and use gdb_spawn_attach_cmdline
+ Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add
+ new gdb_attach to check "attach" command", this commit proposes to
+ introduce the gdb_spawn_attach_cmdline helper and use it in
+ gdb.base/attach.exp.
+
+ This helper starts GDB and adds the "--pid=$PID" argument.
+
+ Also note that both the original and new implementation use
+ gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn.
+ This makes sure that we use $INTERNAL_GDBFLAGS, which by default already
+ contain "-iex \"set height 0\" -iex \"set width 0\"". To avoid
+ repetition of those arguments, gdb_spawn_attach_cmdline does not repeat
+ those arguments.
+
+ To maintain a behavior similat to what gdb.base/attach.exp used to do,
+ gdb_spawn_attach_cmdline keeps the -quiet flag.
+
+ Tested on x86_64-gnu-linux
+
+ Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358
+
+2022-04-20 Tom Tromey <tom@tromey.com>
+
+ Replace symbol_symtab with symbol::symtab
+ This turns symbol_symtab into a method on symbol. It also replaces
+ symbol_set_symtab with a method.
+
+ Replace symbol_arch with symbol::arch
+ This turns symbol_arch into a method on symbol.
+
+ Replace symbol_objfile with symbol::objfile
+ This turns symbol_objfile into a method on symbol.
+
+ Remove symbol::aclass_index
+ Symbols have an aclass_index method, but this isn't needed, because
+ the aclass index isn't useful outside of the symbol implementation.
+
+ Use array_view for symbol_impls
+ It seemed to me that using array_view for symbol_impls would give a
+ bit more error checking, at least when gdb is built in libstdc++ debug
+ mode.
+
+ Add accessors for symbol's artificial field
+ For a series I'm experimenting with, it was handy to hide a symbol's
+ "artificial" field behind accessors. This patch is the result.
+
+ Unify the DWARF index holders
+ The dwarf2_per_bfd object has a separate field for each possible kind
+ of index. Until an earlier patch in this series, two of these were
+ even derived from a common base class, but still had separate slots.
+ This patch unifies all the index fields using the common base class
+ that was introduced earlier in this series. This makes it more
+ obvious that only a single index can be active at a time, and also
+ removes some code from dwarf2_initialize_objfile.
+
+ Add an ad hoc version check to dwarf_scanner_base
+ Some generic code in the DWARF reader has a special case for older
+ versions of .gdb_index. This patch adds an ad hoc version check
+ method so that these spots can work without specific knowledge of
+ which index is in use.
+
+ Simplify version check in dw2_symtab_iter_next
+ This simplifies the index versio check in dw2_symtab_iter_next, by
+ passing a reference to the index object to this function. This avoids
+ an indirection via the per_bfd object.
+
+ Introduce and use dwarf_scanner_base
+ This introduces dwarf_scanner_base, a base class for all the index
+ readers in the DWARF code. Then, it changes both mapped_index_base
+ and cooked_index_vector to derive from this new base class.
+
+ Introduce readnow_functions
+ This introduces readnow_functions, a new subclass of
+ dwarf2_base_index_functions, and changes the DWARF reader to use it.
+ This lets us drop the "index is NULL" hack from the gdb index code.
+
+ Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
+ The dwarf2_debug_names_index code treats a NULL debug_names_table as
+ if it were from OBJF_READNOW. However, this trick is only done for
+ gdb_index, never for debug_names -- see dwarf2_initialize_objfile.
+
+ Let mapped index classes create the quick_symbol_functions object
+ This changes the mapped index classes to create the
+ quick_symbol_functions objects. This is a step toward having a more
+ abstract interface to mapped indices.
+
+ Give mapped_index_base a virtual destructor
+ This changes mapped_index_base to have a virtual destructor, so it can
+ be destroyed via its base class.
+
+ Move mapped_index_base to new header file
+ This moves mapped_index_base and the helper struct name_component to a
+ new header file in gdb/dwarf2/.
+
+2022-04-20 Jan Beulich <jbeulich@suse.com>
+
+ x86: reject all invalid SAE variants
+ So far an SAE-only specifier was accepted for static-rounding insns,
+ while SAE-only insns didn't accept static rounding specifiers. If
+ anything it would make sense the other way around, allowing SAE-only
+ insns to have the (ignored) rounding mode specified individually rather
+ than globally via -mevexrcig=. But for now make things match the SDM.
+
+2022-04-20 Alan Modra <amodra@gmail.com>
+
+ Re: xcoff: implement linker relaxation
+ * xcofflink.c (xcoff_stub_csect_name): Increase buffer size.
+ (xcoff_stub_get_csect_in_range, xcoff_build_one_stub): Whitespace.
+ (bfd_xcoff_size_stubs): Cast PRIx64 arg to required type.
+ Don't use freed stub_name.
+
+ Revert "as: Reject unknown -gXXX option" testsuite
+ This reverts the test committed as part of 6ea673e2d6.
+
+2022-04-20 Cl?ment Chigot <clement.chigot@atos.net>
+
+ xcoff: implement linker relaxation
+ bfd/ChangeLog:
+
+ * coff-rs6000.c (xcoff_reloc_type_noop): Add info argument.
+ (xcoff_reloc_type_fail): Likewise.
+ (xcoff_reloc_type_pos): Likewise.
+ (xcoff_reloc_type_neg): Likewise.
+ (xcoff_reloc_type_rel): Likewise.
+ (xcoff_reloc_type_toc): Likewise.
+ (xcoff_reloc_type_ba): Likewise.
+ (xcoff_reloc_type_crel): Likewise.
+ (xcoff_reloc_type_tls): Likewise.
+ (xcoff_reloc_type_br): Add stub handler.
+ (xcoff_ppc_relocate_section): Add info to
+ xcoff_calculate_relocation.
+ (xcoff_stub_indirect_call_code): New constant.
+ (xcoff_stub_shared_call_code): Likewise.
+ (bfd_xcoff_backend_data): Add stub code fields.
+ (bfd_pmac_xcoff_backend_data): Likewise.
+ * coff64-rs6000.c (xcoff64_reloc_type_br): Add stub handler.
+ (xcoff64_ppc_relocate_section): Add info to
+ xcoff64_calculate_relocation.
+ (xcoff64_stub_indirect_call_code): New constant.
+ (xcoff64_stub_shared_call_code): Likewise.
+ (bfd_xcoff_backend_data): Add stub code fields.
+ (bfd_xcoff_aix5_backend_data): Likewise.
+ * libxcoff.h (struct xcoff_backend_data_rec): Add stub fields.
+ (bfd_xcoff_stub_indirect_call_code): New define.
+ (bfd_xcoff_stub_indirect_call_size): New define.
+ (bfd_xcoff_stub_shared_call_code): New define.
+ (bfd_xcoff_stub_shared_call_size): New define.
+ (xcoff_reloc_function): Add info argument.
+ (enum xcoff_stub_type): New enum.
+ (struct xcoff_stub_hash_entry): New structure.
+ * xcofflink.c (struct xcoff_link_hash_table): Add stub hash
+ table and params fields.
+ (xcoff_stub_hash_entry): New define.
+ (xcoff_stub_hash_lookup): New define.
+ (stub_hash_newfunc): New function.
+ (_bfd_xcoff_bfd_link_hash_table_free): Free the new stub hash
+ table.
+ (_bfd_xcoff_bfd_link_hash_table_create): Create the new stub
+ hash table.
+ (xcoff_link_add_symbols): Save rawsize for XTY_SD.
+ (bfd_xcoff_link_init): New function.
+ (xcoff_stub_csect_name): New function.
+ (xcoff_stub_get_csect_in_range): New function.
+ (xcoff_stub_name): New function.
+ (bfd_xcoff_get_stub_entry): New function.
+ (bfd_xcoff_type_of_stub): New function.
+ (xcoff_add_stub): New function.
+ (xcoff_build_one_stub): New function.
+ (bfd_xcoff_size_stubs): New function.
+ (bfd_xcoff_build_stubs): New function.
+ (xcoff_stub_create_relocations): New function.
+ (xcoff_link_input_bfd): Adapt relocations to stub.
+ (xcoff_write_global_symbol): Adapt to new TOC entries generated
+ for stubs.
+ (_bfd_xcoff_bfd_final_link): Handle stub file.
+ * xcofflink.h (struct bfd_xcoff_link_params): New structure.
+
+ ld/ChangeLog:
+
+ * emultempl/aix.em (params): New variable.
+ (stub_file): New variable.
+ (xcoff_add_stub_section): New function.
+ (xcoff_layout_sections_again): New function
+ (hook_in_stub): New function.
+ (_after_allocation): Add stub creation.
+ (_create_output_section_statements): Allocate stub file and
+ pass params to backend.
+
+2022-04-20 Cl?ment Chigot <clement.chigot@atos.net>
+
+ Stubs (added in a later patch) will generate new .loader symbols, once the allocations have been done. Thus, the .loader section cannot be layout before that.
+ bfd/ChangeLog:
+
+ * coff-rs6000.c (_bfd_xcoff_put_ldsymbol_name): Write len in
+ ldinfo->strings instead of directly in the output_bfd.
+ * coff64-rs6000.c (_bfd_xcoff64_put_ldsymbol_name): Likewise.
+ * xcofflink.c (struct xcoff_link_hash_table): Remove ldrel_count
+ field. Add ldinfo field.
+ (xcoff_mark_symbol): Adjust to new ldinfo field.
+ (xcoff_mark): Likewise.
+ (bfd_xcoff_link_count_reloc): Likewise.
+ (xcoff_build_loader_section): Split into two functions: one that
+ build the loader section (this function) and one that only size
+ it...
+ (xcoff_size_loader_section): ... (this function).
+ (bfd_xcoff_size_dynamic_sections): Adapt to new ldinfo field.
+ Move the part where the dynamic sections are build to ...
+ (bfd_xcoff_build_dynamic_sections): ... this function.
+ * xcofflink.h: Add bfd_xcoff_build_dynamic_sections prototype.
+
+ include/ChangeLog:
+
+ * coff/xcoff.h (struct xcoff_loader_info): Add ldrel_count and
+ libpath fields.
+
+ ld/ChangeLog:
+
+ * emultempl/aix.em (_after_allocation): New function.
+
+2022-04-20 Tom Tromey <tom@tromey.com>
+
+ Use symbol_symtab accessor in compile-object-load.c
+ I noticed that compile-object-load.c directly references owner.symtab
+ of a symbol. However, I think it's better for all users to call
+ symbol_symtab. This patch makes this change.
+
+2022-04-20 Nick Clifton <nickc@redhat.com>
+
+ Add linker warning for when it creates an executable stack.
+ PR 29072
+
+2022-04-20 Tom Tromey <tom@tromey.com>
+
+ Micro-optimize cooked_index_entry::full_name
+ I noticed that cooked_index_entry::full_name can return the canonical
+ string when there is no parent entry.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-04-20 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Implement loongarch_scan_prologue()
+ If can't determine prologue from the symbol table, need to examine
+ instructions. Implement loongarch_scan_prologue() to analyze the
+ function prologue from START_PC to LIMIT_PC, return the address of
+ the first instruction past the prologue.
+
+2022-04-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-19 H.J. Lu <hjl.tools@gmail.com>
+
+ as: Reject unknown -gXXX option
+ * as.c (parse_args): Reject unknown -gXXX option.
+ * testsuite/gas/all/empty.s: New file.
+ * testsuite/gas/all/pr29067.d: Likewise.
+ * testsuite/gas/all/pr29067.err: Likewise.
+ * testsuite/gas/all/gas.exp: Run pr29067.
+
+2022-04-19 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazily
+ The register_test_foreach_arch is used to instantiate a given selftest
+ for all architectures supported by GDB. It is used in many _initialize_*
+ functions (under initialize_all_files, called by gdb_init).
+
+ Because the call is done during GDB's initialization, and because there
+ is no guaranty about the order in which all the _initialize_* functions
+ are executed, when register_test_foreach_arch is called, GDB is not
+ fully initialized. Specifically, when a particular initialize function
+ is executed, only the architectures registered at that point are listed
+ by gdbarch_printable_names.
+
+ As a consequence, the list of selftest effectively executed depends on
+ the order the _initialize_* functions are called. This can be observed
+ with the following:
+
+ $ ./gdb/gdb \
+ -data-directory ./gdb/data-directory \
+ -quiet -batch -ex "maint selftest" 2>&1 \
+ | grep -E "Ran [0-9]+ unit tests"
+ Ran 145 unit tests, 0 failed
+ $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
+ -data-directory ./gdb/data-directory \
+ -quiet -batch -ex "maint selftest" 2>&1 \
+ | grep -E "Ran [0-9]+ unit tests"
+ Ran 82 unit tests, 0 failed
+
+ To fix this, make register_test_foreach_arch register a lazy selftest
+ generator. This way when the test generator is eventually executed, all
+ architectures are registered and we do not have a dependency on the
+ order the initialize functions are executed in.
+
+ Tested on x86_64-linux
+
+ Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925
+
+2022-04-19 Lancelot SIX <lancelot.six@amd.com>
+
+ gdbsupport/selftest: Allow lazy registration
+ This patch adds a way to delay the registration of tests until the
+ latest possible moment. This is intended for situations where GDB needs
+ to be fully initialized in order to decide if a particular selftest can
+ be executed or not.
+
+ This mechanism will be used in the next patch.
+
+ Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0
+
+2022-04-19 Lancelot SIX <lancelot.six@amd.com>
+
+ gdbsupport/selftest: Replace for_each_selftest with an iterator_range
+ Remove the callback-based selftests::for_each_selftest function and use
+ an iterator_range instead.
+
+ Also use this iterator range in run_tests so all iterations over the
+ selftests are done in a consistent way. This will become useful in a
+ later commit.
+
+ Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583
+
+2022-04-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't mistake ordinary immediates for SAE / rounding control
+ The way SAE templates are constructed was always puzzling me (including
+ the need for separate templates in the first place), and expressing the
+ extzra attribute via Imm8 actually has a bad effect: Ordinary immediates
+ would also be accepted, leading to an extra byte being added after the
+ instruction (i.e. generating bad code). Before re-working this (in
+ particular to accept proper Intel syntax there), fix the immediate issue
+ by adding the so far missing check.
+
+ x86: VCMPSH is Evex.LLIG
+ These were mistakenly flagged as Evex.128. Getting the LLIG status right
+ for insns allowing for SAE is a prereq for planned further work.
+
+ x86: drop stray CheckRegSize from VFPCLASSPH
+ Like VFPCLASSP{S,D} it has only a single operand allowing multiple
+ sizes, hence there are no pairs of operands to check for consistent
+ size.
+
+ x86/Intel: test non-legacy VCVT{,U}SI2SH insn forms
+ For an unclear reason corresponding AVX512F tests were apparently not
+ cloned or used as reference here, and instead the bogus legacy forms of
+ the insns (with the embedded rounding specifier not last) were used.
+
+2022-04-19 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct and simplify NOP disassembly
+ It's not just REX.W which is ignored with opcode 0x90. The same goes for
+ REX.R and REX.X as well as empty REX. None of these are forms of
+ "xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they
+ also shouldn't be disassembled this way.
+
+ While there simplify things: A single hook function suffices, thus
+ making it unnecessary to keep two expressions in sync. And checking
+ ins->address_mode for mode_64bit also is unnecessary, as "rex" can be
+ non-zero only in that case anyway.
+
+2022-04-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
+ To support DWARF 5 in the DWARF assembler line tables, we currently copy
+ the first user-provided directory and the first user-provided files and
+ make them elements at indices 0 in the directory and file name tables.
+ That was a sufficient behavior at the time (see commit 44fda089397a
+ ("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
+ the following patches, I would need to have finer grained control on
+ what is generated exactly. For example, I'd like to generate a DWARF 5 line
+ table with just a single file and a single directory.
+
+ Get rid of this behavior, and implement what is suggested in
+ 44fda089397a: make include_dir return the directory index that can be
+ used to refer to that directory entry (based on the DWARF version), and
+ use it afterwards.
+
+ Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced
+ DWARF5 binaries will change a bit, in that they will now have a single
+ directory and file, where they had two before. But it doesn't change
+ the expected GDB behavior.
+
+ Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
+
+2022-04-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search
+ Since this is the latest use of gdb_tilde_expand_up, remove it.
+
+ Change-Id: I964c812ce55fe087876abf91e7a3577ad79c0425
+
+2022-04-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: make gdb_realpath_keepfile return an std::string
+ I'm trying to switch these functions to use std::string instead of char
+ arrays, as much as possible. Some callers benefit from it (can avoid
+ doing a copy of the result), while others suffer (have to make one more
+ copy).
+
+ Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc
+
+2022-04-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: make gdb_abspath return an std::string
+ I'm trying to switch these functions to use std::string instead of char
+ arrays, as much as possible. Some callers benefit from it (can avoid
+ doing a copy of the result), while others suffer (have to make one more
+ copy).
+
+ Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
+
+2022-04-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: call gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search
+ This removes a use of gdb_tilde_expand_up, which is removed later in
+ this series.
+
+ Change-Id: I5887d526cea987103e4ca24514a982b0a28e992a
+
+2022-04-18 Tom Tromey <tromey@adacore.com>
+
+ Update gnulib
+ This updates gnulib to a relatively recent commit. Most of this was
+ done by the gnulib import script; the only change I made was to
+ update-gnulib.sh.
+
+ Tested on x86-64 Fedora 34. I also did a mingw cross build.
+
+2022-04-18 Tom Tromey <tom@tromey.com>
+
+ Fix C++ cast of derived class to base class
+ PR c++/28907 points out that casting from a derived class to a base
+ class fails in some situations. The problem turned out to be a
+ missing use of value_embedded_offset. One peculiarity here is that,
+ if you managed to construct a pointer-to-derived with an embedded
+ offset of 0, the cast would work -- for example, one of the two new
+ tests here passes without the patch.
+
+ This embedded offset stuff is an endless source of bugs. I wonder if
+ it's possible to get rid of it somehow.
+
+ Regression tested on x86-64 Fedora 34.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28907
+
+2022-04-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location
+ This test attempts to run until the line marked "STOP", which is at
+ prot.adb:34. It first runs until the "main" symbol, then tries to place
+ a breakpoint by line at line 34, without specifying the source file. When looking at the logs:
+
+ -break-insert -t 34^M
+ ^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M
+ ... continues ...
+ *stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/ mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co re="8"^M
+
+ ... we see that the breakpoint is placed in some generated file, not in
+ the test source file as we expect. The problem is that "b main" in Ada
+ does not place a breakpoint on the "Ada main", but on some symbol in a
+ generated source file. So when stopped at the "main" symbol, we are not
+ stopped in the file that contains the STOP marker at line 34.
+
+ The test passes anyway today, so it doesn't seem to matter that we are
+ stopped at an unexpected location. But it starts failing with this
+ patch [1], because b~prot.adb:34 happens to be between two functions, so
+ the breakpoint doesn't resolve.
+
+ Fix this by placing the breakpoint at "$srcfile:$line", which works
+ regardless of what is the current source file.
+
+ However, this ends up introducing a path in the test name. Modify
+ mi_tbreak and mi_continue_to_line to avoid that.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html
+
+ Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75
+
+2022-04-18 Vignesh Balasubramanian <Vignesh.Balasubrmanian@amd.com>
+
+ gdb/testsuite: add text_segment option to gdb_compile
+ LLVM's lld linker doesn't have the "-Ttext-segment" option, but
+ "--image-base" can be used instead.
+
+ To centralize the logic of checking which option is supported, add the
+ text_segment option to gdb_compile. Change tests that are currently
+ using -Ttext-segment to use that new option instead.
+
+ This patch fixes only compilation error, for example:
+
+ Before:
+
+ $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
+ Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
+ gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]
+
+ After:
+
+ $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
+ Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
+ FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
+ FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
+ FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
+ FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
+ FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
+ FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
+ FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
+ FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
+ FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2
+
+ === gdb Summary ===
+
+ # of expected passes 26
+ # of unexpected failures 9
+
+ Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635
+
+2022-04-18 Enze Li <lienze2010@hotmail.com>
+
+ gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
+ The clear command shouldn't delete momentary and internal breakpoints,
+ nor internal breakpoints created via Python's gdb.Breakpoint.
+
+ This patch fixes this issue and adds a testcase.
+
+ Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7161
+
+2022-04-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-16 Tom Tromey <tom@tromey.com>
+
+ Add comments to dwarf2/abbrev-cache.h
+ This patch started when I noticed that the unordered_set include
+ wasn't needed in abbrev-cache.h. (That was probably leftover from
+ some earlier implementation of the class.) Then, I noticed that the
+ class itself was under-commented. This patch fixes both issues.
+
+2022-04-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Return void from gdb_putc
+ I don't think it's very useful to return the character from gdb_putc,
+ so this patch changes it to return void.
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Handle "set height 1"
+ PR cli/17151 points out that "set height 1" has pathological behavior
+ in gdb. What I see is that gdb will endlessly print the pagination
+ prompt. This patch takes a simple and expedient approach to a fix:
+ pretend that the height is really 2.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17151
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Allow word wrapping even when paging is disabled
+ PR cli/20741 points out that when pagination is disabled, this also
+ disabled word wrapping. However, the manual documents that these
+ settings are separate -- if you intend to disable the wrapping, you
+ must use "set width unlimited".
+
+ This patch fixes the bug by letting the pagination-disabled case fall
+ through to the code that also handles word-wrapping.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20741
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Implement value_print for Rust
+ This adds an implementation of the value_print method to Rust. As
+ described in PR rust/22254, this removes a bit of weird-looking output
+ from some "print"s -- because c_value_print is bypassed. I don't have
+ a test for the bug that inspired this patch, because I only know how
+ to reproduce it when using a relatively old Rust compiler. However,
+ the new "cast-printing" code in value_print is required, because
+ omitting this causes some existing tests to fail.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22254
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Reimplement Rust slice printing
+ The current nightly Rust compiler (aka 1.61) added better DWARF
+ representation for unsized types. Fixing this is PR rust/21466; but
+ the code is actually the same as what is required to make slice
+ printing more useful, which is PR rust/23871. This patch implements
+ this. I tested this against various Rust compilers: 1.48, current
+ stable, current beta, and current nightly.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Remove some dead code from the Rust value printer
+ This removes a bit of dead code from the Rust value printer. This
+ code wasn't always dead -- it fixed a real bug, and a test case was
+ added for it. However, once val_print was removed, it became
+ unnecessary.
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Match rustc beta versions
+ The rust_compiler_version proc extracts the Rust compiler version from
+ the "rustc --version" output. For a beta compiler, the output looks
+ like:
+
+ rustc 1.60.0-beta.6 (7bccde197 2022-03-22)
+
+ This patch slightly relaxes the regexp -- removing a space -- so that
+ this can be understood by this proc.
+
+2022-04-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32
+ With test-case gdb.ada/float-bits.exp and native we get:
+ ...
+ (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
+ $9 = 5.0e+25^M
+ (gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
+ ...
+ but with target board unix/-m32 we have instead:
+ ...
+ (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
+ Cannot export value 2596145952482202326224873165792712 as 96-bits \
+ unsigned integer (must be between 0 and 79228162514264337593543950335)^M
+ (gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
+ ...
+
+ Fix this by testing whether 16llf is supported by doing ptype long_long_float
+ which gets us either:
+ ...
+ type = <16-byte float>^M
+ ...
+ or:
+ ...
+ type = <12-byte float>^M
+ ...
+
+ Tested on x86_64-linux with native and unix/-m32.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29041
+
+2022-04-15 Tom Tromey <tom@tromey.com>
+
+ Remove WITH_SIM define
+ Since score-tdep.c was removed, the WITH_SIM define is not used in
+ gdb. This patch removes it.
+
+ Note that re-running autoheader shows a separate change that was
+ missed. I've kept it in this patch to avoid extra work.
+
+2022-04-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.go/methods.exp with check-readmore
+ When running test-case gdb.go/methods.exp with make check we have:
+ ...
+ (gdb) break main.T.Foo^M
+ Function "main.T.Foo" not defined.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
+ ...
+ but with make check-readmore the XFAIL fails to trigger:
+ ...
+ (gdb) break main.T.Foo^M
+ Function "main.T.Foo" not defined.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
+ ...
+
+ This happens because this gdb_test_multiple "maintenance print symbols"
+ regexp:
+ ...
+ -re "\r\n$gdb_prompt $" {
+ ...
+ matches the entire command output.
+
+ Fix this by adding the missing ^ at the regexp start.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29064
+
+2022-04-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-14 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Eliminate prepare_to_access_memory
+ Given:
+
+ - The prepare_to_access_memory machinery was added for non-stop mode.
+
+ - Only Linux supports non-stop.
+
+ - Linux no longer needs the prepare_to_access_memory machinery. In
+ fact, after the previous patch,
+ linux_process_target::prepare_to_access_memory became a nop.
+
+ Thus, prepare_to_access_memory can go away, simplifying core GDBserver
+ code.
+
+ Change-Id: I93ac8bfe66bd61c3d1c4a0e7d419335163120ecf
+
+2022-04-14 Pedro Alves <pedro@palves.net>
+
+ gdbserver/linux: Access memory even if threads are running
+ Similarly to how the native Linux target was changed
+ and subsequently reworked in these commits:
+
+ 05c06f318fd9 Linux: Access memory even if threads are running
+ 8a89ddbda2ec Avoid /proc/pid/mem races (PR 28065)
+
+ ... teach GDBserver to access memory even when the current thread is
+ running, by always accessing memory via /proc/PID/mem.
+
+ The existing comment:
+
+ /* Neither ptrace nor /proc/PID/mem allow accessing memory through a
+ running LWP. */
+
+ ... is incorrect for /proc/PID/mem does allow that.
+
+ Actually, from GDB's perspective, GDBserver could already access
+ memory while threads were running, but at the expense of pausing all
+ threads for the duration of the memory access, via
+ prepare_to_access_memory. This new implementation does not require
+ pausing any thread, thus
+ linux_process_target::prepare_to_access_memory /
+ linux_process_target::done_accessing_memory become nops. A subsequent
+ patch will remove the whole prepare_to_access_memory infrastructure
+ completely.
+
+ The GDBserver linux-low.cc implementation is simpler than GDB's
+ linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
+ children to the process list immediately when the fork/vfork event is
+ seen out of ptrace. I.e., there's no need to keep the file descriptor
+ stored on a side map, we can store it directly in the process
+ structure.
+
+ Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61
+
+2022-04-14 Pedro Alves <pedro@palves.net>
+
+ gdbserver: special case target_write_memory len==0
+ The next patch in this series adds a common helper routine for both
+ memory reads and writes, like this:
+
+ static int
+ proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf,
+ const gdb_byte *writebuf, int len)
+ {
+ gdb_assert ((readbuf == nullptr) != (writebuf == nullptr));
+ ...
+ }
+
+ int
+ linux_process_target::read_memory (CORE_ADDR memaddr,
+ unsigned char *myaddr, int len)
+ {
+ return proc_xfer_memory (memaddr, myaddr, nullptr, len);
+ }
+
+ linux_process_target::write_memory (CORE_ADDR memaddr,
+ const unsigned char *myaddr, int len)
+ {
+ return proc_xfer_memory (memaddr, nullptr, myaddr, len);
+ }
+
+ Surprisingly, the assertion fails. That happens because it can happen
+ that target_write_memory is called with LEN==0, due to this in
+ gdb/remote.c:
+
+ /* Determine whether the remote target supports binary downloading.
+ This is accomplished by sending a no-op memory write of zero length
+ to the target at the specified address. (...) */
+
+ void
+ remote_target::check_binary_download (CORE_ADDR addr)
+ {
+ ...
+ p = rs->buf.data ();
+ *p++ = 'X';
+ p += hexnumstr (p, (ULONGEST) addr);
+ *p++ = ',';
+ p += hexnumstr (p, (ULONGEST) 0);
+ *p++ = ':';
+ *p = '\0';
+
+ In this scenario, in gdbserver's target_write_memory, the "myaddr"
+ argument of the_target->write_memory is passed the data() of a local
+ gdb::byte_vector (which is a specialized std::vector). It's valid for
+ std::vector::data() to return NULL when the vector is empty.
+
+ This commit adds an early return to target_write_memory to avoid
+ target backends having to care about this. For good measure, do the
+ same on the read side, in read_inferior_memory.
+
+ Change-Id: Iac8f04fcf99014c624ef4036bd318ca1771ad491
+
+2022-04-14 Pedro Alves <pedro@palves.net>
+
+ gdbserver/qXfer::threads, prepare_to_access_memory=>target_pause_all
+ handle_qxfer_threads_proper needs to pause all threads even if the
+ target can read memory when threads are running, so use
+ target_pause_all instead, which is what the Linux implementation of
+ prepare_to_access_memory uses. (Only Linux implements this hook.)
+
+ A following patch will make the Linux backend be able to access memory
+ when threads are running, and thus will also make
+ prepare_to_access_memory do nothing, which would cause testsuite
+ regressions without this change.
+
+ Change-Id: I127fec7246b7c45b60dfa7341e781606bf54b5da
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Ignore 0,0 entries in .debug_aranges
+ When running the internal AdaCore test suite against the new DWARF
+ indexer, I found one regression on RISC-V. The test in question uses
+ --gc-sections, and winds up with an entry in the middle of a
+ .debug_aranges that has both address and length of 0. In this
+ scenario, gdb assumes the entries are terminated and then proceeds to
+ reject the section because it reads a subsequent entry as if it were a
+ header.
+
+ It seems to me that, because each header describes the size of each
+ .debug_aranges CU, it's better to simply ignore 0,0 entries and simply
+ read to the end. That is what this patch does.
+
+ I've patched an existing test to provide a regression test for this.
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Use GetThreadDescription on Windows
+ Windows 10 introduced SetThreadDescription and GetThreadDescription, a
+ simpler way to set a thread's name. This changes gdb and gdbserver to
+ use this convention when it is available.
+
+ This is part of PR win32/29050.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Set the worker thread name on Windows
+ This patch is a bit different from the rest of the series, in that it
+ is a change to gdb's behavior on the host. It changes gdb's thread
+ pool to try to set the thread name on Windows, if SetThreadDescription
+ is available.
+
+ This is part of PR win32/29050.
+
+ This patch isn't likely to be useful to many people in the short term,
+ because the Windows port of the libstdc++ thread code is not upstream.
+ (AdaCore uses it, and sent it upstream, but it did not land, I don't
+ know why.) However, if that patch does ever go in, or presumably if
+ you build using some other C++ runtime library, then this will be
+ useful.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Implement thread_name for gdbserver
+ This changes gdbserver to implement thread_name method.
+
+ Share handle_ms_vc_exception with gdbserver
+ Currently, gdb's native Windows target implements the exception-based
+ approach for setting thread names, but gdbserver does not. This patch
+ moves handle_ms_vc_exception to the shared nat/windows-nat.c code, as
+ preparation for adding this support to gdbserver.
+
+ Move target_read_string to target/target.c
+ This moves the two overloads of target_read_string to a new file,
+ target/target.c, and updates both gdb and gdbserver to build this.
+
+ Remove the byte order parameter to target_read_string
+ target_read_string takes a byte order parameter, but only uses this to
+ check whether a given character is zero. This is readily done without
+ requiring the parameter, so remove it.
+
+ Rename read_string
+ This renames read_string to be an overload of target_read_string.
+ This makes it more consistent for the eventual merger with gdbserver.
+
+ Don't call QUIT in read_string
+ read_string does not need to call QUIT, because target_read_memory
+ already does. This change is needed to make string-reading usable by
+ gdbserver.
+
+ Fix possible Cygwin build problem
+ I noticed that nat/windows-nat.c checks __USEWIDE, but nothing sets it
+ there -- I forgot to copy over the definition when making this file.
+ This patch tries to fix the problem. I don't have a Cygwin setup, so
+ I don't know whether this is sufficient, but it's probably necessary.
+
+2022-04-14 Lancelot SIX <lancelot.six@amd.com>
+ Pedro Alves <pedro@palves.net>
+
+ gdb/testsuite: Fix race in gdb.dwarf2/calling-convention.exp
+ Pedro Alves warned me that there is a race in
+ gdb.dwarf2/calling-convention.exp making the test sometimes fail on his
+ setup. This can be reliably reproduced using :
+
+ make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
+
+ The relevant part of the gdb.log file is:
+
+ return 35
+ Function 'foo' does not follow the target calling convention.
+ If you continue, setting the return value will probably lead to unpredictable behaviors.
+ Make foo return now? (y or n) PASS: gdb.dwarf2/calling-convention.exp: return 35
+ n
+ Not confirmed
+ (gdb) FAIL: gdb.dwarf2/calling-convention.exp: finish
+
+ The issue is that when doing the test for "return 35", the DejaGnu test
+ sends "n" (to tell GDB not to perform the return action) but never
+ consumes the "Not confirmed" acknowledgment sent by GDB. Later, when
+ trying to do the next test, DejaGnu tries to match the leftover output
+ from the "return" test. As this output is not expected, the test fails.
+
+ Fix by using gdb_test to send the "n" answer and match the confirmation
+ and consume all output to the prompt.
+
+ Also do minor adjustments to the main regex:
+ - Remove the leading ".*" which is not required.
+ - Ensure that the "?" from the question is properly escaped.
+
+ Tested on x86_64-gnu-linux, using
+
+ - make check TESTS="gdb.dwarf2/calling-convention.exp"
+ - make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
+ - make check-readmore TESTS="gdb.dwarf2/calling-convention.exp"
+
+ Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Silence -Wmaybe-uninitialized warning from target_waitstatus
+ Currently, one use of target_waitstatus yields a warning:
+
+ target/waitstatus.h: In function 'void stop_all_threads()':
+ target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized]
+ 175 | m_value = other.m_value;
+ | ~~~~~~~~^~~~~~~~~~~~~~~
+
+ This patch silences the warning. I tried the "volatile member"
+ approach that was used for gdb::optional, but that didn't work, so
+ this patch simply initializes the member.
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Fix regression on Windows with WOW64
+ Internally at AdaCore, we recently started testing a 64-bit gdb
+ debugging 32-bit processes. This failed with gdb head, but not with
+ gdb 11.
+
+ The tests fail like this:
+
+ Starting program: [...].exe
+ warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
+ Do you need "set solib-search-path" or "set sysroot"?
+ warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
+ Do you need "set solib-search-path" or "set sysroot"?
+ warning: Could not load shared library symbols for NOT_AN_IMAGE.
+ Do you need "set solib-search-path" or "set sysroot"?
+ warning: Could not load shared library symbols for NOT_AN_IMAGE.
+ Do you need "set solib-search-path" or "set sysroot"?
+
+ After some debugging and bisecting, to my surprise the bug was
+ introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus
+ safe").
+
+ The problem occurs in handle_exception. Previously the code did:
+
+ - ourstatus->kind = TARGET_WAITKIND_STOPPED;
+ [...]
+ case EXCEPTION_BREAKPOINT:
+ [...]
+ - ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
+ [...]
+ /* FALLTHROUGH */
+ case STATUS_WX86_BREAKPOINT:
+ DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
+ - ourstatus->value.sig = GDB_SIGNAL_TRAP;
+ [...]
+ - last_sig = ourstatus->value.sig;
+
+ However, in the new code, the fallthrough case does:
+
+ + ourstatus->set_stopped (GDB_SIGNAL_TRAP);
+
+ ... which changes the 'kind' in 'ourstatus' after falling through.
+
+ This patch rearranges the 'last_sig' setting to more closely match
+ what was done before (this is probably not strictly needed but also
+ seemed harmless), and removes the fall-through in the
+ 'ignore_first_breakpoint' case when __x86_64__ is defined.
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Reorganize Python events documentation
+ This slightly reorganizes the Python events documentation. It hoists
+ the "ThreadEvent" text out of the list of events, where it seemed to
+ be misplaced. It tidies the formatting a little bit (adding some
+ vertical space for easier reading in info), fixes a typo, adds some
+ missing commas, and fixes an incorrect reference to NewInferiorEvent.
+
+2022-04-14 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove move constructor and move assignment operator from cooked_index
+ Building with clang++-14, I see:
+
+ CXX dwarf2/cooked-index.o
+ In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21:
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:172:12: error: explicitly defaulted move constructor is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
+ explicit cooked_index (cooked_index &&other) = default;
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move constructor of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move constructor
+ auto_obstack m_storage;
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:28: note: 'auto_obstack' has been explicitly marked deleted here
+ DISABLE_COPY_AND_ASSIGN (auto_obstack);
+ ^
+ In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21:
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:174:17: error: explicitly defaulted move assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
+ cooked_index &operator= (cooked_index &&other) = default;
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move assignment operator of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move assignment operator
+ auto_obstack m_storage;
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:3: note: 'operator=' has been explicitly marked deleted here
+ DISABLE_COPY_AND_ASSIGN (auto_obstack);
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/../include/ansidecl.h:425:8: note: expanded from macro 'DISABLE_COPY_AND_ASSIGN'
+ void operator= (const TYPE &) = delete
+ ^
+
+ We explicitly make cooked_index have a default move constructor and
+ move assignment operator. But it doesn't actually happen because
+ cooked_index has a field of type auto_obstack, which isn't movable.
+ We don't actually need cooked_index to be movable at the moment, so
+ remove those lines.
+
+ Change-Id: Ifc1fe3d7d67e3ae1a14363d6c1869936fe80b0a2
+
+2022-04-14 Tom Tromey <tromey@adacore.com>
+
+ Let std::thread check pass even without pthreads
+ Currently, the configure check for std::thread relies on pthreads
+ existing. However, this means that if std::thread is implemented for
+ a non-pthreads host, then the check will yield the wrong answer. This
+ happened in AdaCore internal builds. Here, we have this GCC patch:
+
+ https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html
+
+ ... which adds mingw support to GCC's gthreads implementation, and
+ also to std::thread.
+
+ This configure change fixes this problem and enables threading for
+ gdb.
+
+2022-04-14 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: fix build errors in gdbsupport/thread-pool.h used with old gcc
+ When I build gdb with gcc 8.3, there exist the following build errors,
+ rename the typedef to task_t to fix them.
+
+ CXX thread-pool.o
+ In file included from /home/loongson/gdb.git/gdbsupport/thread-pool.cc:21:
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<void> gdb::thread_pool::post_task(std::function<void()>&&)’:
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:69:44: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local]
+ std::packaged_task<void ()> task (std::move (func));
+ ^~~~
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here
+ typedef std::packaged_task<void ()> task;
+ ^~~~
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<_Res> gdb::thread_pool::post_task(std::function<T()>&&)’:
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:80:41: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local]
+ std::packaged_task<T ()> task (std::move (func));
+ ^~~~
+ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here
+ typedef std::packaged_task<void ()> task;
+ ^~~~
+
+2022-04-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Detect 'No MPX support'
+ On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
+ ...
+ (gdb) run ^M
+ Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib64/libthread_db.so.1".^M
+ No MPX support^M
+ ...
+ and eventually into all sort of fails in this and other mpx test-cases.
+
+ Fix this by detecting the "No MPX support" message in have_mpx.
+
+ Tested on x86_64-linux with target boards unix and unix/-m32.
+
+2022-04-14 Sergei Trofimovich <siarheit@google.com>
+
+ M68K: avoid quadratic slowdlow in label alignment check
+ Before the change tc-m68k maintained a list of seen labels.
+ Alignment check traversed label list to resolve symbol to label.
+ This caused quadratic slowdown as each symbol was checked against
+ each label. Worst affected files are the ones built with debugging
+ enabled as DWARF generates many labels.
+
+ The change embeds auxiliary label information right into symbol using
+ TC_SYMFIELD_TYPE.
+
+ Before the change test from PR 29058 did not finish in 10 minutes. After
+ the change it finishes in 2 seconds.
+
+ gas/ChangeLog:
+
+ PR 29058
+ * config/tc-m68k.h (TC_SYMFIELD_TYPE): define as m68k_tc_sy.
+ * config/tc-m68k.c (m68k_frob_label): Use TC_SYMFIELD_TYPE to
+ store label information.
+
+2022-04-14 caiyinyu <caiyinyu@loongson.cn>
+
+ ld:LoongArch: Fix glibc fail: tst-audit25a/b.
+ bfd/
+
+ * elfnn-loongarch.c: Add new func elf_loongarch64_hash_symbol.
+
+2022-04-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-13 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add ATTRIBUTE_PRINTF to complaint_interceptor::issue_complaint
+ Fix this error when building with clang++-14:
+
+ CXX complaints.o
+ /home/smarchi/src/binutils-gdb/gdb/complaints.c:130:65: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
+ g_complaint_interceptor->m_complaints.insert (string_vprintf (fmt, args));
+ ^~~
+
+ Change-Id: I0ef11f970510eb8638d1651fa0d5eeecd6a9d31a
+
+2022-04-13 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix clang build failure in msymbol_is_mips
+ Building with clang++-14, I see:
+
+ CXX mips-tdep.o
+ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
+ return !(MSYMBOL_TARGET_FLAG_MIPS16 (msym)
+ ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
+ (sym)->target_flag_1 ()
+ ^
+ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: note: cast one or both operands to int to silence this warning
+ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
+ (sym)->target_flag_1 ()
+ ^
+
+ That's since commit e165fcef1e7 ("gdb: remove MSYMBOL_TARGET_FLAG_{1,2}
+ macros"). Fix this by using the boolean || rather than the bitwise |,
+ since the new methods return bool values. No change in behavior
+ expected.
+
+ Change-Id: Ia82664135aa25db64c29c92f5c1141859d345bf7
+
+2022-04-13 Alexander von Gluck IV <kallisti5@unixzen.com>
+
+ binutils: enable PE on 32bit haiku build
+ * config.bfd (x86-haiku): Add i386_pei_vec as a selectable format.
+
+2022-04-13 Pedro Alves <pedro@palves.net>
+
+ Make intrusive_list_node's next/prev private
+ Tromey noticed that intrusive_list_node leaves its data members
+ public, which seems sub-optimal.
+
+ This commit makes intrusive_list_node's data fields private.
+ intrusive_list_iterator, intrusive_list_reverse_iterator, and
+ intrusive_list do need to access the fields, so they are made friends.
+
+ Change-Id: Ia8b306b40344cc218d423c8dfb8355207a612ac5
+
+2022-04-13 Pedro Alves <pedro@palves.net>
+
+ Tidy gdb.base/parse_number.exp
+ Now that Ada is able to parse & print 0xffffffffffffffff (2^64-1) in
+ hex, move it to the else branch like most other languages.
+
+ Change-Id: Ib305f6bb2b6b230a1190ea783b245b865821094c
+
+2022-04-13 Alan Modra <amodra@gmail.com>
+
+ ubsan: member access within null pointer of union
+ Add some nonsense to cover "undefined behaviour".
+
+ * ldlang.c (section_for_dot): Avoid UB.
+
+2022-04-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-12 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in Ada number lexing
+ On irc, Pedro pointed out that Ada couldn't properly handle
+ 0xffffffffffffffff. This used to work, but is a regression due to
+ some patches I wrote in the Ada lexer. This patch fixes the bug.
+
+2022-04-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix "passing NULL to memcpy" UBsan error in dwarf2/cooked-index.c
+ Reading a simple file compiled with :
+
+ $ gcc -DONE=1 -gdwarf-4 -g3 test.c
+ $ gcc --version
+ gcc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
+
+ I get:
+
+ Reading symbols from /tmp/cwd/a.out...
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:332:11: runtime error: null pointer passed as argument 2, which is declared to never be null
+
+ It looks like even if the size is 0 (the size of the `entries` vector is
+ 0), we shouldn't be passing a NULL pointer to memcpy. And
+ `entries.data ()` returns NULL.
+
+ Fix that by using std::vector::insert to insert the items of entries
+ into m_entries. I haven't checked, but it should essentially compile
+ down to a memcpy, since the vector elements are trivially copyiable.
+
+ Change-Id: I75f1c901e9b522e42e89eb5936e2c70d68eb21e5
+
+2022-04-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change subfile::line_vector to an std::vector
+ Change this field to an std::vector to facilitate memory management.
+ Since the linetable_entry array is copied into the symtab resulting from
+ the subfile, it is possible to change it without changing how symtab
+ stores the linetable entries (which would be a much larger change).
+
+ There is a small change in buildsym_compunit::record_line to avoid
+ accessing a now invalid linetable_entry. Before this patch, we keep a
+ pointer to the last linetable entry, pop it from the vector, and then
+ read last->line. It works with the manually-maintained array, but since
+ we now use std::vector::pop_back, I am afraid that it could be flagged
+ as an invalid access by the various static / dynamic analysis tools to
+ access the linetable_entry object after popping it from the vector.
+ Instead, record just the line number in an optional and use it.
+
+ There are substantial changes in xcoffread.c that simplify the code, but
+ I can't test them. I was hesitant to do this change because of that,
+ but I decided to send it anyway. I don't think that an almost dead
+ platform should hold back improving the code in the common parts of GDB.
+
+ The changes in xcoffread.c are:
+
+ - Make arrange_linetable "arrange" the linetable passed as a parameter,
+ instead of returning possibly a new one, possibly the same one.
+ - In the "Process main file's line numbers.", I'm not too sure what
+ happens. We get the lintable from "main_subfile", "arrange" it, but
+ then assign the result to the current subfile, obtained with
+ get_current_subfile. I assume that the current subfile is also the
+ main one, so now I just call arrange_linetable on the main subfile's
+ line table.
+ - Remove that weird "Useless if!!!" FIXME comment. It's been there
+ forever, but the "if" is still there, so I guess the "if" can stay
+ there.
+
+ Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80
+
+2022-04-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use std::vector for temporary linetable_entry array in arrange_linetable
+ Reduce manual memory management and make the code a bit easier to read.
+ This helps me a bit in the following patch.
+
+ I don't have a way to test this, it's best-effort.
+
+ Change-Id: I64af9cd756311deabc6cd95e701dfb21234a40a5
+
+2022-04-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: change subfile::name and buildsym_compunit::m_comp_dir to strings
+ Change subfile::name to be a string, for easier memory management.
+ Change buildsym_compunit::m_comp_dir as well, since we move one in to
+ the other at some point in patch_subfile_names, so it's easier to do
+ both at the same time. There are various NULL checks for both fields
+ currently, replace them with empty checks, I think it ends up
+ equivalent.
+
+ I can't test the change in xcoffread.c, it's best-effort.
+
+ Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016
+
+2022-04-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: allocate subfile with new
+ Allocate struct subfile with new, initialize its fields instead of
+ memset-ing it to 0. Use a unique_ptr for the window after a subfile has
+ been allocated but before it is linked in the buildsym_compunit's list
+ of subfile (and therefore owned by the buildsym_compunit.
+
+ I can't test the change in xcoffread.c, it's best-effort. I couldn't
+ find where subfiles are freed in that file, I assume they were
+ intentionally (or not) leaked.
+
+ Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24
+
+2022-04-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use decltype instead of typeof in dwarf2/read.c
+ When building with -std=c++11, I get:
+
+ CXX dwarf2/read.o
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function ‘void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’:
+ /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before ‘typeof’
+ 7130 | using iter_type = typeof (per_bfd->all_comp_units.begin ());
+ | ^~~~~~
+
+ This is because typeof is a GNU extension. Use C++'s decltype keyword
+ instead.
+
+ Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14
+
+2022-04-12 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: use result_of_t instead of result_of in parallel-for.h
+ When building with -std=c++11, I get:
+
+ In file included from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:134:10: error: ‘result_of_t’ is not a member of ‘std’; did you mean ‘result_of’?
+ 134 | std::result_of_t<RangeFunction (RandomIt, RandomIt)>
+ | ^~~~~~~~~~~
+ | result_of
+
+ This is because result_of_t has been introduced in C++14. Use the
+ equivalent result_of<...>::type instead.
+
+ result_of and result_of_t have been removed in C++20 though, so I think
+ we'll need some patches eventually to make the code use invoke_result
+ instead, depending on the C++ version.
+
+ Change-Id: I4817f361c0ebcdd4b32976898fc368bb302b61b9
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Remove dwarf2_per_cu_data::v
+ Now that the psymtab reader has been removed, the
+ dwarf2_per_cu_data::v union is no longer needed. Instead, we can
+ simply move the members from dwarf2_per_cu_quick_data into
+ dwarf2_per_cu_data and remove the "quick" object entirely.
+
+ Delete DWARF psymtab code
+ This removes the DWARF psymtab reader.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Enable the new DWARF indexer
+ This patch finally enables the new indexer. It is left until this
+ point in the series to avoid any regressions; in particular, it has to
+ come after the changes to the DWARF index writer to avoid this
+ problem.
+
+ However, if you experiment with the series, this patch can be moved
+ anywhere from the patch to wire in the new reader to this point.
+ Moving this patch around is how I got separate numbers for the
+ parallelization and background finalization patches.
+
+ In the ongoing performance example, this reduces the time from the
+ baseline of 1.598869 to 0.903534.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Adapt .debug_names writer to new DWARF scanner
+ This updates the .debug_names writer to work with the new DWARF
+ scanner.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Adapt .gdb_index writer to new DWARF scanner
+ This updates the .gdb_index writer to work with the new DWARF scanner.
+ The .debug_names writer is deferred to another patch, to make review
+ simpler.
+
+ This introduces a small hack to psyms_seen_size, but is
+ inconsequential because this function will be deleted in a subsequent
+ patch.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Genericize addrmap handling in the DWARF index writer
+ This updates the DWARF index writing code to make the addrmap-writing
+ a bit more generic. Now, it can handle multiple maps, and it can work
+ using the maps generated by the new indexer.
+
+ Note that the new addrmap_index_data::using_index field will be
+ deleted in a future patch, when the rest of the DWARF psymtab code is
+ removed.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Change parameters to write_address_map
+ To support the removal of partial symtabs from the DWARF index writer,
+ this makes a small change to have write_address_map accept the address
+ map as a parameter, rather than assuming it always comes from the
+ per-BFD object.
+
+ Change the key type in psym_index_map
+ In order to change the DWARF index writer to avoid partial symtabs,
+ this patch changes the key type in psym_index_map (and renames that
+ type as well). Using the dwarf2_per_cu_data as the key makes it
+ simpler to reuse this code with the new indexer.
+
+ Rename write_psymtabs_to_index
+ We'll be removing all the psymtab code from the DWARF reader. As a
+ preparatory step, this renames write_psymtabs_to_index to avoid the
+ "psymtab" name.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ "Finalize" the DWARF index in the background
+ After scanning the CUs, the DWARF indexer merges all the data into a
+ single vector, canonicalizing C++ names as it proceeds. While not
+ necessarily single-threaded, this process is currently done in just
+ one thread, to keep memory costs lower.
+
+ However, this work is all done without reference to any data outside
+ of the indexes. This patch improves the apparent performance of GDB
+ by moving it to the background. All uses of the index are then made
+ to wait for this process to complete.
+
+ In our ongoing example, this reduces the scanning time on gdb itself
+ to 0.173937 (wall). Recall that before this patch, the time was
+ 0.668923; and psymbol reader does this in 1.598869. That is, at the
+ end of this series, we see about a 10x speedup.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Parallelize DWARF indexing
+ This parallelizes the new DWARF indexer. The indexer's storage was
+ designed so that each storage object and each indexer is fully
+ independent. This setup makes it simple to scan different CUs
+ independently.
+
+ This patch creates a new cooked index storage object per thread, and
+ then scans a subset of all the CUs in each such thread, using gdb's
+ existing thread pool.
+
+ In the ongoing "gdb gdb" example, this patch reduces the wall time
+ down to 0.668923, from 0.903534. (Note that the 0.903534 is the time
+ for the new index -- that is, when the "enable the new index" patch is
+ rebased to before this one. However, in the final series, that patch
+ appears toward the end. Hopefully this isn't too confusing.)
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Pre-read DWARF section data
+ Because BFD is not thread-safe, we need to be sure that any section
+ data that is needed is read before trying to do any DWARF indexing in
+ the background.
+
+ This patch takes a simple approach to this -- it pre-reads the
+ "info"-related sections. This is done for the main file, but also any
+ auxiliary files as well, such as the DWO file.
+
+ This patch could be perhaps enhanced by removing some now-redundant
+ calls to dwarf2_section_info::read.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Introduce thread-safe handling for complaints
+ This introduces a new class that can be used to make the "complaint"
+ code thread-safe. Instantiating the class installs a new handler that
+ collects complaints, and then prints them all when the object is
+ destroyed.
+
+ This approach requires some locks. I couldn't think of a better way
+ to handle this, though, because the I/O system is not thread-safe.
+
+ It seemed to me that only GDB developers are likely to enable
+ complaints, and because the complaint macro handle this case already
+ (before any locks are required), I reasoned that any performance
+ degradation that would result here would be fine.
+
+ As an aside about complaints -- are they useful at all? I just ignore
+ them, myself, since mostly they seem to indicate compiler problems
+ that can't be solved in the GDB world anyway. I'd personally prefer
+ them to be in a separate tool, like a hypothetical 'dwarflint'.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Wire in the new DWARF indexer
+ This wires the new DWARF indexer into the existing reader code. That
+ is, this patch makes the modification necessary to enable the new
+ indexer. It is not actually enabled by this patch -- that will be
+ done later.
+
+ I did a bit of performance testing for this patch and a few others. I
+ copied my built gdb to /tmp, so that each test would be done on the
+ same executable. Then, each time, I did:
+
+ $ ./gdb -nx
+ (gdb) maint time 1
+ (gdb) file /tmp/gdb
+
+ This patch is the baseline and on one machine came in at 1.598869 wall
+ time.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Implement quick_symbol_functions for cooked DWARF index
+ This implements quick_symbol_functions for the cooked DWARF index.
+ This is the code that interfaces between the new index and the rest of
+ gdb. Cooked indexes still aren't created by anything.
+
+ For the most part this is straightforward. It shares some concepts
+ with the existing DWARF indices. However, because names are stored
+ pre-split in the cooked index, name lookup here is necessarily
+ different; see expand_symtabs_matching for the gory details.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ The new DWARF indexer
+ This patch adds the code to index DWARF. This is just the scanner; it
+ reads the DWARF and constructs the index, but nothing calls it yet.
+
+ The indexer is split into two parts: a storage object and an indexer
+ object. This is done to support the parallelization of this code -- a
+ future patch will create a single storage object per thread.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Introduce the new DWARF index class
+ This patch introduces the new DWARF index class. It is called
+ "cooked" to contrast against a "raw" index, which is mapped from disk
+ without extra effort.
+
+ Nothing constructs a cooked index yet. The essential idea here is
+ that index entries are created via the "add" method; then when all the
+ entries have been read, they are "finalize"d -- name canonicalization
+ is performed and the entries are added to a sorted vector.
+
+ Entries use the DWARF name (DW_AT_name) or linkage name, not the full
+ name as is done for partial symbols.
+
+ These two facets -- the short name and the deferred canonicalization
+ -- help improve the performance of this approach. This will become
+ clear in later patches, when parallelization is added.
+
+ Some special code is needed for Ada, because GNAT only emits mangled
+ ("encoded", in the Ada lingo) names, and so we reconstruct the
+ hierarchical structure after the fact. This is also done in the
+ finalization phase.
+
+ One other aspect worth noting is that the way the "main" function is
+ found is different in the new code. Currently gdb will notice
+ DW_AT_main_subprogram, but won't recognize "main" during reading --
+ this is done later, via explicit symbol lookup. This is done
+ differently in the new code so that finalization can be done in the
+ background without then requiring a synchronization to look up the
+ symbol.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Update skip_one_die for new abbrev properties
+ This updates skip_one_die to speed it up in the cases where either
+ sibling_offset or size_if_constant are set.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Statically examine abbrev properties
+ The new DIE scanner works more or less along the lines indicated by
+ the text for the .debug_names section, disregarding the bugs in the
+ specification.
+
+ While working on this, I noticed that whether a DIE is interesting is
+ a static property of the DIE's abbrev. It also turns out that many
+ abbrevs imply a static size for the DIE data, and additionally that
+ for many abbrevs, the sibling offset is stored at a constant offset
+ from the start of the DIE.
+
+ This patch changes the abbrev reader to analyze each abbrev and stash
+ the results on the abbrev. These combine to speed up the new indexer.
+ If the "interesting" flag is false, GDB knows to skip the DIE
+ immediately. If the sibling offset is statically known, skipping can
+ be done without reading any attributes; and in some other cases, the
+ DIE can be skipped using simple arithmetic.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Introduce DWARF abbrev cache
+ The replacement for the DWARF psymbol reader works in a somewhat
+ different way. The current reader reads and stores all the DIEs that
+ might be interesting. Then, if it is missing a DIE, it re-scans the
+ CU and reads them all. This approach is used for both intra- and
+ inter-CU references.
+
+ I instrumented the partial DIE hash to see how frequently it was used:
+
+ [ 0] -> 1538165
+ [ 1] -> 4912
+ [ 2] -> 96102
+ [ 3] -> 175
+ [ 4] -> 244
+
+ That is, most DIEs are never used, and some are looked up twice -- but
+ this is just an artifact of the implementation of
+ partial_die_info::fixup, which may do two lookups.
+
+ Based on this, the new implementation doesn't try to store any DIEs,
+ but instead just re-scans them on demand. In order to do this,
+ though, it is convenient to have a cache of DWARF abbrevs. This way,
+ if a second CU is needed to resolve an inter-CU reference, the abbrevs
+ for that CU need only be computed a single time.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Add "fullname" handling to file_and_directory
+ This changes the file_and_directory object to be able to compute and
+ cache the "fullname" in the same way that is done by other code, like
+ the psymtab reader.
+
+ Specialize std::hash for gdb_exception
+ This adds a std::hash specialization for gdb_exception. This lets us
+ store these objects in a hash table, which is used later in this
+ series to de-duplicate the exception output from multiple threads.
+
+ Return vector of results from parallel_for_each
+ This changes gdb::parallel_for_each to return a vector of the results.
+ However, if the passed-in function returns void, the return type
+ remains 'void'. This functionality is used later, to parallelize the
+ new indexer.
+
+ Add batching parameter to parallel_for_each
+ parallel_for_each currently requires each thread to process at least
+ 10 elements. However, when indexing, it's fine for a thread to handle
+ just a single CU. This patch parameterizes this, and updates the one
+ user.
+
+ Refactor build_type_psymtabs_reader
+ The new DWARF scanner needs to save the entire cutu_reader object, not
+ just parts of it. In order to make this possible, this patch
+ refactors build_type_psymtabs_reader. This change is done separately
+ because it is easy to review in isolation and it helps make the later
+ patches smaller.
+
+ Add new overload of dwarf5_djb_hash
+ This adds a new overload of dwarf5_djb_hash. This is used in
+ subsequent patches.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Add name splitting
+ The new DWARF index code works by keeping names pre-split. That is,
+ rather than storing a symbol name like "a::b::c", the names "a", "b",
+ and "c" will be stored separately.
+
+ This patch introduces some helper code to split a full name into its
+ components.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Let skip_one_die not skip children
+ This patch adds an option to skip_one_die that causes it not to skip
+ child DIEs. This is needed in the new scanner.
+
+ Allow ada_decode not to decode operators
+ The new DWARF scanner records names as they appear in DWARF. However,
+ because Ada is unusual, it also decodes the Ada names to synthesize
+ package components for them. In order for this to work out properly,
+ gdb also needs a mode where ada_decode can be instructed not to decode
+ Ada operator names. That is what this patch implements.
+
+ Refactor dwarf2_get_pc_bounds
+ This changes dwarf2_get_pc_bounds so that it does not directly access
+ a psymtab or psymtabs_addrmap. Instead, both the addrmap and the
+ desired payload are passed as parameters. This makes it suitable to
+ be used by the new indexer.
+
+ Add dwarf2_per_cu_data::addresses_seen
+ This adds a new member to dwarf2_per_cu_data that indicates whether
+ addresses have been seen for this CU. This is then set by the
+ .debug_aranges reader. The idea here is to detect when a CU does not
+ have address information, so that the new indexer will know to do
+ extra scanning in that case.
+
+ Fix latent bug in read_addrmap_from_aranges
+ Tom de Vries found a failure that we tracked down to a latent bug in
+ read_addrmap_from_aranges (previously create_addrmap_from_aranges).
+ The bug is that this code can erroneously reject .debug_aranges when
+ dwz is in use, due to CUs at duplicate offsets. Because aranges can't
+ refer to a CU coming from the dwz file, the fix is to simply skip such
+ CUs in the loop.
+
+ Split create_addrmap_from_aranges
+ This patch splits create_addrmap_from_aranges into a wrapper function
+ and a worker function. The worker function is then used in a later
+ patch.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Allow thread-pool.h to work without threads
+ thread-pool.h requires CXX_STD_THREAD in order to even be included.
+ However, there's no deep reason for this, and during review we found
+ that one patch in the new DWARF indexer series unconditionally
+ requires the thread pool.
+
+ Because the thread pool already allows a task to be run in the calling
+ thread (for example if it is configured to have no threads in the
+ pool), it seemed straightforward to make this code ok to use when host
+ threads aren't available at all.
+
+ This patch implements this idea. I built it on a thread-less host
+ (mingw, before my recent configure patch) and verified that the result
+ builds.
+
+ After the thread-pool change, parallel-for.h no longer needs any
+ CXX_STD_THREAD checks at all, so this patch removes these as well.
+
+2022-04-12 Nick Clifton <nickc@redhat.com>
+
+ Rebase the zlib sources to the 1.2.12 release
+
+2022-04-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/stap-probe.exp with read1
+ When running test-case gdb.base/stap-probe.exp with make target check-read1, I
+ run into this and similar:
+ ...
+ FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
+ info probes stap (timeout)
+ ...
+
+ Fix this by using gdb_test_lines instead of gdb_test.
+
+ Tested on x86_64-linux.
+
+2022-04-12 Tom Tromey <tom@tromey.com>
+
+ Add C++ "save gdb-index" test
+ I found a bug in the new DWARF reader series, related to the handling
+ of enumerator names. This bug caused a crash, so this patch adds a
+ regression test for this particular case. I'm checking this in.
+
+2022-04-12 Tom Tromey <tromey@adacore.com>
+
+ Remove "Ada Settings" node from the manual
+ A while back, I sent a patch to unify the Ada varsize-limit setting
+ with the more generic max-value-size:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html
+
+ However, it turns out I somehow neglected to send part of the patch.
+ Internally, I also removed the "Ada Settings" node from the manual, as
+ it only documents the obsolete setting.
+
+ This patch removes this text.
+
+2022-04-12 Tom Tromey <tromey@adacore.com>
+
+ Require GNAT debug info for some Ada tests
+ A few Ada tests require some debug info in the GNAT runtime. When run
+ without this info, these tests can't pass. This patch changes these
+ tests to detect this situation and stop with "untested".
+
+2022-04-12 Nick Clifton <nickc@redhat.com>
+
+ Stop strip from removing debuglink sections.
+ PR 28992
+ * objcopy.c (is_strip_section_1): Do not delete debuglink sections
+ when stripping debug information.
+
+2022-04-12 Jan Beulich <jbeulich@suse.com>
+
+ gas: new_logical_line{,_flags}() can return "void"
+ With the sole user of the return value gone, convert the return type to
+ void. This in turn allows simplifying another construct, by moving it
+ slightly later in the function.
+
+ gas: drop .appfile and .appline
+ These were used originally to represent "# <line> <file>" constructs
+ inserted by (typically) compilers when pre-processing. Quite some time
+ ago they were replaced by .linefile though. Since the original
+ directives were never documented, we ought to be able to remove support
+ for them. As a result in a number of case function parameter aren't used
+ anymore and can hence be dropped.
+
+2022-04-12 Jan Beulich <jbeulich@suse.com>
+
+ gas: further adjust file/line handling for .macro
+ Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
+ and alike blocks"), while dealing okay with actual assembly source files
+ not using .file/.line and alike outside but not inside of .macro, has
+ undue effects when the logical file/line pair was already overridden:
+ Line numbers would continuously increment while processing the expanded
+ macro, while the goal of the PR gas/16908 workaround is to keep the
+ expansion associated with the line invoking the macro. However, as soon
+ as enough state was overridden _inside_ the macro to cause as_where() to
+ no longer fall back top as_where_physical(), honor this by resuming the
+ bumping of the logical line number.
+
+ Note that from_sb_is_expansion's initializer was 1 for an unknown
+ reason. While renaming the variable and changing its type, also change
+ the initializer to "expanding_none", which would have been "0" in the
+ original code. Originally the initializer value itself wasn't ever used
+ anyway (requiring sb_index != -1), as it necessarily had changed in
+ input_scrub_include_sb() alongside setting sb_index to other than -1.
+
+ Strictly speaking input_scrub_insert_line() perhaps shouldn't use
+ expanding_none, yet none of the other enumerators fit there either. And
+ then strictly speaking that function probably shouldn't exist in the
+ first place. It's used only by tic54x.
+
+2022-04-12 Jan Beulich <jbeulich@suse.com>
+
+ gas: further adjust file/line handling for .irp and alike
+ Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
+ and alike blocks"), while dealing okay with actual assembly source files
+ not using .file/.line and alike outside but not inside of .irp et al,
+ has undue effects when the logical file/line pair was already
+ overridden: Line numbers would continuously increment upon every
+ iteration, thus potentially getting far off. Furthermore it left it to
+ the user to actually insert .file/.line inside such constructs. Note
+ though that before aforementioned change things weren't pretty either:
+ Diagnostics (and debug info) would be associated with the directive
+ terminating the iteration construct, rather than with the actual lines.
+
+ Handle this automatically by simply latching the present line and then
+ re-instating coordinates first thing on every iteration; note that the
+ file can't change from what was previously pushed on the scrubber's
+ state stack, and hence can be taken from there by using a new flavor of
+ .linefile (which is far better memory-footprint-wise than recording the
+ full path in the inserted directive). (This then leaves undisturbed any
+ file/line control occurring in the body of the construct, as these will
+ only be seen and processed afterwards.)
+
+2022-04-12 Jan Beulich <jbeulich@suse.com>
+
+ x86: make {disp16} work similarly to {disp32}
+ In a few places {disp32} was handled specially when really {disp16}
+ wants handling just the same.
+
+2022-04-12 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng doesn't build with gcc 5.5
+ gprofng/ChangeLog
+ 2022-04-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/29026
+ * configure.ac: Check version of bison.
+ * src/Makefile.am (QLParser.yy): Run bison
+ * src/QLParser.yy: Adapted for bison 3.04 or later.
+ * src/DbeSession.cc: make some params const.
+ * src/DbeSession.h: Likewise.
+ * configure: Regenerate.
+ * Makefile.in: Regenerate.
+ * src/Makefile.in: Regenerate.
+ * src/QLParser.tab.cc: Deleted.
+ * src/QLParser.tab.hh: Deleted.
+ * doc/Makefile.in: Regenerate.
+ * gp-display-html/Makefile.in: Regenerate.
+ * libcollector/configure: Regenerate.
+
+2022-04-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-11 John Baldwin <jhb@FreeBSD.org>
+
+ i386-fbsd-nat: Remove two unused variables.
+ Earlier versions of the change in
+ 1285ce8629b37f800bf21731ee7c7a8b1b8d0233 used this variable, but not
+ the final version that landed.
+
+2022-04-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macros
+ Replace with equivalent getter/setter macros.
+
+ Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2
+
+2022-04-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove minimal symbol size macros
+ Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them
+ with equivalent methods.
+
+ Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538
+
+2022-04-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove MSYMBOL_TYPE macro
+ Add a getter and a setter for a minimal symbol's type. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
+
+2022-04-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove symbol value macros
+ Remove all macros related to getting and setting some symbol value:
+
+ #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue
+ #define SYMBOL_VALUE_ADDRESS(symbol) \
+ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \
+ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
+ #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block
+ #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
+ #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain
+ #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue
+ #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
+ #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \
+ #define BMSYMBOL_VALUE_ADDRESS(symbol) \
+ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \
+ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
+ #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
+
+ Replace them with equivalent methods on the appropriate objects.
+
+ Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/doc: add section about Fortran intrinsic functions and types
+ The earlier version of this document had no sections about the
+ available Fortran intrinsic functions or the Fortran builtin types.
+
+ I added two sections 'Fortran intrinsics' and 'Fortran types' to
+ document the available Fortran language features. The subsection
+ 'Fortran Defaults' has been integrated into the Fortran subsection.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran/testsuite: add complex from integers test
+ When working on the files I noted that there was no actual test for a
+ COMPLEX built from two INTEGERS. I added that now for completion.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: rewrite intrinsic handling and add some missing overloads
+ The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept
+ (some only with Fortran 2003) the optional parameter KIND. This
+ parameter determines the kind of the associated return value. So far,
+ implementation of this kind parameter has been missing in GDB.
+ Additionally, the one argument overload for the CMPLX intrinsic function
+ was not yet available.
+
+ This patch adds overloads for all above mentioned functions to the
+ Fortran intrinsics handling in GDB.
+
+ It re-writes the intrinsic function handling section to use the helper
+ methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic.
+ These methods define the action taken when a Fortran intrinsic function
+ is called with a certain amount of arguments (1/2/3). The helper methods
+ fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents
+ to the existing wrap and wrap2 methods.
+
+ After adding more overloads to the intrinsics handling, some of the
+ operation names were no longer accurate. E.g. UNOP_FORTRAN_CEILING
+ has been renamed to FORTRAN_CEILING as it is no longer a purely unary
+ intrinsic function. This patch also introduces intrinsic functions with
+ one, two, or three arguments to the Fortran parser and the
+ UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: rename f77_keywords to f_keywords
+ Rename f77_keywords to f_keywords since some of the introduced keywords
+ in the array are f90 only.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: Change GDB print for fortran default types
+ Currently, when asking GDB to print the type of a Fortran default type
+ such as INTEGER or REAL, GDB will return the default name of that type,
+ e.g. "integer"/"real":
+
+ (gdb) ptype integer
+ type = integer
+ (gdb) ptype real
+ type = real
+
+ For LOGICAL and COMPLEX it would return the actual underlying types
+
+ (gdb) ptype logical
+ type = logical*4
+ (gdb) ptype complex
+ type = complex*4
+
+ Similarly, GDB would print the default integer type for the underlying
+ default type:
+
+ (gdb) ptype integer*4
+ type = integer
+ (gdb) ptype real*4
+ type = real
+ (gdb) ptype logical
+ type = logical*4
+ (gdb) ptype complex*4
+ type = complex*4
+
+ This is inconsistent and a bit confusing. Both options somehow indicate
+ what the internal underlying type for the default type is - but I think
+ the logical/complex version is a bit clearer.
+
+ Consider again:
+
+ (gdb) ptype integer
+ type = integer
+
+ This indicates to a user that the type of "integer" is Fortran's default
+ integer type. Without examining "ptype integer*4" I would expect, that
+ any variable declared integer in the actual code would also fit into a
+ GDB integer. But, since we cannot adapt out internal types to the
+ compiler flags used at compile time of a debugged binary, this might be
+ wrong. Consider debugging Fortran code compiled with GNU and e.g. the
+ "-fdefault-integer-8" flag. In this case the gfortran default integer
+ would be integer*8 while GDB internally still would use a builtin_integer,
+ so an integer of the size of an integer*4 type. On the other hand having
+ GDB print
+
+ (gdb) ptype integer
+ type = integer*4
+
+ makes this clearer. I would still be tempted to fit a variable declared
+ integer in the code into a GDB integer - but at least ptype would
+ directly tell me what is going on. Note, that when debugging a binary
+ compiled with "-fdefault-integer-8" a user will always see the actual
+ underlying type of any variable declared "integer" in the Fortran code.
+ So having the code
+
+ program test
+ integer :: a = 5
+ print *, a ! breakpt
+ end program test
+
+ will, when breaking at breakpt print
+
+ (gdb) ptype var
+ type = integer(kind=4)
+
+ or
+
+ (gdb) ptype var
+ type = integer(kind=8)
+
+ depending on the compiler flag.
+
+ This patch changes the outputs for the REAL and INTEGER default types to
+ actually print the internally used type over the default type name.
+
+ The new behavior for the above examples is:
+
+ (gdb) ptype integer
+ type = integer*4
+ (gdb) ptype integer*4
+ type = integer*4
+
+ Existing testcases have been adapted to reflect the new behavior.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: clean-up Fortran intrinsic types
+ The currently implemented intrinsic type handling for Fortran missed some
+ tokens and their parsing. While still not all Fortran type kinds are
+ implemented this patch at least makes the currently handled types
+ consistent. As an example for what this patch does, consider the
+ intrinsic type INTEGER. GDB implemented the handling of the
+ keywords "integer" and "integer_2" but missed "integer_4" and "integer_8"
+ even though their corresponding internal types were already available as
+ the Fortran builtin types builtin_integer and builtin_integer_s8.
+ Similar problems applied to LOGICAL, REAL, and COMPLEX. This patch adds
+ all missing tokens and their parsing. Whenever a section containing the
+ type handling was touched, it also was reordered to be in a more easy to
+ grasp order. All INTEGER/REAL/LOGICAL/COMPLEX types were grouped
+ together and ordered ascending in their size making a missing one more
+ easy to spot.
+
+ Before this change GDB would print the following when tyring to use the
+ INTEGER keywords:
+
+ (gdb) set language fortran
+ (gdb) ptype integer*1
+ unsupported kind 1 for type integer
+ (gdb) ptype integer_1
+ No symbol table is loaded. Use the "file" command.
+ (gdb) ptype integer*2
+ type = integer*2
+ (gdb) ptype integer_2
+ type = integer*2
+ (gdb) ptype integer*4
+ type = integer
+ (gdb) ptype integer_4
+ No symbol table is loaded. Use the "file" command.
+ (gdb) ptype integer*8
+ type = integer*8
+ (gdb) ptype integer_8
+ No symbol table is loaded. Use the "file" command.
+ (gdb) ptype integer
+ type = integer
+
+ With this patch all keywords are available and the GDB prints:
+
+ (gdb) set language fortran
+ (gdb) ptype integer*1
+ type = integer*1
+ (gdb) ptype integer_1
+ type = integer*1
+ (gdb) ptype integer*2
+ type = integer*2
+ (gdb) ptype integer_2
+ type = integer*2
+ (gdb) ptype integer*4
+ type = integer*4
+ (gdb) ptype integer_4
+ type = integer*4
+ (gdb) ptype integer*8
+ type = integer*8
+ (gdb) ptype integer_8
+ type = integer*8
+ (gdb) ptype integer
+ type = integer
+
+ The described changes have been applied to INTEGER, REAL, COMPLEX,
+ and LOGICAL. Existing testcases have been adapted to reflect the
+ new behavior. Tests for formerly missing types have been added.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: change default logical type to builtin_logical
+ According to the Fortran standard, logical is of the size of a
+ 'single numeric storage unit' (just like real and integer). For
+ gfortran, flang and ifx/ifort this storage unit (or the default
+ logical type) is of size kind 4, actually occupying 4 bytes of
+ storage, and so the default type for logical expressions in
+ Fortran should probably also be Logical*4 and not Logical*2. I
+ adapted GDB's behavior to be in line with
+ gfortran/ifort/ifx/flang.
+
+ gdb/fortran: reformat build_fortran_types in f-lang.c
+ Add a few newlines after the type definitions and remove some
+ unnecessary linebreaks.
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: fix complex type in Fortran builtin types
+ Before this patch things like
+
+ (gdb) ptype complex*8
+ complex*16
+ (gdb) ptype complex*4
+ complex*8
+
+ were possible in GDB, which seems confusing for a user. The reason
+ is a mixup in the implementation of the Fortran COMPLEX type. In
+ Fortran the "*X" after a type would normally (I don't think this
+ is language required) specify the type's size in memory. For the
+ COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang)
+ specify not the size of the whole type but the size of the individual
+ two REALs used to form the COMPLEX. Thus, a COMPLEX*4 will usually
+ consist of two REAL*4s. Internally this type was represented by a
+ builtin_complex_s8 - but here I think the s8 actually meant the raw
+ size of the type. This is confusing and I renamed the types (e.g.
+ builting_complex_s8 became builtin_complex_s4 according to its most
+ common useage) and their printed names to their language equivalent.
+ Additionally, I added the default COMPLEX type "COMPLEX" being the same
+ as a COMPLEX*4 (as is normally the case) and removed the latter. I added
+ a few tests for this new behavior as well.
+
+ The new behavior is
+
+ (gdb) ptype complex*8
+ complex*8
+ (gdb) ptype complex*4
+ complex*4
+
+2022-04-11 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/f-lang: remove hidden ^L characters
+
+ gdb/f-lang: add Integer*1 to Fortran builtin types
+ Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.
+
+2022-04-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/annota1.exp with pie
+ Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more
+ robust") we see this fail with target board unix/-fPIE/-pie:
+ ...
+ FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+ ...
+
+ The problem is that the commit makes the number and order of matched
+ annotations fixed, while between target boards unix and unix/-fPIE/-pie there
+ is a difference:
+ ...
+ \032\032post-prompt
+ Starting program: outputs/gdb.base/annota1/annota1
+
+ +\032\032breakpoints-invalid
+ +
+ \032\032starting
+
+ \032\032frames-invalid
+ ...
+
+ Fix this by optionally matching the additional annotation.
+
+ Tested on x86_64-linux.
+
+2022-04-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp for m32 pie
+ As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
+ target board unix/-m32/-fPIE/-pie, we run into:
+ ...
+ Breakpoint 2, 0x56555540 in bar ()^M
+ (gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
+ continue to breakpoint: foo \(1\)
+ next^M
+ Single stepping until exit from function bar,^M
+ which has no line number information.^M
+ 0x56555587 in main ()^M
+ (gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
+ next to foo (2)
+ ...
+
+ The problem is that the bar breakpoint ends up at an unexpected location
+ because:
+ - the synthetic debug info is incomplete and doesn't provide line info
+ for the prologue part of the function, so consequently gdb uses the i386
+ port prologue skipper to get past the prologue
+ - the i386 port prologue skipper doesn't get past a get_pc_thunk call.
+
+ Work around this in the test-case by breaking on bar_label instead.
+
+ Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
+ unix/-m32/-fPIE/-pie.
+
+2022-04-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-09 Tom Tromey <tom@tromey.com>
+
+ Remove MSYMBOL_VALUE_CHAIN
+ I noticed that MSYMBOL_VALUE_CHAIN is unused, so this patch removes it.
+
+2022-04-09 Alan Modra <amodra@gmail.com>
+
+ Rearrange struct bfd_section a little
+ For better packing on 64-bit hosts.
+
+ * section.c (struct bfd_section): Move next and prev field earlier.
+ Move alignment_power later.
+ (BFD_FAKE_SECTION): Adjust to suit.
+ * bfd-in2.h: Regenerate.
+
+2022-04-09 Alan Modra <amodra@gmail.com>
+
+ Don't run pr27228 test for hppa
+ As the comment says, hppa doesn't support use of BFD_RELOC_* in
+ .reloc directives. Using xfail can result in a spurious XPASS result
+ as BFD_RELOC values change.
+
+ * testsuite/gas/elf/pr27228.d: Change xfail to notarget for hppa.
+
+2022-04-09 Alan Modra <amodra@gmail.com>
+
+ Correct nds32 readelf reloc numbers
+ * readelf.c (is_32bit_abs_reloc, is_16bit_abs_reloc): Comment fixes.
+ (is_none_reloc): Correct nds32 reloc numbers.
+
+2022-04-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-08 Fangrui Song <i@maskray.me>
+
+ gas: Port "copy st_size only if unset" to aarch64 and riscv
+ And disable the new test gas/elf/size.s for alpha which uses its own
+ .set, for hppa*-*-hpux* which does not allow .size before declaration.
+
+2022-04-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: fprintf_styled_func not inizialized for disassembler
+ gprofng/ChangeLog
+ 2022-04-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * libcollector/unwind.c: inizialize fprintf_styled_func.
+ * src/Disasm.cc: Likewise.
+
+2022-04-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: zlib handling
+ gprofng/ChangeLog
+ 2022-04-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * configure.ac: Add AM_ZLIB.
+ * src/Makefile.am: Add $(ZLIBINC) and $(ZLIB).
+ * gprofng/src/DbeSession.h: Likewise.
+ * configure: Regenerate.
+ * Makefile.in: Regenerate.
+ * doc/Makefile.in: Regenerate.
+ * gp-display-html/Makefile.in: Regenerate.
+ * src/Makefile.in: Regenerate.
+
+2022-04-08 Pedro Alves <pedro@palves.net>
+
+ gdb: Avoid undefined shifts, fix Go shifts
+ I noticed that a build of GDB with GCC + --enable-ubsan, testing
+ against GDBserver showed this GDB crash:
+
+ (gdb) PASS: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: advance to trace begin
+ tstart
+ ../../src/gdb/valarith.c:1365:15: runtime error: left shift of 48320975398096333 by 46 places cannot be represented in type 'long int'
+ ERROR: GDB process no longer exists
+ GDB process exited with wait status 269549 exp9 0 1
+ UNRESOLVED: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: start trace experiment
+
+ The problem is that, "0x00abababcdcdcdcd << 46" is an undefined signed
+ left shift, because the result is not representable in the type of the
+ lhs, which is signed. This actually became defined in C++20, and if
+ you compile with "g++ -std=c++20 -Wall", you'll see that GCC no longer
+ warns about it, while it warns if you specify prior language versions.
+
+ While at it, there are a couple other situations that are undefined
+ (and are still undefined in C++20) and result in GDB dying: shifting
+ by a negative ammount, or by >= than the bit size of the promoted lhs.
+ For the latter, GDB shifts using (U)LONGEST internally, so you have to
+ shift by >= 64 bits to see it:
+
+ $ gdb --batch -q -ex "p 1 << -1"
+ ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent -1 is negative
+ $ # gdb exited
+
+ $ gdb --batch -q -ex "p 1 << 64"
+ ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
+ $ # gdb exited
+
+ Also, right shifting a negative value is implementation-defined
+ (before C++20, after which it is defined). For this, I chose to
+ change nothing in GDB other than adding tests, as I don't really know
+ whether we need to do anything. AFAIK, most implementations do an
+ arithmetic right shift, and it may be we don't support any host or
+ target that behaves differently. Plus, this becomes defined in C++20
+ exactly as arithmetic right shift.
+
+ Compilers don't error out on such shifts, at best they warn, so I
+ think GDB should just continue doing the shifts anyhow too.
+
+ Thus:
+
+ - Adjust scalar_binop to avoid the undefined paths, either by adding
+ explicit result paths, or by casting the lhs of the left shift to
+ unsigned, as appropriate.
+
+ For the shifts by a too-large count, I made the result be what you'd
+ get if you split the large count in a series of smaller shifts.
+ Thus:
+
+ Left shift, positive or negative lhs:
+
+ V << 64
+ => V << 16 << 16 << 16 << 16
+ => 0
+
+ Right shift, positive lhs:
+
+ Vpos >> 64
+ => Vpos >> 16 >> 16 >> 16 >> 16
+ => 0
+
+ Right shift, negative lhs:
+
+ Vneg >> 64
+ => Vneg >> 16 >> 16 >> 16 >> 16
+ => -1
+
+ This is actually Go's semantics (the compiler really emits
+ instructions to make it so that you get 0 or -1 if you have a
+ too-large shift). So for that language GDB does the shift and
+ nothing else. For other C-like languages where such a shift is
+ undefined, GDB warns in addition to performing the shift.
+
+ For shift by a negative count, for Go, this is a hard error. For
+ other languages, since their compilers only warn, I made GDB warn
+ too. The semantics I chose (we're free to pick them since this is
+ undefined behavior) is as-if you had shifted by the count cast to
+ unsigned, thus as if you had shifted by a too-large count, thus the
+ same as the previous scenario illustrated above.
+
+ Examples:
+
+ (gdb) set language go
+ (gdb) p 1 << 100
+ $1 = 0
+ (gdb) p -1 << 100
+ $2 = 0
+ (gdb) p 1 >> 100
+ $3 = 0
+ (gdb) p -1 >> 100
+ $4 = -1
+ (gdb) p -2 >> 100
+ $5 = -1
+ (gdb) p 1 << -1
+ left shift count is negative
+
+ (gdb) set language c
+ (gdb) p -2 >> 100
+ warning: right shift count >= width of type
+ $6 = -1
+ (gdb) p -2 << 100
+ warning: left shift count >= width of type
+ $7 = 0
+ (gdb) p 1 << -1
+ warning: left shift count is negative
+ $8 = 0
+ (gdb) p -1 >> -1
+ warning: right shift count is negative
+ $9 = -1
+
+ - The warnings' texts are the same as what GCC prints.
+
+ - Add comprehensive tests in a new gdb.base/bitshift.exp testcase, so
+ that we exercise all these scenarios.
+
+ Change-Id: I8bcd5fa02de3114b7ababc03e65702d86ec8d45d
+
+2022-04-08 Pedro Alves <pedro@palves.net>
+
+ Fix undefined behavior in the Fortran, Go and Pascal number parsers
+ This commit ports these two fixes to the C parser:
+
+ commit ebf13736b42af47c9907b5157c8e80c78dbe00e1
+ CommitDate: Thu Sep 4 21:46:28 2014 +0100
+
+ parse_number("0") reads uninitialized memory
+
+ commit 20562150d8a894bc91657c843ee88c508188e32e
+ CommitDate: Wed Oct 3 15:19:06 2018 -0600
+
+ Avoid undefined behavior in parse_number
+
+ ... to the Fortran, Go, and Fortran number parsers, fixing the same
+ problems there.
+
+ Also add a new testcase that exercises printing 0xffffffffffffffff
+ (max 64-bit) in all languages, which crashes a GDB built with UBsan
+ without the fix.
+
+ I moved get_set_option_choices out of all-architectures.exp.tcl to
+ common code to be able to extract all the supported languages. I did
+ a tweak to it to generalize it a bit -- you now have to pass down the
+ "set" part of the command as well. This is so that the proc can be
+ used with "maintenance set" commands as well in future.
+
+ Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a
+
+2022-04-08 Nick Clifton <nickc@redhat.com>
+
+ Debug info for function in Windows PE binary on wrong instruction
+ PR 29038
+ * coffgen.c (coff_find_nearest_line_with_names): Fix typo
+ retrieving saved bias.
+
+2022-04-08 Simon Marchi <simon.marchi@efficios.com>
+
+ Pass PKG_CONFIG_PATH down from top-level Makefile
+ [Sending to binutils, gdb-patches and gcc-patches, since it touches the
+ top-level Makefile/configure]
+
+ I have my debuginfod library installed in a non-standard location
+ (/opt/debuginfod), which requires me to set
+ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during
+ configure:
+
+ $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure --with-debuginfod
+ $ make
+
+ or
+
+ $ ./configure --with-debuginfod PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
+ $ make
+
+ Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
+ configure. When running make (which runs gdb's and binutils'
+ configure), PKG_CONFIG_PATH is not set, which results in their configure
+ script not finding the library:
+
+ checking for libdebuginfod >= 0.179... no
+ configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable."
+
+ Change the top-level configure/Makefile system to capture the value
+ passed when configuring the top-level and pass it down to
+ subdirectories (similar to CFLAGS, LDFLAGS, etc).
+
+ I don't know much about the top-level build system, so I really don't
+ know if I did this correctly. The changes are:
+
+ - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
+ @PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
+ in config files (i.e. Makefile)
+ - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
+ to @PKG_CONFIG_PATH@
+ - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
+ variables set when running the sub-configures
+
+ I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
+ I don't think it's needed. AFAIU, this defines the flags to pass down
+ when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to
+ be passed down during configure. After that, it's captured in
+ gdb/config.status, so even if a "make" causes a re-configure later
+ (because gdb/configure has changed, for example), the PKG_CONFIG_PATH
+ value will be remembered.
+
+ ChangeLog:
+
+ * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
+ * configure: Re-generate.
+ * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
+ (PKG_CONFIG_PATH): New.
+ * Makefile.in: Re-generate.
+
+ Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
+
+2022-04-08 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: use nopie in gdb.dwarf2/dw2-inline-param.exp
+ I see this failure:
+
+ (gdb) run ^M
+ Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
+ Warning:^M
+ Cannot insert breakpoint 1.^M
+ Cannot access memory at address 0x113b^M
+ ^M
+ (gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b
+
+ The test loads the binary in GDB, grabs the address of a symbol, strips
+ the binary, reloads it in GDB, runs the program, and then tries to place
+ a breakpoint at that address. The problem is that the binary is built
+ as position independent, so the address GDB grabs in the first place
+ isn't where the code ends up after running.
+
+ Fix this by linking the binary as non-position-independent. The
+ alternative would be to compute the relocated address where to place the
+ breakpoint, but that's not very straightforward, unfortunately.
+
+ I was confused for a while, I was trying to load the binary in GDB
+ manually to get the symbol address, but GDB was telling me the symbol
+ could not be found. Meanwhile, it clearly worked in gdb.log. The thing
+ is that GDB strips the binary in-place, so we don't have access to the
+ intermediary binary with symbols. Change the test to output the
+ stripped binary to a separate file instead.
+
+ Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba
+
+2022-04-08 Alan Modra <amodra@gmail.com>
+
+ gdb maintainer commit rights
+ Formalise what ought to be obvious. The top level of the binutils-gdb
+ repository isn't owned by binutils.
+
+ * MAINTAINERS: Spelling fix. GDB global maintainer rights.
+
+2022-04-08 Bernhard Heckel <bernhard.heckel@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: print fortran extended types with ptype
+ Add the print of the base-class of an extended type to the output of
+ ptype. This requires the Fortran compiler to emit DW_AT_inheritance
+ for the extended type.
+
+2022-04-08 Bernhard Heckel <bernhard.heckel@intel.com>
+ Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/fortran: add support for accessing fields of extended types
+ Fortran 2003 supports type extension. This patch allows access
+ to inherited members by using their fully qualified name as described
+ in the Fortran standard.
+
+ In doing so the patch also fixes a bug in GDB when trying to access the
+ members of a base class in a derived class via the derived class' base
+ class member.
+
+ This patch fixes PR22497 and PR26373 on GDB side.
+
+ Using the example Fortran program from PR22497
+
+ program mvce
+ implicit none
+
+ type :: my_type
+ integer :: my_int
+ end type my_type
+
+ type, extends(my_type) :: extended_type
+ end type extended_type
+
+ type(my_type) :: foo
+ type(extended_type) :: bar
+
+ foo%my_int = 0
+ bar%my_int = 1
+
+ print*, foo, bar
+
+ end program mvce
+
+ and running this with GDB and setting a BP at 17:
+
+ Before:
+ (gdb) p bar%my_type
+ A syntax error in expression, near `my_type'.
+ (gdb) p bar%my_int
+ There is no member named my_int.
+ (gdb) p bar%my_type%my_int
+ A syntax error in expression, near `my_type%my_int'.
+ (gdb) p bar
+ $1 = ( my_type = ( my_int = 1 ) )
+
+ After:
+ (gdb) p bar%my_type
+ $1 = ( my_int = 1 )
+ (gdb) p bar%my_int
+ $2 = 1 # this line requires DW_TAG_inheritance to work
+ (gdb) p bar%my_type%my_int
+ $3 = 1
+ (gdb) p bar
+ $4 = ( my_type = ( my_int = 1 ) )
+
+ In the above example "p bar%my_int" requires the compiler to emit
+ information about the inheritance relationship between extended_type
+ and my_type which gfortran and flang currently do not de. The
+ respective issue gcc/49475 has been put as kfail.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373
+ https://sourceware.org/bugzilla/show_bug.cgi?id=22497
+
+2022-04-08 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb: add Nils-Christian Kempke to gdb/MAINTAINERS
+
+2022-04-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change file_file_name to return an std::string
+ Straightforward change, return an std::string instead of a
+ gdb::unique_xmalloc_ptr<char>. No behavior change expected.
+
+ Change-Id: Ia5e94c94221c35f978bb1b7bdffbff7209e0520e
+
+2022-04-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/fortran: fix fetching assumed rank array content
+ Commit:
+
+ commit df7a7bdd9766adebc6b117c31bc617d81c1efd43
+ Date: Thu Mar 17 18:56:23 2022 +0000
+
+ gdb: add support for Fortran's ASSUMED RANK arrays
+
+ Added support for Fortran assumed rank arrays. Unfortunately, this
+ commit contained a bug that means though GDB can correctly calculate
+ the rank of an assumed rank array, GDB can't fetch the contents of an
+ assumed rank array.
+
+ The history of this patch can be seen on the mailing list here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-January/185306.html
+
+ The patches that were finally committed can be found here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186906.html
+
+ The original patches did support fetching the array contents, it was
+ only the later series that introduced the regression.
+
+ The problem is that when calculating the array rank the result is a
+ count of the number of ranks, i.e. this is a 1 based result, 1, 2, 3,
+ etc.
+
+ In contrast, when computing the details of any particular rank the
+ value passed to the DWARF expression evaluator should be a 0 based
+ rank offset, i.e. a 0 based number, 0, 1, 2, etc.
+
+ In the patches that were originally merged, this was not the case, and
+ we were passing the 1 based rank number to the expression evaluator,
+ e.g. passing 1 when we should pass 0, 2 when we should pass 1, etc.
+ As a result the DWARF expression evaluator was reading the
+ wrong (undefined) memory, and returning garbage results.
+
+ In this commit I have extended the test case to cover checking the
+ array contents, I've then ensured we make use of the correct rank
+ value, and extended some comments, and added or adjusted some asserts
+ as appropriate.
+
+2022-04-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: add "macros" option to gdb_compile
+ Make gdb_compile handle a new "macros" option, which makes it pass the
+ appropriate flag to make the compiler include macro information in the
+ debug info. This will help simplify tests using macros, reduce
+ redundant code, and make it easier to add support for a new compiler.
+
+ Right now it only handles clang specially (using -fdebug-macro) and
+ falls back to -g3 otherwise (which works for gcc). Other compilers can
+ be added as needed.
+
+ There are some tests that are currently skipped if the compiler is nor
+ gcc nor clang. After this patch, the tests will attempt to run (the -g3
+ fall back will be used). That gives a chance to people using other
+ compilers to notice something is wrong and maybe add support for their
+ compiler. If it is needed to support a compiler that doesn't have a way
+ to include macro information, then we can always introduce a
+ "skip_macro_tests" that can be used to skip over them.
+
+ Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove subfile::buildsym_compunit field
+ It is only set, never used.
+
+ Change-Id: Ia46ed2f9da243b0ccfc4588c1b57be2a0f3939de
+
+2022-04-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make gdb.base/annota1.exp more robust
+ On openSUSE Tumbleweed I run into:
+ ...
+ FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+ ...
+
+ The problem is that the libthread_db message occurs at a location where it's
+ not expected:
+ ...
+ Starting program: outputs/gdb.base/annota1/annota1 ^M
+ ^M
+ ^Z^Zstarting^M
+ ^M
+ ^Z^Zframes-invalid^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib64/libthread_db.so.1".^M
+ ^M
+ ^Z^Zbreakpoints-invalid^M
+ ^M
+ ...
+
+ Fix this by making the matching more robust:
+ - rewrite the regexp such that each annotation is on a single line,
+ starting with \r\n\032\032 and ending with \r\n
+ - add a regexp variable optional_re, that matches all possible optional
+ output, and use it as a separator in the first part of the regexp
+
+ Tested on x86_64-linux.
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/dwarf: simplify line number program syntax
+ By calling `uplevel $body` in the program proc (a pattern we use at many
+ places), we can get rid of curly braces around each line number program
+ directive. That seems like a nice small improvement to me.
+
+ Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/dwarf: remove two unused variables
+ These variables seem to be unused, remove them.
+
+ Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove symtab::pspace
+ Same idea as previous patch, but for symtab::pspace.
+
+ Change-Id: I1023abe622bea75ef648c6a97a01b53775d4104d
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove symtab::objfile
+ Same idea as previous patch, but for symtab::objfile. I find
+ it clearer without this wrapper, as it shows that the objfile is
+ common to all symtabs of a given compunit. Otherwise, you could think
+ that each symtab (of a given compunit) can have a specific objfile.
+
+ Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove symtab::blockvector
+ symtab::blockvector is a wrapper around compunit_symtab::blockvector.
+ It is a bit misleadnig, as it gives the impression that a symtab has a
+ blockvector. Remove it, change all users to fetch the blockvector
+ through the compunit instead.
+
+ Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
+
+2022-04-07 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove symtab::dirname
+ I think the symtab::dirname method is bogus, or at least very
+ misleading. It makes you think that it returns the directory that was
+ used to find that symtab's file during compilation (i.e. the directory
+ the file refers to in the DWARF line header file table), or the
+ directory part of the symtab's filename maybe. In fact, it returns the
+ compilation unit's directory, which is the CWD of the compiler, at
+ compilation time. At least for DWARF, if the symtab's filename is
+ relative, it will be relative to that directory. But if the symtab's
+ filename is absolute, then the directory returned by symtab::dirname has
+ nothing to do with the symtab's filename.
+
+ Remove symtab::dirname to avoid this confusion, change all users to
+ fetch the same information through the compunit. At least, it will be
+ clear that this is a compunit property, not a symtab property.
+
+ Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0
+
+2022-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: make gdb_breakpoint and runto take a linespec
+ Change gdb_breakpoint to accept a linespec, not just a function. In
+ fact, no behavior changes are necessary, this only changes the parameter
+ name and documentation. Change runto as well, since the two are so
+ close (runto forwards all its arguments to gdb_breakpoint).
+
+ I wrote this for a downstrean GDB port, but thought it could be
+ useful upstream, eventually, even though not callers take advantage of
+ it yet.
+
+ Change-Id: I08175fd444d5a60df90fd9985e1b5dfd87c027cc
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: update comments throughout reggroups.{c,h} files
+ This commit updates the comments in the gdb/reggroups.{c,h} files.
+ Fill in some missing comments, correct a few comments that were not
+ clear, and where we had comments duplicated between .c and .h files,
+ update the .c to reference the .h.
+
+ No user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move struct reggroup into reggroups.h header
+ Move 'struct reggroup' into the reggroups.h header. Remove the
+ reggroup_name and reggroup_type accessor functions, and just use the
+ name/type member functions within 'struct reggroup', update all uses
+ of these removed functions.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: convert reggroup to a C++ class with constructor, etc
+ Convert the 'struct reggroup' into a real class, with a constructor
+ and getter methods.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make the pre-defined register groups const
+ Convert the 7 global, pre-defined, register groups const, and fix the
+ fall out (a minor tweak required in riscv-tdep.c).
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: more 'const' in gdb/reggroups.{c,h}
+ Convert the reggroup_new and reggroup_gdbarch_new functions to return
+ a 'const regggroup *', and fix up all the fallout.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove reggroup_next and reggroup_prev
+ Add a new function gdbarch_reggroups that returns a reference to a
+ vector containing all the reggroups for an architecture.
+
+ Make use of this function throughout GDB instead of the existing
+ reggroup_next and reggroup_prev functions.
+
+ Finally, delete the reggroup_next and reggroup_prev functions.
+
+ Most of these changes are pretty straight forward, using range based
+ for loops instead of the old style look using reggroup_next. There
+ are two places where the changes are less straight forward.
+
+ In gdb/python/py-registers.c, the register group iterator needed to
+ change slightly. As the iterator is tightly coupled to the gdbarch, I
+ just fetch the register group vector from the gdbarch when needed, and
+ use an index counter to find the next item from the vector when
+ needed.
+
+ In gdb/tui/tui-regs.c the tui_reg_next and tui_reg_prev functions are
+ just wrappers around reggroup_next and reggroup_prev respectively.
+ I've just inlined the logic of the old functions into the tui
+ functions. As the tui function had its own special twist (wrap around
+ behaviour) I think this is OK.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: convert reggroups to use a std::vector
+ Replace manual linked list with a std::vector. This commit doesn't
+ change the reggroup_next and reggroup_prev API, but that will change
+ in a later commit.
+
+ This commit is focused on the minimal changes needed to manage the
+ reggroups using a std::vector, without changing the API exposed by the
+ reggroup.c file.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: always add the default register groups
+ There's a set of 7 default register groups. If we don't add any
+ gdbarch specific register groups during gdbarch initialisation, then
+ when we iterate over the register groups using reggroup_next and
+ reggroup_prev we will make use of these 7 default groups. See the use
+ of default_groups in gdb/reggroups.c for details on this.
+
+ However, if the gdbarch adds its own groups during gdbarch
+ initialisation, then these groups will be used in preference to the
+ default groups.
+
+ A problem arises though if the particular architecture makes use of
+ the target description mechanism. If the default target
+ description(s) (i.e. those internal to GDB that are used when the user
+ doesn't provide their own) don't mention any additional register
+ groups then the default register groups will be used.
+
+ But if the target description does mention additional groups then the
+ default groups are not used, and instead, the groups from the target
+ description are used.
+
+ The problem with this is that what usually happens is that the target
+ description will mention additional groups, e.g. groups for special
+ registers. Most architectures that use target descriptions work
+ around this by adding all (or most) of the default register groups in
+ all cases. See i386_add_reggroups, aarch64_add_reggroups,
+ riscv_add_reggroups, xtensa_add_reggroups, and others.
+
+ In this patch, my suggestion is that we should just add the default
+ register groups for every architecture, always. This change is in
+ gdb/reggroups.c.
+
+ All the remaining changes are me updating the various architectures to
+ not add the default groups themselves.
+
+ So, where will this change be visible to the user? I think the
+ following commands will possibly change:
+
+ * info registers / info all-registers:
+
+ The user can provide a register group to these commands. For example,
+ on csky, we previously never added the 'vector' group. Now, as a
+ default group, this will be available, but (presumably) will not
+ contain any registers. I don't think this is necessarily a bad
+ thing, there's something to be said for having some consistent
+ defaults available. There are other architectures that didn't add
+ all 7 of the defaults, which will now have gained additional groups.
+
+ * maint print reggroups
+
+ This prints the set of all available groups. As a maintenance
+ command I'm less concerned with the output changing here.
+ Obviously, for the architectures that didn't previously add all the
+ defaults, this list just got bigger.
+
+ * maint print register-groups
+
+ This prints all the registers, and the groups they are in. If the
+ defaults were not previously being added then a register (obviously)
+ can't appear in one of the default groups. Now the groups are
+ available then registers might be in more groups than previously.
+ However, this is again a maintenance command, so I'm less concerned
+ about this changing.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: fix 'tui reg next/prev' command when data window is hidden
+ Start GDB like:
+
+ $ gdb -q executable
+ (gdb) start
+ (gdb) layout src
+ ... tui windows are now displayed ...
+ (gdb) tui reg next
+
+ At this point the data (register) window should be displayed, but will
+ contain the message 'Register Values Unavailable', and at the console
+ you'll see the message "unknown register group 'next'".
+
+ The same happens with 'tui reg prev' (but the error message is
+ slightly different).
+
+ At this point you can continue to use 'tui reg next' and/or 'tui reg
+ prev' and you'll keep getting the error message.
+
+ The problem is that when the data (register) window is first
+ displayed, it's current register group is nullptr. As a consequence
+ tui_reg_next and tui_reg_prev (tui/tui-regs.c) will always just return
+ nullptr, which triggers an error in tui_reg_command.
+
+ In this commit I change tui_reg_next and tui_reg_prev so that they
+ instead return the first and last register group respectively if the
+ current register group is nullptr.
+
+ So, after this, using 'tui reg next' will (in the above case) show the
+ first register group, while 'tui reg prev' will display the last
+ register group.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: avoid theoretical bug with 'tui reg' command
+ While looking at the 'tui reg' command as part of another patch, I
+ spotted a theoretical bug.
+
+ The 'tui reg' command takes the name of a register group, but also
+ handles partial register group matches, though the partial match has to
+ be unique. The current command logic goes:
+
+ With the code as currently written, if a target description named a
+ register group either 'prev' or 'next' then GDB would see this as an
+ ambiguous register name, and refuse to switch groups.
+
+ Naming a register group 'prev' or 'next' seems pretty unlikely, but,
+ by adding a single else block we can prevent this problem.
+
+ Now, if there's a 'prev' or 'next' register group, the user will not
+ be able to select the group directly, the 'prev' and 'next' names will
+ always iterate through the available groups instead. But at least the
+ user could select their groups by iteration, rather than direct
+ selection.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have reggroup_find return a const
+ Update reggroup_find to return a const reggroup *.
+
+ There are other function in gdb/reggroup.{c,h} files that could
+ benefit from returning const, these will be updated in later commits.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use 'const reggroup *' in python/py-registers.c file
+ Convert uses of 'struct reggroup *' in python/py-registers.c to be
+ 'const'.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: switch to using 'const reggroup *' in tui-regs.{c,h}
+ Make uses of 'reggroup *' const throughout tui-regs.{c,h}.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make gdbarch_register_reggroup_p take a const reggroup *
+ Change gdbarch_register_reggroup_p to take a 'const struct reggroup *'
+ argument. This requires a change to the gdb/gdbarch-components.py
+ script, regeneration of gdbarch.{c,h}, and then updates to all the
+ architectures that implement this method.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add some const in gdb/reggroups.c
+ This commit makes the 'struct reggroup *' argument const for the
+ following functions:
+
+ reggroup_next
+ reggroup_prev
+ reggroup_name
+ reggroup_type
+
+ There are other places that could benefit from const in the
+ reggroup.{c,h} files, but these will be changing in further commits.
+
+ There should be no user visible changes after this commit.
+
+2022-04-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't try to use readline before it's initialized
+ While working on a different patch, I triggered an assertion from the
+ initialize_current_architecture code, specifically from one of
+ the *_gdbarch_init functions in a *-tdep.c file. This exposes a
+ couple of issues with GDB.
+
+ This is easy enough to reproduce by adding 'gdb_assert (false)' into a
+ suitable function. For example, I added a line into i386_gdbarch_init
+ and can see the following issue.
+
+ I start GDB and immediately hit the assert, the output is as you'd
+ expect, except for the very last line:
+
+ $ ./gdb/gdb --data-directory ./gdb/data-directory/
+ ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ ... snip ...
+ ---------------------
+ ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n) ../../src.dev-1/gdb/ser-event.c:212:16: runtime error: member access within null pointer of type 'struct serial'
+
+ Something goes wrong when we try to query the user. Note, I
+ configured GDB with --enable-ubsan, I suspect that without this the
+ above "error" would actually just be a crash.
+
+ The backtrace from ser-event.c:212 looks like this:
+
+ (gdb) bt 10
+ #0 serial_event_clear (event=0x675c020) at ../../src/gdb/ser-event.c:212
+ #1 0x0000000000769456 in invoke_async_signal_handlers () at ../../src/gdb/async-event.c:211
+ #2 0x000000000295049b in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:194
+ #3 0x0000000001f015f8 in gdb_readline_wrapper (
+ prompt=0x67135c0 "../../src/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugg"...)
+ at ../../src/gdb/top.c:1141
+ #4 0x0000000002118b64 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) (
+ ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ", defchar=0 '\000', args=0x7fffffffa6e0)
+ at ../../src/gdb/utils.c:934
+ #5 0x0000000002118f72 in query (ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ")
+ at ../../src/gdb/utils.c:1026
+ #6 0x00000000021170f6 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x6107bc0 <internal_error_problem>, file=0x2b976c8 "../../src/gdb/i386-tdep.c",
+ line=8455, fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:417
+ #7 0x00000000021175a0 in internal_verror (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
+ fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:485
+ #8 0x00000000029503b3 in internal_error (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
+ fmt=0x2b96d7f "%s: Assertion `%s' failed.") at ../../src/gdbsupport/errors.cc:55
+ #9 0x000000000122d5b6 in i386_gdbarch_init (info=..., arches=0x0) at ../../src/gdb/i386-tdep.c:8455
+ (More stack frames follow...)
+
+ It turns out that the problem is that the async event handler
+ mechanism has been invoked, but this has not yet been initialized.
+
+ If we look at gdb_init (in gdb/top.c) we can indeed see the call to
+ gdb_init_signals is after the call to initialize_current_architecture.
+
+ If I reorder the calls, moving gdb_init_signals earlier, then the
+ initial error is resolved, however, things are still broken. I now
+ see the same "Quit this debugging session? (y or n)" prompt, but when
+ I provide an answer and press return GDB immediately crashes.
+
+ So what's going on now? The next problem is that the call_readline
+ field within the current_ui structure is not initialized, and this
+ callback is invoked to process the reply I entered.
+
+ The problem is that call_readline is setup as a result of calling
+ set_top_level_interpreter, which is called from captured_main_1.
+ Unfortunately, set_top_level_interpreter is called after gdb_init is
+ called.
+
+ I wondered how to solve this problem for a while, however, I don't
+ know if there's an easy "just reorder some lines" solution here.
+ Looking through captured_main_1 there seems to be a bunch of
+ dependencies between printing various things, parsing config files,
+ and setting up the interpreter. I'm sure there is a solution hiding
+ in there somewhere.... I'm just not sure I want to spend any longer
+ looking for it.
+
+ So.
+
+ I propose a simpler solution, more of a hack/work-around. In utils.c
+ we already have a function filtered_printing_initialized, this is
+ checked in a few places within internal_vproblem. In some of these
+ cases the call gates whether or not GDB will query the user.
+
+ My proposal is to add a new readline_initialized function, which
+ checks if the current_ui has had readline initialized yet. If this is
+ not the case then we should not attempt to query the user.
+
+ After this change GDB prints the error message, the backtrace, and
+ then aborts (including dumping core). This actually seems pretty sane
+ as, if GDB has not yet made it through the initialization then it
+ doesn't make much sense to allow the user to say "no, I don't want to
+ quit the debug session" (I think).
+
+2022-04-07 Luis Machado <luis.machado@arm.com>
+
+ Recognize the NT_ARM_SYSTEM_CALL register set
+ Update binutils to recognize the NT_ARM_SYSTEM_CALL set that is dumped by
+ Linux to core files.
+
+2022-04-07 Mark Harmstone <mark@harmstone.com>
+
+ Add support for COFF secidx relocations
+ bfd * coff-i386.c (in_reloc_p): Add R_SECTION.
+ (howto_table): Add R_SECTION.
+ (coff_pe_i386_relocation_section): Add support for R_SECTION.
+ (coff_i386_reloc_type_lookup): Add support for
+ BFD_RELOC_16_SECCIDX.
+ * coff-x86_64.c (in_reloc_p): Add R_SECTION.
+ (howto_table): Add R_SECTION.
+ (coff_pe_amd64_relocation_section): Add support for R_SECTION.
+ (coff_amd64_reloc_type_lookup): Add support for
+ BFD_RELOC_16_SECCIDX.
+ * reloc.c: Add BFD_RELOC_16_SECIDX.
+ * bfd-in2.h: Regenerate.
+ * libbfd.h: Regenerate.
+
+ gas * config/tc-i386.c (pe_directive_secidx): New function.
+ (md_pseudo_table): Add support for secidx.
+ (x86_cons_fix_new): Likewise.
+ (tc_gen_reloc): Likewise.
+ * expr.c (op_rank): Add O_secidx.
+ * expr.h (operatorT): Likewise.
+ * symbols.c (resolve_symbol_value): Add support for O_secidx.
+ * testsuite/gas/i386/secidx.s: New test source file.
+ * testsuite/gas/i386/secidx.d: New test driver file.
+ * testsuite/gas/i386/i386.exp: Run new test.
+
+ include * coff/i386.h: Define R_SECTION.
+ * coff/x86_64.h: Likewise.
+
+ ld * testsuite/ld-pe/secidx1.s: New test source file.
+ * testsuite/ld-pe/secidx2.s: New test source file.
+ * testsuite/ld-pe/secidx.d: New test driver file.
+ * testsuite/ld-pe/secidx_64.d: New test driver file.
+ * testsuite/ld-pe/pe.exp: Add new tests.
+
+2022-04-07 Jan Beulich <jbeulich@suse.com>
+
+ gas/Dwarf: record functions
+ To help tools like addr2line looking up function names, in particular
+ when dealing with e.g. PE/COFF binaries (linked from ELF objects), where
+ there's no ELF symbol table to fall back to, emit minimalistic
+ information for functions marked as such and having their size
+ specified.
+
+ Notes regarding the restriction to (pure) ELF:
+ - I realize this is a layering violation; I don't see how to deal with
+ that in a better way.
+ - S_GET_SIZE(), when OBJ_MAYBE_ELF is defined, looks wrong: Unlike
+ S_SET_SIZE() it does not check whether the hook is NULL.
+ - symbol_get_obj(), when OBJ_MAYBE_ELF is defined, looks unusable, as
+ its return type can only ever be one object format's type (and this
+ may then not be ELF's).
+
+ The new testcases are limited to x86 because I wanted to include the
+ case where function size can't be determined yet at the time Dwarf2 info
+ is generated. As .nops gains support by further targets, they could also
+ be added here then (with, as necessary, expecations suitably relaxed to
+ cover for insn size differences).
+
+2022-04-07 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: arrange for line number emission for .inst
+ Just like insns encoded the more conventional way these should have line
+ number info associated with them.
+
+ Arm32: arrange for line number emission for .inst
+ Just like insns encoded the more conventional way these should have line
+ number info associated with them.
+
+ RISC-V: add testcase to check line number emission for .insn
+ Since no such test looks to exist, derive one from insn.s.
+
+2022-04-07 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM zSystems: Add support for z16 as CPU name.
+ So far z16 was identified as arch14. After the machine has been
+ announced we can now add the real name.
+
+ gas/ChangeLog:
+
+ * config/tc-s390.c (s390_parse_cpu): Add z16 as alternate CPU
+ name.
+ * doc/as.texi: Add z16 and arch14 to CPU string list.
+ * doc/c-s390.texi: Add z16 to CPU string list.
+
+ opcodes/ChangeLog:
+
+ * s390-mkopc.c (main): Enable z16 as CPU string in the opcode
+ table.
+
+2022-04-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-06 Youling Tang <tangyouling@loongson.cn>
+
+ gdb: mips: Fix the handling of complex type of function return value
+ $ objdump -d outputs/gdb.base/varargs/varargs
+ 00000001200012e8 <find_max_float_real>:
+ ...
+ 1200013b8: c7c10000 lwc1 $f1,0(s8)
+ 1200013bc: c7c00004 lwc1 $f0,4(s8)
+ 1200013c0: 46000886 mov.s $f2,$f1
+ 1200013c4: 46000046 mov.s $f1,$f0
+ 1200013c8: 46001006 mov.s $f0,$f2
+ 1200013cc: 46000886 mov.s $f2,$f1
+ 1200013d0: 03c0e825 move sp,s8
+ 1200013d4: dfbe0038 ld s8,56(sp)
+ 1200013d8: 67bd0080 daddiu sp,sp,128
+ 1200013dc: 03e00008 jr ra
+ 1200013e0: 00000000 nop
+
+ From the above disassembly, we can see that when the return value of the
+ function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value
+ will be passed through $f0 and $f2, so fix the corresponding processing
+ in mips_n32n64_return_value().
+
+ $ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test'
+
+ Before applying the patch:
+ FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
+ FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4)
+
+ # of expected passes 9
+ # of unexpected failures 2
+
+ After applying the patch:
+ # of expected passes 11
+
+ This also fixes:
+ FAIL: gdb.base/callfuncs.exp: call inferior func with struct - returns float _Complex
+
+ Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+2022-04-06 Tom Tromey <tom@tromey.com>
+
+ Use new and delete in jit.c
+ This changes jit.c to use new and delete, rather than XCNEW. This
+ simplifies the code a little. This was useful for another patch I'm
+ working on, and I thought it would make sense to send it separately.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-04-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: don't copy entirely optimized out values in value_copy
+ Bug 28980 shows that trying to value_copy an entirely optimized out
+ value causes an internal error. The original bug report involves MI and
+ some Python pretty printer, and is quite difficult to reproduce, but
+ another easy way to reproduce (that is believed to be equivalent) was
+ proposed:
+
+ $ ./gdb -q -nx --data-directory=data-directory -ex "py print(gdb.Value(gdb.Value(5).type.optimized_out()))"
+ /home/smarchi/src/binutils-gdb/gdb/value.c:1731: internal-error: value_copy: Assertion `arg->contents != nullptr' failed.
+
+ This is caused by 5f8ab46bc691 ("gdb: constify parameter of
+ value_copy"). It added an assertion that the contents buffer is
+ allocated if the value is not lazy:
+
+ if (!value_lazy (val))
+ {
+ gdb_assert (arg->contents != nullptr);
+
+ This was based on the comment on value::contents, which suggest that
+ this is the case:
+
+ /* Actual contents of the value. Target byte-order. NULL or not
+ valid if lazy is nonzero. */
+ gdb::unique_xmalloc_ptr<gdb_byte> contents;
+
+ However, it turns out that it can also be nullptr also if the value is
+ entirely optimized out, for example on exit of
+ allocate_optimized_out_value. That function creates a lazy value, marks
+ the entire value as optimized out, and then clears the lazy flag. But
+ contents remains nullptr.
+
+ This wasn't a problem for value_copy before, because it was calling
+ value_contents_all_raw on the input value, which caused contents to be
+ allocated before doing the copy. This means that the input value to
+ value_copy did not have its contents allocated on entry, but had it
+ allocated on exit. The result value had it allocated on exit. And that
+ we copied bytes for an entirely optimized out value (i.e. meaningless
+ bytes).
+
+ From here I see two choices:
+
+ 1. respect the documented invariant that contents is nullptr only and
+ only if the value is lazy, which means making
+ allocate_optimized_out_value allocate contents
+ 2. extend the cases where contents can be nullptr to also include
+ values that are entirely optimized out (note that you could still
+ have some entirely optimized out values that do have contents
+ allocated, it depends on how they were created) and adjust
+ value_copy accordingly
+
+ Choice #1 is safe, but less efficient: it's not very useful to allocate
+ a buffer for an entirely optimized out value. It's even a bit less
+ efficient than what we had initially, because values coming out of
+ allocate_optimized_out_value would now always get their contents
+ allocated.
+
+ Choice #2 would be more efficient than what we had before: giving an
+ optimized out value without allocated contents to value_copy would
+ result in an optimized out value without allocated contents (and the
+ input value would still be without allocated contents on exit). But
+ it's more risky, since it's difficult to ensure that all users of the
+ contents (through the various_contents* accessors) are all fine with
+ that new invariant.
+
+ In this patch, I opt for choice #2, since I think it is a better
+ direction than choice #1. #1 would be a pessimization, and if we go
+ this way, I doubt that it will ever be revisited, it will just stay that
+ way forever.
+
+ Add a selftest to test this. I initially started to write it as a
+ Python test (since the reproducer is in Python), but a selftest is more
+ straightforward.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28980
+ Change-Id: I6e2f5c0ea804fafa041fcc4345d47064b5900ed7
+
+2022-04-06 Jeff Law <jeffreyalaw@gmail.com>
+
+ Fix for v850e divq instruction
+ This is the last of the correctness fixes I've been carrying around for the
+ v850.
+
+ Like the other recent fixes, this is another case where we haven't been as
+ careful as we should WRT host vs target types. For the divq instruction
+ both operands are 32 bit types. Yet in the simulator code we convert them
+ from unsigned int to signed long by assignment. So 0xfffffffb (aka -5)
+ turns into 4294967291 and naturally that changes the result of our division.
+
+ The fix is simple, insert a cast to int32_t to force interpretation as a
+ signed value.
+
+ Testcase for the simulator is included. It has a trivial dependency on the
+ bins patch.
+
+2022-04-06 Jeff Law <jeffreyalaw@gmail.com>
+
+ Fix "bins" simulation for v850e3v5
+ I've been carrying this for a few years. One test in the GCC testsuite is
+ failing due to a bug in the handling of the v850e3v5 instruction "bins".
+
+ When the "bins" instruction specifies a 32bit bitfield size, the simulator
+ exhibits undefined behavior by trying to shift a 32 bit quantity by 32 bits.
+ In the case of a 32 bit shift, we know what the resultant mask should be. So
+ we can just set it.
+
+ That seemed better than using 1UL for the constant (on a 32bit host unsigned
+ long might still just be 32 bits) or needlessly forcing everything to
+ long long types.
+
+ Thankfully the case where this shows up is only bins <src>, 0, 32, <dest>
+ which would normally be encoded as a simple move.
+
+ * testsuite/v850/allinsns.exp: Add v850e3v5.
+ * testsuite/v850/bins.cgs: New test.
+ * v850/simops.c (v850_bins): Avoid undefined behavior on left shift.
+
+2022-04-06 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: prepend tramp frame unwinder for signal
+ Implement the "init" method of struct tramp_frame to prepend tramp
+ frame unwinder for signal on LoongArch.
+
+ With this patch, the following failed testcases can be fixed:
+
+ FAIL: gdb.base/annota1.exp: backtrace @ signal handler (timeout)
+ FAIL: gdb.base/annota3.exp: backtrace @ signal handler (pattern 2)
+
+2022-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make interp_add static
+ Since this commit:
+
+ commit 8322445e0584be846f5873b9aab257dc9fbda05d
+ Date: Tue Jun 21 01:11:45 2016 +0100
+
+ Introduce interpreter factories
+
+ Interpreters should be registered with GDB, not by calling interp_add,
+ but with a call to interp_factory_register. I've checked the insight
+ source, and it too has moved over to using interp_factory_register.
+
+ In this commit I make interp_add static within interps.c.
+
+ There should be no user visible change after this commit.
+
+2022-04-06 Nick Clifton <nickc@redhat.com>
+
+ Add code to display the contents of .debug_loclists sections which contain offset entry tables.
+ PR 28981
+ * dwarf.c (fetch_indexed_value): Rename to fecth_indexed_addr and
+ return the address, rather than a string.
+ (fetch_indexed_value): New function - returns a value indexed by a
+ DW_FORM_loclistx or DW_FORM_rnglistx form.
+ (read_and_display_attr_value): Add support for DW_FORM_loclistx
+ and DW_FORM_rnglistx.
+ (process_debug_info): Load the loclists and rnglists sections.
+ (display_loclists_list): Add support for DW_LLE_base_addressx,
+ DW_LLE_startx_endx, DW_LLE_startx_length and
+ DW_LLE_default_location.
+ (display_offset_entry_loclists): New function. Displays a
+ .debug_loclists section that contains offset entry tables.
+ (display_debug_loc): Call the new function.
+ (display_debug_rnglists_list): Add support for
+ DW_RLE_base_addressx, DW_RLE_startx_endx and DW_RLE_startx_length.
+ (display_debug_ranges): Display the contents of the section's
+ header.
+ * dwarf.h (struct debug_info): Add loclists_base field.
+ * testsuite/binutils-all/dw5.W: Update expected output.
+ * testsuite/binutils-all/x86-64/pr26808.dump: Likewise.
+
+2022-04-06 Luis Machado <luis.machado@linaro.org>
+
+ Enable ARMv8.1-m PACBTI support
+ This set of changes enable support for the ARMv8.1-m PACBTI extensions [1].
+
+ The goal of the PACBTI extensions is similar in scope to that of a-profile
+ PAC/BTI (aarch64 only), but the underlying implementation is different.
+
+ One important difference is that the pointer authentication code is stored
+ in a separate register, thus we don't need to mask/unmask the return address
+ from a function in order to produce a correct backtrace.
+
+ The patch introduces the following modifications:
+
+ - Extend the prologue analyser for 32-bit ARM to handle some instructions
+ from ARMv8.1-m PACBTI: pac, aut, pacg, autg and bti. Also keep track of
+ return address signing/authentication instructions.
+
+ - Adds code to identify object file attributes that indicate the presence of
+ ARMv8.1-m PACBTI (Tag_PAC_extension, Tag_BTI_extension, Tag_PACRET_use and
+ Tag_BTI_use).
+
+ - Adds support for DWARF pseudo-register RA_AUTH_CODE, as described in the
+ aadwarf32 [2].
+
+ - Extends the dwarf unwinder to track the value of RA_AUTH_CODE.
+
+ - Decorates backtraces with the "[PAC]" identifier when a frame has signed
+ the return address.
+
+ - Makes GDB aware of a new XML feature "org.gnu.gdb.arm.m-profile-pacbti". This
+ feature is not included as an XML file on GDB's side because it is only
+ supported for bare metal targets.
+
+ - Additional documentation.
+
+ [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
+ [2] https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst
+
+2022-04-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move gdb_disassembly_flag into a new disasm-flags.h file
+ While working on the disassembler I was getting frustrated. Every
+ time I touched disasm.h it seemed like every file in GDB would need to
+ be rebuilt. Surely the disassembler can't be required by that many
+ parts of GDB, right?
+
+ Turns out that disasm.h is included in target.h, so pretty much every
+ file was being rebuilt!
+
+ The only thing from disasm.h that target.h needed is the
+ gdb_disassembly_flag enum, as this is part of the target_ops api.
+
+ In this commit I move gdb_disassembly_flag into its own file. This is
+ then included in target.h and disasm.h, after which, the number of
+ files that depend on disasm.h is much reduced.
+
+ I also audited all the other includes of disasm.h and found that the
+ includes in mep-tdep.c and python/py-registers.c are no longer needed,
+ so I've removed these.
+
+ Now, after changing disasm.h, GDB rebuilds much quicker.
+
+ There should be no user visible changes after this commit.
+
+2022-04-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-05 Tom Tromey <tom@tromey.com>
+
+ Introduce wrapped_file
+ Simon pointed out that timestamped_file probably needed to implement a
+ few more methods. This patch introduces a new file-wrapping file that
+ forwards most of its calls, making it simpler to implement new such
+ files. It also converts timestamped_file and pager_file to use it.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-04-05 Tom Tromey <tromey@adacore.com>
+
+ Don't call init_thread_list in windows-nat.c
+ I don't think there's any need to call init_thread_list in
+ windows-nat.c. This patch removes it. I tested this using the
+ internal AdaCore test suite on Windows, which FWIW does include some
+ multi-threaded inferiors.
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix intermittent failure in gdb.base/vfork-follow-parent.exp
+ Tom de Vries reported some failures in this test:
+
+ continue
+ Continuing.
+ [New inferior 2 (process 14967)]
+
+ Thread 1.1 "vfork-follow-pa" hit Breakpoint 2, break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23
+ 23 }
+ (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2
+ inferior 1
+ [Switching to inferior 1 [process 14961] (/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vfork-follow-parent)]
+ [Switching to thread 1.1 (process 14961)]
+ #0 break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23
+ 23 }
+ (gdb) PASS: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1
+ continue
+ Continuing.
+ [Inferior 2 (process 14967) exited normally]
+ (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (the program exited)
+
+ Here, we continue both the vfork parent and child, since
+ schedule-multiple is on. The child exits, which un-freezes the parent
+ and makes an exit event available to GDB. We expect GDB to consume this
+ exit event and present it to the user. Here, we see that GDB shows the
+ parent hitting a breakpoint before showing the child exit.
+
+ Because of the vfork, we know that chronologically, the child exiting
+ must have happend before the parent hitting a breakpoint. However,
+ scheduling being what it is, it is possible for the parent to un-freeze
+ and exit quickly, such that when GDB pulls events out of the kernel,
+ exit events for both processes are available. And then, GDB may chose
+ at random to return the one for the parent first. This is what I
+ imagine what causes the failure shown above.
+
+ We could change the test to expect both possible outcomes, but I wanted
+ to avoid complicating the .exp file that way. Instead, add a variable
+ that the parent loops on that we set only after we confirmed the exit of
+ the child. That should ensure that the order is always the same.
+
+ Note that I wasn't able to reproduce the failure, so I can't tell if
+ this fix really fixes the problem.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29021
+ Change-Id: Ibc8e527e0e00dac54b22021fe4d9d8ab0f3b28ad
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: fix intermittent failures in gdb.mi/mi-cmd-user-context.exp
+ I got failures like this once on a CI:
+
+ frame^M
+ &"frame\n"^M
+ ~"#0 child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M
+ ~"33\t dummy = !dummy; /* thread loop line */\n"^M
+ ^done^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
+
+ The problem is that the test expects the following regexp:
+
+ ".*#0 0x.*"
+
+ And that typically works, when the output of the frame command looks
+ like:
+
+ #0 0x00005555555551bb in child_sub_function () at ...
+
+ Note the lack of hexadecimal address in the failing case. Whether or
+ not the hexadecimal address is printed (roughly) depends on whether the
+ current PC is at the beginning of a line. So depending on where thread
+ 2 was when GDB stopped it (after thread 1 hit its breakpoint), we can
+ get either output. Adjust the regexps to not expect an hexadecimal
+ prefix (0x) but a function name instead (either child_sub_function or
+ child_function). That one is always printed, and is also a good check
+ that we are in the frame we expect.
+
+ Note that for test "frame 5", we are showing a pthread frame (on my
+ system), so the function name is internal to pthread, not something we
+ can rely on. In that case, it's almost certain that we are not at the
+ beginning of a line, or that we don't have debug info, so I think it's
+ fine to expect the hex prefix.
+
+ And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
+ test currently does), since we are showing thread 1, which has hit a
+ breakpoint placed at the beginning of a line.
+
+ When testing this, Tom de Vries pointed out that the current test code
+ doesn't ensure that the child threads are in child_sub_function when
+ they are stopped. If the scheduler chooses so, it is possible for the
+ child threads to be still in the pthread_barrier_wait or child_function
+ functions when they get stopped. So that would be another racy failure
+ waiting to happen.
+
+ The only way I can think of to ensure the child threads are in the
+ child_sub_function function when they get stopped is to synchronize the
+ threads using some variables instead of pthread_barrier_wait. So,
+ replace the barrier with an array of flags (one per child thread). Each
+ child thread flips its flag in child_sub_function to allow the main
+ thread to make progress and eventually hit the breakpoint.
+
+ I copied user-selected-context-sync.c to a new mi-cmd-user-context.c and
+ made modifications to that, to avoid interfering with
+ user-selected-context-sync.exp.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29025
+ Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90
+
+2022-04-05 Luis Machado <luis.machado@arm.com>
+
+ Fix qRcmd error code parsing
+ Someone at IRC spotted a bug in qRcmd handling. This looks like an oversight
+ or it is that way for historical reasons.
+
+ The code in gdb/remote.c:remote_target::rcmd uses isdigit instead of
+ isxdigit. One could argue that we are expecting decimal numbers, but further
+ below we use fromhex ().
+
+ Update the function to use isxdigit instead and also update the documentation.
+
+ I see there are lots of other cases of undocumented number format for error
+ messages, mostly described as NN instead of nn. For now I'll just update
+ this particular function.
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: resume ongoing step after handling fork or vfork
+ The test introduced by this patch would fail in this configuration, with
+ the native-gdbserver or native-extended-gdbserver boards:
+
+ FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=2: next to for loop
+
+ The problem is that the step operation is forgotten when handling the
+ fork/vfork. With "debug infrun" and "debug remote", it looks like this
+ (some lines omitted for brevity). We do the next:
+
+ [infrun] proceed: enter
+ [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+ [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154304.0] at 0x5555555553bf
+ [infrun] do_target_resume: resume_ptid=4154304.0.0, step=1, sig=GDB_SIGNAL_0
+ [remote] Sending packet: $vCont;r5555555553bf,5555555553c4:p3f63c0.3f63c0;c:p3f63c0.-1#cd
+ [infrun] proceed: exit
+
+ We then handle a fork event:
+
+ [infrun] fetch_inferior_event: enter
+ [remote] wait: enter
+ [remote] Packet received: T05fork:p3f63ee.3f63ee;06:0100000000000000;07:b08e59f6ff7f0000;10:bf60e8f7ff7f0000;thread:p3f63c0.3f63c6;core:17;
+ [remote] wait: exit
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 4154304.4154310.0 [Thread 4154304.4154310],
+ [infrun] print_target_wait_results: status->kind = FORKED, child_ptid = 4154350.4154350.0
+ [infrun] handle_inferior_event: status->kind = FORKED, child_ptid = 4154350.4154350.0
+ [remote] Sending packet: $D;3f63ee#4b
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154310.0] at 0x7ffff7e860bf
+ [infrun] do_target_resume: resume_ptid=4154304.0.0, step=0, sig=GDB_SIGNAL_0
+ [remote] Sending packet: $vCont;c:p3f63c0.-1#73
+ [infrun] fetch_inferior_event: exit
+
+ In the first snippet, we resume the stepping thread with the range-stepping (r)
+ vCont command. But after handling the fork (detaching the fork child), we
+ resumed the whole process freely. The stepping thread, which was paused by
+ GDBserver while reporting the fork event, was therefore resumed freely, instead
+ of confined to the addresses of the stepped line. Note that since this
+ is a "next", it could be that we have entered a function, installed a
+ step-resume breakpoint, and it's ok to continue freely the stepping
+ thread, but that's not the case here. The two snippets shown above were
+ next to each other in the logs.
+
+ For the fork case, we can resume stepping right after handling the
+ event.
+
+ However, for the vfork case, where we are waiting for the
+ external child process to exec or exit, we only resume the thread that
+ called vfork, and keep the others stopped (see patch "gdb: fix handling of
+ vfork by multi-threaded program" prior in this series). So we can't
+ resume the stepping thread right now. Instead, do it after handling the
+ vfork-done event.
+
+ Change-Id: I92539c970397ce880110e039fe92b87480f816bd
+
+2022-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/remote: remove_new_fork_children don't access target_waitstatus::child_ptid if kind == TARGET_WAITKIND_THREAD_EXITED
+ Following the previous patch, running
+ gdb.threads/forking-threads-plus-breakpoints.exp continuously eventually
+ gives me an internal error.
+
+ gdb/target/waitstatus.h:372: internal-error: child_ptid: Assertion `m_kind == TARGET_WAITKIND_FORKED || m_kind == TARGET_WAITKIND_VFORKED' failed.^M
+ FAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=0: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error)
+
+ The backtrace is:
+
+ 0x55925b679c85 internal_error(char const*, int, char const*, ...)
+ /home/simark/src/binutils-gdb/gdbsupport/errors.cc:55
+ 0x559258deadd2 target_waitstatus::child_ptid() const
+ /home/simark/src/binutils-gdb/gdb/target/waitstatus.h:372
+ 0x55925a7cbac9 remote_target::remove_new_fork_children(threads_listing_context*)
+ /home/simark/src/binutils-gdb/gdb/remote.c:7311
+ 0x55925a79dfdb remote_target::update_thread_list()
+ /home/simark/src/binutils-gdb/gdb/remote.c:3981
+ 0x55925ad79b83 target_update_thread_list()
+ /home/simark/src/binutils-gdb/gdb/target.c:3793
+ 0x55925addbb15 update_thread_list()
+ /home/simark/src/binutils-gdb/gdb/thread.c:2031
+ 0x559259d64838 stop_all_threads(char const*, inferior*)
+ /home/simark/src/binutils-gdb/gdb/infrun.c:5104
+ 0x559259d88b45 keep_going_pass_signal
+ /home/simark/src/binutils-gdb/gdb/infrun.c:8215
+ 0x559259d8951b keep_going
+ /home/simark/src/binutils-gdb/gdb/infrun.c:8251
+ 0x559259d78835 process_event_stop_test
+ /home/simark/src/binutils-gdb/gdb/infrun.c:6858
+ 0x559259d750e9 handle_signal_stop
+ /home/simark/src/binutils-gdb/gdb/infrun.c:6580
+ 0x559259d6c07b handle_inferior_event
+ /home/simark/src/binutils-gdb/gdb/infrun.c:5832
+ 0x559259d57db8 fetch_inferior_event()
+ /home/simark/src/binutils-gdb/gdb/infrun.c:4222
+
+ Indeed, the code accesses target_waitstatus::child_ptid when the kind
+ is TARGET_WAITKIND_THREAD_EXITED, which is not right. A
+ TARGET_WAITKIND_THREAD_EXITED event does not have a child_ptid value
+ associated, it has an exit status, which we are not interested in. The
+ intent is to remove from the thread list the thread that has exited.
+ Its ptid is found in the stop reply event, get it from there.
+
+ Change-Id: Icb298cbb80b8779fdf0c660dde9a5314d5591535
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver: report correct status in thread stop race condition
+ The test introduced by the following patch would sometimes fail in this
+ configuration:
+
+ FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=14: next to for loop
+
+ The test has multiple threads constantly forking or vforking while the
+ main thread keep doing "next"s.
+
+ (After writing the commit message, I realized this also fixes a similar
+ failure in gdb.threads/forking-threads-plus-breakpoint.exp with the
+ native-gdbserver and native-extended-gdbserver boards.)
+
+ As stop_all_threads is called, because the main thread finished its
+ "next", it inevitably happens at some point that we ask the remote
+ target to stop a thread and wait() reports that this thread stopped with
+ a fork or vfork event, instead of the SIGSTOP we sent to try to stop it.
+
+ While running this test, I attached to GDBserver and stopped at
+ linux-low.cc:3626. We can see that the status pulled from the kernel
+ for 2742805 is indeed a vfork event:
+
+ (gdb) p/x w
+ $3 = 0x2057f
+ (gdb) p WIFSTOPPED(w)
+ $4 = true
+ (gdb) p WSTOPSIG(w)
+ $5 = 5
+ (gdb) p/x (w >> 8) & (PTRACE_EVENT_VFORK << 8)
+ $6 = 0x200
+
+ However, the statement at line 3626 overrides that:
+
+ ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+ OURSTATUS becomes "stopped by a SIGTRAP". The information about the
+ fork or vfork is lost.
+
+ It's then all downhill from there, stop_all_threads eventually asks for
+ a thread list update. That thread list includes the child of that
+ forgotten fork or vfork, the remote target goes "oh cool, a new process,
+ let's attach to it!", when in fact that vfork child's destiny was to be
+ detached.
+
+ My reverse-engineered understanding of the code around there is that the
+ if/else between lines 3562 and 3583 (in the original code) makes sure
+ OURSTATUS is always initialized (not "ignore"). Either the details are
+ already in event_child->waitstatus (in the case of fork/vfork, for
+ example), in which case we just copy event_child->waitstatus to
+ ourstatus. Or, if the event is a plain "stopped by a signal" or a
+ syscall event, OURSTATUS is set to "stopped", but without a signal
+ number. Lines 3601 to 3629 (in the original code) serve to fill in that
+ last bit of information.
+
+ The problem is that when `w` holds the vfork status, the code wrongfully
+ takes this branch, because WSTOPSIG(w) returns SIGTRAP:
+
+ else if (current_thread->last_resume_kind == resume_stop
+ && WSTOPSIG (w) != SIGSTOP)
+
+ The intent of this branch is, for example, when we sent SIGSTOP to try
+ to stop a thread, but wait() reports that it stopped with another signal
+ (that it must have received from somewhere else simultaneously), say
+ SIGWINCH. In that case, we want to report the SIGWINCH. But in our
+ fork/vfork case, we don't want to take this branch, as the thread didn't
+ really stop because it received a signal. For the non "stopped by a
+ signal" and non "syscall signal" cases, we would ideally skip over all
+ that snippet that fills in the signal or syscall number.
+
+ The fix I propose is to move this snipppet of the else branch of the
+ if/else above. In addition to moving the code, the last two "else if"
+ branches:
+
+ else if (current_thread->last_resume_kind == resume_stop
+ && WSTOPSIG (w) != SIGSTOP)
+ {
+ /* A thread that has been requested to stop by GDB with vCont;t,
+ but, it stopped for other reasons. */
+ ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+ }
+ else if (ourstatus->kind () == TARGET_WAITKIND_STOPPED)
+ ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+ are changed into a single else:
+
+ else
+ ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+ This is the default path we take if:
+
+ - W is not a syscall status
+ - W does not represent a SIGSTOP that have sent to stop the thread and
+ therefore want to suppress it
+
+ Change-Id: If2dc1f0537a549c293f7fa3c53efd00e3e194e79
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on)
+ There is a problem with how GDB handles a vfork happening in a
+ multi-threaded program. This problem was reported to me by somebody not
+ using vfork directly, but using system(3) in a multi-threaded program,
+ which may be implemented using vfork.
+
+ This patch only deals about the follow-fork-mode=parent,
+ detach-on-fork=on case, because it would be too much to chew at once to
+ fix the bugs in the other cases as well (I tried).
+
+ The problem
+ -----------
+
+ When a program vforks, the parent thread is suspended by the kernel
+ until the child process exits or execs. Specifically, in a
+ multi-threaded program, only the thread that called vfork is suspended,
+ other threads keep running freely. This is documented in the vfork(2)
+ man page ("Caveats" section).
+
+ Let's suppose GDB is handling a vfork and the user's desire is to detach
+ from the child. Before detaching the child, GDB must remove the software
+ breakpoints inserted in the shared parent/child address space, in case
+ there's a breakpoint in the path the child is going to take before
+ exec'ing or exit'ing (unlikely, but possible). Otherwise the child could
+ hit a breakpoint instruction while running outside the control of GDB,
+ which would make it crash. GDB must also avoid re-inserting breakpoints
+ in the parent as long as it didn't receive the "vfork done" event (that
+ is, when the child has exited or execed): since the address space is
+ shared with the child, that would re-insert breakpoints in the child
+ process also. So what GDB does is:
+
+ 1. Receive "vfork" event for the parent
+ 2. Remove breakpoints from the (shared) address space and set
+ program_space::breakpoints_not_allowed to avoid re-inserting them
+ 3. Detach from the child thread
+ 4. Resume the parent
+ 5. Wait for and receive "vfork done" event for the parent
+ 6. Clean program_space::breakpoints_not_allowed and re-insert
+ breakpoints
+ 7. Resume the parent
+
+ Resuming the parent at step 4 is necessary in order for the kernel to
+ report the "vfork done" event. The kernel won't report a ptrace event
+ for a thread that is ptrace-stopped. But the theory behind this is that
+ between steps 4 and 5, the parent won't actually do any progress even
+ though it is ptrace-resumed, because the kernel keeps it suspended,
+ waiting for the child to exec or exit. So it doesn't matter for that
+ thread if breakpoints are not inserted.
+
+ The problem is when the program is multi-threaded. In step 4, GDB
+ resumes all threads of the parent. The thread that did the vfork stays
+ suspended by the kernel, so that's fine. But other threads are running
+ freely while breakpoints are removed, which is a problem because they
+ could miss a breakpoint that they should have hit.
+
+ The problem is present with all-stop and non-stop targets. The only
+ difference is that with an all-stop targets, the other threads are
+ stopped by the target when it reports the vfork event and are resumed by
+ the target when GDB resumes the parent. With a non-stop target, the
+ other threads are simply never stopped.
+
+ The fix
+ -------
+
+ There many combinations of settings to consider (all-stop/non-stop,
+ target-non-stop on/off, follow-fork-mode parent/child, detach-on-fork
+ on/off, schedule-multiple on/off), but for this patch I restrict the
+ scope to follow-fork-mode=parent, detach-on-fork=on. That's the
+ "default" case, where we detach the child and keep debugging the
+ parent. I tried to fix them all, but it's just too much to do at once.
+ The code paths and behaviors for when we don't detach the child are
+ completely different.
+
+ The guiding principle for this patch is that all threads of the vforking
+ inferior should be stopped as long as breakpoints are removed. This is
+ similar to handling in-line step-overs, in a way.
+
+ For non-stop targets (the default on Linux native), this is what
+ happens:
+
+ - In follow_fork, we call stop_all_threads to stop all threads of the
+ inferior
+ - In follow_fork_inferior, we record the vfork parent thread in
+ inferior::thread_waiting_for_vfork_done
+ - Back in handle_inferior_event, we call keep_going, which resumes only
+ the event thread (this is already the case, with a non-stop target).
+ This is the thread that will be waiting for vfork-done.
+ - When we get the vfork-done event, we go in the (new) handle_vfork_done
+ function to restart the previously stopped threads.
+
+ In the same scenario, but with an all-stop target:
+
+ - In follow_fork, no need to stop all threads of the inferior, the
+ target has stopped all threads of all its inferiors before returning
+ the event.
+ - In follow_fork_inferior, we record the vfork parent thread in
+ inferior::thread_waiting_for_vfork_done.
+ - Back in handle_inferior_event, we also call keep_going. However, we
+ only want to resume the event thread here, not all inferior threads.
+ In internal_resume_ptid (called by resume_1), we therefore now check
+ whether one of the inferiors we are about to resume has
+ thread_waiting_for_vfork_done set. If so, we only resume that
+ thread.
+
+ Note that when resuming multiple inferiors, one vforking and one not
+ non-vforking, we could resume the vforking thread from the vforking
+ inferior plus all threads from the non-vforking inferior. However,
+ this is not implemented, it would require more work.
+ - When we get the vfork-done event, the existing call to keep_going
+ naturally resumes all threads.
+
+ Testing-wise, add a test that tries to make the main thread hit a
+ breakpoint while a secondary thread calls vfork. Without the fix, the
+ main thread keeps going while breakpoints are removed, resulting in a
+ missed breakpoint and the program exiting.
+
+ Change-Id: I20eb78e17ca91f93c19c2b89a7e12c382ee814a1
+
+2022-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/infrun: add logging statement to do_target_resume
+ This helped me, it shows which ptid we actually call target_resume with.
+
+ Change-Id: I2dfd771e83df8c25f39371a13e3e91dc7882b73d
+
+2022-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/infrun: add inferior parameters to stop_all_threads and restart_threads
+ A following patch will want to stop all threads of a given inferior (as
+ opposed to all threads of all inferiors) while handling a vfork, and
+ restart them after. To help with this, add inferior parameters to
+ stop_all_threads and restart_threads. This is done as a separate patch
+ to make sure this doesn't cause regressions on its own, and to keep the
+ following patches more concise.
+
+ No visible changes are expected here, since all calls sites pass
+ nullptr, which should keep the existing behavior.
+
+ Change-Id: I4d9ba886ce842042075b4e346cfa64bbe2580dbf
+
+2022-04-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork_done
+ The inferior::waiting_for_vfork_done flag indicates that some thread in
+ that inferior is waiting for a vfork-done event. Subsequent patches
+ will need to know which thread precisely is waiting for that event.
+
+ Replace the boolean flag (waiting_for_vfork_done) with a thread_info
+ pointer (thread_waiting_for_vfork_done).
+
+ I think there is a latent buglet in that waiting_for_vfork_done is
+ currently not reset on inferior exec or exit. I could imagine that if a
+ thread in the parent process calls exec or exit while another thread of
+ the parent process is waiting for its vfork child to exec or exit, we
+ could end up with inferior::waiting_for_vfork_done without a thread
+ actually waiting for a vfork-done event anymore. And since that flag is
+ checked in resume_1, things could misbehave there.
+
+ Since the new field points to a thread_info object, and those are
+ destroyed on exec or exit, it could be worse now since we could try to
+ access freed memory, if thread_waiting_for_vfork_done were to point to a
+ stale thread_info. To avoid this, clear the field in
+ infrun_inferior_exit and infrun_inferior_execd.
+
+ Change-Id: I31b847278613a49ba03fc4915f74d9ceb228fdce
+
+2022-04-05 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: make timestamped_file implement write_async_safe
+ Trying to use "set debug linux-nat 1", I get an internal error:
+
+ /home/smarchi/src/binutils-gdb/gdb/ui-file.h:70: internal-error: write_async_safe: write_async_safe
+
+ The problem is that timestamped_file doesn't implement write_async_safe,
+ which linux-nat's sigchld_handler uses. Implement it.
+
+ Change-Id: I830981010c6119f13ae673605ed015cced0f5ee8
+
+2022-04-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix timeout in server-pipe.exp test
+ I noticed that the gdb.server/server-pipe.exp test would sometimes
+ timeout when my machine was more heavily loaded. Turns out the test
+ is reading all the shared libraries over GDB's remote protocol, which
+ can be slow.
+
+ We avoid this in other tests by setting the sysroot in GDBFLAGS,
+ something which is missing from the gdb.server/server-pipe.exp test.
+
+ Fix the timeouts by setting sysroot in GDBFLAGS, after this the shared
+ libraries are no longer copied over the remote protocol, and I no
+ longer see the test timeout.
+
+2022-04-04 John Baldwin <jhb@FreeBSD.org>
+
+ Handle TLS variable lookups when using separate debug files.
+ Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
+ a separate debug file was passed as the objfile for a shared library
+ to svr4_fetch_objfile_link_map. However, a separate debug file can
+ also be passed for TLS variables in the main executable. In addition,
+ frv_fetch_objfile_link_map also expects to be passed the original
+ objfile rather than a separate debug file, so pull the code to resolve
+ a separate debug file to the main objfile up into
+ target_translate_tls_address.
+
+2022-04-04 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Add maint set ignore-prologue-end-flag
+ The previous patch added support for the DWARF prologue-end flag in line
+ table. This flag can be used by DWARF producers to indicate where to
+ place breakpoints past a function prologue. However, this takes
+ precedence over prologue analyzers. So if we have to debug a program
+ with erroneous debug information, the overall debugging experience will
+ be degraded.
+
+ This commit proposes to add a maintenance command to instruct GDB to
+ ignore the prologue_end flag.
+
+ Tested on x86_64-gnu-linux.
+
+ Change-Id: Idda6d1b96ba887f4af555b43d9923261b9cc6f82
+
+2022-04-04 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Add support for DW_LNS_set_prologue_end in line-table
+ Add support for DW_LNS_set_prologue_end when building line-tables. This
+ attribute can be set by the compiler to indicate that an instruction is
+ an adequate place to set a breakpoint just after the prologue of a
+ function.
+
+ The compiler might set multiple prologue_end, but considering how
+ current skip_prologue_using_sal works, this commit modifies it to accept
+ the first instruction with this marker (if any) to be the place where a
+ breakpoint should be placed to be at the end of the prologue.
+
+ The need for this support came from a problematic usecase generated by
+ hipcc (i.e. clang). The problem is as follows: There's a function
+ (lets call it foo) which covers PC from 0xa800 to 0xa950. The body of
+ foo begins with a call to an inlined function, covering from 0xa800 to
+ 0xa94c. The issue is that when placing a breakpoint at 'foo', GDB
+ inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is
+ foo's first address past the prologue.
+
+ Later, when hitting the breakpoint, GDB reports the stop within the
+ inlined function because the PC falls in its range while the user
+ expects to stop in FOO.
+
+ Looking at the line-table for this location, we have:
+
+ INDEX LINE ADDRESS IS-STMT
+ [...]
+ 14 293 0x000000000000a66c Y
+ 15 END 0x000000000000a6e0 Y
+ 16 287 0x000000000000a800 Y
+ 17 END 0x000000000000a818 Y
+ 18 287 0x000000000000a824 Y
+ [...]
+
+ For comparison, let's look at llvm-dwarfdump's output for this CU:
+
+ Address Line Column File ISA Discriminator Flags
+ ------------------ ------ ------ ------ --- ------------- -------------
+ [...]
+ 0x000000000000a66c 293 12 2 0 0 is_stmt
+ 0x000000000000a6e0 96 43 82 0 0 is_stmt
+ 0x000000000000a6f8 102 18 82 0 0 is_stmt
+ 0x000000000000a70c 102 24 82 0 0
+ 0x000000000000a710 102 18 82 0 0
+ 0x000000000000a72c 101 16 82 0 0 is_stmt
+ 0x000000000000a73c 2915 50 83 0 0 is_stmt
+ 0x000000000000a74c 110 1 1 0 0 is_stmt
+ 0x000000000000a750 110 1 1 0 0 is_stmt end_sequence
+ 0x000000000000a800 107 0 1 0 0 is_stmt
+ 0x000000000000a800 287 12 2 0 0 is_stmt prologue_end
+ 0x000000000000a818 114 59 81 0 0 is_stmt
+ 0x000000000000a824 287 12 2 0 0 is_stmt
+ 0x000000000000a828 100 58 82 0 0 is_stmt
+ [...]
+
+ The main difference we are interested in here is that llvm-dwarfdump's
+ output tells us that 0xa800 is an adequate place to place a breakpoint
+ past a function prologue. Since we know that foo covers from 0xa800 to
+ 0xa94c, 0xa800 is the address at which the breakpoint should be placed
+ if the user wants to break in foo.
+
+ This commit proposes to add support for the prologue_end flag in the
+ line-program processing.
+
+ The processing of this prologue_end flag is made in skip_prologue_sal,
+ before it calls gdbarch_skip_prologue_noexcept. The intent is that if
+ the compiler gave information on where the prologue ends, we should use
+ this information and not try to rely on architecture dependent logic to
+ guess it.
+
+ The testsuite have been executed using this patch on GNU/Linux x86_64.
+ Testcases have been compiled with both gcc/g++ (verison 9.4.0) and
+ clang/clang++ (version 10.0.0) since at the time of writing GCC does not
+ set the prologue_end marker. Tests done with GCC 11.2.0 (not over the
+ entire testsuite) show that it does not emit this flag either.
+
+ No regression have been observed with GCC or Clang. Note that when
+ using Clang, this patch fixes a failure in
+ gdb.opt/inline-small-func.exp.
+
+ Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
+
+2022-04-04 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/buildsym: Line record use a record flag
+ Currently when recording a line entry (with
+ buildsym_compunit::record_line), a boolean argument argument is used to
+ indicate that the is_stmt flag should be set for this particular record.
+ As a later commit will add support for new flags, instead of adding a
+ parameter to record_line for each possible flag, transform the current
+ is_stmt parameter into a enum flag. This flags parameter will allow
+ greater flexibility in future commits.
+
+ This enum flags type is not propagated into the linetable_entry type as
+ this would require a lot of changes across the codebase for no practical
+ gain (it currently uses a bitfield where each interesting flag only
+ occupy 1 bit in the structure).
+
+ Tested on x86_64-linux, no regression observed.
+
+ Change-Id: I5d061fa67bdb34918742505ff983d37453839d6a
+
+2022-04-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make timestamped_file implement can_emit_style_escape
+ In our AMDGPU downstream port, we use styling in some logging output.
+ We noticed it stopped working after the gdb_printf changes. Making
+ timestamped_file implement can_emit_style_escape (returning the value of
+ the stream it wraps) fixes it. To show that it works, modify some
+ logging statements in auto-load.c to output style filenames. You can
+ see it in action by setting "set debug auto-load 1" and running a
+ program. We can incrementally add styling to other debug statements
+ throughout GDB, as needed.
+
+ Change-Id: I78a2fd1e078f80f2263251cf6bc53b3a9de9c17a
+
+2022-04-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove assertion in psymbol_functions::expand_symtabs_matching
+ psymtab_to_symtab is documented as possibly returning nullptr, if the
+ primary symtab of the partial symtab has no symbols. However,
+ psymbol_functions::expand_symtabs_matching asserts that the result of
+ psymtab_to_symtab as non-nullptr.
+
+ I caught this assert by trying the CTF symbol reader on a library I
+ built with -gctf:
+
+ $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+ ...
+ Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
+ (gdb) maintenance expand-symtabs
+ /home/simark/src/binutils-gdb/gdb/psymtab.c:1142: internal-error: expand_symtabs_matching: Assertion `symtab != nullptr' failed.
+
+ The "symtab" in question is:
+
+ $ readelf --ctf=.ctf /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+ ...
+ CTF archive member: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c:
+
+ Header:
+ Magic number: 0xdff2
+ Version: 4 (CTF_VERSION_3)
+ Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR)
+ Parent name: .ctf
+ Compilation unit name: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c
+ Type section: 0x0 -- 0x13 (0x14 bytes)
+ String section: 0x14 -- 0x5f (0x4c bytes)
+
+ Labels:
+
+ Data objects:
+
+ Function objects:
+
+ Variables:
+
+ Types:
+ 0x80000001: (kind 5) bt_bool (*) (const bt_value *) (aligned at 0x8)
+
+ Strings:
+ 0x0:
+ 0x1: .ctf
+ 0x6: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c
+
+ It contains a single type, and it is skipped by ctf_add_type_cb, because
+ an identical type was already seen earlier in this objfile. As a
+ result, no compunit_symtab is created.
+
+ Change psymbol_functions::expand_symtabs_matching to expect that
+ psymtab_to_symtab can return nullptr.
+
+ Another possibility would be to make the CTF symbol reader always create
+ a compunit_symtab, even if there are no symbols in it (like the DWARF
+ parser does), but so far I don't see any advantage in doing so.
+
+ Change-Id: Ic43c38202c838a5eb87630ed1fd61d33528164f4
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ sim: fixes for libopcodes styled disassembler
+ In commit:
+
+ commit 60a3da00bd5407f07d64dff82a4dae98230dfaac
+ Date: Sat Jan 22 11:38:18 2022 +0000
+
+ objdump/opcodes: add syntax highlighting to disassembler output
+
+ I broke several sim/ targets by forgetting to update their uses of the
+ libopcodes disassembler to take account of the new styled printing.
+
+ These should all be fixed by this commit.
+
+ I've not tried to add actual styled output to the simulator traces,
+ instead, the styled print routines just ignore the style and print the
+ output unstyled.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Remove some globals from nat/windows-nat.c
+ nat/windows-nat.c has a number of globals that it uses to communicate
+ with its clients (gdb and gdbserver). However, if we ever want the
+ Windows ports to be multi-inferior, globals won't work.
+
+ This patch takes a step toward that by moving most nat/windows-nat.c
+ globals into a new struct windows_process_info. Many functions are
+ converted to be methods on this object.
+
+ A couple of globals remain, as they are needed to truly be global due
+ to the way that the Windows debugging APIs work.
+
+ The clients still have a global for the current process. That is,
+ this patch is a step toward the end goal, but doesn't implement the
+ goal itself.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Remove windows_thread_info destructor
+ windows_thread_info declares and defines a destructor, but this
+ doesn't need to be explicit.
+
+ Use unique_ptr in the Windows thread list
+ windows-nat.c uses some manual memory management when manipulating the
+ thread_list global. Changing this to use unique_ptr simplifies the
+ code, in particular windows_init_thread_list. (Note that, while I
+ think the the call to init_thread_list in there is wrong, I haven't
+ removed it in this patch.)
+
+ Use auto_obstack in windows-nat.c
+ One spot in windows-nat.c can use auto_obstack, removing some manual
+ memory management.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Simplify windows-nat.c solib handling
+ Currently windows-nat.c uses struct so_list to record its local idea
+ of which shared libraries have been loaded. However, many fields in
+ this are not needed, and furthermore I found this quite confusing at
+ first -- Windows actually uses solib-target and so the use of so_list
+ here is weird.
+
+ This patch simplifies this code by changing it to use a std::vector
+ and a new type that holds exactly what's needed for the Windows code.
+
+2022-04-04 Pedro Alves <pedro@palves.net>
+
+ Avoid undefined behavior in gdbscm_make_breakpoint
+ Running gdb.guile/scm-breakpoint.exp against an --enable-ubsan build,
+ we see:
+
+ UNRESOLVED: gdb.guile/scm-breakpoint.exp: test_watchpoints: create a breakpoint with an invalid type number
+ ...
+ guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999))
+ ../../src/gdb/guile/scm-breakpoint.c:377:11: runtime error: load of value 999, which is not a valid value for type 'bptype'
+ ERROR: GDB process no longer exists
+
+ Fix this by parsing the user/guile input as plain int, and cast to
+ internal type only after we know we have a number that would be valid.
+
+ Change-Id: I03578d07db00be01b610a8f5ce72e5521aea6a4b
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Add context-sensitive field name completion to Ada parser
+ This updates the Ada expression parser to implement context-sensitive
+ field name completion. This is PR ada/28727.
+
+ This is somewhat complicated due to some choices in the Ada lexer --
+ it chooses to represent a sequence of "."-separated identifiers as a
+ single token, so the parser must partially recreate the completer's
+ logic to find the completion word boundaries.
+
+ Despite the minor warts in this patch, though, it is a decent
+ improvement. It's possible that the DWARF reader rewrite will help
+ fix the package completion problem pointed out in this patch as well.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28727
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Consolidate single-char tokens in ada-lex.l
+ There are two rules in ada-lex.l that match single-character tokens.
+ This merges them.
+
+ Also, this removes '.' from the list of such tokens. '.' is not used
+ in any production in ada-exp.y, and removing it here helps the
+ subsequent completion patches.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Remove the Ada DOT_ALL token
+ The Ada parser has a DOT_ALL token to represent ".all", and another
+ token to represent other ".<identifier>" forms. However, for
+ completion it is a bit more convenient to unify these cases, so this
+ patch removes DOT_ALL.
+
+ Refactor ada-lex.l:processId
+ processId in ada-lex.l is a bit funny -- it uses an "if" and a
+ "switch", and a nested loop. This patch cleans it up a bit, changing
+ it to use a boolean flag and a simpler "if".
+
+ Implement completion for Ada attributes
+ This adds a completer for Ada attributes. Some work in the lexer is
+ required in order to match end-of-input correctly, as flex does not
+ have a general-purpose way of doing this. (The approach taken here is
+ recommended in the flex manual.)
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Refactor expression completion
+ This refactors the gdb expression completion code to make it easier to
+ add more types of completers.
+
+ In the old approach, just two kinds of completers were supported:
+ field names for some sub-expression, or tag names (like "enum
+ something"). The data for each kind was combined in single structure,
+ "expr_completion_state", and handled explicitly by
+ complete_expression.
+
+ In the new approach, the parser state just holds an object that is
+ responsible for implementing completion. This way, new completion
+ types can be added by subclassing this base object.
+
+ The structop completer is moved into structop_base_operation, and new
+ objects are defined for use by the completion code. This moves much
+ of the logic of expression completion out of completer.c as well.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Enable "set debug parser" for Ada
+ I noticed that "set debug parser 1" did not affect Ada parsing. This
+ patch fixes the problem.
+
+ Because this is rarely useful, and pretty much only for maintainers, I
+ didn't write a test case.
+
+2022-04-04 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in Ada attributes lexing
+ The Ada lexer allows whitespace between the apostrophe and the
+ attribute text, but processAttribute does not handle this. This patch
+ fixes the problem and introduces a regression test.
+
+ Remove null sentinel from 'attributes'
+ In a subsequent patch, it's handy if the 'attributes' array in
+ ada-lex.l does not have a NULL sentinel at the end. In C++, this is
+ easy to avoid.
+
+ Handle ghost entities in symbol lookup
+ Normally, SPARK ghost entities are removed from the executable.
+ However, with -gnata, they will be preserved. In this situation, it's
+ handy to be able to inspect them. This patch allows this by removing
+ the "___ghost_" prefix in the appropriate places.
+
+2022-04-04 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename start_symtab/end_symtab to start_compunit_symtab/end_compunit_symtab
+ It's a bit confusing because we have both "compunit_symtab" and "symtab"
+ types, and many methods and functions containing "start_symtab" or
+ "end_symtab", which actually deal with compunit_symtabs. I believe this
+ comes from the time before compunit_symtab was introduced, where
+ symtab did the job of both.
+
+ Rename everything I found containing start_symtab or end_symtab to use
+ start_compunit_symtab or end_compunit_symtab.
+
+ Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
+
+2022-04-04 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove some unused buildsym-legacy functions
+ Pretty much self-explanatory.
+
+ Change-Id: I5b658d017cd891ecdd1df61075eacb0f44316935
+
+2022-04-04 Fangrui Song <i@maskray.me>
+
+ gas: copy st_size only if unset
+ For
+ ```
+ .size foo1, 1
+ foo1:
+
+ .set bar1, foo1
+ .size bar1, 2
+ .size bar2, 2
+ .set bar2, foo1
+
+ .set bar3, foo2
+ .size bar3, 2
+ .size bar4, 2
+ .set bar4, foo2
+
+ .size foo2, 1
+ foo2:
+ ```
+
+ bar1's size is 2 while bar2, bar3, bar4's is 1. The behavior of bar1 makes sense
+ (generally directives on the new symbol should win) and is relied upon by glibc
+ stdio-common/errlist.c:
+
+ ```
+ .hidden _sys_errlist_internal
+ .globl _sys_errlist_internal
+ .type _sys_errlist_internal, @object
+ .size _sys_errlist_internal, 1072
+ _sys_errlist_internal:
+
+ .globl __GLIBC_2_1_sys_errlist
+ .set __GLIBC_2_1_sys_errlist, _sys_errlist_internal
+ .type __GLIBC_2_1_sys_errlist, %object
+ .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8)
+
+ // glibc expects that .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) wins.
+ ```
+
+ The behavior of bar2/bar3/bar4 seems brittle. To avoid the reordering of the two
+ code blocks which will result in the bar3 situation, glibc compiles errlist.c
+ with gcc -fno-toplevel-reorder (previously -fno-unit-at-a-time).
+
+ To fix the inconsistency and improve robustness, make bar2/bar3/bar4 match bar1,
+ removing the directive order sensitivity.
+
+ There is a pity that `.size dest, 0` is indistinguishable from the case where
+ dest is unset, but the compromise seems fine.
+
+ PR gas/29012
+ * config/obj-elf.c (elf_copy_symbol_attributes): don't copy if src's size
+ has been set.
+ * testsuite/gas/elf/elf.exp: New test.
+ * testsuite/gas/elf/size.d: New file.
+ * testsuite/gas/elf/size.s: Likewise.
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove use of vfprintf_filtered
+ Commit:
+
+ commit 60a3da00bd5407f07d64dff82a4dae98230dfaac
+ Date: Sat Jan 22 11:38:18 2022 +0000
+
+ objdump/opcodes: add syntax highlighting to disassembler output
+
+ Introduced a new use of vfprintf_filtered, which has been deprecated.
+ This commit replaces this with gdb_vprintf instead.
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/i386: partially implement disassembler style support
+ This commit adds partial support for disassembler styling in the i386
+ disassembler.
+
+ The i386 disassembler collects the instruction arguments into an array
+ of strings, and then loops over the array printing the arguments out
+ later on. The problem is that by the time we print the arguments out
+ it's not obvious what the type of each argument is.
+
+ Obviously this can be fixed, but I'd like to not do that as part of
+ this commit, rather, I'd prefer to keep this commit as small as
+ possible to get the basic infrastructure in place, then we can improve
+ on this, to add additional styling, in later commits.
+
+ For now then, I think this commit should correctly style mnemonics,
+ some immediates, and comments. Everything else will be printed as
+ plain text, which will include most instruction arguments, unless the
+ argument is printed as a symbol, by calling the print_address_func
+ callback.
+
+ Ignoring colours, there should be no other user visible changes in the
+ output of the disassembler in either objdump or gdb.
+
+ opcodes/ChangeLog:
+
+ * disassembler.c (disassemble_init_for_target): Set
+ created_styled_output for i386 based targets.
+ * i386-dis.c: Changed throughout to use fprintf_styled_func
+ instead of fprintf_func.
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ opcodes/riscv: implement style support in the disassembler
+ Update the RISC-V disassembler to supply style information. This
+ allows objdump to apply syntax highlighting to the disassembler
+ output (when the appropriate command line flag is used).
+
+ Ignoring colours, there should be no other user visible changes in the
+ output of the disassembler in either objdump or gdb.
+
+ opcodes/ChangeLog:
+
+ * disassembler.c (disassemble_init_for_target): Set
+ created_styled_output for riscv.
+ * riscv-dis.c: Changed throughout to use fprintf_styled_func
+ instead of fprintf_func.
+
+2022-04-04 Andrew Burgess <aburgess@redhat.com>
+
+ objdump/opcodes: add syntax highlighting to disassembler output
+ This commit adds the _option_ of having disassembler output syntax
+ highlighted in objdump. This option is _off_ by default. The new
+ command line options are:
+
+ --disassembler-color=off # The default.
+ --disassembler-color=color
+ --disassembler-color=extended-color
+
+ I have implemented two colour modes, using the same option names as we
+ use of --visualize-jumps, a basic 8-color mode ("color"), and an
+ extended 8bit color mode ("extended-color").
+
+ The syntax highlighting requires that each targets disassembler be
+ updated; each time the disassembler produces some output we now pass
+ through an additional parameter indicating what style should be
+ applied to the text.
+
+ As updating all target disassemblers is a large task, the old API is
+ maintained. And so, a user of the disassembler (i.e. objdump, gdb)
+ must provide two functions, the current non-styled print function, and
+ a new, styled print function.
+
+ I don't currently have a plan for converting every single target
+ disassembler, my hope is that interested folk will update the
+ disassemblers they are interested in. But it is possible some might
+ never get updated.
+
+ In this initial series I intend to convert the RISC-V disassembler
+ completely, and also do a partial conversion of the x86 disassembler.
+ Hopefully having the x86 disassembler at least partial converted will
+ allow more people to try this out easily and provide feedback.
+
+ In this commit I have focused on objdump. The changes to GDB at this
+ point are the bare minimum required to get things compiling, GDB makes
+ no use of the styling information to provide any colors, that will
+ come later, if this commit is accepted.
+
+ This first commit in the series doesn't convert any target
+ disassemblers at all (the next two commits will update some targets),
+ so after this commit, the only color you will see in the disassembler
+ output, is that produced from objdump itself, e.g. from
+ objdump_print_addr_with_sym, where we print an address and a symbol
+ name, these are now printed with styling information, and so will have
+ colors applied (if the option is on).
+
+ Finally, my ability to pick "good" colors is ... well, terrible. I'm
+ in no way committed to the colors I've picked here, so I encourage
+ people to suggest new colors, or wait for this commit to land, and
+ then patch the choice of colors.
+
+ I do have an idea about using possibly an environment variable to
+ allow the objdump colors to be customised, but I haven't done anything
+ like that in this commit, the color choices are just fixed in the code
+ for now.
+
+ binutils/ChangeLog:
+
+ * NEWS: Mention new feature.
+ * doc/binutils.texi (objdump): Describe --disassembler-color
+ option.
+ * objdump.c (disassembler_color): New global.
+ (disassembler_extended_color): Likewise.
+ (disassembler_in_comment): Likewise.
+ (usage): Mention --disassembler-color option.
+ (long_options): Add --disassembler-color option.
+ (objdump_print_value): Use fprintf_styled_func instead of
+ fprintf_func.
+ (objdump_print_symname): Likewise.
+ (objdump_print_addr_with_sym): Likewise.
+ (objdump_color_for_disassembler_style): New function.
+ (objdump_styled_sprintf): New function.
+ (fprintf_styled): New function.
+ (disassemble_jumps): Use disassemble_set_printf, and reset
+ disassembler_in_comment.
+ (null_styled_print): New function.
+ (disassemble_bytes): Use disassemble_set_printf, and reset
+ disassembler_in_comment.
+ (disassemble_data): Update init_disassemble_info call.
+ (main): Handle --disassembler-color option.
+
+ include/ChangeLog:
+
+ * dis-asm.h (enum disassembler_style): New enum.
+ (struct disassemble_info): Add fprintf_styled_func field, and
+ created_styled_output field.
+ (disassemble_set_printf): Declare.
+ (init_disassemble_info): Add additional parameter.
+ (INIT_DISASSEMBLE_INFO): Add additional parameter.
+
+ opcodes/ChangeLog:
+
+ * dis-init.c (init_disassemble_info): Take extra parameter,
+ initialize the new fprintf_styled_func and created_styled_output
+ fields.
+ * disassembler.c (disassemble_set_printf): New function definition.
+
+2022-04-04 Tom Tromey <tom@tromey.com>
+
+ Remove more Python 2 code
+ I found another more place that still had a workaround for Python 2.
+ This patch removes it.
+
+2022-04-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix KPASS in gdb.ada/arrayptr.exp
+ On openSUSE Leap 15.3 I run into:
+ ...
+ KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all \
+ (PRMS minimal encodings)
+ KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) \
+ (PRMS minimal encodings)
+ KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all(3) \
+ (PRMS minimal encodings)
+ ...
+
+ The test-case KFAILs some tests. However, the analysis in the corresponding
+ PR talks of a compiler problem, so it should use XFAILs instead.
+
+ The KFAILs are setup for pre-gcc-12, but apparantly the fix has been
+ backported to system compiler 7.5.0, hence the KPASS.
+
+ Fix this by:
+ - using an XFAIL instead of a KFAIL
+ - matching the specific gdb output that corresponds to the XFAILs
+ (reproduced on Fedora 34).
+
+ Tested on x86_64-linux, specifically openSUSE Leap 15.3 and Fedora 34.
+
+2022-04-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-03 rupothar <rupesh.potharla@amd.com>
+
+ gdb: add support for Fortran's ASSUMED RANK arrays
+ This patch adds a new dynamic property DYN_PROP_RANK, this property is
+ read from the DW_AT_rank attribute and stored within the type just
+ like other dynamic properties.
+
+ As arrays with dynamic ranks make use of a single
+ DW_TAG_generic_subrange to represent all ranks of the array, support
+ for this tag has been added to dwarf2/read.c.
+
+ The final piece of this puzzle is to add support in gdbtypes.c so that
+ we can resolve an array type with dynamic rank. To do this the
+ existing resolve_dynamic_array_or_string function is split into two,
+ there's a new resolve_dynamic_array_or_string_1 core that is
+ responsible for resolving each rank of the array, while the now outer
+ resolve_dynamic_array_or_string is responsible for figuring out the
+ array rank (which might require resolving a dynamic property) and then
+ calling the inner core.
+
+ The resolve_dynamic_range function now takes a rank, which is passed
+ on to the dwarf expression evaluator. This rank will only be used in
+ the case where the array itself has dynamic rank, but we now pass the
+ rank in all cases, this should be harmless if the rank is not needed.
+
+ The only small nit is that resolve_dynamic_type_internal actually
+ handles resolving dynamic ranges itself, which now obviously requires
+ us to pass a rank value. But what rank value to use? In the end I
+ just passed '1' through here as a sane default, my thinking is that if
+ we are in resolve_dynamic_type_internal to resolve a range, then the
+ range isn't part of an array with dynamic rank, and so the range
+ should actually be using the rank value at all.
+
+ An alternative approach would be to make the rank value a
+ gdb::optional, however, this ends up adding a bunch of complexity to
+ the code (e.g. having to conditionally build the array to pass to
+ dwarf2_evaluate_property, and handling the 'rank - 1' in
+ resolve_dynamic_array_or_string_1) so I haven't done that, but could,
+ if people think that would be a better approach.
+
+ Finally, support for assumed rank arrays was only fixed very recently
+ in gcc, so you'll need the latest gcc in order to run the tests for
+ this.
+
+ Here's an example test program:
+
+ PROGRAM arank
+ REAL :: a1(10)
+ CALL sub1(a1)
+
+ CONTAINS
+
+ SUBROUTINE sub1(a)
+ REAL :: a(..)
+ PRINT *, RANK(a)
+ END SUBROUTINE sub1
+ END PROGRAM arank
+
+ Compiler Version:
+ gcc (GCC) 12.0.0 20211122 (experimental)
+
+ Compilation command:
+ gfortran assumedrank.f90 -gdwarf-5 -o assumedrank
+
+ Without Patch:
+
+ gdb -q assumedrank
+ Reading symbols from assumedrank...
+ (gdb) break sub1
+ Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
+ (gdb) run
+ Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
+
+ Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787
+ /bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10
+ 10 PRINT *, RANK(a)
+ (gdb) print RANK(a)
+ 'a' has unknown type; cast it to its declared type
+
+ With patch:
+
+ gdb -q assumedrank
+ Reading symbols from assumedrank...
+ (gdb) break sub1
+ Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
+ (gdb) run
+ Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
+
+ Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10
+ 10 PRINT *, RANK(a)
+ (gdb) print RANK(a)
+ $1 = 1
+ (gdb) ptype a
+ type = real(kind=4) (10)
+ (gdb)
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/dwarf: pass an array of values to the dwarf evaluator
+ When we need to evaluate a DWARF expression in order to resolve some
+ dynamic property of a type we call the dwarf2_evaluate_property
+ function, which is declared in gdb/dwarf/loc.h and defined in
+ gdb/dwarf/loc.c.
+
+ Currently, this function takes (amongst other things) an argument of
+ type property_addr_info called addr_stack and a boolean called
+ push_initial_value. When push_initial_value then the top value of
+ addr_stack is pushed onto the dwarf expression evaluation stack before
+ the expression is evaluated.
+
+ So far this has worked fine, as the only two cases we needed to handle
+ are the case the DWARF expression doesn't require the object
+ address (what the top of addr_stack represents), and the case where
+ the DWARF expression does require the address.
+
+ In the next commit this is going to change. As we add support for
+ Fortran assumed rank arrays, we need to start resolving the dynamic
+ properties of arrays. To do this, we need to push the array rank onto
+ the dwarf expression evaluation stack before the expression is
+ evaluated.
+
+ This commit is a refactoring commit aimed at making it easier to
+ support Fortran assumed rank arrays. Instead of passing a boolean,
+ and using this to decide if we should push the object address or not,
+ we instead pass an array (view) of values that should be pushed to the
+ dwarf expression evaluation stack.
+
+ In the couple of places where we previously passed push_initial_value
+ as true (mostly this was defaulting to false), we now have to pass the
+ address from the addr_stack as an item in the array view.
+
+ In the next commit, when we want to handle passing the array rank,
+ this will easily be supported too.
+
+ There should be no user visible changes after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: small simplification in dwarf2_locexpr_baton_eval
+ While examining the dwarf expression evaluator, I noticed that in
+ dwarf2_locexpr_baton_eval, whenever push_initial_value is true, the
+ addr_stack will never be nullptr.
+
+ This allows for a small cleanup, replacing an if/then/else with an
+ assertion.
+
+ There should be no user visible changes after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve some duplicate test names in gdb.base
+ This commit resolves all the duplicate test names that I see in the
+ script:
+
+ gdb.base/attach-pie-misread.exp
+
+ The duplicate names all come from a second call to
+ build_executable_own_libs, so in this commit I've places the second
+ call inside a with_test_prefix block.
+
+ While I was making this change I've also modified the value being
+ passed as the testname for the second build_executable_own_libs call.
+ Previously we used ${test}, however, I think this was likely a
+ mistake, the 'test' variable is setup for the previous test. I
+ suspect that ${testfile} is a better choice - especially now we have a
+ testname prefix.
+
+ As the testname is only used (after various calls) from within
+ build_executable_from_specs should the build fail, I don't think this
+ change really makes much difference though.
+
+ There should be no change in what is tested after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve a duplicate test name in a gdb.mi test
+ Solve two duplicate test names in the test script:
+
+ gdb.mi/mi-catch-cpp-exceptions.exp
+
+ by moving the call to restart_for_test inside the with_test_prefix
+ block. There should be no difference in what is tested after this
+ commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/Makefile.in: move ALLDEPFILES earlier in Makefile.in
+ If I do 'make tags' in the gdb build directory, the tags target does
+ complete, but I see these warnings:
+
+ ../../src/gdb/arm.c: No such file or directory
+ ../../src/gdb/arm-get-next-pcs.c: No such file or directory
+ ../../src/gdb/arm-linux.c: No such file or directory
+
+ The reason for this is the ordering of build rules and make variables
+ in gdb/Makefile.in, specifically, the placement of the tags related
+ rules, and the ALLDEPFILES variable. The ordering is like this:
+
+ TAGFILES_NO_SRCDIR = .... $(ALLDEPFILES) ....
+
+ TAGS: $(TAGFILES_NO_SRCDIR) ....
+ # Recipe uses $(TAGFILES_NO_SRCDIR)
+
+ tags: TAGS
+
+ ALLDEPFILES = .....
+
+ When the TAGS rule is parsed TAGFILES_NO_SRCDIR is expanded, which
+ then expands ALLDEPFILES, which, at that point in the Makefile is
+ undefined, and so expands to the empty string. As a result TAGS does
+ not depend on any file listed in ALLDEPFILES.
+
+ However, when the TAGS recipe is invoked ALLDEPFILES is now defined.
+ As a result, all the files in ALLDEPFILES are passed to the etags
+ program.
+
+ The ALLDEPFILES references three files, arm.c, arm-get-next-pcs.c, and
+ arm-linux.c, which are actually in the gdb/arch/ directory, but, in
+ ALLDEPFILES these files don't include the arch/ prefix. As a result,
+ the etags program ends up looking for these files in the wrong
+ location.
+
+ As ALLDEPFILES is only used by the TAGS rule, this mistake was not
+ previously noticed (the TAGS rule itself was broken until a recent
+ commit).
+
+ In this commit I make two changes, first, I move ALLDEPFILES to be
+ defined before TAGFILES_NO_SRCDIR, this means that the TAGS rule will
+ depend on all the files in ALLDEPFILES. With this change the TAGS
+ rule now breaks complaining that there's no rule to build the 3 files
+ mentioned above.
+
+ Next, I have added all *.c files in gdb/arch/ to ALLDEPFILES,
+ including their arch/ prefix, and removed the incorrect (missing arch/
+ prefix) references.
+
+ With these two changes the TAGS (or tags if you prefer) target now
+ builds without any errors or warnings.
+
+2022-04-03 Reuben Thomas <rrt@sc3d.org>
+
+ gdb/Makefile.in: fix 'make tags' build target
+ The gdb_select.h file was moved to the gdbsupport directory long ago,
+ but a reference was accident left in gdb/Makefile.in (in the
+ HFILES_NO_SRCDIR variable), this commit removes that reference.
+
+ Before this commit, if I use 'make tags' here's what I see:
+
+ $ make tags
+ make: *** No rule to make target 'gdb_select.h', needed by 'TAGS'. Stop.
+
+ After this commit 'make tags' completes, but I still see these
+ warnings:
+
+ ../../src/gdb/arm.c: No such file or directory
+ ../../src/gdb/arm-get-next-pcs.c: No such file or directory
+ ../../src/gdb/arm-linux.c: No such file or directory
+
+ These are caused by a separate issue, and will be addressed in the
+ next commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/Makefile.in: remove SOURCES variable
+ The SOURCES variable was added to gdb/Makefile.in as part of commit:
+
+ commit fb40c20903110ed8af9701ce7c2635abd3770d52
+ Date: Wed Feb 23 00:25:43 2000 +0000
+
+ Add mi/ and testsuite/gdb.mi/ subdirectories.
+
+ But as far as I can tell was not used at the time it was added, and is
+ not used today.
+
+ Lets remove it.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: fair split of delta after a resize
+ Currently, in master gdb, when a tui window is changed in size, the
+ screen delta is mostly just added to the next available window. We
+ do take care to respect the min/max size, but in most cases, these
+ limits are just "the terminal size", and so, we end up placing the
+ whole delta on the next window.
+
+ Consider these steps in an 80 column, 24 line terminal:
+
+ (gdb) tui enable
+ (gdb) layout src
+ (gdb) layout split
+ (gdb) info win
+ Name Lines Columns Focus
+ src 8 80 (has focus)
+ asm 8 80
+ status 1 80
+ cmd 8 80
+ (gdb) winheight cmd +2
+ (gdb) info win
+ Name Lines Columns Focus
+ src 6 80 (has focus)
+ asm 8 80
+ status 1 80
+ cmd 10 80
+
+ Notice that initially, the windows were balanced, 8 lines each for the
+ major windows. Then, when the cmd window was adjusted, the extra two
+ lines were given to the asm window.
+
+ I think it would be nicer if the delta was spread more evenly over the
+ available windows. In the example above, after the adjustment the
+ layout now looks like:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ src 7 80 (has focus)
+ asm 7 80
+ status 1 80
+ cmd 10 80
+
+ This is achieved within tui_layout_split::set_size, by just handing
+ out the delta in increments of 1 to each window (except for the window
+ the user adjusted), until there's no more delta left. Of course, we
+ continue to respect the min/max window sizes.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: relax restrictions on window max height and width
+ This commit removes some arbitrary adjustments made in
+ tui_cmd_window::max_height, tui_win_info::max_height, and
+ tui_win_info::max_width.
+
+ These member functions all subtract some constant from the theoretical
+ maximum height or width. I've looked back through the history a
+ little and can see no real reason why these adjustments should be
+ needed, with these adjustments removed all the existing tui tests
+ still pass.
+
+ However, retaining these restrictions causes some bugs, consider:
+
+ (gdb) tui new-layout hsrc {-horizontal src 1 cmd 1} 1
+
+ When this layout is selected with current master, gdb will leave a 4
+ line gap at the bottom of the terminal.
+
+ The problem is that the maximum height is restricted, for the cmd
+ window, to 4 less than the terminal height.
+
+ By removing this restriction gdb is able to size the windows to the
+ complete terminal height, and the layout is done correctly.
+
+ This 4 line restriction is also what prevents this layout from working
+ correctly:
+
+ (gdb) tui new-layout conly cmd 1
+
+ Previously, this layout would present a cmd window only, but there
+ would be a 4 line gap at the bottom of the terminal. This issue was
+ mentioned in an earlier commit in this series (when a different bug
+ was fixed), but with this commit, the above layout now correctly fills
+ the terminal. The associated test is updated.
+
+ After removing the adjustment in tui_cmd_window::max_height, the
+ implementation is now the same as the implementation in the parent
+ class tui_win_info, so I've completely removed the max_height call
+ from tui_cmd_window.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: some additional tests in gdb.tui/scroll.exp
+ This commit just adds an extra check of the src window size prior to
+ sending all the commands to gdb. We also set the cmd window height to
+ its existing height, this (obviously) shouldn't change the window
+ layout, which we check.
+
+ My main motivation was adding the initial window layout check, the
+ winheight and recheck are just extras. All of these test pass both
+ before and after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: support placing the cmd window into a horizontal layout
+ This commit allows the user to place the cmd window within horizontal
+ tui layouts. Consider this set of steps, carried out in an 80 columns
+ by 24 lines terminal, using current master gdb:
+
+ (gdb) tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
+ (gdb) tui layout hsrc
+
+ What you end up with is a full width cmd window with the status bar
+ beneath. Where's the src window gone? We then try:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ src 23 3 (has focus)
+ cmd 23 80
+ status 1 80
+ (gdb)
+
+ Something weird has gone on, gdb has overlapped the cmd window with
+ the src window. If we trigger the src window to redraw is content,
+ for example, 'list main', then we see corruption in the cmd window as
+ the src window overwrites it.
+
+ So, what's going on?
+
+ The problem is some code in tui_layout_split::apply, in tui-layout.c.
+ Within 'Step 1', there is a loop that calculates the min/max window
+ sizes for all windows within a tui_layout_split. However, there's a
+ special case for the cmd window.
+
+ This special case is trying to have the cmd window retain its current
+ size when a layout is re-applied, or a new layout is applied. This
+ makes sense, consider moving from the 'src' layout to the 'asm'
+ layout, this looks something like this (status window removed):
+
+ .-------. .-------.
+ | src | | asm |
+ |-------| ====> |-------|
+ | cmd | | cmd |
+ '-------' '-------'
+
+ If the user has gone to the effort of adjusting the cmd window size,
+ then, the thinking goes, we shouldn't reset the cmd window size when
+ switching layouts like this.
+
+ The problem though, is that when we do a switch more like this:
+
+ .-----------. .-----------.
+ | src | | | |
+ |-----------| ====> | asm | cmd |
+ | cmd | | | |
+ '-----------' '-----------'
+
+ Now retaining the cmd window width makes no sense; the new layout has
+ a completely different placement for the cmd window, instead of sizing
+ by height, we're now sizing by width. The existing code doesn't
+ understand this though, and tried to retain the full width for the cmd
+ window.
+
+ To solve this problem, I propose we introduce the idea of a layout
+ "fingerprint". The fingerprint tries to capture, in an abstract way,
+ where the cmd window lives within the layout.
+
+ Only when two layouts have the same fingerprint will we attempt to
+ retain the cmd window size.
+
+ The fingerprint for a layout is represented as a string, the string is
+ a series of 'V' or 'H' characters, ending with a single 'C'
+ character. The series of 'V' and 'H' characters represent the
+ vertical or horizontal layouts that must be passed through to find the
+ cmd window.
+
+ Here are a few examples:
+
+ # This layout is equivalent to the builtin 'src' layout.
+ # Fingerprint: VC
+ tui new-layout example1 src 2 status 0 cmd 1
+
+ # This layout is equivalent to the builtin 'split' layout.
+ # Fingerprint: VC
+ tui new-layout example2 src 1 asm 1 status 0 cmd 1
+
+ # This is the same layout that was given at the top.
+ # Fingerprint: VHC
+ tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
+
+ And so, when switching between example1 and example2, gdb knows that
+ the cmd window is, basically, in the same sort of position within the
+ layout, and will retain the cmd window size.
+
+ In contrast, when switching to the hsrc layout, gdb understands that
+ the position of the cmd window is different, and does not try to
+ retain the cmd window size.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: allow cmd window to change size in tui_layout_split::apply
+ When we switch layouts we call the tui_layout_split::apply member
+ function to reapply the layout, and recalculate all the window sizes.
+
+ One special case is the cmd window, which we try to keep at its
+ existing size.
+
+ However, in some cases it is not appropriate to keep the cmd window at
+ its existing size. I will describe two such cases here, in one, we
+ want the cmd window to reduce in size, and in the other, we want the
+ cmd window to grow in size.
+
+ Try these steps in a 80 columns, by 24 lines terminal:
+
+ (gdb) tui enable
+ (gdb) layout src
+ (gdb) winheight cmd 20
+ (gdb) layout split
+
+ You should see that the status window is missing from the new layout,
+ and that the cmd window has been placed over the border of the asm
+ window. The 'info win' output is:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ src 3 80 (has focus)
+ asm 3 80
+ status 1 80
+ cmd 20 80
+
+ Notice that gdb has assigned 27 lines of screen space, even with the
+ border overlap between the src and asm windows, this is still 2 lines
+ too many.
+
+ The problem here is that after switching layouts, gdb has forced the
+ cmd window to retain its 20 line height. Really, we want the cmd
+ window to reduce in height so that the src and asm windows can occupy
+ their minimum required space.
+
+ This commit allows this (details on how are below). After this
+ commit, in the above situation, we now see the status window displayed
+ correctly, and the 'info win' output is:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ src 3 80 (has focus)
+ asm 3 80
+ status 1 80
+ cmd 18 80
+
+ The cmd window has been reduced in size by 2 lines so that everything
+ can fit on the screen.
+
+ The second example is one which was discussed in a recent commit,
+ consider this case (still in the 80 column, 24 line terminal):
+
+ (gdb) tui enable
+ (gdb) tui new-layout conly cmd 1
+ (gdb) layout conly
+ (gdb) info win
+ Name Lines Columns Focus
+ cmd 8 80 (has focus)
+ (gdb)
+
+ This layout only contains a cmd window, which we would expect to
+ occupy the entire terminal. But instead, the cmd window only occupies
+ the first 8 lines, and the rest of the terminal is unused!
+
+ The reason is, again, that the cmd window is keeping its previous
+ size (8 lines).
+
+ After this commit things are slightly different, the 'info win' output
+ is now:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ cmd 20 80 (has focus)
+
+ Which is a little better, but why only 20 lines? Turns out there's
+ yet another bug hitting this case. That bug will be addressed in a
+ later commit, so, for now, we're accepting the 20 lines.
+
+ What this commit does is modify the phase of tui_layout_split::apply
+ that handles any left over space. Usually, in "Step 2", each
+ sub-layout has a size calculated. As the size is an integer, then,
+ when all sizes are calculated we may have some space left over.
+
+ This extra space is then distributed between all the windows fairly
+ until all the space is used up.
+
+ When we consider windows minimum size, or fixed size windows, then it
+ is possible that we might try to use more space than is available,
+ this was our first example above. The same code that added extra
+ space to the windows, can also be used to reclaim space (in the over
+ allocation case) to allow all windows to fit.
+
+ The problem then is the cmd window, which we often force to a fixed
+ size. Inside the loop that handles the allocation of excess space, if
+ we find that we have tried every window, and still have space either
+ left to give, or we need to claim back more space, then, if the cmd
+ window was changed to a fixed size, we can change the cmd window back
+ to a non-fixed-size window, and proceed to either give, or take space
+ from the cmd window as needed.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: fairer distribution of excess space during apply
+ When applying layouts gdb computes the size of each window (or rather,
+ each sub-layout within a layout) using integer arithmetic. As this
+ rounds down the results, then, when all sub-layouts are sized, there
+ is the possibility that we have some space left over.
+
+ Currently, this space is just assigned to an arbitrary sub-layout.
+
+ This can result in some unbalanced results. Consider this set of
+ steps with current master:
+
+ (gdb) tui enable
+ (gdb) layout regs
+ (gdb) info win
+ Name Lines Columns Focus
+ regs 7 80
+ src 9 80 (has focus)
+ status 1 80
+ cmd 8 80
+
+ Notice the weird split between the src and regs windows, the original
+ layout specification has these windows given equal weight. The
+ problem is that, with rounding, both the regs and src windows are
+ initially sized to 7, the extra 2 lines are then arbitrarily added to
+ the src window.
+
+ In this commit, rather than add all the extra space to one single
+ window, I instead hand out the extra space 1 line at a time, looping
+ over all the sub-layouts. We take care to respect the min/max sizes,
+ and so, we now get this result:
+
+ (gdb) tui enable
+ (gdb) layout regs
+ (gdb) info win
+ Name Lines Columns Focus
+ regs 8 80
+ src 8 80 (has focus)
+ status 1 80
+ cmd 8 80
+
+ This looks more natural to me.
+
+ This is obviously a change in behaviour, and so, lots of the existing
+ tests need to be updated to take this into account. None of the
+ changes are huge, it's just a line or two (or column for width) moved
+ between windows.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: avoid fp exception when applying layouts
+ Consider:
+
+ (gdb) tui enable
+ (gdb) layout src
+ (gdb) tui new-layout conly cmd 1
+ (gdb) layout conly
+
+ After this, with current master, gdb crashes with a floating-point
+ exception.
+
+ The problem is that in tui_layout_split::apply, when we switch from
+ 'src' to 'conly', we will try to retain the cmd window height. As
+ such, the cmd window will become a fixed size window, which decreases
+ the available_size, but doesn't count towards the total_weight.
+
+ As the cmd window is the only window, the total_weight stays at zero,
+ and, when we move into step 2, where we attempt to size the windows,
+ we perform a divide by zero, and crash.
+
+ After this commit we avoid the divide by zero, and just directly set
+ the window size based on the fixed size.
+
+ There is still a problem after this commit, when the conly layout is
+ selected the cmd window retains its original height, which will only
+ be part of the terminal. The rest of the terminal is left unused.
+ This issue will be addressed in a later commit, this commit is just
+ about the floating-point exception.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui/testsuite: refactor new-layout.exp test
+ This commit changes the gdb.tui/new-layout.exp test to make use of a
+ list of test descriptions, and a loop to check each description in
+ turn. There's no change to what is actually tested after this commit.
+
+ In future commits I plan to add additional tests to this file, and
+ this will be easier now that all I have to do is add a new test
+ description to the list.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: add left_boxed_p and right_boxed_p member functions
+ When I initially saw this code in tui_layout_split::apply, I assumed
+ that this must be a bug:
+
+ /* Two adjacent boxed windows will share a border, making a bit
+ more size available. */
+ if (i > 0
+ && m_splits[i - 1].layout->bottom_boxed_p ()
+ && m_splits[i].layout->top_boxed_p ())
+ ...
+
+ After all, the apply might be laying out a horizontal layout, right?
+ So checking bottom_boxed_p and top_boxed_p is clearly wrong.
+
+ Well, it turns on, that due to the implementations of these things,
+ bottom_boxed_p is equivalent to an imagined right_boxed_p, and
+ top_boxed_p is equivalent to an imagined left_boxed_p.
+
+ In this commit I've renamed both top_boxed_p and bottom_boxed_p to
+ first_edge_has_border_p and last_edge_has_border_p respectively, and
+ extended the comments in tui_layout_base to mention that these methods
+ handle both horizontal and vertical layouts.
+
+ Now, hopefully, the code shouldn't look like it only applies for
+ vertical layouts.
+
+ There should be no user visible changes after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: add a tui debugging flag
+ This commit adds 'set debug tui on|off' and 'show debug tui'. This
+ commit adds the control variable, and the printing macros in
+ tui/tui.h. I've then added some uses of these in tui.c and
+ tui-layout.c.
+
+ To help produce more useful debug output in tui-layout.c, I've added
+ some helper member functions in the class tui_layout_split, and also
+ moved the size_info struct out of tui_layout_split::apply into the
+ tui_layout_split class.
+
+ If tui debug is not turned on, then there should be no user visible
+ changes after this commit.
+
+ One thing to note is that, due to the way that the tui terminal is
+ often cleared, the only way I've found this useful is when I do:
+
+ (gdb) tui enable
+ (gdb) set logging file /path/to/file
+ (gdb) set logging debugredirect on
+ (gdb) set logging enable on
+
+ Additionally, gdb has some quirks when it comes to setting up logging
+ redirect and switching interpreters. Thus, the above only really
+ works if the logging is enabled after the tui is enabled, and disabled
+ again before the tui is disabled.
+
+ Enabling logging and switching interpreters can cause undefined
+ results, including crashes. This is an existing bug in gdb[1], and
+ has nothing directly to do with tui debug, but it is worth mentioning
+ here I think.
+
+ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28948
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: add new 'tui window width' command and 'winwidth' alias
+ This commit adds a new command 'tui window width', and an alias
+ 'winwidth'. This command is equivalent to the old 'winheight'
+ command (which was recently renamed 'tui window height').
+
+ Even though I recently moved the old tui commands under the tui
+ namespace, and I would strongly encourage all new tui commands to be
+ added as 'tui ....' only (users can create their own top-level aliases
+ if they want), I'm breaking that suggestion here, and adding a
+ 'winwidth' alias.
+
+ Given that we already have 'winheight' and have done for years, it
+ just didn't seem right to no have the matching 'winwidth'.
+
+ You might notice in the test that the window resizing doesn't quite
+ work right. I setup a horizontal layout, then grow and shrink the
+ windows. At the end of the test the windows should be back to their
+ original size...
+
+ ... they are not. This isn't my fault, honest! GDB's window resizing
+ is a little ... temperamental, and is prone to getting things slightly
+ wrong during resizes, off by 1 type things. This is true for height
+ resizing, as well as the new width resizing.
+
+ Later patches in this series will rework the resizing algorithm, which
+ should improve things in this area. For now, I'm happy that the width
+ resizing is as good as the height resizing, given the existing quirks.
+
+ For the docs side I include a paragraph that explains how multiple
+ windows are required before the width can be adjusted. For
+ completeness, I've added the same paragraph to the winheight
+ description. With the predefined layouts this extra paragraph is not
+ really needed for winheight, as there are always multiple windows on
+ the screen. However, with custom layouts, this might not be true, so
+ adding the paragraph seems like a good idea.
+
+ As for the changes in gdb itself, I've mostly just taken the existing
+ height adjustment code, changed the name to make it generic 'size'
+ adjustment, and added a boolean flag to indicate if we are adjusting
+ the width or the height.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: rename tui_layout_split:set_weights_from_heights
+ In a following commit I'm going to add the ability to change the width
+ of a tui window (when in a horizontal layout). As a result, some of
+ the places where we currently hard-code references to height need to
+ be changed to handle either height, or width, based on whether we are
+ in a vertical, or horizontal layout.
+
+ This commit renames set_weights_from_heights to
+ set_weights_from_sizes, and makes the function use either the height,
+ or width as appropriate.
+
+ Currently, the only place that we call this function is from the
+ tui_layout_split::set_height function, in a part of the code we will
+ only reach for vertical layouts, so the new code is not actually being
+ used, but, this small change will help make later patches smaller, so
+ I'm proposing this as a stand alone change.
+
+ There should be no user visible changes after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: rename tui_layout_base::adjust_size to ::set_height
+ Rename tui_layout_base::adjust_size to tui_layout_base::set_height,
+ the new name more accurately reflects what this member function does,
+ and makes it easier for a later commit to add a new
+ tui_layout_base::set_width member function.
+
+ There should be no user visible changes after this commit.
+
+2022-04-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: move some commands into the tui namespace
+ There are a lot of tui related commands that live in the top-level
+ command name space, e.g. layout, focus, refresh, winheight.
+
+ Having them at the top level means less typing for the user, which is
+ good, but, I think, makes command discovery harder.
+
+ In this commit, I propose moving all of the above mentioned commands
+ into the tui namespace, so 'layout' becomes 'tui layout', etc. But I
+ will then add aliases so that the old commands will still work,
+ e.g. I'll make 'layout' an alias for 'tui layout'.
+
+ The benefit I see in this work is that tui related commands can be
+ more easily discovered by typing 'tui ' and then tab-completing. Also
+ the "official" command is now a tui-sub-command, this is visible in,
+ for example, the help output, e.g.:
+
+ (gdb) help layout
+ tui layout, layout
+ Change the layout of windows.
+ Usage: tui layout prev | next | LAYOUT-NAME
+
+ List of tui layout subcommands:
+
+ tui layout asm -- Apply the "asm" layout.
+ tui layout next -- Apply the next TUI layout.
+ tui layout prev -- Apply the previous TUI layout.
+ tui layout regs -- Apply the TUI register layout.
+ tui layout split -- Apply the "split" layout.
+ tui layout src -- Apply the "src" layout.
+
+ Which I think is a good thing, it makes it clearer that this is a tui
+ command.
+
+ I've added a NEWS entry and updated the docs to mention the new and
+ old command names, with the new name being mentioned first.
+
+2022-04-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix gdb_print -> gdb_printf typo
+ This caused a build failure with !CXX_STD_THREAD.
+
+ Change-Id: I30f0c89c43a76f85c0db34809192644fa64a9d18
+
+2022-04-03 Alan Modra <amodra@gmail.com>
+
+ Move microblaze relax info to target specific data
+ Target specific data shouldn't be put in struct bfd_section.
+
+ * section.c (struct bfd_section): Delete relax and relax_count.
+ (BFD_FAKE_SECTION): Adjust to suit.
+ (struct relax_table): Move to..
+ * elf32-microblaze.c (struct relax_table): ..here.
+ (struct _microblaze_elf_section_data): New.
+ (microblaze_elf_section_data): Define.
+ (microblaze_elf_new_section_hook): New function.
+ (bfd_elf32_new_section_hook): Define.
+ (calc_fixup): Return a size_t. Adjust to suit new location of
+ relax and relax_count.
+ (microblaze_elf_relax_section): Adjust to suit new location of
+ relax and relax_count. Make some variables size_t.
+ * bfd-in2.h: Regenerate.
+
+2022-04-03 Alan Modra <amodra@gmail.com>
+
+ Revert commit 240d6706c6a2
+ PR 28592
+ PR 15994
+ PR 15935
+ * dwarf2.c (lookup_address_in_line_info_table): Return bool rather
+ than a range.
+ (comp_unit_find_nearest_line): Likewise. Return true if function
+ info found without line info.
+ (_bfd_dwarf2_find_nearest_line): Revert range handling code.
+
+ Regen bfd po/SRC-POTFILES.in
+
+2022-04-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-02 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: rename floatformats_ia64_quad to floatformats_ieee_quad
+ It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
+ to reflect the reality, and then we can clean up the related code.
+
+ As Tom Tromey said [1]:
+
+ These files are maintained in gcc and then imported into the
+ binutils-gdb repository, so any changes to them will have to
+ be proposed there first.
+
+ the related changes have been merged into gcc master now [2], it is time
+ to do it for gdb.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
+ [2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6
+
+2022-04-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-04-01 John Baldwin <jhb@FreeBSD.org>
+
+ Remove unused variable.
+
+2022-04-01 Aaron Merey <amerey@redhat.com>
+
+ gdb/debuginfod-support.c: Always display debuginfod errors
+ Errors encountered when downloading files from debuginfod servers
+ are not displayed if debuginfod verbosity is set to 0 (via
+ 'set debuginfod verbose 0').
+
+ Tom recommended that these errors always be displayed, regardless
+ of the verbosity setting [1]. Fix this.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html
+
+2022-04-01 John Baldwin <jhb@FreeBSD.org>
+
+ Use I386_GSBASE_REGNUM in i386fbsd_get_thread_local_address.
+ 32-bit x86 arches always the I386_*BASE_REGNUM values. Only code that
+ needs to support both 64-bit and 32-bit arches needs to use
+ tdep->fsbase_regnum to compute a segment base register number.
+
+ FreeBSD/x86: Read segment base registers from NT_X86_SEGBASES.
+ FreeBSD kernels recently grew a new register core dump note containing
+ the base addresses of the %fs and %gs segments (corresponding to the
+ %fsbase and %gsbase registers). Parse this note to permit inspecting
+ TLS variables in core dumps. Native processes already supported TLS
+ via older ptrace() operations.
+
+2022-04-01 John Baldwin <jhb@FreeBSD.org>
+
+ Use pseudosections for NT_FREEBSD_X86_SEGBASES core dump notes.
+ This includes adding pseudosections when reading a core dump as well
+ as support for writing out a core dump note from a pseudosection.
+
+ bfd/ChangeLog:
+
+ * elf-bfd.h (elfcore_write_x86_segbases): New.
+ * elf.c (elfcore_grok_freebsd_note): Add pseudosections for
+ NT_FREEBSD_X86_SEGBASES register notes.
+ (elfcore_write_x86_segbases): New.
+ (elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES
+ register notes.
+
+2022-04-01 John Baldwin <jhb@FreeBSD.org>
+
+ Recognize FreeBSD core dump note for x86 segment base registers.
+ This core dump note contains the value of the base address of the %fs
+ and %gs segments for both i386 and amd64 core dumps. It is primarily
+ useful in resolving the address of TLS variables in core dumps.
+
+ binutils/ChangeLog:
+
+ * readelf.c (get_freebsd_elfcore_note_type): Handle
+ NT_FREEBSD_X86_SEGBASES.
+
+ include/ChangeLog:
+
+ * elf/common.h (NT_FREEBSD_X86_SEGBASES): Define.
+
+2022-04-01 John Baldwin <jhb@FreeBSD.org>
+
+ elfcore_grok_freebsd_note: Remove checks of note->namesz.
+ This function is only called if the note name is "FreeBSD", so
+ checking the name size is unnecessary.
+
+ bfd/ChangeLog:
+
+ * elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.
+
+2022-04-01 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testing/tui: add new _csi_{L,S,T}
+ This patch was original part of this series:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
+
+ I've pulled this out as it might be useful ahead of the bigger series
+ being merged.
+
+ This commit adds:
+
+ _csi_L - insert line
+ _csi_S - pan down
+ _csi_T - pan up
+
+2022-04-01 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Remove bfd_arch_l1om and bfd_arch_k1om
+ Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been
+ removed from gas, ld and opcodes.
+
+ bfd/
+
+ * Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo.
+ (ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c.
+ * archures.c (bfd_mach_l1om): Removed.
+ (bfd_mach_l1om_intel_syntax): Likewise.
+ (bfd_mach_k1om): Likewise.
+ (bfd_mach_k1om_intel_syntax): Likewise.
+ (bfd_k1om_arch): Likewise.
+ (bfd_l1om_arch): Likewise.
+ (bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch
+ references.
+ * config.bfd (targ_selvecs): Remove l1om_elf64_vec.
+ l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec.
+ (targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch.
+ * configure.ac (k1om_elf64_vec): Removed.
+ (k1om_elf64_fbsd_vec): Likewise.
+ (l1om_elf64_vec): Likewise.
+ (l1om_elf64_fbsd_vec): Likewise.
+ * cpu-k1om.c: Removed.
+ * cpu-l1om.c: Likewise.
+ * elf64-x86-64.c (elf64_l1om_elf_object_p): Removed.
+ (elf64_k1om_elf_object_p): Likewise.
+ (l1om_elf64_vec): Removed.
+ (l1om_elf64_fbsd_vec): Likewise.
+ (k1om_elf64_vec): Likewise.
+ (k1om_elf64_fbsd_vec): Likewise.
+ (ELF_TARGET_OS): Undefine.
+ * targets.c (_bfd_target_vector): Remove k1om_elf64_vec,
+ k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Likewise.
+ * configure: Likewise.
+
+ opcodes/
+
+ * configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references.
+ * disassemble.c (disassembler): Likewise.
+ * configure: Regenerate.
+
+2022-04-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/ctf: pass partial symtab's filename to buildsym_compunit
+ I noticed that the CTF symbol reader passes the objfile's name to all
+ buildsym_compunit instances it creates. The result is that all
+ compunit_symtabs created have the same name, that of the objfile:
+
+ { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
+ { ((struct compunit_symtab *) 0x621000286760)
+ debugformat ctf
+ producer (null)
+ name libbabeltrace2.so.0.0.0
+ dirname (null)
+ blockvector ((struct blockvector *) 0x6210003911d0)
+ user ((struct compunit_symtab *) (null))
+ { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+ { ((struct compunit_symtab *) 0x621000275c10)
+ debugformat ctf
+ producer (null)
+ name libbabeltrace2.so.0.0.0
+ dirname (null)
+ blockvector ((struct blockvector *) 0x621000286710)
+ user ((struct compunit_symtab *) (null))
+ { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+
+ Notice the two "name libbabeltrace2.so.0.0.0".
+
+ Change it to pass the partial_symtab's filename instead. The output
+ becomes:
+
+ { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
+ { ((struct compunit_symtab *) 0x621000295610)
+ debugformat ctf
+ producer (null)
+ name libbabeltrace2.so.0.0.0
+ dirname (null)
+ blockvector ((struct blockvector *) 0x6210003a15d0)
+ user ((struct compunit_symtab *) (null))
+ { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+ { ((struct compunit_symtab *) 0x621000288700)
+ debugformat ctf
+ producer (null)
+ name current-thread.c
+ dirname (null)
+ blockvector ((struct blockvector *) 0x6210002955c0)
+ user ((struct compunit_symtab *) (null))
+ { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+
+ Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
+ its name. This is because the CTF symbol reader really creates a
+ partial symtab named like this. It appears to be because the debug info
+ contains information that has been factored out of all CUs and is at the
+ "top-level" of the objfile, outside any real CU. So it creates a
+ partial symtab and an artificial CU that's named after the objfile.
+
+ Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
+
+2022-04-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: print compunit_symtab name in "maint info symtabs"
+ I think it would make sense to print a compunit_symtab's name in "maint
+ info symtabs". If you are looking for a given CU in the list, that's
+ probably the field you will be looking at. As the doc of
+ compunit_symtab::name says, it is not meant to be a reliable file name,
+ it is for debugging purposes (and "maint info symtabs" exists for
+ debugging purposes).
+
+ Sample output with the new field:
+
+ (gdb) maintenance info symtabs
+ { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
+ { ((struct compunit_symtab *) 0x621000131630)
+ debugformat DWARF 5
+ producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
+ name test.c
+ dirname /home/simark/build/binutils-gdb-one-target/gdb
+ blockvector ((struct blockvector *) 0x621000131d10)
+ user ((struct compunit_symtab *) (null))
+ { symtab test.c ((struct symtab *) 0x6210001316b0)
+ fullname (null)
+ linetable ((struct linetable *) 0x621000131d40)
+ }
+ { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+ { ((struct compunit_symtab *) 0x6210001170a0)
+ debugformat DWARF 5
+ producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
+ name foo.c
+ dirname /home/simark/build/binutils-gdb-one-target/gdb
+ blockvector ((struct blockvector *) 0x621000131580)
+ user ((struct compunit_symtab *) (null))
+ { symtab foo.c ((struct symtab *) 0x621000117120)
+ fullname (null)
+ linetable ((struct linetable *) 0x6210001315b0)
+ }
+ { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150)
+ fullname (null)
+ linetable ((struct linetable *) 0x0)
+ }
+ }
+ }
+
+ Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
+
+2022-04-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/ctf: don't create a buildsym_compunit when building partial symbols
+ I am trying to do some changes to buildsym_compunit, so I am auditing
+ the current uses. Something seems odd with this use of
+ buildsym_compunit (that this patch removes).
+
+ A buildsym_compunit is normally used when building a compunit_symtab.
+ That is, when expanding a partial symtab into a full compunit symtab.
+ In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
+ is only used when creating partial symtabs. At this moment, I don't
+ see how that's useful. ctf_start_archive creates a new
+ buildsym_compunit and starts a subfile. But that buildsym_compunit is
+ never used again. It's just overriden in ctf_start_symtab, which means
+ we leak the old buildsym_compunit, I suppose.
+
+ Remove ctf_start_archive completely. Add an assert in
+ ctf_start_symtab to verify that we are not overwriting an existing
+ buildsym_compunit (meaning we'd leak the existing one). This assert
+ triggers without the other part of the fix. When doing:
+
+ $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+ ...
+ (gdb) maintenance expand-symtabs
+ /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.
+
+ Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
+
+2022-04-01 Tom Tromey <tom@tromey.com>
+
+ Style URLs in GDB output
+ I noticed that GDB will display URLs in a few spots. This changes
+ them to be styled. Originally I thought I'd introduce a new "url"
+ style, but there aren't many places to use this, so I just reused
+ filename styling instead. This patch also changes the debuginfod URL
+ list to be printed one URL per line. I think this is probably a bit
+ easier to read.
+
+2022-04-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: initialize ctf_context::builder in create_partial_symtab
+ I built a random project with -gctf, in order to test the CTF support in
+ GDB. With my ASan/UBSan/etc-enabled build of GDB, I get:
+
+ $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+ ...
+ Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
+ /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
+ 0xbebebebebebebebe: note: pointer points here
+
+ The 0xbebebebebebebebe value is a sign that the ctf_context::builder
+ field is uninitialized. The problem probably goes under the radar if
+ the field happens to be zero-initialized, because ctf_start_archive
+ contains this code:
+
+ if (ccx->builder == nullptr)
+ {
+ ccx->builder = new buildsym_compunit (of,
+ of->original_name, nullptr, language_c, 0);
+
+ If the field was zero-initialized (by chance), this will create a new
+ buildsym_compunit. But if the field was purposely filled with random
+ bytes by one of the sanitizers, we won't create a buildsym_compunit here
+ and we'll continue with ccx->builder equal to 0xbebebebebebebebe.
+
+ Fix this the easy way by initializing ccx->builder where the other
+ ctf_context fields are initialized (yeah, this code could be made nicer
+ C++, but I am going for the obvious fix here).
+
+ With this patch, this passes cleanly on my system:
+
+ $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
+ # of expected passes 40
+
+ ... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
+ system gcc does not have it.
+
+ Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
+
+2022-03-31 Tom Tromey <tromey@adacore.com>
+
+ Remove dbx mode
+ This patch removes gdb's dbx mode. Regression tested on x86-64 Fedora
+ 34.
+
+2022-03-31 H.J. Lu <hjl.tools@gmail.com>
+
+ gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml
+ 1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
+ them into a single keys.xml.
+ 2. Enable PKU for x32 to fix:
+
+ $ gdbserver :123456 x32-program
+ ...
+ .../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
+ .
+ Unknown register pkru requested
+
+ on Tiger Lake.
+
+2022-03-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
+ The check removed by this patch, using current_inferior, looks wrong.
+ When debugging multiple inferiors with the Linux native target and
+ linux_handle_extended_wait is called, there's no guarantee about which
+ is the current inferior. The vfork-done event we receive could be for
+ any inferior. If the vfork-done event is for a non-current inferior, we
+ end up wrongfully ignoring it. As a result, the core never processes a
+ TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
+ is never cleared, and breakpoints are never reinserted. However,
+ because the Linux native target decided to ignore the event, it resumed
+ the thread - while breakpoints out. And that's bad.
+
+ The proposed fix is to remove this check. Always report vfork-done
+ events and let infrun's logic decide if it should be ignored. We don't
+ save much cycles by filtering the event here.
+
+ Add a test that replicates the situation described above. See comments
+ in the test for more details.
+
+ Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
+
+2022-03-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver/linux: set lwp !stopped when failing to resume
+ I see some failures, at least in gdb.multi/multi-re-run.exp and
+ gdb.threads/interrupted-hand-call.exp. Running `stress -C $(nproc)` at
+ the same time as the test makes those tests relatively frequent.
+
+ Let's take gdb.multi/multi-re-run.exp as an example. The failure looks
+ like this, an unexpected "no resumed":
+
+ continue
+ Continuing.
+ No unwaited-for children left.
+ (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit
+
+ The situation is:
+
+ - Inferior 1 is stopped somewhere, it won't really play a role here.
+ - Inferior 2 has 2 threads, both stopped.
+ - We resume inferior 2, the leader thread is expected to exit, making
+ the process exit.
+
+ From GDB's perspective, a failing run looks like this:
+
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] do_target_wait: Found 2 inferiors, starting at #1
+ [infrun] random_pending_event_thread: None found.
+ [remote] wait: enter
+ [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e;
+ [remote] wait: exit
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 713933.713933.0 [Thread 713933.713933],
+ [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+ [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+ [infrun] clear_step_over_info: clearing step over info
+ [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
+ [infrun] handle_signal_stop: stop_pc=0x555555555195
+ [infrun] start_step_over: enter
+ [infrun] start_step_over: stealing global queue of threads to step, length = 0
+ [infrun] operator(): step-over queue now empty
+ [infrun] start_step_over: exit
+ [infrun] process_event_stop_test: no stepping, continue
+ [remote] Sending packet: $Z0,555555555194,1#8e
+ [remote] Packet received: OK
+ [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
+ [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
+ [remote] Packet received: OK
+ [remote] Sending packet: $vCont;c:pae4cd.-1#9f
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+ [infrun] fetch_inferior_event: exit
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] do_target_wait: Found 2 inferiors, starting at #0
+ [infrun] random_pending_event_thread: None found.
+ [remote] wait: enter
+ [remote] Packet received: N
+ [remote] wait: exit
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: -1.0.0 [process -1],
+ [infrun] print_target_wait_results: status->kind = NO_RESUMED
+ [infrun] handle_inferior_event: status->kind = NO_RESUMED
+ [remote] Sending packet: $Hgp0.0#ad
+ [remote] Packet received: OK
+ [remote] Sending packet: $qXfer:threads:read::0,1000#92
+ [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
+ [infrun] stop_waiting: stop_waiting
+ [remote] Sending packet: $qXfer:threads:read::0,1000#92
+ [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
+ [infrun] infrun_async: enable=0
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+ [infrun] fetch_inferior_event: exit
+
+ We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
+ When the test passes, we get an EXITED status to indicate the process
+ has exited.
+
+ From GDBserver's point of view, it looks like this. The logs contain
+ some logging I added and that are part of this patch.
+
+ [remote] getpkt: getpkt ("vCont;c:pae4cf.-1"); [no ack sent]
+ [threads] resume: enter
+ [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
+ [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
+ [threads] get_pc: pc is 0x555555555195
+ [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
+ [threads] get_pc: pc is 0x7ffff7d35a95
+ [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
+ [threads] resume: Resuming, no pending status or step over needed
+ [threads] resume_one_thread: resuming LWP 713935
+ [threads] proceed_one_lwp: lwp 713935
+ [threads] resume_one_lwp_throw: continue from pc 0x555555555195
+ [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
+ [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
+ [threads] resume_one_thread: resuming LWP 713936
+ [threads] proceed_one_lwp: lwp 713936
+ [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
+ [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
+ [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+ [threads] resume: exit
+ [threads] wait_1: enter
+ [threads] wait_1: [<all threads>]
+ [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+ [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0
+ [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
+ [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
+ [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+ [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
+ [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
+ [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
+ [threads] delete_lwp: deleting 713935
+ [threads] wait_for_event_filtered: exit (no unwaited-for LWP)
+ sigchld_handler
+ [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
+ [threads] wait_1: exit
+
+ What happens is:
+
+ - We resume the leader (713935) successfully.
+ - The leader exits.
+ - We resume the secondary thread (713936), we get ESRCH. This is
+ expected this the leader has exited.
+ - resume_one_lwp_throw throws, it's caught by resume_one_lwp.
+ - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
+ failure can be explained by the LWP becoming zombie, and swallows the
+ error.
+ - Note that this means that the secondary lwp still has stopped==1.
+ - wait_1 is called, probably because linux_process_target::resume marks
+ the async pipe at the end.
+ - The exit event isn't ready yet, probably because the machine is under
+ load, so waitpid returns nothing.
+ - check_zombie_leaders detects that the leader is zombie and deletes
+ - We try to find a resumed (non-stopped) LWP to get an event from,
+ there's none since the leader (that was resumed) is now deleted, and
+ the secondary thread is still marked stopped.
+ wait_for_event_filtered returns -1, causing wait_1 to return
+ NO_RESUMED.
+
+ What I notice here is that there is some kind of race between the
+ availability of the process' exit notification and the call to wait_1
+ that results from marking the async pipe at the end of resume.
+
+ I think what we want from this wait_1 invocation is to keep waiting, as
+ we will eventually get thread exit notifications for both of our
+ threads.
+
+ The fix I came up with is to mark the secondary thread as !stopped (or
+ resumed) when we fail to resume it. This makes wait_1 see that there is
+ at least one resume lwp, so it won't return NO_RESUMED. I think this
+ makes sense to consider it resumed, because we are going to receive an
+ exit event for it. Here's the GDBserver logs with the fix applied:
+
+ [threads] resume: enter
+ [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
+ [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
+ [threads] get_pc: pc is 0x555555555195
+ [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
+ [threads] get_pc: pc is 0x7ffff7d35a95
+ [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
+ [threads] resume: Resuming, no pending status or step over needed
+ [threads] resume_one_thread: resuming LWP 724597
+ [threads] proceed_one_lwp: lwp 724597
+ [threads] resume_one_lwp_throw: continue from pc 0x555555555195
+ [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
+ [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
+ [threads] resume_one_thread: resuming LWP 724598
+ [threads] proceed_one_lwp: lwp 724598
+ [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
+ [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
+ [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+ [threads] resume: exit
+ [threads] wait_1: enter
+ [threads] wait_1: [<all threads>]
+ sigchld_handler
+ [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+ [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
+ [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
+ [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
+ [threads] delete_lwp: deleting 724597
+ [threads] wait_for_event_filtered: sigsuspend'ing
+ sigchld_handler
+ [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
+ [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
+ [threads] filter_event: 724598 exited
+ [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
+ [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
+ [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+ sigchld_handler
+ [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
+ [threads] wait_1: exit
+
+ Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
+
+2022-03-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite/tui: implement _csi_P proc
+ Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these
+ errors when running gdb.tui/scroll.exp:
+
+ ERROR: invalid command name "_csi_P"
+ while executing
+ "::gdb_tcl_unknown _csi_P 2"
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel 1 ::gdb_tcl_unknown $args"
+ (procedure "::unknown" line 5)
+ invoked from within
+ "_csi_P 2"
+ ("eval" body line 1)
+ invoked from within
+ "eval _csi_$cmd $params"
+
+ It looks like GDB is emitting a CSI that it did not emit before, the
+ "Delete character" one:
+
+ https://vt100.net/docs/vt510-rm/DCH.html
+
+ Implement it.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
+
+2022-03-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix use of fprintf_filtered in top.c
+ A race condition in how patches were pushed causes this build failure:
+
+ CXX top.o
+ /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’:
+ /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’?
+ 1622 | fprintf_filtered (stream, _("\
+ | ^~~~~~~~~~~~~~~~
+
+ fprintf_filtered has been removed, gdb_printf must be used now. Fix
+ this.
+
+ Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b
+
+2022-03-31 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Relax check for RNG system registers
+ FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
+ to earlier architectures as well. GAS previously made the RNG registers
+ conditional on having both armv8.5-a and +rng, but only +rng should be
+ required.
+
+ This seems to be the only feature that was handled like this.
+
+ opcodes/
+ * aarch64-opc.c (SR_RNG): Don't require V8_5.
+
+ gas/
+ * testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
+ test.
+
+2022-03-31 Eli Zaretskii <eliz@gnu.org>
+
+ * gdb/top.c (print_gdb_configuration): Announce --enable-threading.
+ This includes the reporting of --enable/disable-threading as part of
+ the GDB configuration description.
+
+2022-03-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/infrun: add reason parameter to stop_all_threads
+ Add a "reason" parameter, only used to show in debug messages what is
+ the reason for stopping all threads. This helped me understand the
+ debug logs while adding some new uses of stop_all_threads, so I am
+ proposing to merge it.
+
+ Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55
+
+2022-03-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*
+ I forgot to do this before pushing the previous commit.
+
+ Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805
+
+2022-03-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off
+ The particular behavior we have when using that combination of settings
+ doesn't seem tested at all (at least, I don't find it if I grep for "Can
+ not resume the parent process"). Add a simple test for that.
+
+ Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5
+
+2022-03-31 Nick Clifton <nickc@redhat.com>
+
+ Accept the + character as part of filenames for MRI scripts.
+
+2022-03-31 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Fix procfs.c compilation
+ procfs.c doesn't compile on Solaris:
+
+ /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
+ /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
+ 3302 | gdb_argv built_argv (args);
+ | ^~~~~~~~
+ /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
+ 3303 | for (char *arg : built_argv)
+ | ^~~~~~~~~~
+ | buildargv
+
+ Fixed by including "gdbsupport/buildargv.h".
+
+ Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
+
+2022-03-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: add tests for Term
+ While trying to review Andrew's patch here [1], I thought I spotted a
+ bug in the handling of a CSI, but I had no way to know for sure. So I
+ thought it would be useful to have unit tests for the handling of
+ control characters and control sequences of our toy terminal
+ implementation. It might help avoid chasing bugs in the GDB TUI when in
+ reality it's a problem with the testsuite's terminal implementation.
+
+ Add the gdb.tui/tuiterm.exp file to do that. All currently supported
+ control sequences and characters are tested, except _csi_m (the one that
+ handles colors and stuff). _csi_m should probably be tested too, but it
+ will require more work.
+
+ Fix a few issues that the tests spotted:
+
+ - backspace: according to [3] (table 4-1), a backspace when the cursor
+ is at the beginning of a line should have no effect. Our
+ implementation did wrap to the end of the previous line. Change our
+ implementation to match the doc (and the test).
+ - insert character: this control sequence is supposed to insert blank
+ characters, shifting all the rest of the line right. The current
+ implementation moves N characters right, but it overwrites the
+ characters on the right instead of shifting them. It also doesn't
+ insert blank characters at the cursor.
+ - Cursor down, forward, next line: off-by-one error when reaching the
+ end of the display.
+ - erase in display, line: off-by-one errors.
+ - vertical line position absolute: allowed setting the cursor outside
+ the display, when it should clamp it to the display size.
+
+ I found that this web page [2] gave some good clues on the expected
+ behavior of some control characters or sequences that some other pages
+ didn't.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
+ [2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
+ [3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3
+
+ Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
+
+2022-03-30 Tom Tromey <tom@tromey.com>
+
+ Only allow QUIT on the main thread
+ Pedro pointed out that gdb worker threads should not react to quits.
+ While I don't think that the new DWARF reader can call QUIT from a
+ worker thread (and I don't think the existing minsym threading code
+ can either), it seems safest to address this before checking in the
+ new code. This patch arranges for the QUIT macro to only work on the
+ main thread.
+
+2022-03-30 Tom Tromey <tromey@adacore.com>
+
+ Use gdb_printf and gdb_vprintf in more places
+ Luis pointed out that I missed a spot in the gdb_printf conversion --
+ namely aarch64-nat.c. While looking at this, I found another spot in
+ darwin-nat.c that I also missed. I can't build either of these, but I
+ think this patch should fix the problems.
+
+ Consolidate definition of current_directory
+ I noticed that both gdbserver and gdb define current_directory.
+ However, as it is referenced by gdbsupport, it seemed better to define
+ it there as well. This patch also moves the declaration to
+ pathstuff.h. Tested by rebuilding.
+
+2022-03-30 Tom Tromey <tromey@adacore.com>
+
+ Decode "dynamic" interface types in Ada
+ In Ada, if a class implements an interface and has a dynamic
+ superclass, then the "offset to top" -- the offset that says how to
+ turn a pointer to the interface into a pointer to the whole object --
+ is stored in the object itself. This patch changes GDB to understand
+ this.
+
+ Because this only touches Ada code, and because Joel already reviewed
+ it internally, I am checking it in.
+
+2022-03-30 Jeff Law <jeffreyalaw@gmail.com>
+
+ Fix for MUL instruction on the v850
+ * sim/v850/simops.c (Multiply64): Properly test if we need to
+ negate either of the operands.
+
+ * sim/testsuite/v850/mul.cgs: New test.
+
+2022-03-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Remove two unused hooks
+ I noticed that a couple of deprecated hooks aren't ever called, so
+ they can't really be used by Insight. This patch removes them
+ entirely. I checked the Insight sources, and these aren't mentioned
+ there, either.
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Remove unnecessary calls to wrap_here and gdb_flush
+ Various spots in gdb currently know about the wrap buffer, and so are
+ careful to call wrap_here to be certain that all output has been
+ flushed.
+
+ Now that the pager is just an ordinary stream, this isn't needed, and
+ a simple call to gdb_flush is enough.
+
+ Similarly, there are places where gdb prints to gdb_stderr, but first
+ flushes gdb_stdout. stderr_file already flushes gdb_stdout, so these
+ aren't needed.
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Minor comment updates in utils.h
+ This patch updates some comments in utils.h to more closely reflect
+ the new reality.
+
+ Remove vfprintf_styled
+ Nothing calls vfprintf_styled any more, so remove it.
+
+ Remove ui_out_flag::unfiltered_output
+ There is no longer any need for ui_out_flag::unfiltered_output --
+ nothing ever sets this flag. This used to be needed to make the
+ _unfiltered output work, but now only printf_unfiltered can be used,
+ and it uses the puts_unfiltered method. This patch removes the flag
+ and the dead code.
+
+ Rename fprintf_symbol_filtered
+ fprintf_symbol_filtered is misnamed, because whether filtering happens
+ is now up to the stream. This renames it to fprintf_symbol, which
+ isn't a great name (the first "f" doesn't mean much and the second one
+ is truly meaningless here), but "print_symbol" was already taken.
+
+ Rename puts_filtered_tabular
+ puts_filtered_tabular is now misnamed, because whether filtering
+ happens is now up to the stream. So, rename it. (This function is
+ pretty weird, and should probably be rewritten to avoid using the
+ chars_printed global, and moved into objc-lang.c. However, I haven't
+ done so.)
+
+ Rename print_spaces_filtered
+ print_spaces_filtered is now misnamed, because whether filtering
+ happens is up to the stream. So, rename it.
+
+ Unify gdb printf functions
+ Now that filtered and unfiltered output can be treated identically, we
+ can unify the printf family of functions. This is done under the name
+ "gdb_printf". Most of this patch was written by script.
+
+ Unify gdb putc functions
+ Now that filtered and unfiltered output can be treated identically, we
+ can unify the putc family of functions. This is done under the name
+ "gdb_putc". Most of this patch was written by script.
+
+ Unify gdb puts functions
+ Now that filtered and unfiltered output can be treated identically, we
+ can unify the puts family of functions. This is done under the name
+ "gdb_puts". Most of this patch was written by script.
+
+ Unify vprintf functions
+ Now that filtered and unfiltered output can be treated identically, we
+ can unify the vprintf family of functions: vprintf_filtered,
+ vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For
+ the gdb_stdout variants, recall that only printf_unfiltered gets truly
+ unfiltered output at this point.) This removes one such function and
+ renames the remaining two to "gdb_vprintf". All callers are updated.
+ Much of this patch was written by script.
+
+ Remove fputs_styled_unfiltered
+ fputs_styled_unfiltered is only called from cli_ui_out, so remove it.
+ This area will be further simplified in future patches.
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Change the pager to a ui_file
+ This rewrites the output pager as a ui_file implementation.
+
+ A new header is introduced to declare the pager class. The
+ implementation remains in utils.c for the time being, because there
+ are some static globals there that must be used by this code. (This
+ could be cleaned up at some future date.)
+
+ I went through all the text output in gdb to ensure that this change
+ should be ok. There are a few cases:
+
+ * Any existing call to printf_unfiltered is required to be avoid the
+ pager. This is ensured directly in the implementation.
+
+ * All remaining calls to the f*_unfiltered functions -- the ones that
+ take an explicit ui_file -- either send to an unfiltered stream
+ (e.g., gdb_stderr), which is obviously ok; or conditionally send to
+ gdb_stdout
+
+ I investigated all such calls by searching for:
+
+ grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr
+
+ This yields a number of candidates to check.
+
+ * The breakpoint _print_recreate family, and
+ save_trace_state_variables. These are used for "save" commands
+ and so are fine.
+
+ * Things printing to a temporary stream. Obviously ok.
+
+ * Disassembly selftests.
+
+ * print_gdb_help - this is non-obvious, but ok because paging isn't
+ yet enabled at this point during startup.
+
+ * serial.c - doens't use gdb_stdout
+
+ * The code in compile/. This is all printing to a file.
+
+ * DWARF DIE dumping - doesn't reference gdb_stdout.
+
+ * Calls to the _filtered form -- these are all clearly ok, because if
+ they are using gdb_stdout, then filtering will still apply; and if
+ not, then filtering never applied and still will not.
+
+ Therefore, at this point, there is no longer any distinction between
+ all the other _filtered and _unfiltered calls, and they can be
+ unified.
+
+ In this patch, take special note of the vfprintf_maybe_filtered and
+ ui_file::vprintf change. This is one instance of the above idea,
+ erasing the distinction between filtered and unfiltered -- in this
+ part of the change, the "unfiltered_output" flag is never passe to
+ cli_ui_out. Subsequent patches will go much further in this
+ direction.
+
+ Also note the can_emit_style_escape changes in ui-file.c. Checking
+ against gdb_stdout or gdb_stderr was always a bit of a hack; and now
+ it is no longer needed, because this is decision can be more fully
+ delegated to the particular ui_file implementation.
+
+ ui_file::can_page is removed, because this patch removed the only call
+ to it.
+
+ I think this is the main part of fixing PR cli/7234.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7234
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Remove vfprintf_styled_no_gdbfmt
+ This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point
+ of call.
+
+ Add style-escape methods to ui_file
+ This adds emit_style_escape and reset_style methods to ui_file. These
+ aren't used yet, but they will be once the pager is converted to be a
+ ui_file subclass.
+
+ Add puts_unfiltered method to ui_file
+ When the pager is rewritten as a ui_file, gdb will still need a way to
+ bypass the filtering. After examining a few approaches, I chose this
+ patch, which adds a puts_unfiltered method to ui_file. For most
+ implementations of ui_file, this will just delegate to puts. This
+ patch also switches printf_unfiltered to use the new method.
+
+ Only have one API for unfiltered output
+ At the end of this series, the use of unfiltered output will be very
+ restricted -- only places that definitely need it will use it. To
+ this end, I thought it would be good to reduce the number of
+ _unfiltered APIs that are exposed. This patch changes gdb so that
+ only printf_unfiltered exists. (After this patch, the f* variants
+ still exist as well, but those will be removed later.)
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Remove some uses of printf_unfiltered
+ A number of spots call printf_unfiltered only because they are in code
+ that should not be interrupted by the pager. However, I believe these
+ cases are all handled by infrun's blanket ban on paging, and so can be
+ converted to the default (_filtered) API.
+
+ After this patch, I think all the remaining _unfiltered calls are ones
+ that really ought to be. A few -- namely in complete_command -- could
+ be replaced by a scoped assignment to pagination_enabled, but for the
+ remainder, the code seems simple enough like this.
+
+2022-03-29 Tom Tromey <tom@tromey.com>
+
+ Use unfiltered output in annotate.c
+ It seems to me that annotations should not be filtered. While it
+ might be weird for an annotation-based UI to use the pager, it's not,
+ I think, out of the question. This patch makes this change.
+
+2022-03-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+ Aleksandar Paunovic <aleksandar.paunovic@intel.com>
+
+ gdb/remote: use current_inferior in read_ptid if multi-process not supported
+ When parsing the ptid out of a reply package, if the multi-process
+ extensions are not supported, use current_inferior's pid as the pid of
+ the reported thread, instead of inferior_ptid. This is needed because
+ the inferior_ptid may be null_ptid although a legit context exists,
+ due to a prior context switch via switch_to_inferior_no_thread.
+
+ Below is a scenario that illustrates what could go wrong. First,
+ setup a multi-target scenario. This is needed, because in a
+ multi-target setting, the inferior_ptid is cleared out before waiting
+ on targets. The second inferior below sits on top of a remote target.
+ Multi-process packets are disabled.
+
+ $ # First, spawn a process with PID 26253 to attach to later.
+ $ gdb-up a.out
+ Reading symbols from a.out...
+ (gdb) maint set target-non-stop on
+ (gdb) set remote multiprocess-feature-packet off
+ (gdb) start
+ ...
+ (gdb) add-inferior -no-connection
+ [New inferior 2]
+ Added inferior 2
+ (gdb) inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) target extended-remote | gdbserver --multi -
+ Remote debugging using | gdbserver --multi -
+ Remote debugging using stdio
+ (gdb) attach 26253
+ Attaching to Remote target
+ Attached; pid = 26253
+ [New Thread 26253]
+ [New inferior 3]
+ Reading /tmp/a.out from remote target...
+ ...
+ [New Thread 26253]
+ ...
+ Reading /usr/local/lib/debug/....debug from remote target...
+ >>> GDB seems to hang here.
+
+ After attaching to a process and reading some library files, GDB
+ seems to hang. One interesting thing to note is that
+
+ [New Thread 26253]
+
+ appears twice. We also see
+
+ [New inferior 3]
+
+ Running the same scenario with "debug infrun on" reveals more details.
+
+ ...
+ (gdb) attach 26253
+ [infrun] scoped_disable_commit_resumed: reason=attaching
+ Attaching to Remote target
+ Attached; pid = 26253
+ [New Thread 26253]
+ [infrun] infrun_async: enable=1
+ [infrun] attach_command: immediately after attach:
+ [infrun] attach_command: thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING
+ [infrun] clear_proceed_status_thread: 26253.26253.0
+ [infrun] reset: reason=attaching
+ [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] do_target_wait: Found 2 inferiors, starting at #1
+ [infrun] random_pending_event_thread: None found.
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+ [infrun] print_target_wait_results: 26253.26253.0 [Thread 26253],
+ [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_0
+ [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0
+ [infrun] start_step_over: enter
+ [infrun] start_step_over: stealing global queue of threads to step, length = 0
+ [infrun] operator(): step-over queue now empty
+ [infrun] start_step_over: exit
+ [infrun] context_switch: Switching context from 0.0.0 to 26253.26253.0
+ [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151
+ [infrun] stop_waiting: stop_waiting
+ [infrun] stop_all_threads: starting
+ [infrun] stop_all_threads: pass=0, iterations=0
+ [New inferior 3]
+ Reading /tmp/a.out from remote target...
+ warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+ Reading /tmp/a.out from remote target...
+ Reading symbols from target:/tmp/a.out...
+ [New Thread 26253]
+ [infrun] stop_all_threads: 4723.4723.0 not executing
+ [infrun] stop_all_threads: 26253.26253.0 not executing
+ [infrun] stop_all_threads: 42000.26253.0 executing, need stop
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+ [infrun] print_target_wait_results: -1.0.0 [Thread 0],
+ [infrun] print_target_wait_results: status->kind = IGNORE
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+ [infrun] print_target_wait_results: -1.0.0 [Thread 0],
+ [infrun] print_target_wait_results: status->kind = IGNORE
+
+ GDB tried to stop Thread 42000.26253.0, which does not exist, and we
+ are waiting for a stop event that will never happen. The PID in
+ '42000.26253.0', namely 42000, is the PID of magic_null_ptid.
+ It comes from gdb/remote.c:read_ptid:
+
+ /* Since the stub is not sending a process id, then default to
+ what's in inferior_ptid, unless it's null at this point. If so,
+ then since there's no way to know the pid of the reported
+ threads, use the magic number. */
+ if (inferior_ptid == null_ptid)
+ pid = magic_null_ptid.pid ();
+ else
+ pid = inferior_ptid.pid ();
+
+ if (obuf)
+ *obuf = pp;
+ return ptid_t (pid, tid);
+
+ Because multi-process was turned off, GDB did not parse an explicitly
+ specified PID. Furthermore, inferior_ptid == null_ptid, and
+ eventually GDB picked the PID from magic_null_ptid.
+
+ If target-non-stop is not turned on at the beginning, the same bug
+ reveals itself as a duplicated thread as shown below.
+
+ # Same setup as above, without 'maint set target-non-stop on'.
+ ...
+ (gdb) attach 26253
+ Attaching to Remote target
+ Attached; pid = 26253
+ [New inferior 3]
+ ...
+ [New Thread 26253]
+ ...
+ (gdb) info threads
+ Id Target Id Frame
+ 1.1 process 13517 "a.out" main () at test.c:3
+ * 2.1 Thread 26253 "a.out" 0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6
+ 3.1 Thread 26253 "a.out" Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+ (gdb)
+
+ Fix the problem by preferring current_inferior()'s pid instead of
+ magic_null_ptid.
+
+ Regression-tested on X86-64 Linux.
+
+2022-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix test failure when building against readline v7
+ The test added in the commit:
+
+ commit a6b413d24ccc5d76179bab866834e11fd6fec294
+ Date: Fri Mar 11 14:44:03 2022 +0000
+
+ gdb: work around prompt corruption caused by bracketed-paste-mode
+
+ Was not written with readline 7 in mind, only readline 8+. Between
+ readline 7 and 8 the escape sequence used to disable bracketed paste
+ mode changed, an additional '\r' character was added to the end. In
+ fact, it was the addition of this '\r' character that triggered the
+ issue for which the above commit is part of the solution.
+
+ Anyway, the test tries to spot the case where the output from GDB is
+ not perfect, but does have the above work around applied. However,
+ the pattern in the test assumes that the problematic '\r' will be
+ present, and this is only true for readline 8+. With readline 7 the
+ test was failing.
+
+ In this commit I generalise the pattern a little so that the test will
+ still KFAIL with readline 7.
+
+ It's a little unfortunate that the test is KFAILing with readline 7,
+ as without the problematic '\r' there's actually no reason that GDB
+ couldn't "do the right thing" in this case, in which case, the test
+ would PASS, but that would require changes within GDB itself.
+
+ My preference then is that initially we patch the test to get it
+ KFAILing, then in a separate commit I can modify GDB so that it can
+ PASS with readline 7.
+
+2022-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp
+ The test gdb.python/py-format-address.exp, added in commit:
+
+ commit 25209e2c6979c3838e14e099f0333609810db280
+ Date: Sat Oct 23 09:59:25 2021 +0100
+
+ gdb/python: add gdb.format_address function
+
+ included 3 copy & paste errors where the wrong address was used in the
+ expected output patterns.
+
+ The test compiles two almost identical test binaries (one function
+ changes its name, that's the only difference), two inferiors are
+ created, each inferior using one of the test binaries.
+
+ We then take the address of the name changing function in both
+ inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests
+ are carried out using these addresses.
+
+ What we're checking for is that symbols 'foo' and 'bar' show up in the
+ correct inferior, and that (as this test is for a Python API feature),
+ the user can have one inferior selected, but ask about the other
+ inferior, and see the correct symbol in the result.
+
+ The hope is that the two binaries will be laid out identically by the
+ compiler, and that 'foo' and 'bar' will be at the same address. This
+ is fine, unless the executable is compiled as PIE (position
+ independent executable), in which case there is a problem.
+
+ The problem is that though inferior 1 is set running, the inferior 2
+ never is. If the executables are compiled as PIE, then the address in
+ the inferior 2 will not have been resolved, while the address in the
+ inferior 1 will have been, and so the two addresses we use in the
+ tests will be different.
+
+ This issue was reported here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html
+
+ The first part of the fix is to use the correct address variable in
+ the expected output patterns, with this change the tests pass even
+ when the executables are compiled as PIE.
+
+ A second part of this fix is to pass the 'nopie' option when we
+ compile the tests, this should ensure that the address obtained in
+ inferior 2 is the same as the address from inferior 1, which makes the
+ test more useful.
+
+2022-03-29 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: fix use after free of frame_info causing spurious notifications
+ In commit:
+
+ commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f
+ Date: Wed Mar 16 15:08:22 2022 +0000
+
+ gdb/mi: consistently notify user when GDB/MI client uses -thread-select
+
+ Changes were made to GDB to address some inconsistencies in when
+ notifications are sent from a MI terminal to a CLI terminal (when
+ multiple terminals are in use, see new-ui command).
+
+ Unfortunately, in order to track when the currently selected frame has
+ changed, that commit grabs a frame_info pointer before and after an MI
+ command has executed, and compares the pointers to see if the frame
+ has changed.
+
+ This is not safe.
+
+ If the frame cache is deleted for any reason then the frame_info
+ pointer captured before the command started, is no longer valid, and
+ any comparisons based on that pointer are undefined.
+
+ This was leading to random test failures for some folk, see:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186867.html
+
+ This commit changes GDB so we no longer hold frame_info pointers, but
+ instead store the frame_id and frame_level, this is safe even when the
+ frame cache is flushed.
+
+2022-03-29 Jan Beulich <jbeulich@suse.com>
+
+ bfd/Dwarf2: gas doesn't mangle names
+ Include the language identifier emitted by gas in the set of ones where
+ no mangled names are expected. Even if there could be "hand-mangled"
+ names, gas doesn't emit DW_AT_linkage_name in the first place.
+
+ bfd/Dwarf2: make find-nearest-line returned function name consistent
+ Prior to entering the enclosing "else if()" the earlier associated if()
+ checks function->is_linkage and, if set, uses function->name. The
+ comment in patch context precedes (and explains) the setting
+ function->is_linkage. Yet with the flag set, we should then also return
+ the function name, just like said earlier if() would do when we came
+ here a 2nd time for the same "addr". And indeed passing the same address
+ twice on addr2line's command line would resolve the function for the 2nd
+ instance, but not for the 1st (if this code path is taken). (This,
+ obviously, is particularly relevant when there's no ELF symbol table in
+ the first place, like would be the case - naturally - in PE/COFF
+ binaries, for example.)
+
+ gas/Dwarf: special-case .linefile only for macros
+ Restrict the PR gas/16908 workaround to just macros, matching the
+ original intention as well as the comment there. For constructs like
+ .irp or .rept the reasoning doesn't apply, as there's no separate
+ "invocation" point which may be of interest to record (for, as said
+ there, short macros).
+
+2022-03-29 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: correct FCVT.Q.L[U]
+ While the spec isn't explicit about this, it pointing out the similarity
+ with the D extension ought to extend to the ignoring of a meaningless
+ rounding mode: "Note FCVT.D.W[U] always produces an exact result and is
+ unaffected by rounding mode." Hence the chosen encodings also ought to
+ match.
+
+ Note that to avoid breaking existing code the forms with a 3rd operand
+ are not removed, which means there continues to be a difference to
+ FCVT.D.W[U].
+
+2022-03-29 Mike Frysinger <vapier@gentoo.org>
+
+ sim: add arch/.gdbinit stub scripts
+ Make it easy to load the common gdbinit script even when running in
+ the arch/ subdir instead of the top-level sim dir.
+
+2022-03-29 Alan Modra <amodra@gmail.com>
+
+ asan: heap buffer overflow in pa_chk_field_selector
+ The buffer overflow showed up running the gas "all macro" test.
+
+ PR 29005
+ * config/tc-hppa.c (pa_chk_field_selector): Don't read past end
+ of line.
+
+2022-03-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-28 Tom Tromey <tom@tromey.com>
+
+ Add Rust parser check for end of expression
+ I noticed that "print 5," passed in Rust -- the parser wasn't checking
+ that the entire input was used. This patch fixes the problem. This
+ in turn pointed out another bug in the parser, namely that it didn't
+ lex the next token after handling a string token. This is also fixed
+ here.
+
+2022-03-28 Tom Tromey <tom@tromey.com>
+
+ Switch gdb_stdlog to use timestamped_file
+ Currently, timestamps for logging are done by looking for the use of
+ gdb_stdlog in vfprintf_unfiltered. This seems potentially buggy, in
+ that during logging or other redirects (like execute_fn_to_ui_file) we
+ might have gdb_stdout==gdb_stdlog and so, conceivably, wind up with
+ timestamps in a log when they were not desired.
+
+ It seems better, instead, for timestamps to be a property of the
+ ui_file itself.
+
+ This patch changes gdb to use the new timestamped_file for gdb_stdlog
+ where appropriate, and removes the special case from
+ vfprintf_unfiltered.
+
+ Note that this may somewhat change the output in some cases -- in
+ particular, when going through execute_fn_to_ui_file (or the _string
+ variant), timestamps won't be emitted. This could be fixed in those
+ functions, but it wasn't clear to me whether this is really desirable.
+
+ Note also that this changes the TUI to send gdb_stdlog to gdb_stderr.
+ I imagine that the previous use of gdb_stdout here was inadvertent.
+ (And in any case it probably doesn't matter.)
+
+2022-03-28 Tom Tromey <tom@tromey.com>
+
+ Add new timestamped_file class
+ This adds a "timestamped_file" subclass of ui_file. This class adds a
+ timestamp to its output when appropriate. That is, it follows the
+ rule already used in vfprintf_unfiltered of adding a timestamp at most
+ once per write.
+
+ The new class is not yet used.
+
+2022-03-28 Tom Tromey <tom@tromey.com>
+
+ Use unique_ptr in CLI logging code
+ This changes the CLI logging code to avoid manual memory management
+ (to the extent possible) by using unique_ptr in a couple of spots.
+ This will come in handy in a later patch.
+
+2022-03-28 Tom Tromey <tom@tromey.com>
+
+ Simplify the CLI set_logging logic
+ The CLI's set_logging logic seemed unnecessarily complicated to me.
+ This patch simplifies it, with an eye toward changing it to use RAII
+ objects in a subsequent patch.
+
+ I did not touch the corresponding MI code. That code seems incorrect
+ (nothing ever uses raw_stdlog, and nothing ever sets
+ saved_raw_stdlog). I didn't attempt to fix this, because I question
+ whether this is even useful for MI.
+
+2022-03-28 Tom Tromey <tromey@adacore.com>
+
+ Handle multiple addresses in call_site_target
+ A large customer program has a function that is partitioned into hot
+ and cold parts. A variable in a callee of this function is described
+ using DW_OP_GNU_entry_value, but gdb gets confused when trying to find
+ the caller. I tracked this down to dwarf2_get_pc_bounds interpreting
+ the function's changes so that the returned low PC is the "wrong"
+ function.
+
+ Intead, when processing DW_TAG_call_site, the low PC of each range in
+ DW_AT_ranges should be preserved in the call_site_target. This fixes
+ the variable lookup in the test case I have.
+
+ I didn't write a standalone test for this as it seemed excessively
+ complicated.
+
+2022-03-28 Tom Tromey <tromey@adacore.com>
+
+ Change call_site_target to iterate over addresses
+ In order to handle the case where a call site target might refer to
+ multiple addresses, we change the code to use a callback style. Any
+ spot using call_site_target::address now passes in a callback function
+ that may be called multiple times.
+
+2022-03-28 Tom Tromey <tromey@adacore.com>
+
+ Change call_site_find_chain_1 to work recursively
+ call_site_find_chain_1 has a comment claiming that recursive calls
+ would be too expensive. However, I doubt this is so expensive; and
+ furthermore the explicit state management approach here is difficult
+ both to understand and to modify. This patch changes this code to use
+ explicit recursion, so that a subsequent patch can generalize this
+ code without undue trauma.
+
+ Additionally, I think this patch detects a latent bug in the recursion
+ code. (It's hard for me to be completely certain.) The bug is that
+ when a new target_call_site is entered, the code does:
+
+ if (target_call_site)
+ {
+ if (addr_hash.insert (target_call_site->pc ()).second)
+ {
+ /* Successfully entered TARGET_CALL_SITE. */
+
+ chain.push_back (target_call_site);
+ break;
+ }
+ }
+
+ Here, if entering the target_call_site fails, then any tail_call_next
+ elements in this call site are not visited. However, if this code
+ does happen to enter a call site, then the tail_call_next elements
+ will be visited during backtracking. This applies when doing the
+ backtracking as well -- it will only continue through a given chain as
+ long as each element in the chain can successfully be visited.
+
+ I'd appreciate some review of this. If this behavior is intentional,
+ it can be added to the new implementation.
+
+2022-03-28 Tom Tromey <tromey@adacore.com>
+
+ Constify chain_candidate
+ While investigating this bug, I wasn't sure if chain_candidate might
+ update 'chain'. I changed it to accept a const reference, making it
+ clear that it cannot. This simplifies the code a tiny bit as well.
+
+ Make call_site_target members private
+ This makes the data members of call_site_target 'private'. This lets
+ us remove most of its public API. call_site_to_target_addr is changed
+ to be a method of this type. This is a preparatory refactoring for
+ the fix at the end of this series.
+
+ Change call_site_target to use custom type and enum
+ call_site_target reuses field_loc_kind and field_location. However,
+ it has never used the full range of the field_loc_kind enum. In a
+ subsequent patch, I plan to add a new 'kind' here, so it seemed best
+ to avoid this reuse and instead introduce new types here.
+
+2022-03-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-26 Tom Tromey <tom@tromey.com>
+
+ Remove an unused declaration from value.h
+ value.h has a declaration of value_print_array_elements that is
+ incorrect. In C, this would have been an error, but in C++ this is a
+ declaration of an overload that is neither defined nor used. This
+ patch removes the declaration.
+
+2022-03-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-25 Nick Alcock <nick.alcock@oracle.com>
+
+ libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
+ My previous nm patch handled all cases but one -- if the user set NM in
+ the environment to a path which contained an option, libtool's nm
+ detection tries to run nm against a copy of nm with the options in it:
+ e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
+ test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
+ This is unlikely to be desirable: in this case we should run
+ "/usr/bin/nm --blargle /usr/bin/nm".
+
+ Furthermore, as part of this nm has to detect when the passed-in $NM
+ contains a path, and in that case avoid doing a path search itself.
+ This too was thrown off if an option contained something that looked
+ like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
+ "nm -B../prev-gcc nm" which rarely works well (and indeed it looks
+ to see whether that nm exists, finds it doesn't, and wrongly concludes
+ that nm -p or whatever does not work).
+
+ Fix all of these by clipping all options (defined as everything
+ including and after the first " -") before deciding whether nm
+ contains a path (but not using the clipped value for anything else),
+ and then removing all options from the path-modified nm before
+ looking to see whether that nm existed.
+
+ NM=my-nm now does a path search and runs e.g.
+ /usr/bin/my-nm -B /usr/bin/my-nm
+
+ NM=/usr/bin/my-nm now avoids a path search and runs e.g.
+ /usr/bin/my-nm -B /usr/bin/my-nm
+
+ NM="my-nm -p../wombat" now does a path search and runs e.g.
+ /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
+
+ NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
+ ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
+
+ This seems to be all combinations, including those used by GCC bootstrap
+ (which, before this commit, fails to bootstrap when configured
+ --with-build-config=bootstrap-lto, because the lto plugin is now using
+ --export-symbols-regex, which requires libtool to find a working nm,
+ while also using -B../prev-gcc to point at the lto plugin associated
+ with the GCC just built.)
+
+ Regenerate all affected configure scripts.
+
+ * libtool.m4 (LT_PATH_NM): Handle user-specified NM with
+ options, including options containing paths.
+
+2022-03-25 Alan Modra <amodra@gmail.com>
+
+ Re: gas/Dwarf: improve debug info generation from .irp and alike blocks
+ am33_2.0-linux is a mn10300 target.
+
+ * testsuite/gas/elf/dwarf-5-irp.d: xfail am33.
+
+2022-03-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-24 Aaron Merey <amerey@redhat.com>
+
+ Remove download size from debuginfod progress messages if unavailable
+ Currently debuginfod progress update messages include the size of
+ each download:
+
+ Downloading 7.5 MB separate debug info for /lib/libxyz.so.0
+
+ This value originates from the Content-Length HTTP header of the
+ transfer. However this header is not guaranteed to be present for
+ each download. This can happen when debuginfod servers compress files
+ on-the-fly at the time of transfer. In this case gdb wrongly prints
+ "-0.00 MB" as the size.
+
+ This patch removes download sizes from progress messages when they are
+ not available. It also removes usage of the progress bar until
+ a more thorough reworking of progress updating is implemented. [1]
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html
+
+2022-03-24 Reuben Thomas <rrt@sc3d.org>
+
+ sim: fix a comment typo in sim-load.c
+ Fix a typo where the documentation refers to a function parameter by the
+ wrong name.
+
+ Change-Id: I99494efe62cd4aa76fb78a0bd5da438d35740ebe
+
+2022-03-24 Reuben Thomas <rrt@sc3d.org>
+
+ sim: fix “alligned” typos
+ Change-Id: Ifd574e38524dd4f1cf0fc003e0c5c7499abc84a0
+
+2022-03-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: mention dropped L1OM/K1OM support in ld/ as well
+ This amends e961c696dcb2 ("x86: drop L1OM/K1OM support from ld"). Also
+ remove the marker that I mistakenly added in c085ab00c7b2 ("x86: drop
+ L1OM/K1OM support from gas").
+
+2022-03-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: remove gdb.python/pretty-print-call-by-hand.exp
+ This test was added without a corresponding fix, with some setup_kfails.
+ However, it results in UNRESOLVED results when GDB is built with ASan.
+
+ ERROR: GDB process no longer exists
+ GDB process exited with wait status 1946871 exp7 0 1
+ UNRESOLVED: gdb.python/pretty-print-call-by-hand.exp: frame print: backtrace test (PRMS gdb/28856)
+
+ Remove the test from the tree, I'll attach it to the Bugzilla bug
+ instead [1].
+
+ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28856
+
+ Change-Id: Id95d8949fb8742874bd12aeac758aa4d7564d678
+
+2022-03-24 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop L1OM/K1OM support from ld
+ This was only rudimentary support anyway; none of the sub-architecture
+ specific insns were ever supported.
+
+ x86: drop L1OM special case from disassembler
+ There wasn't any real support anyway: None of the sub-architecture
+ specific insns were ever supported.
+
+2022-03-24 Jan Beulich <jbeulich@suse.com>
+
+ MAINTAINERS: add myself
+ I much appreciate Nick offering this role to me. Nevertheless there's
+ still a lot for me to learn here.
+
+ At this occasion also update my email address in the pre-existing, much
+ more narrow entry.
+
+2022-03-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp
+ The gdb.mi/mi-multi-commands.exp test was added in commit:
+
+ commit d08cbc5d3203118da5583296e49273cf82378042
+ Date: Wed Dec 22 12:57:44 2021 +0000
+
+ gdb: unbuffer all input streams when not using readline
+
+ And then tweaked in commit:
+
+ commit 144459531dd68a1287905079aaa131b777a8cc82
+ Date: Mon Feb 7 20:35:58 2022 +0000
+
+ gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test
+
+ The second of these commits was intended to address periodic test
+ failures that I was seeing, and this change did fix some problems,
+ but, unfortunately, introduced other issues.
+
+ The problem is that the test relies on sending two commands to GDB in
+ a single write. As the characters that make these two commands arrive
+ they are echoed to GDB's console. However, there is a race between
+ how quickly the characters are echoed and how quickly GDB decides to
+ act on the incoming commands.
+
+ Usually, both commands are echoed in full before GDB acts on the first
+ command, but sometimes this is not the case, and GDB can execute the
+ first command before both commands are fully echoed to the console.
+ In this case, the output of the first command will be mixed in with
+ the echoing of the second command.
+
+ This mixing of the command echoing and the first command output is
+ what was causing failures in the original version of the test.
+
+ The second commit relaxed the expected output pattern a little, but
+ was still susceptible to failures, so this commit further relaxes the
+ pattern.
+
+ Now, we look for the first command output with no regard to what is
+ before, or after the command. Then we look for the first mi prompt to
+ indicate that the first command has completed.
+
+ I believe that this change should make the test more stable than it
+ was before.
+
+2022-03-23 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging option
+ libctf has always handled endianness differences by detecting
+ foreign-endian CTF dicts on the input and endian-flipping them: dicts
+ are always written in native endianness. This makes endian-awareness
+ very low overhead, but it means that the foreign-endian code paths
+ almost never get routinely tested, since "make check" usually reads in
+ dicts ld has just written out: only a few corrupted-CTF tests are
+ actually in fixed endianness, and even they only test the foreign-
+ endian code paths when you run make check on a big-endian machine.
+ (And the fix is surely not to add more .s-based tests like that, because
+ they are a nightmare to maintain compared to the C-code-based ones.)
+
+ To improve on this, add a new environment variable,
+ LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally
+ endian-flip at ctf_write time, so the output is always in the wrong
+ endianness. This then tests the foreign-endian read paths properly
+ at open time.
+
+ Make this easier by restructuring the writeout code in ctf-serialize.c,
+ which duplicates the maybe-gzip-and-write-out code three times (once
+ for ctf_write_mem, with thresholding, and once each for
+ ctf_compress_write and ctf_write just so those can avoid thresholding
+ and/or compression). Instead, have the latter two call the former
+ with thresholds of 0 or (size_t) -1, respectively.
+
+ The endian-flipping code itself gains a bit of complexity, because
+ one single endian-flipper (flip_types) was assuming the input to be
+ in foreign-endian form and assuming it could pull things out of the
+ input once they had been flipped and make sense of them. At the
+ cost of a few lines of duplicated initializations, teach it to
+ read before flipping if we're flipping to foreign-endianness instead
+ of away from it.
+
+ libctf/
+ * ctf-impl.h (ctf_flip_header): No longer static.
+ (ctf_flip): Likewise.
+ * ctf-open.c (flip_header): Rename to...
+ (ctf_flip_header): ... this, now it is not private to one file.
+ (flip_ctf): Rename...
+ (ctf_flip): ... this too. Add FOREIGN_ENDIAN arg.
+ (flip_types): Likewise. Use it.
+ (ctf_bufopen_internal): Adjust calls.
+ * ctf-serialize.c (ctf_write_mem): Add flip_endian path via
+ a newly-allocated bounce buffer.
+ (ctf_compress_write): Move below ctf_write_mem and reimplement
+ in terms of it.
+ (ctf_write): Likewise.
+ (ctf_gzwrite): Note that this obscure writeout function does not
+ support endian-flipping.
+
+2022-03-23 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, ld: diagnose corrupted CTF header cth_strlen
+ The last section in a CTF dict is the string table, at an offset
+ represented by the cth_stroff header field. Its length is recorded in
+ the next field, cth_strlen, and the two added together are taken as the
+ size of the CTF dict. Upon opening a dict, we check that none of the
+ header offsets exceed this size, and we check when uncompressing a
+ compressed dict that the result of the uncompression is the same length:
+ but CTF dicts need not be compressed, and short ones are not.
+ Uncompressed dicts just use the ctf_size without checking it. This
+ field is thankfully almost unused: it is mostly used when reserializing
+ a dict, which can't be done to dicts read off disk since they're
+ read-only.
+
+ However, when opening an uncompressed foreign-endian dict we have to
+ copy it out of the mmaped region it is stored in so we can endian-
+ swap it, and we use ctf_size when doing that. When the cth_strlen is
+ corrupt, this can overrun.
+
+ Fix this by checking the ctf_size in all uncompressed cases, just as we
+ already do in the compressed case. Add a new test.
+
+ This came to light because various corrupted-CTF raw-asm tests had an
+ incorrect cth_strlen: fix all of them so they produce the expected
+ error again.
+
+ libctf/
+ PR libctf/28933
+ * ctf-open.c (ctf_bufopen_internal): Always check uncompressed
+ CTF dict sizes against the section size in case the cth_strlen is
+ corrupt.
+
+ ld/
+ PR libctf/28933
+ * testsuite/ld-ctf/diag-strlen-invalid.*: New test,
+ derived from diag-cttname-invalid.s.
+ * testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen.
+ * testsuite/ld-ctf/diag-cttname-null.s: Likewise.
+ * testsuite/ld-ctf/diag-cuname.s: Likewise.
+ * testsuite/ld-ctf/diag-parlabel.s: Likewise.
+ * testsuite/ld-ctf/diag-parname.s: Likewise.
+
+2022-03-23 Nick Alcock <nick.alcock@oracle.com>
+
+ include, libctf, ld: extend variable section to contain functions too
+ The CTF variable section is an optional (usually-not-present) section in
+ the CTF dict which contains name -> type mappings corresponding to data
+ symbols that are present in the linker input but not in the output
+ symbol table: the idea is that programs that use their own symbol-
+ resolution mechanisms can use this section to look up the types of
+ symbols they have found using their own mechanism.
+
+ Because these removed symbols (mostly static variables, functions, etc)
+ all have names that are unlikely to appear in the ELF symtab and because
+ very few programs have their own symbol-resolution mechanisms, a special
+ linker flag (--ctf-variables) is needed to emit this section.
+
+ Historically, we emitted only removed data symbols into the variable
+ section. This seemed to make sense at the time, but in hindsight it
+ really doesn't: functions are symbols too, and a C program can look them
+ up just like any other type. So extend the variable section so that it
+ contains all static function symbols too (if it is emitted at all), with
+ types of kind CTF_K_FUNCTION.
+
+ This is a little fiddly. We relied on compiler assistance for data
+ symbols: the compiler simply emits all data symbols twice, once into the
+ symtypetab as an indexed symbol and once into the variable section.
+
+ Rather than wait for a suitably adjusted compiler that does the same for
+ function symbols, we can pluck unreported function symbols out of the
+ symtab and add them to the variable section ourselves. While we're at
+ it, we do the same with data symbols: this is redundant right now
+ because the compiler does it, but it costs very little time and lets the
+ compiler drop this kludge and save a little space in .o files.
+
+ include/
+ * ctf.h: Mention the new things we can see in the variable
+ section.
+
+ ld/
+ * testsuite/ld-ctf/data-func-conflicted-vars.d: New test.
+
+ libctf/
+ * ctf-link.c (ctf_link_deduplicating_variables): Duplicate
+ symbols into the variable section too.
+ * ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename
+ to...
+ (symtypetab_delete_nonstatics): ... this. Check the funchash
+ when pruning redundant variables.
+ (ctf_symtypetab_sect_sizes): Adjust accordingly.
+ * NEWS: Describe this change.
+
+2022-03-23 Nick Alcock <nick.alcock@oracle.com>
+
+ ld, testsuite: improve CTF-availability test
+ The test for -gctf support in the compiler is used to determine when to
+ run the ld-ctf tests and most of those in libctf. Unfortunately,
+ because it uses check_compiler_available and compile_one_cc, it will
+ fail whenever the compiler emits anything on stderr, even if it
+ actually does support CTF perfectly well.
+
+ So, instead, ask the compiler to emit assembler output and grep it for
+ references to ".ctf": this is highly unlikely to be present if the
+ compiler does not support CTF. (This will need adjusting when CTF grows
+ support for non-ELF platforms that don't dot-prepend their section
+ names, but right now the linker doesn't link CTF on any such platforms
+ in any case.)
+
+ With this in place we can do things like run all the libctf tests under
+ leak sanitizers etc even if those spray warnings on simple CTF
+ compilations, rather than being blocked from doing so just when we would
+ most like to.
+
+ ld/
+ * testsuite/lib/ld-lib.exp (check_ctf_available): detect CTF
+ even if a CTF-capable compiler emits warnings.
+
+2022-03-23 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/python: remove Python 2/3 compatibility macros
+ New in this version:
+
+ - Rebase on master, fix a few more issues that appeared.
+
+ python-internal.h contains a number of macros that helped make the code
+ work with both Python 2 and 3. Remove them and adjust the code to use
+ the Python 3 functions.
+
+ Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
+
+2022-03-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/python: remove Python 2 support
+ New in this version:
+
+ - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If
+ the user passes --with-python=python2, this will cause a configure
+ failure saying that GDB only supports Python 3.
+
+ Support for Python 2 is a maintenance burden for any patches touching
+ Python support. Among others, the differences between Python 2 and 3
+ string and integer types are subtle. It requires a lot of effort and
+ thinking to get something that behaves correctly on both. And that's if
+ the author and reviewer of the patch even remember to test with Python
+ 2.
+
+ See this thread for an example:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
+
+ So, remove Python 2 support. Update the documentation to state that GDB
+ can be built against Python 3 (as opposed to Python 2 or 3).
+
+ Update all the spots that use:
+
+ - sys.version_info
+ - IS_PY3K
+ - PY_MAJOR_VERSION
+ - gdb_py_is_py3k
+
+ ... to only keep the Python 3 portions and drop the use of some
+ now-removed compatibility macros.
+
+ I did not update the configure script more than just removing the
+ explicit references to Python 2. We could maybe do more there, like
+ check the Python version and reject it if that version is not
+ supported. Otherwise (with this patch), things will only fail at
+ compile time, so it won't really be clear to the user that they are
+ trying to use an unsupported Python version. But I'm a bit lost in the
+ configure code that checks for Python, so I kept that for later.
+
+ Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: reject relocations involving registers
+ To prevent fatal or even internal errors, add a simple check to
+ i386_validate_fix(), rejecting relocations when their target symbol is
+ an equate of a register (or resolved to reg_section for any other
+ reason).
+
+ x86: improve resolution of register equates
+ Allow transitive (or recursive) equates to work in addition to direct
+ ones. The only requirements are that
+ - the equate being straight of a register, i.e. no expressions involved
+ (albeit I'm afraid something like "%eax + 0" will be viewed as %eax),
+ - at the point of use there's no forward ref left which cannot be
+ resolved, yet.
+
+ Revert "PR28977 tc-i386.c internal error in parse_register"
+ This reverts commit 5fac3f02edacfca458f7eeaaaa33a87e26e0e332,
+ which was superceeded / replaced by 4faaa10f3fab.
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't attempt to resolve equates and alike from i386_parse_name()
+ PR gas/28977
+
+ Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
+ i386_parse_name() to call parse_register(). This being a hook from the
+ expression parser, it shouldn't be resolving e.g. equated symbols.
+ That's relevant only for all other callers of parse_register().
+
+ To compensate, in Intel syntax mode check_register() needs calling;
+ perhaps not doing so was an oversight right when the function was
+ introduced. This is necessary in particular to force EVEX encoding when
+ VRex registers are used (but of course also to reject bad uses of
+ registers, i.e. fully matching what parse_register() needs it for).
+
+2022-03-23 Luis Machado <luis.machado@arm.com>
+
+ Update the list of recognized m-profile TAG_CPU_ARCH_*
+ Check 3 additional variants previously not recognized:
+
+ - TAG_CPU_ARCH_V7E_M
+ - TAG_CPU_ARCH_V8M_BASE
+ - TAG_CPU_ARCH_V8M_MAIN
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ gas/Dwarf5: re-use file 0 line string table entry when faking file 0
+ No need to emit the same string a 2nd time for file 1 in this case.
+
+ gas/Dwarf5: adjust .debug_line file 0 checking
+ First of all when a table entry has a NULL filename, the two inner if()s
+ are better done the other way around: The 2nd doesn't depend on what the
+ first does. This then renders redundant half of the conditions of the
+ other if() and clarifies that subsequently only entry 0 is dealt with
+ (indicating that part of the comment was wrong). Finally for there to be
+ a usable name in slot 1, files_in_use needs to be larger than 1 and slot
+ 1's (rather than slot 0's) name needs to be non-NULL.
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ gas/Dwarf5: drop dead code
+ Commit 3417bfca676f ("GAS: DWARF-5: Ensure that the 0'th entry in the
+ directory table contains the current... ") added a "dwarf_level < 5"
+ check to out_dir_and_file_list(). This rendered dead that branch of the
+ construct, due to the enclosing if()'s "DWARF2_LINE_VERSION >= 5".
+ Delete that code as well as the corresponding part of the comment.
+
+ While there also drop a redundant "dirs != NULL": "dirs" will always be
+ non-NULL when dirs_in_use is not zero.
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ gas/Dwarf: improve debug info generation from .irp and alike blocks
+ Tying the bumping of the logical line number to reading from the
+ original source file looks wrong: Upon finishing of the processing of an
+ sb the original values will be restored anyway. Yet without bumping the
+ line counter uses of .line inside e.g. an .irp construct won't have the
+ intended effect: Such uses may be necessary to ensure proper debug info
+ is emitted in particular when switching sections inside the .irp body,
+ as dwarf2_gen_line_info() would bail without doing anything when it
+ finds the line number unchanged from what it saw last.
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ ELF32: don't silently truncate relocation addends
+ At least x86-64's x32 sub-mode and RISC-V's 32-bit mode calculate
+ addends as 64-bit values, but store them in signed 32-bit fields when
+ generating the file without encountering any earlier error. When the
+ relocated field is a 64-bit one, the value resulting after processing
+ the relocation record when linking (or the latest when loading) may
+ thus be wrong due to the truncation.
+
+ With the code change in place, one x32 testcase actually triggers the
+ new diagnostic. That one case of too large a (negative) addend is being
+ adjusted alongside the addition of a new testcase to actually trigger
+ the new error. (Note that due to internal BFD behavior the relocation in
+ .data doesn't get processed anymore after the errors in .text.)
+
+ Note that in principle it is possible to express 64-bit relocations in
+ ELF32, but this would require .rel relocations, i.e. with the addend
+ stored in the 64-bit field being relocated. But I guess it would be a
+ lot of effort for little gain to actually support this.
+
+2022-03-23 Jan Beulich <jbeulich@suse.com>
+
+ gas: retain whitespace between strings
+ Macro arguments may be separated by commas or just whitespace. Macro
+ arguments may also be quoted (where one level of quotes is removed in
+ the course of determining the values for the respective formal
+ parameters). Furthermore this quote removal knows _two_ somewhat odd
+ escaping mechanisms: One, apparently in existence forever, is that a
+ pair of quotes counts as the escaping of a quote, with the pair being
+ transformed to a single quote in the course of quote removal. The other
+ (introduced by c06ae4f232e6) looks more usual on the surface in that it
+ deals with \" sequences, but it _retains_ the escaping \. Hence only the
+ former mechanism is suitable when the value to be used by the macro body
+ is to contain a quote. Yet this results in ambiguity of what "a""b" is
+ intended to mean; elsewhere (e.g. for .ascii) it represents two
+ successive string literals. However, in any event is the above different
+ from "a" "b": I don't think this can be viewed the same as "a""b" when
+ processing macro arguments.
+
+ Change the scrubber to retain such whitespace, by making the processing
+ of strings more similar to that of symbols. And indeed this appears to
+ make sense when taking into account that for quite a while gas has been
+ supporting quoted symbol names.
+
+ Taking a more general view, however, the change doesn't go quite far
+ enough. There are further cases where significant whitespace is removed
+ by the scrubber. The new testcase enumerates a few in its ".if 0"
+ section. I'm afraid the only way that I see to deal with this would be
+ to significantly simplify the scrubber, such that it wouldn't do much
+ more than collapse sequences of unquoted whitespace into a single blank.
+ To be honest problems in this area aren't really surprising when seeing
+ that there's hardly any checking of .macro use throughout the testsuite
+ (and in particular in the [relatively] generic tests under all/).
+
+2022-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Only .so files are used in libcollector. Remove the other files.
+ * libcollector/Makefile.am (install-data-local): Remove the *.la
+ and *.a libraries.
+ * libcollector/Makefile.in: Regenerate.
+
+2022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: use gdb_attach to fix jit-elf.exp
+ If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
+ command without superuser:
+
+ make check-gdb TESTS="gdb.base/jit-elf.exp"
+
+ we can see the following messages in gdb/testsuite/gdb.log:
+
+ (gdb) attach 1650108
+ Attaching to program: /home/yangtiezhu/build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 1650108
+ ptrace: Operation not permitted.
+ (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
+
+ use gdb_attach to fix the above issue, at the same time, the clean_reattach
+ proc should return a value to indicate whether it worked, and the callers
+ should return early as well on failure.
+
+2022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: use gdb_attach to fix attach-pie-noexec.exp
+ If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
+ command without superuser:
+
+ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+ we can see the following messages in gdb/testsuite/gdb.log:
+
+ (gdb) attach 6500
+ Attaching to process 6500
+ ptrace: Operation not permitted.
+ (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
+
+ It is obviously wrong, the expected result should be UNSUPPORTED in such
+ a case.
+
+ With this patch, we can see "Operation not permitted" in the log info,
+ and then we can do the following processes to test:
+ (1) set ptrace_scope as 0
+ $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
+ $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+ (2) use sudo
+ $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+2022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: add new gdb_attach to check "attach" command
+ This commit adds new gdb_attach to centralize the failure checking of
+ "attach" command. Return 0 if attach failed, otherwise return 1.
+
+2022-03-23 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: remove attach test from can_spawn_for_attach
+ As Pedro Alves said, caching procs should not issue pass/fail [1],
+ this commit removes attach test from can_spawn_for_attach, at the
+ same time, use "verbose -log" instead of "unsupported" to get a
+ trace about why a test run doesn't support spawning for attach.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html
+
+2022-03-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ Add support for hardware breakpoints/watchpoints on FreeBSD/Aarch64.
+ This shares aarch64-nat.c and nat/aarch64-hw-point.c with the Linux
+ native target. Since FreeBSD writes all of the debug registers in one
+ ptrace op, use an unordered_set<> to track the "dirty" state for
+ threads rather than bitmasks of modified registers.
+
+ fbsd-nat: Add a low_prepare_to_resume virtual method.
+ This method can be overridden by architecture-specific targets to
+ perform additional work before a thread is resumed.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Add a low_delete_thread virtual method.
+ This method can be overridden by architecture-specific targets to
+ perform additional work when a thread is deleted.
+
+ Note that this method is only invoked on systems supporting LWP
+ events, but the pending use case (aarch64 debug registers) is not
+ supported on older kernels that do not support LWP events.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Add helper routine to fetch siginfo_t for a ptid.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ aarch64: Add an aarch64_nat_target mixin class.
+ This class includes platform-independent target methods for hardware
+ breakpoints and watchpoints using routines from
+ nat/aarch64-hw-point.c.
+
+ stopped_data_address is not platform-independent since the FAR
+ register holding the address for a breakpoint hit must be fetched in a
+ platform-specific manner. However, aarch64_stopped_data_address is
+ provided as a helper routine which performs platform-independent
+ validation given the value of the FAR register.
+
+ For tracking the per-process debug register mirror state, use an
+ unordered_map indexed by pid as recently adopted in x86-nat.c rather
+ than a manual linked-list.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ nat: Split out platform-independent aarch64 debug register support.
+ Move non-Linux-specific support for hardware break/watchpoints from
+ nat/aarch64-linux-hw-point.c to nat/aarch64-hw-point.c. Changes
+ beyond a simple split of the code are:
+
+ - aarch64_linux_region_ok_for_watchpoint and
+ aarch64_linux_any_set_debug_regs_state renamed to drop linux_ as
+ they are not platform specific.
+
+ - Platforms must implement the aarch64_notify_debug_reg_change
+ function which is invoked from the platform-independent code when a
+ debug register changes for a given debug register state. This does
+ not use the indirection of a 'low' structure as is done for x86.
+
+ - The handling for kernel_supports_any_contiguous_range is not
+ pristine. For non-Linux it is simply defined to true. Some uses of
+ this could perhaps be implemented as new 'low' routines for the
+ various places that check it instead?
+
+ - Pass down ptid into aarch64_handle_breakpoint and
+ aarch64_handle_watchpoint rather than using current_lwp_ptid which
+ is only defined on Linux. In addition, pass the ptid on to
+ aarch64_notify_debug_reg_change instead of the unused state
+ argument.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ x86-fbsd-nat: Copy debug register state on fork.
+ Use the FreeBSD native target low_new_fork hook to copy the
+ per-process debug state from the parent to the child on fork.
+
+ fbsd-nat: Add a low_new_fork virtual method.
+ This method can be overridden by architecture-specific targets to
+ perform additional work when a new child process is forked.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ Add an x86_fbsd_nat_target mixin class for FreeBSD x86 native targets.
+ This class implements debug register support common between the i386
+ and amd64 native targets.
+
+ While here, remove #ifdef's for HAVE_PT_GETDBREGS in FreeBSD-specific
+ code. The ptrace request has been present on FreeBSD x86
+ architectures since 4.0 (released in March 2000). The last FreeBSD
+ release without this support is 3.5 released in June 2000.
+
+2022-03-22 John Baldwin <jhb@FreeBSD.org>
+
+ x86-nat: Add x86_lookup_debug_reg_state.
+ This function returns nullptr if debug register state does not yet
+ exist for a given process rather than creating new state.
+
+ x86-nat: Use an unordered_map to store per-pid debug reg state.
+ This replaces a manual linked list which used O(n) lookup and removal.
+
+ Remove USE_SIGTRAP_SIGINFO condition for FreeBSD/x86 debug regs support.
+ For BSD x86 targets, stopped_by_hw_breakpoint doesn't check siginfo_t
+ but inspects the DR6 register directly via PT_GETDBREGS.
+
+2022-03-22 Tom Tromey <tom@tromey.com>
+
+ Remove two unused variables
+ I found a couple of spots that declare a symtab_and_line but don't
+ actually use it. I think this probably isn't detected as unused
+ because it has a constructor.
+
+2022-03-22 Steiner H Gunderson <steinar+sourceware@gunderson.no>
+
+ Fix return code in _bfd_dwarf2_find_nearest_line().
+ * dwarf2.c (_bfd_dwarf2_find_nearest_line): if a function name is
+ found, but no line number info, then return a result of 2.
+
+2022-03-22 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: add gdb.format_address function
+ Add a new function, gdb.format_address, which is a wrapper around
+ GDB's print_address function.
+
+ This method takes an address, and returns a string with the format:
+
+ ADDRESS <SYMBOL+OFFSET>
+
+ Where, ADDRESS is the original address, formatted as hexadecimal,
+ SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is
+ the offset from SYMBOL to ADDRESS in decimal.
+
+ If there's no SYMBOL suitably close to ADDRESS then the
+ <SYMBOL+OFFSET> part is not included.
+
+ This is useful if a user wants to write a Python script that
+ pretty-prints addresses, the user no longer needs to do manual symbol
+ lookup, or worry about correctly formatting addresses.
+
+ Additionally, there are some settings that effect how GDB picks
+ SYMBOL, and whether the file name and line number should be included
+ with the SYMBOL name, the gdb.format_address function ensures that the
+ users Python script also benefits from these settings.
+
+ The gdb.format_address by default selects SYMBOL from the current
+ inferiors program space, and address is formatted using the
+ architecture for the current inferior. However, a user can also
+ explicitly pass a program space and architecture like this:
+
+ gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE)
+
+ In order to format an address for a different inferior.
+
+ Notes on the implementation:
+
+ In py-arch.c I extended arch_object_to_gdbarch to add an assertion for
+ the type of the PyObject being worked on. Prior to this commit all
+ uses of arch_object_to_gdbarch were guaranteed to pass this function a
+ gdb.Architecture object, but, with this commit, this might not be the
+ case.
+
+ So, with this commit I've made it a requirement that the PyObject be a
+ gdb.Architecture, and this is checked with the assert. And in order
+ that callers from other files can check if they have a
+ gdb.Architecture object, I've added the new function
+ gdbpy_is_architecture.
+
+ In py-progspace.c I've added two new function, the first
+ progspace_object_to_program_space, converts a PyObject of type
+ gdb.Progspace to the associated program_space pointer, and
+ gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not.
+
+2022-03-22 Luis Machado <luis.machado@arm.com>
+
+ Fix some stale header names from dwarf files
+ Some of these references were not updated when they were moved to a separate
+ directory.
+
+2022-03-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ Install gprofng libraries under $(pkglibdir)
+ gprofng/ChangeLog
+ 2022-03-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ PR gprofng/28972
+ * gprofng/libcollector/Makefile.am: Rename lib_LTLIBRARIES to
+ pkglib_LTLIBRARIES. Add install-data-local.
+ * gprofng/src/Makefile.am: Likewise.
+ * gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of
+ the gprofng libraries.
+ * gprofng/configure.ac: Removed an unused GPROFNG_LIBDIR.
+ * gprofng/Makefile.am: Removed an unused GPROFNG_LIBDIR. Add
+ install-data-local.
+ * gprofng/configure: Regenerate.
+ * gprofng/Makefile.in: Likewise.
+ * gprofng/doc/Makefile.in: Likewise.
+ * gprofng/gp-display-htmllibcollector/Makefile.in: Likewise.
+ * gprofng/libcollector/Makefile.in: Likewise.
+ * gprofng/src/Makefile.in: Likewise.
+
+2022-03-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-21 Roland McGrath <mcgrathr@google.com>
+
+ gdb: Add missing #include in solib.h
+ The gdb_bfd_ref_ptr type is used in solib.h declarations.
+
+2022-03-21 Aaron Merey <amerey@redhat.com>
+
+ PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings
+ Add debuginfod support to core_target::build_file_mappings and
+ locate_exec_from_corefile_build_id to enable the downloading of
+ missing executables and shared libraries referenced in core files.
+
+ Also add debuginfod support to solib_map_sections so that previously
+ downloaded shared libraries can be retrieved from the local debuginfod
+ cache.
+
+ When core file shared libraries are found locally, verify that their
+ build-ids match the corresponding build-ids found in the core file.
+ If there is a mismatch, attempt to query debuginfod for the correct
+ build and print a warning if unsuccessful:
+
+ warning: Build-id of /lib64/libc.so.6 does not match core file.
+
+ Also disable debuginfod when gcore invokes gdb. Debuginfo is not
+ needed for core file generation so debuginfod queries will slow down
+ gcore unnecessarily.
+
+2022-03-21 Aaron Merey <amerey@redhat.com>
+
+ gdb: Add soname to build-id mapping for core files
+ Since commit aa2d5a422 gdb has been able to read executable and shared
+ library build-ids within core files.
+
+ Expand this functionality so that each core file bfd maintains a map of
+ soname to build-id for each shared library referenced in the core file.
+
+ This feature may be used to verify that gdb has found the correct shared
+ libraries for core files and to facilitate downloading shared libaries via
+ debuginfod.
+
+2022-03-21 Pedro Alves <pedro@palves.net>
+
+ Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)
+ If GDB reports a watchpoint hit, and then the next event is not
+ TARGET_WAITKIND_STOPPED, but instead some event for which there's a
+ catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly
+ thinks the watchpoint triggered. Vis, using foll-fork.c:
+
+ (gdb) awatch v
+ Hardware access (read/write) watchpoint 2: v
+ (gdb) catch fork
+ Catchpoint 3 (fork)
+ (gdb) c
+ Continuing.
+
+ Hardware access (read/write) watchpoint 2: v
+
+ Old value = 0
+ New value = 5
+ main () at gdb.base/foll-fork.c:16
+ 16 pid = fork ();
+ (gdb)
+ Continuing.
+
+ Hardware access (read/write) watchpoint 2: v <<<<
+ <<<< these lines are spurious
+ Value = 5 <<<<
+
+ Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49
+ 49 arch-fork.h: No such file or directory.
+ (gdb)
+
+ The problem is that when we handle the fork event, nothing called
+ watchpoints_triggered before calling bpstat_stop_status. Thus, each
+ watchpoint's watchpoint_triggered field was still set to
+ watch_triggered_yes from the previous (real) watchpoint stop.
+ watchpoint_triggered is only current called in the handle_signal_stop
+ path, when handling TARGET_WAITKIND_STOPPED.
+
+ This fixes it by adding watchpoint_triggered calls in the other events
+ paths that call bpstat_stop_status. But instead of adding them
+ explicitly, it adds a new function bpstat_stop_status_nowatch that
+ wraps bpstat_stop_status and calls watchpoint_triggered, and then
+ replaces most calls to bpstat_stop_status with calls to
+ bpstat_stop_status_nowatch.
+
+ This required constifying watchpoints_triggered.
+
+ New test included, which fails without the fix.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621
+
+ Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c
+
+2022-03-21 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Fixup previous patch
+ The previous prepare_resume_reply change missed updating the 'buf'
+ reference that overwrites the 'T', so if 'buf' was advanced, we'd
+ still overwrite the wrong character. This fixes it.
+
+ Change-Id: Ia8ce433366b85af4e268c1c49e7b447da3130a4d
+
+2022-03-21 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Fix incorrect assertion
+ While playing with adding a new event kind, I noticed that
+ prepare_resume_reply TARGET_WAITKIND_FORKED, etc. advance 'buf', so if
+ we force-disable the T packet, we'd fail the *buf == 'T' assertion.
+
+ Fix it by tweaking the assertion to always look at the beginning of
+ the buffer.
+
+ Change-Id: I8c38e32353db115edcde418b3b1e8ba12343c22b
+
+2022-03-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: re-generate config.in
+ I'm getting this diff when running `autoreconf -vf`.
+
+ Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d
+
+2022-03-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/x86: handle stap probe arguments in xmm registers
+ On x86 machines with xmm register, and with recent versions of
+ systemtap (and gcc?), it can occur that stap probe arguments will be
+ placed into xmm registers.
+
+ I notice this happening on a current Fedora Rawhide install with the
+ following package versions installed:
+
+ $ rpm -q glibc systemtap gcc
+ glibc-2.35.9000-10.fc37.x86_64
+ systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64
+ gcc-12.0.1-0.12.fc37.x86_64
+
+ If I check the probe data in libc, I see this:
+
+ $ readelf -n /lib64/libc.so.6
+ ...
+ stapsdt 0x0000004d NT_STAPSDT (SystemTap probe descriptors)
+ Provider: libc
+ Name: pthread_start
+ Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
+ Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx)
+ stapsdt 0x00000050 NT_STAPSDT (SystemTap probe descriptors)
+ Provider: libc
+ Name: pthread_create
+ Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
+ Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp)
+ ...
+
+ Notice that for both of these probes, the first argument is a uint64_t
+ stored in the xmm1 register.
+
+ Unfortunately, if I try to use this probe within GDB, then I can't
+ view the first argument. Here's an example session:
+
+ $ gdb $(which gdb)
+ (gdb) start
+ ...
+ (gdb) info probes stap libc pthread_create
+ ...
+ (gdb) break *0x00007ffff729e2f1 # Use address of probe.
+ (gdb) continue
+ ...
+ (gdb) p $_probe_arg0
+ Invalid cast.
+
+ What's going wrong? If I re-run my session, but this time use 'set
+ debug stap-expression 1', this is what I see:
+
+ (gdb) set debug stap-expression 1
+ (gdb) p $_probe_arg0
+ Operation: UNOP_CAST
+ Operation: OP_REGISTER
+ String: xmm1
+ Type: uint64_t
+ Operation: UNOP_CAST
+ Operation: OP_REGISTER
+ String: r13
+ Type: uint64_t
+ Operation: UNOP_CAST
+ Operation: UNOP_IND
+ Operation: UNOP_CAST
+ Operation: BINOP_ADD
+ Operation: OP_LONG
+ Type: long
+ Constant: 0x0000000000000008
+ Operation: OP_REGISTER
+ String: rsp
+ Type: uint64_t *
+ Type: uint64_t
+ Operation: UNOP_CAST
+ Operation: UNOP_IND
+ Operation: UNOP_CAST
+ Operation: BINOP_ADD
+ Operation: OP_LONG
+ Type: long
+ Constant: 0x0000000000000010
+ Operation: OP_REGISTER
+ String: rsp
+ Type: uint64_t *
+ Type: uint64_t
+ Invalid cast.
+ (gdb)
+
+ The important bit is this:
+
+ Operation: UNOP_CAST
+ Operation: OP_REGISTER
+ String: xmm1
+ Type: uint64_t
+
+ Which is where we cast the xmm1 register to uint64_t. And the final
+ piece of the puzzle is:
+
+ (gdb) ptype $xmm1
+ type = union vec128 {
+ v8bf16 v8_bfloat16;
+ v4f v4_float;
+ v2d v2_double;
+ v16i8 v16_int8;
+ v8i16 v8_int16;
+ v4i32 v4_int32;
+ v2i64 v2_int64;
+ uint128_t uint128;
+ }
+
+ So, we are attempting to cast a union type to a scalar type, which is
+ not supporting in C/C++, and as a consequence GDB's expression
+ evaluator throws an error when we attempt to do this.
+
+ The first approach I considered for solving this problem was to try
+ and make use of gdbarch_stap_adjust_register. We already have a
+ gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak
+ the name of the register that we access. Currently only x86
+ architectures use this to transform things like ax to eax in some
+ cases.
+
+ I wondered, what if we change gdbarch_stap_adjust_register to do more
+ than just change the register names? What if this method instead
+ became gdbarch_stap_read_register. This new method would return a
+ operation_up, and would take the register name, and the type we are
+ trying to read from the register, and return the operation that
+ actually reads the register.
+
+ The default implementation of this method would just use
+ user_reg_map_name_to_regnum, and then create a register_operation,
+ like we already do in stap_parse_register_operand. But, for x86
+ architectures this method would fist possibly adjust the register
+ name, then do the default action to read the register. Finally, for
+ x86 this method would spot when we were accessing an xmm register,
+ and, based on the type being pulled from the register, would extract
+ the correct field from the union.
+
+ The benefit of this approach is that it would work with the expression
+ types that GDB currently supports. The draw back would be that this
+ approach would not be very generic. We'd need code to handle each
+ sub-field size with an xmm register. If other architectures started
+ using vector registers for probe arguments, those architectures would
+ have to create their own gdbarch_stap_read_register method. And
+ finally, the type of the xmm registers comes from the type defined in
+ the target description, there's a risk that GDB might end up
+ hard-coding the names of type sub-fields, then if a target uses a
+ different target description, with different field names for xmm
+ registers, the stap probes would stop working.
+
+ And so, based on all the above draw backs, I rejected this first
+ approach.
+
+ My second plan involves adding a new expression type to GDB called
+ unop_extract_operation. This new expression takes a value and a type,
+ during evaluation the value contents are fetched, and then a new value
+ is extracted from the value contents (based on type). This is similar
+ to the following C expression:
+
+ result_value = *((output_type *) &input_value);
+
+ Obviously we can't actually build this expression in this case, as the
+ input_value is in a register, but hopefully the above makes it clearer
+ what I'm trying to do.
+
+ The benefit of the new expression approach is that this code can be
+ shared across all architectures, and it doesn't care about sub-field
+ names within the union type.
+
+ The draw-backs that I see are potential future problems if arguments
+ are not stored within the least significant bytes of the register.
+ However if/when that becomes an issue we can adapt the
+ gdbarch_stap_read_register approach to allow architectures to control
+ how a value is extracted.
+
+ For testing, I've extended the existing gdb.base/stap-probe.exp test
+ to include a function that tries to force an argument into an xmm
+ register. Obviously, that will only work on a x86 target, so I've
+ guarded the new function with an appropriate GCC define. In the exp
+ script we use readelf to check if the probe exists, and is using the
+ xmm register.
+
+ If the probe doesn't exist then the associated tests are skipped.
+
+ If the probe exists, put isn't using the xmm register (which will
+ depend on systemtap/gcc versions), then again, the tests are skipped.
+
+ Otherwise, we can run the test. I think the cost of running readelf
+ is pretty low, so I don't feel too bad making all the non-xmm targets
+ running this step.
+
+ I found that on a Fedora 35 install, with these packages installed, I
+ was able to run this test and have the probe argument be placed in an
+ xmm register:
+
+ $ rpm -q systemtap gcc glibc
+ systemtap-4.6-4.fc35.x86_64
+ gcc-11.2.1-9.fc35.x86_64
+ glibc-2.34-7.fc35.x86_64
+
+ Finally, as this patch adds a new operation type, then I need to
+ consider how to generate an agent expression for the new operation
+ type.
+
+ I have kicked the can down the road a bit on this. In the function
+ stap_parse_register_operand, I only create a unop_extract_operation in
+ the case where the register type is non-scalar, this means that in
+ most cases I don't need to worry about generating an agent expression
+ at all.
+
+ In the xmm register case, when an unop_extract_operation will be
+ created, I have sketched out how the agent expression could be
+ handled, however, this code is currently not reached. When we try to
+ generate the agent expression to place the xmm register on the stack,
+ GDB hits this error:
+
+ (gdb) trace -probe-stap test:xmmreg
+ Tracepoint 1 at 0x401166
+ (gdb) actions
+ Enter actions for tracepoint 1, one per line.
+ End with a line saying just "end".
+ >collect $_probe_arg0
+ Value not scalar: cannot be an rvalue.
+
+ This is because GDB doesn't currently support placing non-scalar types
+ on the agent expression evaluation stack. Solving this is clearly
+ related to the original problem, but feels a bit like a second
+ problem. I'd like to get feedback on whether my approach to solving
+ the original problem is acceptable or not before I start looking at
+ how to handle xmm registers within agent expressions.
+
+2022-03-21 Steiner H Gunderson <steinar+sourceware@gunderson.no>
+
+ Reduce O(n2) performance overhead when parsing DWARF unit information.
+ PR 28978
+ * dwarf2.c (scan_unit_for_symbols): When performing second pass,
+ check to see if the function or variable being processed is the
+ same as the previous one.
+
+2022-03-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't suppress overflow diagnostics in x32 mode
+ Unlike in 64-bit mode, where values wrap at the 64-bit boundary anyway,
+ there's no wrapping at the 32-bit boundary here, and hence overflow
+ detection shouldn't be suppressed just because rela relocations are
+ going to be used.
+
+ The extra check against NO_RELOC is actually a result of an ilp32 test
+ otherwise failing. But thinking about it, reporting overflows for
+ not-really-relocations (typically because of earlier errors) makes
+ little sense in general. Perhaps this should even be extended to non-
+ 64-bit modes.
+
+2022-03-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/testsuite: reformat gdb.python/pretty-print-call-by-hand.py
+ Run black on the file.
+
+ Change-Id: Ifb576137fb7158a0227173f61c1202f0695b3685
+
+2022-03-21 Bruno Larsen <blarsen@redhat.com>
+
+ [gdb/testsuite] test a function call by hand from pretty printer
+ The test case added here is testing the bug gdb/28856, where calling a
+ function by hand from a pretty printer makes GDB crash. There are 6
+ mechanisms to trigger this crash in the current test, using the commands
+ backtrace, up, down, finish, step and continue. Since the failure happens
+ because of use-after-free (more details below) the tests will always
+ have a chance of passing through sheer luck, but anecdotally they seem
+ to fail all of the time.
+
+ The reason GDB is crashing is a use-after-free problem. The above
+ mentioned functions save a pointer to the current frame's information,
+ then calls the pretty printer, and uses the saved pointer for different
+ reasons, depending on the function. The issue happens because
+ call_function_by_hand needs to reset the obstack to get the current
+ frame, invalidating the saved pointer.
+
+2022-03-21 Pedro Alves <pedro@palves.net>
+
+ gdb/testsuite: Installed-GDB testing & data-directory
+ In testsuite/README, we suggest that you can run the testsuite against
+ some other GDB binary by using:
+
+ make check RUNTESTFLAGS=GDB=/usr/bin/gdb
+
+ However, that example isn't fully correct, because with that command
+ line, the testsuite will still pass
+
+ -data-directory=[pwd]/../data-directory
+
+ to /usr/bin/gdb, like e.g.:
+
+ ...
+ builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0
+ ...
+
+ while if you're testing an installed GDB (the system GDB being the
+ most usual scenario), then you should normally let it use its own
+ configured directory, not the just-built GDB's data directory.
+
+ This commit improves the status quo with the following two changes:
+
+ - if the user specifies GDB on the command line, then by default,
+ don't start GDB with the -data-directory command line option.
+ I.e., let the tested GDB use its own configured data directory.
+
+ - let the user override the data directory, via a new
+ GDB_DATA_DIRECTORY global. This replaces the existing
+ BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which
+ wasn't overridable, and was a bit misnamed for the new purpose.
+
+ So after this, the following commands I believe behave intuitively:
+
+ # Test the non-installed GDB in some build dir:
+
+ make check \
+ RUNTESTFLAGS="GDB=/path/to/other/build/gdb \
+ GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory"
+
+ # Test the GDB installed in some prefix:
+
+ make check \
+ RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb"
+
+ # Test the built GDB with some alternative data directory, e.g., the
+ system GDB's data directory:
+
+ make check \
+ RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb"
+
+ Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb
+
+2022-03-21 Nick Clifton <nickc@redhat.com>
+
+ z80 assembler: Fix new unexpected overflow warning in v2.37
+ PR 28791
+ * config/tc-z80.c (emit_data_val): Do not warn about overlarge
+ constants generated by bit manipulation operators.
+ * testsuite/gas/z80/pr28791.s: New test source file.
+ * testsuite/gas/z80/pr28791.d: New test driver file.
+
+2022-03-21 Andreas Schwab <schwab@linux-m68k.org>
+
+ Add support for readline 8.2
+ In readline 8.2 the type of rl_completer_word_break_characters changed to
+ include const.
+
+2022-03-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-20 Andreas Schwab <schwab@linux-m68k.org>
+
+ RISC-V: Fix misplaced @end table
+ Move the csr-check and arch items inside the table for the .option directive.
+
+2022-03-20 Alan Modra <amodra@gmail.com>
+
+ PR28979, internal error in demand_empty_rest_of_line
+ The change in read_a_source_file prevents the particular testcase in
+ the PR from triggering the assertion in demand_empty_rest_of_line.
+ I've also removed the assertion. Nothing much goes wrong with gas if
+ something else triggers it, so it's not worthy of an abort.
+
+ I've also changed my previous patch to ignore_rest_of_line to allow
+ that function to increment input_line_pointer past buffer_limit, like
+ demand_empty_rest_of_line: The two functions ought to behave the
+ same in that respect. Finally, demand_empty_rest_of_line gets a
+ little hardening to prevent accesses past buffer_limit plus one.
+
+ PR 28979
+ * read.c (read_a_source_file): Calculate known size for sbuf
+ rather than calling strlen.
+ (demand_empty_rest_of_line): Remove "know" check. Expand comment.
+ Don't dereference input_line_pointer when past buffer_limit.
+ (ignore_rest_of_line): Allow input_line_pointer to increment to
+ buffer_limit plus one. Expand comment.
+
+2022-03-20 Joel Brobecker <brobecker@adacore.com>
+
+ Update gdb/NEWS after GDB 12 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.
+
+2022-03-20 Joel Brobecker <brobecker@adacore.com>
+
+ Bump version to 13.0.50.DATE-git.
+ Now that the GDB 12 branch has been created,
+ this commit bumps the version number in gdb/version.in to
+ 13.0.50.DATE-git
+
+ For the record, the GDB 12 branch was created
+ from commit 2be64de603f8b3ae359d2d3fbf5db0e79869f32b.
+
+ 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 13.
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64
+ ld/testsuite/ld-loongarch-elf
+
+ * ld-loongarch-elf.exp: Test LoongArch32 and LoongArch64 testcases respectively.
+ * jmp_op.d: Fix bug in test LoongArch32.
+ * disas-jirl-32.d: New test case for LoongArch32.
+ * disas-jirl-32.s: New test case for LoongArch32.
+ * disas-jirl.d: Skip test case LoongArch32.
+ * macro_op_32.d: New test case for LoongArch32.
+ * macro_op_32.s: New test case for LoongArch32.
+ * macro_op.d: Skip test case LoongArch32.
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ gas:LoongArch: Fix "make check" pr21884 fail in LoongArch32.
+ gas/config/
+ * tc-loongarch.c: Add function to select target mach.
+ * tc-loongarch.h: Define macro TARGET_MACH.
+
+ ld: loongarch: Skip unsupport test cases.
+ ld/testsuite/ld-elf/
+ * eh5.d Skip loongarch64 target.
+ * pr21884.d Skip loongarch* targets.
+ * pr26936.d Skip loongarch* targets.
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Fix LD check fails.
+ Some test cases about ifunc.
+
+ bfd/
+ * elfnn-loongarch.c
+ * elfxx-loongarch.h
+
+ === ld Summary ===
+ of expected passes 1430
+ of expected failures 11
+ of untested testcases 1
+ of unsupported tests 154
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Update ABI eflag in elf header.
+ Update LoongArch ABI eflag in elf header.
+ ilp32s 0x5
+ ilp32f 0x6
+ ilp32d 0x7
+ lp64s 0x1
+ lp64f 0x2
+ lp64d 0x3
+
+ bfd/
+ * elfnn-loongarch.c Check object flags while ld.
+
+ gas/
+ * tc-loongarch.c Write eflag to elf header.
+
+ include/elf
+ * loongarch.h Define ABI number.
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ gas:LoongArch: Fix wrong line number in .debug_line
+ The dwarf2_emit_insn() can create debuginfo of line. But it is called
+ too late in append_fixp_and_insn. It causes extra offs when debuginfo
+ of line sets address.
+
+ gas/config/
+ * tc-loongarch.c
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ gas:LoongArch: Fix segment error in compilation due to too long symbol name.
+ Change "char buffer[8192];" into "char *buffer =
+ (char *) malloc(1000 + 6 * len_str);" in function
+ loongarch_expand_macro_with_format_map.
+
+ gas/
+ * config/tc-loongarch.c
+
+ include/
+ * opcode/loongarch.h
+
+ opcodes/
+ * loongarch-coder.c
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch: Use functions instead of magic numbers.
+ Replace the magic numbers in gas(tc-loongarch.c) and
+ bfd(elfnn-loongarch.c) with the functions defined in
+ the howto table(elfxx-loongarch.c).
+
+ gas/
+ * config/tc-loongarch.c: use functions.
+
+ bfd/
+ * elfnn-loongarch.c: use functions.
+ * elfxx-loongarch.c: define functions.
+ * elfxx-loongarch.h
+
+2022-03-20 liuzhensong <liuzhensong@loongson.cn>
+
+ ubsan: loongarch : signed integer shift overflow.
+ opcodes/
+ * loongarch-coder.c :
+ int32_t ret = 0;
+ ret <<= sizeof (ret) * 8 - len;
+ ret >>= sizeof (ret) * 8 - len;
+ ...
+ Avoid ubsan warning.
+
+2022-03-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-19 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/python: remove gdb._mi_commands dict
+ The motivation for this patch is the fact that py-micmd.c doesn't build
+ with Python 2, due to PyDict_GetItemWithError being a Python 3-only
+ function:
+
+ CXX python/py-micmd.o
+ /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’:
+ /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’?
+ 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
+ | ^~~~~~~~~~~~~~~~~~~~~~~
+ | PyDict_GetItemString
+
+ A first solution to fix this would be to try to replace
+ PyDict_GetItemWithError equivalent Python 2 code. But I looked at why
+ we are doing this in the first place: it is to maintain the
+ `gdb._mi_commands` Python dictionary that we use as a `name ->
+ gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is
+ never actually used in Python, it seems like a lot of trouble to use a
+ Python object for this.
+
+ My first idea was to replace it with a C++ map
+ (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While
+ implementing this, I realized we don't really need this map at all. The
+ mi_command_py objects registered in the main MI command table can own
+ their backing micmdpy_object (that's a gdb.MICommand, but seen from the
+ C++ code). To know whether an mi_command is an mi_command_py, we can
+ use a dynamic cast. Since there's one less data structure to maintain,
+ there are less chances of messing things up.
+
+ - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
+ now what keeps the MICommand alive.
+ - Set micmdpy_object::mi_command in the constructor of mi_command_py.
+ If mi_command_py manages setting/clearing that field in
+ swap_python_object, I think it makes sense that it also takes care of
+ setting it initially.
+ - Move a bunch of checks from micmdpy_install_command to
+ swap_python_object, and make them gdb_asserts.
+ - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is
+ needed to know whether there's a Python MI command already registered
+ with that name. But we can already tell if there's a non-Python
+ command registered with that name. Return an error if that happens,
+ rather than waiting for insert_mi_cmd_entry to fail. Change the
+ error message to "name is already in use" rather than "may already be
+ in use", since it's more precise.
+
+ I asked Andrew about the original intent of using a Python dictionary
+ object to hold the command objects. The reason was to make sure the
+ objects get destroyed when the Python runtime gets finalized, not later.
+ Holding the objects in global C++ data structures and not doing anything
+ more means that the held Python objects will be decref'd after the
+ Python interpreter has been finalized. That's not desirable. I tried
+ it and it indeed segfaults.
+
+ Handle this by adding a gdbpy_finalize_micommands function called in
+ finalize_python. This is the mirror of gdbpy_initialize_micommands
+ called in do_start_initialization. In there, delete all Python MI
+ commands. I think it makes sense to do it this way: if it was somehow
+ possible to unload Python support from GDB in the middle of a session
+ we'd want to unregister any Python MI command. Otherwise, these MI
+ commands would be backed with a stale PyObject or simply nothing.
+
+ Delete tests that were related to `gdb._mi_commands`.
+
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+ Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
+
+2022-03-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-18 Pedro Alves <pedro@palves.net>
+
+ Fix crash with stepi, no debug info, and "set debug infrun 1"
+ A stepi in a function without debug info with "set debug infrun 1"
+ crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun
+ debug print statements), due to a reference to
+ "tp->current_symtab->filename" when tp->current_symtab is null.
+
+ This commit adds the missing null check. The output in this case
+ becomes:
+
+ [infrun] set_step_info: symtab = <null>, line = 0, step_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}, step_stack_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}
+
+ Change-Id: I5171a9d222bc7e15b9dba2feaba7d55c7acd99f8
+
+2022-03-18 Tom Tromey <tromey@adacore.com>
+
+ Implement gdbarch_stack_frame_destroyed_p for aarch64
+ The internal AdaCore testsuite has a test that checks that an
+ out-of-scope watchpoint is deleted. This fails on some aarch64
+ configurations, reporting an extra stop:
+
+ (gdb) continue
+ Continuing.
+
+ Thread 3 hit Watchpoint 2: result
+
+ Old value = 64
+ New value = 0
+ 0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
+ 13 end Get_Val;
+
+ I believe what is happening here is that the variable is stored at:
+
+ <efa> DW_AT_location : 2 byte block: 91 7c (DW_OP_fbreg: -4)
+
+ and the extra stop is reported just before a return, when the ldp
+ instruction is executed:
+
+ 0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
+ 0x0000000040021648 <+208>: ret
+
+ This instruction modifies the frame base calculation, and so the test
+ picks up whatever memory is pointed to in the callee frame.
+
+ Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
+ this problem.
+
+ As usual with this sort of patch, it has passed internal testing, but
+ I don't have a good way to try it with dejagnu. So, I don't know
+ whether some existing test covers this. I suspect there must be one,
+ but it's also worth noting that this test passes for aarch64 in some
+ configurations -- I don't know what causes one to fail and another to
+ succeed.
+
+2022-03-18 Nick Clifton <nickc@redhat.com>
+
+ Fix Build issues due to patch "gprofng: a new GNU profiler"
+ Find and fix more places where clock_gettime() and CLOCK_MONOTONIC_RAW are used.
+
+2022-03-18 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: run black to format some Python files
+ Seems like some leftovers from previous commits.
+
+ Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83
+
+2022-03-18 Viorel Preoteasa <viorel.preoteasa@gmail.com>
+
+ Fix ld-arm bug in encoding of blx calls jumping from thumb to arm instructions
+ PR 28924
+ * elf32-arm.c (THM_MAX_FWD_BRANCH_OFFSET): Fix definition.
+ (THM2_MAX_FWD_BRANCH_OFFSET): Likewise.
+
+2022-03-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: also fold remaining multi-vector-size shift insns
+ By slightly relaxing the checking in operand_type_register_match() we
+ can fold the vector shift insns with an XMM source as well. While
+ strictly speaking an overlap in just one size (see the code comment) is
+ not enough (both operands could have multiple sizes with just a single
+ common one), this is good enough for all templates we have, or which
+ could sensibly / usefully appear (within the scope of the present
+ operand matching model).
+
+ Tightening this a little would be possible, but would require broadcast
+ related information to be passed into the function.
+
+2022-03-18 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop stray CheckRegSize from VEXTRACT{F,I}32X4
+ They have only a single operand allowing multiple sizes, hence there are
+ no pairs of operands to check for consistent size.
+
+ x86: fold certain AVX2 templates into their AVX counterparts
+ Like for AVX512VL we can make the handling of operand sizes a little
+ more flexible to allow reducing the number of templates we have.
+
+2022-03-18 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Cache management instructions
+ This commit adds 'Zicbom' / 'Zicboz' instructions.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
+ new instruction classes.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_CBO_CLEAN, MASK_CBO_CLEAN,
+ MATCH_CBO_FLUSH, MASK_CBO_FLUSH, MATCH_CBO_INVAL,
+ MASK_CBO_INVAL, MATCH_CBO_ZERO, MASK_CBO_ZERO): New macros.
+ * opcode/riscv.h (enum riscv_insn_class): Add new instruction
+ classes INSN_CLASS_ZICBOM and INSN_CLASS_ZICBOZ.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Add cache-block management
+ instructions.
+
+2022-03-18 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Prefetch hint instructions and operand set
+ This commit adds 'Zicbop' hint instructions.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
+ new instruction class.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_ip): Add handling for new operand
+ type 'f' (32-byte aligned pseudo S-type immediate for prefetch
+ hints).
+ (validate_riscv_insn): Likewise.
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I,
+ MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W,
+ MASK_PREFETCH_W): New macros.
+ * opcode/riscv.h (enum riscv_insn_class): Add new instruction
+ class INSN_CLASS_ZICBOP.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (print_insn_args): Add handling for new operand
+ type.
+ * riscv-opc.c (riscv_opcodes): Add prefetch hint instructions.
+
+2022-03-18 Alan Modra <amodra@gmail.com>
+
+ PR28977 tc-i386.c internal error in parse_register
+ PR 28977
+ * config/tc-i386.c (parse_register): Handle X_op not O_register
+ as for a non-reg_section symbol. Simplify array bounds check.
+
+2022-03-18 Alan Modra <amodra@gmail.com>
+
+ Tidy gas current_frame before exit
+ Releases some obstack memory on an error path.
+
+ * cond.c (cond_finish_check): Call cond_exit_macro.
+
+2022-03-18 Alan Modra <amodra@gmail.com>
+
+ ubsan: logical_input_line signed integer overflow
+ To avoid a completely useless fuzzing ubsan "bug" report, I decided to
+ make logical_input_line unsigned.
+
+ * input-scrub.c (logical_input_line): Make unsigned.
+ (struct input_save): Here too.
+ (input_scrub_reinit, input_scrub_close, bump_line_counters),
+ (as_where): Adjust to suit.
+
+2022-03-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-17 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Skip jsynprog with a broken javac
+ On CET enabled Linux/x86-64 machines, one can get
+
+ $ javac simple.java
+ Error: dl failure on line 894
+ Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled
+
+ Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the
+ jsynprog test with a broken javac.
+
+ PR gprofng/28965
+ * Makefile.am (GPROFNG_BROKEN_JAVAC): New.
+ (check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest.
+ * configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST. Set to yes
+ with a broken javac.
+ * Makefile.in: Regenerate.
+ * configure: Likewise.
+ * testsuite/gprofng.display/display.exp: Skip jsynprog with a
+ broken javac.
+
+2022-03-17 John Baldwin <jhb@FreeBSD.org>
+
+ Remove fall throughs in core_target::xfer_partial.
+ The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
+ can try to fetch different data objects (such as
+ TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
+ aren't present. Return with TARGET_XFER_E_IO if the gdbarch method
+ isn't present instead.
+
+2022-03-17 Pedro Alves <pedro@palves.net>
+
+ gdb: Remove support for S+core
+ GCC removed support for score back in 2014 already. Back then, we
+ basically agreed about removing it from GDB too, but it ended up being
+ forgotten. See:
+
+ https://sourceware.org/pipermail/gdb/2014-October/044643.html
+
+ Following through this time around.
+
+ Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4
+
+2022-03-17 Tom Tromey <tromey@adacore.com>
+
+ Add another test for Ada Wide_Wide_String
+ In an earlier patch, I had written that I wanted to add this test:
+
+ ptype Wide_Wide_String'("literal")
+
+ ... but that it failed with the distro GNAT. Further investigation
+ showed that it could be made to work by adding a function using
+ Wide_Wide_String to the program -- this caused the type to end up in
+ the debug info.
+
+ This patch adds the test. I'm checking this in.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ ubsan: Null dereference in parse_module
+ * vms-alpha.c (parse_module): Sanity check that DST__K_RTNBEG
+ has set module->func_table for DST__K_RTNEND. Check return
+ of bfd_zalloc.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ asan: Buffer overflow in evax_bfd_print_dst
+ With "name" a char*, the length at name[0] might be negative, escaping
+ buffer limit checks.
+
+ * vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*.
+ (evax_bfd_print_emh): Likewise.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ asan: Buffer overflow in som_set_reloc_info
+ * som.c (som_set_reloc_info): Add symcount parameter. Don't
+ access symbols past symcount. Don't access fixup past end_fixups.
+ (som_slurp_reloc_table): Adjust som_set_reloc_info calls.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ asan: use of uninitialized value in buffer_and_nest
+ More occurences of the same as commit d12b8d620c6a.
+
+ * macro.c (buffer_and_nest): Sanity check length in buffer
+ before calling strncasecmp.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ gprofng configure target tests
+ ${target} in configure.ac should be the canonical target, so that for
+ example, someone configuring with --target=x86_64-linux will match
+ x86_64-*-linux*.
+
+ * configure.ac: Invoke AC_CANONICAL_TARGET.
+ * libcollector/configure.ac: Likewise.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * doc/Makefile.in: Regenerate.
+ * gp-display-html/Makefile.in: Regenerate.
+ * libcollector/Makefile.in: Regenerate.
+ * libcollector/configure: Regenerate.
+ * src/Makefile.in: Regenerate.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ Re: asan: buffer overflow in peXXigen.c
+ In the process of fixing a buffer overflow in commit fe69d4fcf0194a,
+ I managed to introduce a fairly obvious NULL pointer dereference..
+
+ * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't
+ segfault on not finding section. Wrap overlong lines.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflows after calling ignore_rest_of_line
+ operand() is not a place that should be calling ignore_rest_of_line.
+ ignore_rest_of_line shouldn't increment input_line_pointer if already
+ at buffer limit.
+
+ * expr.c (operand): Don't call ignore_rest_of_line.
+ * read.c (s_mri_common): Likewise.
+ (ignore_rest_of_line): Don't increment input_line_pointer if
+ already at buffer_limit.
+
+2022-03-17 Alan Modra <amodra@gmail.com>
+
+ Re: bfd: add AMDGCN architecture
+ * po/SRC-POTFILES.in: Regenerate.
+
+2022-03-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: don't accept base architectures as extensions
+ The -march= intentions are quite clear: A base architecture may be
+ followed by any number of extensions. Accepting a base architecture in
+ place of an extension will at best result in confusion, as the first of
+ the two (or more) items specified simply would not take effect, due to
+ being overridden by the later one(s).
+
+2022-03-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: never set i386_cpu_flags' "unused" field
+ Setting this field risks cpu_flags_all_zero() mistakenly returning
+ "false" when the object passed in was e.g. the result of ANDing together
+ two objects which had the bit set, or ANDNing together an object with
+ the field set and one with the field clear.
+
+ While there also avoid setting CpuNo64: Like Cpu64 this is driven
+ differently anyway and hence shouldn't be set anywhere by default.
+
+ Note that the moving of the two items in i386-gen.c's cpu_flags[] is
+ only for documentation purposes (and slight reducing of overhead), as
+ the fields are sorted anyway upon program start.
+
+2022-03-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: unify CPU flag on/off processing
+ There's no need for the arbitrary special "unknown" token: Simply
+ recognize the leading ~ and process everything else the same, merely
+ recording whether to set individual fields to 1 or 0.
+
+ While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS
+ override cpu_arch_flags anyway when -march=iamcu is passed, and there's
+ no reason to have the stray flag set even if no insn actually is keyed
+ to it.
+
+2022-03-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: add another IAMCU testcase
+ Now that {L,K}1OM support is gone, and with it the brokenness in
+ check_cpu_arch_compatible(), put in place a test making sure that only
+ extensions can be enabled via .arch for IAMCU, and that the base
+ architecture cannot be changed.
+
+ x86: drop L1OM/K1OM support from gas
+ This was only rudimentary support anyway; none of the sub-architecture
+ specific insns were ever supported.
+
+ x86: assorted IAMCU CPU checking fixes
+ The checks done by check_cpu_arch_compatible() were halfway sensible
+ only at the time where only L1OM support was there. The purpose,
+ however, has always been to prevent bad uses of .arch (turning off the
+ base CPU "feature" flag) while at the same time permitting extensions to
+ be enabled / disabled. In order to achieve this (and to prevent
+ regressions when L1OM and K1OM support are removed)
+ - set CpuIAMCU in CPU_IAMCU_FLAGS,
+ - adjust the IAMCU check in the function itself (the other two similarly
+ broken checks aren't adjusted as they're slated to be removed anyway),
+ - avoid calling the function for extentions (which would never have the
+ base "feature" flag set),
+ - add a new testcase actually exercising ".arch iamcu" (which would also
+ regress with the planned removal).
+
+2022-03-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: work around prompt corruption caused by bracketed-paste-mode
+ In this commit:
+
+ commit b4f26d541aa7224b70d363932e816e6e1a857633
+ Date: Tue Mar 2 13:42:37 2021 -0700
+
+ Import GNU Readline 8.1
+
+ We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
+ was reported. This bug spotted that, when the user terminated GDB by
+ sending EOF (usually bound to Ctrl+d), the last prompt would become
+ corrupted. Here's what happens, the user is sat at a prompt like
+ this:
+
+ (gdb)
+
+ And then the user sends EOF (Ctrl+d), we now see this:
+
+ quit)
+ ... gdb terminates, and we return to the shell ...
+
+ Notice the 'quit' was printed over the prompt.
+
+ This problem is a result of readline 8.1 enabling bracketed paste mode
+ by default. This problem is present in readline 8.0 too, but in that
+ version of readline bracketed paste mode is off by default, so a user
+ will not see the bug unless they specifically enable the feature.
+
+ Bracketed paste mode is available in readline 7.0 too, but the bug
+ is not present in this version of readline, see below for why.
+
+ What causes this problem is how readline disables bracketed paste
+ mode. Bracketed paste mode is a terminal feature that is enabled and
+ disabled by readline emitting a specific escape sequence. The problem
+ for GDB is that the escape sequence to disable bracketed paste mode
+ includes a '\r' character at the end, see this thread for more
+ details:
+
+ https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
+
+ The change to add the '\r' character to the escape sequence used to
+ disable bracketed paste mode was introduced between readline 7.0 and
+ readline 8.0, this is why the bug would not occur when using older
+ versions of readline (note: I don't know if its even possible to build
+ GDB using readline 7.0. That really isn't important, I'm just
+ documenting the history of this issue).
+
+ So, the escape sequence to disable bracketed paste mode is emitted
+ from the readline function rl_deprep_terminal, this is called after
+ the user has entered a complete command and pressed return, or, if the
+ user sends EOF.
+
+ However, these two cases are slightly different. In the first case,
+ when the user has entered a command and pressed return, the cursor
+ will have moved to the next, empty, line, before readline emits the
+ escape sequence to leave bracketed paste mode. The final '\r'
+ character moves the cursor back to the beginning of this empty line,
+ which is harmless.
+
+ For the EOF case though, this is not what happens. Instead, the
+ escape sequence to leave bracketed paste mode is emitted on the same
+ line as the prompt. The final '\r' moves the cursor back to the start
+ of the prompt line. This leaves us ready to override the prompt.
+
+ It is worth noting, that this is not the intended behaviour of
+ readline, in rl_deprep_terminal, readline should emit a '\n' character
+ when EOF is seen. However, due to a bug in readline this does not
+ happen (the _rl_eof_found flag is never set). This is the first
+ readline bug that effects GDB.
+
+ GDB prints the 'quit' message from command_line_handler (in
+ event-top.c), this function is called (indirectly) from readline to
+ process the complete command line, but also in the EOF case (in which
+ case the command line is set to nullptr). As this is part of the
+ callback to process a complete command, this is called after readline
+ has disabled bracketed paste mode (by calling rl_deprep_terminal).
+
+ And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
+ the cursor at the start of the prompt line (in the EOF case), and
+ command_line_handler then prints 'quit', which overwrites the prompt.
+
+ The solution to this problem is to print the 'quit' message earlier,
+ before rl_deprep_terminal is called. This is easy to do by using the
+ rl_deprep_term_function hook. It is this hook that usually calls
+ rl_deprep_terminal, however, if we replace this with a new function,
+ we can print the 'quit' string, and then call rl_deprep_terminal
+ ourselves. This allows the 'quit' to be printed before
+ rl_deprep_terminal is called.
+
+ The problem here is that there is no way in rl_deprep_terminal to know
+ if readline is processing EOF or not, and as a result, we don't know
+ when we should print 'quit'. This is the second readline bug that
+ effects GDB.
+
+ Both of these readline issues are discussed in this thread:
+
+ https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
+
+ The result of that thread was that readline was patched to address
+ both of these issues.
+
+ Now it should be easy to backport the readline fix to GDB's in tree
+ copy of readline, and then change GDB to make use of these fixes to
+ correctly print the 'quit' string.
+
+ However, we are just about to branch GDB 12, and there is concern from
+ some that changing readline this close to a new release is a risky
+ idea, see this thread:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
+
+ So, this commit doesn't change readline at all. Instead, this commit
+ is the smallest possible GDB change in order to avoid the prompt
+ corruption.
+
+ In this commit I change GDB to print the 'quit' string on the line
+ after the prompt, but only when bracketed paste mode is on. This
+ avoids the overwriting issue, the user sees this:
+
+ (gdb)
+ quit
+ ... gdb terminates, and returns to the shell ...
+
+ This isn't ideal, but is better than the existing behaviour. After
+ GDB 12 has branched, we can backport the readline fix, and apply a
+ real fix to GDB.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-03-16 Fangrui Song <i@maskray.me>
+
+ objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbols
+ PR binutils/28926
+ * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols
+ * NEWS: Mention feature.
+ * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test.
+ * testsuite/binutils-all/weaken-gnu-unique.s: New.
+
+2022-03-16 Tom Tromey <tromey@adacore.com>
+
+ Reimplement array concatenation for Ada and D
+ This started as a patch to implement string concatenation for Ada.
+ However, while working on this, I looked at how this code could
+ possibly be called. It turns out there are only two users of
+ concat_operation: Ada and D. So, in addition to implementing this for
+ Ada, this patch rewrites value_concat, removing the odd "concatenate
+ or repeat" semantics, which were completely unused. As Ada and D both
+ seem to represent strings using TYPE_CODE_ARRAY, this removes the
+ TYPE_CODE_STRING code from there as well.
+
+ Remove eval_op_concat
+ eval_op_concat has code to search for an operator overload of
+ BINOP_CONCAT. However, the operator overloading code is specific to
+ C++, which does not have this operator. And,
+ binop_types_user_defined_p rejects this case right at the start, and
+ value_x_binop does not handle this case. I think this code has been
+ dead for a very long time. This patch removes it and hoists the
+ remaining call into concatenation::evaluate, removing eval_op_concat
+ entirely.
+
+2022-03-16 Tom Tromey <tromey@adacore.com>
+
+ Ada support for wide strings
+ This adds some basic support for Wide_String and Wide_Wide_String to
+ the Ada expression evaluator. In particular, a string literal may be
+ converted to a wide or wide-wide string depending on context.
+
+ The patch updates an existing test case. Note that another test,
+ namely something like:
+
+ ptype Wide_Wide_String'("literal")
+
+ ... would be nice to add, but when tested against a distro GNAT, this
+ did not work (probably due to lack of debuginfo); so, I haven't
+ included it here.
+
+2022-03-16 Tom Tromey <tromey@adacore.com>
+
+ Remove eval_op_string
+ eval_op_string is only used in a single place -- the implementation of
+ string_operation. This patch turns it into the
+ string_operation::evaluate method, removing a bit of extraneous code.
+
+2022-03-16 Carl Love <cel@us.ibm.com>
+
+ Powerpc fix for gdb.base/ending-run.exp
+ The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
+ system does not have the needed glibc debug-info files loaded. In this
+ case, gdb is not able to determine where execution stopped. This behavior
+ looks as follows for the test case:
+
+ The next to the last test does a next command when the program is stopped
+ at the closing bracket for main. The message printed is:
+
+ 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
+
+ which fails to match any of the test_multiple options.
+
+ The test then does another next command. On Powerpc, the
+ message printed it:
+
+ Cannot find bounds of current function
+
+ The test fails as the output does not match any of the options for the
+ gdb_test_multiple.
+
+ I checked the behavior on Powerpc to see if this is typical.
+ I ran gdb on the following simple program as shown below.
+
+ #include <stdio.h>
+ int
+ main(void)
+ {
+ printf("Hello, world!\n");
+ return 0;
+ }
+
+ gdb ./hello_world
+ <snip the gdb start info>
+
+ Type "apropos word" to search for commands related to "word"...
+ Reading symbols from ./hello_world...
+ (No debugging symbols found in ./hello_world)
+ (gdb) break main
+ Breakpoint 1 at 0x818
+ (gdb) r
+
+ Starting program: /home/carll/hello_world
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
+
+ Breakpoint 1, 0x0000000100000818 in main ()
+ (gdb) n
+ Single stepping until exit from function main,
+ which has no line number information.
+ Hello, world!
+ 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
+ (gdb) n
+ Cannot find bounds of current function
+
+ So it would seem that the messages seen from the test case are
+ "normal" output for Powerpc when the debug-info is not available.
+
+ The following patch adds the output from Powerpc as an option
+ to the gdb_test_multiple statement, identifying the output as the expected
+ output on Powerpc without the needed debug-info files installed.
+
+ The patch has been tested on a Power 10 system and an Intel
+ 64-bit system. No additional regression failures were seen on
+ either platform.
+
+2022-03-16 Martin Storsj? <martin@martin.st>
+
+ dlltool: Use the output name as basis for deterministic temp prefixes
+ PR 28885
+ * dlltool.c (main): use imp_name rather than dll_name when
+ generating a temporary file name.
+
+2022-03-16 Jan Vrany <jan.vrany@labware.com>
+ Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: consistently notify user when GDB/MI client uses -thread-select
+ GDB notifies users about user selected thread changes somewhat
+ inconsistently as mentioned on gdb-patches mailing list here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html
+
+ Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI
+ interfaces connected to separate terminals.
+
+ Assuming inferior is stopped and thread 1 is selected, when a thread
+ 2 is selected using '-thread-select 2' command on GDB/MI terminal:
+
+ -thread-select 2
+ ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"}
+ (gdb)
+
+ and on CLI terminal we get the notification (as expected):
+
+ [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))]
+ #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30
+ 30 volatile int dummy = 0;
+
+ However, now that thread 2 is selected, if thread 1 is selected
+ using 'thread-select --thread 1 1' command on GDB/MI terminal
+ terminal:
+
+ -thread-select --thread 1 1
+ ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"}
+ (gdb)
+
+ but no notification is printed on CLI terminal, despite the fact
+ that user selected thread has changed.
+
+ The problem is that when `-thread-select --thread 1 1` is executed
+ then thread is switched to thread 1 before mi_cmd_thread_select () is
+ called, therefore the condition "inferior_ptid != previous_ptid"
+ there does not hold.
+
+ To address this problem, we have to move notification logic up to
+ mi_cmd_execute () where --thread option is processed and notify
+ user selected contents observers there if context changes.
+
+ However, this in itself breaks GDB/MI because it would cause context
+ notification to be sent on MI channel. This is because by the time
+ we notify, MI notification suppression is already restored (done in
+ mi_command::invoke(). Therefore we had to lift notification suppression
+ logic also up to mi_cmd_execute (). This change in made distinction
+ between mi_command::invoke() and mi_command::do_invoke() unnecessary
+ as all mi_command::invoke() did (after the change) was to call
+ do_invoke(). So this patches removes do_invoke() and moves the command
+ execution logic directly to invoke().
+
+ With this change, all gdb.mi tests pass, tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
+
+2022-03-16 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Use symver attribute if available
+ Use symver attribute if available, instead of asm statement, to support
+ LTO build.
+
+ PR gprof/28962
+ * libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use
+ SYMVER_ATTRIBUTE.
+ (timer_create@GLIBC_2.2): Likewise.
+ (timer_create@GLIBC_2.2.5): Likewise.
+ (pthread_create@@GLIBC_2.1): Likewise.
+ (pthread_create@GLIBC_2.0): Likewise.
+ * libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise.
+ (open64@GLIBC_2.1): Likewise.
+ (fopen@@GLIBC_2.1): Likewise.
+ (fopen@GLIBC_2.0): Likewise.
+ (fclose@@GLIBC_2.1): Likewise.
+ (fclose@GLIBC_2.0): Likewise.
+ (fdopen@@GLIBC_2.1): Likewise.
+ (fdopen@GLIBC_2.0): Likewise.
+ (pread@@GLIBC_2.2): Likewise.
+ (pread@GLIBC_2.1): Likewise.
+ (pwrite@@GLIBC_2.2): Likewise.
+ (pwrite@GLIBC_2.1): Likewise.
+ (pwrite64@@GLIBC_2.2): Likewise.
+ (pwrite64@GLIBC_2.1): Likewise.
+ (fgetpos@@GLIBC_2.2): Likewise.
+ (fgetpos@GLIBC_2.0): Likewise.
+ (fgetpos64@@GLIBC_2.2): Likewise.
+ (fgetpos64@GLIBC_2.1): Likewise.
+ (fsetpos@@GLIBC_2.2): Likewise.
+ (fsetpos@GLIBC_2.0): Likewise.
+ (fsetpos64@@GLIBC_2.2): Likewise.
+ (fsetpos64@GLIBC_2.1): Likewise.
+ * libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise.
+ (posix_spawn@GLIBC_2.2): Likewise.
+ (posix_spawn@GLIBC_2.2.5): Likewise.
+ (posix_spawnp@@GLIBC_2.15): Likewise.
+ (posix_spawnp@GLIBC_2.2): Likewise.
+ (posix_spawnp@GLIBC_2.2.5): Likewise.
+ (popen@@GLIBC_2.1): Likewise.
+ (popen@GLIBC_2.0): Likewise.
+ (_popen@@GLIBC_2.1): Likewise.
+ (_popen@GLIBC_2.0): Likewise.
+ * libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise.
+ (dlopen@GLIBC_2.0): Likewise.
+ * libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2):
+ Likewise.
+ (pthread_cond_wait@GLIBC_2.0): Likewise.
+ (pthread_cond_wait@GLIBC_2.2.5): Likewise.
+ (pthread_cond_wait@GLIBC_2.2): Likewise.
+ (pthread_cond_timedwait@@GLIBC_2.3.2): Likewise.
+ (pthread_cond_timedwait@GLIBC_2.0): Likewise.
+ (pthread_cond_timedwait@GLIBC_2.2.5): Likewise.
+ (pthread_cond_timedwait@GLIBC_2.2): Likewise.
+ (sem_wait@@GLIBC_2.1): Likewise.
+ (sem_wait@GLIBC_2.0): Likewise.
+ * src/collector_module.h (SYMVER_ATTRIBUTE): New.
+
+2022-03-16 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Don't hardcode -Wno-format-truncation/-Wno-switch
+ Use -Wno-format-truncation and -Wno-switch only if they are supported.
+
+ PR gprof/28969
+ * configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New
+ AC_SUBST for -Wno-format-truncation.
+ (GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch.
+ * Makefile.in: Regenerate.
+ * configure: Likewise.
+ * src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation
+ and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and
+ GPROFNG_NO_SWITCH_CFLAGS.
+ * src/Makefile.in: Regenerate.
+
+2022-03-16 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Don't hardcode -Wno-nonnull-compare
+ Use -Wno-nonnull-compare only if it is supported.
+
+ PR gprof/28969
+ * libcollector/Makefile.am (AM_CFLAGS): Replace
+ -Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS.
+ * libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS):
+ New AC_SUBST for -Wno-nonnull-compare.
+ * libcollector/Makefile.in: Regenerate.
+ * libcollector/aclocal.m4: Likewise.
+ * libcollector/configure: Likewise.
+
+2022-03-16 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Define ATTRIBUTE_FALLTHROUGH
+ Define ATTRIBUTE_FALLTHROUGH to __attribute__ ((fallthrough)) only for
+ GCC 7 or above.
+
+ PR gprof/28969
+ * common/gp-defs.h (ATTRIBUTE_FALLTHROUGH): New.
+ * src/gp-collect-app.cc (collect::check_args): Replace
+ /* FALLTHROUGH */ with ATTRIBUTE_FALLTHROUGH.
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ binutils/readelf: handle AMDGPU relocation types
+ Make readelf recognize AMDGPU relocation types, as documented here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#amdgpu-relocation-records
+
+ The user-visible change looks like:
+
+ -000000000004 000400000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD0
+ -00000000000c 000500000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD1
+ -000000000014 000600000007 unrecognized: 7 0000000000000000 global_var0
+ -00000000001c 000700000008 unrecognized: 8 0000000000000000 global_var1
+ -000000000024 000800000009 unrecognized: 9 0000000000000000 global_var2
+ -00000000002c 00090000000a unrecognized: a 0000000000000000 global_var3
+ -000000000034 000a0000000b unrecognized: b 0000000000000000 global_var4
+ +000000000004 000400000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD0
+ +00000000000c 000500000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD1
+ +000000000014 000600000007 R_AMDGPU_GOTPCREL 0000000000000000 global_var0
+ +00000000001c 000700000008 R_AMDGPU_GOTPCREL 0000000000000000 global_var1
+ +000000000024 000800000009 R_AMDGPU_GOTPCREL 0000000000000000 global_var2
+ +00000000002c 00090000000a R_AMDGPU_REL32_LO 0000000000000000 global_var3
+ +000000000034 000a0000000b R_AMDGPU_REL32_HI 0000000000000000 global_var4
+
+ binutils/ChangeLog:
+
+ * readelf.c (dump_relocations): Handle EM_AMDGPU.
+
+ include/ChangeLog:
+
+ * elf/amdgpu.h: Add relocation values.
+
+ Change-Id: I2ed4589f4cd37ea11ad2e0cb38d4b682271e1334
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ binutils/readelf: build against msgpack, dump NT_AMDGPU_METADATA note contents
+ The AMDGPU HSA OS ABI (code object v3 and above) defines the
+ NT_AMDGPU_METADATA ELF note [1]. The content is a msgpack object
+ describing, among other things, the kernels present in the code object
+ and how to call them.
+
+ I think it would be useful for readelf to be able to display the content
+ of those notes. msgpack is a structured format, a bit like JSON, except
+ not text-based. It is therefore possible to dump the contents in
+ human-readable form without knowledge of the specific layout of the
+ note.
+
+ Add configury to binutils to optionally check for the msgpack C library
+ [2]. Add There is a new --with{,out}-msgpack configure flag, and the actual
+ library lookup is done using pkg-config.
+
+ If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks
+ like:
+
+ $ readelf --notes amdgpu-code-object
+ Displaying notes found in: .note
+ Owner Data size Description
+ AMDGPU 0x0000040d NT_AMDGPU_METADATA (code object metadata)
+ {
+ "amdhsa.kernels": [
+ {
+ ".args": [
+ {
+ ".address_space": "global",
+ ".name": "out.coerce",
+ ".offset": 0,
+ ".size": 8,
+ ".value_kind": "global_buffer",
+ },
+ <snip>
+
+ If msgpack support is disabled, dump the contents as hex, as is done
+ with notes that are not handled in a special way. This allows one to
+ decode the contents manually (maybe using a command-line msgpack
+ decoder) if really needed.
+
+ [1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata
+ [2] https://github.com/msgpack/msgpack-c/tree/c_master
+
+ binutils/ChangeLog:
+
+ * Makefile.am (readelf_CFLAGS): New.
+ (readelf_LDADD): Add MSGPACK_LIBS.
+ * Makefile.in: Re-generate.
+ * config.in: Re-generate.
+ * configure: Re-generate.
+ * configure.ac: Add --with-msgpack flag and check for msgpack
+ using pkg-config.
+ * readelf.c: Include msgpack.h if HAVE_MSGPACK.
+ (print_note_contents_hex): New.
+ (print_indents): New.
+ (dump_msgpack_obj): New.
+ (dump_msgpack): New.
+ (print_amdgpu_note): New.
+ (process_note): Handle NT_AMDGPU_METADATA note contents.
+ Use print_note_contents_hex.
+
+ Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ binutils/readelf: handle NT_AMDGPU_METADATA note name
+ Handle the NT_AMDGPU_METADATA note, which is described here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records
+
+ As of this patch, just print out the name, not the contents, which is in
+ the msgpack format.
+
+ binutils/ChangeLog:
+
+ * readelf.c (get_amdgpu_elf_note_type): New.
+ (process_note): Handle "AMDGPU" notes.
+
+ include/ChangeLog:
+
+ * elf/amdgcn.h (NT_AMDGPU_METADATA): New.
+
+ Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ binutils/readelf: decode AMDGPU-specific e_flags
+ Decode and print the AMDGPU-specific fields of e_flags, as documented
+ here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#header
+
+ That is:
+
+ - The specific GPU model
+ - Whether the xnack and sramecc features are enabled
+
+ The result looks like:
+
+ - Flags: 0x52f
+ + Flags: 0x52f, gfx906, xnack any, sramecc any
+
+ The flags for the "HSA" OS ABI are properly versioned and documented on
+ that page. But the NONE, PAL and MESA3D OS ABIs are not well documented
+ nor versioned. Taking a peek at the LLVM source code, we see that they
+ encode their flags the same way as HSA v3. For example, for PAL:
+
+ https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601
+
+ So for those other OS ABIs, we read them the same as HSA v3.
+
+ binutils/ChangeLog:
+
+ * readelf.c: Include elf/amdgcn.h.
+ (decode_AMDGPU_machine_flags): New.
+ (get_machine_flags): Handle flags for EM_AMDGPU machine type.
+
+ include/ChangeLog:
+
+ * elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and
+ EF_AMDGPU_FEATURE_* defines.
+
+ Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ binutils/readelf: handle AMDGPU OS ABIs
+ When the machine is EM_AMDGPU, handle the various OS ABIs described
+ here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#header
+
+ For a binary with the HSA OS ABI, the change looks like:
+
+ - OS/ABI: <unknown: 40>
+ + OS/ABI: AMD HSA
+
+ binutils/ChangeLog:
+
+ * readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs.
+
+ include/ChangeLog:
+
+ * elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D):
+ New.
+
+ Change-Id: I383590c390f7dc2fe0f902f50038735626d71863
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ opcodes: handle bfd_amdgcn_arch in configure script
+ There isn't an actual opcodes implementation for the AMDGCN arch (yet),
+ this is just the bare minimum to get
+
+ $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
+ $ make all-binutils
+
+ working later in this series.
+
+ opcodes/ChangeLog:
+
+ * configure.ac: Handle bfd_amdgcn_arch.
+ * configure: Re-generate.
+
+ Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
+
+2022-03-16 Simon Marchi <simon.marchi@efficios.com>
+
+ bfd: add AMDGCN architecture
+ Add support for the AMDGCN architecture to BFD.
+
+ This is the bare minimum to get
+
+ $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
+ $ make all-binutils
+
+ working later in this series.
+
+ The specific AMDGCN models added here are a bit arbitrary, based on
+ what we intend to initially support in GDB. This list will need to be
+ updated in the future anyway. The complete up-to-date list of existing
+ AMDGPU models can be found here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#processors
+
+ The ELF format for this architecture is documented here:
+
+ https://llvm.org/docs/AMDGPUUsage.html#elf-code-object
+
+ The flags for the "HSA" OS ABI are properly versioned and documented on
+ that page. But the NONE, PAL and MESA3D OS ABIs are not well documented
+ nor versioned. Taking a peek at the LLVM source code, we see that they
+ encode their flags the same way as HSA v3. For example, for PAL:
+
+ https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601
+
+ So at least, we know that all AMDGPU objects (of which AMDGCN objects
+ are a subset of) at the time of writing encode the specific GPU model in
+ the EF_AMDGPU_MACH field of e_flags.
+
+ bfd/ChangeLog:
+
+ * Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES):
+ Add cpu-amdgcn.c.
+ (BFD64_BACKENDS): Add elf64-amdgcn.lo.
+ (BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c.
+ * Makefile.in: Re-generate.
+ * cpu-amdgcn.c: New.
+ * elf64-amdgcn.c: New.
+ * archures.c (bfd_architecture): Add bfd_arch_amdgcn and related
+ mach defines.
+ (bfd_amdgcn_arch): New.
+ (bfd_archures_list): Add bfd_amdgcn_arch.
+ * bfd-in2.h: Re-generate.
+ * config.bfd: Handle amdgcn* target.
+ * configure.ac: Handle amdgcn_elf64_le_vec.
+ * configure: Re-generate.
+ * elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA.
+ * targets.c (amdgcn_elf64_le_vec): New.
+ (_bfd_target_vector): Add amdgcn_elf64_le_vec.
+
+ include/ChangeLog:
+
+ * elf/amdgpu.h: New.
+ * elf/common.h (ELFOSABI_AMDGPU_HSA): Add.
+
+ Change-Id: I969f7b14960797e88891c308749a6e341eece5b2
+
+2022-03-16 Nick Clifton <nickc@redhat.com>
+
+ Updated Serbian (for binutils/) and Russian (for gprof/) translations
+
+2022-03-16 Pedro Alves <pedro@palves.net>
+
+ Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserver
+ gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were
+ recently disabled unless testing with the native target, because they
+ rely on inferior I/O. However, when testing against gdbserver using
+ the native-gdbserver/native-extended-gdbserver boards, we do have
+ access to inferior I/O.
+
+ The right way to check whether the board can do I/O, is via checking
+ the gdb,noinferiorio board variable. Switch to using that.
+
+ And then, tweak the testcases to expect output to appear in
+ inferior_spawn_id, instead of gdb_spawn_id. When testing against the
+ native target, inferior_spawn_id is the same as gdb_spawn_id. When
+ testing against gdbserver, it maps to gdbserver_spawn_id.
+
+ This exposed a buglet in gdb.fortran/array-slices.f90's show_1d
+ subroutine -- it was missing printing newline at the end of the
+ "Expected GDB Output" text, leading to a test timeout. All other
+ subroutines end with advance=yes, except this one. Fix it by using
+ advance=yes here too.
+
+ Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5
+
+2022-03-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-15 Alan Modra <amodra@gmail.com>
+
+ Delete PowerPC macro insn support
+ Let's hope this stays dead, but it's here as a patch separate from
+ those that removed use of powerpc_macros just in case it needs to be
+ resurrected.
+
+ include/
+ * opcode/ppc.h (struct powerpc_macro): Delete declaration.
+ (powerpc_macros, powerpc_num_macros): Likewise..
+ opcodes/
+ * ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete.
+ gas/
+ * config/tc-ppc.c (ppc_macro): Delete function.
+ (ppc_macro_hash): Delete.
+ (ppc_setup_opcodes, md_assemble): Delete macro support.
+
+2022-03-15 Alan Modra <amodra@gmail.com>
+
+ PowerPC SPE/SPE2 aliases in powerpc_macros
+ * ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs",
+ "evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt",
+ "evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui",
+ "evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz",
+ "evststgt", "evststlt", "evststeq"..
+ (powerpc_opcodes): ..to here.
+ (powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi",
+ and "evdotpwsssia"..
+ (spe2_opcodes): ..to here.
+
+2022-03-15 Alan Modra <amodra@gmail.com>
+
+ PowerPC VLE extended instructions in powerpc_macros
+ This moves VLE insn out of the macro table. "e_slwi" and "e_srwi"
+ already exist in vle_opcodes as distinct instructions rather than
+ encodings of e_rlwinm.
+
+ opcodes/
+ * ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand.
+ Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi",
+ "e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi".
+ (powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too.
+ gas/
+ * testsuite/gas/ppc/vle-simple-5.d: Update.
+
+2022-03-15 Alan Modra <amodra@gmail.com>
+
+ PowerPC32 extended instructions in powerpc_macros
+ As for PowerPC64, move instructions to the main opcode table.
+
+ opcodes/
+ * ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn),
+ (insert_erwn, extract_erwn, insert_erwb, extract_erwb),
+ (insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn),
+ (insert_irwb, extract_irwn, insert_rrwn, extract_rrwn),
+ (insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions.
+ (CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb),
+ (RRWn, SLWn, SRWn): Define and add powerpc_operands entries.
+ (MMB_MASK, MME_MASK, MSHMB_MASK): Define.
+ (powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi",
+ "slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding
+ record (ie. dot suffix) forms.
+ (powerpc_macros): Delete same.
+ gas/
+ * testsuite/gas/ppc/476.d: Update.
+ * testsuite/gas/ppc/simpshft.d: Update.
+
+2022-03-15 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 extended instructions in powerpc_macros
+ The extended instructions implemented in powerpc_macros aren't used by
+ the disassembler. That means instructions like "sldi r3,r3,2" appear
+ in disassembly as "rldicr r3,r3,2,61", which is annoying since many
+ other extended instructions are shown.
+
+ Note that some of the instructions moved out of the macro table to the
+ opcode table won't appear in disassembly, because they are aliases
+ rather than a subset of the underlying raw instruction. If enabled,
+ rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all
+ occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many
+ occurrences in the case of clrlsldi if n <= b was added to the extract
+ functions.)
+
+ The patch also fixes a small bug in opcode sanity checking.
+
+ include/
+ * opcode/ppc.h (PPC_OPSHIFT_SH6): Define.
+ opcodes/
+ * ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn),
+ (insert_crdn, extract_crdn, insert_rrdn, extract_rrdn),
+ (insert_sldn, extract_sldn, insert_srdn, extract_srdn),
+ (insert_erdb, extract_erdb, insert_csldn, extract_csldb),
+ (insert_irdb, extract_irdn): New functions.
+ (ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb):
+ Define and add associated powerpc_operands entries.
+ (powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi",
+ "sldi", "extldi", "clrlsldi", "insrdi" and corresponding record
+ (ie. dot suffix) forms.
+ (powerpc_macros): Delete same from here.
+ gas/
+ * config/tc-ppc.c (insn_validate): Don't modify value passed
+ to operand->insert for PPC_OPERAND_PLUS1 when calculating mask.
+ Handle PPC_OPSHIFT_SH6.
+ * testsuite/gas/ppc/prefix-reloc.d: Update.
+ * testsuite/gas/ppc/simpshft.d: Update.
+ ld/
+ * testsuite/ld-powerpc/elfv2so.d: Update.
+ * testsuite/ld-powerpc/notoc.d: Update.
+ * testsuite/ld-powerpc/notoc3.d: Update.
+ * testsuite/ld-powerpc/tlsdesc2.d: Update.
+ * testsuite/ld-powerpc/tlsget.d: Update.
+ * testsuite/ld-powerpc/tlsget2.d: Update.
+ * testsuite/ld-powerpc/tlsopt5.d: Update.
+ * testsuite/ld-powerpc/tlsopt6.d: Update.
+
+2022-03-15 Tom Tromey <tom@tromey.com>
+
+ Do not capture updated 'pc' in add_local_symbols
+ Simon pointed out that commit 13835d88 ("Use function view when
+ iterating over block symbols") caused a regression. The bug is that
+ the new closure captures 'pc' by reference, but later code updates
+ this variable -- but the earlier code did not update the callback
+ structure with the new value.
+
+ This patch restores the old behavior by using a new varible name in an
+ inner scope.
+
+2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ gprofng: avoid using `fallthrough' attributes
+ gprofng didn't build with gcc 6.3 due to the usage of __attribute__
+ ((fallthrough)). This patch uses /* FALLTHROUGH */ instead.
+
+ 2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * gprofng/src/gp-collect-app.cc (collect::check_args): Use
+ fallthrough comment instead of attribute.
+
+2022-03-15 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in dwarf-mode.el
+ I noticed that, occasionally, dwarf-mode would think that the objdump
+ subprocess was still running after it had clearly exited. I managed
+ to reliably reproduce this today and learned that a process sentinel
+ is not guaranteed to be run with the current buffer set to the process
+ buffer. This patch fixes the problem.
+
+ I've bumped the version number of dwarf-mode.el to make it easier to
+ install for users who already have an earlier one installed.
+
+ I'm checking this in.
+
+ 2022-03-15 Tom Tromey <tromey@adacore.com>
+
+ * dwarf-mode.el: Now 1.7.
+ (dwarf--sentinel): Switch to the process buffer.
+
+2022-03-15 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: rename a proc and fix a typo
+ Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the
+ old name was most likely a typo. The old name
+ match_re_or_ensure_not_output seems (to me) to imply we're in some way
+ checking that the regexp was not output. But that's not what we are
+ doing, we're checking either for the regexp, or for no output, hence
+ the new name match_re_or_ensure_no_output.
+
+ Additionally, I found a definite typo in one of the comments that I've
+ also fixed.
+
+ I also updated some test names. These tests (probably due to copy &
+ paste errors) has 'on MI' on their name, when they were actually
+ checking CLI output. For these test I changed the name to use 'on
+ CLI'.
+
+ There should be no change in what is tested after this commit.
+
+2022-03-15 Nick Clifton <nickc@redhat.com>
+
+ gprofng: Add a configure test for clock_gettime and a use of the test in getthrtime.c
+
+2022-03-15 H.J. Lu <hjl.tools@gmail.com>
+
+ gprofng: Don't generate gprofng.info in source
+ Add info-in-builddir to AUTOMAKE_OPTIONS.
+
+ PR gprof/28967
+ * doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir.
+ * doc/Makefile.in: Regenerate.
+
+2022-03-15 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: fix failed testcases in gdb.base/align-c.exp
+ When execute the following command on LoongArch:
+
+ make check-gdb TESTS="gdb.base/align-c.exp"
+
+ there exist some failed testcases:
+
+ ...
+ FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float)
+ FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double)
+ FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double)
+ ...
+
+ According to LoongArch ELF ABI specification [1], set the target data types
+ of floating-point to fix the above failed testcases.
+
+ [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
+
+2022-03-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python/mi: create MI commands using python
+ This commit allows a user to create custom MI commands using Python
+ similarly to what is possible for Python CLI commands.
+
+ A new subclass of mi_command is defined for Python MI commands,
+ mi_command_py. A new file, gdb/python/py-micmd.c contains the logic
+ for Python MI commands.
+
+ This commit is based on work linked too from this mailing list thread:
+
+ https://sourceware.org/pipermail/gdb/2021-November/049774.html
+
+ Which has also been previously posted to the mailing list here:
+
+ https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html
+
+ And was recently reposted here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html
+
+ The version in this patch takes some core code from the previously
+ posted patches, but also has some significant differences, especially
+ after the feedback given here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html
+
+ A new MI command can be implemented in Python like this:
+
+ class echo_args(gdb.MICommand):
+ def invoke(self, args):
+ return { 'args': args }
+
+ echo_args("-echo-args")
+
+ The 'args' parameter (to the invoke method) is a list
+ containing (almost) all command line arguments passed to the MI
+ command (--thread and --frame are handled before the Python code is
+ called, and removed from the args list). This list can be empty if
+ the MI command was passed no arguments.
+
+ When used within gdb the above command produced output like this:
+
+ (gdb)
+ -echo-args a b c
+ ^done,args=["a","b","c"]
+ (gdb)
+
+ The 'invoke' method of the new command must return a dictionary. The
+ keys of this dictionary are then used as the field names in the mi
+ command output (e.g. 'args' in the above).
+
+ The values of the result returned by invoke can be dictionaries,
+ lists, iterators, or an object that can be converted to a string.
+ These are processed recursively to create the mi output. And so, this
+ is valid:
+
+ class new_command(gdb.MICommand):
+ def invoke(self,args):
+ return { 'result_one': { 'abc': 123, 'def': 'Hello' },
+ 'result_two': [ { 'a': 1, 'b': 2 },
+ { 'c': 3, 'd': 4 } ] }
+
+ Which produces output like:
+
+ (gdb)
+ -new-command
+ ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}]
+ (gdb)
+
+ I have required that the fields names used in mi result output must
+ match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes).
+ This restriction was never written down anywhere before, but seems
+ sensible to me, and we can always loosen this rule later if it proves
+ to be a problem. Much harder to try and add a restriction later, once
+ people are already using the API.
+
+ What follows are some details about how this implementation differs
+ from the original patch that was posted to the mailing list.
+
+ In this patch, I have changed how the lifetime of the Python
+ gdb.MICommand objects is managed. In the original patch, these object
+ were kept alive by an owned reference within the mi_command_py object.
+ As such, the Python object would not be deleted until the
+ mi_command_py object itself was deleted.
+
+ This caused a problem, the mi_command_py were held in the global mi
+ command table (in mi/mi-cmds.c), which, as a global, was not cleared
+ until program shutdown. By this point the Python interpreter has
+ already been shutdown. Attempting to delete the mi_command_py object
+ at this point was causing GDB to try and invoke Python code after
+ finalising the Python interpreter, and we would crash.
+
+ To work around this problem, the original patch added code in
+ python/python.c that would search the mi command table, and delete the
+ mi_command_py objects before the Python environment was finalised.
+
+ In contrast, in this patch, I have added a new global dictionary to
+ the gdb module, gdb._mi_commands. We already have several such global
+ data stores related to pretty printers, and frame unwinders.
+
+ The MICommand objects are placed into the new gdb.mi_commands
+ dictionary, and it is this reference that keeps the objects alive.
+ When GDB's Python interpreter is shut down gdb._mi_commands is deleted,
+ and any MICommand objects within it are deleted at this point.
+
+ This change avoids having to make the mi_cmd_table global, and walk
+ over it from within GDB's python related code.
+
+ This patch handles command redefinition entirely within GDB's python
+ code, though this does impose one small restriction which is not
+ present in the original code (detailed below), I don't think this is a
+ big issue. However, the original patch relied on being able to
+ finish executing the mi_command::do_invoke member function after the
+ mi_command object had been deleted. Though continuing to execute a
+ member function after an object is deleted is well defined, it is
+ also (IMHO) risky, its too easy for someone to later add a use of the
+ object without realising that the object might sometimes, have been
+ deleted. The new patch avoids this issue.
+
+ The one restriction that is added to avoid this, is that an MICommand
+ object can't be reinitialised with a different command name, so:
+
+ (gdb) python cmd = MyMICommand("-abc")
+ (gdb) python cmd.__init__("-def")
+ can't reinitialize object with a different command name
+
+ This feels like a pretty weird edge case, and I'm happy to live with
+ this restriction.
+
+ I have also changed how the memory is managed for the command name.
+ In the most recently posted patch series, the command name is moved
+ into a subclass of mi_command, the python mi_command_py, which
+ inherits from mi_command is then free to use a smart pointer to manage
+ the memory for the name.
+
+ In this patch, I leave the mi_command class unchanged, and instead
+ hold the memory for the name within the Python object, as the lifetime
+ of the Python object always exceeds the c++ object stored in the
+ mi_cmd_table. This adds a little more complexity in py-micmd.c, but
+ leaves the mi_command class nice and simple.
+
+ Next, this patch adds some extra functionality, there's a
+ MICommand.name read-only attribute containing the name of the command,
+ and a read-write MICommand.installed attribute that can be used to
+ install (make the command available for use) and uninstall (remove the
+ command from the mi_cmd_table so it can't be used) the command. This
+ attribute will be automatically updated if a second command replaces
+ an earlier command.
+
+ This patch adds additional error handling, and makes more use the
+ gdbpy_handle_exception function.
+
+ Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
+
+2022-03-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: compare some fields against 0 verify_gdbarch
+ After the previous commit, which removes the predicate function
+ gdbarch_register_type_p, I noticed that the gdbarch->register_type
+ field was not checked at in the verify_gdbarch function.
+
+ More than not being checked, the field wasn't mentioned at all.
+
+ I find this strange, I would expect that every field would at least be
+ mentioned - we already generate comments for some fields saying that
+ this field is _not_ being checked, so the fact that this field isn't
+ being checked looks (to me), like this field is somehow slipping
+ through the cracks.
+
+ The comment at the top of gdbarch-components.py tries to explain how
+ the validation is done. I didn't understand this comment completely,
+ but, I think this final sentence:
+
+ "Otherwise, the check is done against 0 (really NULL for function
+ pointers, but same idea)."
+
+ Means that, if non of the other cases apply, then the field should be
+ checked against 0, with 0 indicating that the field is invalid (was
+ not set by the tdep code). However, this is clearly not being done.
+
+ Looking in gdbarch.py at the code to generate verify_gdbarch we do
+ find that there is a case that is not handled, the case where the
+ 'invalid' field is set true True, but non of the other cases apply.
+
+ In this commit I propose two changes:
+
+ 1. Handle the case where the 'invalid' field of a property is set to
+ True, this should perform a check for the field of gdbarch still
+ being set to 0, and
+
+ 2. If the if/else series that generates verify_gdbarch doesn't handle
+ a property then we should raise an exception. This means that if a
+ property is added which isn't handled, we should no longer silently
+ ignore it.
+
+ After doing this, I re-generated the gdbarch files and saw that the
+ following gdbarch fields now had new validation checks:
+
+ register_type
+ believe_pcc_promotion
+ register_to_value
+ value_to_register
+ frame_red_zone_size
+ displaced_step_restore_all_in_ptid
+ solib_symbols_extension
+
+ Looking at how these are currently set in the various -tdep.c files, I
+ believe the only one of these that is required to be set for all
+ architectures is the register_type field.
+
+ And so, for all of the other fields, I've changed the property
+ definition on gdbarch-components.py, setting the 'invalid' field to
+ False.
+
+ Now, after re-generation, the register_type field is checked against
+ 0, thus an architecture that doesn't set_gdbarch_register_type will
+ now fail during validation. For all the other fields we skip the
+ validation, in which case, it is find for an architecture to not set
+ this field.
+
+ My expectation is that there should be no user visible changes after
+ this commit. Certainly for all fields except register_type, all I've
+ really done is cause some extra comments to be generated, so I think
+ that's clearly fine.
+
+ For the register_type field, my claim is that any architecture that
+ didn't provide this would fail when creating its register cache, and I
+ couldn't spot an architecture that doesn't provide this hook. As
+ such, I think this change should be fine too.
+
+2022-03-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: remove the predicate function for gdbarch_register_type
+ I don't believe that the gdbarch_register_type_p predicate is called
+ anywhere in GDB, and the gdbarch_register_type function is called
+ without checking the gdbarch_register_type_p predicate function
+ everywhere it is used, for example in
+ init_regcache_descr (regcache.c).
+
+ My claim is that the gdbarch_register_type function is required for
+ every architecture, and GDB will not work if this function is not
+ supplied.
+
+ And so, in this commit, I remove the 'predicate=True' from
+ gdbarch-components.py for the 'register_type' field, and regenerate
+ the gdbarch files.
+
+ There should be no user visible changes after this commit.
+
+2022-03-14 Patrick Monnerat <patrick@monnerat.net>
+
+ Replace deprecated_target_wait_hook by observers
+ Commit b60cea7 (Make target_wait options use enum flags) broke
+ deprecated_target_wait_hook usage: there's a commit comment telling
+ this hook has not been converted.
+
+ Rather than trying to mend it, this patch replaces the hook by two
+ target_wait observers:
+
+ target_pre_wait (ptid_t ptid)
+ target_post_wait (ptid_t event_ptid)
+
+ Upon target_wait entry, target_pre_wait is notified with the ptid
+ passed to target_wait. Upon exit, target_post_wait is notified with
+ the event ptid returned by target_wait. Should an exception occur,
+ event_ptid is null_ptid.
+
+ This change benefits to Insight (out-of-tree): there's no real use of the
+ late hook in gdb itself.
+
+2022-03-14 Tom Tromey <tromey@adacore.com>
+
+ Correctly print subrange types in generic_value_print
+ I noticed that generic_value_print assumes that a subrange type is
+ always a subrange of an integer type. However, this isn't necessarily
+ the case. In Ada, for example, one has subranges of character and
+ enumeration types.
+
+ This code isn't often exercised, I think, because languages with real
+ subrange types tend to implement their own printers. However, it
+ still seemed worth fixing.
+
+2022-03-14 Luis Machado <luis.machado@arm.com>
+
+ [aarch64/arm] Properly extract the return value returned in memory
+ When running gdb.cp/non-trivial-retval.exp, the following shows up for
+ both aarch64-linux and armhf-linux:
+
+ Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
+ 35 A a;
+ (gdb) finish
+ Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
+ main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163
+ 163 B b = f2 (i1, i2);
+ Value returned is $6 = {a = -11952}
+ (gdb)
+
+ The return value should be {a = 123} instead. This happens because the
+ backends don't extract the return value from the correct location. GDB should
+ fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf.
+
+ With the patch, gdb.cp/non-trivial-retval.exp has full passes on
+ aarch64-linux and armhf-linux on Ubuntu 20.04/18.04.
+
+ The problem only shows up with the "finish" command. The "call" command
+ works correctly and displays the correct return value.
+
+ This is also related to PR gdb/28681
+ (https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in
+ gdb.ada/mi_var_array.exp.
+
+ A new testcase is provided, and it exercises GDB's ability to "finish" a
+ function that returns a large struct (> 16 bytes) and display the
+ contents of this struct correctly. This has always been incorrect for
+ these backends, but no testcase exercised this particular scenario.
+
+2022-03-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-13 Alan Modra <amodra@gmail.com>
+
+ PR28959, obdump doesn't disassemble mftb instruction
+ Without a -M cpu option given, powerpc objdump defaults currently to
+ -Mpower10 but -Many is also given. Commit 1ff6a3b8e562 regressed
+ -Many disassembly of instructions that are encoded differently
+ depending on cpu, such as mftb which has pre- and post-power4
+ encodings.
+
+ PR 28959
+ * ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change. Instead
+ only look at deprecated PPC_OPCODE_RAW bit when -Many.
+
+2022-03-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-12 Tom Tromey <tom@tromey.com>
+
+ Relax regexp in gdb.rust/unsized.exp
+ With nightly rustc, gdb.rust/unsized.exp fails:
+
+ (gdb) ptype *us
+ Structure has no component named operator*.
+
+ rustc changed to emit a bit more debug info for unsized types.
+ Because the original test is just to make sure that ptype of an
+ unsized array looks right, this patch relaxes the regexp and changes
+ the expression. I think this keeps the original test meaning, but
+ also works with nightly. I also tested stable and 1.48.
+
+2022-03-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-11 Tom Tromey <tromey@adacore.com>
+
+ Avoid crash with cross-linux core file
+ An internal test case creates a core file using gcore, then restarts
+ gdb with that core. When run with a cross-linux gdb (in this case,
+ x86-64 host with ppc64-linux target), the test fails:
+
+ | (gdb) core core
+ | [New LWP 18437]
+ | warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.
+ | warning: Could not load shared library symbols for /lib64/ld64.so.1.
+ | Do you need "set solib-search-path" or "set sysroot"?
+ | ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed.
+ | A problem internal to GDB has been detected,
+ | further debugging may prove unreliable.
+ | Quit this debugging session? (y or n) y
+
+ What's happening here is that the core file lists some shared
+ libraries. These aren't available via the solib search path, and so
+ gdb finds the local (x86-64) libraries. This is not ideal, but on the
+ other hand, it is what was asked for -- while the test does set
+ solib-search-path, it does not set the sysroot.
+
+ But, because gdb isn't configured to handle these libraries, it
+ crashes.
+
+ It seems to me that it's better to avoid the crash by having
+ solib_bfd_open fail in the case where a library is incompatible. That
+ is what this patch does. Now it looks like:
+
+ | [New LWP 15488]
+ | Error while mapping shared library sections:
+ | `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.
+
+ ... and does not crash gdb.
+
+ I don't have a good setup for testing this using dejagnu, so I don't
+ know whether an existing gdb test covers this scenario.
+
+2022-03-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: remove duplicates from gdb.base/stap-probe.exp
+ Remove the duplicate test names from gdb.base/stap-probe.exp, this is
+ done by actually passing a unique test name in a couple of
+ places (rather than using the command as the test name), and in
+ another couple of places, a test has a duplicate name due to a cut &
+ paste error, which I've fixed.
+
+ There's no change in what is actually being tested after this commit.
+
+2022-03-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ gprofng: a new GNU profiler
+ top-level
+ * Makefile.def: Add gprofng module.
+ * configure.ac: Add --enable-gprofng option.
+ * src-release.sh: Add gprofng.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * gprofng: New directory.
+
+ binutils
+ * MAINTAINERS: Add gprofng maintainer.
+ * README-how-to-make-a-release: Add gprofng.
+
+ include.
+ * collectorAPI.h: New file.
+ * libcollector.h: New file.
+ * libfcollector.h: New file.
+
+2022-03-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-10 Aaron Merey <amerey@redhat.com>
+
+ gdb/auto-load: Remove repeating "auto-load" from debug message
+ Remove "auto-load:" from a format string passed to auto_load_debug_printf.
+ It is unnecessary since this function will prefix the string with "[auto-load]"
+ when printing it.
+
+2022-03-10 Tom Tromey <tromey@adacore.com>
+
+ Change how "print/x" displays floating-point value
+ Currently, "print/x" will display a floating-point value by first
+ casting it to an integer type. This yields weird results like:
+
+ (gdb) print/x 1.5
+ $1 = 0x1
+
+ This has confused users multiple times -- see PR gdb/16242, where
+ there are several dups. I've also seen some confusion from this
+ internally at AdaCore.
+
+ The manual says:
+
+ 'x'
+ Regard the bits of the value as an integer, and print the integer
+ in hexadecimal.
+
+ ... which seems more useful. So, perhaps what happened is that this
+ was incorrectly implemented (or maybe correctly implemented and then
+ regressed, as there don't seem to be any tests).
+
+ This patch fixes the bug.
+
+ There was a previous discussion where we agreed to preserve the old
+ behavior:
+
+ https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html
+
+ However, I think it makes more sense to follow the manual.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
+
+2022-03-10 Tom Tromey <tromey@adacore.com>
+
+ Simplify the ui-out progress API
+ I noticed that 'progress' is a method on ui-out, but it seems to me
+ that it would be better if the only API were via the progress_meter
+ class. This patch makes this change, changing progress to be a method
+ on the meter itself.
+
+2022-03-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbarch: fix typo in gdbarch-components.py
+ Fixes a minor typo, in a comment, in the gdbarch-components.py script.
+
+ There should be no user visible changes after this commit.
+
+2022-03-10 Lancelot SIX <lancelot.six@amd.com>
+
+ Process exit status is leader exit status testcase
+ This adds a multi-threaded testcase that has all threads in the
+ process exit with a different exit code, and ensures that GDB reports
+ the thread group leader's exit status as the whole-process exit
+ status. Before this set of patches, this would randomly report the
+ exit code of some other thread, and thus fail.
+
+ Tested on Linux-x86_64, native and gdbserver.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ Re-add zombie leader on exit, gdbserver/linux
+ Same as the previous patch, but for GDBserver.
+
+ In summary, the current zombie leader detection code in linux-low.cc
+ has a race -- if a multi-threaded inferior exits just before
+ check_zombie_leaders finds that the leader is now zombie via checking
+ /proc/PID/status, check_zombie_leaders deletes the leader, assuming we
+ won't get an event for that exit (which we won't in some scenarios,
+ but not in this one), which is a false-positive scenario, where the
+ whole process is simply exiting. Later when we see the last LWP in
+ our list exit, we report that LWP's exit status as exit code, even
+ though for the (real) parent process, the exit code that counts is the
+ child's leader thread's exit code.
+
+ Like for GDB, the solution here is to:
+
+ - only report whole-process exit events for the leader.
+ - re-add the leader back to the LWP list when we finally see it
+ exit.
+
+ Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ Re-add zombie leader on exit, gdb/linux
+ The current zombie leader detection code in linux-nat.c has a race --
+ if a multi-threaded inferior exits just before check_zombie_leaders
+ finds that the leader is now zombie via checking /proc/PID/status,
+ check_zombie_leaders deletes the leader, assuming we won't get an
+ event for that exit (which we won't in some scenarios, but not in this
+ one). That might seem mostly harmless, but it has some downsides:
+
+ - later when we continue pulling events out of the kernel, we will
+ collect the exit event of the non-leader threads, and once we see
+ the last lwp in our list exit, we return _that_ lwp's exit code as
+ whole-process exit code to infrun, instead of the leader's exit
+ code.
+
+ - this can cause a hang in stop_all_threads in infrun.c. Say there
+ are 2 threads in the process. stop_all_threads stops each of those
+ threads, and then waits for two stop or exit events, one for each
+ thread. If the whole process exits, and check_zombie_leaders hits
+ the false-positive case, linux-nat.c will only return one event to
+ GDB (the whole-process exit returned when we see the last thread,
+ the non-leader thread, exit), making stop_all_threads hang forever
+ waiting for a second event that will never come.
+
+ However, in this false-positive scenario, where the whole process is
+ exiting, as opposed to just the leader (with pthread_exit(), for
+ example), we _will_ get an exit event shortly for the leader, after we
+ collect the exit event of all the other non-leader threads. Or put
+ another way, we _always_ get an event for the leader after we see it
+ become zombie.
+
+ I tried a number of approaches to fix this:
+
+ #1 - My first thought to address the race was to make GDB always
+ report the whole-process exit status for the leader thread, not for
+ whatever is the last lwp in the list. We _always_ get a final exit
+ (or exec) event for the leader, and when the race triggers, we're not
+ collecting it.
+
+ #2 - My second thought was to try to plug the race in the first place.
+
+ I thought of making GDB call waitpid/WNOHANG for all non-leader
+ threads immediately when the zombie leader is detected, assuming there
+ would be an exit event pending for each of them waiting to be
+ collected. Turns out that that doesn't work -- you can see the leader
+ become zombie _before_ the kernel kills all other threads. Waitpid in
+ that small time window returns 0, indicating no-event. Thankfully we
+ hit that race window all the time, which avoided trading one race for
+ another. Looking at the non-leader thread's status in /proc doesn't
+ help either, the threads are still in running state for a bit, for the
+ same reason.
+
+ #3 - My next attempt, which seemed promising, was to synchronously
+ stop and wait for the stop for each of the non-leader threads. For
+ the scenario in question, this will collect all the exit statuses of
+ the non-leader threads. Then, if we are left with only the zombie
+ leader in the lwp list, it means we either have a normal while-process
+ exit or an exec, in which case we should not delete the leader. If
+ _only_ the leader exited, like in gdb.threads/leader-exit.exp, then
+ after pausing threads, we will still have at least one live non-leader
+ thread in the list, and so we delete the leader lwp. I got this
+ working and polished, and it was only after staring at the kernel code
+ to convince myself that this would really work (and it would, for the
+ scenario I considered), that I realized I had failed to account for
+ one scenario -- if any non-leader thread is _already_ stopped when
+ some thread triggers a group exit, like e.g., if you have some threads
+ stopped and then resume just one thread with scheduler-locking or
+ non-stop, and that thread exits the process. I also played with
+ PTRACE_EVENT_EXIT, see if it would help in any way to plug the race,
+ and I couldn't find a way that it would result in any practical
+ difference compared to looking at /proc/PID/status, with respect to
+ having a race.
+
+ So I concluded that there's no way to plug the race, we just have to
+ deal with it. Which means, going back to approach #1. That is the
+ approach taken by this patch.
+
+ Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Reindent check_zombie_leaders
+ This fixes the indentation of
+ linux_process_target::check_zombie_leaders, which will help with
+ keeping its comments in sync with the gdb/linux-nat.c counterpart.
+
+ Change-Id: I37332343bd80423d934249e3de2d04feefad1891
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ gdbserver: Reorganize linux_process_target::filter_event
+ Reorganize linux-low.cc:linux_process_target::filter_event such that
+ all the handling for events for LWPs not in the LWP list is together.
+ This helps make a following patch clearer. The comments and debug
+ messages have also been tweaked to have them synchronized with the GDB
+ counterpart.
+
+ Change-Id: If9019635f63a846607cfda44b454b4254a404019
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ gdb: Reorganize linux_nat_filter_event
+ Reorganize linux-nat.c:linux_nat_filter_event such that all the
+ handling for events for LWPs not in the LWP list is together. This
+ helps make a following patch clearer. The comments and debug messages
+ have also been tweaked - the end goal is to have them synchronized
+ with the gdbserver counterpart.
+
+ Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/current-lwp-dead.exp race
+ If we make GDB report the process EXIT event for the leader thread, as
+ will be done in a latter patch of this series, then
+ gdb.threads/current-lwp-dead.exp starts failing:
+
+ (gdb) break fn_return
+ Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45.
+ (gdb) continue
+ Continuing.
+ [New LWP 2138466]
+ [Inferior 1 (process 2138459) exited normally]
+ (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited)
+
+ The inferior exit reported is actually correct. The main thread has
+ indeed exited, and that's the thread that has the right exit code to
+ report to the user, as that's the exit code that is reported to the
+ program's parent. In this case, GDB managed to collect the exit code
+ for the leader thread before reaping the other thread, because in
+ reality, the testcase isn't creating standard threads, it is using raw
+ clone, and the new clones are put in their own thread group.
+
+ Fix it by making the main "thread" not exit until the scenario we're
+ exercising plays out. Also, run the program to completion for
+ completeness.
+
+ The original program really wanted the leader thread to exit before
+ the fn_return function was reached -- it was important that the
+ current thread as pointed by inferior_ptid was gone when infrun got
+ the breakpoint event. I've tweaked the testcase to ensure that that
+ condition is still held, though it is no longer the main thread that
+ exits. This required a bit of synchronization between the threads,
+ which required using CLONE_VM unconditionally. The #ifdef guards were
+ added as a fix for
+ https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't
+ think they were necessary because the program is not using TLS. If it
+ turns out they were necessary, we can link the testcase with "-z now"
+ instead, which was mentioned as an alternative workaround in that
+ Bugzilla.
+
+ Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.threads/clone-new-thread-event.exp race
+ If we make GDB report the process EXIT event for the leader thread,
+ instead of whatever is the last thread in the LWP list, as will be
+ done in a latter patch of this series, then
+ gdb.threads/current-lwp-dead.exp starts failing:
+
+ (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
+
+ This is a testcase race -- the main thread does not wait for the
+ spawned clone "thread" to finish before exiting, so the main program
+ may exit before the second thread is scheduled and reports its
+ SIGUSR1. With the change to make GDB report the EXIT for the leader,
+ the race is 100% reproducible by adding a sleep(), like so:
+
+ --- c/gdb/testsuite/gdb.threads/clone-new-thread-event.c
+ +++ w/gdb/testsuite/gdb.threads/clone-new-thread-event.c
+ @@ -51,6 +51,7 @@ local_gettid (void)
+ static int
+ fn (void *unused)
+ {
+ + sleep (1);
+ tkill (local_gettid (), SIGUSR1);
+ return 0;
+ }
+
+ Resulting in:
+
+ Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65
+ 65 stack = malloc (STACK_SIZE);
+ (gdb) continue
+ Continuing.
+ [New LWP 3715562]
+ [Inferior 1 (process 3715555) exited normally]
+ (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
+
+ That inferior exit reported is actually correct. The main thread has
+ indeed exited, and that's the thread that has the right exit code to
+ report to the user, as that's the exit code that is reported to the
+ program's parent. In this case, GDB managed to collect the exit code
+ for the leader thread before reaping the other thread, because in
+ reality, the testcase isn't creating standard threads, it is using raw
+ clone, and the new clones are put in their own thread group.
+
+ Fix it by making the main thread wait for the child to exit. Also,
+ run the program to completion for completeness.
+
+ Change-Id: I315cd3dc2b9e860395dcab9658341ea868d7a6bf
+
+2022-03-10 Pedro Alves <pedro@palves.net>
+
+ Fix gdbserver/linux target_waitstatus logging assert
+ Turning on debug output in gdbserver leads to an assertion failure if
+ gdbserver reports a non-signal event:
+
+ [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1
+ [threads] wait_1: Hit a non-gdbserver trap event.
+ ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected.
+ sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.
+
+ Fix it in the obvious way, using target_waitstatus::to_string(),
+ resulting in, for example:
+
+ [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+
+ Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645
+
+2022-03-10 Nick Clifton <nickc@redhat.com>
+
+ Add option to objdump/readelf to disable access to debuginfod servers.
+ * dwarf.c (use_debuginfod): New variable. Set to 1.
+ (load_separate_debug_info): Only call
+ debuginfod_fetch_separate_debug_info is use_debuginfod is true.
+ (dwarf_select_sections_by_names): Add do-not-use-debuginfod and
+ use-debuginfod options.
+ (dwarf_select_sections_by_letters): Add D and E options.
+ * dwarf.h (use_debuginfod): New extern.
+ * objdump.c (usage): Mention the new options.
+ * readelf.c (usage): Likewise.
+ * doc/binutils.texi: Document the new options.
+ * doc/debug-options.texi: Describe the new options.
+ * NEWS: Mention the new feature.
+ * testsuite/binutils-all/debuginfod.exp: Add tests of the new
+ options.
+
+2022-03-10 Alan Modra <amodra@gmail.com>
+
+ Re: ld: Add a before_plugin_all_symbols_read hook
+ * testsuite/ld-plugin/pr28849.d: Adjust for powerpc64 function
+ descriptors.
+
+2022-03-10 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add a before_plugin_all_symbols_read hook
+ Add a before_plugin_all_symbols_read hook to load symbol references from
+ DT_NEEDED entries, included from --copy-dt-needed-entries, before reading
+ plugin symbols to properly resolve plugin symbol references.
+
+ bfd/
+
+ PR ld/28849
+ * elf-bfd.h (elf_link_hash_table): Add handling_dt_needed.
+ * elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic
+ before plugin 'all symbols read' hook is called.
+
+ ld/
+
+ PR ld/28849
+ * ldelf.c (ldelf_handle_dt_needed): New function.
+ (ldelf_before_plugin_all_symbols_read): Likewise.
+ (ldelf_after_open): Call ldelf_handle_dt_needed.
+ * ldelf.h (ldelf_before_plugin_all_symbols_read): New.
+ * ldemul.c (ldemul_before_plugin_all_symbols_read): Likewise.
+ * ldemul.h (ldemul_before_plugin_all_symbols_read): Likewise.
+ (ld_emulation_xfer_struct): Add before_plugin_all_symbols_read.
+ * ldlang.c (lang_process): Call
+ ldemul_before_plugin_all_symbols_read before calling
+ plugin_call_all_symbols_read.
+ * emultempl/elf.em
+ (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New.
+ (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): New.
+ * emultempl/emulation.em (ld_${EMULATION_NAME}_emulation):
+ Initialize the before_plugin_all_symbols_read field.
+ * testsuite/ld-plugin/lto.exp: Run PR ld/28849 tests.
+ * testsuite/ld-plugin/pr28849.d: New file.
+ * testsuite/ld-plugin/pr28849a.c: Likewise.
+ * testsuite/ld-plugin/pr28849b.c: Likewise.
+
+2022-03-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-09 Hans-Peter Nilsson <hp@axis.com>
+
+ toplevel: Makefile.def: Make configure-sim depend on all-readline
+ Without this, a "make all-sim" without the equivalent of
+ libreadline-dev installed on the build system, won't
+ properly pick up the in-tree readline build, and you'll see:
+
+ mkdir -p -- ./sim
+ Configuring in ./sim
+ configure: creating cache ./config.cache
+ checking build system type... x86_64-pc-linux-gnu
+ checking host system type... x86_64-pc-linux-gnu
+ checking target system type... cris-axis-elf
+ checking for x86_64-pc-linux-gnu-gcc... gcc
+ checking whether the C compiler works... yes
+ ...
+ checking for library containing tgetent... -ltermcap
+ checking for readline in -lreadline... no
+ configure: error: the required "readline" library is missing
+ make[1]: *** [Makefile:11188: configure-sim] Error 1
+ make[1]: Leaving directory '/home/hp/sim/b'
+
+ The sim dependency on readline is apparently (nominally)
+ valid as there's a readline call in sim/erc32/sis.c.
+
+ 2022-02-21 Hans-Peter Nilsson <hp@axis.com>
+
+ * Makefile.def (dependencies): Make configure-sim depend on
+ all-readline.
+
+2022-03-09 Maciej W. Rozycki <macro@embecosm.com>
+
+ GDB/testsuite: Fix a "displayed" typo in gdb.base/default.exp
+ Fix a typo, s/dislayed/displayed/ in default.exp at the top level.
+
+ GDB/testsuite: Remove a stray backslash from gdb.base/settings.exp
+ Remove a stray trailing backslash from `test-integer' in settings.exp.
+ It is harmless as only white space follows in the next line before the
+ closing brace, so it merely swallows the newline character, but it may
+ look confusing to the reader.
+
+2022-03-09 Christina Schimpe <christina.schimpe@intel.com> (tiny change)
+
+ * gdb/doc/gdb.texinfo (Requirements): Fix a typo.
+
+2022-03-09 Alan Modra <amodra@gmail.com>
+
+ Constant fold view increment expressions
+ The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3.
+
+ * dwarf2dbg.c (set_or_check_view): Remove useless assertion.
+ Resolve multiple view increments.
+ * testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.
+
+2022-03-09 Alan Modra <amodra@gmail.com>
+
+ Reduce duplicated symbol_clone_if_forward_ref work
+ * symbol.c (struct symbol_flags): Add forward_resolved.
+ (symbol_entry_find): Update needle initialisation.
+ (symbol_clone_if_forward_ref): Do no work when forward_resolved
+ is already set. Set forward_resolved.
+
+2022-03-09 Aaron Merey <amerey@redhat.com>
+
+ gdb: Try searching for auto-load script using .gnu_debuglink
+ If an auto-load script cannot be found and objfile is a separate
+ debuginfo whose filename does not match the name found in the parent
+ file's .gnu_debuglink section, then repeat the search using the
+ parent's filename where the last component is replaced with the
+ .gnu_debuglink name.
+
+ For example if the parent's filename is "/usr/lib/libxyz.so" and the
+ name in its .gnu_debuglink section is "libxyz.so.debug", then
+ if no auto-load script is otherwise found the search will be
+ repeated with the filename "/usr/lib/libxyz.so.debug".
+
+ This helps gdb locate auto-load scripts when debuginfo files do not have
+ the expected filename, such as when they are aquired from debuginfod.
+
+2022-03-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-08 Aaron Merey <amerey@redhat.com>
+
+ PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source
+ Source files downloaded from debuginfod currently use their original DWARF
+ filename as their "fullname". This causes a mismatch between the fullname
+ and the actual location of the source file in the debuginfod client cache.
+
+ MI consumers such as VSCode will fail to open debuginfod-downloaded
+ source files due to this. Also 'info source' will fail to include the
+ true paths of these files.
+
+ To fix this, use the debuginfod cache path as the fullname for debuginfod-
+ downloaded source files.
+
+2022-03-08 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/mi: preserve user selected thread and frame when invoking MI commands
+ Fix for PR gdb/20684. When invoking MI commands with --thread and/or
+ --frame, the user selected thread and frame was not preserved:
+
+ (gdb)
+ info thread
+ &"info thread\n"
+ ~" Id Target Id Frame \n"
+ ~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
+ ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+ ~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+ ^done
+ (gdb)
+ info frame
+ &"info frame\n"
+ ~"Stack level 0, frame at 0x7fffffffdf90:\n"
+ ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
+ ~" source language c.\n"
+ ~" Arglist at 0x7fffffffdf80, args: \n"
+ ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
+ ~" Saved registers:\n "
+ ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
+ ^done
+ (gdb)
+ -stack-info-depth --thread 3
+ ^done,depth="4"
+ (gdb)
+ info thread
+ &"info thread\n"
+ ~" Id Target Id Frame \n"
+ ~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
+ ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+ ~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+ ^done
+ (gdb)
+ info frame
+ &"info frame\n"
+ ~"Stack level 0, frame at 0x7ffff742dee0:\n"
+ ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
+ ~" called by frame at 0x7ffff742df00\n"
+ ~" source language c.\n"
+ ~" Arglist at 0x7ffff742ded0, args: \n"
+ ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
+ ~" Saved registers:\n "
+ ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
+ ^done
+ (gdb)
+
+ This caused problems for frontends that provide access to CLI because UI
+ may silently change the context for CLI commands (as demonstrated above).
+
+ This commit fixes the problem by restoring thread and frame in
+ mi_cmd_execute (). With this change, there are only two GDB/MI commands
+ that can change user selected context: -thread-select and -stack-select-frame.
+ This allows us to remove all and rather complicated logic of notifying
+ about user selected context change from mi_execute_command (), leaving it
+ to these two commands themselves to notify.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684
+
+2022-03-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: announce upcoming removal of Python 2 support from gdb
+ As has been discussed here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html
+
+ Python 2 support will be removed from GDB after GDB 12 has branched.
+ This commit places an entry in the NEWS file to inform users of this
+ decision.
+
+2022-03-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: add new test for comparing char types in Python
+ There's an interesting property of the 'char' type in C and C++, the
+ three types 'char', 'unsigned char', and 'signed char', are all
+ considered distinct.
+
+ In contrast, and 'int' is signed by default, and so 'int' and 'signed
+ int' are considered the same type.
+
+ This commit adds a test to ensure that this edge case is visible to a
+ user from Python.
+
+ It is worth noting that for any particular compiler implementation (or
+ the flags a compiler was invoked with), a 'char' will be either signed
+ or unsigned; it has to be one or the other, and a user can access this
+ information by using the Type.is_signed property. However, for
+ something like function overload resolution, the 'char' type is
+ considered distinct from the signed and unsigned variants.
+
+ There's no change to GDB with this commit, this is just adding a new
+ test to guard some existing functionality.
+
+2022-03-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add Type.is_signed property
+ Add a new read-only property, Type.is_signed, which is True for signed
+ types, and False otherwise.
+
+ This property should only be read on types for which Type.is_scalar is
+ true, attempting to read this property for non-scalar types will raise
+ a ValueError.
+
+ I chose 'is_signed' rather than 'is_unsigned' in order to match the
+ existing Architecture.integer_type method, which takes a 'signed'
+ parameter. As far as I could find, that was the only existing
+ signed/unsigned selector in the Python API, so it seemed reasonable to
+ stay consistent.
+
+2022-03-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add Type.is_scalar property
+ Add a new read-only property which is True for scalar types,
+ otherwise, it's False.
+
+2022-03-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: add --no-connection to MI -add-inferior command
+ Following on from the previous commit, where the -add-inferior command
+ now uses the same connection as the current inferior, this commit adds
+ a --no-connection option to -add-inferior.
+
+ This new option matches the existing option of the same name for the
+ CLI version of add-inferior; the new inferior is created with no
+ connection.
+
+ I've added a new 'connection' field to the MI output of -add-inferior,
+ which includes the connection number and short name. I haven't
+ included the longer description field, this is the MI after all. My
+ expectation would be that if the frontend wanted to display all the
+ connection details then this would be looked up from 'info
+ connection' (or the MI equivalent if/when such a command is added).
+
+ The existing -add-inferior tests are updated, as are the docs.
+
+2022-03-07 Umair Sair <umair_sair@hotmail.com>
+
+ gdb/mi: fix regression in mi -add-inferior command
+ Prior to the multi-target support commit:
+
+ commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
+ Date: Fri Jan 10 20:06:08 2020 +0000
+
+ Multi-target support
+
+ When a new inferior was added using the MI -add-inferior command, the
+ new inferior would be using the same target as all the other
+ inferiors. This makes sense, GDB only supported a single target stack
+ at a time.
+
+ After the above commit, each inferior has its own target stack.
+
+ To maintain backward compatibility, for the CLI add-inferior command,
+ when a new inferior is added the above commit has the new inferior
+ inherit a copy of the target stack from the current inferior.
+
+ Unfortunately, this same backward compatibility is missing for the MI.
+
+ This commit fixes this oversight.
+
+ Now, when the -add-inferior MI command is used, the new inferior will
+ inherit a copy of the target stack from the current inferior.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Deprecate dbx mode
+ GDB has a dbx emulation mode that adds a few aliases and helper
+ commands. This mode is barely documented and is very superficial
+ besides. I suspect it is rarely used, and I would like to propose
+ deprecating it for GDB 12, and then removing it in GDB 13.
+
+2022-03-07 Pedro Alves <pedro@palves.net>
+
+ Remove unnecessary inferior lookup in infrun:handle_one
+ infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
+ already have a thread pointer handy, and the thread has a pointer to
+ the inferior. This commit removes the unnecessary lookup.
+
+ Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in ada_print_floating
+ ada_print_floating rewrites a floating-point string representation to
+ conform to Ada syntax. However, if you managed to get a floating
+ point error, you might see:
+
+ (gdb) print whatever
+ $2 = <invalid float valu.0e>
+
+ What's happening here is that ada_print_floating doesn't recognize
+ this error case, and proceeds to modify the error text.
+
+ This patch fixes this problem.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Implement real literal extension for Ada
+ Sometimes it is convenient to be able to specify the exact bits of a
+ floating-point literal. For example, you may want to set a
+ floating-point register to a denormalized value, or to a particular
+ NaN.
+
+ In C, you can do this by combining the "{}" cast with an array
+ literal, like:
+
+ (gdb) p {double}{0x576488BDD2AE9FFE}
+ $1 = 9.8765449999999996e+112
+
+ This patch adds a somewhat similar idea to Ada. It extends the lexer
+ to allow "l" and "f" suffixes in a based literal. The "f" indicates a
+ floating-point literal, and the "l"s control the size of the
+ floating-point type.
+
+ Note that this differs from Ada's based real literals. I believe
+ those can also be used to control the bits of a floating-point value,
+ but they are a bit more cumbersome to use (simplest is binary but
+ that's also very lengthy). Also, these aren't implemented in GDB.
+
+ I chose not to allow this extension to work with based integer
+ literals with exponents. That didn't seem very useful.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Fix Ada integer literals with exponents
+ While working on another patch, I noticed that Ada integer literals
+ with exponents did not work. For example, with one form you get an
+ error:
+
+ (gdb) print 8e2
+ Invalid digit `e' in based literal
+
+ And with another form you get an incorrect value:
+
+ (gdb) print 16#8#e2
+ $2 = 8
+
+ This patch fixes the bugs and adds tests.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Fix gdb.ada/arrayptr.exp results
+ PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
+ but fails with minimal encodings in earlier versions.
+
+ This patch updates the test to try to report the results correctly. I
+ tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
+ built from git trunk sometime relatively recently.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Handle non-ASCII identifiers in Ada
+ Ada allows non-ASCII identifiers, and GNAT supports several such
+ encodings. This patch adds the corresponding support to gdb.
+
+ GNAT encodes non-ASCII characters using special symbol names.
+
+ For character sets like Latin-1, where all characters are a single
+ byte, it uses a "U" followed by the hex for the character. So, for
+ example, thorn would be encoded as "Ufe" (0xFE being lower case
+ thorn).
+
+ For wider characters, despite what the manual says (it claims
+ Shift-JIS and EUC can be used), in practice recent versions only
+ support Unicode. Here, characters in the base plane are represented
+ using "Wxxxx" and characters outside the base plane using
+ "WWxxxxxxxx".
+
+ GNAT has some further quirks here. Ada is case-insensitive, and GNAT
+ emits symbols that have been case-folded. For characters in ASCII,
+ and for all characters in non-Unicode character sets, lower case is
+ used. For Unicode, however, characters that fit in a single byte are
+ converted to lower case, but all others are converted to upper case.
+
+ Furthermore, there is a bug in GNAT where two symbols that differ only
+ in the case of "Y WITH DIAERESIS" (and potentially others, I did not
+ check exhaustively) can be used in one program. I chose to omit
+ handling this case from gdb, on the theory that it is hard to figure
+ out the logic, and anyway if the bug is ever fixed, we'll regret
+ having a heuristic.
+
+ This patch introduces a new "ada source-charset" setting. It defaults
+ to Latin-1, as that is GNAT's default. This setting controls how "U"
+ characters are decoded -- W/WW are always handled as UTF-32.
+
+ The ada_tag_name_from_tsd change is needed because this function will
+ read memory from the inferior and interpret it -- and this caused an
+ encoding failure on PPC when running a test that tries to read
+ uninitialized memory.
+
+ This patch implements its own UTF-32-based case folder. This avoids
+ host platform quirks, and is relatively simple. A short Python
+ program to generate the case-folding table is included. It simply
+ relies on whatever version of Unicode is used by the host Python,
+ which seems basically acceptable.
+
+ Test cases for UTF-8, Latin-1, and Latin-3 are included. This
+ exercises most of the new code paths, aside from Y WITH DIAERESIS as
+ noted above.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Define HOST_UTF32 in charset.h
+ rust-parse.c has a #define for the host-specific UTF-32 charset name.
+ A later patch needs the same thing, so this patch moves the definition
+ to charset.h for easier reuse.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Let phex and phex_nz handle sizeof_l==1
+ Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
+ this case fall through to the default case. However, a subsequent
+ patch in this series needs this case to work correctly.
+
+ I looked at all calls to these functions that pass a 1 for the
+ sizeof_l parameter. The only such case seems to be correct with this
+ change.
+
+2022-03-07 Tom Tromey <tromey@adacore.com>
+
+ Don't pre-size result string in ada_decode
+ Currently, ada_decode pre-sizes the output string, filling it with 'X'
+ characters. However, it's a bit simpler and more flexible to let
+ std::string do the work here, and simply append characters to the
+ string as we go. This turns out to be useful for a subsequent patch.
+
+ Simplify a regular expression in ada-lex.l
+ ada-lex.l uses "%option case-insensitive", so there is no need for
+ regular expressions to match upper case.
+
+2022-03-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ MIPS/opcodes: Fix alias annotation for branch instructions
+ Correct issues with INSN2_ALIAS annotation for branch instructions:
+
+ - regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
+ BEQ/L and BNE/L respectively with the `rs' operand equal to $0,
+
+ - microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
+ BEQ and BNE respectively with the `rt' operand equal to $0,
+
+ - regular MIPS BAL assembly instruction is an idiom for architecture
+ levels of up to the MIPSr5 ISA and a machine instruction on its own
+ from the MIPSr6 ISA up.
+
+ Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
+ new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:
+
+ $ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o
+
+ bal.o: file format elf32-tradlittlemips
+
+ Disassembly of section .text:
+
+ 00000000 <foo>:
+ 0: 04110000 0x4110000
+ ...
+ $
+
+ Add test cases accordingly.
+
+ Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.
+
+ 2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk>
+
+ binutils/
+ * testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
+ * testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
+ * testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
+ * testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
+ * testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
+ * testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
+ test.
+ * testsuite/binutils-all/mips/micromips-branch-alias.d: New
+ test.
+ * testsuite/binutils-all/mips/micromips-branch-noalias.d: New
+ test.
+ * testsuite/binutils-all/mips/mips-branch-alias.s: New test
+ source.
+ * testsuite/binutils-all/mips/micromips-branch-alias.s: New test
+ source.
+ * testsuite/binutils-all/mips/mips.exp: Run the new tests.
+
+ 2022-03-06 Sagar Patel <sagarmp@cs.unc.edu>
+ Maciej W. Rozycki <macro@orcam.me.uk>
+
+ opcodes/
+ * mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
+ for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
+ * micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
+ "bnez" instructions.
+
+2022-03-06 Tom Tromey <tom@tromey.com>
+
+ Use function view when iterating over block symbols
+ This changes iterate_over_block_local_vars and
+ iterate_over_block_arg_vars to take a gdb::function_view rather than a
+ function pointer and a user-data. In one spot, this allows us to
+ remove a helper structure and helper function. In another spot, this
+ looked more complicated, so I changed the helper function to be an
+ "operator()" -- also a simplification, just not as big.
+
+2022-03-06 Tom Tromey <tom@tromey.com>
+
+ Simplify hppa-tdep.c use of objfile_key
+ I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
+ then I saw that the use of objfile_key could be simplified -- removing
+ some code and using the default deleter rather than noop_deleter.
+
+ Tested by rebuilding. Let me know what you think.
+
+2022-03-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: constify parameter of value_copy
+ In a following patch, I have a const value I want to copy using a
+ value_copy. However, value_copy takes a non-const source value, at the
+ moment. Change the paramter to be const,
+
+ If the source value is not lazy, we currently call
+ value_contents_all_raw, which calls allocate_value_contents, to get a
+ view on the contents. They both take a non-const value, that's a
+ problem. My first attempt at solving it was to add a const version of
+ value_contents_all_raw, make allocate_value_contents take a const value,
+ and either:
+
+ - make value::contents mutable
+ - make allocate_value_contents cast away the const
+
+ The idea being that allocating the value contents buffer does modify the
+ value at the bit level, but logically that doesn't change its state.
+
+ That was getting a bit complicated, so what I ended up doing is make
+ value_copy not call value_contents_all_raw. We know at this point that
+ the value is not lazy, so value::contents must have been allocate
+ already.
+
+ Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4
+
+2022-03-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove internalvar_funcs::destroy
+ No kind of internal var uses it remove it. This makes the transition to
+ using a variant easier, since we don't need to think about where this
+ should be called (in a destructor or not), if it can throw, etc.
+
+ Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd
+
+2022-03-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-04 Tom Tromey <tromey@adacore.com>
+
+ Mark vDSO as not a file
+ The vDSO objfile is not a real file, so mark it as such. I noticed
+ this because, when playing with debuginfod, I saw:
+
+ Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000
+
+ That "/tmp" is wrong -- it's just gdb's cwd. This patch corrects the
+ problem, resulting in:
+
+ Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-03-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ binutils/readelf: fix indentation in process_dynamic_section
+ Clangd shows a warning about misleading indentation in this file, fix
+ it.
+
+ binutils/ChangeLog:
+
+ * readelf.c (process_dynamic_section): Fix indentation.
+
+ Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297
+
+2022-03-04 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb: Use a typedef's scoped type name to identify local typedefs
+ GDB prints the wrong type for typedefs in case there is another typedef
+ available for the same raw type (gdb/16040). The reason is that the
+ current hashmap based substitution mechanism always compares the target
+ type of a typedef and not its scoped name.
+
+ The original output of GDB for a program like
+
+ ~~~~
+ namespace ns
+ {
+ typedef double scoped_double;
+ }
+
+ typedef double global_double;
+
+ class TypedefHolder
+ {
+ public:
+ double a;
+ ns::scoped_double b;
+ global_double c;
+
+ private:
+ typedef double class_double;
+ class_double d;
+
+ double method1(ns::scoped_double) { return 24.0; }
+ double method2(global_double) { return 24.0; }
+ };
+
+ int main()
+ {
+ TypedefHolder th;
+ return 0;
+ }
+ ~~~~
+
+ is
+ ~~~~
+
+ (gdb) b 27
+ Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
+ (gdb) r
+ Starting program: /tmp/typedefholder
+
+ Breakpoint 1, main () at TypedefHolder.cc:27
+ 27 return 0;
+ (gdb) ptype th
+ type = class TypedefHolder {
+ public:
+ class_double a;
+ class_double b;
+ class_double c;
+ private:
+ class_double d;
+
+ class_double method1(class_double);
+ class_double method2(class_double);
+
+ typedef double class_double;
+ }
+ ~~~~
+
+ Basically all attributes of a class which have the raw type "double" are
+ substituted by "class_double".
+
+ With the patch the output is the following
+
+ ~~~~
+ type = class TypedefHolder {
+ public:
+ double a;
+ ns::scoped_double b;
+ global_double c;
+ private:
+ class_double d;
+
+ double method1(ns::scoped_double);
+ double method2(global_double);
+
+ typedef double class_double;
+ }
+ ~~~~
+
+2022-03-04 Jan Beulich <jbeulich@suse.com>
+
+ RISC-V: make .insn actually work for 64-bit insns
+ Presently in this case, due to an undefined behavior shift, at least
+ with x86 cross builds I'm observing:
+
+ Error: value conflicts with instruction length `8,0x0000003f'
+
+ Eliminate the UB and extend the respective testcase.
+
+2022-03-04 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop redundant x86-64-code16-2 test
+ The code16-2 test is already meaningless enough as a gas test, identical
+ to this one, and is run uniformly for all ELF targets anyway.
+
+2022-03-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-03 Roland McGrath <mcgrathr@google.com>
+
+ Fix typo in last change.
+
+2022-03-03 Roland McGrath <mcgrathr@google.com>
+
+ Avoid conflict with gnulib open/close macros.
+ On some systems, the gnulib configuration will decide to define open
+ and/or close as macros to replace the POSIX C functions. This
+ interferes with using those names in C++ class or namespace scopes.
+
+ gdbsupport/
+ * event-pipe.cc (event_pipe::open): Renamed to ...
+ (event_pipe::open_pipe): ... this.
+ (event_pipe::close): Renamed to ...
+ (event_pipe::close_pipe): ... this.
+ * event-pipe.h (class event_pipe): Updated.
+ gdb/
+ * inf-ptrace.h (async_file_open, async_file_close): Updated.
+ gdbserver/
+ * gdbserver/linux-low.cc (linux_process_target::async): Likewise.
+
+2022-03-03 Alan Modra <amodra@gmail.com>
+
+ Adjust ld ctf test for 32-bit targets
+ powerpc-linux, and I suspect other 32-bit targets, report "aligned at
+ 0x4" for this test.
+
+ * testsuite/ld-ctf/nonrepresentable.d: Accept any alignment.
+
+2022-03-03 Luis Machado <luis.machado@arm.com>
+
+ Update my e-mail address in the MAINTAINERS file
+ Update the information accordingly.
+
+2022-03-03 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.exp
+ When execute the following command:
+
+ make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
+
+ we can see there exist some failed testcases:
+
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
+ FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
+
+ here are the detailed messages in gdb/testsuite/gdb.log:
+
+ attach 873776
+ A program is being debugged already. Kill it? (y or n) n
+ Not killed.
+ (gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
+
+ so handle the case "A program is being debugged already. Kill it" in
+ can_spawn_for_attach to fix the failed testcases.
+
+2022-03-03 Alan Modra <amodra@gmail.com>
+
+ comment typo fix
+
+2022-03-03 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 DT_RELR relative reloc addresses
+ Section addresses can change between ppc64_elf_size_stubs and
+ ppc64_elf_build_stubs due to .eh_frame editing. The idea of stashing
+ r_offset final addresses calculated in ppc64_elf_size_stubs for use by
+ ppc64_elf_build_stubs was never a good idea. Instead, we need to keep
+ section/offset pairs.
+
+ * elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr.
+ Add relr section/offset array.
+ (append_relr_off): Rewrite. Update all callers.
+ (sort_relr): New function.
+ (ppc64_elf_size_stubs): Adjust to suit new relative reloc stash.
+ (ppc64_elf_build_stubs): Likewise.
+
+2022-03-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-02 John Baldwin <jhb@FreeBSD.org>
+
+ configure: Stop checking for PT_GETXMMREGS.
+ This request is present on all modern *BSD/i386 systems (those
+ released since mid-2006), and the *BSD/i386 targets now assume it is
+ present unconditionally.
+
+ i386-bsd-nat: Assume PT_GETXMMREGS is present.
+ NetBSD has included PT_GETXMMREGS since 1.6 released in September
+ 2002. OpenBSD has included PT_GETXMMREGS since 3.8 released in
+ November 2005.
+
+ i386-fbsd-nat: Assume PT_GETXMMREGS is present.
+ PT_GETXMMREGS was first added in FreeBSD 6.0 released in November 2005.
+ The last FreeBSD release without support was 5.5 released in May 2006.
+
+2022-03-02 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-tdep: Implement the vsyscall_range gdbarch hook.
+ FreeBSD recently added a real vDSO in its shared page for the amd64
+ architecture. The vDSO is mapped at the address given by the
+ AT_KPRELOAD ELF auxiliary vector entry. To find the end of the
+ mapping range, parse the list of virtual map entries used by 'info
+ proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
+ via the kinfo_getvmmap function for native targets (fetched from the
+ native target as the TARGET_OBJECT_FREEBSD_VMMAP object).
+
+ This silences warnings on recent FreeBSD/amd64 kernels due to not
+ finding symbols for the vdso:
+
+ warning: Could not load shared library symbols for [vdso].
+ Do you need "set solib-search-path" or "set sysroot"?
+
+2022-03-02 Tom Tromey <tromey@adacore.com>
+
+ Rewrite make-target-delegates in Python
+ I think gdb is probably better off having fewer languages involved
+ when generating code. 'sh' is unavoidable for build-time generation,
+ but for other things, let's use Python.
+
+ This rewrites make-target-delegates in Python. I've stuck pretty
+ closely to the original code in this rewrite, so it may look slightly
+ weird from a Python perspective.
+
+ The only output difference is that a copyright header is now
+ generated, using the code introduced in the previous patch.
+
+ make-target-delegates.py is simpler to invoke, as it knows the correct
+ input file to scan and it creates the output file itself.
+
+2022-03-02 Tom Tromey <tromey@adacore.com>
+
+ Move copyright code from gdbarch.py to new file
+ This moves the copyright code from gdbarch.py to a new Python source
+ file, gdbcopyright.py. The function in this file will find the
+ copyright dates by scanning the calling script. This will be reused
+ in a future patch.
+
+ This involved minor changes to the output of gdbarch.py. Also, I've
+ updated copyright.py to remove the reference to gdbarch.sh. We don't
+ need to mention gdbarch.py there, either.
+
+2022-03-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-03-01 Tom Tromey <tom@tromey.com>
+
+ Some "distclean" fixes in gdb
+ PR build/12440 points out that "make distclean" is broken in gdb.
+ Most of the breakage comes from other projects in the tree, but we can
+ fix some of the issues, which is what this patch does.
+
+ Note that the yacc output files, like c-exp.c, are left alone. In a
+ source distribution, these are included in the tarball, and if the
+ user builds in-tree, we would not want to remove them.
+
+ While that seems a bit obscure, it seems to me that "distclean" is
+ only really useful for in-tree builds anyway -- out-of-tree I simply
+ delete the entire build directory and start over.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440
+
+2022-03-01 Tom Tromey <tom@tromey.com>
+
+ Fix typo in the "alias" example
+ PR cli/17332, filed around 8 years ago, points out a typo in the docs
+ -- in one example, the command and its output are obviously out of
+ sync. This patch fixes it. I'm checking this in as obvious.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332
+
+2022-03-01 Nick Clifton <nickc@redhat.com>
+
+ Fix a typo in the previous delta to bfdio.c.
+ PR 25713
+ * bfdio.c (_bfd_real_fopen): Fix typo.
+
+2022-03-01 Alan Modra <amodra@gmail.com>
+
+ Revert "Check thin archive element file size against archive header"
+ This reverts commit 48e3e6aec8a4f37d00ea6c0da3ab45e76490e3db.
+
+ PR 28929
+ * archive.c (_bfd_get_elt_at_filepos): Don't check thin archive
+ element file size.
+
+2022-03-01 Nick Clifton <nickc@redhat.com>
+
+ Fix linker tests to compile with gcc-12.
+ PR 21964
+ * testsuite/ld-elf/pr21964-1a.c: Fix array comparisons.
+ * testsuite/ld-elf/pr21964-1b.c: Likewise.
+ * testsuite/ld-elf/pr21964-1c.c: Likewise.
+ * testsuite/ld-elf/pr21964-2a.c: Likewise.
+ * testsuite/ld-elf/pr21964-2b.c: Likewise.
+ * testsuite/ld-elf/pr21964-3a.c: Likewise.
+
+ Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes.
+ PR 28848
+ PR 28859
+ * elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first
+ input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have
+ TAG_FP_arch set then reset the TAG_ABI_HardFP_use.
+
+2022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
+ If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
+ gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
+ following info:
+
+ (gdb) attach 6500
+ Attaching to process 6500
+ ptrace: Operation not permitted.
+ (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
+
+ It is obviously wrong, the expected result should be UNSUPPORTED in such
+ a case.
+
+ It is better to make can_spawn_for_attach to return false for this case.
+ It would have to setup a small test program, compile it to exec, spawn it
+ and try to attach to it.
+
+ With this patch, we can see "Operation not permitted" in the log info,
+ and then we can do the following processes to test:
+ (1) set ptrace_scope as 0
+ $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
+ $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+ (2) use sudo
+ $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+ Additionally, handle the other cases when test with RUNTESTFLAGS=
+ "--target_board=native-extended-gdbserver".
+
+2022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: print explicit test result in can_spawn_for_attach
+ In the current code, there is no test result when execute the following
+ commands:
+
+ $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
+ $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+
+ It is better to print explicit test result in can_spawn_for_attach.
+
+2022-03-01 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: add Tiezhu Yang as LoongArch maintainer
+ The patch series "gdb: Add basic support for LoongArch" has been
+ merged into master, list Tiezhu Yang as LoongArch maintainer.
+
+2022-03-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-28 Keith Seitz <keiths@redhat.com>
+
+ Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp
+ Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
+ causes several Tcl errors to appear. For example,
+
+ (gdb)
+ ERROR: : spawn id exp20 not open
+ while executing
+ "expect {
+ -i exp11 -timeout 10
+ -i "$inferior_spawn_id"
+ -re ".*Cannot exec.*Permission denied" {
+ set saw_perm_error 1
+ verbose -log "saw..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE : spawn id exp20 not open
+ UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
+
+ This is happening because of the way this test is implemented:
+
+ while {1} {
+ gdb_expect {
+ -i "$inferior_spawn_id"
+ -re ".*Cannot exec.*Permission denied" {
+ set saw_perm_error 1
+ verbose -log "saw mi error"
+ }
+ -i "$gdb_spawn_id"
+ -re "\\^error,msg=\"During startup program exited with code 127" {
+ set saw_mi_error 1
+ verbose -log "saw mi error"
+ }
+ # and so on
+ }
+ }
+
+ The first time this loop is executed, `inferior_spawn_id' is valid. When the
+ first branch of the expect statement is reached, gdbserver has exited, closing
+ the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed
+ again. The first branch now refers to a non-existent spawn_id, leading to the error.
+
+ This can be fixed by using exp_continue to loop in expect instead of looping around
+ expect, which is the approach I have used[1]. Note I've had to update the expected
+ message for the "During startup..." error message when running with gdbserver.
+
+ One other small change I've made is to add a log entry which spills the values of
+ the two variables, saw_mi_error and saw_perm_error (and updated the log output
+ for the later). This should make the log output clearer about why the test failed.
+
+ With this patch installed, all the ERRORs disappear, leaving previously masked
+ FAILs (which I have not attempted to fix).
+
+ [1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
+ assume that it was intentionally written this way, and I've modified the code with
+ that assumption. I have tested a version using gdb_test_multiple, and that appears
+ to work fine, too, if that is preferred. [It still employs exp_continue to fix the
+ spawn_id errors.]
+
+2022-02-28 Tom Tromey <tromey@adacore.com>
+
+ Add more filename styling
+ I found a few spots where filename styling ought to be applied, but is
+ not.
+
+2022-02-28 Tom Tromey <tromey@adacore.com>
+
+ Fix maybe-uninitialized warning in py-infthread.c
+ I got this warning from py-infthread.c using the Fedora 34 system GCC:
+
+ ../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+ I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
+ 'if' whose condition is always true -- but GCC can't know this. This
+ patch avoids the warning by adding a harmless initialization.
+
+2022-02-28 Tom Tromey <tromey@adacore.com>
+
+ Handle multi-byte bracket sequences in Ada lexer
+ As noted in an earlier patch, the Ada lexer does not handle multi-byte
+ bracket sequences. This patch adds support for these for character
+ literals. gdb does not generally seem to handle the Ada wide string
+ types, so for the time being these continue to be excluded -- but an
+ explicit error is added to make this more clear.
+
+2022-02-28 Tom Tromey <tromey@adacore.com>
+
+ Handle 'QWW' encoding case in Ada enums
+ In Ada, an enum can contain character literals. GNAT encodes these
+ values in a special way. For example, the Unicode character U+0178
+ would be represented as 'QW0178' in the DWARF:
+
+ <3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
+ <1130> DW_AT_name : (indirect string, offset: 0x19ff): QW0178
+ <1134> DW_AT_const_value : 2
+
+ gdb handles this reasonably well, but failed to handle the 'QWW'
+ encoding, which is used for characters outside the base plane.
+
+ Also, while working on this, I noticed that gdb will print the decimal
+ value for an enum character constant:
+
+ (gdb) print Char_X
+ $2 = 1 'x'
+
+ This is a nice feature, IMO, because in this situation the 'x' enum
+ constant does not have its usual decimal value -- it has the value
+ that's assigned based on the enumeration type.
+
+ However, gdb did not do this when it decided to print the constant
+ using the bracket notation:
+
+ (gdb) print Char_Thorn
+ $3 = ["de"]
+
+ This patch changes gdb to print the decimal value here as well, and to
+ put the bracket notation in single quotes -- otherwise gdb will be
+ printing something that it can't then read. Now it looks like:
+
+ (gdb) print Char_Thorn
+ $3 = 4 '["de"]'
+
+ Note that gdb can't read longer bracket notations, like the other ones
+ printed in this test case:
+
+ (gdb) print Char_King
+ $4 = 3 '["01fa00"]'
+
+ While I think this is a bug, I plan to fix it separately.
+
+ Finally, in the new test case, the copyright dates are chosen this way
+ because this all started as a copy of an existing test.
+
+2022-02-28 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: Add gdb.InferiorThread.details attribute
+ This adds a new read-only attribute gdb.InferiorThread.details, this
+ attribute contains a string, the results of target_extra_thread_info
+ for the thread, or None, if target_extra_thread_info returns nullptr.
+
+ As the string returned by target_extra_thread_info is unstructured,
+ this attribute is only really useful for echoing straight through to
+ the user, but, if a user wants to write a command that displays the
+ same, or a similar 'Thread Id' to the one seen in 'info threads', then
+ they need access to this string.
+
+ Given that the string produced by target_extra_thread_info varies by
+ target, there's only minimal testing of this attribute, I check that
+ the attribute can be accessed, and that the return value is either
+ None, or a string.
+
+2022-02-28 Keith Seitz <keiths@redhat.com>
+
+ Error when gdb_is_target_1 is called without running gdb instance
+ This is a snafu that I encountered while implementing the previous
+ patch, which attempted to use gdb_is_target_native. This proc and
+ gdb_is_target_remote both rely on gdb_is_target_1, which actually
+ cannot be called without gdb already running.
+
+ This patch adds appropriate warning comments to these procs and
+ causes gdb_is_target_1 to issue a Tcl error if it is called without a
+ gdb instance already running. This should prevent unwitting callers
+ from using this at the wrong time.
+
+2022-02-28 Keith Seitz <keiths@redhat.com>
+
+ Fix gdb.fortran "failed to extract expected results" errors
+ When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
+ the test suite throws several ERRORs on native-gdbserver/-m{32,64},
+ and native-extended-gdbsever/-m{32,64}:
+
+ [on native-extended-gdbserver/-m64]
+ Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
+ ERROR: failed to extract expected results
+ ERROR: failed to extract expected results
+ Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
+ ERROR: failed to extract expected results for lbound
+
+ This occurs because the tests require inferior I/O which we do not have
+ access to while using these targets.
+
+ This patch skips these tests when running on non-native targets.
+
+2022-02-28 Torbj?rn Svensson <torbjorn.svensson@st.com>
+
+ Further correct the handling of long pathnames on Windows hosts.
+ PR 25713
+ * bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260
+ characters on Windows hosts.
+
+2022-02-28 Nick Clifton <nickc@redhat.com>
+
+ Clarify the wording of the error message when an obsolete configuration is encountered.
+ PR 28886
+ * config.bfd: Update error message for obsolete configurations.
+
+2022-02-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-26 Kevin Buettner <kevinb@redhat.com>
+
+ Handle recursive internal problem in gdb_internal_error_resync
+ I came across this problem when testing gdb.base/gdb-sigterm.exp
+ on a machine with a pre-release version of glib-2.34 installed:
+
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n) Recursive internal problem.
+ FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
+ Resyncing due to internal error.
+ ERROR: : spawn id exp11 not open
+ while executing
+ "expect {
+ -i exp11 -timeout 10
+ -re "Quit this debugging session\\? \\(y or n\\) $" {
+ send_gdb "n\n" answer
+ incr count
+ }
+ -re "Create..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE : spawn id exp11 not open
+ ERROR: Could not resync from internal error (timeout)
+ gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
+ UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
+
+ I don't have a problem with the latter ERROR nor the UNRESOLVED
+ messages. However the first ERROR regarding the exp11 spawn id
+ not being open is not especially useful.
+
+ This commit handles the "Recursive internal problem" case, avoiding
+ the problematic ERROR shown above.
+
+ With this commit in place, the log messages look like this instead:
+
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n) Recursive internal problem.
+ FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
+ Resyncing due to internal error.
+ ERROR: Could not resync from internal error (recursive internal problem)
+ gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
+ UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
+
+ gdb/testsuite/ChangeLog:
+
+ * lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
+ internal problem".
+
+2022-02-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-25 Aaron Merey <amerey@redhat.com>
+
+ gdb-add-index: disable debuginfod
+ gdb-add-index may trigger debuginfod's first-use notice. The notice
+ is misleading in this case. It instructs the user to modify .gdbinit
+ in order to permanently enable/disable debuginfod but gdb-add-index
+ invokes gdb with -nx which ignores .gdbinit.
+
+ Additionally debuginfod is not needed for gdb-add-index since the
+ symbol file is given as an argument and should already be present
+ locally.
+
+ Fix this by disabling debuginfod when gdb-add-index invokes gdb.
+
+2022-02-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add operator+= and operator+ overload for std::string
+ This commit adds operator+= and operator+ overloads for adding
+ gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3
+ places in GDB where this was useful right now, and these all make use
+ of operator+=.
+
+ I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
+ makes use of both operator+= and operator+, so they are both getting
+ used/tested.
+
+ There should be no user visible changes after this commit, except when
+ running 'maint selftest', where the new self test is visible.
+
+2022-02-25 Tom Tromey <tromey@adacore.com>
+
+ Print MI prompt on interrupted command
+ Joel noticed that if the remote dies unexpectedly during a command --
+ you can simulate this by using "continue" and then killing gdbserver
+ -- then the CLI will print a new prompt, but MI will not. Later, we
+ found out that this was also filed in bugzilla as PR mi/23820.
+
+ The output looks something like this:
+
+ | (gdb)
+ | cont
+ | &"cont\n"
+ | ~"Continuing.\n"
+ | ^running
+ | *running,thread-id="all"
+ | (gdb)
+ | [... some output from GDB during program startup...]
+ | =thread-exited,id="1",group-id="i1"
+ | =thread-group-exited,id="i1"
+ | &"Remote connection closed\n"
+
+ Now, what about that "(gdb)" in the middle?
+
+ That prompt comes from this questionable code in
+ mi-interp.c:mi_on_resume_1:
+
+ /* This is what gdb used to do historically -- printing prompt
+ even if it cannot actually accept any input. This will be
+ surely removed for MI3, and may be removed even earlier. */
+ if (current_ui->prompt_state == PROMPT_BLOCKED)
+ fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
+
+ ... which seems like something to remove. But maybe the intent here
+ is that this prompt is sufficient, and MI clients must be ready to
+ handle output coming after a prompt. On the other hand, if this code
+ *is* removed, then nothing would print a prompt in this scenario.
+
+ Anyway, the CLI and the TUI handle emitting the prompt here by hooking
+ into gdb::observers::command_error, but MI doesn't install an observer
+ here.
+
+ This patch adds the missing observer and arranges to show the MI
+ prompt. Regression tested on x86-64 Fedora 34.
+
+ It seems like this area could be improved a bit, by having
+ start_event_loop call the prompt-displaying code directly, rather than
+ indirecting through an observer. However, I haven't done this.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820
+
+2022-02-25 Andrew Burgess <aburgess@redhat.com>
+ Tom Tromey <tromey@adacore.com>
+
+ gdb/testsuite: fix list.exp test cases
+ PR testsuite/7142 -- old enough to have been converted from Gnats --
+ points out that test_list_filename_and_function in gdb.base/list.exp
+ has "fails" that are unmatched with passes. This patch cleans this up
+ a little.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142
+
+2022-02-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Remove a loop in the ISA parser
+ Since commit e601909a3287bf541c6a7d82214bb387d2c76d82 ("RISC-V: Support
+ to parse the multi-letter prefix in the architecture string.") changed
+ so that all prefixed extensions are parsed in single
+ riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset
+ is no longer required.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop.
+
+2022-02-25 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Fix mask for some fcvt instructions
+ This commit fixes incorrect uses of mask values in 'fcvt' instruction
+ family.
+
+ opcodes/ChangeLog:
+
+ * riscv-opc.c (riscv_opcodes): Fix incorrect uses of mask values
+ in 'fcvt' instruction family.
+
+2022-02-25 Keith Seitz <keiths@redhat.com>
+
+ Support template lookups in strncmp_iw_with_mode
+ This patch adds support for wild template parameter list matches, similar
+ to how ABI tags or function overloads are now handled.
+
+ With this patch, users will be able to "gloss over" the details of matching
+ template parameter lists. This is accomplished by adding (yet more) logic
+ to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
+ by the user.
+
+ Here's a simple example using gdb.linespec/cpls-ops.exp:
+
+ Before
+ ------
+ (gdb) ptype test_op_call
+ type = struct test_op_call {
+ public:
+ void operator()(void);
+ void operator()(int);
+ void operator()(long);
+ void operator()<int>(int *);
+ }
+ (gdb) b test_op_call::operator()
+ Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
+ (gdb) i b
+ Num Type Disp Enb Address What
+ 1 breakpoint keep y <MULTIPLE>
+ 1.1 y 0x400583 in test_op_call::operator()(int)
+ at cpls-ops.cc:43
+ 1.2 y 0x40058e in test_op_call::operator()()
+ at cpls-ops.cc:47
+ 1.3 y 0x40059e in test_op_call::operator()(long)
+ at cpls-ops.cc:51
+
+ The breakpoint at test_op_call::operator()<int> was never set.
+
+ After
+ -----
+ (gdb) b test_op_call::operator()
+ Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
+ (gdb) i b
+ Num Type Disp Enb Address What
+ 1 breakpoint keep y <MULTIPLE>
+ 1.1 y 0x400583 in test_op_call::operator()(int)
+ at cpls-ops.cc:43
+ 1.2 y 0x40058e in test_op_call::operator()()
+ at cpls-ops.cc:47
+ 1.3 y 0x40059e in test_op_call::operator()(long)
+ at cpls-ops.cc:51
+ 1.4 y 0x4008d0 in test_op_call::operator()<int>(int*)
+ at cpls-ops.cc:57
+
+ Similar to how scope lookups work, passing "-qualified" to the break command
+ will cause a literal lookup of the symbol. In the example immediately above,
+ this will cause GDB to only find the three non-template functions.
+
+2022-02-25 Keith Seitz <keiths@redhat.com>
+
+ Unit tests for strncmp_iw_with_mode
+ This patch attempts to make a start at adding unit tests for
+ strncmp_iw_with_mode. While there is quite a bit of testing
+ of this function in other tests, these are currently end-to-end
+ tests.
+
+ This patch attempts to cover the basics of string matching, white
+ space, C++ ABI tags, and several other topics. However, one area
+ that is ostensibly missing is testing the `match_for_lcd' feature.
+ This is otherwise tested as part of our end-to-end DejaGNU-based
+ testing.
+
+2022-02-25 Keith Seitz <keiths@redhat.com>
+
+ Move find_toplevel_char to cp-support.[ch]
+ find_toplevel_char is being used more and more outside of linespec.c, so
+ this patch moves it into cp-support.[ch].
+
+2022-02-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-24 Tom Tromey <tom@tromey.com>
+ Andrew Burgess <aburgess@redhat.com>
+
+ Fix crash in Fortran code
+ PR fortran/28801 points out a gdb crash that can be provoked by
+ certain Fortran code. The bug is that f77_get_upperbound assumes the
+ property is either a constant or undefined, but in this case it is
+ PROP_LOCEXPR.
+
+ This patch fixes the crash by making this function (and the
+ lower-bound one as well) do the correct check before calling
+ 'const_val'.
+
+ Thanks to Andrew for writing the test case.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801
+
+2022-02-24 John Baldwin <jhb@FreeBSD.org>
+
+ Revert "do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async."
+ Commit 14b3360508b1 ("do_target_wait_1: Clear
+ TARGET_WNOHANG if the target isn't async.") broke some multi-target
+ tests, such as gdb.multi/multi-target-info-inferiors.exp. The symptom
+ is that execution just hangs at some point. What happens is:
+
+ 1. One remote inferior is started, and now sits stopped at a breakpoint.
+ It is not "async" at this point (but it "can async").
+
+ 2. We run a native inferior, the event loop gets woken up by the native
+ target's fd.
+
+ 3. In do_target_wait, we randomly choose an inferior to call target_wait
+ on first, it happens to be the remote inferior.
+
+ 4. Because the target is currently not "async", we clear
+ TARGET_WNOHANG, resulting in synchronous wait. We therefore block
+ here:
+
+ #0 0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
+ #1 0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
+ #2 0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
+ #3 0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
+ #4 0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
+ #5 0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
+ #6 0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
+ #7 0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
+ #8 0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
+ #9 0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
+ #10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
+ #11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
+ #12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
+ #13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
+ #14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
+ #15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
+ #16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
+ #17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061
+
+ Before the aforementioned commit, we would not have cleared
+ TARGET_WNOHANG, the remote target's wait would have returned nothing,
+ and we would have consumed the native target's event.
+
+ After applying this revert, the testsuite state looks as good as before
+ for me on Ubuntu 20.04 amd64.
+
+ Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f
+
+2022-02-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use a range based for loop when iterating over an array
+ Make use of a range based for loop to iterate over a static global
+ array, removing the need to have a null entry at the end of the
+ array.
+
+ There should be no user visible changes after this commit.
+
+2022-02-24 Dominique Quatravaux <dominique.quatravaux@epfl.ch>
+ Louis-He <1726110778@qq.com>
+ Philippe Blain <levraiphilippeblain@gmail.com>
+
+ gdb/darwin: skip over WIFSTOPPED wait4 status
+ On modern Darwin's, there appears to be a new circumstance in which a
+ MACH_NOTIFY_DEAD_NAME message can be received, and which was not
+ previously accounted for: to signal the WIFSTOPPED condition in the
+ debuggee. In that case the debuggee is not dead yet (and in fact,
+ counting it as dead would cause a zombie leak - A process in such a
+ state reparents to PID 1, but cannot be killed).
+
+ - Read and ignore such messages (counting on the next exception message
+ to let us know of the inferior's new state again)
+ - Refactor logging so as to clearly distinguish between the
+ MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
+ something else), and warn in the last case
+
+ Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1
+
+2022-02-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-tdep: move "Perms" column right
+ Commit 29ef4c0699e1 ("gdb/linux-tdep.c: Add Perms to the 'info proc
+ mappings' output") has broken test gdb.base/info-proc.exp on Linux,
+ because it changes the output of "info proc mappings" in a way that the
+ test does not expect (my bad for not testing before pushing).
+
+ I looked at how FreeBSD handles this, since I remembered it did show
+ permission flags. It looks like this:
+
+ Start Addr End Addr Size Offset Flags File
+ 0x200000 0x243000 0x43000 0x0 r-- CN-- /usr/local/bin/tmux
+
+ (I think that `Flags` and the flags not being aligned is not
+ intentional)
+
+ The test passes on FreeBSD, because the test looks for four hex numbers
+ in a row and ignores the rest:
+
+ ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"
+
+ I suggest fixing it on Linux by moving the flags column to the same
+ place as in the FreeBSD output. It makes things a bit more consistent
+ between OSes, and we don't have to touch the test.
+
+ At the same time, make use of the actual length of the permission's
+ string to specify the number of characters to print.
+
+ Before this patch, the output looks like:
+
+ Start Addr End Addr Perms Size Offset objfile
+ 0x55dd4b544000 0x55dd4b546000 r--p 0x2000 0x0 /usr/bin/sleep
+
+ and after, it looks like:
+
+ Start Addr End Addr Size Offset Perms objfile
+ 0x5622ae662000 0x5622ae664000 0x2000 0x0 r--p /usr/bin/sleep
+
+ Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f
+
+2022-02-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux-tdep: make read_mapping return a structure
+ Change read_mapping to return a structure instead of taking many output
+ parameters. Change the string + length output parameters (permissions
+ and device) to be gdb::string_view, since that's what string_view is
+ for (a non-NULL terminated view on a string). No changes in behavior
+ expected.
+
+ Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112
+
+2022-02-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-23 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in C++ overload resolution
+ PR c++/28901 points out a bug in C++ overload resolution. When
+ comparing two overloads, one might be better than the other for
+ certain parameters -- but, if that one also has some invalid
+ conversion, then it should never be considered the better choice.
+ Instead, a valid-but-not-apparently-quite-as-good overload should be
+ preferred.
+
+ This patch fixes this problem by changing how overload comparisons are
+ done. I don't believe it should affect any currently valid overload
+ resolution; nor should it affect resolutions where all the choices are
+ equally invalid.
+
+2022-02-23 Dominik 'Disconnect3d' Czarnota <dominik.b.czarnota@gmail.com>
+
+ gdb/linux-tdep.c: Add Perms to the 'info proc mappings' output
+ Fixes #28914 and so it adds a 'Perms' (permissions) column to the
+ 'info proc mappings' command output. This will allow users to know
+ the memory pages permissions right away from GDB instead of having
+ to fetch them from the /proc/$pid/maps file (which is also what GDB
+ does internally, but it just did not print that column).
+
+ Below I am also showing how an example output looks like before and
+ after this commit in case someone wonders.
+
+ On i386 targets - before this commit:
+ ```
+ (gdb) info proc mappings
+ process 3461464
+ Mapped address spaces:
+
+ Start Addr End Addr Size Offset objfile
+ 0x56555000 0x56556000 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out
+ 0x56556000 0x56557000 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out
+ 0x56557000 0x56558000 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0x56558000 0x5655a000 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0xf7fc4000 0xf7fc8000 0x4000 0x0 [vvar]
+ 0xf7fc8000 0xf7fca000 0x2000 0x0 [vdso]
+ 0xf7fca000 0xf7fcb000 0x1000 0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7fcb000 0xf7fee000 0x23000 0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7fee000 0xf7ffb000 0xd000 0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7ffb000 0xf7ffe000 0x3000 0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xfffdc000 0xffffe000 0x22000 0x0 [stack]
+ (gdb)
+ ```
+
+ On i386 targets - after this commit:
+ ```
+ (gdb) info proc mappings
+ process 3461464
+ Mapped address spaces:
+
+ Start Addr End Addr Perms Size Offset objfile
+ 0x56555000 0x56556000 r--p 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out
+ 0x56556000 0x56557000 r-xp 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out
+ 0x56557000 0x56558000 r--p 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0x56558000 0x5655a000 rw-p 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0xf7fc4000 0xf7fc8000 r--p 0x4000 0x0 [vvar]
+ 0xf7fc8000 0xf7fca000 r-xp 0x2000 0x0 [vdso]
+ 0xf7fca000 0xf7fcb000 r--p 0x1000 0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7fcb000 0xf7fee000 r-xp 0x23000 0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7fee000 0xf7ffb000 r--p 0xd000 0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xf7ffb000 0xf7ffe000 rw-p 0x3000 0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
+ 0xfffdc000 0xffffe000 rw-p 0x22000 0x0 [stack]
+ (gdb)
+ ```
+
+ On amd64 targets - after this commit:
+ ```
+ (gdb) info proc mappings
+ process 3461869
+ Mapped address spaces:
+
+ Start Addr End Addr Perms Size Offset objfile
+ 0x555555554000 0x555555555000 r--p 0x1000 0x0 /home/dc/src/binutils-gdb/build/a.out
+ 0x555555555000 0x555555556000 r-xp 0x1000 0x1000 /home/dc/src/binutils-gdb/build/a.out
+ 0x555555556000 0x555555557000 r--p 0x1000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0x555555557000 0x555555559000 rw-p 0x2000 0x2000 /home/dc/src/binutils-gdb/build/a.out
+ 0x7ffff7fc3000 0x7ffff7fc7000 r--p 0x4000 0x0 [vvar]
+ 0x7ffff7fc7000 0x7ffff7fc9000 r-xp 0x2000 0x0 [vdso]
+ 0x7ffff7fc9000 0x7ffff7fca000 r--p 0x1000 0x0 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+ 0x7ffff7fca000 0x7ffff7ff1000 r-xp 0x27000 0x1000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+ 0x7ffff7ff1000 0x7ffff7ffb000 r--p 0xa000 0x28000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+ 0x7ffff7ffb000 0x7ffff7fff000 rw-p 0x4000 0x31000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+ 0x7ffffffdd000 0x7ffffffff000 rw-p 0x22000 0x0 [stack]
+ 0xffffffffff600000 0xffffffffff601000 --xp 0x1000 0x0 [vsyscall]
+ (gdb)
+ ```
+
+ Change-Id: I4991f6cc758cd532eae3ae98c29d22e7bd9d9c36
+
+2022-02-23 Patrick O'Neill <patrick@rivosinc.com>
+
+ RISC-V: PR28733, add missing extension info to 'unrecognized opcode' error
+ Currently we report errors as "unrecognized opcode `fence.i'" when the
+ opcode isn't part of the selected extensions.
+ This patch expands that error message to include the missing extension
+ information. For example, now the error message would be "unrecognized
+ opcode `fence.i', extension `zifencei' required".
+ If the opcode is not a part of any extension, the error message reverts
+ to "unrecognized opcode `<op statement>'".
+
+
+ bfd/
+ pr 28733
+ * elfxx-riscv.c (riscv_multi_subset_supports_ext): New function,
+ used to return the extension string for each INSN_CLASS_*.
+ * elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext.
+ gas/
+ pr 28733
+ * config/tc-riscv.c (struct riscv_ip_error): New structure,
+ contains information about errors that occur within the riscv_ip.
+ (riscv_ip): Use struct riscv_ip_error to report more detailed errors.
+ * testsuite/gas/riscv/c-fld-fsd-fail.l: Updated.
+ * testsuite/gas/riscv/march-imply-i2p1-01.: Likewise.
+
+2022-02-23 Patrick O'Neill <patrick@rivosinc.com>
+
+ RISC-V: PR28733, add missing extension info to 'invalid CSR' error
+ Currently we report errors as "invalid CSR 'fscr' for the current ISA"
+ when the instruction isn't valid.
+
+ This patch expands that error message to include the missing extension
+ information. For example, now the error message would be "invalid CSR
+ 'fscr' for the current ISA, CSR 'fscr' needs 'f' extension".
+
+
+ gas/
+ pr 28733
+ * config/tc-riscv.c (riscv_csr_address): Report more details
+ when the CSR is invalid.
+ * testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors.
+ * testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+
+2022-02-23 Alan Modra <amodra@gmail.com>
+
+ binutils 2.38 vs. ppc32 linux kernel
+ Commit b25f942e18d6 made .machine more strict. Weaken it again.
+
+ * config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
+ keeping sticky options to work around gcc bugs.
+
+2022-02-23 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Updated CSRs to privileged spec v1.12 and debug spec v1.0.
+ * Removed N extension CSRs,
+ ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip.
+
+ * Removed two supervisor CSRs,
+ sedeleg and sideleg.
+
+ * Changed debug CSR address of scontext from 0x7aa to 0x5a8. We cannot support
+ different versions of debug specs for now, so only supporting the latest one is
+ the only way to move forward.
+
+ * Added debug CSRs,
+ mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1).
+
+ * Regarded hcontext as a debug CSR.
+
+ include/
+ * opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and
+ debug spec v1.0.
+ gas/
+ * testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12
+ and debug spec v1.0.
+ * testsuite/gas/riscv/csr-dw-regnums.d: 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: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
+
+2022-02-23 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Add Privileged Architecture 1.12 CSRs
+ This commit adds,
+
+ * Most of CSRs as listed in the Privileged Architecture,
+ version 1.12 (except scontext and mscontext).
+
+ * Testcases for most CSRs added on the Privileged
+ Architecture, version 1.12 (except moved "scontext" and
+ new "mscontext").
+
+ include/ChangeLog:
+
+ * opcode/riscv-opc.h (CSR_SENVCFG, CSR_MCONFIGPTR, CSR_MENVCFG,
+ CSR_MSTATUSH, CSR_MENVCFGH, CSR_MTINST, CSR_MTVAL2, CSR_MSECCFG,
+ CSR_MSECCFGH, CSR_PMPCFG4, CSR_PMPCFG5, CSR_PMPCFG6,
+ CSR_PMPCFG7, CSR_PMPCFG8, CSR_PMPCFG9, CSR_PMPCFG10,
+ CSR_PMPCFG11, CSR_PMPCFG12, CSR_PMPCFG13, CSR_PMPCFG14,
+ CSR_PMPCFG15, CSR_PMPADDR16, CSR_PMPADDR17, CSR_PMPADDR18,
+ CSR_PMPADDR19, CSR_PMPADDR20, CSR_PMPADDR21, CSR_PMPADDR22,
+ CSR_PMPADDR23, CSR_PMPADDR24, CSR_PMPADDR25, CSR_PMPADDR26,
+ CSR_PMPADDR27, CSR_PMPADDR28, CSR_PMPADDR29, CSR_PMPADDR30,
+ CSR_PMPADDR31, CSR_PMPADDR32, CSR_PMPADDR33, CSR_PMPADDR34,
+ CSR_PMPADDR35, CSR_PMPADDR36, CSR_PMPADDR37, CSR_PMPADDR38,
+ CSR_PMPADDR39, CSR_PMPADDR40, CSR_PMPADDR41, CSR_PMPADDR42,
+ CSR_PMPADDR43, CSR_PMPADDR44, CSR_PMPADDR45, CSR_PMPADDR46,
+ CSR_PMPADDR47, CSR_PMPADDR48, CSR_PMPADDR49, CSR_PMPADDR50,
+ CSR_PMPADDR51, CSR_PMPADDR52, CSR_PMPADDR53, CSR_PMPADDR54,
+ CSR_PMPADDR55, CSR_PMPADDR56, CSR_PMPADDR57, CSR_PMPADDR58,
+ CSR_PMPADDR59, CSR_PMPADDR60, CSR_PMPADDR61, CSR_PMPADDR62,
+ CSR_PMPADDR63): New CSR macros.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+ * testsuite/gas/riscv/csr.s: Add new CSRs.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: 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.
+
+2022-02-23 Tsukasa OI <research_trasio@irq.a4lg.com>
+
+ RISC-V: Reorganize testcases for CFI directives
+ This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to
+ make it test the same CSRs as csr.s.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add
+ defined CSRs tested in csr.s.
+ * testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+
+2022-02-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ NEWS: Note that the FreeBSD async target supports async mode.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ inf-ptrace: Add an event_pipe to be used for async mode in subclasses.
+ Subclasses of inf_ptrace_target have to opt-in to using the event_pipe
+ by implementing the can_async_p and async methods. For subclasses
+ which do this, inf_ptrace_target provides is_async_p, async_wait_fd
+ and closes the pipe in the close target method.
+
+ inf_ptrace_target also provides wrapper routines around the event pipe
+ (async_file_open, async_file_close, async_file_flush, and
+ async_file_mark) for use in target methods such as async.
+ inf_ptrace_target also exports a static async_file_mark_if_open
+ function which can be used in SIGCHLD signal handlers.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ Enable async mode in the target in attach_cmd.
+ If the attach target supports async mode, enable it after the
+ attach target's ::attach method returns.
+
+ fbsd-nat: Return nullptr rather than failing ::thread_name.
+ ptrace on FreeBSD cannot be used against running processes and instead
+ fails with EBUSY. This meant that 'info threads' would fail if any of
+ the threads were running (for example when using schedule-multiple=on
+ in gdb.base/fork-running-state.exp). Instead of throwing errors, just
+ return nullptr as no thread name is better than causing info threads to
+ fail completely.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Various cleanups to the ::resume entry debug message.
+ Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat'
+ since it is helpful for debugging async target support and not just
+ LWP support.
+
+ Use target_pid_to_str to format the ptid and log the step and signo
+ arguments.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Include ptrace operation in error messages.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Implement async target support.
+ This is a fairly simple version of async target support.
+
+ Synchronous mode still uses blocking waitpid() calls in
+ inf_ptrace::wait() unlike the Linux native target which always uses
+ WNOHANG and uses sigsuspend() for synchronous operation.
+
+ Asynchronous mode registers an event pipe with the core as a file
+ handle and writes to the pipe when SIGCHLD is raised. TARGET_WNOHANG
+ is handled by inf_ptrace::wait().
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ inf-ptrace: Support async targets in inf_ptrace_target::wait.
+ - Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning
+ TARGET_WAITKIND_IGNORE if there are no events to report.
+
+ - Handle a race in async mode where SIGCHLD might signal the event
+ pipe for an event that has already been reported. If the event was
+ the exit of the last child process, waitpid() will fail with ECHILD
+ rather than returning a pid of 0. For this case, return
+ TARGET_WAITKIND_NO_RESUMED.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ inf-ptrace: Return an IGNORE event if waitpid() fails.
+ Previously this returned a TARGET_WAITKIND_SIGNALLED event for
+ inferior_ptid. However, inferior_ptid is invalid during ::wait()
+ methods after the multi-target changes, so this was triggering an
+ assertion further up the stack.
+
+ do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async.
+ Previously, TARGET_WNOHANG was cleared if a target supported async
+ mode even if async mode wasn't currently enabled. This change only
+ permits TARGET_WNOHANG if async mode is enabled.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ Don't enable async mode at the end of target ::resume methods.
+ Now that target_resume always enables async mode after target::resume
+ returns, these calls are redundant.
+
+ The other place that target resume methods are invoked outside of
+ target_resume are as the beneath target in record_full_wait_1. In
+ this case, async mode should already be enabled when supported by the
+ target before the resume method is invoked due to the following:
+
+ In general, targets which support async mode run as async until
+ ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
+ no unwaited for children (either they have exited or are stopped).
+ When that occurs, the loop in wait_one disables async mode. Later
+ if a stopped child is resumed, async mode is re-enabled in
+ do_target_resume before waiting for the next event.
+
+ In the case of record_full_wait_1, this function is invoked from the
+ ::wait target method when fetching an event. If the underlying
+ target supports async mode, then an earlier call to do_target_resume
+ to resume the child reporting an event in the loop in
+ record_full_wait_1 would have already enabled async mode before
+ ::wait was invoked. In addition, nothing in the code executed in
+ the loop in record_full_wait_1 disables async mode. Async mode is
+ only disabled higher in the call stack in wait_one after ::wait
+ returns.
+
+ It is also true that async mode can be disabled by an
+ INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
+ the places that invoke that are in the gdb core which is "above" a
+ target ::wait method.
+
+ Note that there is an earlier call to enable async mode in
+ linux_nat_target::resume. That call also marks the async event pipe
+ to report an existing event after enabling async mode, so it needs to
+ stay.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ Enable async mode on supported targets in target_resume.
+ Enabling async mode above the target layer removes duplicate code in
+ ::resume methods of async-capable targets. Commit 5b6d1e4fa4f
+ ("Multi-target support") enabled async mode in do_target_resume after
+ target_resume returns which is a step in this direction. However,
+ other callers of target_resume such as target_continue do not enable
+ async mode. Rather than enabling async mode in each of the callers
+ after target_resume returns, enable async mode at the end of
+ target_resume.
+
+ gdbserver linux-low: Convert linux_event_pipe to the event_pipe class.
+ Use event_pipe from gdbsupport in place of the existing file
+ descriptor array.
+
+ gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class.
+ Use event_pipe from gdbsupport in place of the existing file
+ descriptor array.
+
+2022-02-22 John Baldwin <jhb@FreeBSD.org>
+
+ gdbsupport: Add an event-pipe class.
+ This pulls out the implementation of an event pipe used to implement
+ target async support in both linux-low.cc (gdbserver) and linux-nat.c
+ (gdb).
+
+ This will be used to replace the existing event pipe in linux-low.cc
+ and linux-nat.c in future commits.
+
+ Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
+
+2022-02-22 Ruslan Kabatsayev <b7.10110111@gmail.com>
+
+ gdb: fix detection of compilation and linking flags for source-highlight
+ Currently there are two problems with the detection of
+ source-highlight via pkg-config in GDB's configure script:
+
+ 1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
+ to AC_LINK_IFELSE, which results in the "-L/some/path
+ -lsource-highlight" preceding the conftest.cpp, which can result in a
+ failure to find symbols referenced in conftest.cpp, if the linker is
+ using --as-needed by default.
+
+ 2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
+ output to AC_LINK_IFELSE. However, as the current language is C++,
+ AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
+ returned from pkg-config will not be seen.
+
+ This patch fixes both of these mistakes, allowing GDB to correctly
+ configure and build using source-highlight installed into a custom
+ prefix, e.g. ~/opt/gdb-git (because the system version of
+ source-highlight is too old).
+
+2022-02-22 Philippe Blain <levraiphilippeblain@gmail.com>
+
+ gdb/testsuite/README: point to default value of INTERNAL_GDBFLAGS
+ The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013
+ ([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
+ disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07)
+ to point to the data directory, but its default value mentioned in the
+ testsuite's README was not kept up to date.
+
+ To avoid it getting out of sync even more, point the reader to the
+ definition of the variable in lib/gdb.exp, and move the explanation of
+ the different flags there. Also adjust the example in the README
+ so it follows the flags added in 55c3ad88013.
+
+ Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7
+
+2022-02-22 Kito Cheng <kito.cheng@sifive.com>
+
+ RISC-V: Maintain a string to hold the canonical order
+ Using dummy entry in riscv_supported_std_ext cause confusing and wrongly
+ support `b` and `k` extensions.
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported
+ extensions.
+ (riscv_ext_canonical_order): New.
+ (riscv_init_ext_order): Use riscv_ext_canonical_order rather
+ than riscv_supported_std_ext to compute canonical order.
+
+ V2 Changes:
+
+ - Use `*ext` rather than `*ext != NULL` for checking is reach end of
+ string.
+
+2022-02-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-21 Alan Modra <amodra@gmail.com>
+
+ Re: ld: Support customized output section type
+ "DO NOT EDIT!" says the comment at the top of bfd-in2.h. Move the new
+ type field where it belongs.
+
+ PR ld/28841
+ * section.c (struct bfd_section): Add type. Formatting.
+ (BFD_FAKE_SECTION): Formatting.
+ * bfd-in2.h: Regenerate.
+
+2022-02-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: gdbinit: hoist setup to common code
+ This was left in subdirs because of the dynamic cgen usage. However,
+ we can move this breakpoint call to runtime and let gdb detect whether
+ the symbol exists.
+
+2022-02-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test
+ I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
+ added recently. This test was added in commit:
+
+ commit d08cbc5d3203118da5583296e49273cf82378042
+ Date: Wed Dec 22 12:57:44 2021 +0000
+
+ gdb: unbuffer all input streams when not using readline
+
+ The failures I see only occurred when my machine was very heavily
+ loaded.
+
+ In this test I send multiple commands from dejagnu to gdb with a
+ single send_gdb call. In a well behaving world what I want to happen
+ is that the gdb console sees both commands arrive and echos the text
+ of those commands. Then gdb starts processing the first command,
+ prints the result, and then processes the second command, and prints
+ the result.
+
+ However, what I saw in my loaded environment was that only after
+ sending the two commands, only the first command was echoed to gdb's
+ terminal. Then gdb started processing the first command, and started
+ to write the output. Now, mixed in with the first command output, the
+ second command was echoed to gdb's terminal. Finally, gdb would
+ finish printing the first command output, and would read and handle
+ the second command.
+
+ This mixing of command echoing with the first command output was
+ causing the test matching patterns to fail.
+
+ In this commit I change the command I use in the test from a CLI
+ command to an MI command, this reduces the number of lines of output
+ that come from the test, CLI commands sent through the MI interpreter
+ are echoed back like this:
+
+ (gdb)
+ set $a = "FIRST COMMAND"
+ &"set $a = \"FIRST COMMAND\"\n"
+ ^done
+ (gdb)
+
+ While this is not the case for true MI command:
+
+ (gdb)
+ -data-evaluate-expression $a
+ ^done,value="\"FIRST COMMAND\""
+ (gdb)
+
+ Less output makes for simpler patterns to match against.
+
+ Next, when sending two command to gdb I was previously trying to spot
+ the output of the first command followed by the prompt with nothing
+ between. This is not really needed, for the first command I can look
+ for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
+ looking for the output of the second command.
+
+ So long as the second pattern matches up to the gdb prompt, then I can
+ be sure than nothing is left over in the expect buffer to muck up
+ later matches.
+
+ As to see the second command output gdb must have read in the second
+ command, the second command output never suffers from the corruption
+ that the first command output does.
+
+ Since making this change, I've not seen a failure in this test.
+
+2022-02-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: avoid nullptr access in dbxread.c from read_dbx_symtab
+ This fixes a GDB crash reported in bug pr/28900, related to reading in
+ some stabs debug information.
+
+ In this commit my goal is to stop GDB crashing. I am not trying to
+ ensure that GDB makes the best possible use of the available stabs
+ debug information. At this point I consider stabs a legacy debug
+ format, with only limited support in GDB.
+
+ So, the problem appears to be that, when reading in the stabs data, we
+ need to find a N_SO entry, this is the entry that defines the start of
+ a compilation unit (or at least the location of a corresponding source
+ file).
+
+ It is while handling an N_SO that GDB creates a psymtab to hold the
+ incoming debug information (symbols, etc).
+
+ The problem we hit in the bug is that we encounter some symbol
+ information (an N_PC entry) outside of an N_SO entry - that is we find
+ some symbol information that is not associated with any source file.
+
+ We already have some protection for this case, look (in
+ read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f',
+ if we have no psymtab (the pst variable is nullptr) then we issue a
+ complaint. However, for whatever reason, in both 'f' and 'F'
+ handling, there is one place where we assume that the pst
+ variable (the psymtab) is not nullptr. This is a mistake.
+
+ In this commit, I guard these two locations (in 'f' and 'F' handling)
+ so we no longer assume pst is not nullptr.
+
+ While I was at it, I audited all the other uses of pst in
+ read_dbx_symtab, and in every potentially dangerous case I added a
+ nullptr check, and issue a suitable complaint if pst is found to be
+ nullptr.
+
+ It might well be true that we could/should do something smarter if we
+ see a debug symbol outside of an N_SO entry, and if anyone wanted to
+ do that work, they're welcome too. But this commit is just about
+ preventing the nullptr access, and the subsequent GDB crash.
+
+ I don't have any tests for this change, I have no idea how to generate
+ weird stabs data for testing. The original binary from the bug report
+ now loads just fine without GDB crashing.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28900
+
+2022-02-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make use of std::string in dbxread.c and xcoffread.c
+ While taking a look through dbxread.c I spotted a couple of places
+ where making use of std::string would remove the need for manual
+ memory allocation and memcpy.
+
+ During review Simon pointed out that the same code exists in
+ xcoffread.c, so I've applied the same fix there too.
+
+ There should be no user visible changes after this commit.
+
+2022-02-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-20 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Only paginate for filtered output in fputs_maybe_filtered
+ A have had situation where a unfiltered output (done using
+ fputs_unfiltered) ended up triggering pagination. The backtrace for this was:
+
+ ...
+ #24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335
+ #25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216
+ #26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148
+ #27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438
+ #28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752
+ #29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 " [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811
+ ...
+
+ This comes from what appears to be a oversight in fputs_maybe_filtered. This
+ function has a FILTER parameter which if true makes the function pause after
+ every screenful (i.e. triggers pagination).
+
+ The filter parameter is correctly used to guard the first place where
+ prompt_for_continue. There is a second place in the function which can call
+ prompt_for_continue, but is currently unguarded. I believe that this is an
+ oversight, this patch fixes that.
+
+ Tested on Linux-x86_64, no regression observed.
+
+ Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece
+
+2022-02-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-19 Dominique Quatravaux <dominique.quatravaux@epfl.ch>
+
+ gdb/darwin: remove not-so-harmless spurious call to `wait4`
+ As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this
+ code will typically wait4() a second time on the same process that was
+ already wait4()'d a few lines above. While this used to be
+ harmless/idempotent (when we assumed that the process already exited),
+ this now causes a deadlock in the WIFSTOPPED case.
+
+ The early (~2019) history of bug #24069 cautiously suggests to use
+ WNOHANG instead of outright deleting the call. However, tests on the
+ current version of Darwin (Big Sur) demonstrate that gdb runs just fine
+ without a redundant call to wait4(), as would be expected.
+ Notwithstanding the debatable value of conserving bug compatibility with
+ an OS release that is more than a decade old, there is scant evidence of
+ what that double-wait4() was supposed to achieve in the first place - A
+ cursory investigation with `git blame` pinpoints commits bb00b29d7802
+ and a80b95ba67e2 from the 2008-2009 era, but fails to answer the
+ "why" question conclusively.
+
+ Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com>
+ Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0
+
+2022-02-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-18 Tom Tromey <tromey@adacore.com>
+
+ Add constructor to bound_minimal_symbol
+ This adds a constructor to bound_minimal_symbol, to avoid a build
+ failure with clang that Simon pointed out.
+
+ I also took the opportunity to remove some redundant initializations,
+ and to change one use of push_back to emplace_back, as suggested by
+ Simon.
+
+2022-02-18 Roland McGrath <mcgrathr@google.com>
+
+ Fix typo in ld.texi
+ ld/
+ * ld.texi (Output Section Type): Fix typo in @code syntax.
+
+2022-02-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove newlines from some linux_nat_debug_printf calls
+ Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10
+
+2022-02-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-17 Nick Clifton <nickc@redhat.com>
+
+ Updated Serbian translations for the bfd, gold, ld and opcodes directories
+
+2022-02-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-16 Fangrui Song <maskray@google.com>
+
+ ld: Support customized output section type
+ bfd/
+ PR ld/28841
+ * bfd-in2.h (struct bfd_section): Add type.
+ (discarded_section): Add field.
+ * elf.c (elf_fake_sections): Handle bfd_section::type.
+ * section.c (BFD_FAKE_SECTION): Add field.
+ * mri.c (mri_draw_tree): Update function call.
+
+ ld/
+ PR ld/28841
+ * ld.texi: Document new output section type.
+ * ldlex.l: Add new token TYPE.
+ * ldgram.y: Handle TYPE=exp.
+ * ldlang.h: Add type_section to list of section types.
+ * ldlang.c (lang_add_section): Handle type_section.
+ (map_input_to_output_sections): Handle type_section.
+ * testsuite/ld-scripts/output-section-types.t: Add tests.
+ * testsuite/ld-scripts/output-section-types.d: Update.
+
+2022-02-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: add a missing white space character
+ Just adds a missing space. There should be no user visible changes
+ after this commit.
+
+ gdb: convert callback_handler_installed from int to bool
+ Simple int to bool conversion on callback_handler_installed in
+ event-top.c. There should be no user visible changes after this
+ commit.
+
+2022-02-16 Alan Modra <amodra@gmail.com>
+
+ gas local label and dollar label handling
+ Much of the gas source and older BFD source use "long" for function
+ parameters and variables, when other types would be more appropriate.
+ This patch fixes one of those cases. Dollar labels and numeric local
+ labels do not need large numbers. Small positive itegers are usually
+ all that is required. Due to allowing longs, it was possible for
+ fb_label_name and dollar_label_name to overflow their buffers.
+
+ * symbols.c: Delete unnecessary forward declarations.
+ (dollar_labels, dollar_label_instances): Use unsigned int.
+ (dollar_label_defined, dollar_label_instance): Likewise.
+ (define_dollar_label): Likewise.
+ (fb_low_counter, fb_labels, fb_label_instances): Likewise.
+ (fb_label_instance_inc, fb_label_instance): Likewise.
+ (fb_label_count, fb_label_max): Make them size_t.
+ (dollar_label_name, fb_label_name): Rewrite using sprintf.
+ * symbols.h (dollar_label_defined): Update prototype.
+ (define_dollar_label, dollar_label_name): Likewise.
+ (fb_label_instance_inc, fb_label_name): Likewise.
+ * config/bfin-lex.l (yylex): Remove unnecessary casts.
+ * expr.c (integer_constant): Likewise.
+ * read.c (read_a_source_file): Limit numeric label range to int.
+
+2022-02-16 Alan Modra <amodra@gmail.com>
+
+ ubsan: s_app_line integer overflow
+ There are quite a few ubsan warnings in gas. This one disappears with
+ a code tidy.
+
+ * read.c (s_app_line): Rename 'l' to 'linenum'. Avoid ubsan
+ warning.
+
+2022-02-16 Alan Modra <amodra@gmail.com>
+
+ pe_ILF_make_a_symbol_reloc segfault
+ pei-aarch64-little apparently lacks support for BFD_RELOC_RVA.
+
+ * peicode.h (pe_ILF_make_a_symbol_reloc): Don't segfault on
+ NULL howto.
+
+2022-02-16 Alan Modra <amodra@gmail.com>
+
+ What to do when sh_addralign isn't a power of two
+ BFD generally doesn't handle anything but a power of two section
+ alignment, and ELF sh_addralign is required to be an integral power of
+ two (or zero) by the ELF spec. Of course this is ignored by fuzzers,
+ and because bfd_log2 rounds up, we can end up with alignment_power
+ being 32 on a 32-bit object or 64 on a 64-bit object. That then
+ triggers ubsan warnings in places like bfd_update_compression_header
+ where we want to convert from alignment_power back to an alignment.
+ I suppose we could reject object files that have non-compliant
+ sh_addralign, but I think it's also reasonable to use the greatest
+ power of two divisor of sh_addralign, ie. the rightmost 1 bit.
+
+ * elf.c (_bfd_elf_make_section_from_shdr): Use greatest power
+ of two divisor of sh_addralign.
+ (_bfd_elf_assign_file_position_for_section): Likewise.
+ (assign_file_positions_for_non_load_sections): Likewise.
+
+2022-02-16 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflow in vms-alpha.c
+ * vms-alpha.c (evax_bfd_print_dst): Sanity check another place
+ printing strings.
+
+ asan : use of uninitialized value in buffer_and_nest
+ * macro.c (buffer_and_nest): Don't read past end of string buffer.
+
+ asan: buffer overflow in peXXigen.c
+ * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Properly
+ sanity check DataDirectory[PE_DEBUG_DATA].Size.
+
+2022-02-16 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/common: Improve sim_dump_memory head comment
+ As requested by Mike.
+
+ * sim-memopt.c: Improve head comment.
+
+2022-02-16 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris/c/stat3.c: Fix formatting nit
+ * c/stat3.c (main): Fix formatting nit.
+
+2022-02-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: cleanup the istarget * logic
+ Now that the multitarget testing has settled, clean up the cases where
+ istarget * is used. This ends up being mostly style unindenting.
+
+2022-02-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-15 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL
+ Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation
+ in read-only section.
+
+ bfd/
+
+ PR ld/28894
+ * elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow
+ R_386_TLS_IE.
+
+ ld/
+ PR ld/28894
+ * testsuite/ld-i386/i386.exp: Run pr28894.
+ * testsuite/ld-i386/pr28894.d: New file.
+ * testsuite/ld-i386/pr28894.s: Likewise.
+
+2022-02-15 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite: Default global_cc_os and global_cc_works properly
+ There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set
+ global_cc_os also when no compiler is found"; global_cc_os
+ wasn't set for other than the primary target, which means
+ that the "unguarded" use of global_cc_os in
+ testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read
+ "global_cc_os": no such variable" when e.g. configuring for
+ pru-elf and doing "make check-sim". Better initializing
+ both variables at the top to default values, rather than
+ adding another single 'set global_cc_os ""', to reduce the
+ risk of not setting them properly if or when that
+ if-statement-chain is made longer.
+
+ sim/testsuite:
+ * lib/sim-defs.exp (sim_init_toolchain): Default
+ global_cc_os and global_cc_works properly, before if-chain.
+
+2022-02-15 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Add has_sib to struct instr_info
+ Add has_sib to struct instr_info and use SIB info only if ins->has_sib
+ is true.
+
+ PR binutils/28892
+ * i386-dis.c (instr_info): Add has_sib.
+ (get_sib): Set has_sib.
+ (OP_E_memory): Replace havesib with ins->has_sib.
+ (OP_VEX): Use ins->sib.index only if ins->has_sib is true.
+
+2022-02-15 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Respect the DW_CC_nocall attribute
+ It is possible for a compiler to optimize a function in a such ways that
+ the function does not follow the calling convention of the target. In
+ such situation, the compiler can use the DW_AT_calling_convention
+ attribute with the value DW_CC_nocall to tell the debugger that it is
+ unsafe to call the function. The DWARF5 standard states, in 3.3.1.1:
+
+ > If the value of the calling convention attribute is the constant
+ > DW_CC_nocall, the subroutine does not obey standard calling
+ > conventions, and it may not be safe for the debugger to call this
+ > subroutine.
+
+ Non standard calling convention can affect GDB's assumptions in multiple
+ ways, including how arguments are passed to the function, how values are
+ returned, and so on. For this reason, it is unsafe for GDB to try to do
+ the following operations on a function with marked with DW_CC_nocall:
+
+ - call / print an expression requiring the function to be evaluated,
+ - inspect the value a function returns using the 'finish' command,
+ - force the value returned by a function using the 'return' command.
+
+ This patch ensures that if a command which relies on GDB's knowledge of
+ the target's calling convention is used on a function marked nocall, GDB
+ prints an appropriate message to the user and does not proceed with the
+ operation which is unreliable.
+
+ Note that it is still possible for someone to use a vendor specific
+ value for the DW_AT_calling_convention attribute for example to indicate
+ the use of an alternative calling convention. This commit does not
+ prevent this, and target dependent code can be adjusted if one wanted to
+ support multiple calling conventions.
+
+ Tested on x86_64-Linux, with no regression observed.
+
+ Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540
+
+2022-02-15 Lancelot SIX <lancelot.six@amd.com>
+ Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add a symbol* argument to get_return_value
+ Add an argument to the get_return_value function to indicate the symbol
+ of the function the debuggee is returning from. This will be used by
+ the following patch.
+
+ Since the function return type can be deduced from the symbol remove the
+ value_type argument which becomes redundant.
+
+ No user visible change after this patch.
+
+ Tested on x86_64-linux.
+
+ Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc
+
+2022-02-15 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Use MAXPAGESIZE for the relro segment alignment
+ Adjust x86-64 linker tests after reverting
+
+ commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be
+ Author: Alan Modra <amodra@gmail.com>
+ Date: Thu Feb 3 08:57:47 2022 +1030
+
+ PR28824, relro security issues, x86 keep COMMONPAGESIZE relro
+
+ to use MAXPAGESIZE for the end of the relro segment alignment, like other
+ ELF targets.
+
+ * testsuite/ld-x86-64/plt-main-bnd.dd: Updated.
+ * testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise.
+ * testsuite/ld-x86-64/plt-main-ibt.dd: Likewise.
+ * testsuite/ld-x86-64/pr14207.d: Likewise.
+ * testsuite/ld-x86-64/pr18176.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-02-15 H.J. Lu <hjl.tools@gmail.com>
+
+ Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro"
+ This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be.
+
+2022-02-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris: If failing compilation, mark C tests as errors
+ ...when we know we have a working compiler. This will reduce
+ the risk of faulty edits by exposing them rather than hiding
+ them as "unresolved". It also harmonizes behavior with that of
+ run_sim_test.
+
+ * c/c.exp: Mark C tests failing compilation test errors.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris: Remove faulty use of basename in C tests
+ Calls to basename were added here as part of commit
+ e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that
+ commit missed adding "#include <libgen.h>" or the equivalent
+ GNU extension, see basename(3). Fixing that shows a logical
+ error in the change to openpf1.c; the non-/-prefixed
+ code-path was changed instead of the "/"-prefixed code-path,
+ which is the one executed after that commit.
+
+ For "newlib" these tests failed linking after that commit.
+ Recent newlib has the (asm-renamed) GNU-extension-variant of
+ basename, but we're better off not using it at all.
+
+ Unfortunately, compilation failures for C tests run by the
+ machinery in c.exp are currently just marked "unresolved",
+ in contrast to C and assembler tests run by calling
+ run_sim_test.
+
+ The interaction of calling with the full program-path vs.
+ use of --sysroot exposes a consistency problem: when
+ --sysroot is used, argv[0] isn't the path by which the
+ program can find itself. It's undecided whether argv[0] for
+ the program running in the simulator should be edited
+ (related to the naked argument to the simulator before
+ passing on to the simulated program) to remove a leading
+ --sysroot. Either way, such a change would be out of scope
+ for this commit.
+
+ * c/stat3.c (mybasename): New macro. Use it instead of basename.
+ * c/openpf1.c: Correct basename-related change and update related
+ comment.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim: Add sim_dump_memory for debugging
+ Intended to be called from the debugger tool.
+
+ sim/common:
+ * sim-memopt.c (sim_dump_memory): New function.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim: Fix use of out-of-tree assembler and linker when testing
+ With commit 7a259895bb2d "sim: testsuite: expand arch specific
+ toolchain settings", trying to use out-of-tree ld and as at test-time
+ broke for the "primary target", like when testing a release-tarball.
+
+ Subsequent to that commit, all assembler tests without in-tree-built
+ tools FAIL, getting errors when trying to call
+ $(abs_builddir)/../gas/as-new. But, that isn't the actual culprint;
+ it's actually it's its immediate predecessor, commit 8996c21067373
+ "sim: testsuite: setup per-port toolchain settings for multitarget
+ build", which hardcodes in-tree-paths to those tools instead of
+ considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable
+ for single-target builds, as set up by the toplevel Makefile.
+
+ This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific
+ features aren't used) from toplev/config/acx.m4, somewhat like calls
+ in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS
+ step, for each X to find a value for $(<X>_FOR_TARGET). N.B.: in-tree
+ tools still override any ${target}-${tool} found in $PATH, i.e. only
+ previously broken builds are affected.
+
+ The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel
+ Makefile to the same value or better, but has to be set here too, as
+ automake "wants" Makefiles to be self-contained (you get an error
+ pointing out that the variable may be empty). If it hadn't been for
+ that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed.
+ This detail should only (positively) affect users invoking "make
+ check" in sim/ instead of "make check-sim" (or "make check") at the
+ toplevel. Now the output from "configure" matches the target tools
+ actually used by sim at test-time, for the "primary target".
+
+ Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as
+ that appears to be a deliberate special-case.
+
+ Note that all tools still have to be installed and present in
+ $PATH at configure-time to be properly used at test-time.
+
+ sim:
+ * m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET):
+ New defun.
+ (SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables
+ AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded
+ values.
+ * Makefile.in, configure: Regenerate.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim cris: Unbreak --disable-sim-hardware builds
+ With --disable-sim-hardware (--enable-sim-hardware=no),
+ whose default was changed to --enable-sim-hardware(=yes) in
+ commit 34cf51120683, building for cris-elf fails as
+ sim_hw_parse then doesn't exist.
+
+ A cris-elf simulator configured for --enable-sim-hardware
+ (or the default after to the mentioned commit) runs about
+ 2.5x slower than one configured --disable-sim-hardware.
+ A further 2-5% performance regression was not investigated.
+
+ When sim_hw_parse doesn't exist, --cris-900000xx can't be
+ supported. The best action here is to remove it completely,
+ so its absence can be identified through --help, but
+ avoiding littering the code with "#if WITH_HW".
+
+ sim/cris:
+ * sim-if.c (cris_options) [WITH_HW]: Conditionalize
+ support of option --cris-900000xx.
+ (sim_open) [WITH_HW]: Conditionalize sim_hw_parse
+ call.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris: As applicable, require simoption --cris-900000xx
+ Apply the new run_sim_test option "require" as in "#require
+ simoption --cris-900000xx" for all tests using that option.
+ This allows a clean test-suite-run for a build with
+ --disable-sim-hardware, where that option is not supported,
+ by skipping those tests as "untested".
+
+ sim/testsuite/cris:
+ * asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms,
+ asm/io7.ms: Call "#require: simoption --cris-900000xx".
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite: Support "requires: simoption <--name-of-option>"
+ Simulator features can be present or not, typically
+ depending on different-valued configure options, like
+ --enable-sim-hardware[=off|=on]. To avoid failures in
+ test-suite-runs when testing such configurations, a new
+ predicate is needed, as neither "target", "progos" nor
+ "mach" fits cleanly.
+
+ The immediate need was to check for presence of a simulator
+ option, but rather than a specialized "requires-simoption:"
+ predicate I thought I'd handle the general (parametrized)
+ need, so here's a generic predicate machinery and a (first)
+ predicate to use together with it; checking whether a
+ particular option is supported, by looking at "run --help"
+ output. This was inspired by the check_effective_target_
+ machinery in the gcc test-suite.
+
+ Multiple "requires: <requirement> <parameter>" form a list of
+ predicates (with parameters), to be used as a conjunction.
+
+ sim/testsuite:
+ * lib/sim-defs.exp (sim_check_requires_simoption): New function.
+ (run_sim_test): Support "requires: <requirement> <parameter>".
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris/hw/rv-n-cris/irq1.ms: Disable due to randomness
+ For reasons that remain largely to be investigated (besides
+ the apparent lack of synchronization between two processes),
+ this test fails randomly, with two different sets of common
+ outputs. Curiously, that doesn't happen for the other
+ similar tests. There's a comment that mentions this, though
+ that doesn't make it a sustainable part of a test-suite.
+ (Known-blinking tests should be disabled until fixed.)
+
+ sim/testsuite/cris:
+ * hw/rv-n-cris/irq1.ms: Disable by use of a never-matched
+ "progos" value.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris/c: Use -sim3 but only for newlib targets
+ Commit a39487c6685f "sim: cris: use -sim with C tests for cris-elf
+ targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for
+ cris*-*-elf, where testing had until then relied on
+ "RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make
+ check-sim", adding the right options. While "-sim" happens to work,
+ the baseboard-file cris-sim.exp uses "-sim3" so for consistency use
+ that instead.
+
+ Then commit b42f20d2ac72 "sim: testsuite: drop most specific istarget
+ checks" caused " -sim" to be appended for *all* targets, which just
+ doesn't work. For example, for crisv32-linux-gnu, that's not a
+ recognized option and will cause a dejagnu error and further testing
+ in c.exp will be aborted.
+
+ While cris-sim.exp appends "-static" for *-linux-gnu, further changes
+ in the test-suite have caused "linux"-specific tests to break, so that
+ part will be tended to separately.
+
+ But, save and restore CFLAGS_FOR_TARGET around the modification and
+ use where needed, to not have the CRIS-specific modification affect a
+ continuing test-run (possibly for other targets).
+
+ sim/testsuite/cris:
+ * c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim"
+ with " -sim3", but do it conditionally for newlib targets. Save
+ and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such
+ that it doesn't affect the value of CFLAGS_FOR_TARGET outside
+ c.exp.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite: Set global_cc_os also when no compiler is found
+ If we don't set this variable, it doesn't exist, and using "#progos:"
+ in an assembler-file will cause an error rather than just skipping the
+ test, viz:
+
+ Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ...
+ ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp.
+ ERROR: can't read "global_cc_os": no such variable
+ while executing
+ "if { $opts(progos) != "" && $opts(progos) != $global_cc_os } {
+ untested $subdir/$name
+ return
+ }"
+ (procedure "run_sim_test" line 102)
+
+ Neither the commit introducing progos, nor the top comment
+ in run_sim_test, mentions progos as intended only for C
+ tests, or that its use must be gated on $global_cc_works !=
+ 0, so (not) setting it in the no-working-compiler path seems
+ just overlooked.
+
+ Allowing it to be used for assembler tests makes it usable
+ for e.g. an always-false predicate and in expressions in
+ .exp files without gating on $global_cc_works != 0.
+
+ With this patch, global_cc_os is set to "", just as for "unknown OS".
+
+ sim/testsuite:
+ * lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when
+ no working target C compiler is found.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim/testsuite/cris: Assembler testcase for PRIx32 usage bug
+ Several C test-cases exposed the bug, but let's have one for
+ people who test using just the assembler and linker.
+
+ * asm/endmem1.ms: New test.
+
+2022-02-14 Hans-Peter Nilsson <hp@axis.com>
+
+ sim cris: Correct PRIu32 to PRIx32
+ In 5ee0bc23a68f "sim: clean up bfd_vma printing" there was
+ an additional introduction of PRIx32 and PRIu32 but just in
+ sim/cris/sim-if.c. One type of bug was fixed in commit
+ d16ce6e4d581 "sim: cris: fix memory setup typos" but one
+ remained; the PRIu32 usage is wrong, as hex output is
+ desired; note the 0x prefix.
+
+ Without this fix, you'll see output like:
+ memory map 0:0x4000..0x5fff (8192 bytes) overlaps 0:0x0..0x16383 (91012 bytes)
+ program stopped with signal 6 (Aborted).
+ for some C programs, like some of the ones in the sim/cris/c
+ testsuite from where the example is taken (freopen2.c).
+
+ The bug behavior was with memory allocation. With an
+ attempt to allocate memory using the brk syscall such that
+ the room up to the next 8192-byte "page boundary" wasn't
+ sufficient, the simulator memory allocation machinery horked
+ on a consistency error when trying to allocate a memory
+ block to raise the "end of the data segment": there was
+ already memory allocated at that address.
+
+ Unfortunately, none of the programs in sim/cris/asm exposed
+ this bug at the time, but an assembler test-case is
+ committed after this fix.
+
+ sim/cris:
+ * sim-if.c (sim_open): Correct PRIu32 to PRIx32.
+
+2022-02-14 Sergei Trofimovich <siarheit@google.com>
+
+ microblaze: fix fsqrt collicion to build on glibc-2.35
+ * microblaze-opcm.h: Renamed 'fsqrt' to 'microblaze_fsqrt'.
+ * microblaze-opc.h: Follow 'fsqrt' rename.
+
+2022-02-14 Tom Tromey <tom@tromey.com>
+
+ Remove LA_PRINT_STRING
+ This removes the LA_PRINT_STRING macro, in favor of using ordinary
+ method calls.
+
+ Remove LA_PRINT_CHAR
+ This removes the LA_PRINT_CHAR macro, in favor of using ordinary
+ method calls.
+
+ Remove LA_PRINT_TYPE
+ This removes the LA_PRINT_TYPE macro, in favor of using ordinary
+ method calls.
+
+2022-02-14 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: move styling support to gdb.styling
+ This commit moves the two Python functions that are used for styling
+ into a new module, gdb.styling, there's then a small update in
+ python.c so GDB can find the functions in their new location.
+
+ The motivation for this change is purely to try and reduce the clutter
+ in the top-level gdb module, and encapsulate related functions into
+ modules. I did ponder documenting these functions as part of the
+ Python API, however, doing so would effectively "fix" the API, and I'm
+ still wondering if there's improvements that could be made, also, the
+ colorize function is only called in some cases now that GDB prefers
+ libsource-highlight, so it's not entirely sure how this would work as
+ part of a user facing API.
+
+ Still, despite these functions never having been part of a documented
+ API, it is possible that a user out there has overridden these to, in
+ some way, customize how GDB performs styling. Moving the function as
+ I propose in this patch could break things for that user, however,
+ fixing this breakage is trivial, and, as these functions were never
+ documented, I don't think we should be obliged to not break user code
+ that relies on them.
+
+2022-02-14 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: use python to colorize disassembler output
+ This commit adds styling support to the disassembler output, as such
+ two new commands are added to GDB:
+
+ set style disassembler enabled on|off
+ show style disassembler enabled
+
+ In this commit I make use of the Python Pygments package to provide
+ the styling. I did investigate making use of libsource-highlight,
+ however, I found the highlighting results to be inferior to those of
+ Pygments; only some mnemonics were highlighted, and highlighting of
+ register names such as r9d and r8d (on x86-64) was incorrect.
+
+ To enable disassembler highlighting via Pygments, I've added a new
+ extension language hook, which is then implemented for Python. This
+ hook is very similar to the existing hook for source code
+ colorization.
+
+ One possibly odd choice I made with the new hook is to pass a
+ gdb.Architecture through, even though this is currently unused. The
+ reason this argument is not used is that, currently, styling is
+ performed identically for all architectures.
+
+ However, even though the Python function used to perform styling of
+ disassembly output is not part of any documented API, I don't want
+ to close the door on a user overriding this function to provide
+ architecture specific styling. To do this, the user would inevitably
+ require access to the gdb.Architecture, and so I decided to add this
+ field now.
+
+ The styling is applied within gdb_disassembler::print_insn, to achieve
+ this, gdb_disassembler now writes its output into a temporary buffer,
+ styling is then applied to the contents of this buffer. Finally the
+ gdb_disassembler buffer is copied out to its final destination stream.
+
+ There's a new test to check that the disassembler output includes some
+ escape sequences, though I don't check for specific colours; the
+ precise colors will depend on which instructions are in the
+ disassembler output, and, I guess, how pygments is configured.
+
+ The only negative change with this commit is how we currently style
+ addresses in GDB.
+
+ Currently, when the disassembler wants to print an address, we call
+ back into GDB, and GDB prints the address value using the `address`
+ styling, and the symbol name using `function` styling. After this
+ commit, if pygments is used, then all disassembler styling is done
+ through pygments, and this include the address and symbol name parts
+ of the disassembler output.
+
+ I don't know how much of an issue this will be for people. There's
+ already some precedent for this in GDB when we look at source styling.
+ For example, function names in styled source listings are not styled
+ using the `function` style, but instead, either GNU Source Highlight,
+ or pygments gets to decide how the function name should be styled.
+
+ If the Python pygments library is not present then GDB will continue
+ to behave as it always has, the disassembler output is mostly
+ unstyled, but the address and symbols are styled using the `address`
+ and `function` styles, as they are today.
+
+ However, if the user does `set style disassembler enabled off`, then
+ all disassembler styling is switched off. This obviously covers the
+ use of pygments, but also includes the minimal styling done by GDB
+ when pygments is not available.
+
+2022-02-14 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Keep indirect symbol from IR if referenced from shared object
+ Don't change indirect symbol defined in IR to undefined if it is
+ referenced from shared object.
+
+ bfd/
+
+ PR ld/28879
+ * elflink.c (_bfd_elf_merge_symbol): Don't change indirect
+ symbol defined in IR to undefined if it is referenced from
+ shared object.
+
+ ld/
+
+ PR ld/28879
+ * testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests.
+ * testsuite/ld-plugin/pr28879a.cc: New file.
+ * testsuite/ld-plugin/pr28879b.cc: Likewise.
+
+2022-02-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-13 Alan Modra <amodra@gmail.com>
+
+ PR28882, build failure with gcc-4.2 due to use of 0b literals
+ PR 28882
+ * elf/loongarch.h: Replace binary literals with hex.
+
+2022-02-13 Alan Modra <amodra@gmail.com>
+
+ Don't pass around expld.dataseg pointer
+ The better to see any code that accesses expld.dataseg.
+
+ * ldexp.c (fold_segment_end): Remove seg parameter. Adjust calls.
+ (fold_segment_align, fold_segment_relro_end): Likewise.
+ * ldlang.c (lang_size_segment): Likewise.
+ (lang_size_relro_segment_1, lang_find_relro_sections_1): Likewise.
+
+2022-02-13 Alan Modra <amodra@gmail.com>
+
+ Remove bfd ELF_RELROPAGESIZE
+ Now that ld properly aligns the end of the relro segment, the hack to
+ make relro work on powerpc can disappear.
+
+ bfd/
+ * bfd.c (bfd_emul_get_commonpagesize): Remove relro param.
+ Don't return bed->relropagesize.
+ * elf-bfd.h (struct elf_backend_data): Remove relropagesize.
+ * elfxx-target.h (ELF_RELROPAGESIZE): Remove.
+ * elf32-ppc.c (ELF_RELROPAGESIZE): Don't define.
+ * elf64-ppc.c: Likewise.
+ * bfd-in2.h: Regenerate.
+ ld/
+ * ldemul.c (after_parse_default): Adjust
+ bfd_emul_get_commonpagesize call.
+
+2022-02-13 Alan Modra <amodra@gmail.com>
+
+ PR28824, relro security issues, x86 keep COMMONPAGESIZE relro
+ x86 treats MAXPAGESIZE as a memory optimisation parameter, actual
+ hardware paging is always COMMPAGESIZE of 4k. Use COMMONPAGESIZE for
+ the end of the relro segment alignment.
+
+ The previous patch regresses pr18176, increasing the testcase file
+ size from 322208 to 2099872 bytes. Fixing this on x86 will require
+ introducing a gap after the end of the relro segment (of up to
+ relropagesize-1 bytes).
+
+ PR 28824
+ PR 18176
+ * ld.h (ld_config_type): Add relro_use_commonpagesize field.
+ * ldexp.c (fold_segment_align): Set relropagesize depending on
+ relro_use_commonpagesize.
+ * emultempl/elf-x86.em (elf_x86_create_output_section_statements):
+ Set relro_use_commonpagesize.
+ * testsuite/ld-x86-64/pr18176.d: xfail.
+
+2022-02-13 Alan Modra <amodra@gmail.com>
+
+ PR28824, relro security issues
+ Background
+ ==========
+ There are constraints on layout of binaries to meet demand paging and
+ memory protection requirements. Demand paged binaries must have file
+ offset mod pagesize equal to vma mod pagesize. Memory protection
+ (executable, read, write status) can only change at page boundaries.
+ The linker's MAXPAGESIZE variable gives the page size for these layout
+ constraints.
+
+ In a typical basic executable with two memory segments, text (RE) and
+ data (RW), the data segment must start on a different page to the
+ last text segment page. For example, with 64k pages and a small
+ executable of 48k text and 1k data, the text segment might start at
+ address 0x10000 and data at 0x20000 for a total of two 64k memory
+ pages. Demand paging would require the image on disk to be 64k+1k
+ in size. We can do better than that. If the data segment instead
+ starts at 0x2c000 (the end of the text segment plus one 64k page) then
+ there are still only two memory pages, but the disk image is now
+ smaller, 48k+1k in size. This is why the linker normally starts the
+ data segment at the end of the text segment plus one page. That
+ simple heuristic isn't ideal in all cases. Changing our simple
+ example to one with 64k-1 text size, following that heuristic would
+ result in data starting at 0x2ffff. Now we have two 64k memory data
+ pages for a data segment of 1k! If the data segment instead started
+ at 0x30000 we'd get a single data segment page at the cost of 1 byte
+ extra in the disk image, which is likely a good trade-off. So the
+ linker does adjust the simple heuristic. Just how much disk image
+ size increase is allowed is controlled by the linker's COMMONPAGESIZE
+ variable.
+
+ A PT_GNU_RELRO segment overlays the initial part of the data segment,
+ saying that those pages should be made read-only after relocation by
+ the dynamic loader. Page granularity for memory protection means that
+ the end of the relro segment must be at a page boundary.
+
+ The problem
+ ===========
+ Unfortunately most targets currently only align the end of the relro
+ segment to COMMONPAGESIZE. That results in only partial relro
+ protection if an executable is running with MAXPAGESIZE pages, since
+ any part of the relro segment past the last MAXPAGESIZE boundary can't
+ be made read-only without also affecting sections past the end of the
+ relro segment. I believe this problem arose because x86 always runs
+ with 4k (COMMPAGESIZE) memory pages, and therefore using a larger
+ MAXPAGESIZE on x86 is for reasons other than the demand paging and
+ memory page protection boundary requirements.
+
+ The solution
+ ============
+ Always end the relro segment on a MAXPAGESIZE boundary, except for
+ x86. Note that the relro segment, comprising of sections at the start
+ of the data segment, is sized according to how those sections are laid
+ out. That means the start of the relro segment is fixed relative to
+ its end. Which also means the start of the data segment must be at a
+ fixed address mod MAXPAGESIZE. So for relro the linker can't play
+ games with the start of the data segment to save disk space. At
+ least, not without introducing gaps between the relro sections. In
+ fact, because the linker was starting layout using its simple
+ heuristic of starting the data segment at the end of the text segment
+ plus one page, it was sometimes introducing page gaps for no reason.
+ See pr28743.
+
+ PR 28824
+ PR 28734
+ * ldexp.c (fold_segment_align): When relro, don't adjust up by
+ offset within page. Set relropagesize.
+ (fold_segment_relro_end): Align to relropagesize.
+ * ldexp.h (seg_align_type): Rename pagesize to commonpagesize.
+ Add relropagesize. Comment.
+ * ldlang.c (lang_size_segment): Adjust to suit field renaming.
+ (lang_size_relro_segment_1): Align relro_end using relropagesize.
+
+2022-02-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-11 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Disallow invalid relocation against protected symbol
+ I am checking this into master and will backport it to 2.38 branch.
+
+ H.J
+ ----
+ On x86, GCC 12 supports -mno-direct-extern-access to enable canonical
+ reference to protected function and disable copy relocation. With
+ -mno-direct-extern-access, the canonical protected function symbols must
+ be accessed via canonical reference and the protected data symbols in
+ shared libraries are non-copyable. Under glibc 2.35, non-canonical
+ reference to the canonical protected function will get the run-time error:
+
+ ./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function
+
+ and copy relocations against the non-copyable protected symbols will get
+ the run-time error:
+
+ ./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol
+
+ Update x86 linker to disallow non-canonical reference to the canonical
+ protected function:
+
+ ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so
+ ld: failed to set dynamic section sizes: bad value
+
+ and copy relocation against the non-copyable protected symbol:
+
+ ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so
+
+ at link-time.
+
+ bfd/
+
+ PR ld/28875
+ * elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip
+ shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+ * elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical
+ reference to canonical protected function.
+ * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+ * elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy
+ relocation against non-copyable protected symbol.
+
+ ld/
+
+ PR ld/28875
+ * testsuite/ld-i386/i386.exp: Check non-canonical reference to
+ canonical protected function and check copy relocation against
+ non-copyable protected symbol.
+ * testsuite/ld-i386/pr21997-1.err: New file.
+ * testsuite/ld-i386/pr28875.err: Likewise.
+ * testsuite/ld-i386/pr28875a.c: Likewise.
+ * testsuite/ld-i386/pr28875b.c: Likewise.
+ * testsuite/ld-x86-64/pr21997-1a.err: Updated.
+ * testsuite/ld-x86-64/pr21997-1b.err: Likewise.
+ * testsuite/ld-x86-64/pr28875-data.err: New file.
+ * testsuite/ld-x86-64/pr28875-func.err: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference
+ to canonical protected function and check copy relocation against
+ non-copyable protected symbol.
+
+2022-02-11 Tom Tromey <tromey@adacore.com>
+
+ Add initializers to bound_minimal_symbol
+ This adds initializers to bound_minimal_symbol, allowing for the
+ removal of some calls to memset.
+
+2022-02-11 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ gdb/fortran: support ptype and print commands for namelist variables
+ Gfortran supports namelists (a Fortran feature); it emits
+ DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not
+ process these dies and does not support 'print' or 'ptype' commands on
+ namelist variables.
+
+ An attempt to print namelist variables results in gdb bailing out with
+ the error message as shown below.
+
+ (gdb) print nml
+ No symbol "nml" in current context.
+
+ This commit is to make the print and ptype commands work for namelist
+ variables and its items. Sample output of these commands is shared
+ below, with fixed gdb.
+
+ (gdb) ptype nml
+ type = Type nml
+ integer(kind=4) :: a
+ integer(kind=4) :: b
+ End Type nml
+ (gdb) print nml
+ $1 = ( a = 10, b = 20 )
+
+2022-02-11 Bruno Larsen <blarsen@redhat.com>
+
+ gdb: fix until behavior with trailing !is_stmt lines
+ When using the command "until", it is expected that GDB will exit a
+ loop if the current instruction is the last one related to that loop.
+ However, if there were trailing non-statement instructions, "until"
+ would just behave as "next". This was noticeable in clang-compiled
+ code, but might happen with gcc-compiled as well. PR gdb/17315 relates
+ to this problem, as running gdb.base/watchpoint.exp with clang
+ would fail for this reason.
+
+ To better understand this issue, consider the following source code,
+ with line numbers marked on the left:
+
+ 10: for (i = 0; i < 10; ++i)
+ 11: loop_body ();
+ 12: other_stuff ();
+
+ If we transform this to pseudo-assembler, and generate a line table,
+ we could end up with something like this:
+
+ Address | Pseudo-Assembler | Line | Is-Statement?
+
+ 0x100 | i = 0 | 10 | Yes
+ 0x104 | loop_body () | 11 | Yes
+ 0x108 | i = i + 1 | 10 | Yes
+ 0x10c | if (i < 10): | 10 | No
+ 0x110 | goto 0x104 | 10 | No
+ 0x114 | other_stuff () | 12 | Yes
+
+ Notice the two non-statement instructions at the end of the loop.
+
+ The problem is that when we reach address 0x108 and use 'until',
+ hoping to leave the loop, GDB sets up a stepping range that runs from
+ the start of the function (0x100 in our example) to the end of the
+ current line table entry, that is 0x10c in our example. GDB then
+ starts stepping forward.
+
+ When 0x10c is reached GDB spots that we have left the stepping range,
+ that the new location is not a statement, and that the new location is
+ associated with the same source line number as the previous stepping
+ range. GDB then sets up a new stepping range that runs from 0x10c to
+ 0x114, and continues stepping forward.
+
+ Within that stepping range the inferior hits the goto (at 0x110) and
+ loops back to address 0x104.
+
+ At 0x104 GDB spots that we have left the previous stepping range, that
+ the new address is marked as a statement, and that the new address is
+ for a different source line. As a result, GDB stops and returns
+ control to the user. This is not what the user was expecting, they
+ expected GDB to exit the loop.
+
+ The fix proposed in this patch, is that, when the user issues the
+ 'until' command, and GDB sets up the initial stepping range, GDB will
+ check subsequent SALs (symtab_and_lines) to see if they are
+ non-statements associated with the same line number. If they are then
+ the end of the initial stepping range is extended to the end of the
+ non-statement SALs.
+
+ In our example above, the user is at 0x108 and uses 'until', GDB now
+ sets up a stepping range from the start of the function 0x100 to
+ 0x114, the first address associated with a different line.
+
+ Now as GDB steps around the loop it never leaves the initial stepping
+ range. It is only when GDB exits the loop that we leave the stepping
+ range, and the stepping finishes at address 0x114.
+
+ This patch also adds a test case that can be run with gcc to test that
+ this functionality is not broken in the future.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17315
+
+2022-02-11 Richard Sandiford <richard.sandiford@arm.com>
+
+ gas/doc: Fix "a true results" typo
+
+2022-02-11 Jan Vrany <jan.vrany@labware.com>
+
+ gdb: extend the information printed by 'maint info jit'
+ This commit updates the output of 'maint info jit' to print not just
+ the jit_code_entry address, but also the symfile address, and the
+ symfile size.
+
+ The new information could be obtained by looking into target memory at
+ the contents of the jit_code_entry, but, by storing this information
+ within gdb at the time the jit object is loaded, it is now possible to
+ check if the jit_code_entry has been modified in target memory behind
+ gdb's back.
+
+ Additionally, the symfile address is the same address that is now used
+ in the objfile names after commit 4a620b7e.
+
+ One test that relies on the output of 'maint info jit' was updated to
+ allow for the new output format.
+
+2022-02-11 Michael Forney <mforney@mforney.org>
+
+ bfd: Remove return with expression in void function
+ * bfd.c (bfd_set_gp_value): Remove return with expression
+ in void function.
+
+2022-02-11 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: LoongArch: Add Makefile, configure and NEWS
+ This commit adds Makefile, configure and NEWS for LoongArch.
+
+ gdb: LoongArch: Add initial native Linux support
+ This commit adds initial native Linux support for LoongArch.
+
+ gdb: LoongArch: Add initial Linux target support
+ This commit adds initial Linux target support for LoongArch.
+
+ gdb: LoongArch: Add initial baremetal support
+ This commit adds initial baremetal support for LoongArch.
+
+ gdb: LoongArch: Add initial target description support
+ This commit adds initial target description support for LoongArch.
+
+2022-02-11 Mike Frysinger <vapier@gentoo.org>
+
+ libctf: delete unused libctf_TEXINFOS
+ It's not clear what this was meant for, but it's not used by anything,
+ and the info pages still generate fine without it.
+
+2022-02-11 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, clone, sysgood
+ I think it's safe to remove checking support for these ptrace features,
+ they have all been added in what is now ancient times (around the
+ beginning of Linux 2.6). This allows removing a bit of complexity in
+ linux-nat.c and nat/linux-ptrace.c.
+
+ It also allows saving one extra fork every time we start debugging on
+ Linux: linux_check_ptrace_features forks a child process to test if some
+ ptrace features are supported. That child process forks a grand-child,
+ to test whether ptrace reports an event for the fork by the child. This
+ is no longer needed, if we assume the kernel supports reporting forks.
+
+ PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416
+
+ PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964
+
+ PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and
+ PTRACE_O_TRACECLONE were introduced in this change, in 2002:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46
+
+ Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d
+
+2022-02-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-10 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/infrun: some extra infrun debug print statements
+ While reviewing a different patch I wanted to know more about what was
+ going on during GDB's stepping. I added some extra infrun debug print
+ calls, and I thought these might be useful to others.
+
+2022-02-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-09 Nick Clifton <nickc@redhat.com>
+
+ Update the obsolete list and how-to-make-a-release documentation now that the 2.38 release is out.
+
+2022-02-09 Alan Modra <amodra@gmail.com>
+
+ PR28763, SIGSEGV during processing of program headers via readelf
+ PR 28763
+ * readelf.c (process_file_header): Discard any cached program
+ headers if there is an extension field for e_phnum in first
+ section header.
+
+2022-02-09 Alan Modra <amodra@gmail.com>
+
+ Work around gcc-4 warnings in elf64-ppc.c
+ elf64-ppc.c: In function 'ppc64_elf_size_dynamic_sections':
+ elf64-ppc.c:10309:45: error: value computed is not used [-Werror=unused-value]
+ ++lgot_ents, ++lgot_masks, isym != NULL && isym++)
+
+ It is of course a silly warning, fixed in later versions of gcc. I
+ wrote "isym != NULL && isym++" rather than the simpler "isym++" to
+ stop sanitisers complaining about incrementing a NULL pointer. isym
+ is of course unused in any code path where it might start off as
+ NULL. Sometimes you can't win. So don't try to be clever in reading
+ local symbols only when needed. 99 times out of 100 they will be
+ cached anyway.
+
+ * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Avoid annoying
+ warnings by always reading local syms.
+ (ppc64_elf_layout_multitoc): Likewise.
+
+2022-02-09 Peilin Ye <peilin.ye@bytedance.com>
+
+ Test --only-keep-debug on ELF relocatables
+ Add a test for commit 7c4643efe7be, which fixed --only-keep-debug for ELF
+ relocatables.
+
+ * testsuite/binutils-all/objcopy.exp
+ (keep_debug_symbols_for_elf_relocatable): New test.
+
+2022-02-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-08 Palmer Dabbelt <palmer@rivosinc.com>
+
+ RISC-V: Stop reporting warnings for mismatched extension versions
+ The extension version checking logic is really just too complicated to
+ encode into the linker, trying to do so causes more harm than good.
+ This removes the checks and the associated tests, leaving the logic to
+ keep the largest version of each extension linked into the target.
+
+ bfd/
+
+ * elfnn-riscv.c (riscv_version_mismatch): Rename to
+ riscv_update_subset_version, and stop reporting warnings on
+ version mismatches.
+ (riscv_merge_std_ext): Adjust calls to riscv_version_mismatch.
+ (riscv_merge_multi_letter_ext): Likewise.
+
+ ld/
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d: Remove
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02a.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02b.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02c.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02d.s: Likewise
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: New test.
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p0.s:
+ Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p1.s:
+ Likewise.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Remove obselete
+ attr-merge-arch-failed-{01,02}, replace with
+ attr-merge-user-ext-01.
+
+2022-02-08 Alan Modra <amodra@gmail.com>
+
+ PR28862, heap-buffer-overflow in parse_stab_string
+ I have no info on the format of a "SUNPRO C++ Namespace" stab, so am
+ relying on the previous code being correct in parsing these stabs.
+ Just don't allow NULs anywhere in the stab.
+
+ PR 28862
+ * stabs.c (parse_stab_string): Don't overrun buffer when parsing
+ 'Y' stab.
+
+2022-02-08 Alan Modra <amodra@gmail.com>
+
+ Re: elf: Check symbol version without any symbols
+ * testsuite/ld-elf/pr24718-1.d: Don't xfail for hppa64.
+
+2022-02-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: remove tailing newlines from index_cache_debug calls
+ I noticed that most of the calls to index_cache_debug include a
+ trailing newline. As the new debug mechanism already adds a newline,
+ that means all of these debug calls result in a blank line being
+ printed, which I think is a mistake.
+
+ Remove all the trailing newlines.
+
+ I also reformatted one of the index_cache_debug where a string will
+ now fit onto a single line.
+
+ Unless 'set debug index-cache on' is used, there should be no visible
+ change in output after this commit.
+
+2022-02-08 H.J. Lu <hjl.tools@gmail.com>
+
+ i386: Allow GOT32 relocations against ABS symbols
+ GOT32 relocations are allowed since absolute value + addend is stored in
+ the GOT slot.
+
+ Tested on glibc 2.35 build with GCC 11.2 and -Os.
+
+ bfd/
+
+ PR ld/28870
+ * elfxx-x86.c (_bfd_elf_x86_valid_reloc_p): Also allow GOT32
+ relocations.
+
+ ld/
+
+ PR ld/28870
+ * testsuite/ld-i386/i386.exp: Run pr28870.
+ * testsuite/ld-i386/pr28870.d: New file.
+ * testsuite/ld-i386/pr28870.s: Likewise.
+
+2022-02-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: allow Value.format_string to return styled output
+ Add a new argument to the gdb.Value.format_string method, 'styling'.
+ This argument is False by default.
+
+ When this argument is True, then the returned string can contain output
+ styling escape sequences.
+
+ When this argument is False, then the returned string will not contain
+ any styling escape sequences.
+
+ If the returned string is going to be printed to the user, then it is
+ often nice to retain the GDB styling.
+
+ For the testing, we need to adjust the TERM environment variable, as
+ we do for all the styling tests. I'm now running all of the C tests
+ in gdb.python/py-format-string.exp in an environment where styling
+ could be generated, but only my new test should actually produce
+ styled output, hopefully this will catch the case where a bug might
+ cause format_string to always produce styled output.
+
+2022-02-07 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: make thread_info::m_thread_fsm a std::unique_ptr
+ While working on function calls, I realized that the thread_fsm member
+ of struct thread_info is a raw pointer to a resource it owns. This
+ commit changes the type of the thread_fsm member to a std::unique_ptr in
+ order to signify this ownership relationship and slightly ease resource
+ management (no need to manually call delete).
+
+ To ensure consistent use, the field is made a private member
+ (m_thread_fsm). The setter method (set_thread_fsm) can then check
+ that it is incorrect to associate a FSM to a thread_info object if
+ another one is already in place. This is ensured by an assertion.
+
+ The function run_inferior_call takes an argument as a pointer to a
+ call_thread_fsm and installs it in it in a thread_info instance. Also
+ change this function's signature to accept a unique_ptr in order to
+ signify that the ownership of the call_thread_fsm is transferred during
+ the call.
+
+ No user visible change expected after this commit.
+
+ Tested on x86_64-linux with no regression observed.
+
+ Change-Id: Ia1224f72a4afa247801ce6650ce82f90224a9ae8
+
+2022-02-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: unbuffer all input streams when not using readline
+ This commit should fix PR gdb/28711. What's actually going on is
+ pretty involved, and there's still a bit of the story that I don't
+ understand completely, however, from my observed results, I think that
+ the change I propose making here (or something very similar) is going
+ to be needed.
+
+ The original bug report involves using eclipse to drive gdb using mi
+ commands. A separate tty is spun off in which to send gdb the mi
+ commands, this tty is created using the new-ui command.
+
+ The behaviour observed is that, given a particular set of mi commands
+ being sent to gdb, we sometimes see an ESPIPE error from a lseek
+ call, which ultimately results in gdb terminating.
+
+ The problems all originate from gdb_readline_no_editing_callback in
+ gdb/event-top.c, where we can (sometimes) perform calls to fgetc, and
+ allow glibc to perform buffering on the FILE object being used.
+
+ I say sometime, because, gdb_readline_no_editing_callback already
+ includes a call to disable the glibc buffering, but this is only done
+ if the input stream is not a tty. In our case the input stream is a
+ tty, so the buffering is left in place.
+
+ The first step to understanding why this problem occurs is to
+ understand that eclipse sends multiple commands to gdb very quickly
+ without waiting for and answer to each command, eclipse plans to
+ collect all of the command results after sending all the commands to
+ gdb. In fact, eclipse sends the commands to gdb that they appear to
+ arrive in the gdb process as a single block of data. When reproducing
+ this issue within the testsuite I find it necessary to send multiple
+ commands using a single write call.
+
+ The next bit of the story gets a little involved, and this is where my
+ understanding is not complete. I can describe the behaviour that I
+ observe, and (for me at least) I'm happy that what I'm seeing, if a
+ little strange, is consistent. In order to fully understand what's
+ going on I think I would likely need to dive into kernel code, which
+ currently seems unnecessary given that I'm happy with the solution I'm
+ proposing.
+
+ The following description all relates to input from a tty in which I'm
+ not using readline. I see the same problems either when using a
+ new-ui tty, or with gdb's standard, non-readline, mi tty.
+
+ Here's what I observe happening when I send multiple commands to gdb
+ using a single write, if I send gdb this:
+
+ command_1\ncommand_2\ncommand_3
+
+ then gdb's event loop will wake up (from its select) as it sees there
+ is input available. We call into gdb_readline_no_editing_callback,
+ where we call fgetc, glibc will do a single big read, and get back
+ just:
+
+ command_1\n
+
+ that is, despite there being multiple lines of input available, I
+ consistently get just a single line. From glibc a single character is
+ returned from the fgetc call, and within gdb we accumulate characters,
+ one at a time, into our own buffer. Eventually gdb sees the '\n'
+ character, and dispatches the whole 'command_1' into gdb's command
+ handler, which processes the command and prints the result. We then
+ return to gdb_readline_no_editing_callback, which in turn returns to
+ gdb's event loop where we re-enter the select.
+
+ Inside the select we immediately see that there is more input waiting
+ on the input stream, drop out of the select, and call back into
+ gdb_readline_no_editing_callback. In this function we again call
+ fgetc where glibc performs another big read. This time glibc gets:
+
+ command_2\n
+
+ that is, we once again get just a single line, despite there being a
+ third line available. Just like the first command we copy the whole
+ string, character by character into gdb's buffer, then handle the
+ command. After handling the command we go to the event loop, enter,
+ and then exit the select, and call back to the function
+ gdb_readline_no_editing_callback.
+
+ In gdb_readline_no_editing_callback we again call fgetc, this time
+ glibc gets the string:
+
+ command_3\n
+
+ like before, we copy this to gdb's buffer and handle the command, then
+ we return to the event loop. At this point the select blocks while we
+ wait for more input to arrive.
+
+ The important bit of this is that someone, somewhere is, it appears,
+ taking care to split the incoming write into lines.
+
+ My next experiment is to try something like:
+
+ this_is_a_very_long_command\nshort_command\n
+
+ However, I actually make 'this_is_a_very_long_command' very long, as
+ in many hundreds of characters long. One way to do this is:
+
+ echo xxxxxx.....xxxxx
+
+ and just adding more and more 'x' characters as needed. What I'm
+ aiming for is to have the first command be longer than glibc's
+ internal read buffer, which, on my machine, is 1024 characters.
+
+ However, for this discussion, lets imagine that glibc's buffer is just
+ 8 characters (we can create just this situation by adding a suitable
+ setbuf call into gdb_readline_no_editing_callback).
+
+ Now, if I send gdb this data:
+
+ abcdefghij\nkl\n
+
+ The first read from glibc will get 'abcdefgh', that is a full 8
+ character buffer. Once gdb has copied these to its buffer we call
+ fgetc again, and now glibc will get 'ij\n', that is, just like before,
+ multiple lines are split at the '\n' character. The full command,
+ which is now in gdb's buffer can be handled 'abcdefghij', after which
+ we go (via the event loop) back to gdb_readline_no_editing_callback.
+ Now we call fgetc, and glibc will get 'kl\n', which is then handled in
+ the normal way.
+
+ So far, so good. However, there is, apparently, one edge case where
+ the above rules don't apply.
+
+ If the '\n' character is the first character read from the kernel,
+ then the incoming lines are not split up. So, given glibc's 8
+ character buffer, if I send gdb this:
+
+ abcdefgh\nkl\n
+
+ that is the first command is 8 characters plus a newline, then, on the
+ first read (from within glibc) we get 'abcdefgh' in a single buffer.
+ As there's no newline gdb calls fgetc again, and glibc does another
+ large read, now we get:
+
+ \nkl\n
+
+ which doesn't follow the above pattern - the lines are not split into
+ separate buffers!
+
+ So, gdb reads the first character from glibc using fgetc, this is the
+ newline. Now gdb has a complete command, and so the command is
+ handled. We then return to the event loop and enter the select.
+
+ The problem is that, as far as the kernel is concerned, there is no
+ more input pending, it's all been read into glibc's buffer, and so the
+ select doesn't return. The second command is basically stuck in
+ glibc's buffer.
+
+ If I send another command to gdb, or even just send an empty
+ command (a lone newline) then the select returns, we call into
+ gdb_readline_no_editing_callback, and now gdb sees the second
+ command.
+
+ OK, so the above is interesting, but it doesn't explain the ESPIPE
+ error.
+
+ Well, that's a slightly different, but related issue. The ESPIPE
+ case will _only_ show up when using new-ui to create the separate tty
+ for mi commands, and is a consequence of this commit:
+
+ commit afe09f0b6311a4dd1a7e2dc6491550bb228734f8
+ Date: Thu Jul 18 17:20:04 2019 +0100
+
+ Fix for using named pipes on Windows
+
+ Prior to this commit, the new-ui command would open the tty three
+ times, once each for stdin, stderr, and stdout. After this commit we
+ open the tty just once and reuse the FILE object for all three roles.
+
+ Consider the problem case, where glibc has (unexpectedly) read the
+ second command into its internal buffer. When we handle the first
+ command we usually end up having to write something to the mi output
+ stream.
+
+ After the above commit the same FILE object represents both the input
+ and output streams, so, when gdb tries to write to the FILE object,
+ glibc spots that there is input pending within the input buffer, and
+ so assumes that we have read ahead of where we should be in the input
+ file. To correct for this glibc tries to do an lseek call to
+ reposition the file offset of the output stream prior to writing to
+ it. However, as the output stream is a tty, and seeking is not
+ supported on a tty, this lseek call fails, this results in the ESPIPE,
+ which ultimately causes gdb to terminate.
+
+ So, now we understand why the ESPIPE triggers (which was what caused
+ the gdb crash in the original bug report), and we also understand that
+ sometime gdb will not handle the second command in a timely
+ fashion (if the first command is just the wrong length). So, what to
+ do about all this?
+
+ We could revert the commit mentioned above (and implement its
+ functionality another way). This would certainly resolve the ESPIPE
+ issue, the buffered input would now only be on the input stream, the
+ output stream would have no buffered input, and so glibc would never
+ try to lseek, and so we'd never get the ESPIPE error.
+
+ However, this only solves one of the two problems. We would still
+ suffer from the problem where, if the first command is just the wrong
+ length, the second command will not (immediately) get handled.
+
+ The only solution I can see to this problem is to unbuffer the input
+ stream. If glibc is not buffering the input, but instead, we read
+ incoming data character by character from the kernel, then everything
+ will be fine. As soon as we see the newline at the end of the first
+ command we will handle the first command. As glibc will have no
+ buffered input it will not be tempted to lseek, so no ESPIPE error.
+ When we go have to the event loop there will be more data pending in
+ the kernel, so the select will immediately return, and the second
+ command will be processed.
+
+ I'm tempted to suggest that we should move the unbuffering of the
+ input stream out of gdb_readline_no_editing_callback and do it
+ somewhere earlier, more like when we create the input streams.
+ However, I've not done that in this commit for a couple of reasons:
+
+ 1. By keeping the unbuffering in gdb_readline_no_editing_callback
+ I'm making the smallest possible change that fixes the bug. Moving
+ the unbuffering somewhere better can be done as a refactor later, if
+ that 's felt to be important,
+
+ 2. I don't think making repeated calls to unbuffer the input will
+ have that much performance impact. We only make the unbuffer call
+ once per call to gdb_readline_no_editing_callback, and, if the input
+ stream is already unbuffered we'll return pretty quickly, so I don't
+ see this as being massively costly,
+
+ 3. Tom is currently doing lots of gdb stream management changes and
+ I want to minimise the chances we'll conflict.
+
+ So, this commit just changes gdb_readline_no_editing_callback to
+ always unbuffer the input stream.
+
+ The test for this issue sends two commands in a loop, with the first
+ command growing bigger each time around the loop. I actually make the
+ first command bigger by just adding whitespace to the front, as gdb
+ still has to read the complete command (including whitespace) via
+ glibc, so this is enough to trigger the bug.
+
+ The original bug was reported when using a virtual machine, and in
+ this situation we see this in the strace output:
+
+ read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) = 64
+ read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67
+
+ I'm not completely sure what's going on here, but it appears that the
+ kernel on the virtual machine is delivering the input to glibc slower
+ than I see on my real hardware; glibc asks for 1024 bytes, but only
+ gets 64 bytes the first time. In the second read we see the problem
+ case, the first character is the newline, but then the entire second
+ command is included.
+
+ If I run this exact example on my real hardware then the first command
+ would not be truncated at 64 bytes, instead, I'd expect to see the
+ newline included in the first read, with the second command split into
+ a second read.
+
+ So, for testing, I check cases where the first command is just a few
+ characters (starting at 8 character), all the way up to 2048
+ characters. Hopefully, this should mean we hit the problem case for
+ most machine setups.
+
+ The only last question relates to commit afe09f0b6311a4d that I
+ mentioned earlier. That commit was intended to provide support for
+ Microsoft named pipes:
+
+ https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes
+
+ I know next to nothing about this topic beyond a brief scan of the
+ above link, but I think these windows named pipe are closer in
+ behaviour to unix sockets than to unix named fifos.
+
+ I am a little nervous that, after the above commit, we now use the
+ same FILE for in, err, and out streams. In contrast, in a vanilla C
+ program, I would expect different FILE objects for each stream.
+
+ Still, I'm reluctant to revert the above commit (and provide the same
+ functionality a different way) without a specific bug to point at,
+ and, now that the streams are unbuffered, I expect a lot of the read
+ and write calls are going straight to the kernel with minimal glibc
+ involvement, so maybe it doesn't really matter. Anyway, I haven't
+ touched the above patch, but it is something to keep in mind when
+ working in this area.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28711
+
+2022-02-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/disasm: combine the no printing disassembler setup code
+ We have three places in gdb where we initialise a disassembler that
+ will not print anything (used for figuring out the length of
+ instructions, or collecting other information from the disassembler).
+
+ Each of these places has its own stub function to act as a print like
+ callback, the stub function is identical in each case, and just does
+ nothing.
+
+ In this commit I create a new function to initialise a disassembler
+ that doesn't print anything, and have all three locations use this new
+ function. There's now only one non-printing stub function.
+
+ There should be no user visible changes after this commit.
+
+2022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb: add the 'set/show suppress-cli-notifications' command
+ GDB already has a flag to suppress printing notification events, such
+ as thread and inferior context switches, on the CLI. This is used
+ internally when executing commands. Make the flag available to the
+ user via a new command. This is expected to be useful in scripts.
+
+ For instance, suppose that when Inferior 1 gets to a certain state,
+ you want to add and set up a new inferior using the commands below,
+ but you also want to have a reduced/clean output.
+
+ define do-setup
+ printf "Setting up Inferior 2...\n"
+ add-inferior -exec a.out
+ inferior 2
+ break file.c:3
+ run
+ inferior 1
+ printf "Done\n"
+ end
+
+ Currently, GDB prints
+
+ (gdb) do-setup
+ Setting up Inferior 2...
+ [New inferior 2]
+ Added inferior 2 on connection 1 (native)
+ [Switching to inferior 2 [<null>] (/tmp/a.out)]
+ Breakpoint 2 at 0x1155: file file.c, line 3.
+
+ Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
+ 3 return 0;
+ [Switching to inferior 1 [process 7670] (/tmp/test)]
+ [Switching to thread 1.1 (process 7670)]
+ #0 main () at test.c:2
+ 2 int a = 1;
+ Done
+
+ GDB's Python API make it possible to capture and return GDB's output,
+ but this does not work for all the streams. In particular, CLI
+ notification events are not captured:
+
+ (gdb) python gdb.execute("do-setup", False, True)
+ [Switching to inferior 2 [<null>] (/tmp/a.out)]
+
+ Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
+ 3 return 0;
+ [Switching to inferior 1 [process 8263] (/tmp/test)]
+ [Switching to thread 1.1 (process 8263)]
+ #0 main () at test.c:2
+ 2 int a = 1;
+
+ You can use the new "set suppress-cli-notifications" command to
+ suppress the output:
+
+ (gdb) set suppress-cli-notifications on
+ (gdb) do-setup
+ Setting up Inferior 2...
+ [New inferior 2]
+ Added inferior 2 on connection 1 (native)
+ Breakpoint 2 at 0x1155: file file.c, line 3.
+ Done
+
+2022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb/cli: add a 'normal_stop' option to 'cli_suppress_notification'
+ Extend the 'cli_suppress_notification' struct with a new field,
+ 'normal_stop', that can be used for checking if printing normal stop
+ events on the CLI should be suppressed.
+
+ This patch only introduces the flag. The subsequent patch adds a user
+ command to turn the flag off/on.
+
+2022-02-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb/cli: convert cli_suppress_notification from int to bool
+ Convert the suppress_notification flag for the CLI from int to bool.
+
+2022-02-07 Alan Modra <amodra@gmail.com>
+
+ Revert "elf: Remove the 1-page gap before the RELRO segment"
+ This reverts commit 2f83249c13d86065b4c7cdb198ea871017b4bba1.
+
+ PR ld/28743
+ * ldlang.c (lang_size_relro_segment_1): Revert 2022-01-10 changes.
+ * testsuite/ld-i386/pr20830.d: Likewise.
+ * testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise.
+ * testsuite/ld-x86-64/pr14207.d: Likewise.
+ * testsuite/ld-x86-64/pr18176.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-02-07 Alan Modra <amodra@gmail.com>
+
+ Revert "ld: Rewrite lang_size_relro_segment_1"
+ This reverts commit c804c6f98d342c3d46f73d7a7ec6229d5ab1c9f3.
+
+ PR ld/28743
+ PR ld/28819
+ * ldlang.c (lang_size_relro_segment_1): Revert 2022-01-14 change.
+ * testsuite/ld-x86-64/pr28743-1.d: Likewise.
+ * testsuite/ld-x86-64/pr28743-1.s: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Likewise.
+
+2022-02-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-06 Alan Modra <amodra@gmail.com>
+
+ A more elegant pr28827-1 testcase
+ Use .irpc macros in pr28827-1.s
+
+ * testsuite/ld-powerpc/pr28827-1.s: Make the testcase more
+ elegant. Comment.
+
+2022-02-06 Tom Tromey <tom@tromey.com>
+
+ Merge do_val_print and common_val_print
+ The only caller of do_val_print just does a small bit of work before
+ the call. This patch merges the two functions, and removes an
+ unnecessary local variable, making gdb a bit simpler.
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_LINE macro
+ Add a getter and a setter for a symbol's line. Remove the corresponding macro
+ and adjust all callers.
+
+ Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_TYPE macro
+ Add a getter and a setter for a symbol's type. Remove the corresponding
+ macro and adjust all callers.
+
+ Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remote SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION macro
+ Add a getter for a whether a symbol is a C++ template function. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: I89abc2802a952b77b0e0eb73a25c2306cb8e8bcc
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_INLINED macro
+ Add a getter and a setter for whether a symbol is inlined. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_IS_ARGUMENT macro
+ Add a getter and a setter for whether a symbol is an argument. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_OBJFILE_OWNED macro
+ Add a getter and a setter for whether a symbol is objfile owned. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_DOMAIN macro
+ Add a getter and a setter for a symbol's domain. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_CLASS macro, add getter
+ Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_IMPL macro, add method
+ Add a getter for a symbol's "impl". Remove the corresponding macro and
+ adjust all callers.
+
+ Change-Id: Ibe26ed442f0f99a0f5cddafca30bd96ec7fb9fa8
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setter
+ Add a getter and a setter for a symbol's aclass index. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMBOL_MATCHES_SEARCH_NAME
+ It seems like this macro is not needed at all anymore, it just wraps the
+ function of the same name with the same arguments.
+
+ Change-Id: I3c342ac8d89c27af5aee1a819dc32cc6396fd41b
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_DIRNAME macro
+ Remove the macro, replace with an equivalent method.
+
+ Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_PSPACE macro
+ Remove the macro, replace with an equivalent method.
+
+ Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_OBJFILE macro
+ Remove the macro, replace with an equivalent method.
+
+ Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_BLOCKVECTOR macro
+ Remove the macro, replace with an equivalent method.
+
+ Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_LANGUAGE macro, add getter/setter
+ Add a getter and a setter for a symtab's language. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_LINETABLE macro, add getter/setter
+ Add a getter and a setter for a symtab's linetable. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove SYMTAB_COMPUNIT macro, add getter/setter
+ Add a getter and a setter for a symtab's compunit_symtab. Remove the
+ corresponding macro and adjust all callers.
+
+ For brevity, I chose the name "compunit" instead of "compunit_symtab"
+ the the field, getter and setter names. Since we are already in symtab
+ context, the _symtab suffix seems redundant.
+
+ Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's macro table. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
+ Remove the corresponding macro and adjust all callers.
+
+ Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's locations valid flag.
+ Remove the corresponding macro and adjust all callers.
+
+ Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's block line section. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's blockvector. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_DIRNAME macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's dirname. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_PRODUCER macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's producer. Remove the
+ corresponding macro and adjust all callers.
+
+ Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setter
+ Add a getter and a setter for a compunit_symtab's debugformat. Remove
+ the corresponding macro and adjust all callers.
+
+ Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_FILETABS macro
+ I think that most remaining uses of COMPUNIT_FILETABS intend to get the
+ primary filetab of the compunit_symtab specifically (and not to iterate
+ over all filetabs, for example, those cases would use compunit_filetabs,
+ which has been converted to compunit_symtab::filetabs), so replace mosts
+ uses with compunit_symtab::primary_filetab.
+
+ In jit.c, function finalize_symtab, we can save the symtab object
+ returned by allocate_symtab and use it, it makes things simpler.
+
+ Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move compunit_filetabs to compunit_symtab::filetabs
+ Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
+ method of compunit_symtab. The name filetabs conflicts with the current
+ name of the field. Rename the field to m_filetabs, since at this point
+ nothing outside of compunit_symtab uses it, so we should treat it as
+ private (even though it's not actually private). Rename the
+ last_filetab field to m_last_filetab as well (it's only used on
+ compunit_symtab::add_filetab).
+
+ Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
+ returning the first filetab.
+
+ Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add compunit_symtab::set_primary_filetab method
+ Add a method to set the primary filetab of the CU. This is currently
+ done in buildsym_compunit::end_symtab_with_blockvector.
+
+ Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add compunit_symtab::add_filetab method
+ Add a method to append a filetab/symtab to a compunit_symtab. There is
+ a single place where this is done currently, in allocate_symtab.
+
+ Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetab
+ Make compunit_primary_filetab a method of compunit_symtab.
+
+ Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: remove COMPUNIT_OBJFILE macro
+ Remove the macro, update all users to use the getter directly.
+
+ Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6
+
+2022-02-06 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: add getter/setter for compunit_symtab::objfile
+ Rename the field to m_objfile, and add a getter and a setter. Update
+ all users.
+
+ Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317
+
+2022-02-06 Tom Tromey <tom@tromey.com>
+
+ Allow non-ASCII characters in Rust identifiers
+ Rust 1.53 (quite a while ago now) ungated the support for non-ASCII
+ identifiers. This didn't work in gdb. This is PR rust/20166.
+
+ This patch fixes the problem by allowing non-ASCII characters to be
+ considered as identifier components. It seemed simplest to just pass
+ them through -- doing any extra checking didn't seem worthwhile.
+
+ The new test also verifies that such characters are allowed in strings
+ and character literals as well. The latter also required a bit of
+ work in the lexer.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
+
+2022-02-06 Tom Tromey <tom@tromey.com>
+
+ Fix Rust parser bug with function fields
+ In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
+ function-valued field 'f' in 'obj'. The Rust parser in gdb currently
+ gets this wrong. This is PR rust/24082.
+
+ The expression and Rust parser rewrites made this simple to fix --
+ simply wrapping a parenthesized expression in a new operation handles
+ it. This patch has a slight hack because I didn't want to introduce a
+ new exp_opcode enumeration constant just for this. IMO this doesn't
+ matter, since we should work toward removing dependencies on these
+ opcodes anyway; but let me know what you think of this.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
+
+2022-02-06 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add emultempl/emulation.em
+ Add emultempl/emulation.em to define ld_${EMULATION_NAME}_emulation so
+ that new emulation hooks can be added easily.
+
+ * emultempl/aix.em (LDEMUL_AFTER_OPEN): New.
+ (LDEMUL_SET_OUTPUT_ARCH): Likewise.
+ (LDEMUL_CHOOSE_TARGET): Likewise.
+ (LDEMUL_BEFORE_ALLOCATION): Likewise.
+ (LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS): Likewise.
+ (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+ (LDEMUL_PARSE_ARGS): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_UNRECOGNIZED_FILE): Likewise.
+ (LDEMUL_PRINT_SYMBOL): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/beos.em (gld_${EMULATION_NAME}_before_parse):
+ Renamed to ...
+ (gld${EMULATION_NAME}_before_parse): This.
+ (gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+ (gld${EMULATION_NAME}_set_symbols): This.
+ (gld_${EMULATION_NAME}_after_open): Renamed to ...
+ (gld${EMULATION_NAME}_after_open): This.
+ (gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+ (gld${EMULATION_NAME}_before_allocation): This.
+ (gld_${EMULATION_NAME}_get_script): Renamed to ...
+ (gld${EMULATION_NAME}_get_script): This.
+ (LDEMUL_AFTER_OPEN): New.
+ (LDEMUL_BEFORE_ALLOCATION): Likewise.
+ (LDEMUL_PLACE_ORPHAN): Likewise.
+ (LDEMUL_SET_SYMBOLS): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/elf.em (LDEMUL_AFTER_PARSE): New.
+ (LDEMUL_AFTER_OPEN): Likewise.
+ (LDEMUL_BEFORE_PLACE_ORPHANS): Likewise.
+ (LDEMUL_AFTER_ALLOCATION): Likewise.
+ (LDEMUL_SET_OUTPUT_ARCH): Likewise.
+ (LDEMUL_BEFORE_ALLOCATION): Likewise.
+ (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+ (LDEMUL_PLACE_ORPHAN): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_LIST_OPTIONS): Likewise.
+ (LDEMUL_UNRECOGNIZED_FILE): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/emulation.em: New file.
+ * emultempl/generic.em (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/msp430.em (LDEMUL_AFTER_OPEN): New.
+ (LDEMUL_AFTER_ALLOCATION): Likewise.
+ (LDEMUL_PLACE_ORPHAN): Likewise.
+ (LDEMUL_FINISH): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_LIST_OPTIONS): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/pe.em (gld_${EMULATION_NAME}_before_parse): Renamed
+ to ...
+ (gld${EMULATION_NAME}_before_parse): This.
+ (gld_${EMULATION_NAME}_list_options): Renamed to ...
+ (gld${EMULATION_NAME}_list_options): This.
+ (gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+ (gld${EMULATION_NAME}_set_symbols): This.
+ (gld_${EMULATION_NAME}_after_parse): Renamed to ...
+ (gld${EMULATION_NAME}_after_parse): This.
+ (gld_${EMULATION_NAME}_after_open): Renamed to ...
+ (gld${EMULATION_NAME}_after_open): This.
+ (gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+ (gld${EMULATION_NAME}_before_allocation): This.
+ (gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
+ (gld${EMULATION_NAME}_unrecognized_file): This.
+ (gld_${EMULATION_NAME}_recognized_file): Renamed to ...
+ (gld${EMULATION_NAME}_recognized_file): This.
+ (gld_${EMULATION_NAME}_finish): Renamed to ...
+ (gld${EMULATION_NAME}_finish): This.
+ (gld_${EMULATION_NAME}_place_orphan): Renamed to ...
+ (gld${EMULATION_NAME}_place_orphan): This.
+ (gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
+ (gld${EMULATION_NAME}_open_dynamic_archive): This.
+ (gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
+ (gld${EMULATION_NAME}_find_potential_libraries): This.
+ (gld_${EMULATION_NAME}_get_script): Renamed to ...
+ (gld${EMULATION_NAME}_get_script): This.
+ (LDEMUL_AFTER_PARSE): New.
+ (LDEMUL_AFTER_OPEN): Likewise.
+ (LDEMUL_BEFORE_ALLOCATION): Likewise.
+ (LDEMUL_FINISH=): Likewise.
+ (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+ (LDEMUL_PLACE_ORPHAN): Likewise.
+ (LDEMUL_SET_SYMBOLS): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_UNRECOGNIZED_FILE): Likewise.
+ (LDEMUL_LIST_OPTIONS): Likewise.
+ (LDEMUL_RECOGNIZED_FILE): Likewise.
+ (LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/pep.em (gld_${EMULATION_NAME}_before_parse): Renamed
+ to ...
+ (gld${EMULATION_NAME}_before_parse): This.
+ (gld_${EMULATION_NAME}_list_options): Renamed to ...
+ (gld${EMULATION_NAME}_list_options): This.
+ (gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+ (gld${EMULATION_NAME}_set_symbols): This.
+ (gld_${EMULATION_NAME}_after_parse): Renamed to ...
+ (gld${EMULATION_NAME}_after_parse): This.
+ (gld_${EMULATION_NAME}_after_open): Renamed to ...
+ (gld${EMULATION_NAME}_after_open): This.
+ (gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+ (gld${EMULATION_NAME}_before_allocation): This.
+ (gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
+ (gld${EMULATION_NAME}_unrecognized_file): This.
+ (gld_${EMULATION_NAME}_recognized_file): Renamed to ...
+ (gld${EMULATION_NAME}_recognized_file): This.
+ (gld_${EMULATION_NAME}_finish): Renamed to ...
+ (gld${EMULATION_NAME}_finish): This.
+ (gld_${EMULATION_NAME}_place_orphan): Renamed to ...
+ (gld${EMULATION_NAME}_place_orphan): This.
+ (gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
+ (gld${EMULATION_NAME}_open_dynamic_archive): This.
+ (gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
+ (gld${EMULATION_NAME}_find_potential_libraries): This.
+ (gld_${EMULATION_NAME}_get_script): Renamed to ...
+ (gld${EMULATION_NAME}_get_script): This.
+ (LDEMUL_AFTER_PARSE): New.
+ (LDEMUL_AFTER_OPEN): Likewise.
+ (LDEMUL_BEFORE_ALLOCATION): Likewise.
+ (LDEMUL_FINISH=): Likewise.
+ (LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+ (LDEMUL_PLACE_ORPHAN): Likewise.
+ (LDEMUL_SET_SYMBOLS): Likewise.
+ (LDEMUL_ADD_OPTIONS): Likewise.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_UNRECOGNIZED_FILE): Likewise.
+ (LDEMUL_LIST_OPTIONS): Likewise.
+ (LDEMUL_RECOGNIZED_FILE): Likewise.
+ (LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/ticoff.em (gld_${EMULATION_NAME}_list_options):
+ Renamed to ...
+ (gld${EMULATION_NAME}_list_options): This.
+ (gld_${EMULATION_NAME}_before_parse): Renamed to ...
+ (gld_${EMULATION_NAME}_get_script): Renamed to ...
+ (gld${EMULATION_NAME}_get_script): This.
+ (LDEMUL_ADD_OPTIONS): New.
+ (LDEMUL_HANDLE_OPTION): Likewise.
+ (LDEMUL_LIST_OPTIONS): Likewise.
+ (ld_${EMULATION_NAME}_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+ * emultempl/vanilla.em (LDEMUL_BEFORE_PARSE): New.
+ (LDEMUL_SET_OUTPUT_ARCH): Likewise.
+ (LDEMUL_GET_SCRIPT): Likewise.
+ (EMULATION_NAME): Likewise.
+ (OUTPUT_FORMAT): Likewise.
+ (ld_vanilla_emulation): Removed.
+ Source ${srcdir}/emultempl/emulation.em.
+
+2022-02-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: update docs for 'info win' and 'winheight' commands
+ This started by noticing that the docs for 'winheight' are out of
+ date, the docs currently give a specific list of possible window
+ names. However, now that windows can be implemented in Python, it is
+ not possible to list all possible names.
+
+ I now link the user to a mechanism by which they can discover the
+ valid names for themselves at run time (by using 'info win'). That,
+ and the fact that gdb provides tab-completion of the name at the
+ command line, feels good enough.
+
+ Finally, I noticed that the docs for 'win info' don't explicitly say
+ that the name of the window is given in the output. This could
+ probably have been inferred, but given I'm now linking to this as a
+ mechanism to find the window name, I'd prefer to mention that the name
+ can be found in the output.
+
+2022-02-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/tui: add window width information to 'info win' output
+ Now that we support horizontal window placement in the tui, it makes
+ sense to have 'info win' include the width, as well as the height, of
+ the currently visible windows.
+
+ That's what this commit does. Example output is now:
+
+ (gdb) info win
+ Name Lines Columns Focus
+ src 12 40 (has focus)
+ asm 12 41
+ status 1 80
+ cmd 11 80
+
+ I've added a NEWS entry, but the documentation was already suitably
+ vague, it just says that 'info win' displays the size of the visible
+ windows, so I don't think anything needs to be added there.
+
+ I've also added some tests, as far as I could find, the 'info win'
+ command was previously untested.
+
+2022-02-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-05 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Skip undefined symbol when finishing DT_RELR
+ Don't abort for undefined symbol when finishing DT_RELR. Instead, skip
+ undefined symbol. Undefined symbol will be reported by relocate_section.
+
+ * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Skip
+ undefined symbol in finishing phase.
+
+2022-02-05 Alan Modra <amodra@gmail.com>
+
+ Tweak assembler invocation for pr28827-1 test
+ PR 28827
+ * testsuite/ld-powerpc/pr28827-1.d: Pass -a64 to gas.
+
+2022-02-05 Alan Modra <amodra@gmail.com>
+
+ PR28827 testcase
+ This testcase triggers a stub sizing error with the patches applied
+ for PR28743 (commit 2f83249c13d8 and c804c6f98d34).
+
+ PR 28827
+ * testsuite/ld-powerpc/pr28827-1.s,
+ * testsuite/ld-powerpc/pr28827-1.d: New test.
+ * testsuite/ld-powerpc/powerpc.exp: Run it.
+
+2022-02-05 Alan Modra <amodra@gmail.com>
+
+ Enable "size" as a dumpprog in ld
+ binutils/
+ * testsuite/lib/binutils-common.exp (run_dump_test): Reference
+ global SIZE and SIZEFLAGS.
+ ld/
+ * testsuite/config/default.exp: Define SIZE and SIZEFLAGS.
+
+2022-02-05 Alan Modra <amodra@gmail.com>
+
+ Detect .eh_frame_hdr earlier for SIZEOF_HEADERS
+ Current code detects the need for PT_GNU_EH_FRAME using a field set by
+ _bfd_elf_discard_section_eh_frame_hdr, which is called fairly late in
+ the linking process. Use the elf hash table eh_info instead, which is
+ set up earlier by size_dynamic_sections.
+
+ * elf-bfd.h (struct output_elf_obj_tdata): Delete eh_frame_hdr.
+ (elf_eh_frame_hdr): Don't define.
+ (_bfd_elf_discard_section_eh_frame_hdr): Update prototype.
+ * elf-eh-frame.c (_bfd_elf_discard_section_eh_frame_hdr): Delete
+ abfd parameter. Don't set elf_eh_frame_hdr.
+ * elf.c (elf_eh_frame_hdr): New function.
+ (get_program_header_size): Adjust elf_eh_frame_hdr call.
+ (_bfd_elf_map_sections_to_segments): Likewise.
+
+2022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim: mips: Add simulator support for mips32r6/mips64r6
+ 2022-02-01 Ali Lown <ali.lown@imgtec.com>
+ Andrew Bennett <andrew.bennett@imgtec.com>
+ Dragan Mladjenovic <dragan.mladjenovic@rt-rk.com>
+ Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim/common/ChangeLog:
+ * sim-bits.h (EXTEND9, EXTEND18 ,EXTEND19, EXTEND21,
+ EXTEND26): New macros.
+
+ sim/mips/ChangeLog:
+ * Makefile.in (IGEN_INCLUDE): Add mips3264r6.igen.
+ * configure: Regenerate.
+ * configure.ac: Support mipsisa32r6 and mipsisa64r6.
+ (sim_engine_run): Pick simulator model from processor specified
+ in e_flags.
+ * cp1.c (value_fpr): Handle fmt_dc32.
+ (fp_unary, fp_binary): Zero initialize locals.
+ (update_fcsr, fp_classify, fp_rint, fp_r6_cmp, inner_fmac,
+ fp_fmac, fp_min, fp_max, fp_mina, fp_maxa, fp_fmadd, fp_fmsub):
+ New functions.
+ (sim_fpu_class_mips_mapping): New.
+ * cp1.h (fcsr_ABS2008_mask, fcsr_ABS2008_shift): New define.
+ * interp.c (MIPSR6_P): New.
+ (load_word): Allow unaligned memory access for MIPSR6.
+ * micromips.igen (sc, scd): Adapt to new do_sc* helper signature.
+ * mips.igen: Add *r6 models.
+ (signal_if_cti, forbiddenslot32): New helpers.
+ (delayslot32): Use signal_if_cti.
+ (do_sc, do_scd); Add store_ll_bit parameter.
+ (sc, scd): Adapt to previous change.
+ (nal, beq, bal): New definitions for *r6.
+ (sll): Split nop and ssnop cases into ...
+ (nop, ssnop): New definitions.
+ (loadstore_ea): Use the 32-bit compatibility adressing.
+ (cache): Split logic into ...
+ (do_cache): New helper.
+ (check_fpu): Select IEEE 754-2008 mode for R6.
+ (not_word_value, unpredictable, check_mt_hilo, check_mf_hilo,
+ check_multi_hilo, check_div_hilo, check_u64, do_dmfc1b, add,
+ li, addu, and, andi, bgez, bgtz, blez, bltz, bne, break, dadd,
+ daddiu, daddu, dror, dror32, drorv, dsll, dsll32, dsllv, dsra,
+ dsra32, dsrav, dsrl, dsrl32, dsub, dsubu, j, jal, jalr,
+ jalr.hb, lb, lbu, ld, lh, lhu, lui, lw, lwu, nor, or, ori, ror,
+ rorv, sb, sd, sh, sll, sllv, slt, slti, sltiu, sltu, sra, srav,
+ srl, srlv, sub, subu, sw, sync, syscall, teq, tge, tgeu, tlt,
+ tltu, tne, xor, xori, check_fmt_p, do_load_double,
+ do_store_double, abs.FMT, add.FMT, ceil.l.FMT, ceil.w.FMT,
+ cfc1, ctc1, cvt.d.FMT, cvt.l.FMT, cvt.w.FMT, div.FMT, dfmc1,
+ dmtc1, floor.l.FMT, floor.w.FMT, ldc1, lwc1, mfc1, mov.FMT,
+ mtc1, mul.FMT, recip.FMT, round.l.FMT, round.w.FMT, rsqrt.FMT,
+ sdc1, sqrt.FMT, sub.FMT, swc1, trunc.l.FMT, trunc.w.FMT, bc0f,
+ bc0fl, bc0t, bc0tl, dmfc0, dmtc0, eret, mfc0, mtc0, cop, tlbp,
+ tlbr, tlbwi, tlbwr): Enable on *r6 models.
+ * mips3264r2.igen (dext, dextm, dextu, di, dins, dinsm, dinsu,
+ dsbh, dshd, ei, ext, mfhc1, mthc1, ins, seb, seh, synci, rdhwr,
+ wsbh): Likewise.
+ * mips3264r6.igen: New file.
+ * sim-main.h (FP_formats): Add fmt_dc32.
+ (FORBIDDEN_SLOT): New macros.
+ (simFORBIDDENSLOT, FP_R6CMP_*, FP_R6CLASS_*): New defines.
+ (fp_r6_cmp, fp_classify, fp_rint, fp_min, fp_max, fp_mina,
+ fp_maxa, fp_fmadd, fp_fmsub): New declarations.
+ (R6Compare, Classify, RoundToIntegralExact, Min, Max, MinA,
+ MaxA, FusedMultiplyAdd, FusedMultiplySub): New macros. Wrapping
+ previous declarations.
+
+ sim/testsuite/mips/ChangeLog:
+ * basic.exp: Add r6-*.s tests.
+ (run_r6_removed_test): New function.
+ (run_endian_tests): New function.
+ * hilo-hazard-3.s: Skip for mips*r6.
+ * r2-fpu.s: New test.
+ * r6-64.s: New test.
+ * r6-branch.s: New test.
+ * r6-forbidden.s: New test.
+ * r6-fpu.s: New test.
+ * r6-llsc-dp.s: New test.
+ * r6-llsc-wp.s: New test.
+ * r6-removed.csv: New test.
+ * r6-removed.s: New test.
+ * r6.s: New test.
+ * utils-r6.inc: New inc.
+
+2022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim: Add partial support for IEEE 754-2008
+ 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim/common/ChangeLog:
+ * sim-fpu.c (sim_fpu_minmax_nan): New.
+ (sim_fpu_max): Add variant behaviour for IEEE 754-2008.
+ (sim_fpu_min): Likewise.
+ (sim_fpu_is_un, sim_fpu_is_or): New.
+ (sim_fpu_un, sim_fpu_or): New.
+ (sim_fpu_is_ieee754_2008, sim_fpu_is_ieee754_1985): New.
+ (sim_fpu_set_mode): New.
+ (sim_fpu_classify): New.
+ * sim-fpu.h (sim_fpu_minmax_nan): New declaration.
+ (sim_fpu_un, sim_fpu_or): New declarations.
+ (sim_fpu_is_un, sim_fpu_is_or): New declarations.
+ (sim_fpu_mode): New enum.
+ [sim_fpu_state](current_mode): New field.
+ (sim_fpu_current_mode): New define.
+ (sim_fpu_is_ieee754_2008): New declaration.
+ (sim_fpu_is_ieee754_1985): New declaration.
+ (sim_fpu_set_mode): New declaration.
+ (sim_fpu_classify): New declaration.
+
+2022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim: Factor out NaN handling in floating point operations
+ 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim/common/ChangeLog:
+ * sim-fpu.c (sim_fpu_op_nan): New.
+ (sim_fpu_add): Factor out NaN operand handling with
+ a call to sim_fpu_op_nan.
+ (sim_fpu_sub, sim_fpu_mul, sim_fpu_div): Likewise.
+ (sim_fpu_rem, sim_fpu_max, sim_fpu_min): Likewise.
+ * sim-fpu.h (sim_fpu_op_nan): New declaration.
+
+2022-02-05 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim: Allow toggling of quiet NaN-bit semantics
+ IEEE754-1985 specifies the top bit of the mantissa as an indicator
+ of signalling vs. quiet NaN, but does not define the precise semantics.
+ Most architectures treat this bit as indicating quiet NaN, but legacy
+ (pre-R6) MIPS goes the other way and treats it as signalling NaN.
+
+ This used to be controlled by a macro that was only defined for MIPS.
+ This patch replaces the macro with a variable to track the current
+ semantics of the NaN bit and allows differentiation between older
+ (pre-R6) and and newer MIPS cores.
+
+ 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com>
+
+ sim/common/ChangeLog:
+ * sim-fpu.c (_sim_fpu): New.
+ (pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics.
+ * sim-fpu.h (sim_fpu_state): New struct.
+ (_sim_fpu): New extern.
+ (sim_fpu_quiet_nan_inverted): New define.
+
+ sim/mips/ChangeLog:
+ * cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New.
+ * mips.igen (check_fpu): Select default quiet NaN mode
+ for legacy MIPS.
+ * sim-main.h (SIM_QUIET_NAN_NEGATED): Remove.
+
+2022-02-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-04 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Remove emultempl/armcoff.em
+ Remove emultempl/armcoff.em which has been unused after
+
+ commit 2ac93be706418f3b2aebeb22159a328023faed52
+ Author: Alan Modra <amodra@gmail.com>
+ Date: Mon Apr 16 20:33:36 2018 +0930
+
+ Remove arm-aout and arm-coff support
+
+ This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and
+ arm-riscix. Those targets weren't on the obsolete list but they are
+ all aout, and it doesn't make all that much sense to remove arm-aout
+ without removing them too.
+
+ * emultempl/armcoff.em: Removed.
+
+2022-02-04 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: include jit_code_entry::symfile_addr value in names of objfiles created by jit reader API
+ This commit includes the JIT object's symfile address in the names of
+ objfiles created by JIT reader API (e.g., << JIT compiled code at
+ 0x7ffd8a0c77a0 >>). This allows one to at least differentiate one from
+ another.
+
+ The address is the one that the debugged program has put in
+ jit_code_entry::symfile_addr, and that the JIT reader's read function
+ receives. As we can see in gdb.base/jit-reader-host.c and
+ gdb.base/jit-reader.c, that may not be the actual value of where the
+ JIT-ed code is. But it is a value chosen by the author of the JIT
+ engine and the JIT reader, so including this value in the objfile name
+ may help them correlate the JIT objfiles created by with their logs /
+ data structures.
+
+ To access this field, we need to pass down a reference to the
+ jit_code_entry. So make jit_dbg_reader_data a structure (instead of an
+ alias for a CORE_ADDR) that includes the address of the code entry in
+ the inferior's address space (the previous meaning of
+ jit_dbg_reader_data) plus a reference to the jit_code_entry as read into
+ GDB's address space. And while at it, pass down the gdbarch, so that we
+ don't have to call target_gdbarch.
+
+ Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
+ Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5
+
+2022-02-04 Tom Tromey <tromey@adacore.com>
+
+ Improve Ada unchecked union type printing
+ Currently, "ptype" of an Ada unchecked union may show a
+ compiler-generated wrapper structure in its output. It's more
+ Ada-like to elide this structure, which is what this patch implements.
+ It turned out to be simplest to reuse a part of print_variant_clauses
+ for this.
+
+ As this is Ada-specific, and Joel already reviewed it internally, I am
+ going to check it in.
+
+2022-02-04 Tom Tromey <tromey@adacore.com>
+
+ Remove host_hex_value
+ I noticed that host_hex_value is redundant, because gdbsupport already
+ has fromhex. This patch removes the former in favor of the latter.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-02-04 Andi Kleen <andi@firstfloor.org>
+
+ Support symbol+offset lookup in addr2line
+ The Linux kernel usually ouputs symbol+offset instead of plain code
+ addresses these days, to avoid leaking ASLR secrets and to handle
+ dynamically loaded modules.
+
+ Converting those with addr2line is somewhat involved: it requires
+ looking up the symbol first using nm and then manually compute the
+ offset, and then pass it to addr2line.
+
+ This patch implements the necessary steps directly in addr2line,
+ by looking up the symbol (with demangling if needed) and computing
+ the offset.
+
+ It's possible that a symbol is ambigious with a hex number. In this
+ case it uses the symbol lookup if the string contains a +. When it isn't
+ ambigious the + is optional.
+
+2022-02-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-03 Cary Coutant <ccoutant@gmail.com>
+
+ Rename EM_56800V4 to EM_56800EF.
+ include/elf:
+ * common.h: Rename EM_56800V4 to EM_56800EF.
+
+2022-02-03 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Update X86_64_GOT_TYPE_P to cover more GOT relocations
+ Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and
+ R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations.
+
+ PR ld/28858
+ * elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32,
+ R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64.
+
+2022-02-03 Cary Coutant <ccoutant@gmail.com>
+
+ Add new e_machine values.
+ include/elf:
+ * common.h: Add EM_U16_U8CORE, EM_TACHYUM, EM_56800V4.
+
+2022-02-03 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ testsuite: fix failure in gdb.threads/killed-outside.exp
+ Starting with commit
+
+ commit 1da5d0e664e362857153af8682321a89ebafb7f6
+ Date: Tue Jan 4 08:02:24 2022 -0700
+
+ Change how Python architecture and language are handled
+
+ we see a failure in gdb.threads/killed-outside.exp:
+
+ ...
+ Executing on target: kill -9 16622 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 16622
+ continue
+ Continuing.
+ Couldn't get registers: No such process.
+ (gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited]
+
+ Program terminated with signal SIGKILL, Killed.
+ The program no longer exists.
+ FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
+
+ This is not a regression but a failure due to a change in GDB's
+ output. Prior to the aforementioned commit, GDB has been printing the
+ "Couldn't get registers: No such process." message twice. The second
+ one came from
+
+ (top-gdb) bt
+ #0 amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225
+ #1 0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502
+ #2 0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945
+ #3 0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587
+ #4 0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601
+ #5 0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690
+ #6 0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748
+ #7 0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53
+ #8 0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235
+ #9 0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580,
+ realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143
+ #10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199
+ #11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972
+ #12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007
+ #13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948
+ #14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572
+ #15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602
+ #16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665
+ #17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890
+ #18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720
+ #19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810
+ #20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848
+ #21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ")
+ at /gdb-up/gdb/python/python.c:1063
+ #22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922
+ #23 0x0000555555f7d442 in std::_Function_handler<void (char const*), void (*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&) (__functor=...,
+ __args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316
+ #24 0x0000555555f752dd in std::function<void (char const*)>::operator()(char const*) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
+ at /usr/include/c++/7/bits/std_function.h:706
+ #25 0x0000555555f75100 in gdb::observers::observable<char const*>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
+ at /gdb-up/gdb/../gdbsupport/observable.h:150
+ #26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444
+ #27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411
+ #28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205
+ #29 0x0000555555c2173f in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316
+ #30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706
+ #31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150
+ #32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438
+ #33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481
+ #34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348
+ #35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363
+ #36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32
+
+ Commit 1da5d0e664 eliminated the call to 'get_current_arch'
+ in 'gdbpy_before_prompt_hook'. Hence, the second instance of
+ "Couldn't get registers: No such process." does not appear anymore.
+
+ Fix the failure by updating the regular expression in the test.
+
+2022-02-03 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 treatment of absolute symbols
+ Supporting -static-pie on PowerPC64 requires the linker to properly
+ treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used
+ absolute symbol. I've been slow to fix the linker on powerpc because
+ there is some chance that this will break some shared libraries or
+ PIEs.
+
+ bfd/
+ * elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym
+ handling code. Don't count dyn relocs against non-dynamic
+ absolute symbols.
+ (dec_dynrel_count): Adjust to suit.
+ (ppc64_elf_edit_toc): Don't remove entries for absolute symbols
+ when pic.
+ (allocate_got): Don't allocate space for got relocs against
+ non-dynamic absolute syms.
+ (ppc64_elf_layout_multitoc): Likewise.
+ (got_and_plt_relr): Likewise.
+ (ppc64_elf_size_dynamic_sections): Likewise for local got.
+ (got_and_plt_relr_for_local_syms): Likewise.
+ (ppc64_elf_size_stubs): Don't allocate space for relr either.
+ (ppc64_elf_relocate_section): Don't write relocs against non-dynamic
+ absolute symbols. Don't optimise got and toc code sequences
+ loading absolute symbol entries.
+ ld/
+ * testsuite/ld-powerpc/abs-reloc.s,
+ * testsuite/ld-powerpc/abs-static.d,
+ * testsuite/ld-powerpc/abs-static.r,
+ * testsuite/ld-powerpc/abs-pie.d,
+ * testsuite/ld-powerpc/abs-pie.r,
+ * testsuite/ld-powerpc/abs-shared.d,
+ * testsuite/ld-powerpc/abs-shared.r,
+ * testsuite/ld-powerpc/abs-pie-relr.d,
+ * testsuite/ld-powerpc/abs-pie-relr.r,
+ * testsuite/ld-powerpc/abs-shared-relr.d,
+ * testsuite/ld-powerpc/abs-shared-relr.r: New tests.
+ * testsuite/ld-powerpc/powerpc.exp: Run them.
+
+2022-02-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-02 Nick Clifton <nickc@redhat.com>
+
+ Stop the BFD library complaining about compressed dwarf debug string sections being too big.
+ PR 28834
+ * dwarf2.c (read_section): Change the heuristic that checks for
+ overlarge dwarf debug info sections.
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix formatting for help set/show extended-prompt
+ The formatting of the help text for 'help set extended-prompt' and
+ 'help show extended-prompt' is a little off.
+
+ Here's the offending snippet:
+
+ Substitutions are applied to VALUE to compute the real prompt.
+
+ The currently defined substitutions are:
+ \[ Begins a sequence of non-printing characters.
+ \\ A backslash.
+ \] Ends a sequence of non-printing characters.
+ \e The ESC character.
+
+ Notice that the line for '\[' is indented more that the others.
+
+ Turns out this is due to how we build this help text, something which
+ is done in Python. We extended a classes __doc__ string with some
+ dynamically generated text.
+
+ The classes doc string looks like this:
+
+ """Set the extended prompt.
+
+ Usage: set extended-prompt VALUE
+
+ Substitutions are applied to VALUE to compute the real prompt.
+
+ The currently defined substitutions are:
+ """
+
+ Notice the closing """ are in a line of their own, and include some
+ white space just before. It's this extra white space that's causing
+ the problem.
+
+ Fix the formatting issue by moving the """ to the end of the previous
+ line. I then add the extra newline in at the point where the doc
+ string is merged with the dynamically generated text.
+
+ Now everything lines up correctly.
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: test to check one aspect of the linespec parsing code
+ While working on the fix for PR cli/28665 (see previous couple of
+ commits), I was playing with making a change in the linespec parsing
+ code. Specifically, I was thinking about whether the spec_string for
+ LINESPEC_LOCATION locations should ever be nullptr.
+
+ I made a change to prevent the spec_string from ever being nullptr,
+ tested gdb, and saw no regressions.
+
+ However, as part of this work I was reviewing how the breakpoint code
+ handles this case (spec_string being nullptr), and spotted that in
+ parse_breakpoint_sals the nullptr case is specifically handled, so
+ changing this should have caused a regression. But I didn't see one.
+
+ So, this commit adds a comment in location.c mentioning that the
+ nullptr case is (a) not an oversight, and (b) is required. Then I add
+ a new test to gdb.base/break.exp that ensures a change in this area
+ will cause a regression.
+
+ This test passes on current gdb, but with my modified (and broken)
+ gdb, the test would fail.
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle calls to edit command passing only a linespec condition
+ While working on the previous commit to fix PR cli/28665, I noticed
+ that the 'edit' command would suffer from the same problem. That is,
+ something like:
+
+ (gdb) edit task 123
+
+ would cause GDB to break. For a full explanation of what's going on
+ here, see the commit message for the previous commit.
+
+ As with the previous commit, this issue can be prevented by detecting,
+ and throwing, a junk at the end of the line error earlier, before
+ calling decode_line_1.
+
+ So, that's what this commit does. I've also added some tests for this
+ issue.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: handle calls to list command passing only a linespec condition
+ In PR cli/28665, it was reported that GDB would crash when given a
+ command like:
+
+ (gdb) list task 123
+
+ The problem here is that in cli/cli-cmd.c:list_command, the string
+ 'task 123' is passed to string_to_event_location in find a location
+ specification. However, this location parsing understands about
+ breakpoint conditions, and so, will stop parsing when it sees
+ something that looks like a condition, in this case, the 'task 123'
+ looks like a breakpoint condition.
+
+ As a result, the location we get back from string_to_event_location
+ has no actual location specification attached to it. The actual call
+ path is:
+
+ list_command
+ string_to_event_location
+ string_to_event_location_basic
+ new_linespec_location
+
+ In new_linespec_location we call linespec_lex_to_end, which looks at
+ 'task 123' and decides that there's nothing there that describes a
+ location. As such, in new_linespec_location, the spec_string field of
+ the location is left as nullptr.
+
+ Back in list_command we then call decode_line_1, which calls
+ event_location_to_sals, which calls parse_linespec, which takes the
+ spec_string we found earlier, and tries to converts this into a list
+ of sals.
+
+ However, parse_linespec is not intended to be passed a nullptr, for
+ example, calling is_ada_operator will try to access through the
+ nullptr, causing undefined behaviour. But there are other cases
+ within parse_linespec which don't expect to see a nullptr.
+
+ When looking at how to fix this issue, I first considered having
+ linespec_lex_to_end detect the problem. That function understands
+ when the first thing in the linespec is a condition keyword, and so,
+ could throw an error saying something like: "no linespec before
+ condition keyword", however, this is not going to work, at least, not
+ without additional changes to GDB, it is valid to place a breakpoint
+ like:
+
+ (gdb) break task 123
+
+ This will place a breakpoint at the current location with the
+ condition 'task 123', and changing linespec_lex_to_end breaks this
+ behaviour.
+
+ So, next, I considered what would happen if I added a condition to an
+ otherwise valid list command, this is what I see:
+
+ (gdb) list file.c:1 task 123
+ Junk at end of line specification.
+ (gdb)
+
+ So, then I wondered, could we just pull the "Junk" detection forward,
+ so that we throw the error earlier, before we call decode_line_1?
+
+ It turns out that yes we can. Well, sort of.
+
+ It is simpler, I think, to add a separate check into the list_command
+ function, after calling string_to_event_location, but before calling
+ decode_line_1. We know when we call string_to_event_location that the
+ string in question is not empty, so, after calling
+ string_to_event_location, if non of the string has been consumed, then
+ the content of the string must be junk - it clearly doesn't look like
+ a location specification.
+
+ I've reused the same "Junk at end of line specification." error for
+ consistency, and added a few tests to cover this issue.
+
+ While the first version of this patch was on the mailing list, a
+ second bug PR gdb/28797 was raised. This was for a very similar
+ issue, but this time the problem command was:
+
+ (gdb) list ,,
+
+ Here the list command understands about the first comma, list can have
+ two arguments separated by a comma, and the first argument can be
+ missing. So we end up trying to parse the second command "," as a
+ linespec.
+
+ However, in linespec_lex_to_end, we will stop parsing a linespec at a
+ comma, so, in the above case we end up with an empty linespec (between
+ the two commas), and, like above, this results in the spec_string
+ being nullptr.
+
+ As with the previous case, I've resolved this issue by adding an extra
+ check for junk at the end of the line - after parsing (or failing to
+ parse) the nothing between the two commas, we still have the "," left
+ at the end of the list command line - when we see this we can throw
+ the same "junk at the end of the line" error, and all is good.
+
+ I've added tests for this case too.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: move linespec test into gdb.linespec/ directory
+ The gdb.base/linespecs.exp test should really live in the gdb.linespec
+ directory, so lets move it there.
+
+ As we already have gdb.linespec/linespec.exp, I've renamed the test to
+ gdb.linespec/errors.exp, as this better reflects what the test is
+ actually checking.
+
+ Finally, the test script doesn't have its own source file, it was
+ reusing a random other source file, gdb.base/memattr.c. Now the tests
+ script is in gdb.linespec/, I've updated the test to use a different
+ source file from that directory.
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add empty string check in parse_linespec
+ If parse_linespec (linespec.c) is passed ARG as an empty string then
+ we end up calling `strchr (linespec_quote_characters, '\0')`, which
+ will return a pointer to the '\0' at the end of
+ linespec_quote_characters. This then results in GDB calling
+ skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG
+ only contained a single character, the '\0').
+
+ Fix this by checking for the first character of ARG being '\0' before
+ the call to strchr.
+
+ I have additionally added an assertion that ARG can't itself be
+ nullptr, as calling is_ada_operator with nullptr can end up calling
+ 'startswith' on the nullptr, which is undefined behaviour.
+
+ Finally, I moved the declaration of TOKEN into the body of
+ parse_linespec, to where TOKEN is defined.
+
+ This patch came about while I was working on fixes for PR cli/28665
+ and PR gdb/28797. The actual fixes for these two issues will be in a
+ later commit in this series, but, with this patch in place, both of
+ the above bugs would hit the new assertion rather than accessing
+ invalid memory and crashing. The '\0' check is not currently ever
+ hit, but just makes the code a little safer.
+
+ Because this patch only changes the nature of the failure for the
+ above two bugs, there's no tests here. A later commit will fix the
+ above two issues, at which point I'll add some tests.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
+
+2022-02-02 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: update the comment on string_to_event_location
+ The comment on string_to_event_location is (I believe) out of date.
+ This commit fixes the two issues I see:
+
+ 1. This function can't return NULL any more. The implementation
+ calls string_to_explicit_location which can return NULL, but if this
+ is the case we then call string_to_event_location_basic, which I
+ don't believe can ever return NULL.
+
+ 2. I've removed the mention that the returned string is malloc'd,
+ though this is true, now that we return a managed pointer, I believe
+ the source of the memory allocation is irrelevant, and so, shouldn't
+ be discussed in the header comment.
+
+ There should be no user visible changes after this commit.
+
+2022-02-02 Nick Clifton <nickc@redhat.com>
+
+ Updated French translation for the ld/ and gold/ sub-directories
+
+2022-02-02 Stafford Horne <shorne@gmail.com>
+
+ or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto
+ Previously when fixing PR 21464 we masked out upper bits of the
+ relocation value in order to avoid overflow complaints when acceptable.
+ It turns out this does not work when the relocation value ends up being
+ signed.
+
+ To fix this this patch introduces a special howto with
+ complain_on_overflow set to complain_overflow_dont. This is used in
+ place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16
+ relocations.
+
+ bfd/ChangeLog:
+
+ PR 28735
+ * elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define.
+ (or1k_elf_relocate_section): Use new howto instead of trying to
+ mask out relocation bits.
+
+2022-02-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-02-01 Tom Tromey <tromey@adacore.com>
+
+ Fix flex rule in gdb
+ Currently, if flex fails, it will leave the resulting .c file in the
+ tree. This will cause a cascade of errors, and requires the manual
+ deletion of the .c file in order to recreate the problem.
+
+ It's better for the rule to fail such that the .c file is not updated.
+ This way, 'make' will fail the same way every time -- which is much
+ handier for debugging syntax errors.
+
+ This fix just updates the Makefile rule to follow the way that the
+ "yacc" rule already works.
+
+2022-02-01 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, btrace: improve error messages
+ When trying to use 'record btrace' on a system that does not support it,
+ the error message isn't as clear as it could be. See
+ https://sourceware.org/pipermail/gdb/2022-January/049870.html.
+
+ Improve the error message in a few cases.
+
+ Reported-by: Simon Sobisch <simonsobisch@gnu.org>
+
+2022-02-01 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code
+ While experimenting with JIT reader API I realized that calling repr ()
+ on objfile created by JIT reader crashes GDB.
+
+ The problem was that objfpy_repr () called objfile_filename () which
+ returned NULL, causing PyString_FromFormat () to crash.
+
+ This commit fixes this problem by using objfile_name () instead of
+ objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable.
+
+2022-02-01 Samuel Thibault <samuel.thibault@gnu.org>
+
+ hurd: Fix RPC prototypes
+ The last updates of MIG introduced qualifying strings and arrays with
+ const as appropriate. We thus have to update the protypes in gdb too.
+
+ Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df
+
+2022-02-01 Samuel Thibault <samuel.thibault@gnu.org>
+
+ hurd: Fix RPC link names
+ The RPC stub code expects to be calling a C function, not a C++
+ function.
+
+ Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f
+
+2022-02-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-31 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Check symbol version without any symbols
+ VER_FLG_WEAK doesn't indicate that all symbol references of the symbol
+ version have STB_WEAK. VER_FLG_WEAK indicates a weak symbol version
+ definition with no symbols associated with it. It is used to verify
+ the existence of a particular implementation without any symbol references
+ to the weak symbol version.
+
+ PR ld/24718
+ * testsuite/ld-elf/pr24718-1.d: New file.
+ * testsuite/ld-elf/pr24718-1.s: Likewise.
+ * testsuite/ld-elf/pr24718-1.t: Likewise.
+
+2022-01-31 H.J. Lu <hjl.tools@gmail.com>
+
+ Load debug section only when dumping debug sections
+ Don't load debug sections if we aren't dumping any debug sections.
+
+ PR binutils/28843
+ * objdump.c (dump_any_debugging): New.
+ (load_debug_section): Return false if dump_any_debugging isn't
+ set.
+ (main): Set dump_any_debugging when dumping any debug sections.
+ * readelf (dump_any_debugging): New.
+ (parse_args): Set dump_any_debugging when dumping any debug
+ sections.
+ (load_debug_section): Return false if dump_any_debugging isn't
+ set.
+
+2022-01-31 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix some clang-tidy readability-misleading-indentation warnings
+ I have warnings like these showing in my editor all the time, so I
+ thought I'd run clang-tidy with this diagnostic on all the files (that I
+ can compile) and fix them.
+
+ There is still one warning, in utils.c, but that's because some code
+ is mixed up with preprocessor macros (#ifdef TUI), so I think there no
+ good solution there.
+
+ Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b
+
+2022-01-31 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
+ Info symbol is expected to print the symbol table name of a symbol, since
+ symbol lookup happens via the minimal symbol table. This name
+ corresponds to the linkage name in the full symbol table.
+
+ For gfortran (and maybe others) these names currently have the form
+ XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler
+ generated appendix for mangling.
+ An example taken from the modified nested-funcs-2.exp would be
+
+ ~~~~
+ $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
+ increment
+ 00000000000014ab l F .text 0000000000000095 increment.3883
+ 000000000000141c l F .text 000000000000008f increment_program_global.3881
+ ~~~~
+
+ This mangled name gets recognized by the Ada demangler/decoder and decoded as
+ Ada to XXXX (setting the symbol language to Ada). This leads to output
+ of XXXX over XXXX.NUMBER for info symbol on gfortran symbols.
+
+ For ifort and ifx the generated linkage names have the form
+ SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any
+ other demangler for that matter) and thus printed as is.
+ The respective objdump in the above case looks like
+
+ ~~~~
+ $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
+ increment
+ 0000000000403a44 l F .text 0000000000000074 contains_keyword_IP_increment_
+ 0000000000403ab8 l F .text 0000000000000070
+ contains_keyword_IP_increment_program_global_
+ ~~~~
+
+ In the unmodified testcase this results in 'fails' when ran with the intel
+ compilers:
+
+ ~~~~
+ >> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \
+ GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'"
+
+ ...
+
+ === gdb Summary ===
+
+ \# of expected passes 80
+ \# of unexpected failures 14
+ ~~~~
+
+ Note that there is no Fortran mangling standard. We keep the gfortran
+ behavior as is and modify the test to reflect ifx and ifort mangled
+ names which fixes above fails.
+
+2022-01-31 Nick Clifton <nickc@redhat.com>
+
+ Import patch from mainline GCC to fix an infinite recusion in the Rust demangler.
+ PR 98886
+ PR 99935
+ * rust-demangle.c (struct rust_demangler): Add a recursion
+ counter.
+ (demangle_path): Increment/decrement the recursion counter upon
+ entry and exit. Fail if the counter exceeds a fixed limit.
+ (demangle_type): Likewise.
+ (rust_demangle_callback): Initialise the recursion counter,
+ disabling if requested by the option flags.
+
+2022-01-31 Alan Modra <amodra@gmail.com>
+
+ Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+ In trying to find a testcase for PR28827, I managed to hit a linker
+ error in bfd_set_section_contents with a .branch_lt input section
+ being too large for the output .branch_lt.
+
+ bfd/
+ PR 28827
+ * elf64-ppc.c (ppc64_elf_size_stubs): Set section size to
+ maxsize past STUB_SHRINK_ITER before laying out. Remove now
+ unnecessary conditional setting of maxsize at start of loop.
+ ld/
+ * testsuite/ld-powerpc/pr28827-2.d,
+ * testsuite/ld-powerpc/pr28827-2.lnk,
+ * testsuite/ld-powerpc/pr28827-2.s: New test.
+ * testsuite/ld-powerpc/powerpc.exp: Run it.
+
+2022-01-31 Tom Tromey <tom@tromey.com>
+
+ Remove unused variables in fbsd-tdep.c files
+ i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64
+ Fedora 34 machine, using the system gcc, after a recent patch. These
+ two files now have unused variables, which provokes a warning in this
+ configuration.
+
+ I'm checking in this patch to remove the unused variables.
+
+2022-01-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-29 Alan Modra <amodra@gmail.com>
+
+ Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+ The previous patch wasn't quite correct. The size and padding depends
+ on offset used in the current iteration, and if we're fudging the
+ offset past STUB_SHRINK_ITER then we'd better use that offset. We
+ can't have plt_stub_pad using stub_sec->size as the offset.
+
+ PR 28827
+ * elf64-ppc.c (plt_stub_pad): Add stub_off param.
+ (ppc_size_one_stub): Set up stub_offset to value used in this
+ iteration before sizing the stub. Adjust plt_stub_pad calls.
+
+2022-01-29 Alan Modra <amodra@gmail.com>
+
+ objcopy --only-keep-debug
+ From: Peilin Ye <peilin.ye@bytedance.com>
+ objcopy's --only-keep-debug option has been broken for ELF files since
+ commit 8c803a2dd7d3.
+
+ 1. binutils/objcopy.c:setup_section() marks non-debug sections as
+ SHT_NOBITS, then calls bfd_copy_private_section_data();
+ 2. If ISEC and OSEC share the same section flags,
+ bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's
+ section type back to ISEC's section type, effectively undoing
+ "make_nobits".
+
+ * objcopy.c (setup_section): Act on make_nobits after calling
+ bfd_copy_private_section_data.
+
+2022-01-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ gdb: fix ppc-sysv-tdep.c build on 32-bit platforms
+ The previous code triggered the following error on an i386 host:
+
+ /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
+ unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
+ ^~~~~~~~~~~~~~~~~~~~~
+ /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
+ ^~~~~~~~~~~~~~~~~~
+ /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue
+ unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
+ ^~~~~~~~~~~~~~~~~~~~~
+ static_cast<size_t>( )
+ /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
+ ^~~~~~~~~~~~~~~~~~
+ 1 error generated.
+
+ Fix this by using gdb::make_array_view.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ FreeBSD x86 nat: Use register maps for GP register sets.
+ Rather than using the x86-specific register offset tables, use
+ register maps to describe the layout of the general purpose registers
+ fetched via PT_GETREGS. The sole user-visible difference is that
+ FreeBSD/amd64 will now report additional segment registers ($ds, $es,
+ $fs, and $gs) for both 32-bit and 64-bit processes.
+
+ As part of these changes, the FreeBSD x86 native targets no longer use
+ amd64-bsd-nat.c or i386-bsd-nat.c. Remove FreeBSD-specific register
+ handling (for $fs_base, $gs_base, and XSAVE state) from these files.
+ Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c. The
+ FreeBSD x86 native targets use a static xsave_len instead.
+
+ While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386.
+ Probe the ptrace op once in the target read_description method and
+ cache the result for the future similar to the way the status of XSAVE
+ support is probed in the read_description method. In addition, return
+ the proper xcr0 mask (X87-only) for old kernels or systems without
+ either XSAVE or XMM support.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Return a bool from fetch_register_set and store_register_set.
+ Change these helper functions to return true if they did any work.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ FreeBSD x86: Use tramp-frame for signal frames.
+ Use a register map to describe the registers in mcontext_t as part of
+ the signal frame as is done on several other FreeBSD arches. This
+ permits fetching the fsbase and gsbase register values from the signal
+ frame for both amd64 and i386 and permits fetching additional segment
+ registers stored as 16-bit values on amd64.
+
+ While signal frames on FreeBSD do contain floating point/XSAVE state,
+ these unwinders do not attempt to supply those registers. The
+ existing x86 signal frame uwinders do not support these registers, and
+ the only existing functions which handle FSAVE/FXSAVE/XSAVE state all
+ work with regcaches. In the future these unwinders could create a
+ tempory regcache, collect floating point registers, and then supply
+ values out of the regcache into the trad-frame.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ Use register maps for gp regsets on FreeBSD/x86 core dumps.
+ In particular, this permits reporting the value of the $ds, $es, $fs,
+ and $gs segment registers from amd64 core dumps since they are stored
+ as 16-bit values rather than the 32-bit size assumed by i386_gregset.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ regcache: Zero-extend small registers described by a register map.
+ When registers are supplied via regcache_supply_register from a
+ register block described by a register map, registers may be stored in
+ slots smaller than GDB's native register size (e.g. x86 segment
+ registers are 16 bits, but the GDB registers for those are 32-bits).
+ regcache_collect_regset is careful to zero-extend slots larger than a
+ register size, but regcache_supply_regset just used
+ regcache::raw_supply_part and did not initialize the upper bytes of a
+ register value.
+
+ trad_frame_set_reg_regmap assumes these semantics (zero-extending
+ short registers). Upcoming patches also require these semantics for
+ handling x86 segment register values stored in 16-bit slots on
+ FreeBSD. Note that architecturally x86 segment registers are 16 bits,
+ but the x86 gdb architectures treat these registers as 32 bits.
+
+2022-01-28 John Baldwin <jhb@FreeBSD.org>
+
+ FreeBSD x86: Remove fallback for detecting signal trampolines by address.
+ A few FreeBSD releases did not include the page holding the signal
+ code in core dumps. As a workaround, a sysctl was used to fetch the
+ default location of the signal code instead. The youngest affected
+ FreeBSD release is 10.1 released in November 2014 and EOLed in
+ December 2016. The fallback only works for native processes and would
+ require a separate unwinder once the FreeBSD arches are converted to
+ use tramp_frame for signal frames.
+
+ Remove support for pre-5.0 FreeBSD/i386 signal trampolines.
+ The last relevant release (FreeBSD 4.11) was released in January of
+ 2005.
+
+ Remove vestigal FreeBSD/i386 3.x support.
+ This was orphaned when a.out support was removed as the FreeBSD/i386
+ ELF support always used the register layouts from 4.0+.
+
+2022-01-28 Bruno Larsen <blarsen@redhat.com>
+
+ Add Bruno Larsen to gdb/MAINTAINERS
+
+2022-01-28 Enze Li <lienze2010@hotmail.com>
+
+ gdb/build: Fix Wpessimizing-move in clang build
+ When building with clang, I run into an error:
+
+ ...
+ tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy
+ elision [-Werror,-Wpessimizing-move]
+ tal.addr_string = std::move (gdb_dis_out.release ());
+ ^
+ tui/tui-disasm.c:138:25: note: remove std::move call here
+ tal.addr_string = std::move (gdb_dis_out.release ());
+ ^~~~~~~~~~~ ~
+ ...
+
+ The error above is caused by the recent commit 5d10a2041eb8 ("gdb: add
+ string_file::release method").
+
+ Fix this by removing std::move.
+
+ Build on x86_64-linux with clang 13.0.0.
+
+2022-01-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ Add top-level .editorconfig file
+ Add a .editorconfig [1] file. This helps configure editors
+ automatically with the right whitespace settings. It will help me,
+ since I need to juggle with different whitespace settings for different
+ projects. But I think it can also help newcomers get things right from
+ the start.
+
+ Some editors have native support for reading these files, while others
+ require a plug-in [2]. And if you don't want to use it, then this file
+ doesn't change anything to your life.
+
+ I added rules for the kinds of files I edit most often, but more can be
+ added later. I assumed that the rules were the same for GDB and the
+ other projects, but if that's not the case, we can always put
+ .editorconfig files in project subdirectories to override settings.
+
+ [1] https://editorconfig.org/
+ [2] https://editorconfig.org/#download
+
+ Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b
+
+2022-01-28 Nick Clifton <nickc@redhat.com>
+
+ Updated French translation for the gas sub-directory.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ Set __ehdr_start rel_from_abs earlier
+ This is just a tidy, making the __ehdr_start symbol flag tweaks all in
+ one place.
+
+ * ldelf.c (ldelf_before_allocation): Don't set rel_from_abs
+ for __ehdr_start.
+ * ldlang.c (lang_symbol_tweaks): Set it here instead.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 handling of @tocbase
+ * elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol
+ on R_PPC64_TOC isn't local.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ Update PowerPC64 symtocbase test
+ Using a symbol other than .TOC. with @tocbase is an extension to the
+ ABI. It is never valid to use a symbol without a definition in the
+ binary, and symbols on these expressions cannot be overridden. Make
+ this explicit by using ".hidden" in the testcase.
+
+ * testsuite/ld-powerpc/symtocbase-1.s: Align data. Make function
+ entry symbol hidden.
+ * testsuite/ld-powerpc/symtocbase-2.s: Likewise.
+ * testsuite/ld-powerpc/symtocbase.d: Adjust expected output.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+ The assertion is this one in ppc_build_one_stub
+ BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size);
+ It is checking that a stub doesn't overwrite the tail of a previous
+ stub, so not something trivial.
+
+ Normally, stub sizing iterates until no stubs are added, detected by
+ no change in stub section size. Iteration also continues if no stubs
+ are added but one or more stubs increases in size, which also can be
+ detected by a change in stub section size. But there is a
+ pathological case where stub section sizing decreases one iteration
+ then increases the next. To handle that situation, stub sizing also
+ stops at more than STUB_SHRINK_ITER (20) iterations when calculated
+ stub section size is smaller. The previous larger size is kept for
+ the actual layout (so that building the stubs, which behaves like
+ another iteration of stub sizing, will see the stub section sizes
+ shrink). The problem with that stopping condition is that it assumes
+ that stub sizing is only affected by addresses external to the stub
+ sections, which isn't always true.
+
+ This patch fixes that by also keeping larger individual stub_offset
+ addresses past STUB_SHRINK_ITER. It also catches a further
+ pathological case where one stub shrinks and another expands in such a
+ way that no stub section size change is seen.
+
+ PR 28827
+ * elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed.
+ (STUB_SHRINK_ITER): Move earlier in file.
+ (ppc_size_one_stub): Detect any change in stub_offset. Keep
+ larger one if past STUB_SHRINK_ITER.
+ (ppc64_elf_size_stubs): Iterate on stub_changed too.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ PR28826 x86_64 ld segfaults building xen
+ Fallout from commit e86fc4a5bc37
+
+ PR 28826
+ * coffgen.c (coff_write_alien_symbol): Init dummy to zeros.
+
+2022-01-28 Alan Modra <amodra@gmail.com>
+
+ PR28753, buffer overflow in read_section_stabs_debugging_info
+ PR 28753
+ * rddbg.c (read_section_stabs_debugging_info): Don't read past
+ end of section when concatentating stab strings.
+
+2022-01-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: work around negative DW_AT_data_member_location GCC 11 bug
+ g++ 11.1.0 has a bug where it will emit a negative
+ DW_AT_data_member_location in some cases:
+
+ $ cat test.cpp
+ #include <memory>
+
+ int
+ main()
+ {
+ std::unique_ptr<int> ptr;
+ }
+ $ g++ -g test.cpp
+ $ llvm-dwarfdump -F a.out
+ ...
+ 0x00000964: DW_TAG_member
+ DW_AT_name [DW_FORM_strp] ("_M_head_impl")
+ DW_AT_decl_file [DW_FORM_data1] ("/usr/include/c++/11.1.0/tuple")
+ DW_AT_decl_line [DW_FORM_data1] (125)
+ DW_AT_decl_column [DW_FORM_data1] (0x27)
+ DW_AT_type [DW_FORM_ref4] (0x0000067a "default_delete<int>")
+ DW_AT_data_member_location [DW_FORM_sdata] (-1)
+ ...
+
+ This leads to a GDB crash (when built with ASan, otherwise probably
+ garbage results), since it tries to read just before (to the left, in
+ ASan speak) of the value's buffer:
+
+ ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18
+ READ of size 1 at 0x6020000c52af thread T0
+ #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
+ #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347
+ #2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126
+ #3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333
+ #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+ #14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+ #15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+ #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+ #22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+ #23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+ #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+ #28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+ #29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587
+ #30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614
+ #31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189
+ #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337
+ #33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258
+ #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367
+ #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458
+ #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97
+ #37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475
+ #38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670
+ #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523
+ #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618
+ #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317
+ #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338
+ #43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363
+ #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
+ #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
+ #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d)
+
+ 0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8)
+ allocated by thread T0 here:
+ #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+ #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
+ #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29
+ #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029
+ #4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040
+ #5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092
+ #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501
+ #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+ #16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+ #17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+ #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+ #19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+ #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+ #24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+ #25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+ #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+ #27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+ #28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+ #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+
+ Since there are some binaries with this in the wild, I think it would be
+ useful for GDB to work around this. I did the obvious simple thing, if
+ the DW_AT_data_member_location's value is -1, replace it with 0. I
+ added a producer check to only apply this fixup for GCC 11. The idea is
+ that if some other compiler ever uses a DW_AT_data_member_location value
+ of -1 by mistake, we don't know (before analyzing the bug at least) if
+ they did mean 0 or some other value. So I wouldn't want to apply the
+ fixup in that case.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063
+ Change-Id: Ieef3459b0b9bbce8bdad838ba83b4b64e7269d42
+
+2022-01-27 Kevin Buettner <kevinb@redhat.com>
+
+ Fix GDB internal error by using text (instead of data) section offset
+ Fedora Rawhide is now using gcc-12.0. As part of updating to the
+ gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
+ which lacks a .data section. This causes gdb to fail in the following
+ fashion while debugging a program (such as gdb) which uses libgcc_s:
+
+ (top-gdb) run
+ Starting program: rawhide-master/bld/gdb/gdb
+ ...
+ objfiles.h:467: internal-error: sect_index_data not initialized
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ...
+
+ I snipped the backtrace from the above output. Instead, here's a
+ portion of a backtrace obtained using GDB's backtrace command.
+ (Obviously, in order to obtain it, I used a GDB which has been patched
+ with this commit.)
+
+ #0 internal_error (
+ file=0xc6a508 "gdb/objfiles.h", line=467,
+ fmt=0xc6a4e8 "sect_index_data not initialized")
+ at gdbsupport/errors.cc:51
+ #1 0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
+ at gdb/objfiles.h:467
+ #2 0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
+ at gdb/stap-probe.c:1333
+ #3 0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
+ objfile=0x4fa48f0)
+ at gdb/stap-probe.c:1341
+ #4 0x00000000004d7025 in create_exception_master_breakpoint_probe (
+ objfile=0x4fa48f0)
+ at gdb/breakpoint.c:3505
+ #5 0x00000000004d7426 in create_exception_master_breakpoint ()
+ at gdb/breakpoint.c:3575
+ #6 0x00000000004efcc1 in breakpoint_re_set ()
+ at gdb/breakpoint.c:13407
+ #7 0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
+ at gdb/solib.c:1001
+ #8 0x00000000009576a8 in handle_solib_event ()
+ at gdb/solib.c:1269
+ ...
+
+ The function 'relocate_address' in gdb/stap-probe.c attempts to do
+ its "relocation" by using objfile->data_section_offset(). That
+ method, data_section_offset() is defined as follows in objfiles.h:
+
+ CORE_ADDR data_section_offset () const
+ {
+ return section_offsets[SECT_OFF_DATA (this)];
+ }
+
+ The internal error occurs when the SECT_OFF_DATA macro finds that the
+ 'sect_index_data' field is -1:
+
+ #define SECT_OFF_DATA(objfile) \
+ ((objfile->sect_index_data == -1) \
+ ? (internal_error (__FILE__, __LINE__, \
+ _("sect_index_data not initialized")), -1) \
+ : objfile->sect_index_data)
+
+ relocate_address() is obtaining the section offset in order to compute
+ a relocated address. For some ABIs, such as the System V ABI, the
+ section offsets will all be the same. So for those ABIs, it doesn't
+ matter which offset is used. However, other ABIs, such as the FDPIC
+ ABI, will have different offsets for the various sections. Thus, for
+ those ABIs, it is vital that this and other relocation code use the
+ correct offset.
+
+ In stap_probe::get_relocated_address, the address to which to add the
+ offset (thus forming the relocated address) is obtained via
+ this->get_address (); get_address is a getter for m_address in
+ probe.h. It's documented/defined as follows (also in probe.h):
+
+ /* The address where the probe is inserted, relative to
+ SECT_OFF_TEXT. */
+ CORE_ADDR m_address;
+
+ (Thanks to Tom Tromey for this observation.)
+
+ So, based on this, the current use of data_section_offset /
+ SECT_OFF_DATA is wrong. This relocation code should have been using
+ text_section_offset / SECT_OFF_TEXT all along. That being the
+ case, I've adjusted the stap-probe.c relocation code accordingly.
+
+ Searching the sources turned up one other use of data_section_offset,
+ in gdb/dtrace-probe.c, so I've updated that code as well. The same
+ reasoning presented above applies to this case too.
+
+ Summary:
+
+ * gdb/dtrace-probe.c (dtrace_probe::get_relocated_address):
+ Use method text_section_offset instead of data_section_offset.
+ * gdb/stap-probe.c (relocate_address): Likewise.
+
+2022-01-27 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, remote, btrace: move switch_to_thread call right before xfer call
+ In remote_target::remote_btrace_maybe_reopen, we switch to the currently
+ iterated thread in order to set inferior_ptid for a subsequent xfer.
+
+ Move the switch_to_thread call directly before the target_read_stralloc
+ call to clarify why we need to switch threads.
+
+2022-01-27 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, gdbserver: update thread identifier in enable_btrace target method
+ The enable_btrace target method takes a ptid_t to identify the thread on
+ which tracing shall be enabled.
+
+ Change this to thread_info * to avoid translating back and forth between
+ the two. This will be used in a subsequent patch.
+
+2022-01-27 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, btrace: switch threads in remote_btrace_maybe_reopen()
+ In remote_btrace_maybe_reopen() we iterate over threads and use
+ set_general_thread() to set the thread from which to transfer the btrace
+ configuration.
+
+ This sets the remote general thread but does not affect inferior_ptid. On
+ the xfer request later on, remote_target::xfer_partial() again sets the
+ remote general thread to inferior_ptid, overwriting what
+ remote_btrace_maybe_reopen() had done.
+
+ In one case, this led to inferior_ptid being null_ptid when we tried to
+ enable tracing on a newly created thread inside a newly created process
+ during attach.
+
+ This, in turn, led to find_inferior_pid() asserting when we iterated over
+ threads in record_btrace_is_replaying(), which was called from
+ record_btrace_target::xfer_partial() when reading the btrace configuration
+ of the new thread to check whether it was already being recorded.
+
+ The bug was exposed by
+
+ 0618ae41497 gdb: optimize all_matching_threads_iterator
+
+ and found by
+
+ FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)
+
+ Use switch_to_thread() in remote_btrace_maybe_reopen().
+
+2022-01-27 Markus Metzger <markus.t.metzger@intel.com>
+
+ gdb, btrace: rename record_btrace_enable_warn()
+ We use record_btrace_enable_warn() as the new-thread observer callback.
+ It is not used in other contexts.
+
+ Rename it to record_btrace_on_new_thread() to make its role more clear.
+
+2022-01-27 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the binutils subdirectory
+
+2022-01-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: handle non utf-8 characters when source highlighting
+ This commit adds support for source files that contain non utf-8
+ characters when performing source styling using the Python pygments
+ package. This does not change the behaviour of GDB when the GNU
+ Source Highlight library is used.
+
+ For the following problem description, assume that either GDB is built
+ without GNU Source Highlight support, of that this has been disabled
+ using 'maintenance set gnu-source-highlight enabled off'.
+
+ The initial problem reported was that a source file containing non
+ utf-8 characters would cause GDB to print a Python exception, and then
+ display the source without styling, e.g.:
+
+ Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 142: invalid start byte
+ /* Source code here, without styling... */
+
+ Further, as the user steps through different source files, each time
+ the problematic source file was evicted from the source cache, and
+ then later reloaded, the exception would be printed again.
+
+ Finally, this problem is only present when using Python 3, this issue
+ is not present for Python 2.
+
+ What makes this especially frustrating is that GDB can clearly print
+ the source file contents, they're right there... If we disable
+ styling completely, or make use of the GNU Source Highlight library,
+ then everything is fine. So why is there an error when we try to
+ apply styling using Python?
+
+ The problem is the use of PyString_FromString (which is an alias for
+ PyUnicode_FromString in Python 3), this function converts a C string
+ into a either a Unicode object (Py3) or a str object (Py2). For
+ Python 2 there is no unicode encoding performed during this function
+ call, but for Python 3 the input is assumed to be a uft-8 encoding
+ string for the purpose of the conversion. And here of course, is the
+ problem, if the source file contains non utf-8 characters, then it
+ should not be treated as utf-8, but that's what we do, and that's why
+ we get an error.
+
+ My first thought when looking at this was to spot when the
+ PyString_FromString call failed with a UnicodeDecodeError and silently
+ ignore the error. This would mean that GDB would print the source
+ without styling, but would also avoid the annoying exception message.
+
+ However, I also make use of `pygmentize`, a command line wrapper
+ around the Python pygments module, which I use to apply syntax
+ highlighting in the output of `less`. And this command line wrapper
+ is quite happy to syntax highlight my source file that contains non
+ utf-8 characters, so it feels like the problem should be solvable.
+
+ It turns out that inside the pygments module there is already support
+ for guessing the encoding of the incoming file content, if the
+ incoming content is not already a Unicode string. This is what
+ happens for Python 2 where the incoming content is of `str` type.
+
+ We could try and make GDB smarter when it comes to converting C
+ strings into Python Unicode objects; this would probably require us to
+ just try a couple of different encoding schemes rather than just
+ giving up after utf-8.
+
+ However, I figure, why bother? The pygments module already does this
+ for us, and the colorize API is not part of the documented external
+ API of GDB. So, why not just change the colorize API, instead of the
+ content being a Unicode string (for Python 3), lets just make the
+ content be a bytes object. The pygments module can then take
+ responsibility for guessing the encoding.
+
+ So, currently, the colorize API receives a unicode object, and returns
+ a unicode object. I propose that the colorize API receive a bytes
+ object, and return a bytes object.
+
+2022-01-26 Tom Tromey <tom@tromey.com>
+
+ Remove global wrap_here function
+ This removes the global wrap_here function, so that future calls
+ cannot be introduced. Instead, all callers must use the method on the
+ appropriate ui_file.
+
+ This temporarily moves the implementation of this method to utils.c.
+ This will change once the remaining patches to untangle the pager have
+ been written.
+
+2022-01-26 Tom Tromey <tom@tromey.com>
+
+ Always call the wrap_here method
+ This changes all existing calls to wrap_here to call the method on the
+ appropriate ui_file instead. The choice of ui_file is determined by
+ context.
+
+2022-01-26 Tom Tromey <tom@tromey.com>
+
+ Add ui_file::wrap_here
+ Right now, wrap_here is a global function. In the long run, we'd like
+ output streams to be relatively self-contained objects, and having a
+ global function like this is counter to that goal. Also, existing
+ code freely mixes writes to some parameterized stream with calls to
+ wrap_here -- but wrap_here only really affects gdb_stdout, so this is
+ also incoherent.
+
+ This step is a patch toward making wrap_here more sane. It adds a
+ wrap_here method to ui_file and changes ui_out implementations to use
+ it.
+
+2022-01-26 Tom Tromey <tom@tromey.com>
+
+ Convert wrap_here to use integer parameter
+ I think it only really makes sense to call wrap_here with an argument
+ consisting solely of spaces. Given this, it seemed better to me that
+ the argument be an int, rather than a string. This patch is the
+ result. Much of it was written by a script.
+
+2022-01-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: improve the auto help text for gdb.Parameter
+ This commit attempts to improve the help text that is generated for
+ gdb.Parameter objects when the user fails to provide their own
+ documentation.
+
+ Documentation for a gdb.Parameter is currently pulled from two
+ sources: the class documentation string, and the set_doc/show_doc
+ class attributes. Thus, a fully documented parameter might look like
+ this:
+
+ class Param_All (gdb.Parameter):
+ """This is the class documentation string."""
+
+ show_doc = "Show the state of this parameter"
+ set_doc = "Set the state of this parameter"
+
+ def get_set_string (self):
+ val = "on"
+ if (self.value == False):
+ val = "off"
+ return "Test Parameter has been set to " + val
+
+ def __init__ (self, name):
+ super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
+ self._value = True
+
+ Param_All ('param-all')
+
+ Then in GDB we see this:
+
+ (gdb) help set param-all
+ Set the state of this parameter
+ This is the class documentation string.
+
+ Which is fine. But, if the user skips both of the documentation parts
+ like this:
+
+ class Param_None (gdb.Parameter):
+
+ def get_set_string (self):
+ val = "on"
+ if (self.value == False):
+ val = "off"
+ return "Test Parameter has been set to " + val
+
+ def __init__ (self, name):
+ super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
+ self._value = True
+
+ Param_None ('param-none')
+
+ Now in GDB we see this:
+
+ (gdb) help set param-none
+ This command is not documented.
+ This command is not documented.
+
+ That's not great, the duplicated text looks a bit weird. If we drop
+ different parts we get different results. Here's what we get if the
+ user drops the set_doc and show_doc attributes:
+
+ (gdb) help set param-doc
+ This command is not documented.
+ This is the class documentation string.
+
+ That kind of sucks, we say it's undocumented, then proceed to print
+ the documentation. Finally, if we drop the class documentation but
+ keep the set_doc and show_doc:
+
+ (gdb) help set param-set-show
+ Set the state of this parameter
+ This command is not documented.
+
+ That seems OK.
+
+ So, I think there's room for improvement.
+
+ With this patch, for the four cases above we now see this:
+
+ # All values provided by the user, no change in this case:
+ (gdb) help set param-all
+ Set the state of this parameter
+ This is the class documentation string.
+
+ # Nothing provided by the user, the first string is now different:
+ (gdb) help set param-none
+ Set the current value of 'param-none'.
+ This command is not documented.
+
+ # Only the class documentation is provided, the first string is
+ # changed as in the previous case:
+ (gdb) help set param-doc
+ Set the current value of 'param-doc'.
+ This is the class documentation string.
+
+ # Only the set_doc and show_doc are provided, this case is unchanged
+ # from before the patch:
+ (gdb) help set param-set-show
+ Set the state of this parameter
+ This command is not documented.
+
+ The one place where this change might be considered a negative is when
+ dealing with prefix commands. If we create a prefix command but don't
+ supply the set_doc / show_doc strings, then this is what we saw before
+ my patch:
+
+ (gdb) python Param_None ('print param-none')
+ (gdb) help set print
+ set print, set pr, set p
+ Generic command for setting how things print.
+
+ List of set print subcommands:
+
+ ... snip ...
+ set print param-none -- This command is not documented.
+ ... snip ...
+
+ And after my patch:
+
+ (gdb) python Param_None ('print param-none')
+ (gdb) help set print
+ set print, set pr, set p
+ Generic command for setting how things print.
+
+ List of set print subcommands:
+
+ ... snip ...
+ set print param-none -- Set the current value of 'print param-none'.
+ ... snip ...
+
+ This seems slightly less helpful than before, but I don't think its
+ terrible.
+
+ Additionally, I've changed what we print when the get_show_string
+ method is not provided in Python.
+
+ Back when gdb.Parameter was first added to GDB, we didn't provide a
+ show function when registering the internal command object within
+ GDB. As a result, GDB would make use of its "magic" mangling of the
+ show_doc string to create a sentence that would display the current
+ value (see deprecated_show_value_hack in cli/cli-setshow.c).
+
+ However, when we added support for the get_show_string method to
+ gdb.Parameter, there was an attempt to maintain backward compatibility
+ by displaying the show_doc string with the current value appended, see
+ get_show_value in py-param.c. Unfortunately, this isn't anywhere
+ close to what deprecated_show_value_hack does, and the results are
+ pretty poor, for example, this is GDB before my patch:
+
+ (gdb) show param-none
+ This command is not documented. off
+
+ I think we can all agree that this is pretty bad.
+
+ After my patch, we how show this:
+
+ (gdb) show param-none
+ The current value of 'param-none' is "off".
+
+ Which at least is a real sentence, even if it's not very informative.
+
+ This patch does change the way that the Python API behaves slightly,
+ but only in the cases when the user has missed providing GDB with some
+ information. In most cases I think the new behaviour is a lot better,
+ there's the one case (noted above) which is a bit iffy, but I think is
+ still OK.
+
+ I've updated the existing gdb.python/py-parameter.exp test to cover
+ the modified behaviour.
+
+ Finally, I've updated the documentation to (I hope) make it clearer
+ how the various bits of help text come together.
+
+2022-01-26 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add gdb.history_count function
+ Add a new function gdb.history_count to the Python api, this function
+ returns an integer, the number of items in GDB's value history.
+
+ This is useful if you want to pull items from the history by their
+ absolute number, for example, if you wanted to show a complete history
+ list. Previously we could figure out how many items are in the
+ history list by trying to fetch the items, and then catching the
+ exception when the item is not available, but having this function
+ seems nicer.
+
+2022-01-26 Tom Tromey <tromey@adacore.com>
+
+ Remove unused declaration
+ This removes an unused declaration from top.h. This type is not
+ defined anywhere.
+
+2022-01-26 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: convert maintenance target-async and target-non-stop settings to callbacks
+ This simplifies things a bit, as we don't need two variables and think
+ about reverting target_async_permitted_1 and target_non_stop_enabled_1
+ values if we can't change the setting.
+
+ Change-Id: I36acab045dacf02ae1988486cfdb27c1dff309f6
+
+2022-01-26 Keith Seitz <keiths@redhat.com>
+
+ Reference array of structs instead of first member during memcpy
+ aarch64-tdep.c defines the following macro:
+
+ #define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
+ do \
+ { \
+ unsigned int mem_len = LENGTH; \
+ if (mem_len) \
+ { \
+ MEMS = XNEWVEC (struct aarch64_mem_r, mem_len); \
+ memcpy(&MEMS->len, &RECORD_BUF[0], \
+ sizeof(struct aarch64_mem_r) * LENGTH); \
+ } \
+ } \
+ while (0)
+
+ This is simlpy allocating a new array and copying it. However, for
+ the destination address, it is actually copying into the first member
+ of the first element of the array (`&MEMS->len"). This elicits a
+ warning with GCC 12:
+
+ ../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’:
+ ../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=]
+ 3711 | memcpy(&MEMS->len, &RECORD_BUF[0], \
+ | ^
+ ../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’
+ 4394 | MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
+ | ^~~~~~~~~
+ ../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8
+ 3721 | uint64_t len; /* Record length. */
+ | ^~~
+
+ The simple fix is to reference the array, `MEMS' as the destination of the copy.
+
+ Tested by rebuilding.
+
+
+ # Please enter the commit message for your changes. Lines starting
+ # with '#' will be kept; you may remove them yourself if you want to.
+ # An empty message aborts the commit.
+ #
+ # Date: Tue Jan 25 08:28:32 2022 -0800
+ #
+ # On branch master
+ # Your branch is ahead of 'origin/master' by 1 commit.
+ # (use "git push" to publish your local commits)
+ #
+ # Changes to be committed:
+ # modified: aarch64-tdep.c
+ #
+
+2022-01-26 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add string_file::release method
+ A common pattern for string_file is to want to move out the internal
+ string buffer, because it is the result of the computation that we want
+ to return. It is the reason why string_file::string returns a non-const
+ reference, as explained in the comment. I think it would make sense to
+ have a dedicated method for that instead and make string_file::string
+ return a const reference.
+
+ This allows removing the explicit std::move in the typical case. Note
+ that compile_program::compute was missing a move, meaning that the
+ resulting string was copied. With the new version, it's not possible to
+ forget to move.
+
+ Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79
+
+2022-01-26 Tom Tromey <tromey@adacore.com>
+
+ Add a way to temporarily set a gdb parameter from Python
+ It's sometimes useful to temporarily set some gdb parameter from
+ Python. Now that the 'endian' crash is fixed, and now that the
+ current language is no longer captured by the Python layer, it seems
+ reasonable to add a helper function for this situation.
+
+ This adds a new gdb.with_parameter function. This creates a context
+ manager which temporarily sets some parameter to a specified value.
+ The old value is restored when the context is exited. This is most
+ useful with the Python "with" statement:
+
+ with gdb.with_parameter('language', 'ada'):
+ ... do Ada stuff
+
+ This also adds a simple function to set a parameter,
+ gdb.set_parameter, as suggested by Andrew.
+
+ This is PR python/10790.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790
+
+2022-01-26 Tom Tromey <tromey@adacore.com>
+
+ Fix another crash with gdb parameters in Python
+ While looking into the language-capturing issue, I found another way
+ to crash gdb using parameters from Python:
+
+ (gdb) python print(gdb.parameter('endian'))
+
+ (This is related to PR python/12188, though this patch isn't going to
+ fix what that bug is really about.)
+
+ The problem here is that the global variable that underlies the
+ "endian" parameter is initialized to NULL. However, that's not a
+ valid value for an "enum" set/show parameter.
+
+ My understanding is that, in gdb, an "enum" parameter's underlying
+ variable must have a value that is "==" (not just strcmp-equal) to one
+ of the values coming from the enum array. This invariant is relied on
+ in various places.
+
+ I started this patch by fixing the problem with "endian". Then I
+ added some assertions to add_setshow_enum_cmd to try to catch other
+ problems of the same type.
+
+ This patch fixes all the problems that I found. I also looked at all
+ the calls to add_setshow_enum_cmd to ensure that they were all
+ included in the gdb I tested. I think they are: there are no calls in
+ nat-* files, or in remote-sim.c; and I was trying a build with all
+ targets, Python, and Guile enabled.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
+
+2022-01-26 Tom Tromey <tromey@adacore.com>
+
+ Change how Python architecture and language are handled
+ Currently, gdb's Python layer captures the current architecture and
+ language when "entering" Python code. This has some undesirable
+ effects, and so this series changes how this is handled.
+
+ First, there is code like this:
+
+ gdbpy_enter enter_py (python_gdbarch, python_language);
+
+ This is incorrect, because both of these are NULL when not otherwise
+ assigned. This can cause crashes in some cases -- I've added one to
+ the test suite. (Note that this crasher is just an example, other
+ ones along the same lines are possible.)
+
+ Second, when the language is captured in this way, it means that
+ Python code cannot affect the current language for its own purposes.
+ It's reasonable to want to write code like this:
+
+ gdb.execute('set language mumble')
+ ... stuff using the current language
+ gdb.execute('set language previous-value')
+
+ However, this won't actually work, because the language is captured on
+ entry. I've added a test to show this as well.
+
+ This patch changes gdb to try to avoid capturing the current values.
+ The Python concept of the current gdbarch is only set in those few
+ cases where a non-default value is computed or needed; and the
+ language is not captured at all -- instead, in the cases where it's
+ required, the current language is temporarily changed.
+
+2022-01-26 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Make bfd.stamp depend on source bfd.texi
+ Make bfd.stamp depend on source bfd.texi to avoid regenerating
+ doc/bfd.info for each make run.
+
+ PR binutils/28807
+ * Makefile.in: Regenerate.
+ * doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi.
+
+2022-01-26 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Rewrite lang_size_relro_segment_1
+ 1. Compute the desired PT_GNU_RELRO segment base and find the maximum
+ section alignment of sections starting from the PT_GNU_RELRO segment.
+ 2. Find the first preceding load section.
+ 3. Don't add the 1-page gap between the first preceding load section and
+ the relro segment if the maximum page size >= the maximum section
+ alignment. Align the PT_GNU_RELRO segment first. Subtract the maximum
+ page size if therer is still a 1-page gap.
+
+ PR ld/28743
+ PR ld/28819
+ * ldlang.c (lang_size_relro_segment_1): Rewrite.
+ * testsuite/ld-x86-64/pr28743-1.d: New file.
+ * testsuite/ld-x86-64/pr28743-1.s: Likewise.
+ * testsuite/ld-x86-64/x86-64.exp: Run pr28743-1.
+
+2022-01-26 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: Ensure constant test name in gdb.base/break-interp.exp
+ When running the testsuite, I have lines similar to the following in the
+ gdb.sum file:
+
+ ~~~
+ PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1
+ ...
+ PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5
+ ...
+ ~~~
+
+ The address part of the command might change between execution of the
+ test, which adds noise to a diff between two .sum files.
+
+ This patch changes to test name to "p /x $pc" in order to have constant
+ test name.
+
+ Tested on x86_64-Linux.
+
+ Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21
+
+2022-01-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-25 Tom Tromey <tom@tromey.com>
+
+ Always print the "host libthread-db" message to stdout
+ linux-thread-db.c has a bit of unusual code that unconditionally
+ prints a message, but decides whether to print to gdb_stdout or
+ gdb_stdlog based on a debug flag. It seems better to me to simply
+ always print this; and this is the only spot in gdb where we
+ conditionally pass gdb_stdout to one of the f*_unfiltered functions.
+
+2022-01-25 Tom Tromey <tom@tromey.com>
+
+ Reduce explicit use of gdb_stdout
+ In an earlier version of the pager rewrite series, it was important to
+ audit unfiltered output calls to see which were truly necessary.
+
+ This is no longer necessary, but it still seems like a decent cleanup
+ to change calls to avoid explicitly passing gdb_stdout. That is,
+ rather than using something like fprintf_unfiltered with gdb_stdout,
+ the code ought to use plain printf_unfiltered instead.
+
+ This patch makes this change. I went ahead and converted all the
+ _filtered calls I could find, as well, for the same clarity.
+
+2022-01-25 Tom Tromey <tom@tromey.com>
+
+ Sent timing stats to gdb_stdlog
+ This changes the time / space / symtab per-command statistics code to
+ send its output to gdb_stdlog rather than gdb_stdout. This seems
+ slightly more correct to me.
+
+ Send some error output to gdb_stderr
+ This changes some code to send some error messages to gdb_stderr
+ rather than gdb_stdout.
+
+2022-01-25 Klaus Ziegler <klausz@haus-gisela.de>
+
+ Fix a probem building the binutils on SPARC/amd64
+ PR 28816
+ * elf/common.h (AT_SUN_HWCAP): Make definition conditional.
+
+2022-01-25 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Regenerate Makefile.in
+ * Makefile.in: Regenerate.
+
+2022-01-25 Mike Frysinger <vapier@gentoo.org>
+
+ gold: drop old cygnus install hack
+ The gold subdir doesn't actually have a manual, so this hack doesn't
+ do anything. Plus the automake cygnus option was removed years ago
+ by Simon in d0ac1c44885daf68f631befa37e ("Bump to autoconf 2.69 and
+ automake 1.15.1"). So delete it here.
+
+ gas: drop old cygnus install hack
+ This was needed when gas was using the automake cygnus option, but
+ this was removed years ago by Simon in d0ac1c44885daf68f631befa37e
+ ("Bump to autoconf 2.69 and automake 1.15.1"). So delete it here.
+ The info pages are already & still installed by default w/out it.
+
+2022-01-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-24 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Update doc/local.mk
+ PR binutils/28807
+ * Makefile.in: Regenerate.
+ * doc/local.mk (AM_MAKEINFOFLAGS): Add -I "$(srcdir)/%D%" -I %D%.
+ (TEXI2DVI): New.
+ (%D%/bfd.texi): Removed.
+ (doc/bfd/index.html): Remove -I$(srcdir). Replace bfd.texi with
+ %D%/bfd.texi.
+
+2022-01-24 Roland McGrath <mcgrathr@google.com>
+
+ bfd/doc: Fix racy build failure from missing mkdir
+ bfd/
+ * doc/local.mk (%D%/bfdver.texi): Add mkdir command.
+
+2022-01-24 Martin Sebor <msebor@redhat.com>
+
+ Fix a proble building the libiberty library with gcc-12.
+ PR 28779
+ * regex.c: Suppress -Wuse-after-free.
+
+2022-01-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: improve description for Window.click on Python TUI windows
+ The description of the Window.click method doesn't mention where the
+ coordinates are anchored (it's the top left corner).
+
+ This minor tweak just mentions this point.
+
+2022-01-24 Nick Clifton <nickc@redhat.com>
+
+ Update Bulgarian, French, Romaniam and Ukranian translation for some of the sub-directories
+
+2022-01-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-23 Tom Tromey <tom@tromey.com>
+
+ Simplify some Rust expression-evaluation code
+ A few Rust operations do a bit of work in their 'evaluate' functions
+ and then call another function -- but are also the only caller. This
+ patch simplifies this code by removing the extra layer.
+
+ Tested on x86-64 Fedora 34. I'm checking this in.
+
+2022-01-23 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Partially revert commit 0e3839bde6f
+ Partially revert
+
+ commit 0e3839bde6f93e1e3eefce815be3636e3d81054d
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Sun Jan 23 07:29:27 2022 -0800
+
+ bfd: Properly install library and header files
+
+ PR binutils/28807
+ * Makefile.am: Revert bfdlib_LTLIBRARIES and bfdinclude_HEADERS
+ changes.
+ * Makefile.in: Regenerate.
+
+2022-01-23 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Properly install library and header files
+ Rename bfdlib_LTLIBRARIES and bfdinclude_HEADERS to lib_LTLIBRARIES and
+ include_HEADERS to fix the missing installed library and header files in
+ bfd caused by
+
+ commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
+ Author: Mike Frysinger <vapier@gentoo.org>
+ Date: Fri Dec 3 00:23:20 2021 -0500
+
+ bfd: merge doc subdir up a level
+
+ PR binutils/28807
+ * Makefile.am (bfdlib_LTLIBRARIES): Renamed to ...
+ (lib_LTLIBRARIES): This.
+ (bfdinclude_HEADERS): Renamed to ...
+ (include_HEADERS): This.
+ * Makefile.in: Regenerate.
+ * doc/local.mk (install): Removed.
+
+2022-01-23 H.J. Lu <hjl.tools@gmail.com>
+
+ Regenerate Makefile.in files with automake 1.15.1
+ Regenerate Makefile.in files with the unmodified automake 1.15.1 to
+ remove
+
+ runstatedir = @runstatedir@
+
+ bfd/
+
+ * Makefile.in: Regenerate.
+
+ binutils/
+
+ * Makefile.in: Regenerate.
+
+ gas/
+
+ * Makefile.in: Regenerate.
+
+ gold/
+
+ * Makefile.in: Regenerate.
+ * testsuite/Makefile.in: Likewise.
+
+ gprof/
+
+ * Makefile.in: Regenerate.
+
+ ld/
+
+ * Makefile.in: Regenerate.
+
+ opcodes/
+
+ * Makefile.in: Regenerate.
+
+2022-01-23 H.J. Lu <hjl.tools@gmail.com>
+
+ Regenerate configure files with autoconf 2.69
+ Regenerate configure files with the unmodified autoconf 2.69 to remove
+
+ --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
+
+ bfd/
+
+ * configure: Regenerate.
+
+ binutils/
+
+ * configure: Regenerate.
+
+ gas/
+
+ * configure: Regenerate.
+
+ gold/
+
+ * configure: Regenerate.
+
+ gprof/
+
+ * configure: Regenerate.
+
+ ld/
+
+ * configure: Regenerate.
+
+ opcodes/
+
+ * configure: Regenerate.
+
+2022-01-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-22 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: merge doc subdir up a level
+ This avoids a recursive make into the doc subdir and speeds up the
+ build slightly. It also allows for more parallelism.
+
+ bfd: rename core.texi to corefile.texi
+ This is a generated file name from a correspondingly named C file.
+ Rename it to avoid unique build rules since there's no difference
+ to the generated manual.
+
+ bfd: replace doc header generation with pattern rules
+ This unifies boilerplate rules for most files with pattern rules.
+
+2022-01-22 Martin Storsj? <martin@martin.st>
+
+ Allow inferring tmp_prefix from the dll name from a def file.
+
+2022-01-22 Alexander von Gluck IV <kallisti5@unixzen.com>
+
+ Adjust default page sizes for haiku arm.
+ * configure.tgt (arm-haiku): Fix typo.
+ * emulparams/armelf_haiku.su (MAXPAGESIZE): Use the default value.
+ (COMMONPAGESIZE): Likewise.
+
+2022-01-22 Nick Clifton <nickc@redhat.com>
+
+ Update release makeing script with new release numbers
+
+ Change version number to 2.38.50 and regenerate files
+
+ Add markers for 2.38 branch
+
+2022-01-22 Lifang Xia <lifang_xia@linux.alibaba.com>
+
+ RISC-V: create new frag after alignment.
+ PR 28793:
+
+ The alignment may be removed in linker. We need to create new frag after
+ alignment to prevent the assembler from computing static offsets.
+
+ gas/
+ * config/tc-riscv.c (riscv_frag_align_code): Create new frag.
+
+2022-01-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: include gdbsupport/buildargv.h in ser-mingw.c
+ Fixes:
+
+ CXX ser-mingw.o
+ /home/simark/src/binutils-gdb/gdb/ser-mingw.c: In function ‘int pipe_windows_open(serial*, const char*)’:
+ /home/simark/src/binutils-gdb/gdb/ser-mingw.c:870:3: error: ‘gdb_argv’ was not declared in this scope
+ 870 | gdb_argv argv (name);
+ | ^~~~~~~~
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28802
+ Change-Id: I7f3e8ec5f9ca8582d587545fdf6b69901259f199
+
+2022-01-21 Nick Clifton <nickc@redhat.com>
+
+ Updated Serbian translation for the ld sub-directory
+
+2022-01-21 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: fill in two missing @r
+ I noticed two places in the docs where we appear to be missing @r.
+ makeinfo seems to do the correct things despite these being
+ missing (at least, I couldn't see any difference in the pdf or info
+ output), but it doesn't hurt to have the @r in place.
+
+2022-01-21 Mike Frysinger <vapier@gentoo.org>
+
+ drop old unused stamp-h.in file
+ This was needed by ancient versions of automake, but that hasn't been
+ the case since at least automake-1.5, so punt this from the tree.
+
+2022-01-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport/gdb_regex.cc: replace defs.h include with common-defs.h
+ This was forgotten when gdb_regex was moved from gdb to gdbsupport.
+
+ Change-Id: I73b446f71861cabbf7afdb7408ef9d59fa64b804
+
+2022-01-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-20 Tom Tromey <tromey@adacore.com>
+
+ Avoid bad breakpoints with --gc-sections
+ We found a case where --gc-sections can cause gdb to set an invalid
+ breakpoint. In the included test case, gdb will set a breakpoint with
+ two locations, one of which is 0x0.
+
+ The code in lnp_state_machine::check_line_address is intended to
+ filter out this sort of problem, but in this case, the entire CU is
+ empty, causing unrelocated_lowpc==0x0 -- which circumvents the check.
+
+ It seems to me that if a CU is empty like this, then it is ok to
+ simply ignore the line table, as there won't be any locations anyway.
+
+2022-01-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-19 Maciej W. Rozycki <macro@embecosm.com>
+
+ Add `set print array-indexes' tests for C/C++ arrays
+ Add `set print array-indexes' tests for C/C++ arrays, complementing one
+ for Fortran arrays.
+
+2022-01-19 Maciej W. Rozycki <macro@embecosm.com>
+
+ Respect `set print array-indexes' with Fortran arrays
+ Add `set print array-indexes' handling for Fortran arrays. Currently
+ the setting is ignored and indices are never shown.
+
+ Keep track of the most recent index handled so that any outstanding
+ repeated elements printed when the limit set by `set print elements' is
+ hit have the correct index shown.
+
+ Output now looks like:
+
+ (gdb) set print array-indexes on
+ (gdb) print array_1d
+ $1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1)
+ (gdb) set print repeats 4
+ (gdb) set print elements 12
+ (gdb) print array_2d
+ $2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...)
+ (gdb)
+
+ for a 5-element vector and a 5 by 5 array filled with the value of 2.
+
+2022-01-19 Maciej W. Rozycki <macro@embecosm.com>
+
+ Add `set print repeats' tests for C/C++ arrays
+ Add `set print repeats' tests for C/C++ arrays, complementing one for
+ Fortran arrays and covering the different interpretation of the `set
+ print elements' setting in particular where the per-dimension count of
+ the elements handled is matched against the trigger rather than the
+ total element count as with Fortran arrays.
+
+2022-01-19 Maciej W. Rozycki <macro@embecosm.com>
+
+ Respect `set print repeats' with Fortran arrays
+ Implement `set print repeats' handling for Fortran arrays. Currently
+ the setting is ignored and always treated as if no limit was set.
+
+ Unlike the generic array walker implemented decades ago the Fortran one
+ is a proper C++ class. Rather than trying to mimic the old walker then,
+ which turned out a bit of a challenge where interacting with the `set
+ print elements' setting, write it entirely from scratch, by adding an
+ extra specialization handler method for processing dimensions other than
+ the innermost one and letting the specialization class call the `walk_1'
+ method from the handler as it sees fit. This way repeats can be tracked
+ and the next inner dimension recursed into as a need arises only, or
+ unconditionally in the base class.
+
+ Keep track of the dimension number being handled in the class rather as
+ a parameter to the walker so that it does not have to be passed across
+ by the specialization class.
+
+ Use per-dimension element count tracking, needed to terminate processing
+ early when the limit set by `set print elements' is hit. This requires
+ extra care too where the limit triggers exactly where another element
+ that is a subarray begins. In that case rather than recursing we need
+ to terminate processing or lone `(...)' would be printed. Additionally
+ if the skipped element is the last one in the current dimension we need
+ to print `...' by hand, because `continue_walking' won't print it at the
+ upper level, because it can see the last element has already been taken
+ care of.
+
+ Preserve the existing semantics of `set print elements' where the total
+ count of the elements handled is matched against the trigger level which
+ is unlike with the C/C++ array printer where the per-dimension element
+ count is used instead.
+
+ Output now looks like:
+
+ (gdb) set print repeats 4
+ (gdb) print array_2d
+ $1 = ((2, <repeats 5 times>) <repeats 5 times>)
+ (gdb) set print elements 12
+ (gdb) print array_2d
+ $2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...)
+ (gdb)
+
+ for a 5 by 5 array filled with the value of 2.
+
+ Amend existing test cases accordingly that rely on the current incorrect
+ behavior and explicitly request that there be no limit for printing
+ repeated elements there.
+
+ Add suitable test cases as well covering sliced arrays in particular.
+
+ Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
+
+2022-01-19 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Add include for gdb_argv.
+
+2022-01-19 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 DT_RELR ELFv1
+ More fun with R_PPC64_NONE found in .opd. Fixed by the
+ allocate_dynrelocs and ppc64_elf_size_dynamic_sections changes, and
+ since we are doing ifunc, opd and SYMBOL_REFERENCES_LOCAL tests later,
+ don't duplicate that work in check_relocs.
+
+ * elf64-ppc.c (ppc64_elf_check_relocs): Remove opd and ifunc
+ conditions for rel_count.
+ (dec_dynrel_count): Likewise.
+ (allocate_dynrelocs): Test for opd and ifunc when allocating
+ relative relocs.
+ (ppc64_elf_size_dynamic_sections): Likewise.
+
+2022-01-19 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 DT_RELR local PLT
+ Similarly to the local GOT case.
+
+ * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate
+ space for PLT relocs against local syms when enable_dt_relr.
+
+2022-01-19 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 DT_RELR local GOT
+ Fixes another case where we end up with superfluous R_PPC64_NONE.
+
+ * elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate
+ space for GOT relocs against non-TLS local syms when enable_dt_relr.
+ (ppc64_elf_layout_multitoc): Likewise.
+
+2022-01-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ Re: PowerPC64 DT_RELR
+ HJ: "There are 238 R_PPC64_NONEs in libc.so.6 alone."
+ Indeed, let's make them go away. I had the SYMBOL_REFERENCES_LOCAL
+ test in the wrong place. check_relocs is too early to know whether a
+ symbol is dynamic in a shared library. Lots of glibc symbols are made
+ local by version script, but that doesn't happen until
+ size_dynamic_sections.
+
+ * elf64-ppc.c (ppc64_elf_check_relocs): Don't count relative relocs
+ here depending on SYMBOL_REFERENCES_LOCAL.
+ (dec_dynrel_count): Likewise.
+ (allocate_dynrelocs): Do so here instead.
+
+2022-01-18 Tom Tromey <tom@tromey.com>
+
+ Fix the remote-sim.c build
+ My earlier patch to move gdb_argv broke the remote-sim.c build. This
+ patch fixes the bug. I'm checking it in.
+
+2022-01-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: introduce remote_debug_printf
+ Add remote_debug_printf, and use it for all debug messages controlled by
+ remote_debug.
+
+ Change remote_debug to be a bool, which is trivial in this case.
+
+ Change-Id: I90de13cb892faec3830047b571661822b126d6e8
+
+2022-01-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: introduce threads_debug_printf, THREADS_SCOPED_DEBUG_ENTER_EXIT
+ Add the threads_debug_printf and THREADS_SCOPED_DEBUG_ENTER_EXIT, which
+ use the logging infrastructure from gdbsupport/common-debug.h. Replace
+ all debug_print uses that are predicated by debug_threads with
+ threads_dethreads_debug_printf. Replace uses of the debug_enter and
+ debug_exit macros with THREADS_SCOPED_DEBUG_ENTER_EXIT, which serves
+ essentially the same purpose, but allows showing what comes between the
+ enter and the exit in an indented form.
+
+ Note that "threads" debug is currently used for a bit of everything in
+ GDBserver, not only threads related stuff. It should ideally be cleaned
+ up and separated logically as is done in GDB, but that's out of the
+ scope of this patch.
+
+ Change-Id: I2d4546464462cb4c16f7f1168c5cec5a89f2289a
+
+2022-01-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: turn debug_threads into a boolean
+ debug_threads is always used as a boolean. Except in ax.cc and
+ tracepoint.cc. These files have their own macros that use
+ debug_threads, and have a concept of verbosity level. But they both
+ have a single level, so it's just a boolean in the end.
+
+ Remove this concept of level. If we ever want to re-introduce it, I
+ think it will be better implemented in a more common location.
+
+ Change debug_threads to bool and adjust some users that were treating it
+ as an int.
+
+ Change-Id: I137f596eaf763a08c977dd74417969cedfee9ecf
+
+2022-01-18 Tom Tromey <tom@tromey.com>
+
+ Simplify Ada catchpoints
+ All the Ada catchpoints use the same breakpoint_ops contents, because
+ the catchpoint itself records its kind. This patch simplifies the
+ code by removing the redundant ops structures.
+
+ Move "catch exec" to a new file
+ The "catch exec" code is reasonably self-contained, and so this patch
+ moves it out of breakpoint.c (the second largest source file in gdb)
+ and into a new file, break-catch-exec.c.
+
+ Move "catch fork" to a new file
+ The "catch fork" code is reasonably self-contained, and so this patch
+ moves it out of breakpoint.c (the second largest source file in gdb)
+ and into a new file, break-catch-fork.c.
+
+ Unify "catch fork" and "catch vfork"
+ I noticed that "catch fork" and "catch vfork" are nearly identical.
+ This patch simplifies the code by unifying these two cases.
+
+ Move gdb_regex to gdbsupport
+ This moves the gdb_regex convenience class to gdbsupport.
+
+ Introduce gdb-hashtab module in gdbsupport
+ gdb has some extensions and helpers for working with the libiberty
+ hash table. This patch consolidates these and moves them to
+ gdbsupport.
+
+ Move gdb obstack code to gdbsupport
+ This moves the gdb-specific obstack code -- both extensions like
+ obconcat and obstack_strdup, and things like auto_obstack -- to
+ gdbsupport.
+
+ Move gdb_argv to gdbsupport
+ This moves the gdb_argv class to a new header in gdbsupport.
+
+ Simplify event_location_probe
+ event_location_probe currently stores two strings, but really only
+ needs one. This patch simplifies it and removes some unnecessary
+ copies as well.
+
+ Use std::string in event_location
+ This changes event_location to use std::string, removing some manual
+ memory management, and an unnecessary string copy.
+
+ Split event_location into subclasses
+ event_location uses the old C-style discriminated union approach.
+ However, it's better to use subclassing, as this makes the code
+ clearer and removes some chances for error. This also enables future
+ cleanups to avoid manual memory management and copies.
+
+ Remove EL_* macros from location.c
+ This patch removes the old-style EL_* macros from location.c. This
+ cleans up the code by itself, IMO, but also enables further cleanups
+ in subsequent patches.
+
+ Boolify explicit_to_string_internal
+ This changes explicit_to_string_internal to use 'bool' rather than
+ 'int'.
+
+ Remove a use of xfree in location.c
+ This small cleanup removes a use of xfree from location.c, by
+ switching to unique_xmalloc_ptr. One function is only used in
+ location.c, so it is made static. And, another function is changed to
+ avoid a copy.
+
+2022-01-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use ptid_t::to_string instead of target_pid_to_str in debug statements
+ Same idea as 0fab79556484 ("gdb: use ptid_t::to_string in infrun debug
+ messages"), but throughout GDB.
+
+ Change-Id: I62ba36eaef29935316d7187b9b13d7b88491acc1
+
+2022-01-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: preserve `|` in connection details string
+ Consider this GDB session:
+
+ $ gdb -q
+ (gdb) target remote | gdbserver - ~/tmp/hello.x
+ Remote debugging using | gdbserver - ~/tmp/hello.x
+ ... snip ...
+ (gdb) info connections
+ Num What Description
+ * 1 remote gdbserver - ~/tmp/hello.x Remote target using gdb-specific protocol
+ (gdb) python conn = gdb.selected_inferior().connection
+ (gdb) python print(conn.details)
+ gdbserver - ~/tmp/hello.x
+ (gdb)
+
+ I think there are two things wrong here, first in the "What" column of
+ the 'info connections' output, I think the text should be:
+
+ remote | gdbserver - ~/tmp/hello.x
+
+ to correctly show the user how the connection was established. And in
+ a similar fashion, I think that the `details` string of the
+ gdb.TargetConnection object should be:
+
+ | gdbserver - ~/tmp/hello.x
+
+ This commit makes this change. Currently the '|' is detected and
+ removed in gdb/serial.c. The string passed to the pipe_ops
+ structure (from gdb/ser-pipe.c), doesn't then, contain the `|`, this
+ is instead implied by the fact that it is a pipes based implementation
+ of the serial_ops interface.
+
+ After this commit we still detect the `|` in gdb/serial.c, but we now
+ store the full string (including the `|`) in the serial::name member
+ variable.
+
+ For pipe based serial connections, this name is only used for
+ displaying the two fields I mention above, and in pipe_open (from
+ gdb/ser-pipe.c), and in pipe_open, we now know to skip over the `|`.
+
+ The benefit I see from this change is that GDB's output now more
+ accurately reflects the commands used to start a target, thus making
+ it easier for a user to understand what is going on.
+
+2022-01-18 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: print explicit test result for gdb.base/dfp-test.exp
+ In the current code, if decimal floating point is not supported for
+ this target, there is no binary file dfp-test, and also there is no
+ test result after execute the following commands:
+
+ $ make check-gdb TESTS="gdb.base/dfp-test.exp"
+ $ grep error gdb/testsuite/gdb.log
+ /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.c:39:1: error: decimal floating point not supported for this target
+ [...]
+ $ cat gdb/testsuite/gdb.sum
+ [...]
+ Running target unix
+ Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
+
+ === gdb Summary ===
+ [...]
+
+ With this patch:
+
+ $ make check-gdb TESTS="gdb.base/dfp-test.exp"
+ $ cat gdb/testsuite/gdb.sum
+ [...]
+ Running target unix
+ Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
+ UNSUPPORTED: gdb.base/dfp-test.exp: decimal floating point not supported for this target.
+
+ === gdb Summary ===
+
+ # of unsupported tests 1
+ [...]
+
+2022-01-18 Simon Marchi <simon.marchi@efficios.com>
+
+ bfd/elf64-ppc.c: fix clang -Wbitwise-instead-of-logical warning in ppc64_elf_check_init_fini
+ I see this error with clang-14:
+
+ CC elf64-ppc.lo
+ /home/smarchi/src/binutils-gdb/bfd/elf64-ppc.c:13131:11: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
+ return (check_pasted_section (info, ".init")
+ ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Fix by replacing & with &&. But given that the check_pasted_section
+ function has side-effects and we want to make sure both calls are made,
+ assign to temporary variables before evaluating the `&&`.
+
+ Change-Id: I849e1b2401bea5f4d8ef3ab9af99ba9e3ef42490
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ PR28029, debuginfod tests
+ binutils/NEWS says of the change in --process-links semantics:
+ If other debug section display options are also enabled (eg
+ --debug-dump=info) then the contents of matching sections in both the main
+ file and the separate debuginfo file *will* be displayed. This is because in
+ most cases the debug section will only be present in one of the files.
+
+ Implying that debug info is dumped without --process-links. Indeed
+ that appears to be the case for readelf. This does the same for
+ objdump.
+
+ PR 28029
+ * objdump.c (dump_bfd): Do not exit early when !is_mainfile
+ && !processlinks, instead just exclude non-debug output.
+ (dump_dwarf): Add is_mainfile parameter and pass to
+ dump_dwarf_section.
+ (dump_dwarf_section): Only display debug sections when
+ !is_mainfile and !process_links.
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ Check thin archive element file size against archive header
+ Makes it a little less likely for someone to break their thin archives.
+
+ * archive.c (_bfd_get_elt_at_filepos): Check thin archive
+ element file size.
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ lang_size_relro_segment tidy
+ This function has seen too many minimal change style edits.
+ No functional changes in this patch.
+
+ * ldlang.c (lang_size_relro_segment): Tidy.
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 DT_RELR
+ PowerPC64 takes a more traditional approach to DT_RELR than x86. Count
+ relative relocs in check_relocs, allocate space for them and output in
+ the usual places but not doing so when enable_dt_relr. DT_RELR is
+ sized in the existing ppc stub relaxation machinery, run via the
+ linker's ldemul_after_allocation hook. DT_RELR is output in the same
+ function that writes ppc stubs, run via ldemul_finish.
+
+ This support should be considered experimental.
+
+ bfd/
+ * elf64-ppc.c (struct ppc_local_dyn_relocs): Renamed from
+ ppc_dyn_relocs. Add rel_count field. Update uses.
+ (struct ppc_dyn_relocs): New. Replace all uses of elf_dyn_relocs.
+ (struct ppc_link_hash_table): Add relr_alloc, relr_count and
+ relr_addr.
+ (ppc64_elf_copy_indirect_symbol): Merge rel_count.
+ (ppc64_elf_check_relocs): Init rel_count for global and local syms.
+ (dec_dynrel_count): Change r_info param to reloc pointer. Update
+ all callers. Handle decrementing rel_count.
+ (allocate_got): Don't allocate space for relative relocs when
+ enable_dt_relr.
+ (allocate_dynrelocs): Likewise.
+ (ppc64_elf_size_dynamic_sections): Likewise. Handle srelrdyn.
+ (ppc_build_one_stub): Don't emit relative relocs on .branch_lt.
+ (compare_relr_address, append_relr_off): New functions.
+ (got_and_plt_relr_for_local_syms, got_and_plt_relr): Likewise.
+ (ppc64_elf_size_stubs): Size .relr.syn.
+ (ppc64_elf_build_stubs): Emit .relr.dyn.
+ (build_global_entry_stubs_and_plt): Don't output relative relocs
+ when enable_dt_relr.
+ (write_plt_relocs_for_local_syms): Likewise.
+ (ppc64_elf_relocate_section): Likewise.
+ binutils/
+ * testsuite/lib/binutils-common.exp (supports_dt_relr): Add
+ powerpc64.
+ ld/
+ * emulparams/elf64ppc.sh: Source dt-relr.sh.
+ * testsuite/ld-elf/dt-relr-2b.d: Adjust for powerpc.
+ * testsuite/ld-elf/dt-relr-2c.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2d.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2e.d: Likewise.
+
+2022-01-18 Alan Modra <amodra@gmail.com>
+
+ tweak __ehdr_start visibility and flags for check_relocs
+ bfd/
+ * elf-bfd.h (UNDEFWEAK_NO_DYNAMIC_RELOC): Test linker_def.
+ ld/
+ * ldelf.c (ldelf_before_allocation): Don't force __ehdr_start
+ local and hidden here..
+ * ldlang.c (lang_symbol_tweaks): ..do so here instead and set
+ def_regular and linker_def for check_relocs. New function
+ extracted from lang_process.
+
+2022-01-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-17 Nick Clifton <nickc@redhat.com>
+
+ Update the config.guess and config.sub files from the master repository and regenerate files.
+
+2022-01-17 Sergey Belyashov <sergey.belyashov@gmail.com>
+
+ Fix Z80 assembly failure.
+ PR 28762
+ * app.c (do_scrub_chars): Correct handling when the symbol is not 'af'.
+
+2022-01-17 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/infrun: rename variable and move to more specific scope
+ Move the "started" variable to the scope it's needed, and rename it to
+ "step_over_started".
+
+ Change-Id: I56f3384dbd328f55198063bb855edda10f1492a3
+
+2022-01-17 Jan Beulich <jbeulich@suse.com>
+
+ x86: adjust struct instr_info field types
+ Now that this lives on the stack, let's have it be a little less
+ wasteful in terms of space. Switch boolean fields to "bool" (also when
+ this doesn't change their size) and also limit the widths of "rex",
+ "rex_used", "op_ad", and "op_index". Do a little bit of re-ordering as
+ well to limit the number of padding holes.
+
+ x86: drop index16 field
+ There's a single use on a generally infrequently taken code path. Put
+ the necessary conditional there instead.
+
+ x86: drop most Intel syntax register name arrays
+ By making use of, in particular, oappend_maybe_intel() there's no need
+ for this redundant set of static data.
+
+ x86: fold variables in memory operand index handling
+ There's no real need for the pseudo-boolean "haveindex" or for separate
+ 32-bit / 64-bit index pointers. Fold them into a single "indexes" and
+ set that uniformly to AT&T names, compensating by emitting the register
+ name via oappend_maybe_intel().
+
+ x86: constify disassembler static data
+ Now that the code is intended to be largely thread-safe, we'd better not
+ have any writable static objects.
+
+2022-01-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-16 Joel Brobecker <brobecker@adacore.com>
+
+ gdb/copyright.py: Do not update gdbsupport/Makefile.in
+ This file is generated, so we should not modify it (any modification
+ we make is going to be undone at the next re-generation anyway).
+
+2022-01-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.dlang/demangle.exp: update expected output for _D8demangle4testFnZv
+ Since commit ce2d3708bc8b ("Synchronize binutils libiberty sources with
+ gcc version."), I see this failure:
+
+ demangle _D8demangle4testFnZv^M
+ demangle.test(typeof(null))^M
+ (gdb) FAIL: gdb.dlang/demangle.exp: _D8demangle4testFnZv
+
+ The commit imported the commit 0e32a5aa8bc9 ("libiberty: Add support for
+ D `typeof(*null)' types") from the gcc repository. That commit includes
+ an update to libiberty/testsuite/d-demangle-expected, which updates a
+ test for the exact same mangled name:
+
+ _D8demangle4testFnZv
+ -demangle.test(none)
+ +demangle.test(typeof(null))
+
+ I don't know anything about D, but give that the change was made by Iain
+ Buclaw, the D language maintainer, I trust him on that.
+
+ Fix our test by updating the expected output in the same way.
+
+ Note: it's not really useful to have all these D demangling tests in the
+ GDB testsuite, since there are demangling tests in libiberty. We should
+ consider removing them, but we first need to make sure that everything
+ that is covered in gdb/testsuite/gdb.dlang/demangle.exp is also covered
+ in libiberty/testsuite/d-demangle-expected.
+
+ Change-Id: If2b290ea8367b8e1e0b90b20d4a6e0bee517952d
+
+2022-01-14 Nils-Christian Kempke <nils-christian.kempke@intel.com>
+
+ gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info
+ Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
+ version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
+
+ gdb/testsuite/ChangeLog:
+ 2020-12-07 Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
+
+ * lib/compiler.c: Add Intel next gen compiler pre-processor check.
+ * lib/compiler.cc: Ditto.
+ * lib/fortran.exp (fortran_main): Check Intel next gen compiler in
+ test_compiler_info.
+
+2022-01-14 Alan Modra <amodra@gmail.com>
+
+ PR28751 mbind2a / mbind2b regressions on powerpc*-linux
+ include/
+ * bfdlink.h (struct bfd_link_info): Add commonpagesize_is_set.
+ ld/
+ PR 28751
+ * emultempl/elf.em (handle_option): Set commonpagesize_is_set.
+ * ldelf.c (ldelf_after_parse): Don't error when only one of
+ -z max-page-size or -z common-page-size is given, correct the
+ other value to make it sane.
+ * testsuite/ld-elf/elf.exp (mbind2a, mbind2b): Do not pass
+ -z max-page-size.
+
+2022-01-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop ymmxmm_mode
+ This enumerator is not used by any table entry.
+
+ x86: share yet more VEX table entries with EVEX decoding
+ On top of prior similar work more opportunities have appeared in the
+ meantime. Note that this also happens to address the prior lack of
+ decoding of EVEX.L'L for VMOV{L,H}P{S,D} and VMOV{LH,HL}PS.
+
+ x86: consistently use scalar_mode for AVX512-FP16 scalar insns
+ For some reason the original AVFX512F insns were not taken as a basis
+ here, causing unnecessary divergence. While not an active issue, it is
+ still relevant to note that OP_XMM() has special treatment of e.g.
+ scalar_mode (marking broadcast as invalid). Such would better be
+ consistent for all sufficiently similar insns.
+
+ x86: record further wrong uses of EVEX.b
+ For one EVEX.W set does not imply EVEX.b is uniformly valid. Reject it
+ for modes which occur for insns allowing for EVEX.W to be set (noticed
+ with VMOV{H,L}PD and VMOVDDUP, and only in AT&T mode, but not checked
+ whether further insns would also have been impacted; I expect e.g.
+ VCMPSD would have had the same issue). And then the present concept of
+ broadcast makes no sense at all when the memory operand of an insn is
+ the destination.
+
+2022-01-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: reduce AVX512 FP set of insns decoded through vex_w_table[]
+ Like for AVX512-FP16, there's not that many FP insns where going through
+ this table is easier / cheaper than using suitable macros. Utilize %XS
+ and %XD more to eliminate a fair number of table entries.
+
+ While doing this I noticed a few anomalies. Where lines get touched /
+ moved anyway, these are being addressed right here:
+ - vmovshdup used EXx for its 2nd operand, thus displaying seemingly
+ valid broadcast when EVEX.b is set with a memory operand; use
+ EXEvexXNoBcst instead just like vmovsldup already does
+ - vmovlhps used EXx for its 3rd operand, when all sibling entries use
+ EXq; switch to EXq there for consistency (the two differ only for
+ memory operands)
+
+2022-01-14 Jan Beulich <jbeulich@suse.com>
+
+ x86: reduce AVX512-FP16 set of insns decoded through vex_w_table[]
+ Like already indicated during review of the original submission, there's
+ really only very few insns where going through this table is easier /
+ cheaper than using suitable macros. Utilize %XH more and introduce
+ similar %XS and %XD (which subsequently can be used for further table
+ size reduction).
+
+ While there also switch to using oappend() in 'XH' macro processing.
+
+2022-01-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-13 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Disable DT_RELR in some -z relro tests
+ Disable DT_RELR in the following -z relro tests which don't expect
+ DT_RELR in linker outputs.
+
+ * testsuite/ld-i386/pr20830.d: Pass $NO_DT_RELR_LDFLAGS to ld.
+ * testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-01-13 H.J. Lu <hjl.tools@gmail.com>
+
+ Reapply libiberty: Pass --plugin to AR and RANLIB
+ Reapply the patch to detect GCC LTO plugin used for libiberty build to
+ support LTO build in libiberty.
+
+ * Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+ (RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+ (configure_deps): Depend on ../config/gcc-plugin.m4.
+ * aclocal.m4: Include ../config/gcc-plugin.m4.
+ * configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+ RANLIB_PLUGIN_OPTION.
+ * configure: Regenerate.
+
+2022-01-13 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Remove the 1-page gap before the RELRO segment
+ The existing RELRO scheme may leave a 1-page gap before the RELRO segment
+ and align the end of the RELRO segment to the page size:
+
+ [18] .eh_frame PROGBITS 408fa0 008fa0 005e80 00 A 0 0 8
+ [19] .init_array INIT_ARRAY 410de0 00fde0 000008 08 WA 0 0 8
+ [20] .fini_array FINI_ARRAY 410de8 00fde8 000008 08 WA 0 0 8
+ [21] .dynamic DYNAMIC 410df0 00fdf0 000200 10 WA 7 0 8
+ [22] .got PROGBITS 410ff0 00fff0 000010 08 WA 0 0 8
+ [23] .got.plt PROGBITS 411000 010000 000048 08 WA 0 0 8
+
+ Instead, we can remove the 1-page gap if the maximum page size >= the
+ maximum section alignment:
+
+ [18] .eh_frame PROGBITS 408fa0 008fa0 005e80 00 A 0 0 8
+ [19] .init_array INIT_ARRAY 40fde0 00fde0 000008 08 WA 0 0 8
+ [20] .fini_array FINI_ARRAY 40fde8 00fde8 000008 08 WA 0 0 8
+ [21] .dynamic DYNAMIC 40fdf0 00fdf0 000200 10 WA 7 0 8
+ [22] .got PROGBITS 40fff0 00fff0 000010 08 WA 0 0 8
+ [23] .got.plt PROGBITS 410000 010000 000048 08 WA 0 0 8
+
+ Because the end of the RELRO segment is always aligned to the page size
+ and may not be moved, the RELRO segment size may be increased:
+
+ [ 3] .dynstr STRTAB 000148 000148 000001 00 A 0 0 1
+ [ 4] .eh_frame PROGBITS 000150 000150 000000 00 A 0 0 8
+ [ 5] .init_array INIT_ARRAY 200150 000150 000010 08 WA 0 0 1
+ [ 6] .fini_array FINI_ARRAY 200160 000160 000010 08 WA 0 0 1
+ [ 7] .jcr PROGBITS 200170 000170 000008 00 WA 0 0 1
+ [ 8] .data.rel.ro PROGBITS 200180 000180 000020 00 WA 0 0 16
+ [ 9] .dynamic DYNAMIC 2001a0 0001a0 0001c0 10 WA 3 0 8
+ [10] .got PROGBITS 200360 000360 0002a8 00 WA 0 0 8
+ [11] .bss NOBITS 201000 000608 000840 00 WA 0 0 1
+
+ vs the old section layout:
+
+ [ 3] .dynstr STRTAB 000148 000148 000001 00 A 0 0 1
+ [ 4] .eh_frame PROGBITS 000150 000150 000000 00 A 0 0 8
+ [ 5] .init_array INIT_ARRAY 200b48 000b48 000010 08 WA 0 0 1
+ [ 6] .fini_array FINI_ARRAY 200b58 000b58 000010 08 WA 0 0 1
+ [ 7] .jcr PROGBITS 200b68 000b68 000008 00 WA 0 0 1
+ [ 8] .data.rel.ro PROGBITS 200b70 000b70 000020 00 WA 0 0 16
+ [ 9] .dynamic DYNAMIC 200b90 000b90 0001c0 10 WA 3 0 8
+ [10] .got PROGBITS 200d50 000d50 0002a8 00 WA 0 0 8
+ [11] .bss NOBITS 201000 000ff8 000840 00 WA 0 0 1
+
+ But there is no 1-page gap.
+
+ PR ld/28743
+ * ldlang.c (lang_size_relro_segment_1): Remove the 1-page gap
+ before the RELRO segment if the maximum page size >= the maximum
+ section alignment.
+ * testsuite/ld-i386/pr20830.d: Adjusted.
+ * testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise.
+ * testsuite/ld-x86-64/pr14207.d: Likewise.
+ * testsuite/ld-x86-64/pr18176.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830a.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr20830b.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038a.d: Likewise.
+ * testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+ * testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-01-13 Nick Clifton <nickc@redhat.com>
+
+ Synchronize binutils libiberty sources with gcc version.
+ +2021-12-30 Lancelot SIX <lsix@lancelotsix.com>
+ +
+ + * cp-demangle.c (d_clone_suffix): Support digits in clone tag
+ + names.
+ + * testsuite/demangle-expected: Check demangling of clone symbols
+ + with digits in name.
+ +
+ +2021-12-16 H.J. Lu <hjl.tools@gmail.com>
+ +
+ + Revert:
+ + 2021-12-16 H.J. Lu <hjl.tools@gmail.com>
+ +
+ + * Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+ + (RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+ + (configure_deps): Depend on ../config/gcc-plugin.m4.
+ + * configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+ + RANLIB_PLUGIN_OPTION.
+ + * aclocal.m4: Regenerated.
+ + * configure: Likewise.
+ +
+ +2021-12-15 H.J. Lu <hjl.tools@gmail.com>
+ +
+ + * Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+ + (RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+ + (configure_deps): Depend on ../config/gcc-plugin.m4.
+ + * configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+ + RANLIB_PLUGIN_OPTION.
+ + * aclocal.m4: Regenerated.
+ + * configure: Likewise.
+ +
+ +2021-11-29 Eric Gallager <egallager@gcc.gnu.org>
+ +
+ + PR other/103021
+ + * Makefile.in: Use ETAGS variable in TAGS target.
+ + * configure: Regenerate.
+ + * configure.ac: Allow ETAGS variable to be overridden.
+ +
+ +2021-11-29 Andrew Pinski <apinski@marvell.com>
+ +
+ + * make-temp-file.c (try_dir): Check to see if the dir
+ + is actually a directory.
+ +
+ +2021-10-22 Eric Gallager <egallager@gcc.gnu.org>
+ +
+ + PR other/102663
+ + * Makefile.in: Allow dvi-formatted documentation
+ + to be installed.
+ +
+ +2021-10-17 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + PR d/102618
+ + * d-demangle.c (dlang_parse_qualified): Handle anonymous
+ + symbols correctly.
+ + * testsuite/d-demangle-expected: New tests to cover anonymous
+ + symbols.
+ +
+ +2021-10-14 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * testsuite/d-demangle-expected: Add test case for function literals.
+ +
+ +2021-10-14 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * testsuite/d-demangle-expected: Add test cases for simple special
+ + mangles.
+ +
+ +2021-10-12 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * d-demangle.c (dlang_parse_qualified): Remove redudant parenthesis
+ + around lhs and rhs of assignments.
+ +
+ +2021-10-01 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * testsuite/d-demangle-expected: Add missing format for new test
+ +
+ +2021-09-23 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * d-demangle.c (dlang_Type): Validate MANGLED is nonnull.
+ + * testsuite/d-demangle-expected: New test.
+ +
+ +2021-09-23 Lu?s Ferreira <contact@lsferreira.net>
+ +
+ + * d-demangle.c (dlang_symbol_backref): Ensure strlen of
+ + string is less than length computed by dlang_number.
+ +
+ +2021-09-01 Iain Sandoe <iain@sandoe.co.uk>
+
+ * configure: Regenerate.
+ + * configure.ac: Do not search for sbrk on Darwin.
+ + * xmalloc.c: Do not declare sbrk unless it has been found
+ + by configure.
+ +
+ +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org>
+ +
+ + * d-demangle.c (dlang_identifier): Skip over fake parent manglings.
+ + * testsuite/d-demangle-expected: Add tests.
+ +
+ +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org>
+ +
+ + * d-demangle.c (dlang_parse_arrayliteral): Add 'info' parameter.
+ + (dlang_parse_assocarray): Likewise.
+ + (dlang_parse_structlit): Likewise.
+ + (dlang_value): Likewise. Handle function literal symbols.
+ + (dlang_template_args): Pass 'info' to dlang_value.
+ + * testsuite/d-demangle-expected: Add new test.
+ +
+ +2021-08-29 Iain Buclaw <ibuclaw@gdcproject.org>
+ +
+ + * d-demangle.c (dlang_attributes): Handle typeof(*null).
+ + (dlang_type): Likewise. Demangle 'n' as typeof(null).
+ + * testsuite/d-demangle-expected: Update tests.
+ +
+ +2021-08-23 Iain Sandoe <iain@sandoe.co.uk>
+ +
+ + * simple-object-mach-o.c (simple_object_mach_o_write_segment):
+ + Cast the first argument to set_32 as needed.
+
+ -2021-07-03 Nick Clifton <nickc@redhat.com>
+ +2021-08-18 Iain Sandoe <iain@sandoe.co.uk>
+
+ + * simple-object-mach-o.c (simple_object_mach_o_write_segment):
+ + Arrange to swap the LTO index tables where needed.
+ # Please enter the commit message for your changes. Lines starting
+
+2022-01-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't use -Wmissing-prototypes with g++
+ This commit aims to not make use of -Wmissing-prototypes when
+ compiling with g++.
+
+ Use of -Wmissing-prototypes was added with this commit:
+
+ commit a0761e34f054767de6d6389929d27e9015fb299b
+ Date: Wed Mar 11 15:15:12 2020 -0400
+
+ gdb: enable -Wmissing-prototypes warning
+
+ Because clang can provide helpful warnings with this flag.
+ Unfortunately, g++ doesn't accept this flag, and will give this
+ warning:
+
+ cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
+
+ In theory the fact that this flag is not supported should be detected
+ by the configure check in gdbsupport/warning.m4, but for users of
+ ccache, this check doesn't work due to a long standing ccache issue:
+
+ https://github.com/ccache/ccache/issues/738
+
+ The ccache problem is that -W... options are reordered on the command
+ line, and so -Wmissing-prototypes is seen before -Werror. Usually
+ this doesn't matter, but the above warning (about the flag not being
+ valid) is issued before the -Werror flag is processed, and so is not
+ fatal.
+
+ There have been two previous attempts to fix this that I'm aware of.
+ The first is:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html
+
+ In this attempt, instead of just relying on a compile to check if a
+ flag is valid, the proposal was to both compile and link. As linking
+ doesn't go through ccache, we don't suffer from the argument
+ reordering problem, and the link phase will correctly fail when using
+ -Wmissing-prototypes with g++. The configure script will then disable
+ the use of this flag.
+
+ This approach was rejected, and the suggestion was to only add the
+ -Wmissing-prototypes flag if we are compiling with gcc.
+
+ The second attempt, attempts this approach, and can be found here:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html
+
+ This attempt only adds the -Wmissing-prototypes flag is the value of
+ GCC is not 'yes'. This feels like it is doing the right thing,
+ unfortunately, the GCC flag is really a 'is gcc like' flag, not a
+ strict, is gcc check. As such, GCC is set to 'yes' for clang, which
+ would mean the flag was not included for clang or gcc. The entire
+ point of the original commit was to add this flag for clang, so
+ clearly the second attempt is not sufficient either.
+
+ In this new attempt I have added gdbsupport/compiler-type.m4, this
+ file defines AM_GDB_COMPILER_TYPE. This macro sets the variable
+ GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future
+ the list of values might be extended to cover other compilers, if this
+ is ever useful.
+
+ I've then modified gdbsupport/warning.m4 to only add the problematic
+ -Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'.
+
+ I've tested this with both gcc and clang and see the expected results,
+ gcc no longer attempts to use the -Wmissing-prototypes flag, while
+ clang continues to use it.
+
+ When compiling using ccache, I am no longer seeing the warning.
+
+2022-01-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add some extra debug information to attach_command
+ While working on another patch I wanted to add some extra debug
+ information to the attach_command function. This required me to add a
+ new function to convert the thread_info::state variable to a string.
+
+ The new debug might be useful to others, and the state to string
+ function might be useful in other locations, so I thought I'd merge
+ it.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ Re: gas: add visibility support using GNU syntax on XCOFF
+ tc-ppc.c: In function 'ppc_comm':
+ tc-ppc.c:4560:40: error: 'visibility' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+
+ With that fixed we hit lots of segfaults in the ld testsuite.
+
+ PR 22085
+ bfd/
+ * xcofflink.c (xcoff_link_input_bfd): Don't segfault on NULL
+ sym_hash.
+ gas/
+ * config/tc-ppc.c (ppc_comm): Init visibility.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ dt-relr.exp --no-as-needed
+ Otherwise the very simple test may not be linked with libc.so at all,
+ and thus correctly have no version reference added. Causing failure
+ of the dt-relr-glibc-1b.so test.
+
+ * testsuite/ld-elf/dt-relr.exp: Link with --no-as-needed.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ Correct .relr.dyn nocombreloc script
+ * scripttempl/elf.sc (.relr.dyn): Don't depend on $COMBRELOC.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ testsuite supports_dt_relr
+ Tidy, and fix "FAIL: Build dt-relr-glibc-1b.so" on all non-x86
+ linux targets.
+
+ binutils/
+ * binutils-common.exp (supports_dt_relr): New proc.
+ ld/
+ * testsuite/config/default.exp (DT_RELR_LDFLAGS, NO_DT_RELR_LDFLAGS),
+ (DT_RELR_CC_LDFLAGS, NO_DT_RELR_CC_LDFLAGS): Use supports_dt_relr.
+ * testsuite/ld-elf/dt-relr.exp: Don't run unless supports_dt_relr.
+ * testsuite/ld-elf/dt-relr-1a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-1b.d: Likewise.
+ * testsuite/ld-elf/dt-relr-1c.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2b.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2c.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2d.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2e.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2f.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2g.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2h.d: Likewise.
+ * testsuite/ld-elf/dt-relr-3a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-3b.d: Likewise.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ Don't use C++ comments in assembly
+ It might seem to work, but only if '/' is a start of comment char.
+
+ * testsuite/ld-elf/dt-relr-1.s: Use # for comment.
+ * testsuite/ld-elf/dt-relr-2.s: Likewise.
+ * testsuite/ld-elf/dt-relr-3.s: Likewise.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ Move DT_RELR tag setting to elflink.c
+ This makes the code setting DT_RELR tags generally available. Many
+ targets will be able to use the defaults. Those that can't should set
+ up sh_entsize for .relr.dyn output section before reaching the dynamic
+ tag code in bfd_elf_final_link.
+
+ * elflink.c (bfd_elf_final_link): Set up DT_RELR tags and sh_entsize.
+ * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Don't do any
+ of that here.
+
+2022-01-13 Alan Modra <amodra@gmail.com>
+
+ Re: Set SEC_ELF_REVERSE_COPY earlier
+ Let's not rely on .init/.fini having relocs for the size sanity check.
+ This is mainly to squash reports of "my fuzzed object made ld hang".
+
+2022-01-13 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: make string[] type as char in gdb.base/charset.c
+ This reverts the commit ff656e2e1cb1 ("gdb: testsuite: fix failed
+ testcases in gdb.base/charset.exp").
+
+ The original test code has no problem. On an architecture where
+ char is signed, then both 'A' and ebcdic_us_string[7] will yield
+ -63, which makes the equality true. On an architecture where char
+ is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193,
+ which also makes the equality true.
+
+ The test cases only failed on LoongArch. The default type of char
+ is signed char on LoongArch, like x86-64. But when use gdb print
+ command on LoongArch, the default type of char is unsigned char,
+ this is wrong, I will look into it later, sorry for that.
+
+ On LoongArch:
+
+ $ cat test_char.c
+ #include <stdio.h>
+
+ int main()
+ {
+ char c1 = 193;
+ unsigned char c2 = 193;
+
+ printf("%d\n", c1);
+ printf("%d\n", c1 == c2);
+
+ return 0;
+ }
+ $ gcc test_char.c -o test_char
+ $ ./test_char
+ -63
+ 0
+
+ (gdb) set target-charset EBCDIC-US
+ (gdb) print 'A'
+ $1 = 193 'A'
+ (gdb) print /c 'A'
+ $2 = 193 'A'
+ (gdb) print /u 'A'
+ $3 = 193
+ (gdb) print /d 'A'
+ $4 = -63
+ (gdb) print /x 'A'
+ $5 = 0xc1
+
+2022-01-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-12 Carl Love <cel@us.ibm.com>
+
+ gdb Power 9 add test for HW watchpoint support.
+ The Power 9 processor revision 2.2 has HW watchpoint support disabled due
+ to a HW bug. The support is fixed in Power 9 processor revision 2.3. This
+ patch add a test to lib/gdb.exp for Power to determine if the processor
+ supports HW watchpoints or not. If the Power processor doesn't support HW
+ watchpoints the proceedure skip_hw_watchpoint_tests will return 1 to
+ disable the various HW watchpoint tests.
+
+ The patch has been tested on Power 9, processor revesions 2.2 and 2.3. The
+ patch has also been tested on Power 10. No regression test failures were
+ found.
+
+2022-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add gdb.host_charset function
+ We already have gdb.target_charset and gdb.target_wide_charset. This
+ commit adds gdb.host_charset along the same lines.
+
+2022-01-12 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb/testsuite: fix gdb.python/py-events.exp for finding process id
+ When executed with --target_board=native-extended-gdbserver, the
+ gdb.python/py-events.exp test errors out with
+
+ ERROR: tcl error sourcing /path/to/gdb/testsuite/gdb.python/py-events.exp.
+ ERROR: can't read "process_id": no such variable
+ while executing
+ "lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr""
+ (file "/path/to/gdb/testsuite/gdb.python/py-events.exp" line 103)
+ invoked from within
+ "source /path/to/gdb/testsuite/gdb.python/py-events.exp"
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel #0 source /path/to/gdb/testsuite/gdb.python/py-events.exp"
+ invoked from within
+ "catch "uplevel #0 source $test_file_name""
+
+ There are multiple problems around this:
+
+ 1. The process_id variable is not initialized to a default value.
+
+ 2. The test attempts to find the PID of the current thread, but the
+ regexp that it uses is not tailored for the output printed by the
+ remote target.
+
+ 3. The test uses "info threads" to find the current thread PID.
+ Using the "thread" command instead is simpler.
+
+ Fix these problems.
+
+2022-01-12 Tom Tromey <tromey@adacore.com>
+
+ Don't mention "serial" in target remote description
+ PR remote/9177 points out that "info files" mentions "serial" a couple
+ of times:
+
+ Remote serial target in gdb-specific protocol:
+ Debugging a target over a serial line.
+
+ However, often the remote target isn't really a serial connection.
+
+ It seems to me that this text could be a bit clearer; and furthermore
+ since "info files" prints the target's long description,
+ remote_target::files_info doesn't really add much and can simply be
+ removed.
+
+ Regression tested on x86-64 Fedora 34.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9177
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add glibc dependency for DT_RELR
+ When DT_RELR is enabled, to avoid random run-time crash with older glibc
+ binaries without DT_RELR support, add a GLIBC_ABI_DT_RELR symbol version,
+ which is provided by glibc with DT_RELR support, dependency on the shared
+ C library if it provides a GLIBC_2.XX symbol version.
+
+ bfd/
+
+ * elflink.c (elf_link_add_dt_relr_dependency): New function.
+ (bfd_elf_size_dynamic_sections): Call
+ elf_link_add_dt_relr_dependency if DT_RELR is enabled.
+
+ ld/
+
+ * ld.texi: Mention GLIBC_ABI_DT_RELR in -z pack-relative-relocs
+ entry.
+ * testsuite/ld-elf/dt-relr-glibc-1.c: New file.
+ * testsuite/ld-elf/dt-relr-glibc-1a.rd: Likewise.
+ * testsuite/ld-elf/dt-relr-glibc-1b.rd: Likewise.
+ * testsuite/ld-elf/dt-relr.exp: Likewise.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Add simple DT_RELR tests
+ * testsuite/ld-elf/dt-relr-1.s: New file.
+ * testsuite/ld-elf/dt-relr-1a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-1b.d: Likewise.
+ * testsuite/ld-elf/dt-relr-1c.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2.s: Likewise.
+ * testsuite/ld-elf/dt-relr-2a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2b.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2c.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2d.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2e.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2f.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2g.d: Likewise.
+ * testsuite/ld-elf/dt-relr-2h.d: Likewise.
+ * testsuite/ld-elf/dt-relr-3.s: Likewise.
+ * testsuite/ld-elf/dt-relr-3a.d: Likewise.
+ * testsuite/ld-elf/dt-relr-3b.d: Likewise.
+ * testsuite/ld-i386/dt-relr-1.s: Likewise.
+ * testsuite/ld-i386/dt-relr-1a.d: Likewise.
+ * testsuite/ld-i386/dt-relr-1b.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1a.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1b.d: Likewise.
+ * testsuite/ld-x86-64/dt-relr-1.s: Likewise.
+ * testsuite/ld-i386/i386.exp: Run dt-relr-1a and dt-relr-1b.
+ * testsuite/ld-x86-64/x86-64.exp: Run dt-relr-1a, dt-relr-1a-x32
+ dt-relr-1b and dt-relr-1b-x32.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Add DT_RELR support
+ DT_RELR is implemented with linker relaxation:
+
+ 1. During linker relaxation, we scan input relocations with the same
+ logic in relocate_section to determine if a relative relocation should
+ be generated and save the relative relocation candidate information for
+ sizing the DT_RELR section later after all symbols addresses can be
+ determined. For these relative relocations which can't be placed in
+ the DT_RELR section, they will be placed in the rela.dyn/rel.dyn
+ section.
+ 2. When DT_RELR is enabled, _bfd_elf_map_sections_to_segments calls a
+ backend function to size the DT_RELR section which will compute the
+ DT_RELR section size and tell ldelf_map_segments to layout sections
+ again when the DT_RELR section size has been increased.
+ 3. After regular symbol processing is finished, bfd_elf_final_link calls
+ a backend function to finish the DT_RELR section.
+
+ * elf32-i386.c (elf_i386_relocate_section): Don't generate
+ relative relocation when DT_RELR is enabled.
+ (elf_i386_finish_dynamic_symbol): Likewise.
+ * elf64-x86-64.c (elf_x86_64_relocate_section): Don't generate
+ relative relocation when DT_RELR is enabled.
+ (elf_x86_64_finish_dynamic_symbol): Likewise.
+ * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize
+ relative_r_type, relative_r_name, elf_append_reloc,
+ elf_write_addend and elf_write_addend_in_got.
+ (elf_x86_relative_reloc_record_add): New function.
+ (_bfd_x86_elf_link_relax_section): Likewise.
+ (elf64_dt_relr_bitmap_add): Likewise.
+ (elf32_dt_relr_bitmap_add): Likewise.
+ (_bfd_elf32_write_addend): Likewise.
+ (_bfd_elf64_write_addend): Likewise.
+ (elf_x86_size_or_finish_relative_reloc): Likewise.
+ (elf_x86_compute_dl_relr_bitmap): Likewise.
+ (elf_x86_write_dl_relr_bitmap): Likewise.
+ (elf_x86_relative_reloc_compare ): Likewise.
+ (_bfd_elf_x86_size_relative_relocs): Likewise.
+ (_bfd_elf_x86_finish_relative_relocs): Likewise.
+ (_bfd_x86_elf_size_dynamic_sections): Skip the .relr.dyn section.
+ (_bfd_x86_elf_finish_dynamic_sections): Convert 3 spare dynamic
+ tags to DT_RELR, DT_RELRSZ and for compact relative relocation.
+ * elfxx-x86.h (X86_64_GOT_TYPE_P): New.
+ (I386_GOT_TYPE_P): Likewise.
+ (X86_GOT_TYPE_P): Likewise.
+ (X86_64_RELATIVE_RELOC_TYPE_P): Likewise.
+ (I386_RELATIVE_RELOC_TYPE_P): Likewise.
+ (X86_RELATIVE_RELOC_TYPE_P): Likewise.
+ (X86_LOCAL_GOT_RELATIVE_RELOC_P): Likewise.
+ (I386_PCREL_TYPE_P): Likewise.
+ (X86_64_PCREL_TYPE_P): Likewise.
+ (X86_64_NEED_DYNAMIC_RELOC_TYPE_P): Rewrite.
+ (I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+ (GENERATE_DYNAMIC_RELOCATION_P): Also check rel_from_abs.
+ (elf_x86_link_hash_entry): Add got_relative_reloc_done.
+ (elf_x86_relative_reloc_record): New.
+ (elf_x86_relative_reloc_data): Likewise.
+ (elf_dt_relr_bitmap): Likewise.
+ (elf_x86_link_hash_table): Add dt_relr_bitmap, relative_reloc,
+ unaligned_relative_reloc, relative_r_type, relative_r_name,
+ elf_append_reloc, elf_write_addend, elf_write_addend_in_got and
+ relative_reloc_done.
+ (elf_x86_relative_reloc_done): New.
+ (relative_reloc_packed): Likewise.
+ (_bfd_x86_elf_link_relax_section): Likewise.
+ (_bfd_elf_x86_size_relative_relocs): Likewise.
+ (_bfd_elf_x86_finish_relative_relocs): Likewise.
+ (_bfd_elf32_write_addend): Likewise.
+ (_bfd_elf64_write_addend): Likewise.
+ (bfd_elf32_bfd_relax_section): Likewise.
+ (bfd_elf64_bfd_relax_section): Likewise.
+ (elf_backend_size_relative_relocs): Likewise.
+ (elf_backend_finish_relative_relocs): Likewise.
+ (elf_x86_allocate_local_got_info): Also allocate
+ relative_reloc_done.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Support DT_RELR in linker tests
+ Allow eabling and disabling DT_RELR in linker tests. Disable DT_RELR in
+ linker tests which don't expect DT_RELR in linker outputs.
+
+ binutils/
+
+ * testsuite/lib/binutils-common.exp (run_dump_test): Make
+ DT_RELR_LDFLAGS and NO_DT_RELR_LDFLAGS global.
+
+ ld/
+
+ * testsuite/config/default.exp (DT_RELR_LDFLAGS): New.
+ (DT_RELR_CC_LDFLAGS): Likewise.
+ (NO_DT_RELR_LDFLAGS): Likewise.
+ (NO_DT_RELR_CC_LDFLAGS): Likewise.
+ * testsuite/ld-elf/shared.exp: Pass $NO_DT_RELR_LDFLAGS to
+ linker for some tests.
+ * testsuite/ld-i386/export-class.exp: Likewise.
+ * testsuite/ld-i386/i386.exp: Likewise.
+ * testsuite/ld-i386/ibt-plt-2a.d: Pass $NO_DT_RELR_LDFLAGS to
+ linker.
+ * testsuite/ld-i386/ibt-plt-3a.d: Likewise.
+ * testsuite/ld-i386/ibt-plt-3c.d: Likewise.
+ * testsuite/ld-i386/pr26869.d: Likewise.
+ * testsuite/ld-i386/report-reloc-1.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-i386-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
+ * testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
+ * testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
+ * testsuite/ld-x86-64/bnd-branch-1-now.d: Likewise.
+ * testsuite/ld-x86-64/bnd-ifunc-1-now.d: Likewise.
+ * testsuite/ld-x86-64/bnd-ifunc-2-now.d: Likewise.
+ * testsuite/ld-x86-64/bnd-ifunc-2.d: Likewise.
+ * testsuite/ld-x86-64/bnd-plt-1-now.d: Likewise.
+ * testsuite/ld-x86-64/bnd-plt-1.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise.
+ * testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
+ * testsuite/ld-x86-64/ilp32-4.d: Likewise.
+ * testsuite/ld-x86-64/load1c.d: Likewise.
+ * testsuite/ld-x86-64/load1d.d: Likewise.
+ * testsuite/ld-x86-64/pr13082-2b.d: Likewise.
+ * testsuite/ld-x86-64/pr14207.d: Likewise.
+ * testsuite/ld-x86-64/pr18176.d: Likewise.
+ * testsuite/ld-x86-64/pr19162.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2d.d: Likewise.
+ * testsuite/ld-x86-64/pr19636-2l.d: Likewise.
+ * testsuite/ld-x86-64/pr20253-1d.d: Likewise.
+ * testsuite/ld-x86-64/pr20253-1f.d: Likewise.
+ * testsuite/ld-x86-64/pr20253-1j.d: Likewise.
+ * testsuite/ld-x86-64/pr20253-1l.d: Likewise.
+ * testsuite/ld-x86-64/report-reloc-1-x32.d: Likewise.
+ * testsuite/ld-x86-64/report-reloc-1.d: Likewise.
+ * testsuite/ld-x86-64/export-class.exp (x86_64_export_class_test):
+ Pass $NO_DT_RELR_LDFLAGS to linker.
+ * testsuite/ld-x86-64/x86-64.exp: Pass $NO_DT_RELR_LDFLAGS to
+ linker for some tests.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Add size_relative_relocs and finish_relative_relocs
+ On some targets, the DT_RELR section size can be computed only after all
+ symbols addresses can be determined. Set the preliminary DT_RELR section
+ size before mapping sections to segments and set the final DT_RELR section
+ size after regular symbol processing is done.
+
+ * elf-bfd.h (elf_backend_data): Add size_relative_relocs and
+ finish_relative_relocs.
+ * elf.c (_bfd_elf_map_sections_to_segments): Call
+ size_relative_relocs if DT_RELR is enabled.
+ * elflink.c (bfd_elf_final_link): Call finish_relative_relocs
+ after regular symbol processing is finished if DT_RELR is enabled.
+ * elfxx-target.h (elf_backend_size_relative_relocs): New.
+ (elf_backend_finish_relative_relocs): Likewise.
+ (elfNN_bed): Add elf_backend_size_relative_relocs and
+ elf_backend_finish_relative_relocs.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Initial DT_RELR support
+ Add a -z pack-relative-relocs option to enable DT_RELR and create a
+ relr.dyn section for DT_RELR. DT_RELR is implemented with the linker
+ relaxation infrastructure, but it doesn't require the --relax option
+ enabled. -z pack-relative-relocs implies -z combreloc. -z nocombreloc
+ implies -z nopack-relative-relocs.
+
+ -z pack-relative-relocs is chosen over the similar option in lld,
+ --pack-dyn-relocs=relr, to implement a glibc binary lockout mechanism
+ with a special glibc version symbol, to avoid random crashes of DT_RELR
+ binaries with the existing glibc binaries.
+
+ bfd/
+
+ * elf-bfd.h (elf_link_hash_table): Add srelrdyn.
+ * elflink.c (_bfd_elf_link_create_dynamic_sections): Create a
+ .relr.dyn section for DT_RELR.
+
+ include/
+
+ * bfdlink.h (bfd_link_info): Add enable_dt_relr.
+
+ ld/
+
+ * News: Mention -z pack-relative-relocs and
+ -z nopack-relative-relocs.
+ * ld.texi: Document -z pack-relative-relocs and
+ -z nopack-relative-relocs.
+ * ldelf.c (ldelf_after_parse): Disable DT_RELR if not building
+ PIE nor shared library. Add 3 spare dynamic tags for DT_RELR,
+ DT_RELRSZ and DT_RELRENT.
+ * ldlang.c (lang_relax_sections): Also enable relaxation if
+ DT_RELR is enabled.
+ * emulparams/elf32_x86_64.sh: Source dt-relr.sh.
+ * emulparams/elf_i386.sh: Likewise.
+ * emulparams/elf_x86_64.sh: Likewise.
+ * emulparams/dt-relr.sh: New file.
+ * scripttempl/elf.sc: Support .relr.dyn.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Pass need_layout to _bfd_elf_map_sections_to_segments
+ On some targets, the DT_RELR section size can be computed only after all
+ symbols addresses can be determined. Update ldelf_map_segments to pass
+ need_layout to _bfd_elf_map_sections_to_segments which will size DT_RELR
+ section and set need_layout to true if the DT_RELR section size is changed.
+
+ bfd/
+
+ * elf-bfd.h (_bfd_elf_map_sections_to_segments): Add a bool
+ pointer argument.
+ * elf.c (_bfd_elf_map_sections_to_segments): Add a bool pointer
+ argument to indicate if section layout needs update.
+ (assign_file_positions_for_load_sections): Pass NULL to
+ _bfd_elf_map_sections_to_segments.
+ * elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Pass
+ NULL to _bfd_elf_map_sections_to_segments.
+
+ ld/
+
+ * ldelfgen.c (ldelf_map_segments): Pass &need_layout to
+ _bfd_elf_map_sections_to_segments.
+
+2022-01-12 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Add .relr.dyn to special_sections_r
+ * elf.c (special_sections_r): Add .relr.dyn.
+
+2022-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add 'maint set/show gnu-source-highlight enabled' command
+ In a later commit I want to address an issue with the Python pygments
+ based code styling solution. As this approach is only used when the
+ GNU Source Highlight library is not available, testing bugs in this
+ area can be annoying, as it requires GDB to be rebuilt with use of GNU
+ Source Highlight disabled.
+
+ This commit adds a pair of new maintenance commands:
+
+ maintenance set gnu-source-highlight enabled on|off
+ maintenance show gnu-source-highlight enabled
+
+ these commands can be used to disable use of the GNU Source Highlight
+ library, allowing me, in a later commit, to easily test bugs that
+ would otherwise be masked by GNU Source Highlight being used.
+
+ I made this a maintenance command, rather than a general purpose
+ command, as it didn't seem like this was something a general user
+ would need to adjust. We can always convert the maintenance command
+ to a general command later if needed.
+
+ There's no test for this here, but this feature will be used in a
+ later commit.
+
+2022-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: erase items from the source_cache::m_offset_cache
+ The source_cache class has two member variables m_source_map, which
+ stores the file contents, and m_offset_cache, which stores offsets
+ into the file contents.
+
+ As source files are read the contents of the file, as well as the
+ offset data, are stored in the cache using these two member variables.
+
+ Whenever GDB needs either the files contents, or the offset data,
+ source_cache::ensure is called. This function looks for the file in
+ m_source_map, and if it's found then this implies the file is also in
+ m_offset_cache, and we're done.
+
+ If the file is not in m_source_map then GDB calls
+ source_cache::get_plain_source_lines to open the file and read its
+ contents. ::get_plain_source_lines also calculates the offset data,
+ which is then inserted into m_offset_cache.
+
+ Back in ::ensure, the file contents are added into m_source_map. And
+ finally, if m_source_map contains more than MAX_ENTRIES, an entry is
+ removed from m_source_map.
+
+ The problem is entries are not removed from m_offset_cache at the same
+ time.
+
+ This means that if a program contains enough source files, GDB will
+ hold at most MAX_ENTRIES cached source file contents, but can contain
+ offsets data for every source file.
+
+ Now, the offsets data is going to be smaller than the cached file
+ contents, so maybe there's no harm here. But, when we reload the file
+ contents we always recalculate the offsets data. And, when we
+ ::get_line_charpos asking for offset data we still call ::ensure which
+ will ends up loading and caching the file contents.
+
+ So, given the current code does the work of reloading the offset data
+ anyway, we may as well save memory by capping m_offset_cache to
+ MAX_ENTRIES just like we do m_source_map.
+
+ That's what this commit does.
+
+ There should be no user visible changes after this commit, except for
+ ever so slightly lower memory usage in some cases.
+
+2022-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: new 'maint flush source-cache' command
+ This commit adds a new 'maint flush source-cache' command, this
+ flushes the cache of source file contents.
+
+ After flushing GDB is forced to reread source files the next time any
+ source lines are to be displayed.
+
+ I've added a test for this new feature. The test is a little weird,
+ in that it modifies a source file after compilation, and makes use of
+ the cache flush so that the changes show up when listing the source
+ file. I'm not sure when such a situation would ever crop up in real
+ life, but maybe we can imagine such cases.
+
+ In reality, this command is useful for testing the syntax highlighting
+ within GDB, we can adjust the syntax highlighting settings, flush the
+ cache, and then get the file contents re-highlighted using the new
+ settings.
+
+2022-01-12 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: rename lin-lwp to linux-nat in set/show debug
+ Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug
+ lin-lwp' to 'show debug linux-nat'.
+
+ I've updated the documentation and help text to match, as well as
+ making it clear that the debug that is coming out relates to all
+ aspects of Linux native inferior support, not just the LWP aspect of
+ it.
+
+ The boundary between general "native" target debug, and the lwp
+ specific part of that debug was always a little blurry, but the actual
+ debug variable inside GDB is debug_linux_nat, and the print routine
+ linux_nat_debug_printf, is used throughout the linux-nat.c file, not
+ just for lwp related debug, so the new name seems to make more sense.
+
+2022-01-12 Clément Chigot <clement.chigot@atos.net>
+
+ ld: add hidden and internal visibility support for XCOFF
+ This patch adds a primary support for hidden and internal visibility in
+ GNU linker for XCOFF format.
+ The protected visibility isn't yet supported.
+
+ PR 22085
+
+ bfd/ChangeLog:
+
+ * xcofflink.c (xcoff_dynamic_definition_p): Add hidden
+ and internal visibility support.
+ (xcoff_link_add_symbols): Likewise.
+ (xcoff_auto_export_p): Likewise.
+ (bfd_xcoff_export_symbol): Likewise.
+ (xcoff_link_input_bfd): Likewise.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-vsb/main.c: Adapt for XCOFF.
+ * testsuite/ld-vsb/sh1.c: Likewse.
+ * testsuite/ld-vsb/vsb.exp: Likewise.
+ * testsuite/ld-vsb/visibility-1-xcoff-32.d: New test.
+ * testsuite/ld-vsb/visibility-1-xcoff-64.d: New test.
+ * testsuite/ld-vsb/visibility-2-xcoff-32.d: New test.
+ * testsuite/ld-vsb/visibility-2-xcoff-64.d: New test.
+ * testsuite/ld-vsb/xcoffvsb.dat: New test.
+
+2022-01-12 Clément Chigot <clement.chigot@atos.net>
+
+ ld/testsuite: prepare ld-elfvsb to support XCOFF
+ A following patch will add visibility support in ld for XCOFF. Thus,
+ ld-elfvsb is renamed ld-vsb and a suffix is added to files targeting only
+ ELF format.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-elfvsb: rename as ld-vsb.
+ * testsuite/ld-elfvsb/hidden0.d: move to ld-vsb and rename with
+ suffix -elf.d.
+ * testsuite/ld-elfvsb/hidden1.d: Likewise.
+ * testsuite/ld-elfvsb/hidden2.d: Likewise.
+ * testsuite/ld-elfvsb/internal0.d: Likewise.
+ * testsuite/ld-elfvsb/internal1.d: Likewise.
+ * testsuite/ld-elfvsb/protected0.d: Likewise.
+ * testsuite/ld-elfvsb/protected1.d: Likewise.
+
+2022-01-12 Clément Chigot <clement.chigot@atos.net>
+
+ gas: add visibility support using GNU syntax on XCOFF
+ In order to ease port of GNU assembly code and especially ld testsuite,
+ this patch allows XCOFF to accept the usual GNU syntax for visibility.
+
+ PR 22085
+
+ gas/ChangeLog:
+
+ * config/tc-ppc.c (ppc_GNU_visibility): New function.
+ * testsuite/gas/ppc/aix.exp: Add new tests.
+ * testsuite/gas/ppc/xcoff-visibility-2-32.d: New test.
+ * testsuite/gas/ppc/xcoff-visibility-2-64.d: New test.
+ * testsuite/gas/ppc/xcoff-visibility-2.s: New test.
+
+2022-01-12 Clément Chigot <clement.chigot@atos.net>
+
+ gas: add visibility support for XCOFF
+ XCOFF assembly defines the visibility using an additional argument
+ on several pseudo-ops: .globl, .weak, .extern and .comm.
+ This implies that .globl and .weak syntax is different than the
+ usual GNU syntax. But we want to provide compatibility with AIX
+ assembler, especially because GCC is generating the visibility
+ using this XCOFF syntax.
+
+ PR 22085
+
+ bfd/ChangeLog:
+
+ * coffcode.h (coff_write_object_contents): Change XCOFF header
+ vstamp field to 2.
+ * coffgen.c (coff_print_symbol): Increase the size for n_type.
+
+ gas/ChangeLog:
+
+ * config/tc-ppc.c (ppc_xcoff_get_visibility): New function.
+ (ppc_globl): New function.
+ (ppc_weak): New function.
+ (ppc_comm): Add visibility field support.
+ (ppc_extern): Likewise.
+ * testsuite/gas/all/cofftag.d: Adjust to new n_type size
+ providing by objdump.
+ * testsuite/gas/ppc/test1xcoff32.d: Likewise.
+ * testsuite/gas/ppc/aix.exp: Add new tests.
+ * testsuite/gas/ppc/xcoff-visibility-1-32.d: New test.
+ * testsuite/gas/ppc/xcoff-visibility-1-64.d: New test.
+ * testsuite/gas/ppc/xcoff-visibility-1.s: New test.
+
+ include/ChangeLog:
+
+ * coff/internal.h (SYM_V_INTERNAL, SYM_V_HIDDEN,
+ SYM_V_PROTECTED, SYM_V_EXPORTED, SYM_V_MASK): New defines.
+ * coff/xcoff.h (struct xcoff_link_hash_entry): Add visibility
+ field.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-pe/pr19803.d: Adjust to new n_type size
+ providing by objdump.
+
+2022-01-12 Hans-Peter Nilsson <hp@axis.com>
+
+ objdump, readelf: Emit "CU:" format only when wide output is requested
+ As pre-approved by Alan in
+ https://sourceware.org/pipermail/binutils/2021-September/118019.html
+ and I believe people have run into getting testsuite failures for
+ test-environments with "long" directory names, at least once more
+ since that time. Enough. I grepped the gas, binutils and ld
+ testsuites for "CU:" to catch target-specific occurrences, but I
+ noticed none. I chose to remove "CU:" on the objdump tests instead of
+ changing options to get the wide format, so as to keep the name of the
+ test consistent with actual options; but added it to the readelf
+ options for the gas test as I believe the "CU:" format is preferable.
+
+ Tested for cris-elf and native x86_64-pc-linux-gnu.
+
+ binutils:
+ * dwarf.c (display_debug_lines_decoded): Don't check the
+ string length of the directory, instead emit the "CU: dir/name"
+ format only if wide output is requested.
+ * testsuite/binutils-all/dw5.W, testsuite/binutils-all/objdump.WL:
+ Adjust accordingly.
+
+ gas:
+ * testsuite/gas/elf/dwarf-5-loc0.d: Add -W to readelf options.
+
+2022-01-12 Alan Modra <amodra@gmail.com>
+
+ Set SEC_ELF_REVERSE_COPY earlier
+ For the sake of DT_RELR.
+
+ bfd/
+ * elflink.c (elf_link_input_bfd): Don't set SEC_ELF_REVERSE_COPY
+ here. Move sanity checks to reverse copying code.
+ ld/
+ * ldlang.c (lang_add_section): Set SEC_ELF_REVERSE_COPY for
+ .ctors/.dtors in .init_array/.fini_array.
+
+2022-01-12 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: fix wrong comment in gdb.base/charset.c
+ In gdb/testsuite/gdb.base/charset.c, use "IBM1047" instead of "EBCDIC"
+ to fix the wrong comment.
+
+2022-01-12 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: fix failed testcases in gdb.base/charset.exp
+ In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127
+ when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is
+ char, this will change the value due to sign extension.
+
+ For example, ebcdic_us_string[7] will be -63 instead of the original 193 in
+ EBCDIC-US.
+
+ Make the type of string[] as unsigned char to fix the following six failed
+ testcases:
+
+ $ grep FAIL gdb/testsuite/gdb.sum
+ FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US
+ FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US
+ FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US
+ FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047
+ FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047
+ FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047
+
+2022-01-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-11 Fangrui Song <maskray@google.com>
+
+ ar: Add --thin for creating thin archives
+ In many ar implementations (FreeBSD, elfutils, etc), -T has the X/Open
+ System Interface specified semantics. Therefore -T for thin archives is
+ not recommended for portability. -T is deprecated without diagnostics.
+
+ PR binutils/28759
+ * ar.c (long_options): Add --thin.
+ (usage) Add --thin. Deprecate -T without diagnostics.
+ * doc/binutils.texi: Add doc.
+ * NEWS: Mention --thin.
+ * binutils/testsuite/binutils-all/ar.exp: Add tests.
+
+2022-01-11 Martin Storsj <martin@martin.st>
+
+ Fix multiple problems with DLL generation.
+ ld * pe-dll.c (make_head): Prefix the symbol name with the dll name.
+ (make_tail, make_one, make_singleton_name_thunk): Likewise.
+ (make_import_fixup_entry, make_runtime_pseudo_reloc): Likewise.
+ (pe_create_runtime_relocator_reference): Likewise.
+ (pe_dll_generate_implib): Set dll_symname_len.
+ (pe_process_import_defs): Likewise.
+
+ binutils
+ * dlltool.c (main): If a prefix has not been provided, attempt to
+ use a deterministic one based upon the dll name.
+
+2022-01-11 Jan Beulich <jbeulich@suse.com>
+
+ gas/doc: mention quoted symbol names
+
+2022-01-11 Andrew Burgess <aburgess@redhat.com>
+
+ gdbsupport: regenerate Makefile.in
+ I had cause to regenerate gdbsupport/Makefile.in, and noticed some
+ unexpected changes in the copyright header dates.
+
+ I suspect that this was caused by the end of year date range update
+ process.
+
+ The Makefile.in contains two date ranges. The first range appears to
+ be the date range for the version of automake being used, that is the
+ range runs up to 2017 only, when automake 1.15.1 was released.
+
+ The second date range in Makefile.in represents the date range for the
+ generated file, and so, now runs up to 2022.
+
+ Anyway, this is the result of running autoreconf (using automake
+ 1.15.1) in the gdbsupport directory.
+
+2022-01-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-10 Clément Chigot <clement.chigot@atos.net>
+
+ XCOFF: add support for TLS relocations on hidden symbols
+ This patch adds support for TLS relocation targeting C_HIDEXT symbols.
+ In gas, TLS relocations, except R_TLSM and R_TLMSL, must keep the value
+ of their target symbol.
+ In ld, it simply ensures that internal TLS symbols are added to the
+ linker hash table for xcoff_reloc_type_tls.
+
+ It also improves the tests made by both.
+
+ bfd/ChangeLog:
+
+ * coff-rs6000.c (xcoff_howto_table): Fix name of R_TLSML.
+ (xcoff_reloc_type_tls): Replace the error when h is NULL by
+ an assert.
+ (xcoff_complain_overflow_unsigned_func): Adjust comments.
+ * coff64-rs6000.c (xcoff64_howto_table): Fix name of R_TLSML.
+ * xcofflink.c (xcoff_link_add_symbols_to_hash_table): New
+ function.
+ (xcoff_link_add_symbols): Add C_HIDEXT TLS symbols to the linker
+ hash table.
+
+ gas/ChangeLog:
+
+ * config/tc-ppc.c (md_apply_fix): Enable support for TLS
+ relocation over internal symbols.
+ * testsuite/gas/ppc/aix.exp: Replace xcoff-tlms by xcoff-tls.
+ * testsuite/gas/ppc/xcoff-tlsm-32.d: Removed.
+ * testsuite/gas/ppc/xcoff-tlsm-64.d: Removed.
+ * testsuite/gas/ppc/xcoff-tlsm.s: Removed.
+ * testsuite/gas/ppc/xcoff-tls-32.d: New test.
+ * testsuite/gas/ppc/xcoff-tls-64.d: New test.
+ * testsuite/gas/ppc/xcoff-tls.s: New test.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-powerpc/aix52.exp: Improve aix-tls-reloc test.
+ * testsuite/ld-powerpc/aix-tls-reloc.s: Likewise.
+ * testsuite/ld-powerpc/aix-tls-reloc-32.d: Removed.
+ * testsuite/ld-powerpc/aix-tls-reloc-64.d: Removed.
+ * testsuite/ld-powerpc/aix-tls-reloc-32.dd: New test.
+ * testsuite/ld-powerpc/aix-tls-reloc-32.dt: New test.
+ * testsuite/ld-powerpc/aix-tls-reloc-64.dd: New test.
+ * testsuite/ld-powerpc/aix-tls-reloc-64.dt: New test.
+
+2022-01-10 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: add Tiezhu Yang to MAINTAINERS
+
+2022-01-10 Tom Tromey <tom@tromey.com>
+
+ Reduce use of unfiltered output in Darwin code
+ The Darwin code uses unfiltered output liberally. This patch changes
+ this code to send some output to gdb_stdlog (in some cases via the use
+ of debug_prefixed_printf_cond_nofunc), or to gdb_stderr, or to simply
+ switch to filtered output.
+
+ Note that I didn't switch inferior_debug to use
+ debug_prefixed_printf_cond_nofunc, because that would affect the
+ output by removing the information about the inferior. I wasn't sure
+ if this was important or not, so I left it in.
+
+ v2 of this patch uses warning rather than prints to gdb_stderr, and
+ removes some trailing whitespace.
+
+ I can't compile this patch, so it's "best effort".
+
+2022-01-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/hurd: handle inferiors exiting
+ While testing on GNU/Hurd (i386) I noticed that GDB crashes when an
+ inferior exits, with this error:
+
+ inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
+
+ The problem appears to be in gnu_nat_target::wait.
+
+ We always set inferior_ptid to null_ptid before calling target_wait,
+ this has been the case since the multi-target changes were made to GDB
+ in commit:
+
+ commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
+ Date: Fri Jan 10 20:06:08 2020 +0000
+
+ Multi-target support
+
+ With follow up changes in commit:
+
+ commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
+ Date: Thu Jan 30 14:35:40 2020 +0000
+
+ gdb/remote: Restore support for 'S' stop reply packet
+
+ Unfortunately, the GNU/Hurd target is still relying on the value of
+ inferior_ptid in the case where an inferior exits - we return the
+ value of inferior_ptid as the pid of the process that exited. This
+ was fine in the single target world, where inferior_ptid identified
+ the one running inferior, but this is no longer good enough.
+
+ Instead, we should return a ptid containing the pid of the process
+ that exited, as obtained from the wait event, and this is what this
+ commit does.
+
+ I've not run the full testsuite on GNU/Hurd as there appear to be lots
+ of other issues with this target that makes running the full testsuite
+ very painful, but I think this looks like a small easy improvement.
+
+2022-01-08 Tom Tromey <tom@tromey.com>
+
+ Add explicit check for nullptr to target_announce_attach
+ Lancelot pointed out that target_announce_attach was missing an
+ explicit check against nullptr. This patch adds it.
+
+2022-01-08 Hannes Domani <ssbssa@yahoo.de>
+
+ Add _sigsys info to siginfo struct
+ This patch adds information about _sigsys structure from newer
+ kernels, so that $_siginfo decoding can show information about
+ _sigsys, making it easier for developers to debug seccomp failures.
+ Requested in PR gdb/24283.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283
+
+2022-01-08 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ gdb: testsuite: show print array-indexes after set in arrayidx.exp
+ Add "show print array-indexes" testcases after set print array-indexes
+ to off or on.
+
+ Without this patch:
+
+ PASS: gdb.base/arrayidx.exp: set print array-indexes to off
+ PASS: gdb.base/arrayidx.exp: print array with array-indexes off
+ PASS: gdb.base/arrayidx.exp: set print array-indexes to on
+ PASS: gdb.base/arrayidx.exp: print array with array-indexes on
+
+ With this patch:
+
+ PASS: gdb.base/arrayidx.exp: set print array-indexes to off
+ PASS: gdb.base/arrayidx.exp: show print array-indexes is off
+ PASS: gdb.base/arrayidx.exp: print array with array-indexes off
+ PASS: gdb.base/arrayidx.exp: set print array-indexes to on
+ PASS: gdb.base/arrayidx.exp: show print array-indexes is on
+ PASS: gdb.base/arrayidx.exp: print array with array-indexes on
+
+2022-01-08 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Extract _bfd_elf_link_iterate_on_relocs
+ DT_RELR encodes consecutive R_*_RELATIVE relocations in GOT (the global
+ offset table) and data sections in a compact format:
+
+ https://groups.google.com/g/generic-abi/c/bX460iggiKg
+
+ On some targets, R_*_RELATIVE relocations are counted and the GOT offsets
+ are allocated when setting the dynamic section sizes after seeing all
+ relocations. R_*_RELATIVE relocations are generated while relocating
+ sections after section layout has been finalized.
+
+ To prepare for DT_RELR implementation on these targets, extract
+ _bfd_elf_link_iterate_on_relocs from _bfd_elf_link_check_relocs so
+ that a backend can scan relocations in elf_backend_always_size_sections
+
+ For x86 targets, the old check_relocs is renamed to scan_relocs and a
+ new check_relocs is added to chek input sections and create dynamic
+ relocation sections so that they will be mapped to output sections.
+ scan_relocs is now called from elf_backend_always_size_sections.
+
+ Since relocations are scanned after __start, __stop, .startof. and
+ .sizeof. symbols have been finalized on x86, __[start|stop]_SECNAME for
+ --gc-sections -z start-stop-gc are now zero when all SECNAME sections
+ been garbage collected. This is no need for elf_x86_start_stop_gc_p.
+
+ bfd/
+
+ * elf-bfd.h (_bfd_elf_link_iterate_on_relocs): New.
+ * elf32-i386.c (elf_i386_convert_load_reloc): Don't call
+ elf_x86_start_stop_gc_p.
+ (elf_i386_check_relocs): Renamed to ...
+ (elf_i386_scan_relocs): This. Don't call
+ _bfd_elf_make_dynamic_reloc_section.
+ (elf_i386_always_size_sections): New.
+ (elf_backend_check_relocs): Removed.
+ (elf_backend_always_size_sections): New.
+ * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Don't call
+ elf_x86_start_stop_gc_p.
+ (elf_x86_64_check_relocs): Renamed to ...
+ (elf_x86_64_scan_relocs): This. Don't call
+ _bfd_elf_make_dynamic_reloc_section.
+ (elf_x86_64_always_size_sections): New.
+ (elf_backend_check_relocs): Removed.
+ (elf_backend_always_size_sections): New.
+ * elflink.c (elf_link_check_or_scan_relocs):
+ New. Extracted from _bfd_elf_link_check_relocs.
+ (_bfd_elf_link_check_relocs): Call elf_link_check_or_scan_relocs.
+ * elfxx-x86.c (_bfd_x86_elf_check_relocs): New.
+ * elfxx-x86.h (X86_64_NEED_DYNAMIC_RELOC_TYPE_P): New.
+ (I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+ (X86_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+ (_bfd_x86_elf_check_relocs): Likewise.
+ (elf_backend_check_relocs): Likewise.
+ (elf_backend_always_size_sections): Removed.
+ (elf_x86_start_stop_gc_p): Likewise.
+
+ ld/
+
+ * testsuite/ld-i386/pr27491-1a.d: Updated.
+ * testsuite/ld-x86-64/pr27491-1a.d: Likewise.
+
+2022-01-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.mi/mi-catch-load.exp
+ When I run the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.mi/mi-catch-load.exp ...
+ DUPLICATE: gdb.mi/mi-catch-load.exp: breakpoint at main
+ DUPLICATE: gdb.mi/mi-catch-load.exp: mi runto main
+
+ Fix by grouping the various phases in with_test_prefix blocks. Since
+ the tests now have a prefix, remove the manually written prefixes in
+ testnames.
+
+ Also change some messages with the pattern "(timeout) $testname" into
+ "$estname (timeout)" since tools will handle this as $testname[1] (which
+ is what we want in this particular scenario).
+
+ Tested on x86_64-linux.
+
+ [1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.threads/staticthreads.ex
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.threads/staticthreads.exp ...
+ DUPLICATE: gdb.threads/staticthreads.exp: couldn't compile staticthreads.c: unrecognized error
+
+ Fix by using foreach_with_prefix instead of foreach when preparing the
+ test case.
+
+ Testeed on x86_64-linux both in a setup where the test fails to prepare
+ and in a setup where the test fails to setup.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.mi/mi-language.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.mi/mi-language.exp ...
+ DUPLICATE: gdb.mi/mi-language.exp: set lang ada
+
+ This is due to an erroneous explicit test name. This explicit test name
+ also happens to be useless (at least it would have been if it was
+ correct) since it only repeats the command, so just remove the explicit
+ test name and let the command be used as default test name. Also remove
+ explicit test name at another location in the file since it also just
+ repeat the command.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop-exit.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.mi/mi-nonstop-exit.exp ...
+ DUPLICATE: gdb.mi/mi-nonstop-exit.exp: breakpoint at main
+ DUPLICATE: gdb.mi/mi-nonstop-exit.exp: mi runto main
+
+ This test runs the same sequence of operations twice. Refactor the code
+ by running both of those sequences within a foreach_with_prefix block to
+ ensure that the commands have unique test names.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.mi/mi-nonstop.exp ...
+ DUPLICATE: gdb.mi/mi-nonstop.exp: check varobj, w1, 1
+ DUPLICATE: gdb.mi/mi-nonstop.exp: stacktrace of stopped thread
+
+ Fix by adjusting the problematic test names.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.mi/mi-nsthrexec.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.mi/mi-nsthrexec.exp ...
+ DUPLICATE: gdb.mi/mi-nsthrexec.exp: breakpoint at main
+
+ Fix by adjusting the duplicated test name.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/watchpoints.exp
+ When running the testsuite, I have:
+
+ Running ../gdb/testsuite/gdb.base/watchpoints.exp ...
+ DUPLICATE: gdb.base/watchpoints.exp: watchpoint hit, first time
+
+ Fix by adjusting the test names where appropriate.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/nested-subp2.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/nested-subp2.exp ...
+ DUPLICATE: gdb.base/nested-subp2.exp: continue to the STOP marker
+ DUPLICATE: gdb.base/nested-subp2.exp: print c
+ DUPLICATE: gdb.base/nested-subp2.exp: print count
+
+ Fix by using with_test_prefix to differentiate the test that are
+ performed at different points during the execution of the debuggee.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/call-signal-resume.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/call-signal-resume.exp ...
+ DUPLICATE: gdb.base/call-signal-resume.exp: dummy stack frame number
+ DUPLICATE: gdb.base/call-signal-resume.exp: set confirm off
+ DUPLICATE: gdb.base/call-signal-resume.exp: return
+
+ This is due to the fact that a pattern was probably copy/pasted to
+ re-use the logic while not adjusting the test names to avoid the
+ duplication.
+
+ Fix by removing the redundant tests ('set confirm off' only needs to be
+ used once) and adjusting the test names where appropriate.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/pointers.exp
+ When I run the testsuite, I have :
+
+ Running .../gdb/testsuite/gdb.base/pointers.exp ...
+ DUPLICATE: gdb.base/pointers.exp: pointer assignment
+
+ Fix by placing the sections with duplication in with_test_prefix blocks.
+ This removes the duplication and gives a better organization the file.
+
+ Tested on x86_64-linux.
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/unload.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/unload.exp ...
+ DUPLICATE: gdb.base/unload.exp: continuing to unloaded libfile
+
+ Fix by adjusting the test name.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/define-prefix.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/define-prefix.exp ...
+ DUPLICATE: gdb.base/define-prefix.exp: define user command: ghi-prefix-cmd
+
+ Fix by adjusting test names.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/funcargs.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/funcargs.exp ...
+ DUPLICATE: gdb.base/funcargs.exp: run to call2a
+
+ Fix by using proc_with_prefix instead on plain proc to create logical
+ function blocks.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/shlib-call.exp
+ When I run the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/shlib-call.exp ...
+ DUPLICATE: gdb.base/shlib-call.exp: print g
+ DUPLICATE: gdb.base/shlib-call.exp: set print sevenbit-strings
+ DUPLICATE: gdb.base/shlib-call.exp: set print address off
+ DUPLICATE: gdb.base/shlib-call.exp: set width 0
+ DUPLICATE: gdb.base/shlib-call.exp: continue until exit
+
+ Fix by adjusting the test names when required, and by removing
+ un-necessary commands.
+
+ While at it, do some cleanup:
+ - Replace an explicit GDB restart sequence with a call to clean_restart.
+ - Remove trailing whitespaces.
+ - Use $gdb_test_name in gdb_test_multiple.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/set-cfd.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/set-cwd.exp ...
+ DUPLICATE: gdb.base/set-cwd.exp: test_cwd_reset: continue to breakpoint: break-here
+
+ Fix by moving the tests after the 'runto_main' within the same
+ with_test_prefix scope.
+
+ While at it, I fix some indentation issues.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/exprs.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/exprs.exp ...
+ DUPLICATE: gdb.base/exprs.exp: \$[0-9]* = red (setup)
+
+ Fix by using with_test_prefix where appropriate.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/readline.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/readline.exp ...
+ DUPLICATE: gdb.base/readline.exp: Simple operate-and-get-next - final prompt
+
+ Fix by adjusting the prefix given to the second 'simple' call to
+ operate_and_get_next.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/pretty-array.exp
+ When I run the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/pretty-array.exp ...
+ DUPLICATE: gdb.base/pretty-array.exp: print nums
+ DUPLICATE: gdb.base/pretty-array.exp: print nums
+
+ Fix by giving a name to the test cases.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/ui-redirect.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/ui-redirect.exp ...
+ DUPLICATE: gdb.base/ui-redirect.exp: redirect while already logging: set logging redirect off
+
+ Fix by moving the first 'set logging redirect off' to the end of the
+ previous [with_test_prefix] test block. The statement's purpose is to
+ clean the on flag set in this previous block, so moving it there makes
+ sense and does not change the sequence of commands in the test file.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: completion-support.exp: improve leading whitespace support
+ There is a expect support library in the source tree designed to help
+ developers test the auto-completion capabilities of GDB.
+
+ One of the functions is test_gdb_complete_unique_re. It is used
+ (usually indirectly via test_gdb_complete_unique) to test that a given
+ input line is completed as a given output line. The test checks for two
+ ways to do the completion: using tab-completion, or using the
+ 'complete' command. To do this, calls to two dedicated functions are
+ performed. If we omit few details, we can consider that a call to
+
+ test_gdb_complete_unique $input $expected
+
+ is equivalent to the two following calls:
+
+ test_gdb_complete_tab_unique $input $expected
+ test_gdb_complete_cmd_unique $input $expected
+
+ When using the tab-completion, everything works as expected, but some
+ care must be taken when using the 'complete' command if the given input
+ has leading whitespaces. In such situation, the output of the
+ 'complete' command will drop the leading whitespaces.
+
+ The current approach is that in such situation, the input and expected
+ outputs are right trimmed (i.e. all leading whitespaces are removed)
+ when performing the command completion check.
+
+ This means that the following call:
+
+ test_gdb_complete_unique " $input" " $expected"
+
+ is almost equivalent to (again, omitting few details and arguments):
+
+ test_gdb_complete_tab_unique " $input" " $expected"
+ test_gdb_complete_cmd_unique "$input" "$expected"
+
+ This approach comes with a problem that we encounter when running the
+ tests in complete-empty.exp. When doing so, we have:
+
+ Running .../gdb/testsuite/gdb.base/complete-empty.exp ...
+ DUPLICATE: gdb.base/complete-empty.exp: empty-input-line: cmd complete ""
+
+ This is because the test file does something like:
+
+ test_gdb_complete_unique "" "!" " " 1
+ test_gdb_complete_unique " " " !" " " 1¬
+
+ which, if we do the substitution introduced above is equivalent to:
+
+ test_gdb_complete_tab_unique "" "!"
+ test_gdb_complete_cmd_unique "" "!"
+ test_gdb_complete_tab_unique " " " !"
+ test_gdb_complete_cmd_unique "" "!"
+
+ We see that the lines 2 and 4 are now the same, and for this reason the
+ testing framework complains about DUPLICATE test names.
+
+ To fix that, this commit proposes that instead of left trimming both
+ input and expected outputs, only the expected output is trimmed.
+
+ Care must be taken in the case the completion gives more possibilities
+ than allowed by the max-completions setting. In this case, the input
+ will be repeated in the output in its left trimmed version. This commit
+ also ensures that this is taken care of.
+
+ With this commit, the gdb.base/complete-empty.exp still passes all its
+ tests but does not report the DUPLICATE anymore.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/subst.exp
+ When I run the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/subst.ex ...
+ DUPLICATE: gdb.base/subst.exp: unset substitute-path from, no rule entered yet
+
+ Fix by adjusting the problematic test name.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Pedro Alves <pedro@palves.net>
+
+ gdb/testsuite: Remove duplicates from gdb.base/dfp-exprs.exp
+ When I run the testsuite, I have:
+
+ Running ../gdb/testsuite/gdb.base/dfp-exprs.exp ...
+ DUPLICATE: gdb.base/dfp-exprs.exp: p 1.2dl < 1.3df
+
+ Replace hand-written tests checking various comparison operators between
+ various decimal floating point types with a loop to programmatically
+ generate all the combinations. This removes the need to eyeball for all
+ suffixes, which lead to the original duplication.
+
+ Also add a lot more combinations, testing all comparison operators
+ comprehensively. The result is 262 unique tests vs 104 before this
+ patch.
+
+ Tested on x86_86-linux.
+
+ Change-Id: Id215a3d610aa8e032bf06ee160b5e3aed4a92d1e
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/ptype.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/ptype.exp ...
+ DUPLICATE: gdb.base/ptype.exp: ptype the_highest
+ DUPLICATE: gdb.base/ptype.exp: list intfoo
+ DUPLICATE: gdb.base/ptype.exp: list charfoo
+
+ Fix by adjusting the offending test names.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/dfp-test.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/dfp-test.exp ...
+ DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number
+ DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number
+ DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number
+ DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number
+
+ Fix by using proc_with_prefix where appropriate.
+
+ Tested on x86_64-linux.
+ Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/del.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/del.exp ...
+ DUPLICATE: gdb.base/del.exp: info break after removing break on main
+
+ Refactor slightly this test to run the various configurations under
+ foreach_with_prefix so each variant is automatically prefixed, ensuring
+ that the forgotten custom test name cannot happen.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/solib-display.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/solib-display.exp ...
+ DUPLICATE: gdb.base/solib-display.exp: NO: break 25
+ DUPLICATE: gdb.base/solib-display.exp: NO: continue
+ DUPLICATE: gdb.base/solib-display.exp: IN: break 25
+ DUPLICATE: gdb.base/solib-display.exp: IN: continue
+ DUPLICATE: gdb.base/solib-display.exp: SEP: break 25
+ DUPLICATE: gdb.base/solib-display.exp: SEP: continue
+
+ The 'break 25' appears because the test inserts two breakpoints at the
+ same location. Fix this by only inserting the breakpoint once.
+
+ Fix the 'continue' DUPLICATE by giving a phony name to the second
+ continue: 'continue two'.
+
+ While at it, this commit also removes a trailing space.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/decl-before-def.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/decl-before-def.exp ...
+ DUPLICATE: gdb.base/decl-before-def.exp: p a
+
+ Fix by giving explicit names to the two tests that use the same command.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/pending.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/pending.exp ...
+ DUPLICATE: gdb.base/pending.exp: disable other breakpoints
+
+ Fix by adjusting the test names.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/checkpoint.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/checkpoint.exp ...
+ DUPLICATE: gdb.base/checkpoint.exp: verify lines 5 two
+ DUPLICATE: gdb.base/checkpoint.exp: restart 0 one
+
+ This patch fixes the various erroneous incorrect test names.
+
+ While at it, this patch also remove some trailing white spaces across
+ the file.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/pie-fork.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/pie-fork.exp ...
+ DUPLICATE: gdb.base/pie-fork.exp: test_no_detach_on_fork: continue
+
+ Fix by giving explicit names to the 'continue' commands that cause the
+ duplicate message.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/realname-expand.exp
+ When running the testsuite, I have:
+
+ Running .../gdb/testsuite/gdb.base/realname-expand.exp ...
+ DUPLICATE: gdb.base/realname-expand.exp: set basenames-may-differ on
+
+ This is due to the fact that the test restarts GDB twice and each time
+ sets the basenames-may-differ setting. This patch proposes to fix this
+ by not restarting GDB so the setting is maintained. It just clears the
+ breakpoints between the two tests and updates the breakpoints number as
+ required.
+
+ This patch also perform some minor refactorings to improve visibility.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/interp.exp
+ When running the testsuite I have:
+
+ Running .../gdb/testsuite/gdb.base/interp.exp ...
+ DUPLICATE: gdb.base/interp.exp: interpreter-exec mi "-var-update *"
+
+ This is due to the fact that multiple successive instances of
+ gdb_test_multiple use 'pass $cmd', but one of them forgets to reset $cmd
+ to a new test name.
+
+ Fix by using 'pass $gdb_test_name', given that the gdb_test_name is set
+ by gdb_test_multiple.
+
+ While fixing this, this patch refactors all occurrences of the following
+ pattern:
+
+ set cmd foo
+ gdb_test_multiple $cmd $cmd {
+ -re ... {
+ pass $cmd
+ }
+ }
+
+ into
+
+ gdb_test_multiple foo "" {
+ -re ... {
+ pass $gdb_test_name
+ }
+ }
+
+ This makes this test file coherent in its use of $gdb_test_name.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/miscexprs.exp
+ When running the testsuite I see:
+
+ Running .../gdb/testsuite/gdb.base/miscexprs.exp ...
+ DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100]
+ DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100]
+
+ This is due to an explicit test name repeated across multiple tests.
+ The actual test explicit names do not add much over the command from
+ wich default test names are derived.
+
+ Fix by removing the explicit test names across the file where they do
+ not add value. While at doing some cleaning, also use $gdb_test_name in
+ the various uses of gdb_test_multiple.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates from gdb.base/stack-checking.exp
+ When running the testsuite I have:
+
+ Running .../gdb/testsuite/gdb.base/stack-checking.exp ...
+ DUPLICATE: gdb.base/stack-checking.exp: bt
+ DUPLICATE: gdb.base/stack-checking.exp: bt
+
+ Fix by using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2022-01-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: update docs to reflect privileged spec v1.9 has been dropped
+ After commit d8af286fffa ("RISC-V: Drop the privileged spec v1.9
+ support.") has removed support for privileged spec v1.9, this removes
+ it from the documentation.
+
+ References: d8af286fffa ("RISC-V: Drop the privileged spec v1.9 support.")
+
+ gas/ChangeLog:
+
+ * configure: Regenerate.
+ * configure.ac: Remove reference to priv spec 1.9.
+ * po/fr.po: Same.
+ * po/ru.po: Same.
+ * po/uk.po: Same.
+
+2022-01-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: update docs for -mpriv-spec/--with-priv-spec for 1.12
+ While support for the privileged spec was added in a63375ac337
+ ("RISC-V: Hypervisor ext: support Privileged Spec 1.12"), the
+ documentation has not been updated. Add 1.12 to the relevant
+ documentation.
+
+ References: a63375ac337 ("RISC-V: Hypervisor ext: support Privileged Spec 1.12")
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c: Add 1.12 to the usage message.
+ * configure: Regenerate.
+ * configure.ac: Add 1.12 to the help/usage message.
+ * po/fr.po: Same.
+ * po/ru.po: Same.
+ * po/uk.po: Same.
+
+2022-01-07 Tom Tromey <tromey@adacore.com>
+
+ Do not use CC_HAS_LONG_LONG
+ ax.cc checks CC_HAS_LONG_LONG, but nothing defines this. However,
+ PRINTF_HAS_LONG_LONG is checked in configure. This patch removes the
+ former and keeps the latter. This is PR remote/14976 (filed by me in
+ 2012, lol).
+
+ I'm checking this in.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14976
+
+2022-01-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: shorten some source lines, and prevent some line breaks
+ Building on the previous commit, this makes use of a trailing @ to
+ split long @deffn lines in the guile.texi source file. This splitting
+ doesn't change how the document is laid out by texinfo.
+
+ I have also wrapped keyword and argument name pairs in @w{...} to
+ prevent line breaks appearing between the two. I've currently only
+ done this for the longer @deffn lines, where a line break is
+ possible. This makes the @deffn lines much nicer to read in the
+ generated pdf.
+
+2022-01-07 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: Remove (...) around guile procedure names in @deffn lines
+ Most guile procedures in the guile.texi file are defined like:
+
+ @deffn {Scheme Procedure} name arg1 arg2 arg3
+
+ But there are two places where we do this:
+
+ @deffn {Scheme Procedure} (name arg1 arg2 arg3)
+
+ Notice the added (...). Though this does represent how a procedure
+ call is written in scheme, it's not the normal style throughout the
+ manual. I also checked the 'info guile' info page to see how they
+ wrote there declarations, and they use the first style too.
+
+ The second style also has the drawback that index entries are added as
+ '(name', and so they are grouped in the '(' section of the index,
+ which is not very user friendly.
+
+ In this commit I've changed the definitions of make-command and
+ make-parameter to use the first style.
+
+ The procedure declaration lines can get pretty long with all of the
+ arguments, and this was true for both of the procedures I am changing
+ in this commit. I have made use of a trailing '@' to split the deffn
+ lines, and keep them under 80 characters in the texi source. This
+ makes no difference to how the final document looks.
+
+ Finally, our current style for keyword arguments, appears to be:
+
+ [#:keyword-name argument-name]
+
+ I don't really understand the reason for this, 'info guile' just seems
+ to use:
+
+ [#:keyword-name]
+
+ which seems just as good to me. But I don't propose to change
+ that just now. What I do notice though, is that sometimes, texinfo
+ will place a line break between the keyword-name and the
+ argument-name, for example, the pdf of make-command is:
+
+ make-command name [#:invoke invoke] [#:command-class
+ command-class] [#:completer-class completer] [#:prefix? prefix] [#:doc
+ doc-string]
+
+ Notice the line break after '#:command-class' and after '#:doc',
+ neither of which are ideal. And so, for the two commands I am
+ changing in this commit, I have made use of @w{...} to prevent line
+ breaks between the keyword-name and the argument-name. Now the pdf
+ looks like this:
+
+ make-command name [#:invoke invoke]
+ [#:command-class command-class] [#:completer-class completer]
+ [#:prefix? prefix] [#:doc doc-string]
+
+ Which seems much better. I'll probably update the other deffn lines
+ at some point.
+
+2022-01-07 Pavel Mayorov <pmayorov@cloudlinux.com>
+
+ Revert previous delta to debug.c. Replace with patch to reject indirect types that point to indirect types.
+ PR 28718
+ * dwarf.c: Revert previous delta.
+ (debug_get_real_type): Reject indirect types that point to
+ indirect types.
+ (debug_get_type_name, debug_get_type_size, debug_write_type):
+ Likewise.
+
+2022-01-07 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Updated the default ISA spec to 20191213.
+ Update the default ISA spec from 2.2 to 20191213 will change the default
+ version of i from 2.0 to 2.1. Since zicsr and zifencei are separated
+ from i 2.1, users need to add them in the architecture string if they need
+ fence.i and csr instructions. Besides, we also allow old ISA spec can
+ recognize zicsr and zifencei, but we won't output them since they are
+ already included in the i extension when i's version is less than 2.1.
+
+ bfd/
+ * elfxx-riscv.c (riscv_parse_add_subset): Allow old ISA spec can
+ recognize zicsr and zifencei.
+ gas/
+ * config/tc-riscv.c (DEFAULT_RISCV_ISA_SPEC): Updated to 20191213.
+ * testsuite/gas/riscv/csr-version-1p10.d: Added zicsr to -march since
+ the default version of i is 2.1.
+ * testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/option-arch-03.d: Updated i's version to 2.1.
+ * testsuite/gas/riscv/option-arch-03.s: Likewise.
+ ld/
+ * testsuite/ld-riscv-elf/call-relax.d: Added zicsr to -march since
+ the default version of i is 2.1.
+ * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated i's version to 2.1.
+ * testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-01b.: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-02b.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-03b.s: Likewise.
+ * testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Added zifencei
+ into Tag_RISCV_arch since it is added implied when i's version is
+ larger than 2.1.
+
+2022-01-07 Alan Modra <amodra@gmail.com>
+
+ Move elf_backend_always_size_sections earlier
+ * elflink.c (bfd_elf_size_dynamic_sections): Move plt/got init
+ earlier and call elf_backend_always_size_sections at the start
+ of this function.
+
+2022-01-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-06 H.J. Lu <hjl.tools@gmail.com>
+
+ ldelfgen.c: Add missing newlines when calling einfo
+ * ldelfgen.c (ldelf_map_segments): Add the missing newline to
+ einfo.
+
+2022-01-06 Nick Clifton <nickc@redhat.com>
+
+ Fix a stack exhaustion bug parsing malicious STABS format debug information.
+ PR 28718
+ * debug.c (debug_write_type): Allow for malicious recursion via
+ indirect debug types.
+
+2022-01-06 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for new SME instructions
+ This patch adds support for three new SME instructions: ADDSPL,
+ ADDSVL and RDSVL. They behave like ADDPL, ADDVL and RDVL, but read
+ the streaming vector length instead of the current vector length.
+
+ opcodes/
+ * aarch64-tbl.h (aarch64_opcode_table): Add ADDSPL, ADDSVL and RDSVL.
+ * aarch64-dis-2.c: Regenerate.
+
+ gas/
+ * testsuite/gas/aarch64/sme.s, testsuite/gas/aarch64/sme.d: Add tests
+ for ADDSPL, ADDSVL and RDSVL.
+
+2022-01-06 Tom Tromey <tom@tromey.com>
+
+ Use target_announce_detach in more targets
+ target_announce_detach was added in commit 0f48b757 ("Factor out
+ "Detaching from program" message printing"). There, Pedro wrote:
+
+ (For now, I left the couple targets that print this a bit differently
+ alone. Maybe this could be further pulled out into infcmd.c. If we
+ did that, and those targets want to continue printing differently,
+ this new function could be converted to a target method.)
+
+ It seems to me that the differences aren't very big, and in some cases
+ other targets handled the output a bit more nicely. In particular,
+ some targets will print a different message when exec_file==NULL,
+ rather than printing the same output with an empty string as
+ exec_file.
+
+ This patch incorporates the nicer output into target_announce_detach,
+ then changes the remaining ports to use this function.
+
+2022-01-06 Tom Tromey <tom@tromey.com>
+
+ Introduce target_announce_attach
+ This introduces target_announce_attach, by analog with
+ target_announce_detach. Then it converts existing targets to use
+ this, rather than emitting their own output by hand.
+
+2022-01-06 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make use add_setshow_prefix_cmd in gnu-nat.c
+ In gnu-nat.c we currently implement some set/show prefix commands
+ "manually", that is, we call add_prefix_cmd, and assign a set and show
+ function to each prefix command.
+
+ These set/show functions print an error indicating that the user
+ didn't type a complete command.
+
+ If we instead switch to using add_setshow_prefix_cmd then we can
+ delete the set/show functions, GDB provides some default functions,
+ which give a nice help style summary that lists all of the available
+ sub-commands, along with a one line summary of what each does.
+
+ Though this clearly changes the existing behaviour, I think this
+ change is acceptable as the new behaviour is more inline with other
+ set/show prefix commands, and the new behaviour is more informative.
+
+ This change will conflict with Tom's change here:
+
+ https://sourceware.org/pipermail/gdb-patches/2022-January/184724.html
+
+ Where Tom changes the set/show functions that I delete. My suggestion
+ is that the set/show functions still be deleted even after Tom's
+ patch (or instead of Tom's patch).
+
+ For testing I've build GDB on GNU/Hurd, and manually tested these
+ functions. I did a grep over the testsuite, and don't believe the
+ existing error messages are being checked for in any tests.
+
+2022-01-06 Tom Tromey <tom@tromey.com>
+
+ Use warning in windows-nat error messages
+ A warning in windows-nat.c can be converted to use the warning
+ function. As a side effect, this arranges for the output to be sent
+ to gdb_stderr.
+
+2022-01-06 Tom Tromey <tom@tromey.com>
+
+ Clean up some dead code in windows-tdep.c
+ windows-tdep.c checks the result of xmalloc, which isn't necessary. I
+ initially removed this dead check, but then went a bit further and
+ modified the code so that some "goto"s and explicit memory management
+ could be removed. Then, I added a couple of missing bounds checks.
+
+ I believe this also fixes a possible bug with a missing 0-termination
+ of a string. I am not certain, but that is why I think the existing
+ code allocates a buffer that is 1 byte too long -- but then it fails
+ to set this byte to 0.
+
+2022-01-06 Tom Tromey <tromey@adacore.com>
+
+ Avoid crash in language_info
+ language_info calls:
+
+ show_language_command (NULL, 1, NULL, NULL);
+
+ ... "knowing" that show_language_command does not use its ui_file
+ parameter. However, this was changed in commit 7514a661
+ ("Consistently Use ui_file parameter to show callbacks").
+
+ This patch changes language_info to pass a ui_file.
+
+ It took a while to write the test -- this function is only called when
+ 'verbose' is on and when switching the "expected" language in auto
+ mode.
+
+2022-01-06 Tom Tromey <tromey@adacore.com>
+
+ Fix some failures in langs.exp
+ langs.exp currently has some fails for me because the stack trace
+ includes full paths to the source files.
+
+ FAIL: gdb.base/langs.exp: up to foo in langs.exp
+ FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp
+ FAIL: gdb.base/langs.exp: up to fsub in langs.exp
+
+ This fixes the failures by making the filename regexps a bit more lax.
+
+2022-01-06 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop NoAVX insn attribute
+ To avoid issues like that addressed by 6e3e5c9e4181 ("x86: extend SSE
+ check to PCLMULQDQ, AES, and GFNI insns"), base the check on opcode
+ attributes and operand types.
+
+ x86: drop NoAVX from POPCNT
+ With the introduction of CpuPOPCNT the NoAVX attribute has become
+ meaningless for POPCNT.
+
+ x86: drop some "comm" template parameters
+ As already indicated in a remark when introducing these templates, the
+ "commutative" attribute is ignored for legacy encoding templates. Hence
+ it is possible to shorten a number of templates by specifying C directly
+ rather than through a template parameter. I think this helps readability
+ a bit.
+
+ x86: templatize FMA insn templates
+ The operand ordering portion of the mnemonics repeats, causing a flurry
+ of almost identical templates. Abstract this out.
+
+ x86-64: restrict PC32 -> PLT32 conversion
+ Neither non-64-bit code nor uses with a non-zero offset from a symbol
+ should be converted to PLT32, as an eventual PLT entry would not express
+ what was requested.
+
+2022-01-06 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Fix copyright year in gdb/testsuite/gdb.base/inferior-clone.exp
+ I just realized that I forgot to update the year before pushing the
+ patch that created this file. Since it landed after the global
+ copyright year update have been done, this file’s copyright year is
+ updated.
+
+ This patch fixes that.
+
+ Change-Id: I280f7d86e02d38425f7afdcf19a1c3500d51c23f
+
+2022-01-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: migrate to standard uintXX_t types
+ Drop the sim-specific unsignedXX types and move to the standard uintXX_t
+ types that C11 provides.
+
+ sim: common: migrate to standard uintXX_t types
+ Drop the sim-specific unsignedXX types and move to the standard uintXX_t
+ types that C11 provides.
+
+ sim: igen: migrate to standard uintXX_t types
+ Move off the custom local 64-bit types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: mips: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: cris: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: iq2000: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: synacor: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: msp430: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: riscv: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: bfin: migrate to standard uintXX_t types
+ Move off the sim-specific unsignedXX types and to the standard uintXX_t
+ types that C11 provides.
+
+ sim: testsuite: migrate to standard uintXX_t types
+ This old code setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ sim: erc32: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ sim: mn10300: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ sim: v850: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+2022-01-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m68hc11: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: d10v: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cr16: migrate to standard uintXX_t types
+ This old port setup its own uintXX types, but since we require C11
+ now, we can assume the standard uintXX_t types exist and use them.
+
+ Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-05 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Add elf_x86_allocate_local_got_info
+ Add elf_x86_allocate_local_got_info to allocate x86 GOT info for local
+ symbols.
+
+ * elf32-i386.c (elf_i386_check_relocs): Call
+ elf_x86_allocate_local_got_info.
+ * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+ * elfxx-x86.h (elf_x86_allocate_local_got_info): New.
+
+2022-01-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ opcodes: Make i386-dis.c thread-safe
+ Improve thread safety in print_insn_i386_att, print_insn_i386_intel and
+ print_insn_i386 by removing the use of static variables.
+
+ Tested on x86_64-pc-linux-gnu.
+
+ 2022-01-04 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * i386-dis.c: Make print_insn_i386_att, print_insn_i386_intel
+ and print_insn_i386 thread-safe
+
+2022-01-05 H.J. Lu <hjl.tools@gmail.com>
+
+ doc: Replace =frame-interp with =frames-interp
+ The actual objdump and readelf option name is =frames-interp, not
+ =frames-interp.
+
+ PR binutils/28747
+ * doc/debug.options.texi: Replace =frame-interp with
+ =frames-interp.
+
+2022-01-05 Tom Tromey <tromey@adacore.com>
+
+ Change riscv_return_value to use RETURN_VALUE_ABI_PRESERVES_ADDRESS
+ Internally, AdaCore has a test that is equivalent to (really a direct
+ translation of) gdb.base/gnu_vector.exp. On 32-bit RISC-V, the
+ "return" part of this test fails.
+
+ Joel tracked this down to riscv_return_value returning
+ RETURN_VALUE_ABI_RETURNS_ADDRESS. Using
+ RETURN_VALUE_ABI_PRESERVES_ADDRESS is more correct here, and fixes the
+ bug.
+
+ I tested this for both 32- and 64-bit RISC-V using the AdaCore
+ internal test suite, and Andrew Burgess tested it using
+ gnu_vector.exp.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Filtered output cleanup in expression dumping
+ Most of the expression-dumping code uses filtered output, but a few
+ functions did not. This patch cleans up these instance.
+
+ Note that this won't cause any behavior change, because the only calls
+ to dump_prefix_expression pass in gdb_stdlog. However, in the long
+ run it's easier to audit the code if the number of uses of _unfiltered
+ is reduced.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in terminal_info implementations
+ This changes one terminal_info implementation, and
+ default_terminal_info, to use filtered output. Other implementations
+ of this method already use filtered output.
+
+ I can't compile go32-nat.c, so this is a 'best effort' patch.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in gnu-nat.c commands
+ gnu-nat.c has a number of ordinary commands that should use filtered
+ output. In a few cases, I changed the output to use gdb_stderr as
+ well. I can't compile this file, so this patch is split out as a
+ "best effort".
+
+ Use filtered output in *-tdep commands
+ Various targets introduce their own commands, which then use
+ unfiltered output. It's better to use filtered output by default, so
+ this patch fixes the instances I found.
+
+ Use filtered output in btrace-related commands
+ This changes btrace.c and record-btrace.c to use filtered output in
+ the commands implemented there.
+
+ Use filtered output in some dumping commands
+ There are several commands that may optionally send their output to a
+ file -- they take an optional filename argument and open a file. This
+ patch changes these commands to use filtered output. The rationale
+ here is that, when printing to gdb_stdout, filtering is appropriate --
+ it is, and should be, the default for all commands. And, when writing
+ to a file, paging will not happen anyway (it only happens when the
+ stream==gdb_stdout), so using the _filtered form will not change
+ anything.
+
+ Use filtered output in kill command
+ This changes the kill command to use filtered output. I split this
+ one into its own patch because, out of an abundance of caution, I
+ changed the function to call bfd_cache_close_all a bit earlier, in
+ case pagination caused an exception.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in ordinary commands
+ Many otherwise ordinary commands choose to use unfiltered output
+ rather than filtered. I don't think there's any reason for this, so
+ this changes many such commands to use filtered output instead.
+
+ Note that complete_command is not touched due to a comment there
+ explaining why unfiltered output is believed to be used.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in language_info
+ Change language_info to use filtered output. This is ok because the
+ sole caller uses filtered output elsewhere, and because this function
+ calls show_language_command, which also uses filtered output.
+
+ Use filtered output in files_info implementations
+ This changes the implementations of the target files_info method to
+ use filtered output. This makes sense because the sole caller of this
+ method is an ordinary command (info_program_command). This patch
+ changes this command to use filtered output as well.
+
+ Use filtered output in target-descriptions.c
+ target-descriptions.c uses unfiltered output. However, if you happen
+ to invoke this command interactively, it's probably better for it to
+ use filtering. For non-interactive use, this doesn't matter.
+
+ Use filtered output for gdbarch dump
+ This changes gdbarch dumping to use filtered output. This seems a bit
+ better to me, both on the principle that this is an ordinary command,
+ and because the output can be voluminous, so it may be nice to stop in
+ the middle.
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Implement putstr and putstrn in ui_file
+ In my tour of the ui_file subsystem, I found that fputstr and fputstrn
+ can be simplified. The _filtered forms are never used (and IMO
+ unlikely to ever be used) and so can be removed. And, the interface
+ can be simplified by removing a callback function and moving the
+ implementation directly to ui_file.
+
+ A new self-test is included. Previously, I think nothing was testing
+ this code.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-01-05 Tom Tromey <tromey@adacore.com>
+
+ Change how versioned symbols are recorded
+ A change to BFD caused a gdb regression when using the Ada "catch
+ exception" feature. The bug is visible when a shared library throws
+ an exception that is caught in the main executable.
+
+ This was discussed here:
+
+ https://sourceware.org/pipermail/binutils/2021-July/117538.html
+
+ This patch implements Alan's proposed fix, namely to use VERSYM_HIDDEN
+ rather than the name when deciding to install a version-less symbol.
+
+ The internal test case is identical to the catch_ex_std.exp that is
+ in-tree, so I haven't added a new test. I could not make that one
+ fail on x86-64 Linux, though. It's possible that maybe I'd have to
+ update the system linker first, but I didn't want to try that.
+
+ Regression tested on x86-64 Fedora 32.
+
+2022-01-05 Hannes Domani <ssbssa@yahoo.de>
+
+ Fix inferior_thread attribute in new_thread event
+ Commit 72ee03ff58 fixed a use-after-move bug in add_thread_object, but
+ it changed the inferior_thread attribute to contain the inferior instead
+ of the actual thread.
+ This now uses the thread_obj in its new location instead.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28429
+
+2022-01-05 Tom Tromey <tom@tromey.com>
+
+ Simplify execute_control_commands_to_string
+ execute_control_commands_to_string can be rewritten in terms of
+ execute_fn_to_string, which consolidates some knowledge about which
+ streams to redirect.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-01-05 Tom Tromey <tromey@adacore.com>
+
+ Do not print anything when self-backtrace unavailable
+ Right now, gdb's self-backtrace feature will still print something
+ when a backtrace is unavailable:
+
+ sig_write (_("----- Backtrace -----\n"));
+ [...]
+ sig_write (_("Backtrace unavailable\n"));
+ sig_write ("---------------------\n");
+
+ However, if GDB_PRINT_INTERNAL_BACKTRACE is undefined, it seems better
+ to me to print nothing at all.
+
+ This patch implements this change. It also makes a couple of other
+ small changes in this same module: it adds a header guard to
+ bt-utils.h, and it protects the definitions of
+ gdb_internal_backtrace_1 with a check of GDB_PRINT_INTERNAL_BACKTRACE.
+
+2022-01-05 Tom Tromey <tromey@adacore.com>
+
+ Fix pager regression
+ The patch to fix paging with redirection caused a regression in the
+ internal AdaCore test suite. The problem occurs when running an MI
+ command from the CLI using interpreter-exec, when paging is enabled.
+ This scenario isn't covered by the current test suite, so this patch
+ includes a new test.
+
+ The problem is that, in this situation, MI does:
+
+ fputs_unfiltered (strcmp (context->command, "target-select") == 0
+ ? "^connected" : "^done", mi->raw_stdout);
+
+ Here raw_stdout is a stdio_file wrapping stdout, so the pager thinks
+ that it is ok to buffer the output. However, in this setup, it isn't
+ ok, and flushing the wrap buffer doesn't really work properly. Also,
+ MI next does:
+
+ mi_out_put (uiout, mi->raw_stdout);
+
+ ... but this uses ui_file::write, which also doesn't flush the wrap
+ buffer.
+
+ I think all this will be fixed by the pager rewrite series I'm working
+ on. However, in the meantime, adding the old gdb_stdout check back to
+ the pager fixes this problem.
+
+ Regression tested on x86-64 Fedora 34.
+
+2022-01-05 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Set p_align to the minimum page size if possible
+ Currently, on 32-bit and 64-bit ARM, it seems that ld generates p_align
+ values of 0x10000 even if no section alignment is greater than 0x1000.
+ The issue is more general and probably affects other targets with multiple
+ page sizes.
+
+ While file layout absolutely must take 64K page size into account, that
+ does not have to be reflected in the p_align value. If running on a 64K
+ kernel, the file will be loaded at a 64K page boundary by necessity. On
+ a 4K kernel, 64K alignment is not needed.
+
+ The glibc loader has been fixed to honor p_align:
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28676
+
+ similar to kernel:
+
+ commit ce81bb256a224259ab686742a6284930cbe4f1fa
+ Author: Chris Kennelly <ckennelly@google.com>
+ Date: Thu Oct 15 20:12:32 2020 -0700
+
+ fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
+
+ This means that on 4K kernels, we will start to do extra work for 64K
+ p_align, but this pointless for pretty much all binaries (whose section
+ alignment rarely exceeds 16).
+
+ The minimum page size is used, instead of the maximum section alignment
+ due to this glibc bug:
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28688
+
+ It has been fixed in glibc 2.35. But linker output must work on existing
+ glibc binaries.
+
+ 1. Set p_align to the minimum page size while laying out segments aligning
+ to the maximum page size or section alignment. The run-time loader can
+ align segments to the minimum page size or above, depending on system page
+ size.
+ 2. If -z max-page-size=NNN is used, p_align will be set to the maximum
+ page size or the largest section alignment.
+ 3. If a section requires alignment higher than the minimum page size,
+ don't set p_align to the minimum page size.
+ 4. If a section requires alignment higher than the maximum page size,
+ set p_align to the section alignment.
+ 5. For objcopy, when the minimum page size != the maximum page size,
+ p_align may be set to the minimum page size while segments are aligned
+ to the maximum page size. In this case, the input p_align will be
+ ignored and the maximum page size will be used to align the ouput
+ segments.
+ 6. Update linker to disallow the common page size > the maximum page size.
+ 7. Update linker to avoid the common page size > the maximum page size.
+ 8. Adjust pru_irq_map-1.d to expect p_align == sh_addralign:
+
+ Section Headers:
+ [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
+ [ 0] NULL 00000000 000000 000000 00 0 0 0
+ [ 1] .text PROGBITS 20000000 00007c 000004 00 AX 0 0 4
+ ...
+ Program Headers:
+ Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
+ LOAD 0x000074 0x00000000 0x00000000 0x00008 0x00008 RW 0x1
+ LOAD 0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x4
+
+ vs.
+
+ Section Headers:
+ [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
+ [ 0] NULL 00000000 000000 000000 00 0 0 0
+ [ 1] .text PROGBITS 20000000 00007c 000004 00 AX 0 0 4
+ ...
+ Program Headers:
+ Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
+ LOAD 0x000074 0x00000000 0x00000000 0x00008 0x00008 RW 0x1
+ LOAD 0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x1
+
+ To enable this linker optimization, the backend should define ELF_P_ALIGN
+ to ELF_MINPAGESIZE.
+
+ bfd/
+
+ PR ld/28689
+ PR ld/28695
+ * elf-bfd.h (elf_backend_data): Add p_align.
+ * elf.c (assign_file_positions_for_load_sections): Set p_align
+ to the default p_align value while laying out segments aligning
+ to maximum page size or section alignment.
+ (elf_is_p_align_valid): New function.
+ (copy_elf_program_header): Call elf_is_p_align_valid to determine
+ if p_align is valid.
+ * elfxx-target.h (ELF_P_ALIGN): New. Default to 0.
+ (elfNN_bed): Add ELF_P_ALIGN.
+ * elfxx-x86.h (ELF_P_ALIGN): New. Set to ELF_MINPAGESIZE.
+
+ include/
+
+ PR ld/28689
+ PR ld/28695
+ * bfdlink.h (bfd_link_info): Add maxpagesize_is_set.
+
+ ld/
+
+ PR ld/28689
+ PR ld/28695
+ * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Set
+ link_info.maxpagesize_is_set for -z max-page-size=NNN.
+ * ldelf.c (ldelf_after_parse): Disallow link_info.commonpagesize
+ > link_info.maxpagesize.
+ * testsuite/ld-elf/elf.exp: Pass -z max-page-size=0x4000 to
+ linker to build mbind2a and mbind2b.
+ * testsuite/ld-elf/header.d: Add -z common-page-size=0x100.
+ * testsuite/ld-elf/linux-x86.exp: Add PR ld/28689 tests.
+ * testsuite/ld-elf/p_align-1.c: New file.
+ * testsuite/ld-elf/page-size-1.d: New test.
+ * testsuite/ld-elf/pr26936.d: Add -z common-page-size=0x1000.
+ * testsuite/ld-elf/seg.d: Likewise.
+ * testsuite/ld-scripts/rgn-at5.d: Likewise.
+ * testsuite/ld-pru/pru_irq_map-1.d: Append 1 to name. Adjust
+ expected PT_LOAD segment alignment.
+ * testsuite/ld-pru/pru_irq_map-2.d: Append 2 to name.
+ * testsuite/ld-scripts/pr23571.d: Add -z max-page-size=0x1000.
+
+2022-01-05 Alan Modra <amodra@gmail.com>
+
+ Adjust quoted-sym-names test
+ Some targets restrict symbol addresses in .text to instruction
+ boundaries.
+
+ * testsuite/gas/all/quoted-sym-names.s: Define syms in .data.
+ * testsuite/gas/all/quoted-sym-names.d: Adjust to suit.
+
+2022-01-05 Alan Modra <amodra@gmail.com>
+
+ infinite recursion detected in gold testcase
+ gold/testsuite/icf_test.cc:32:5: error: infinite recursion detected [-Werror=infinite-recursion]
+ 32 | int kept_func()
+ | ^~~~~~~~~
+
+ * testsuite/icf_test.cc: Avoid infinite recursion error.
+
+2022-01-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-04 H.J. Lu <hjl.tools@gmail.com>
+
+ ld/x86: Update -z report-relative-reloc
+ Use 0x%v, instead of bfd_sprintf_vma, to report relative relocations.
+ Change linker relative relocations report from
+
+ tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x0000000000002000, info: 0x0000000000000025, addend: 0x0000000000001007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o
+
+ to
+
+ tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x2000, info: 0x25, addend: 0x1007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o
+
+ bfd/
+
+ * elfxx-x86.c (_bfd_x86_elf_link_report_relative_reloc): Use
+ 0x%v instead of bfd_sprintf_vma.
+
+ ld/
+
+ * testsuite/ld-i386/report-reloc-1.l: Updated.
+ * testsuite/ld-x86-64/report-reloc-1.l: Likewise.
+
+2022-01-04 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Improve thin archive member error message
+ Improve thin archive member error message with:
+
+ ld: libbar.a(bar.o): error opening thin archive member: No such file or directory
+
+ instead of
+
+ ld: libbar.a: error adding symbols: No such file or directory
+
+ PR ld/28722
+ * archive.c (_bfd_get_elt_at_filepos): Add a pointer argument
+ for struct bfd_link_info. Call linker callback when failing to
+ open thin archive member.
+ (_bfd_generic_get_elt_at_index): Pass NULL to
+ _bfd_get_elt_at_filepos.
+ (bfd_generic_openr_next_archived_file): Likewise.
+ * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Add a pointer
+ argument for struct bfd_link_info and pass it to
+ _bfd_get_elt_at_filepos.
+ (alpha_ecoff_openr_next_archived_file): Pass NULL to
+ _bfd_get_elt_at_filepos.
+ (alpha_ecoff_get_elt_at_index): Likewise.
+ * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Likewise.
+ * ecoff.c (ecoff_link_add_archive_symbols): Pass info to
+ backend->get_elt_at_filepos.
+ * elflink.c (elf_link_is_defined_archive_symbol): info to
+ _bfd_get_elt_at_filepos.
+ * libbfd-in.h (_bfd_get_elt_at_filepos): Add a pointer argument
+ for struct bfd_link_info.
+ * libbfd.h: Regenerate.
+ * libecoff.h (ecoff_backend_data): Add a pointer argument for
+ struct bfd_link_info to get_elt_at_filepos.
+ * linker.c (_bfd_generic_link_add_archive_symbols): Pass info to
+ _bfd_get_elt_at_filepos.
+
+2022-01-04 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb/testsuite: fix inferior-clone.exp for native-extended-gdbserver
+ 003aae076207dbf32f98ba846158fc32669ef85f (gdb: Copy inferior properties
+ in clone-inferior) introduced a testcase that fails when testing with
+ the native-extended-gdbserver board:
+
+ Running ../gdb/testsuite/gdb.base/inferior-clone.exp ...
+ FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior
+ FAIL: gdb.base/inferior-clone.exp: inferior 3: clone-inferior
+
+ The error is as follows:
+
+ clone-inferior
+ [New inferior 2]
+ Added inferior 2 on connection 1 (extended-remote localhost:2346)
+ (gdb) FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior
+
+ This fails because the testcase only expect the 'Added inferior 2' part
+ of the message. The 'on connection 1 [...]' part is unexpected.
+
+ Fix by adjusting the testcase to a account for the possible trailing
+ part of the message.
+
+ Tested on x86_64-linux with native-extende-gdbserver and unix boards.
+
+ Change-Id: Ie3d6f04c9ffe9cab1fbda8ddf4935ee09b858c7a
+
+2022-01-04 Nick Clifton <nickc@redhat.com>
+
+ Add ATTRIBUTE_UNUSED to load_build_id_debug_file()'s main_filename parameter.
+
+2022-01-04 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: don't pass nullptr to sigwait
+ I tried building GDB on GNU/Hurd, and ran into this warning:
+
+ gdbsupport/scoped_ignore_signal.h:78:16: error: null argument where non-null required (argument 2) [-Werror=nonnull]
+
+ This is because in this commit:
+
+ commit 99624310dd82542c389c89c2e55d8cae36bb74e1
+ Date: Sun Jun 27 15:13:14 2021 -0400
+
+ gdb: fall back on sigpending + sigwait if sigtimedwait is not available
+
+ A call to sigwait was introduced that passes nullptr as the second
+ argument, this call is only reached if sigtimedwait is not supported.
+
+ The original patch was written for macOS, I assume on that target
+ passing nullptr as the second argument is fine.
+
+ On my GNU/Linux box, the man-page for sigwait doesn't mention that
+ nullptr is allowed for the second argument, so my assumption would be
+ that nullptr is not OK, and, if I change the '#ifdef
+ HAVE_SIGTIMEDWAIT' introduced by the above patch to '#if 0', and
+ rebuild on GNU/Linux, I see the same warning that I see on GNU/Hurd.
+
+ I propose that we stop passing nullptr as the second argument to
+ sigwait, and instead pass a valid int pointer. The value returned in
+ the int can then be used in an assert.
+
+ For testing, I (locally) made the change to the #ifdef I mentioned
+ above, compiled GDB, and ran the usual tests, this meant I was using
+ sigwait instead on sigtimedwait on GNU/Linux, I saw no regressions.
+
+2022-01-04 Nick Clifton <nickc@redhat.com>
+
+ Remove a spurious debugging message.
+ PR 28716
+ * dwarf.c (load_build_id_debug_file): Remove spurious printf.
+
+2022-01-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build breaker in gdb/cli/cli-logging.c
+ Fix build breaker in gdb/cli/cli-logging.c:
+ ...
+ gdb/cli/cli-logging.c: In function \
+ ‘void show_logging_enabled(ui_file*, int, cmd_list_element*, const char*)’:
+ gdb/gdbsupport/gdb_locale.h:28:28: error: cannot convert ‘char*’ to ‘ui_file*’
+ 28 | # define _(String) gettext (String)
+ | ~~~~~~~~^~~~~~~~
+ | |
+ | char*
+ gdb/cli/cli-logging.c:202:25: note: in expansion of macro ‘_’
+ 202 | fprintf_unfiltered (_("on: Logging is enabled.\n"));
+ | ^
+ ...
+
+ Build and tested on x86_64-linux.
+
+ Fixes: 45aec4e5ed8 ("[gdb/cli] Improve show logging output")
+
+2022-01-04 Jan Beulich <jbeulich@suse.com>
+
+ x86/Intel: correct VFPCLASSP{S,D} handling when displacement is present
+ fits_in_disp8() can be called before ambiguous operands get resolved
+ or rejected (in process_suffix()), which requires that i.memshift be
+ non-negative to avoid an internal error. This case wasn't covered by
+ 6c0946d0d28d ("x86: correct VFPCLASSP{S,D} operand size handling").
+
+2022-01-04 Jan Beulich <jbeulich@suse.com>
+
+ gas: rework handling of backslashes in quoted symbol names
+ Strange effects can result from the present handling, e.g.:
+
+ .if 1
+ "backslash\\":
+ .endif
+
+ yields first (correctly) "missing closing `"'" but then also "invalid
+ character '\' in mnemonic" and further "end of file inside conditional".
+ Symbols names ending in \ are in principle not expressable with that
+ scheme.
+
+ Instead of recording whether a backslash was seen, inspect the
+ subsequent character right away. Only accept \\ (meaning a single
+ backslash in the resulting symbol name) and \" (meaning an embedded
+ double quote in the resulting symbol name) for now, warning about any
+ other combination.
+
+ While perhaps not necessary immediately, also permit concatenated
+ strings to form a symbol name. This may become useful if going forward
+ we would want to support \<octal> or \x<hex> sequences, where closing
+ and re-opening quotes can be useful to delimit such sequences.
+
+ The ELF "Multibyte symbol names" test gets switched away from using
+ .set, as that would now also mean excluding nios2 and pru. By using
+ .equiv instead, even the existing #notarget can be dropped. (For h8300
+ the .section directive additionally needs attributes specified, to avoid
+ a target specific warning.)
+
+2022-01-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Improve show logging output
+ Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
+ following output for "show logging":
+ ...
+ $ gdb -q -batch -ex "set trace-commands on" \
+ -ex "set logging off" \
+ -ex "show logging" \
+ -ex "set logging on" \
+ -ex "show logging"
+ +set logging off
+ +show logging
+ Future logs will be written to gdb.txt.
+ Logs will be appended to the log file.
+ Output will be logged and displayed.
+ Debug output will be logged and displayed.
+ +set logging on
+ +show logging
+ Currently logging to "gdb.txt".
+ Logs will be appended to the log file.
+ Output will be logged and displayed.
+ Debug output will be logged and displayed.
+ ...
+
+ After that commit we have instead:
+ ...
+ +set logging off
+ +show logging
+ debugredirect: The logging output mode is off.
+ file: The current logfile is "gdb.txt".
+ overwrite: Whether logging overwrites or appends to the log file is off.
+ redirect: The logging output mode is off.
+ +set logging on
+ +show logging
+ debugredirect: The logging output mode is off.
+ file: The current logfile is "gdb.txt".
+ overwrite: Whether logging overwrites or appends to the log file is off.
+ redirect: The logging output mode is off.
+ ...
+ which gives less clear output for some subcommands.
+
+ OTOH, it's explicit about whether boolean values are on or off.
+
+ The new text seems to have been chosen to match the set/show help texts:
+ ...
+ (gdb) help show logging
+ Show logging options.
+
+ List of show logging subcommands:
+
+ show logging debugredirect -- Show the logging debug output mode.
+ show logging file -- Show the current logfile.
+ show logging overwrite -- \
+ Show whether logging overwrites or appends to the log file.
+ show logging redirect -- Show the logging output mode.
+ ...
+
+ Make the show logging messages more clear, while still keep the boolean
+ values explicit, such that we have:
+ ...
+ $ ./gdb.sh -q -batch -ex "show logging"
+ logging debugredirect: off: \
+ Debug output will go to both the screen and the log file.
+ logging enabled: off: Logging is disabled.
+ logging file: The current logfile is "gdb.txt".
+ logging overwrite: off: Logging appends to the log file.
+ logging redirect: off: Output will go to both the screen and the log file.
+ ...
+
+ Tested on x86_64-linux.
+
+2022-01-03 Tom Tromey <tromey@adacore.com>
+
+ Fix use of 'printf' in gdbtypes.c
+ An earlier patch of mine, commit 64b7cc50 ("Remove
+ gdb_print_host_address") inadvertently changed a function in
+ gdbtypes.c to use printf rather than printf_filtered. This patch
+ fixes the problem.
+
+ Fix regression in page-logging.exp
+ Simon and Tom pointed out that page-logging.exp failed on their
+ machines. Tom tracked this down to the "width" setting. Since
+ there's no need in the test to change the width, it seems simplest to
+ remove the setting. I confirmed that the test still fails if the fix
+ is backed out, ensuring that the test is still testing what it
+ purports to.
+
+ Small indentation fix in eval.c
+ I noticed that the AdaCore tree had a small divergence in eval.c -- it
+ had a fix for an indentation problem in binop_promote. I'm checking
+ in this small fix as obvious.
+
+2022-01-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle for loop initial decl with gcc 4.8.5
+ When running test-case gdb.threads/schedlock-thread-exit.exp on a system with
+ system compiler gcc 4.8.5, I run into:
+ ...
+ src/gdb/testsuite/gdb.threads/schedlock-thread-exit.c:33:3: error: \
+ 'for' loop initial declarations are only allowed in C99 mode
+ ...
+
+ Fix this by:
+ - using -std=c99, or
+ - using -std=gnu99, in case that's required, or
+ - in the case of the jit test-cases, rewriting the for loops.
+
+ Tested on x86_64-linux, both with gcc 4.8.5 and gcc 7.5.0.
+
+2022-01-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-02 Tom Tromey <tom@tromey.com>
+
+ Update copying.awk for _initialize declaration patch
+ Commit 6c265988 ("gdb: add back declarations for _initialize
+ functions") modified copying.c, but not copying.awk. This patch
+ updates copying.awk to backport the appropriate fix. This way, if
+ copying.awk is run again, it will create the correct output.
+
+ I'm checking this in as obvious.
+
+2022-01-02 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in print_i387_ext
+ print_i387_ext mostly uses filtered output, but one call in the middle
+ of the function uses the _unfiltered form. This patch fixes this
+ call. I'm checking this in as obvious.
+
+2022-01-02 Alan Modra <amodra@gmail.com>
+
+ Update year range in copyright notice of binutils files
+ The result of running etc/update-copyright.py --this-year, fixing all
+ the files whose mode is changed by the script, plus a build with
+ --enable-maintainer-mode --enable-cgen-maint=yes, then checking
+ out */po/*.pot which we don't update frequently.
+
+ The copy of cgen was with commit d1dd5fcc38ead reverted as that commit
+ breaks building of bfp opcodes files.
+
+2022-01-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2022-01-01 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: copyright: fix a few comment typos
+
+ sim: ppc: drop natural types
+ These are almost entirely unused. For the very few places using them,
+ replace with explicit signed types. This matches what was done in the
+ common sim code.
+
+ sim: mips: clean up bad style/whitespace
+ This doesn't fix all the problems, but grabs a bunch of the more
+ obvious ones.
+
+ sim: tweak copyright lines for gnulib update-copyright
+ The regex it uses does not like so many leading spaces which causes
+ it to think the files lack copyright. Trim them down so the script
+ can find & update them accordingly.
+
+ gdb: update sim mips testsuite copyright exemption
+ The sim testsuite was reorganized last year, so update the path.
+
+2022-01-01 Mike Frysinger <vapier@gentoo.org>
+
+ unify 64-bit bfd checks
+ Move the 64-bit bfd logic out of bfd/configure.ac and into bfd64.m4
+ under config so it can be shared between all the other subdirs.
+
+ This replaces want64 with enable_64_bit_bfd which was already being
+ declared, but not used directly.
+
+2022-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Update Copyright year in gdb/testsuite/gdb.arch/powerpc-power10.exp
+ This commit updates the copyright year range in the script
+ gdb/testsuite/gdb.arch/powerpc-power10.exp. The update was
+ performed by running gdb/copyright.py again, to make sure
+ that the copyright year range will be automatically updated
+ in years forward.
+
+2022-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Fix copyright header in gdb/testsuite/gdb.arch/powerpc-power10.exp
+ The copyright year and holder line is slight malformed, missing
+ a space after a comma, and this is sufficient for gdb's
+ copyright.py script to miss this file during its automated
+ copyright year update.
+
+ This commit fixes this.
+
+2022-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ gdb/copyright.py: Add update-netbsd.sh to MULTIPLE_COPYRIGHT_HEADERS
+ Add gdb/syscalls/update-netbsd.sh to the reminder printed
+ at the end of the execution listing all the files where
+ a manual update of the copyright header is needed. This
+ scripts contains some inline code which includes a copyright
+ header.
+
+ Manual copyright year update of various GDB files
+ This commit updates the copyright year in some files where
+ we have a copyright year outside of the copyright year,
+ and thus are not included in gdb's copyright.py script.
+
+2022-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Automatic Copyright Year update after running gdb/copyright.py
+ This commit brings all the changes made by running gdb/copyright.py
+ as per GDB's Start of New Year Procedure.
+
+ For the avoidance of doubt, all changes in this commits were
+ performed by the script.
+
+2022-01-01 Joel Brobecker <brobecker@adacore.com>
+
+ Update Copyright Year in gdb, gdbserver and gdbreplay version output
+ This commit changes the copyright year printed by gdb, gdbserver
+ and gdbreplay when printing the tool's version.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ ubsan: next_char_of_string signed integer overflow
+ Squash another totally useless fuzz report that I should have ignored.
+
+ * read.c (next_char_of_string): Avoid integer overflow.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ ubsan: bfd_mach_o_build_commands shift exponent 64 is too large
+ * mach-o.c (bfd_mach_o_read_section_32): Limit alignment further.
+ (bfd_mach_o_read_section_64): Likewise.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ ubsan: signed integer multiply overflow
+ 9223371018427387904 * 2 cannot be represented in type 'long', yes, but
+ we don't care.
+
+ * expr.c (expr): Avoid signed overflow.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ asan: Null-dereference in _bfd_xcoff_copy_private_bfd_data
+ sec->output_section will be NULL when objcopy removes sections.
+
+ * coff-rs6000.c (_bfd_xcoff_copy_private_bfd_data): Protect against
+ objcopy removing sections.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ ubsan: integer overflow in section filepos subtraction
+ * elf.c (assign_file_positions_for_non_load_sections): Avoid
+ signed integer overflow.
+
+2022-01-01 Alan Modra <amodra@gmail.com>
+
+ Remove unnecessary ELF_MINPAGESIZE defines
+ The idea of this patch is to make it easy to see which targets (just
+ sparc) have ELF_MINPAGESIZE != ELF_COMMONPAGESIZE.
+
+ * elf32-arm.c (ELF_MINPAGESIZE): Don't define.
+ * elf32-metag.c: Likewise.
+ * elfnn-aarch64.c: Likewise.
+ * elf64-x86-64.c: Likewise. Also don't redefine a bunch of other
+ macros for l1om elf64-target.h use that are unchanged from default.
+
+2022-01-01 H.J. Lu <hjl.tools@gmail.com>
+
+ ld-x86-64: Pass options to linker with "-Wl,"
+ * testsuite/ld-x86-64/x86-64.exp: Pass options to linker with
+ "-Wl,".
+
+2022-01-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-31 Tom Tromey <tom@tromey.com>
+
+ Do not call reinitialize_more_filter from avr_io_reg_read_command
+ avr_io_reg_read_command is an ordinary gdb command, and so should not
+ be calling reinitialize_more_filter. This patch removes it. I'm
+ checking this in as obvious. Tested by rebuilding.
+
+2021-12-31 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Define check_relocs_failed in elfxx-x86.h
+ * elf32-i386.c (check_relocs_failed): Moved to ...
+ * elfxx-x86.h (check_relocs_failed): Here. New.
+ * elf64-x86-64.c (check_relocs_failed): Removed.
+
+ Define X86_PCREL_TYPE_P/X86_SIZE_TYPE_P in elfxx-x86.h
+ * elf32-i386.c: Don't include "elf/i386.h".
+ (X86_PCREL_TYPE_P): Removed.
+ (X86_SIZE_TYPE_P): Likewise.
+ (elf_i386_check_relocs): Pass false to NEED_DYNAMIC_RELOCATION_P.
+ (elf_i386_relocate_section): Pass false to
+ GENERATE_DYNAMIC_RELOCATION_P and COPY_INPUT_RELOC_P.
+ * elf64-x86-64.c: Don't include "elf/x86-64.h".
+ (X86_PCREL_TYPE_P): Removed.
+ (X86_SIZE_TYPE_P): Likewise.
+ (elf_x86_64_check_relocs): Pass true to NEED_DYNAMIC_RELOCATION_P
+ and X86_PCREL_TYPE_P.
+ (elf_x86_64_relocate_section): Pass true to X86_PCREL_TYPE_P,
+ X86_SIZE_TYPE_P, GENERATE_DYNAMIC_RELOCATION_P and
+ COPY_INPUT_RELOC_P.
+ * elfxx-x86.c: Don't include "elf/i386.h" nor "elf/x86-64.h".
+ * elfxx-x86.h (X86_64_PCREL_TYPE_P): New.
+ (I386_PCREL_TYPE_P): Likewise.
+ (X86_PCREL_TYPE_P): Likewise.
+ (X86_64_SIZE_TYPE_P): Likewise.
+ (I386_SIZE_TYPE_P): Likewise.
+ (X86_SIZE_TYPE_P): Likewise.
+ (NEED_DYNAMIC_RELOCATION_P): Add IS_X86_64 and pass it to
+ X86_PCREL_TYPE_P.
+ (COPY_INPUT_RELOC_P): Likewise.
+ (GENERATE_DYNAMIC_RELOCATION_P): Add IS_X86_64, pass it to
+ X86_PCREL_TYPE_P and X86_SIZE_TYPE_P.
+
+2021-12-31 Tamar Christina <tamar.christina@arm.com>
+
+ ld: fix coff PE SEH
+ COFF_WITH_pex64 and COFF_WITH_peAArch64 can't be true at the same time.
+ That means that two conditionals that control the sorting of the .pdata section
+ became a falsum.
+
+ The testsuite doesn't catch this because the linker does the sorting and to link
+ you require library support from the unwinder so we can't test from binutils in
+ isolation.
+
+ bfd/ChangeLog:
+
+ 2021-12-31 Tamar Christina <tamar.christina@arm.com>
+
+ PR ld/28682
+ * peXXigen.c: Fix conditional.
+
+2021-12-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use filtered output in show callbacks
+ "show" command callbacks, like most ordinary gdb commands, should use
+ filtered output. I found a few that did not, so this patch changes
+ them to use the filtered form.
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Consistently Use ui_file parameter to show callbacks
+ I happened to notice that one "show" callback was printing to
+ gdb_stdout rather than to the passed-in ui_file parameter. I went
+ through all such callbacks and fixed them to consistently use the
+ ui_file.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use gdb_stdlog for MI debugging
+ When MI debugging is enabled, the logging output should be sent to
+ gdb_stdlog. This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use debug_prefixed_printf_cond_nofunc in index-cache
+ This changes index-cache.c to use debug_prefixed_printf_cond_nofunc.
+ As a side effect, logs are now written to gdb_stdlog. This is part of
+ PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Send minsym logging to gdb_stdlog
+ This changes minsyms.c to send logging output to gdb_stdlog. This is
+ part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use gdb_stdlog for separate debug file logging
+ This changes the separate debug file logging code (spread across two
+ files) to use gdb_stdlog for its output. This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use debug_prefixed_printf_cond_nofunc in machoread
+ This changes machoread.c to use debug_prefixed_printf_cond_nofunc. As
+ a side effect, the logs are now written to gdb_stdlog. This is part
+ of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use debug_prefixed_printf_cond_nofunc in microblaze.c
+ This changes microblaze.c to use the standard logging macro. As a
+ side effect, logs will now go to gdb_stdlog. This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Send debugging data to gdb_stdlog in mips-linux-nat.c
+ This changes mips-linux-nat.c to send some logging output to
+ gdb_stdlog, rather than stdout. This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Send arch-utils error messages to gdb_stderr
+ This changes arch-utils.c to send some error messages to gdb_stderr.
+ This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Use correct stream for process record output
+ The process record code often emits unfiltered output. In some cases,
+ this output ought to go to gdb_stderr (but see below). In other
+ cases, the output is guarded by a logging variable and so ought to go
+ to gdb_stdlog. This patch makes these changes.
+
+ Note that in many cases, the output to stderr is followed by a
+ "return -1", which is how process record indicates an error. It seems
+ to me that calling error here would be preferable, because, in many
+ cases, that's all the caller does when it sees a -1. However, I
+ haven't made this change.
+
+ This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Send jit.c errors to gdb_stderr
+ jit.c writes some error messages to gdb_stdout, but using gdb_stderr
+ is better. This is part of PR gdb/7233.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Fix logging redirection bug with pager
+ I noticed yesterday that if gdb output is redirected to a file, the
+ pager will still be active. This is irritating, because the output
+ isn't actually visible -- just the pager prompt. Looking in bugzilla,
+ I found that this had been filed 17 years ago, as PR cli/8798.
+
+ This patch fixes the bug. It changes the pagination code to query the
+ particular ui-file to see if paging is allowable. The ui-file
+ implementations are changed so that only the stdout implementation and
+ a tee (where one sub-file is stdout) can page.
+
+ Regression tested on x86-64 Fedora 34.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8798
+
+2021-12-29 Tom Tromey <tom@tromey.com>
+
+ Remove unusual use of core_addr_eq and core_addr_hash
+ gdbtypes.h uses core_addr_eq and core_addr_hash in a weird way: taking
+ the address of a member and then passing this (as a void*) to these
+ functions.
+
+ It seems better to simply inline the ordinary code here. CORE_ADDR is
+ a scalar so it can be directly compared, and the identity hash
+ function seems safe to assume as well.
+
+ After this, core_addr_eq and core_addr_hash are unused, so this patch
+ removes them.
+
+2021-12-29 Lancelot SIX <lancelot.six@amd.com>
+
+ gdb: Copy inferior properties in clone-inferior
+ This commit ensures that the following settings are cloned from one
+ inferior to the new one when processing the clone-inferior command:
+ - inferior-tty
+ - environment variables
+ - cwd
+ - args
+
+ Some of those parameters can be passed as command line arguments to GDB
+ (-args and -tty), so one could expect the clone-inferior to respect
+ those flags. The following debugging session illustrates that:
+
+ gdb -nx -quiet -batch \
+ -ex "show args" \
+ -ex "show inferior-tty" \
+ -ex "clone-inferior" \
+ -ex "inferior 2" \
+ -ex "show args" \
+ -ex "show inferior-tty" \
+ -tty=/some/tty \
+ -args echo foo bar
+ Argument list to give program being debugged when it is started is "foo bar".
+ Terminal for future runs of program being debugged is "/some/tty".
+ [New inferior 2]
+ Added inferior 2.
+ [Switching to inferior 2 [<null>] (/bin/echo)]
+ Argument list to give program being debugged when it is started is "".
+ Terminal for future runs of program being debugged is "".
+
+ The other properties this commit copies on clone (i.e. CWD and the
+ environment variables) are included since they are related (in the sense
+ that they influence the runtime behavior of the program) even if they
+ cannot be directly set using command line switches.
+
+ There is a chance that this patch changes existing user workflow. I
+ think that this change is mostly harmless. If users want to start a new
+ inferior based on an existing one, they probably already propagate those
+ settings to the new inferior in some way.
+
+ Tested on x86_64-linux.
+
+ Change-Id: I3b1f28b662f246228b37bb24c2ea1481567b363d
+
+2021-12-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ elf32-i386: Fix a typo in GOT comments
+ Entry offsets in the global offset table are multiples of 4, not 8.
+
+ * elf32-i386.c (elf_i386_relocate_section): Fix a typo in GOT
+ comments.
+
+2021-12-28 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Don't check non-thin archive member file size
+ There is no need to check member file size for thin archive member.
+
+ * bfdio.c (bfd_bread): Don't check non-thin archive member file
+ size.
+
+2021-12-28 Alan Modra <amodra@gmail.com>
+
+ gas reloc sorting
+ In some cases, eg. riscv_pre_output_hook, gas generates out-of-order
+ relocations. Various places in the linker assume relocs are sorted
+ by increasing r_offset, which is normally the case. Provide
+ GAS_SORT_RELOCS to handle unsorted relocs.
+
+ bfd/
+ PR 28709
+ * elf32-nds32.c (nds32_insertion_sort): Make static.
+ * elf32-nds32.h (nds32_insertion_sort): Delete declaration.
+ gas/
+ PR 28709
+ * write.c (write_relocs): Implement reloc sorting by r_offset
+ when GAS_SORT_RELOCS.
+ * config/tc-nds32.c (compar_relent, nds32_set_section_relocs): Delete.
+ * config/tc-nds32.h (nds32_set_section_relocs): Don't declare.
+ (SET_SECTION_RELOCS): Don't define.
+ (GAS_SORT_RELOCS): Define.
+ * config/tc-riscv.h (GAS_SORT_RELOCS): Define.
+
+2021-12-28 jiawei <jiawei@iscas.ac.cn>
+
+ ld: Fix testcase errors due to -shared not support.
+ Reviewed-by: Jim Wilson <jim.wilson.gcc@gmail.com>
+
+ ld/ChangeLog:
+
+ * testsuite/ld-ctf/ctf.exp: Add shared lib check.
+ * testsuite/ld-plugin/lto.exp: Add lto shared check.
+
+2021-12-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-27 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Update comments for check_relocs in elf_backend_data
+ Since
+
+ commit 5c3261b0e834647cf9eb555320e20871b7854f98
+ Author: H.J. Lu <hjl.tools@gmail.com>
+ Date: Mon Oct 16 03:49:54 2017 -0700
+
+ ELF: Call check_relocs after opening all inputs
+
+ check_relocs is called after opening all inputs.
+
+ * elf-bfd.h (elf_backend_data::check_relocs): Update comments.
+
+2021-12-27 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Remove emultempl/linux.em
+ Remove emultempl/linux.em whose last usage was removed by
+
+ commit c65c21e1ffd1e02d9970a4bca0b7e384788a50f0
+ Author: Alan Modra <amodra@gmail.com>
+ Date: Mon Apr 16 22:14:01 2018 +0930
+
+ various i386-aout and i386-coff target removal
+
+ Also tidies some other aout leftovers in binutils-common.exp.
+
+2021-12-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-24 Tom Tromey <tom@tromey.com>
+
+ Remove gdb_print_host_address
+ gdb_print_host_address is just a simple wrapper around
+ fprintf_filtered. However, it is readily replaced in all callers by a
+ combination of %s and call to host_address_to_string. This also
+ simplifies the code, so I think it's worthwhile to remove this
+ function.
+
+ Regression tested on x86-64 Fedora 64.
+
+2021-12-24 Tom Tromey <tom@tromey.com>
+
+ Move gdb_bfd_errmsg to gdb_bfd.c
+ gdb_bfd.c contains most of gdb's BFD-related utility functions.
+ However, gdb_bfd_errmsg is in utils.c. It seemed better to me to move
+ this out of util.[ch] and into the BFD-related file instead.
+
+ Tested by rebuilding.
+
+2021-12-24 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Rewrite the csr testcases.
+ Maskray (Fangrui Song) had suggested me before that we should combine
+ multiple testcases into one file as possible as we can. So that we can
+ more easily understand what these test cases are testing, and easier to
+ maintain. Therefore, this patch rewrites all csr testcases, to make them
+ more clean.
+
+ gas/
+ * testsuite/gas/riscv/csr-fail-nonexistent.d: Renamed from
+ priv-reg-fail-nonexistent testcase.
+ * testsuite/gas/riscv/csr-fail-nonexistent.: Likewise.
+ * testsuite/gas/riscv/csr-fail-nonexistent.s: Likewise.
+ * testsuite/gas/riscv/csr-insns-pseudo-noalias.d: Renamed from
+ priv-reg-pseudo testcase.
+ * testsuite/gas/riscv/csr-insns-pseudo.d: Likewise.
+ * testsuite/gas/riscv/csr-insns-pseudo.s: Likewise.
+ * testsuite/gas/riscv/csr-insns-read-only.d: Renamed from
+ priv-reg-fail-read-only-02 testcase.
+ * testsuite/gas/riscv/csr-insns-read-only.l: Likewise.
+ * testsuite/gas/riscv/csr-insns-read-only.s: Likewise.
+ * testsuite/gas/riscv/h-ext-32.d: Moved hypervisor csrs to csr.s.
+ * testsuite/gas/riscv/h-ext-32.s: Likewise.
+ * testsuite/gas/riscv/h-ext-64.d: Likewise.
+ * testsuite/gas/riscv/h-ext-64.s: Likewise.
+ * testsuite/gas/riscv/csr.s: Renamed from priv-reg.s, and then
+ added the hypervisor csrs.
+ * testsuite/gas/riscv/csr-version-1p9p1.d: The csr testcase when
+ the privileged spec is 1.9.1. Also tested all invalid csr warnings
+ when -mcsr-check is enabled.
+ * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p10.d: Likewise, but the
+ privileged spec is 1.10..
+ * testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p11.d: Likewise, but the
+ privileged spec is 1.11.
+ * testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+ * testsuite/gas/riscv/csr-version-1p12.d: Likewise, but the
+ privileged spec is 1.12.
+ * testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+ * testsuite/gas/riscv/priv-reg*: Removed or Renamed.
+
+2021-12-24 Vineet Gupta <vineetg@rivosinc.com>
+
+ RISC-V: Hypervisor ext: support Privileged Spec 1.12
+ This is the Hypervisor Extension 1.0
+
+ - Hypervisor Memory-Management Instructions
+ HFENCE.VVMA, HFENCE.GVMA,
+
+ - Hypervisor Virtual Machine Load and Store Instructions
+ HLV.B, HLV.BU, HSV.B,
+ HLV.H, HLV.HU, HLVX.HU, HSB.H,
+ HLV.W, HLV.WU, HLVX.WU, HSV.W,
+ HLV.D, HSV.D
+
+ - Hypervisor CSRs (some new, some address changed)
+ hstatus, hedeleg, hideleg, hie, hcounteren, hgeie, htval, hip, hvip,
+ htinst, hgeip, henvcfg, henvcfgh, hgatp, hcontext, htimedelta, htimedeltah,
+ vsstatus, vsie, vstvec, vsscratch, vsepc, vscause, vstval, vsip, vsatp,
+
+ Note that following were added already as part of svinval extension
+ support:
+ HINVAL.GVMA, HINVAL.VVMA
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+ Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
+
+ bfd/
+ * cpu-riscv.c (riscv_priv_specs): Added entry for 1.12.
+ * cpu-riscv.h (enum riscv_spec_class): Added PRIV_SPEC_CLASS_1P12.
+ gas/
+ * config/tc-riscv.c (abort_version): Updated comment.
+ (validate_riscv_insn): Annotate switch-break.
+ * testsuite/gas/riscv/h-ext-32.d: New testcase for hypervisor.
+ * testsuite/gas/riscv/h-ext-32.s: Likewise.
+ * testsuite/gas/riscv/h-ext-64.d: Likewise.
+ * testsuite/gas/riscv/h-ext-64.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Added encodings for hypervisor csrs and
+ instrcutions.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Added hypervisor instrcutions.
+
+2021-12-24 Vineet Gupta <vineetg@rivosinc.com>
+
+ RISC-V: Hypervisor ext: drop Privileged Spec 1.9.1 implementation/tests
+ This makes way for a clean 1.12 based Hypervisor Ext support.
+
+ There are no known implementors of 1.9.1 H-ext. (Per Jim, kendryte k210
+ is based on priv spec 1.9.1, but it seems unlikely that they implemented
+ H-ext).
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+ Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
+
+ gas/
+ * testsuite/gas/riscv/csr-dw-regnums.d: Drop the hypervisor csrs
+ defined in the privileged spec 1.9.1.
+ * testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-read-only-01.s: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/priv-reg.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Drop the hypervisor csrs defined in the
+ privileged spec 1.9.1.
+
+2021-12-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: resolve some duplicate testnames in gdb.mi
+ Set of fixes to resolve some duplicate test names in the gdb.mi/
+ directory. There should be no real test changes after this set of
+ fixes, they are all either:
+
+ - Adding with_test_prefix type constructs to make test names unique,
+ or
+
+ - Changing the test name to be more descriptive, or better reflect
+ the test being run.
+
+2021-12-23 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/remote: handle attach when stop packet lacks thread-id
+ Bug PR gdb/28405 reports a regression when using attach with an
+ extended-remote target. In this case the target is not including a
+ thread-id in the stop packet it sends back after the attach.
+
+ The regression was introduced with this commit:
+
+ commit 8f66807b98f7634c43149ea62e454ea8f877691d
+ Date: Wed Jan 13 20:26:58 2021 -0500
+
+ gdb: better handling of 'S' packets
+
+ The problem is that when GDB processes the stop packet, it sees that
+ there is no thread-id and so has to "guess" which thread the stop
+ should apply to.
+
+ In this case the target only has one thread, so really, there's no
+ guessing needed, but GDB still runs through the same process, this
+ shouldn't cause us any problems.
+
+ However, after the above commit, GDB now expects itself to be more
+ internally consistent, specifically, only a thread that GDB thinks is
+ resumed, can be a candidate for having stopped.
+
+ It turns out that, when GDB attaches to a process through an
+ extended-remote target, the threads of the process being attached too,
+ are not, initially, marked as resumed.
+
+ And so, when GDB tries to figure out which thread the stop might apply
+ too, it finds no threads in the processes marked resumed, and so an
+ assert triggers.
+
+ In extended_remote_target::attach we create a new thread with a call
+ to add_thread_silent, rather than remote_target::remote_add_thread,
+ the reason is that calling the latter will result in a call to
+ 'add_thread' rather than 'add_thread_silent'. However,
+ remote_target::remote_add_thread includes additional
+ actions (i.e. calling remote_thread_info::set_resumed and set_running)
+ which are missing from extended_remote_target::attach. These missing
+ calls are what would serve to mark the new thread as resumed.
+
+ In this commit I propose that we add an extra parameter to
+ remote_target::remote_add_thread. This new parameter will force the
+ new thread to be added with a call to add_thread_silent. We can now
+ call remote_add_thread from the ::attach method, the extra
+ actions (listed above) will now be performed, and the thread will be
+ left in the correct state.
+
+ Additionally, in PR gdb/28405, a segfault is reported. This segfault
+ triggers when 'set debug remote 1' is used before trying to reproduce
+ the original assertion failure. The cause of this is in
+ remote_target::select_thread_for_ambiguous_stop_reply, where we do
+ this:
+
+ remote_debug_printf ("first resumed thread is %s",
+ pid_to_str (first_resumed_thread->ptid).c_str ());
+ remote_debug_printf ("is this guess ambiguous? = %d", ambiguous);
+
+ gdb_assert (first_resumed_thread != nullptr);
+
+ Notice that when debug printing is on we dereference
+ first_resumed_thread before we assert that the pointer is not
+ nullptr. This is the cause of the segfault, and is resolved by moving
+ the assert before the debug printing code.
+
+ I've extended an existing test, ext-attach.exp, so that the original
+ test is run multiple times; we run in the original mode, as normal,
+ but also, we now run with different packets disabled in gdbserver. In
+ particular, disabling Tthread would trigger the assertion as it was
+ reported in the original bug. I also run the test in all-stop and
+ non-stop modes now for extra coverage, we also run the tests with
+ target-async enabled, and disabled.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28405
+
+2021-12-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: on x86-64 non-trivial C++ objects are returned in memory
+ Fixes PR gdb/28681. It was observed that after using the `finish`
+ command an incorrect value was displayed in some cases. Specifically,
+ this behaviour was observed on an x86-64 target.
+
+ Consider this test program:
+
+ struct A
+ {
+ int i;
+
+ A ()
+ { this->i = 0; }
+ A (const A& a)
+ { this->i = a.i; }
+ };
+
+ A
+ func (int i)
+ {
+ A a;
+ a.i = i;
+ return a;
+ }
+
+ int
+ main ()
+ {
+ A a = func (3);
+ return a.i;
+ }
+
+ And this GDB session:
+
+ $ gdb -q ex.x
+ Reading symbols from ex.x...
+ (gdb) b func
+ Breakpoint 1 at 0x401115: file ex.cc, line 14.
+ (gdb) r
+ Starting program: /home/andrew/tmp/ex.x
+
+ Breakpoint 1, func (i=3) at ex.cc:14
+ 14 A a;
+ (gdb) finish
+ Run till exit from #0 func (i=3) at ex.cc:14
+ main () at ex.cc:23
+ 23 return a.i;
+ Value returned is $1 = {
+ i = -19044
+ }
+ (gdb) p a
+ $2 = {
+ i = 3
+ }
+ (gdb)
+
+ Notice how after the `finish` the contents of $1 are junk, but, when I
+ immediately ask for the value of `a`, I get back the correct value.
+
+ The problem here is that after the finish command GDB calls the
+ function amd64_return_value to figure out where the return value can
+ be found (on x86-64 targets anyway).
+
+ This function makes the wrong choice for the struct A in our case, as
+ sizeof(A) <= 8, then amd64_return_value decides that A will be
+ returned in a register. GDB then reads the return value register an
+ interprets the contents as an instance of A.
+
+ Unfortunately, A is not trivially copyable (due to its copy
+ constructor), and the sys-v specification for argument and return
+ value passing, says that any non-trivial C++ object should have space
+ allocated for it by the caller, and the address of this space is
+ passed to the callee as a hidden first argument. The callee should
+ then return the address of this space as the return value.
+
+ And so, the register that GDB is treating as containing an instance of
+ A, actually contains the address of an instance of A (in this case on
+ the stack), this is why GDB shows the incorrect result.
+
+ The call stack within GDB for where we actually go wrong is this:
+
+ amd64_return_value
+ amd64_classify
+ amd64_classify_aggregate
+
+ And it is in amd64_classify_aggregate that we should be classifying
+ the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently
+ do (via a call to amd64_classify_aggregate_field).
+
+ At the top of amd64_classify_aggregate we already have this logic:
+
+ if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type))
+ {
+ theclass[0] = theclass[1] = AMD64_MEMORY;
+ return;
+ }
+
+ Which handles some easy cases where we know a struct will be placed
+ into memory, that is (a) the struct is more than 16-bytes in size,
+ or (b) the struct has any unaligned fields.
+
+ All we need then, is to add a check here to see if the struct is
+ trivially copyable. If it is not then we know the struct will be
+ passed in memory.
+
+ I originally structured the code like this:
+
+ if (TYPE_LENGTH (type) > 16
+ || amd64_has_unaligned_fields (type)
+ || !language_pass_by_reference (type).trivially_copyable)
+ {
+ theclass[0] = theclass[1] = AMD64_MEMORY;
+ return;
+ }
+
+ This solved the example from the bug, and my small example above. So
+ then I started adding some more extensive tests to the GDB testsuite,
+ and I ran into a problem. I hit this error:
+
+ gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.
+
+ This problem is triggered from:
+
+ amd64_classify_aggregate
+ amd64_has_unaligned_fields
+ field::loc_bitpos
+
+ Inside the unaligned field check we try to get the bit position of
+ each field. Unfortunately, in some cases the field location is not
+ FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK.
+
+ An example that shows this bug is:
+
+ struct B
+ {
+ short j;
+ };
+
+ struct A : virtual public B
+ {
+ short i;
+
+ A ()
+ { this->i = 0; }
+ A (const A& a)
+ { this->i = a.i; }
+ };
+
+ A
+ func (int i)
+ {
+ A a;
+ a.i = i;
+ return a;
+ }
+
+ int
+ main ()
+ {
+ A a = func (3);
+ return a.i;
+ }
+
+ It is the virtual base class, B, that causes the problem. The base
+ class is represented, within GDB, as a field within A. However, the
+ location type for this field is a DWARF_BLOCK.
+
+ I spent a little time trying to figure out how to convert the
+ DWARF_BLOCK to a BITPOS, however, I realised that, in this case at
+ least, conversion is not needed.
+
+ The C++ standard says that a class is not trivially copyable if it has
+ any virtual base classes. And so, in this case, even if I could
+ figure out the BITPOS for the virtual base class fields, I know for
+ sure that I would immediately fail the trivially_copyable check. So,
+ lets just reorder the checks in amd64_classify_aggregate to:
+
+ if (TYPE_LENGTH (type) > 16
+ || !language_pass_by_reference (type).trivially_copyable
+ || amd64_has_unaligned_fields (type))
+ {
+ theclass[0] = theclass[1] = AMD64_MEMORY;
+ return;
+ }
+
+ Now, if we have a class with virtual bases we will fail quicker, and
+ avoid the unaligned fields check completely.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28681
+
+2021-12-23 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make use of SCOPE_EXIT to manage thread executing state
+ While working on another patch relating to how GDB manages threads
+ executing and resumed state, I spotted the following code in
+ record-btrace.c:
+
+ executing = tp->executing ();
+ set_executing (proc_target, inferior_ptid, false);
+
+ id = null_frame_id;
+ try
+ {
+ id = get_frame_id (get_current_frame ());
+ }
+ catch (const gdb_exception &except)
+ {
+ /* Restore the previous execution state. */
+ set_executing (proc_target, inferior_ptid, executing);
+
+ throw;
+ }
+
+ /* Restore the previous execution state. */
+ set_executing (proc_target, inferior_ptid, executing);
+
+ return id;
+
+ I notice that we only catch the exception so we can call
+ set_executing, and this is the same call to set_executing that we need
+ to perform in the non-exception return path.
+
+ This would be much cleaner if we could use SCOPE_EXIT to avoid the
+ try/catch, so lets do that.
+
+ While cleaning this up, I also applied a similar patch to
+ record-full.c, though there's no try/catch in that case, but using
+ SCOPE_EXIT makes the code safe if, in the future, we do start throwing
+ exceptions.
+
+ There should be no user visible changes after this commit.
+
+2021-12-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/doc: add some index entries relating to mi-async setting
+ I noticed that the mi-async setting was not referenced from the index
+ in any way, this commit tries to rectify that a bit.
+
+ The @cindex lines I think are not controversial, these same index
+ entries are used elsewhere in the manual for async related topics (see
+ @node Background Execution).
+
+ The only bit that might be controversial is that I've added a @kindex
+ entry for 'set mi-async' when the command is documented as '-gdb-set
+ mi-async' (with a similar difference for the show/-gdb-show).
+
+ My reasoning here is that nothing else is indexed under -gdb-set or
+ -gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for
+ set/show anything that is documented under set/show can be adjusted
+ using -gdb-set/-gdbshow, and so, I've tried to keep the index
+ consistent for mi-async.
+
+2021-12-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: convert 'set debug lin-lwp' to a boolean command
+ Convert the 'set debug lin-lwp' command to a boolean. Adds a new
+ LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one
+ place (linux_nat_target::stop).
+
+ The manual entry for 'set debug lin-lwp' is already vague about
+ exactly what arguments this command takes, and the description talks
+ about turning debug on and off, so I don't think there's any updates
+ required there.
+
+ I have updated the doc strings shown when the users enters 'help show
+ debug lin-lwp' or 'help show debug lin-lwp'. The old title lines used
+ to talk about the 'GNU/Linux lwp module', but this debug flag is now
+ used for any native linux target debug, so we now talk about
+ 'GNU/Linux native target'. The body string for this setting has been
+ changed from 'Enables printf debugging output.' to 'When on, print
+ debug messages relating to the GNU/Linux native target.', the old
+ value looks like a cut&paste error to me.
+
+2021-12-22 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add threads debugging switch
+ Add new commands:
+
+ set debug threads on|off
+ show debug threads
+
+ Prints additional debug information relating to thread creation and
+ deletion.
+
+ GDB already announces when threads are created of course.... most of
+ the time, but sometimes threads are added silently, in which case this
+ debug message is the only mechanism to see the thread being added.
+ Also, though GDB does announce when a thread exits, it doesn't
+ announce when the thread object is deleted, I've added a debug message
+ for that.
+
+ Additionally, having message printed through the debug system will
+ cause the messages to be nested to an appropriate depth when other
+ debug sub-systems are turned on (especially things like `infrun` and
+ `lin-lwp`).
+
+2021-12-22 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Update Scalar Crypto testcases.
+ Add opcodes in testcases to make sure every instruction generate
+ right opcode after disassemble.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/k-ext-64.d: Add opcode detect.
+ * testsuite/gas/riscv/k-ext.d: Ditto.
+ * testsuite/gas/riscv/zbkb-32.d: Ditto.
+ * testsuite/gas/riscv/zbkb-64.d: Ditto.
+ * testsuite/gas/riscv/zbkc-32.d: Ditto.
+ * testsuite/gas/riscv/zbkc-64.d: Ditto.
+ * testsuite/gas/riscv/zbkx-32.d: Ditto.
+ * testsuite/gas/riscv/zbkx-64.d: Ditto.
+ * testsuite/gas/riscv/zknd-32.d: Ditto.
+ * testsuite/gas/riscv/zknd-64.d: Ditto.
+ * testsuite/gas/riscv/zkne-32.d: Ditto.
+ * testsuite/gas/riscv/zkne-64.d: Ditto.
+ * testsuite/gas/riscv/zknh-32.d: Ditto.
+ * testsuite/gas/riscv/zknh-64.d: Ditto.
+ * testsuite/gas/riscv/zksed-32.d: Ditto.
+ * testsuite/gas/riscv/zksed-64.d: Ditto.
+ * testsuite/gas/riscv/zksh-32.d: Ditto.
+ * testsuite/gas/riscv/zksh-64.d: Ditto.
+
+2021-12-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbarch-components.py: change empty "params" tuples to empty lists
+ During review, it was suggested to change the "params" parameter from a
+ tuple to a list, for esthetic reasons. The empty ones are still tuples
+ though, they should probably be changed to be empty lists, for
+ consistency. It does not change anything in the script result.
+
+ Change-Id: If13c6c527aa167a5ee5b45740e5f1bda1e9517e4
+
+2021-12-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-21 Luis Machado <luis.machado@linaro.org>
+
+ [AArch64] Fix typo in error messages
+ Fix mispelling of PROT_ME to PROT_MTE in the error messages.
+
+2021-12-21 Joel Sherrill <joel@rtems.org>
+
+ Obsolete m32c-rtems and m32r-rtems
+ 2020-12-20 Joel Sherrill <joel@rtems.org>
+
+ bfd/
+ * config.bfd (m32c-*-rtems*): Remove target.
+
+ ld/
+ * configure.tgt (m32c-*-rtems*): Remove target.
+ * configure.tgt (m32r-*-rtems*): Remove target.
+
+2021-12-21 Jan Beulich <jbeulich@suse.com>
+
+ x86: -mfence-as-lock-add=yes doesn't work for 16-bit mode
+ Rather than trying to fix this (which would require making an assumption
+ on the upper half of %esp being zero), simply issue an error. While at
+ it, since the generated code is in conflict with -momit-lock-prefix=yes,
+ issue an error in that case as well.
+
+ gas/ELF: avoid below-base ref in obj_elf_parse_section_letters()
+ We would better be prepared for 'm' being the first character of the
+ incoming string.
+
+2021-12-21 Alan Modra <amodra@gmail.com>
+
+ Typo fixes in binutils doc
+ * doc/binutils.texi: Fix typos.
+
+2021-12-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-20 Tom Tromey <tom@tromey.com>
+
+ Remove print_spaces
+ This removes the print_spaces helper function, in favor of using the
+ "*%s" idiom that's already used in many places in gdb. One spot (in
+ symmisc.c) is changed to use print_spaces_filtered, because the rest
+ of that function is using filtered output. (This highlights one way
+ that the printf idiom is better -- this error is harder to make when
+ using that.)
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-12-20 Tom Tromey <tom@tromey.com>
+
+ Remove puts_debug
+ I noticed that puts_debug isn't used in the tree. git log tells me
+ that the last use was removed in 2015:
+
+ commit 40e0b27177e747600d3ec186458fe0e482a1cf77
+ Author: Pedro Alves <palves@redhat.com>
+ Date: Mon Aug 24 15:40:26 2015 +0100
+
+ Delete the remaining ROM monitor targets
+
+ ... and this commit mentions that the code being removed here probably
+ hadn't worked for 6 years prior to that.
+
+ Based on this, I'm removing puts_debug. I don't think it's useful.
+ Tested by rebuilding.
+
+2021-12-20 Tom Tromey <tom@tromey.com>
+
+ Make n_spaces return a const char *
+ n_spaces keeps the spaces in a static buffer. If a caller overwrites
+ these, it may give an incorrect result to a subsequent caller. So,
+ make the return type const to help avoid this outcome.
+
+2021-12-20 Enze Li <lienze2010@hotmail.com>
+
+ Add Enze Li to gdb/MAINTAINERS
+
+2021-12-20 Joel Brobecker <brobecker@adacore.com>
+
+ gdb/ada-exp.y: Reformat comment to follow GDB's coding standards
+ This commit reformats a comment in gdb/ada-exp.y to avoid
+ the leading '*' at the beginning of each line of the comment.
+
+ gdb/ada-lang.h: Reformat comment to follow coding standards
+ This commit reformats a comment in gdb/ada-lang.h to avoid
+ the leading '*' at the beginning of each line of the comment.
+
+2021-12-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-19 Alan Modra <amodra@gmail.com>
+
+ Obsolete m32c-rtems
+
+ readelf: avoid a possible divide by zero
+ * readelf.c (process_section_headers): Check SHT_RELR entsize.
+
+2021-12-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-18 Enze Li <lienze2010@hotmail.com>
+
+ gdb: add "exit" command as an alias for "quit"
+ This command adds the "exit" command as an alias for the "quit"
+ command, as requested in PR gdb/28406.
+
+ The documentation is also updated to mention this new command.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28406
+
+2021-12-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add assert in remote_target::wait relating to async being off
+ While working on another patch I ended up in a situation where I had
+ async mode disabled (with 'maint set target-async off'), but the async
+ event token got marked anyway.
+
+ In this situation GDB was continually calling into
+ remote_target::wait, however, the async token would never become
+ unmarked as the unmarking is guarded by target_is_async_p.
+
+ We could just unconditionally unmark the token, but that would feel
+ like just ignoring a bug, so, instead, lets assert that if
+ !target_is_async_p, then the async token should not be marked.
+
+ This assertion would have caught my earlier mistake.
+
+ There should be no user visible changes with this commit.
+
+2021-12-18 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/remote: some fixes for 'maint set target-async off'
+ While working on another patch relating to remote targets, I wanted to
+ test with 'maint set target-async off' in place. Unfortunately I ran
+ into some problems. This commit is an attempt to fix one of the
+ issues I hit.
+
+ In my particular case I was actually running with:
+
+ maint set target-async off
+ maint set target-non-stop off
+
+ that is, we're telling GDB to force the targets to operate in
+ non-async mode, and in all-stop mode. Here's my GDB session showing
+ the problem:
+
+ (gdb) maintenance set target-async off
+ (gdb) maintenance set target-non-stop off
+ (gdb) target extended-remote :54321
+ Remote debugging using :54321
+ (gdb) attach 2365960
+ Attaching to process 2365960
+ No unwaited-for children left.
+ (gdb)
+
+ Notice the 'No unwaited-for children left.' error, this is the
+ problem. There's no reason why GDB should not be able to attach to
+ the process.
+
+ The problem is this:
+
+ 1. The user runs 'attach PID' and this sends GDB into attach_command
+ in infcmd.c. From here we call the ::attach method on the attach
+ target, which will be the extended_remote_target.
+
+ 2. In extended_remote_target::attach, we attach to the remote target
+ and get the first reply (which is a stop packet). We put off
+ processing the stop packet until the end of ::attach. We setup the
+ inferior and thread to represent the process we attached to, and
+ download the target description. Finally, we process the initial
+ stop packet.
+
+ If '!target_is_non_stop_p ()' and '!target_can_async_p ()', which is
+ the case for us given the maintenance commands we used, we cache the
+ stop packet within the remote_state::buf for later processing.
+
+ 3. Back in attach_command, if 'target_is_non_stop_p ()' then we
+ request that the target stops. This will either process any cached
+ stop replies, or request that the target stops, and process the stop
+ replies. However, this code is not what we use due to non-stop mode
+ being disabled. So, we skip to the next step which is to call
+ validate_exec_file.
+
+ 4. Calling validate_exec_file can cause packets to be sent to the
+ remote target, and replies received, the first path I hit is the
+ call to target_pid_to_exec_file, which calls
+ remote_target::pid_to_exec_file, which can then try to read the
+ executable from the remote. Sending an receiving packets will make
+ use of the remote_state::buf object.
+
+ 5. The attempt to attach continues, but the damage is already done...
+
+ So, the problem is that, in step #2 we cache a stop reply in the
+ remote_state::buf, and then in step #4 we reuse the remote_state::buf
+ object, discarding any cached stop reply. As a result, the initial
+ stop, which is sent when GDB first attaches to the target, is lost.
+
+ This problem can clearly be seen, I feel, by looking at the
+ remote_state::cached_wait_status flag. This flag tells GDB if there
+ is a wait status cached in remote_state::buf. However, in
+ remote_target::putpkt_binary and remote_target::getpkt_or_notif_sane_1
+ this flag is just set back to 0, doing this immediately discards any
+ cached data.
+
+ I don't know if this scheme ever made sense, looking at commit
+ 2d717e4f8a54, where the cached_wait_status flag was added, it appears
+ that there was nothing between where the stop was cached, and where
+ the stop was consumed, so, I suspect, there never was a situation
+ where we ended up in putpkt_binary or getpkt_or_notif_sane_1 and
+ needed to clear to the flag, maybe the clearing was added "just in
+ case". Whatever the history, I claim that this clearing this flag is
+ no longer a good idea.
+
+ So, my first step toward fixing this issue was to replace the two
+ instances of 'rs->cached_wait_status = 0;' in ::putpkt_binary and
+ ::getpkt_or_notif_sane_1 with 'gdb_assert (rs->cached_wait_status ==
+ 0);', this, at least would show me when GDB was doing something
+ dangerous, and indeed, this assert is now hit in my test case above.
+
+ I did play with using some kind of scoped restore to backup, and
+ restore the remote_state::buf object in all the places within remote.c
+ that I was hitting where the ::buf was being corrupted. The first
+ problem with this is that, where the ::cached_wait_status flag is
+ reset is _not_ where ::buf is corrupted. For the ::putpkt_binary
+ case, by the time we get to the method the buffer has already been
+ corrupted in many cases, so we end up needing to add the scoped
+ save/restore within the callers, which means we need the save/restore
+ in _lots_ of places.
+
+ Plus, using this save/restore model feels like the wrong solution. I
+ don't think that it's obvious that the buffer might be holding cached
+ data, and I think it would be too easy for new corruptions of the
+ buffer to be introduced, which could easily go unnoticed for a long
+ time.
+
+ So, I really wanted a solution that didn't require us to cache data in
+ the ::buf object.
+
+ Luckily, I think we already have such a solution in place, the
+ remote_state::stop_reply_queue, it seems like this does exactly the
+ same task, just in a slightly different way. With the
+ ::stop_reply_queue, the stop packets are processed upon receipt and
+ the stop_reply object is added to the queue. With the ::buf cache
+ solution, the unprocessed stop reply is cached in the ::buf, and
+ processed later.
+
+ So, finally, in this commit, I propose to remove the
+ remote_state::cached_wait_status flag and to stop using the ::buf to
+ cache stop replies. Instead, stop replies will now always be stored
+ in the ::stop_reply_queue.
+
+ There are two places where we use the ::buf to hold a cached stop
+ reply, the first is in the ::attach method, and the second is in
+ remote_target::start_remote, however, the second of these cases is far
+ less problematic, as after caching the stop reply in ::buf we call the
+ global start_remote function, which does very little work before
+ calling normal_stop, which processes the cached stop reply. However,
+ my plan is to switch both users over to using ::stop_reply_queue so
+ that the old (unsafe) ::cached_wait_status mechanism can be completely
+ removed.
+
+ The next problem is that the ::stop_reply_queue is currently only used
+ for async-mode, and so, in remote_target::push_stop_reply, where we
+ push stop_reply objects into the ::stop_reply_queue, we currently also
+ mark the async event token. I've modified this so we only mark the
+ async event token if 'target_is_async_p ()' - note, _is_, not _can_
+ here. The ::push_stop_reply method is called in places where async
+ mode has been temporarily disabled, but, when async mode is switched
+ back on (see remote_target::async) we will mark the event token if
+ there are events in the queue.
+
+ Another change of interest is in remote_target::remote_interrupt_as.
+ Previously this code checked ::cached_wait_status, but didn't check
+ for events in the ::stop_reply_queue. Now that ::cached_wait_status
+ has been removed we now check the queue length instead, which should
+ have the same result.
+
+ Finally, in remote_target::wait_as, I've tried to merge the processing
+ of the ::stop_reply_queue with how we used to handle the
+ ::cached_wait_status flag.
+
+ Currently, when processing the ::stop_reply_queue we call
+ process_stop_reply and immediately return. However, when handling
+ ::cached_wait_status we run through the whole of ::wait_as, and return
+ at the end of the function.
+
+ If we consider a standard stop packet, the two differences I see are:
+
+ 1. Resetting of the remote_state::waiting_for_stop_reply, flag; this
+ is not currently done when processing a stop from the
+ ::stop_reply_queue.
+
+ 2. The final return value has the possibility of being adjusted at
+ the end of ::wait_as, as well as there being calls to
+ record_currthread, non of which are done if we process a stop from
+ the ::stop_reply_queue.
+
+ After discussion on the mailing list:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-December/184535.html
+
+ it was suggested that, when an event is pushed into the
+ ::stop_reply_queue, the ::waiting_for_stop_reply flag is never going
+ to be set. As a result, we don't need to worry about the first
+ difference. I have however, added a gdb_assert to validate the
+ assumption that the flag is never going to be set. If in future the
+ situation ever changes, then we should find out pretty quickly.
+
+ As for the second difference, I have resolved this by having all stop
+ packets taken from the ::stop_reply_queue, pass through the return
+ value adjustment code at the end of ::wait_as.
+
+ An example of a test that reveals the benefits of this commit is:
+
+ make check-gdb \
+ RUNTESTFLAGS="--target_board=native-extended-gdbserver \
+ GDBFLAGS='-ex maint\ set\ target-async\ off \
+ -ex maint\ set\ target-non-stop\ off' \
+ gdb.base/attach.exp"
+
+ For testing I've been running test on x86-64/GNU Linux, and run with
+ target boards unix, native-gdbserver, and native-extended-gdbserver.
+ For each board I've run with the default GDBFLAGS, as well as with:
+
+ GDBFLAGS='-ex maint\ set\ target-async\ off \
+ -ex maint\ set\ target-non-stop\ off' \
+
+ Though running with the above GDBFLAGS is clearly a lot more unstable
+ both before and after my patch, I'm not seeing any consistent new
+ failures with my patch, except, with the native-extended-gdbserver
+ board, where I am seeing new failures, but only because more tests are
+ now running. For that configuration alone I see the number of
+ unresolved go down by 49, the number of passes goes up by 446, and the
+ number of failures also increases by 144. All of the failures are new
+ tests as far as I can tell.
+
+2021-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ x86: Terminate mnemonicendp in swap_operand()
+ Tested on x86_64-pc-linux-gnu.
+
+ opcodes/ChangeLog:
+ 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * i386-dis.c (swap_operand): Terminate mnemonicendp.
+
+ gas/ChangeLog:
+ 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+ * testsuite/gas/i386/opts-intel.d: Updated expected disassembly.
+ * testsuite/gas/i386/opts.d: Likewise.
+ * testsuite/gas/i386/sse2avx-opts-intel.d: Likewise.
+ * testsuite/gas/i386/sse2avx-opts.d: Likewise.
+ * testsuite/gas/i386/x86-64-opts-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-opts.d: Likewise.
+ * testsuite/gas/i386/x86-64-sse2avx-opts-intel.d: Likewise.
+ * testsuite/gas/i386/x86-64-sse2avx-opts.d: Likewise.
+
+2021-12-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-17 Tom Tromey <tom@tromey.com>
+
+ Document gdbarch-components.py
+ This adds a comment to document how to update gdbarch.
+
+ Remove gdbarch.sh
+ This patch runs gdbarch.py and removes gdbarch.sh.
+
+2021-12-17 Simon Marchi <simon.marchi@efficios.com>
+
+ Add new gdbarch generator
+ The new gdbarch generator is a Python program. It reads the
+ "components.py" that was created in the previous patch, and generates
+ gdbarch.c and gdbarch-gen.h.
+
+ This is a relatively straightforward translation of the existing .sh
+ code. It doesn't try very hard to be idiomatic Python or to be
+ especially smart.
+
+ It is, however, incredibly faster:
+
+ $ time ./gdbarch.sh
+
+ real 0m8.197s
+ user 0m5.779s
+ sys 0m3.384s
+
+ $ time ./gdbarch.py
+
+ real 0m0.065s
+ user 0m0.053s
+ sys 0m0.011s
+
+ Co-Authored-By: Tom Tromey <tom@tromey.com>
+
+2021-12-17 Tom Tromey <tom@tromey.com>
+
+ Generate new gdbarch-components.py from gdbarch.sh
+ The new gdbarch.sh approach will be to edit a Python file, rather than
+ adding a line to a certain part of gdbarch.sh. We use the existing sh
+ code, though, to generate the first draft of this .py file.
+
+ Documentation on the format will come in a subsequent patch.
+
+ Note that some info (like "staticdefault") in the current code is
+ actually unused, and so is ignored by this new generator.
+
+2021-12-17 Tom Tromey <tom@tromey.com>
+
+ Do not sort the fields in gdbarch_dump
+ This changes gdbarch.sh so that it no longer sorts the fields in
+ gdbarch_dump. This sorting isn't done anywhere else by gdbarch.sh,
+ and this simplifies the new generator a little bit.
+
+ Do not generate gdbarch.h
+ Now that gdbarch.h has been split, we no longer need the generator
+ code in gdbarch.sh, so remove it.
+
+2021-12-17 Tom Tromey <tom@tromey.com>
+
+ Split gdbarch.h into two files
+ This patch splits gdbarch.h into two files -- gdbarch.h now is
+ editable and hand-maintained, and the new gdbarch-gen.h file is the
+ only thing generated by gdbarch.sh. This lets us avoid maintaining
+ boilerplate in the gdbarch.sh file.
+
+ Note that gdbarch.sh still generates gdbarch.h after this patch. This
+ makes it easier to re-run when rebasing. This code is removed in a
+ subsequent patch.
+
+2021-12-17 Tom Tromey <tom@tromey.com>
+
+ Move ordinary gdbarch code to arch-utils
+ While I think it makes sense to generate gdbarch.c, at the same time I
+ think it is better for ordinary code to be editable in a C file -- not
+ as a hunk of C code embedded in the generator.
+
+ This patch moves this sort of code out of gdbarch.sh and gdbarch.c and
+ into arch-utils.c, then has arch-utils.c include gdbarch.c.
+
+2021-12-17 Maciej W. Rozycki <macro@embecosm.com>
+
+ Avoid redundant operations in `fortran_array_walker'
+ Move inner dimension's element type determination outside the respective
+ loops in `fortran_array_walker'. The operation is exactly the same with
+ each iteration, so there is no point in redoing it for each element and
+ while a smart compiler might be able to move it outside the loop it is
+ regardless a bad coding style. No functional change.
+
+ Initialize `m_ndimensions' in the member initializer list
+ Following our coding convention initialize the `m_ndimensions' member in
+ the member initializer list rather than in the body of the constructor
+ of the `fortran_array_walker' class. No functional change.
+
+2021-12-17 Lancelot SIX <lancelot.six@amd.com>
+ Pedro Alves <pedro@palves.net>
+
+ gdb/tui: install SIGWINCH only when connected to a TTY
+ PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it
+ crashes when it receives a SIGWINCH signal.
+
+ This can be reproduced as follows:
+
+ $ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat
+
+ # from another terminal:
+ $ kill -WINCH %(pidof gdb)
+
+ When doing so, the process crashes in a call to rl_resize_terminal:
+
+ void
+ rl_resize_terminal (void)
+ {
+ _rl_get_screen_size (fileno (rl_instream), 1);
+ ...
+ }
+
+ The problem is that at this point rl_instream has the value NULL.
+
+ The rl_instream variable is supposed to be initialized during a call to
+ readline_initialize_everything, which in a normal startup sequence is
+ called under this call chain:
+
+ tui_interp::init
+ tui_ensure_readline_initialized
+ rl_initialize
+ readline_initialize_everything
+
+ In tui_interp::init, we have the following sequence:
+
+ tui_initialize_io ();
+ tui_initialize_win (); // <- Installs SIGWINCH
+ if (gdb_stdout->isatty ())
+ tui_ensure_readline_initialized (); // <- Initializes rl_instream
+
+ This function unconditionally installs the SIGWINCH signal handler (this
+ is done by tui_initialize_win), and then if gdb_stdout is a TTY it
+ initializes readline. Therefore, if stdout is not a TTY, SIGWINCH is
+ installed but readline is not initialized. In such situation
+ rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its
+ handler and in fine tries to access rl_instream leading to the crash.
+
+ This patch proposes to fix this issue by installing the SIGWINCH signal
+ handler only if GDB is connected to a TTY. Given that this
+ initialization it the only task of tui_initialize_win, this patch moves
+ tui_initialize_win just after the call to
+ tui_ensure_readline_initialized.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056
+ Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: NULL dereference in bfd_elf_set_group_contents
+ * elf-bfd.h (struct output_elf_obj_tdata): Make num_section_syms
+ unsigned.
+ * elf.c (bfd_elf_set_group_contents): Bounds check sec->index
+ and check that entry in elf_section_syms for sec is non-NULL.
+ (_bfd_elf_symbol_from_bfd_symbol): Adjust.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: use after free in _bfd_elf_mips_get_relocated_section_contents
+ Leaving entries on mips_hi16_list from a previous pass over relocs
+ leads to confusing bugs.
+
+ * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents):
+ Free mips_hi16_list entries on error exit.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: abort in wasm_scan_name_function_section
+ Macros like READ_LEB128 in wasm-module.c that alter control flow are
+ evil. Maintainers will break your code if you have hidden ways to
+ reach labels.
+
+ * wasm-module.c (wasm_scan_name_function_section): Don't
+ attempt to bfd_release NULL.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: heap-buffer-overflow in bpf_elf_generic_reloc
+ The bpf reloc howtos are a bit weird, using bitpos to specify an
+ offset from r_offset that is outside the size of the reloc as given by
+ howto.size. That means bfd_get_reloc_size gives the wrong answer for
+ range checking, and thus bfd_reloc_offset_in_range can't be used.
+
+ * elf64-bpf.c (bpf_elf_generic_reloc): Handle bitpos offset reloc
+ range checking.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ ubsan: bfd.c:2519:8: shift exponent 34 is too large
+ * bfd.c (bfd_update_compression_header): Avoid integer overflow.
+
+ asan: buffer overflow in mmo_get_symbols
+ * mmo.c (mmo_get_symbols): Error on symbol name exceeding max length.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ asan: buffer overflow in elfnn-aarch64.c get_plt_type
+ We can't assume .dynamic is a multiple of ElfNN_External_Dyn, at least
+ not when presented with fuzzed object files.
+
+ * elfnn-aarch64.c (get_plt_type): Don't access past end of
+ improperly sized .dynamic.
+
+2021-12-17 Alan Modra <amodra@gmail.com>
+
+ try_build_id_prefix gcc-10 -Wformat-security errors
+ dwarf.c:11300:3: error: format not a string literal and no format arguments [-Werror=format-security]
+ 11300 | f += sprintf (f, prefix);
+
+ PR 28697
+ * dwarf.c (try_build_id_prefix): Avoid -Wformat-security error.
+
+2021-12-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-16 Nick Clifton <nickc@redhat.com>
+
+ Fix AVR assembler so that it creates relocs that will work with linker relaxation.
+ PR 28686
+ gas * config/tc-avr.h (tc_fix_adjustable): Define.
+ * config/tc-avr.c (avr_fix_adjustable): New function.
+ * testsuite/gas/all/gas.exp: Skip tests that need adjustable fixups.
+ * testsuite/gas/elf/elf.exp: Likewise.
+ * testsuite/gas/avr/diffreloc_withrelax.d: Adjust expected output.
+ * testsuite/gas/avr/pc-relative-reloc.d: Adjust expected output.
+
+ ld * testsuite/ld-avr/avr-prop-7.d: Adjust expected output.
+ * testsuite/ld-avr/avr-prop-8.d: Likewise.
+ * testsuite/ld-avr/pr13402.d: Likewise.
+
+2021-12-16 Nick Clifton <nickc@redhat.com>
+
+ When loading separate debug info files, also attempt to locate a file based upon the build-id.
+ PR 28697
+ * dwarf.c (load_build_id_debug_file): New function.
+ (try_build_id_prefix): New function.
+ (check_for_and_load_links): Call load_build_id_debug_file.
+ (debug_displays): Add entry for .note.gnu.build-id.
+ * dwarf.h (enum dwarf_section_display_enum): Add
+ note_gnu_build_id.
+ * testsuite/binutils-all/debuginfod.exp (test_fetch_debuglink):
+ Fix regexp for loads via debuglink section.
+
+2021-12-16 Richard Sandiford <richard.sandiford@arm.com>
+
+ arm: Add support for Armv9.1-A to Armv9.3-A
+ This patch adds AArch32 support for -march=armv9.[123]-a.
+ The behaviour of the new options can be expressed using a
+ combination of existing feature flags and tables.
+
+ The cpu_arch_ver entries for ARM_ARCH_V9_2A and ARM_ARCH_V9_3A
+ are technically redundant but it seemed less surprising to include
+ them anyway.
+
+ include/
+ * opcode/arm.h (ARM_ARCH_V9_1A, ARM_ARCH_V9_2A): New macros.
+ (ARM_ARCH_V9_3A): Likewise.
+
+ gas/
+ * doc/c-arm.texi: Add armv9.1-a, armv9.2-a and armv9.3-a.
+ * config/tc-arm.c (armv91a_ext_table, armv92a_ext_table): New macros.
+ (armv93a_ext_table): Likewise.
+ (arm_archs): Add armv9.1-a, armv9.2-a and armv9.3-a.
+ (cpu_arch_ver): Add ARM_ARCH_V9_1A, ARM_ARCH_V9_2A and ARM_ARCH_V9_3A.
+ * NEWS: Mention the above.
+ * testsuite/gas/arm/attr-march-armv9_1-a.d: New test.
+ * testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise.
+ * testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise.
+ * testsuite/gas/arm/bfloat16-armv9.1-a.d: Likewise.
+ * testsuite/gas/arm/bfloat16-armv9.2-a.d: Likewise.
+ * testsuite/gas/arm/bfloat16-armv9.3-a.d: Likewise.
+ * testsuite/gas/arm/i8mm-armv9.1-a.d: Likewise.
+ * testsuite/gas/arm/i8mm-armv9.2-a.d: Likewise.
+ * testsuite/gas/arm/i8mm-armv9.3-a.d: Likewise.
+
+2021-12-16 Richard Sandiford <richard.sandiford@arm.com>
+
+ arm: Add support for Armv8.7-A and Armv8.8-A
+ This patch adds AArch32 support for -march=armv8.[78]-a.
+ The behaviour of the new options can be expressed using a
+ combination of existing feature flags and tables.
+
+ The cpu_arch_ver entries are technically redundant but
+ it seemed less surprising to include them anyway.
+
+ include/
+ * opcode/arm.h (ARM_ARCH_V8_7A, ARM_ARCH_V8_8A): New macros.
+
+ gas/
+ * doc/c-arm.texi: Add armv8.7-a and armv8.8-a.
+ * config/tc-arm.c (armv87a_ext_table, armv88a_ext_table): New macros.
+ (arm_archs): Add armv8.7-a and armv8.8-a.
+ (cpu_arch_ver): Add ARM_ARCH_V8_7A and ARM_ARCH_V8_8A.
+ * NEWS: Mention the above.
+ * testsuite/gas/arm/attr-march-armv8_7-a.d: New test.
+ * testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise.
+ * testsuite/gas/arm/bfloat16-armv8.7-a.d: Likewise.
+ * testsuite/gas/arm/bfloat16-armv8.8-a.d: Likewise.
+ * testsuite/gas/arm/i8mm-armv8.7-a.d: Likewise.
+ * testsuite/gas/arm/i8mm-armv8.8-a.d: Likewise.
+
+2021-12-16 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for Armv9.1-A to Armv9.3-A
+ This patch adds AArch64 support for -march=armv9.[123]-a.
+ The behaviour of the new options can be expressed using a
+ combination of existing feature flags, so we don't need to
+ eat into the vanishing number of spare AARCH64_FEATURE_* bits.
+ Hoewver, it was more convenient to separate out the |s of
+ feature flags so that Armv9.1-A could reuse the set for
+ Armv8.6-A, and so on.
+
+ include/
+ * opcode/aarch64.h (AARCH64_ARCH_V8_FEATURES): New macro,
+ split out from...
+ (AARCH64_ARCH_V8): ...here.
+ (AARCH64_ARCH_V8_1_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_1): ...here.
+ (AARCH64_ARCH_V8_2_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_2): ...here.
+ (AARCH64_ARCH_V8_3_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_3): ...here.
+ (AARCH64_ARCH_V8_4_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_4): ...here.
+ (AARCH64_ARCH_V8_5_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_5): ...here.
+ (AARCH64_ARCH_V8_6_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_6): ...here.
+ (AARCH64_ARCH_V8_7_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_7): ...here.
+ (AARCH64_ARCH_V8_8_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V8_8): ...here.
+ (AARCH64_ARCH_V9_FEATURES): New macro, split out from...
+ (AARCH64_ARCH_V9): ...here.
+ (AARCH64_ARCH_V9_1_FEATURES, AARCH64_ARCH_V9_1): New macros.
+ (AARCH64_ARCH_V9_2_FEATURES, AARCH64_ARCH_V9_2): New macros.
+ (AARCH64_ARCH_V9_3_FEATURES, AARCH64_ARCH_V9_3): New macros.
+
+ gas/
+ * doc/c-aarch64.texi: Add armv9.1-a, armv9-2-a and armv9.3-a.
+ * config/tc-aarch64.c (aarch64_archs): Likewise.
+ * NEWS: Mention the above.
+ * testsuite/gas/aarch64/armv9_invalid.d,
+ testsuite/gas/aarch64/armv9_invalid.s,
+ testsuite/gas/aarch64/armv9_invalid.l: New test.
+ * testsuite/gas/aarch64/armv9_1.d,
+ testsuite/gas/aarch64/armv9_1.s: Likewise.
+ * testsuite/gas/aarch64/armv9_1_invalid.d,
+ testsuite/gas/aarch64/armv9_1_invalid.s,
+ testsuite/gas/aarch64/armv9_1_invalid.l: Likewise.
+ * testsuite/gas/aarch64/armv9_2.d,
+ testsuite/gas/aarch64/armv9_2.s: Likewise.
+ * testsuite/gas/aarch64/armv9_2_invalid.d,
+ testsuite/gas/aarch64/armv9_2_invalid.s,
+ testsuite/gas/aarch64/armv9_2_invalid.l: Likewise.
+ * testsuite/gas/aarch64/armv9_3.d,
+ testsuite/gas/aarch64/armv9_3.s: Likewise.
+
+2021-12-16 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Support svinval extension with frozen version 1.0.
+ According to the privileged spec, there are five new instructions for
+ svinval extension. Two of them (HINVAL.VVMA and HINVAL.GVMA) need to
+ enable the hypervisor extension. But there is no implementation of
+ hypervisor extension in mainline for now, so let's consider the related
+ issues later.
+
+ 31..25 24..20 19..15 14..12 11...7 6..2 1..0
+ sinval.vma 0001011 rs2 rs1 000 00000 11100 11
+ sfence.w.inval 0001100 00000 00000 000 00000 11100 11
+ sfence.inval.ir 0001100 00001 00000 000 00000 11100 11
+ hinval.vvma 0010011 rs2 rs1 000 00000 11100 11
+ hinval.gvma 0110011 rs2 rs1 000 00000 11100 11
+
+ This patch is cherry-picked from the riscv integration branch since the
+ svinval extension is frozen for now. Besides, we fix the funct7 encodings
+ of hinval.vvma and hinval.gvma, from 0x0011011 and 0x0111011 to 0x0010011
+ and 0x0110011.
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_std_s_ext): Added svinval.
+ (riscv_multi_subset_supports): Handle INSN_CLASS_SVINVAL.
+ gas/
+ * testsuite/gas/riscv/svinval.d: New testcase.
+ * testsuite/gas/riscv/svinval.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Added encodings for svinval.
+ * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_SVINVAL.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Added svinval instructions.
+
+2021-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips/or1k: drop redundant arg to bitsize macro
+ These are just using the default behavior for the 3rd arg, so drop
+ it to make it more clear. This also makes them match all other
+ ports that only use the first 2 arguments.
+
+2021-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: unify texi generation rules
+ The logic between these rules are extremely similar, so unify them
+ into a single variable by leveraging make $@ and $< variables.
+
+ Also add automake silent rule support while we're here.
+
+2021-12-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: fix mingw builds with replacement gnulib open
+ The header shuffling in here broke the workaround for gnulib defining
+ "open". Move it back before the sim-specific includes to fix. This
+ is because the callback struct in the headers has an "open" member and
+ this file tries to call that.
+
+2021-12-16 Sandra Loosemore <sandra@codesourcery.com>
+
+ Adjust compare_link_order for unstable qsort
+ In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host
+ using binutils 2.37, we observed a failure that didn't show up on
+ x86_64-linux-gnu host: testcase pr25490-5.s was failing with
+
+ C:\path\to\nios2-elf-ld.exe: looping in map_segments
+ FAIL: __patchable_function_entries section 5
+
+ * ldelfgen.c (compare_link_order): Don't use section id in
+ sorting. Keep original ordering instead. Update comments.
+
+2021-12-16 Alan Modra <amodra@gmail.com>
+
+ Re: Fix an undefined behaviour in the BFD library's DWARF parser
+ Using an unsigned int cast (to 32 bits) on a pointer difference (of
+ possibly 64 bits) is wrong. Even though it will work on all real
+ object files, the fuzzers will eventually find this hole.
+
+ PR 28687
+ * dwarf1.c (parse_die): Cast pointer difference to size_t.
+ Catch another possible pointer overflow.
+
+2021-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: re-format with black 21.12b0
+ Run black 21.12b0 on gdb/, there is a single whitespace change. I will
+ update the wiki [1] in parallel to bump the version of black to 21.12b0.
+
+ [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
+
+ Change-Id: Ib3b859e3506c74a4f15d16f1e44ef402de3b98e2
+
+2021-12-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: re-format with black 21.9b0
+ Run black 21.9b0 on gdb/ (this is the version currently mentioned on the
+ wiki [1], the subsequent commit will bump that version).
+
+ [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
+
+ Change-Id: I5ceaab42c42428e053e2572df172aa42a88f0f86
+
+2021-12-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-15 Alan Modra <amodra@gmail.com>
+
+ PR28691, validate dwarf attribute form
+ PR28691 is a fuzzing PR that triggers a non-problem of "output changes
+ per run" with PIEs and/or different compilers. I've closed similar
+ PRs before as wontfix, but I guess there will be no end of this type
+ of PR. The trigger is an attribute that usually takes one of the
+ offset/constant reference DW_FORMs being given an indexed string
+ DW_FORM. The bfd reader doesn't support indexed strings and returns
+ an error string instead. The address of the string varies with PIE
+ runs and/or compiler, and we allow that address to appear in output.
+ Fix this by validating integer attribute forms, as we do for string
+ form attributes.
+
+ PR 28691
+ * dwarf2.c (is_str_attr): Rename to..
+ (is_str_form): ..this. Change param type. Update calls.
+ (is_int_form): New function.
+ (read_attribute_value): Handle DW_FORM_addrx2.
+ (find_abstract_instance): Validate form when using attr.u.val.
+ (scan_unit_for_symbols, parse_comp_unit): Likewise.
+
+2021-12-15 Luis Machado <luis.machado@linaro.org>
+
+ New --enable-threading configure option to control use of threads in GDB/GDBserver
+ Add the --enable-threading configure option so multithreading can be disabled
+ at configure time. This is useful for statically-linked builds of
+ GDB/GDBserver, since the thread library doesn't play well with that setup.
+
+ If you try to run a statically-linked GDB built with threading, it will crash
+ when setting up the number of worker threads.
+
+ This new option is also convenient when debugging GDB in a system with lots of
+ threads, where the thread discovery code in GDB will emit too many messages,
+ like so:
+
+ [New Thread 0xfffff74d3a50 (LWP 2625599)]
+
+ If you have X threads, that message will be repeated X times.
+
+ The default for --enable-threading is "yes".
+
+2021-12-15 Nikita Popov <npv1310@gmail.com>
+
+ Fix an undefined behaviour in the BFD library's DWARF parser.
+ PR 28687
+ * dwarf1.c (parse_die): Fix undefined behaviour in range tests.
+
+2021-12-15 Alan Modra <amodra@gmail.com>
+
+ PR28694, Out-of-bounds write in stab_xcoff_builtin_type
+ PR 28694
+ * stabs.c (stab_xcoff_builtin_type): Make typenum unsigned.
+ Negate typenum earlier, simplifying bounds checking. Correct
+ off-by-one indexing. Adjust switch cases.
+
+2021-12-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-14 Alan Modra <amodra@gmail.com>
+
+ loongarch32 build failure on 32-bit host
+ gas/config/tc-loongarch.c: In function ‘assember_macro_helper’:
+ gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow]
+ 915 | hi32 = insn->args[1] >> 32;
+ | ^~
+
+ One possible fix is to make offsetT a 64-bit type for loongarch32.
+ This also makes bfd/targmatch.h (generated from bfd/config.bfd)
+ consistent since the loongarch32 match is inside #ifdef BFD64.
+
+ * config.bfd (loongarch32-*): Set want64.
+
+2021-12-14 Alan Modra <amodra@gmail.com>
+
+ loongarch64 build failure on 32-bit host
+ gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’:
+ gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer
+ -to-int-cast]
+ 661 | imm = (offsetT) str_hash_find (r_htab, arg);
+ | ^
+
+ Cast it to the correct size int, relying on normal integer promotions
+ if offsetT is larger than a pointer.
+
+ * config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
+ Cast return from str_hash_find to intptr_t, not offsetT.
+
+2021-12-14 Alan Modra <amodra@gmail.com>
+
+ XCOFF C_STSYM test failure on 32-bit host
+ This test was failing here and on another similar symbol:
+ [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs
+ where correct output is
+ [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x000000000000000a .bs
+
+ The problem is caused by a 32-bit host pointer being sign-extended
+ when stored into a 64-bit bfd_vma, and then that value not being
+ trimmed back to 32 bits when used. The following belt-and-braces
+ patch fixes both the store and subsequent reads.
+
+ * coffcode.h (coff_slurp_symbol_table): Do not sign extend
+ when storing a host pointer to syment.n_value.
+ * coffgen.c (coff_get_symbol_info): Cast syment.n_value to a
+ bfd_hostptr_t before using in arithmetic.
+ (coff_print_symbol): Likewise.
+
+2021-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver/tracepoint.cc: use snprintf in gdb_agent_socket_init
+ If we modify tracepoint.cc to try to use a too long unix socket name,
+ for example by modifying SOCK_DIR to be:
+
+ #define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut"
+
+ ... trying to start an application with libinproctrace.so loaded
+ crashes:
+
+ $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
+ /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected.
+ xsnprintf: Assertion `ret < size' failed.
+
+ Looking at the rest of the socket initialization code, the intent seems
+ to be that if something goes wrong, we warn but let the program
+ execute. So crashing on this failed assertions seems against the intent.
+
+ Commit 6cebaf6e1ae4 ("use xsnprintf instead of snprintf.") changed this
+ code to use xsnprintf instead of snprintf, introducing this assertion.
+ Before that, snprintf would return a value bigger that UNIX_PATH_MAX and
+ the "if" after would catch it and emit a warning, which is exactly what
+ we want. That change was done because LynxOS didn't have snprintf.
+ Since LynxOS isn't supported anymore, we can simply revert to use
+ snprintf there.
+
+ With this patch, we get a warning (printed by the caller of
+ gdb_agent_socket_init), but the program keeps executing:
+
+ $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
+ ipa: could not create sync socket
+ ...
+
+ Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd
+
+2021-12-14 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver/tracepoint.cc: work around -Wstringop-truncation error
+ When building gdb with on AArch64 with g++ 11.1.0 (and some preceding
+ versions too), -O2 and -fsanitize=address, I get this error.
+
+ CXX tracepoint-ipa.o
+ cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
+ In file included from /usr/include/string.h:519,
+ from ../gnulib/import/string.h:41,
+ from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95,
+ from /home/simark/src/binutils-gdb/gdbserver/server.h:22,
+ from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19:
+ In function ‘char* strncpy(char*, const char*, size_t)’,
+ inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11,
+ inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26,
+ inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41:
+ /usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation]
+ 95 | return __builtin___strncpy_chk (__dest, __src, __len,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
+ 96 | __glibc_objsize (__dest));
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar
+ error if I use -D_FORTIFY_SOURCE=0.
+
+ I am pretty sure it's spurious and might be related to this GCC bug:
+
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
+
+ From what I can see, we are copying from a static 108 bytes long buffer
+ (the global array agent_socket_name) to a 108 bytes long array,
+ sockaddr_un::sun_path. I don't see anything wrong.
+
+ Still, it would make things easier if we didn't see this error. Change
+ the code to check that the source string length is smaller than the
+ destination buffer (including space for the NULL byte) and use strcpy.
+
+ For anybody who would like to try to reproduce, the full command line
+ is:
+
+ g++ -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc
+
+ Change-Id: I18e86c0487feead7e7677e69398405e7057cf464
+
+2021-12-14 Simon Marchi <simon.marchi@polymtl.ca>
+
+ bfd: fix -Wunused errors with clang 13+
+ Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for
+ situations where gcc doesn't. In particular, when a variable is set and
+ then used in a way to update its own value. For example, if `i` is only
+ used in this way:
+
+ int i = 2;
+ i++;
+ i = i + 1;
+
+ gcc won't warn, but clang will.
+
+ Fix all such errors found in an --enable-targets=all build. It would be
+ important for somebody who knows what they're doing to just make sure
+ that these variables can indeed be deleted, and that there a no cases
+ where it's a bug, and the variable should actually be used.
+
+ The first instance of this error fix by this patch is:
+
+ CC elf32-score.lo
+ /home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable]
+ bfd_vma relocation;
+ ^
+
+ Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6
+
+2021-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: rename build_table to add_builtin_mi_commands
+ Just give the function build_table a more descriptive name. There
+ should be no user visible changes after this commit.
+
+2021-12-14 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/mi: rename mi_cmd to mi_command
+ Just give this class a new name, more inline with the name of the
+ sub-classes. I've also updated mi_cmd_up to mi_command_up in
+ mi-cmds.c inline with this new naming scheme.
+
+ There should be no user visible changes after this commit.
+
+2021-12-14 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/mi: use separate classes for different types of MI command
+ This commit changes the infrastructure in mi-cmds.{c,h} to add new
+ sub-classes for the different types of MI command. Instances of these
+ sub-classes are then created and added into mi_cmd_table.
+
+ The existing mi_cmd class becomes the abstract base class, this has an
+ invoke method and takes care of the suppress notifications handling,
+ before calling a do_invoke virtual method which is implemented by all
+ of the sub-classes.
+
+ There's currently two different sub-classes, one of pure MI commands,
+ and a second for MI commands that delegate to CLI commands.
+
+ There should be no user visible changes after this commit.
+
+2021-12-14 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/mi: int to bool conversion in mi_execute_cli_command
+ Change an argument of mi_execute_cli_command from int to bool. Update
+ the callers to take this into account. Within mi_execute_cli_command,
+ update a comparison of a pointer to 0 with a comparison to nullptr,
+ and add an assert, if we are not using the argument string then the
+ string should be nullptr. Also removed a cryptic 'gdb_????' comment,
+ which isn't really helpful.
+
+ There should be no user visible changes after this commit.
+
+2021-12-14 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/mi: use std::map for MI commands in mi-cmds.c
+ This changes the hashmap used in mi-cmds.c from a custom structure to
+ std::map. Not only is replacing a custom container with a standard
+ one an improvement, but using std::map will make it easier to
+ dynamically add commands; which is something that is planned for a
+ later series, where we will allow MI commands to be implemented in
+ Python.
+
+ There should be no user visible changes after this commit.
+
+2021-12-14 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/mi: rename mi_lookup to mi_cmd_lookup
+ Lets give this function a more descriptive name. I've also improved
+ the comments in the header and source files.
+
+ There should be no user visible changes after this commit.
+
+2021-12-14 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Added ld testcases for the medlow and medany code models.
+ There are two linker scripts, code-model-01.ld and code-model-02.ld,
+ which are corresponding to the two different memory layouts,
+
+ * code-model-01.ld: the text section is in the 32-bit address range, but
+ the data section is far away from the text section, which means the data
+ section is over the 32-bit address range.
+
+ * code-model-02.ld: the text section is over the 32-bit address range, but
+ the data section is placed nearly zero address.
+
+ We use the two linker scripts, to test the current medlow and medany behaviors
+ of GNU ld, including the weak symbol references and the relaxations behaviors.
+ Besides, these testcases also show the limits of the current medlow and medany
+ code models, that is - we may get the truncated to fit errors when linking
+ with the above two linker scripts.
+
+ ld/
+ * testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the
+ behaviors of the current medlow and medany code models.
+ * testsuite/ld-riscv-elf/code-model-02.ld: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise.
+ * testsuite/ld-riscv-elf/code-model.s: Likewise.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-12-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-13 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Adjust linker tests for --disable-separate-code
+ Adjust linker tests for linker configured with --disable-separate-code:
+
+ 1. Update expected outputs.
+ 2. Pass -z max-page-size=0x1000 -z separate-code" to linker.
+
+ * testsuite/ld-i386/report-reloc-1.l: Updated.
+ * testsuite/ld-x86-64/report-reloc-1.l: Likewise.
+ * testsuite/ld-x86-64/pe-x86-64.exp: Pass
+ "-z max-page-size=0x1000 -z separate-code" to linker.
+ * testsuite/ld-x86-64/pr19609-4e.d: Likewise.
+ * testsuite/ld-x86-64/pr19609-6a.d: Likewise.
+ * testsuite/ld-x86-64/pr19609-6b.d: Likewise.
+ * testsuite/ld-x86-64/pr19609-7b.d: Likewise.
+ * testsuite/ld-x86-64/pr19609-7d.d: Likewise.
+
+2021-12-13 Carl Love <cel@us.ibm.com>
+
+ gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp
+ Powerpc is not reporting the
+
+ Catchpoint 1 (returned from syscall execve), ....
+
+ as expected. The issue appears to be with the kernel not returning the
+ expected result. This patch marks the test failure as an xfail.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623
+
+2021-12-13 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: improve reuse of value contents when fetching array elements
+ While working on a Python script, which was interacting with a remote
+ target, I noticed some weird slowness in GDB. In my program I had a
+ structure something like this:
+
+ struct foo_t
+ {
+ int array[5];
+ };
+
+ struct foo_t global_foo;
+
+ Then in the Python script I was fetching a complete copy of global
+ foo, like:
+
+ val = gdb.parse_and_eval('global_foo')
+ val.fetch_lazy()
+
+ Then I would work with items in foo_t.array, like:
+
+ print(val['array'][1])
+
+ I called the fetch_lazy method specifically because I knew I was going
+ to end up accessing almost all of the contents of val, and so I wanted
+ GDB to do a single remote protocol call to fetch all the contents in
+ one go, rather than trying to do lazy fetches for a couple of bytes at
+ a time.
+
+ What I observed was that, after the fetch_lazy call, GDB does,
+ correctly, fetch the entire contents of global_foo, including all of
+ the contents of array, however, when I access val.array[1], GDB still
+ goes and fetches the value of this element from the remote target.
+
+ What's going on is that in valarith.c, in value_subscript, for C like
+ languages, we always end up treating the array value as a pointer, and
+ then doing value_ptradd, and value_ind, the second of these calls
+ always returns a lazy value.
+
+ My guess is that this approach allows us to handle indexing off the
+ end of an array, when working with zero element arrays, or when
+ indexing a raw pointer as an array. And, I agree, that in these
+ cases, where, even when the original value is non-lazy, we still will
+ not have the content of the array loaded, we should be using the
+ value_ind approach.
+
+ However, for cases where we do have the array contents loaded, and we
+ do know the bounds of the array, I think we should be using
+ value_subscripted_rvalue, which is what we use for non C like
+ languages.
+
+ One problem I did run into, exposed by gdb.base/charset.exp, was that
+ value_subscripted_rvalue stripped typedefs from the element type of
+ the array, which means the value returned will not have the same type
+ as an element of the array, but would be the raw, non-typedefed,
+ type. In charset.exp we got back an 'int' instead of a
+ 'wchar_t' (which is a typedef of 'int'), and this impacts how we print
+ the value. Removing typedefs from the resulting value just seems
+ wrong, so I got rid of that, and I don't see any test regressions.
+
+ With this change in place, my original Python script is now doing no
+ additional memory accesses, and its performance increases about 10x!
+
+2021-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: update gdb-gdb.py.in for latest changes to struct field
+ This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and
+ 'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after
+ this commit:
+
+ commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404
+ Date: Thu Sep 30 22:38:29 2021 -0400
+
+ gdb: add accessors for field (and call site) location
+
+ I have also incorporated this change:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html
+
+ Which means we print 'm_name' instead of 'name' when displaying the
+ 'm_name' member variable.
+
+ Finally, I have also added support for the new TYPE_SPECIFIC_INT
+ fields, which were added with this commit:
+
+ commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d
+ Date: Wed Sep 23 09:39:24 2020 -0600
+
+ Handle bit offset and bit size in base types
+
+ I updated the gdb.gdb/python-helper.exp test to cover all of these
+ changes.
+
+2021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbserver/linux-low: replace direct assignment to current_thread
+ Use scoped_restore_current_thread and switch_to_thread in
+ linux_process_target::wait_for_sigstop.
+
+2021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbserver: replace direct assignments to current_thread
+ Replace the direct assignments to current_thread with
+ switch_to_thread. Use scoped_restore_current_thread when appropriate.
+ There is one instance remaining in linux-low.cc's wait_for_sigstop.
+ This will be handled in a separate patch.
+
+ Regression-tested on X86-64 Linux using the native-gdbserver and
+ native-extended-gdbserver board files.
+
+2021-12-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdbserver: introduce scoped_restore_current_thread and switch_to_thread
+ Introduce a class for restoring the current thread and a function to
+ switch to the given thread. This is a preparation for a refactoring
+ that aims to remove direct assignments to 'current_thread'.
+
+2021-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make post_startup_inferior a virtual method on inf_ptrace_target
+ While working on a later patch that required me to understand how GDB
+ starts up inferiors, I was confused by the
+ target_ops::post_startup_inferior method.
+
+ The post_startup_inferior target function is only called from
+ inf_ptrace_target::create_inferior.
+
+ Part of the target class hierarchy looks like this:
+
+ inf_child_target
+ |
+ '-- inf_ptrace_target
+ |
+ |-- linux_nat_target
+ |
+ |-- fbsd_nat_target
+ |
+ |-- nbsd_nat_target
+ |
+ |-- obsd_nat_target
+ |
+ '-- rs6000_nat_target
+
+ Every sub-class of inf_ptrace_target, except rs6000_nat_target,
+ implements ::post_startup_inferior. The rs6000_nat_target picks up
+ the implementation of ::post_startup_inferior not from
+ inf_ptrace_target, but from inf_child_target.
+
+ No descendent of inf_child_target, outside the inf_ptrace_target
+ sub-tree, implements ::post_startup_inferior, which isn't really
+ surprising, as they would never see the method called (remember, the
+ method is only called from inf_ptrace_target::create_inferior).
+
+ What I find confusing is the role inf_child_target plays in
+ implementing, what is really a helper function for just one of its
+ descendents.
+
+ In this commit I propose that we formally make ::post_startup_inferior
+ a helper function of inf_ptrace_target. To do this I will remove the
+ ::post_startup_inferior from the target_ops API, and instead make this
+ a protected, pure virtual function on inf_ptrace_target.
+
+ I'll remove the empty implementation of ::post_startup_inferior from
+ the inf_child_target class, and add a new empty implementation to the
+ rs6000_nat_target class.
+
+ All the other descendents of inf_ptrace_target already provide an
+ implementation of this method and so don't need to change beyond
+ making the method protected within their class declarations.
+
+ To me, this makes much more sense now. The helper function, which is
+ only called from within the inf_ptrace_target class, is now a part of
+ the inf_ptrace_target class.
+
+ The only way in which this change is visible to a user is if the user
+ turns on 'set debug target 1'. With this debug flag on, prior to this
+ patch the user would see something like:
+
+ -> native->post_startup_inferior (...)
+ <- native->post_startup_inferior (2588939)
+
+ After this patch these lines are no longer present, as the
+ post_startup_inferior is no longer a top level target method. For me,
+ this is an acceptable change.
+
+2021-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: have mips_nbsd_nat_target inherit from nbsd_nat_target
+ While working on another patch I had reason to look at
+ mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target
+ inherits directly from inf_ptrace_target.
+
+ This is a little strange as alpha_bsd_nat_target,
+ arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target,
+ ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all
+ inherit from nbsd_nat_target.
+
+ Originally, in this commit:
+
+ commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e
+ Date: Thu May 3 00:37:22 2018 +0100
+
+ Convert struct target_ops to C++
+
+ When the target tree was converted to C++, all of the above classes
+ inherited from inf_ptrace_target except for hppa_nbsd_nat_target,
+ which was the only class that originally inherited from
+ nbsd_nat_target.
+
+ Later on all the remaining targets (except mips) were converted to
+ inherit from nbsd_nat_target, these are the commits:
+
+ commit 4fed520be264b60893aa674071947890f8172915
+ Date: Sat Mar 14 16:05:24 2020 +0100
+
+ Inherit alpha_netbsd_nat_target from nbsd_nat_target
+
+ commit 6018d381a00515933016c539d2fdc18ad0d304b8
+ Date: Sat Mar 14 14:50:51 2020 +0100
+
+ Inherit arm_netbsd_nat_target from nbsd_nat_target
+
+ commit 01a801176ea15ddfc988cade2e3d84c3b0abfec3
+ Date: Sat Mar 14 16:54:42 2020 +0100
+
+ Inherit m68k_bsd_nat_target from nbsd_nat_target
+
+ commit 9faa006d11a5e08264a007463435f84b77864c9c
+ Date: Thu Mar 19 14:52:57 2020 +0100
+
+ Inherit ppc_nbsd_nat_target from nbsd_nat_target
+
+ commit 9809762324491b851332ce600ae9bde8dd34f601
+ Date: Tue Mar 17 15:07:39 2020 +0100
+
+ Inherit sh_nbsd_nat_target from nbsd_nat_target
+
+ commit d5be5fa4207da00d039a1d5a040ba316e7092cbd
+ Date: Sat Mar 14 13:21:58 2020 +0100
+
+ Inherit vax_bsd_nat_target from nbsd_nat_target
+
+ I could only find mailing list threads for ppc and sh in the archive ,
+ and unfortunately, none of the commits has any real detail that might
+ explain why mips was missed out, the only extra context I could find
+ was this message:
+
+ https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html
+
+ Which says that "proper" OS support is going to be added to
+ nbsd_nat_target, hence the need to inherit from that class.
+
+ My guess is that leaving mips_nbsd_nat_target unchanged was an
+ oversight, so, in this commit, I propose changing mips_nbsd_nat_target
+ to inherit from nbsd_nat_target just like all the other nbsd targets.
+
+ My motivation for this patch relates to the post_startup_inferior
+ target method. In a future commit I want to change how this method is
+ handled. Currently the mips_nbsd_nat_target will pick up the empty
+ implementation of inf_child_target::post_startup_inferior rather than
+ the version in netbsd-nat.c. This feels like a bug to me, as surely,
+ enabling of proc events is something that would need to be done for
+ all netbsd targets, regardless of architecture.
+
+ In my future patch I have a choice then, either (a) add a new, empty
+ implementation of post_startup_inferior to mips_nbsd_nat_target,
+ or (b) this commit, have mips_nbsd_nat_target inherit from
+ nbsd_nat_target. Option (b) seems like the right way to go, hence,
+ this commit.
+
+ I've done absolutely no testing for this change, not even building it,
+ as that would require at least an environment in which I can x-build
+ mips-netbsd applications, which I have no idea how to set up.
+
+2021-12-13 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: only include mips and riscv targets if building with 64-bit bfd
+ While testing another patch I was trying to build different
+ configurations of GDB, and, during one test build I ran into a
+ problem, I configured with `--enable-targets=all
+ --host=i686-w64-mingw32` and saw this error while linking GDB:
+
+ .../i686-w64-mingw32/bin/ld: mips-tdep.o: in function `mips_gdbarch_init':
+ .../src/gdb/mips-tdep.c:8730: undefined reference to `disassembler_options_mips'
+ .../i686-w64-mingw32/bin/ld: riscv-tdep.o: in function `riscv_gdbarch_init':
+ .../src/gdb/riscv-tdep.c:3851: undefined reference to `disassembler_options_riscv'
+
+ So the `disassembler_options_mips` and `disassembler_options_riscv`
+ symbols are missing.
+
+ This turns out to be because mips-dis.c and riscv-dis.c, in which
+ these symbols are defined, are in the TARGET64_LIBOPCODES_CFILES list
+ in opcodes/Makefile.am, these files are only built when we are
+ building with a 64-bit bfd.
+
+ If we look further, into bfd/Makefile.am, we can see that all the
+ files matching elf*-riscv.lo are in the BFD64_BACKENDS list, as are
+ the elf*-mips.lo files, and (I know because I tried), the two
+ disassemblers do, not surprisingly, depend on features supplied from
+ libbfd.
+
+ So, though we can build most of GDB just fine for riscv and mips with
+ a 32-bit bfd, if I understand correctly, the final GDB
+ executable (assuming we could get it to link) would not understand
+ these architectures at the bfd level, nor would there be any
+ disassembler available. This sounds like a pretty useless GDB to me.
+
+ So, in this commit, I move the riscv and mips targets into GDB's list
+ of targets that require a 64-bit bfd. After this I can build GDB just
+ fine with the configure options given above.
+
+ This was discussed on the mailing list in a couple of threads:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html
+ https://sourceware.org/pipermail/binutils/2021-November/118498.html
+
+ and it is agreed, that it is unfortunate that the 32-bit riscv and
+ 32-bit mips targets require a 64-bit bfd. If in the future this
+ situation ever changes then it would be expected that some (or all) of
+ this patch would be reverted. Until then though, this patch allows
+ GDB to build when configured with --enable-targets=all, and when using
+ a 32-bit libbfd.
+
+2021-12-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-12 Tom Tromey <tom@tromey.com>
+
+ C++-ify path substitution code
+ I found some uses of xfree in the path substitution code in source.c.
+ C++-ifying struct substitute_path_rule both simplifies the code and
+ removes manual memory management.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-12-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-11 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64 @notoc in non-power10 code
+ Gold version of commit 7aba54da42.
+
+ elfcpp/
+ * powerpc.h (R_PPC64_REL24_P9NOTOC): Define.
+ gold/
+ * powerpc.cc (Target_powerpc::maybe_skip_tls_get_addr_call,
+ is_branch_reloc, max_branch_delta): Handle R_PPC64_REL24_P9NOTOC.
+ (Target_powerpc::Branch_info::make_stub): Likewise.
+ (struct Plt_stub_ent): Add p9notoc_, p9off_, tsize_.
+ (struct Branch_stub_ent): Add p9notoc_, p9off_.
+ (Stub_table::add_plt_call_entry): Handle R_PPC64_REL24_P9NOTOC.
+ (Stub_table::add_long_branch_entry): Likewise.
+ (Stub_table::add_eh_frame): Likewise.
+ (Stub_table::plt_call_size): Return aligned size. Adjust callers.
+ Handle p9notoc_ sizing.
+ (Stub_table::do_write): Write out p9notoc_ stubs.
+ (Target_powerpc::Scan::get_reference_flags, local, global):
+ Handle R_PPC64_REL24_P9NOTOC.
+ (Target_powerpc::Relocate::relocate): Likewise.
+
+2021-12-11 H.J. Lu <hjl.tools@gmail.com>
+
+ Don't return the main file as the separate debug info
+ On Fedora 35,
+
+ $ readelf -d /usr/bin/npc
+
+ caused readelf to run out of stack since load_separate_debug_info
+ returned the input main file as the separate debug info:
+
+ (gdb) bt
+ #0 load_separate_debug_info (
+ main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo",
+ xlink=xlink@entry=0x4e5180 <debug_displays+4480>,
+ parse_func=parse_func@entry=0x431550 <parse_gnu_debuglink>,
+ check_func=check_func@entry=0x432ae0 <check_gnu_debuglink>,
+ func_data=func_data@entry=0x7fffffffdb60, file=file@entry=0x51d430)
+ at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057
+ #1 0x000000000043328d in check_for_and_load_links (file=0x51d430,
+ filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
+ at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381
+ #2 0x00000000004332ae in check_for_and_load_links (file=0x51b070,
+ filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
+
+ Return NULL if the separate debug info is the same as the input main
+ file to avoid infinite recursion.
+
+ PR binutils/28679
+ * dwarf.c (load_separate_debug_info): Don't return the input
+ main file.
+
+2021-12-11 Alan Modra <amodra@gmail.com>
+
+ Don't edit bogus sh_link on reading relocatable objects (Oracle fix)
+ This reverts a 1995 fix to handle bogus object files. Presumably such
+ object files have long gone.
+
+ * elf.c (bfd_section_from_shdr): Remove old hack for Oracle
+ libraries.
+
+2021-12-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-10 Jan Vrany <jan.vrany@labware.com>
+
+ gdb/testsuite: respect GDBSERVER variable in remote-stdio-gdbserver "board"
+ The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says
+ that user can specify path to gdbserver on remote system by setting
+ GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver
+ was used unconditionally.
+
+ This commit updates the code to respect GDBSERVER if set and fall back to
+ /usr/bin/gdbserver if not.
+
+2021-12-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ Revert "gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`"
+ This reverts commit fe72c32765e1190c8a17d309fc3a7e1882d6a430.
+
+ It turns out it was wrong, libinproctrace.so does build its own
+ gdbsupport/tdesc.cc. This broke the build:
+
+ make[1]: Entering directory '/home/simark/build/binutils-gdb-one-target/gdbserver'
+ CXXLD libinproctrace.so
+ /usr/bin/ld: gdbsupport/tdesc-ipa.o: in function `print_xml_feature::visit_pre(target_desc const*)':
+ /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:407: undefined reference to `tdesc_architecture_name(target_desc const*)'
+ /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:408: undefined reference to `tdesc_architecture_name(target_desc const*)'
+ /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:411: undefined reference to `tdesc_osabi_name(target_desc const*)'
+ /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:416: undefined reference to `tdesc_compatible_info_list(target_desc const*)'
+ /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:418: undefined reference to `tdesc_compatible_info_arch_name(std::unique_ptr<tdesc_compatible_info, std::default_delete<tdesc_compatible_info> > const&)'
+
+2021-12-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-09 Alan Modra <amodra@gmail.com>
+
+ PR28674, objdump crash
+ Not returning an error indication here leaves the attribute
+ uninitialised, which then leads to intemperate behaviour.
+
+ PR 28674
+ * dwarf2.c (read_attribute_value): Return NULL on trying to read
+ past end of attributes.
+
+2021-12-09 Alan Modra <amodra@gmail.com>
+
+ Set sh_link for reloc sections created as normal sections
+ binutils-all/strip-13 and binutils-all/strip-14 tests create
+ SHT_REL/SHT_RELA sections by hand. These don't have sh_link set to
+ the .symtab section as they should, leading to readelf warnings if you
+ happen to be looking at the object files.
+
+ * elf.c (assign_section_numbers): Formatting. Set sh_link for
+ reloc sections created as normal sections in relocatable
+ objects.
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`
+ I suppose this code was copied from GDBserver and this ifndef was left
+ there. As far as I know, IN_PROCESS_AGENT will never be defined when
+ building this file, so we can remove this.
+
+ Change-Id: I84fc408e330b3a29106df830a09342861cadbaf6
+
+2021-12-09 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/microblaze-tdep.c: fix -Wunused-but-set-variable
+ Fix this, seen when building with clang 14:
+
+ CXX microblaze-tdep.o
+ /home/simark/src/binutils-gdb/gdb/microblaze-tdep.c:207:7: error: variable 'flags' set but not used [-Werror,-Wunused-but-set-variable]
+ int flags = 0;
+ ^
+
+ Change-Id: I59f726ed33e924912748bc475b6fd9a9394fc0d0
+
+2021-12-09 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/csky-tdep.c: fix -Wunused-but-set-variable error
+ Fix these, seen when building with clang 14:
+
+ CXX csky-tdep.o
+ /home/simark/src/binutils-gdb/gdb/csky-tdep.c:332:7: error: variable 'need_dummy_stack' set but not used [-Werror,-Wunused-but-set-variable]
+ int need_dummy_stack = 0;
+ ^
+ /home/simark/src/binutils-gdb/gdb/csky-tdep.c:805:12: error: variable 'offset' set but not used [-Werror,-Wunused-but-set-variable]
+ int offset = 0;
+ ^
+
+ Change-Id: I6703bcb50e83c50083f716f4084ef6aa30d659c4
+
+2021-12-09 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix default behavior of runto
+ The documented behavior of proc runto is to not emit a PASS when
+ succeeding to to run to the specified location, but emit a FAIL when
+ failing to do so. I suppose the intent is that it won't pollute the
+ results normally passing tests (although I don't see why we would care),
+ but make visible any problems.
+
+ However, it seems like the implementation makes it default to never
+ print anything. "no-message" is prependend to "args", so if "message"
+ is not passed, we will always take the path that sets print_fail to 0,
+ which will silence any failure.
+
+ This unfortunately means that tests relying on runto_main won't emit a
+ FAIL if failing to run to main. And since commit 4dfef5be6812
+ ("gdb/testsuite: make runto_main not pass no-message to runto"), tests
+ don't emit a FAIL themselves when failing to run to main. This means
+ that tests failing to run to main just fail silently, and that's bad.
+
+ This can be reproduced by hacking gdb.base/template.exp like so:
+
+ diff --git a/gdb/testsuite/gdb.base/template.c b/gdb/testsuite/gdb.base/template.c
+ index bcf39c377d92..052be5b79d73 100644
+ --- a/gdb/testsuite/gdb.base/template.c
+ +++ b/gdb/testsuite/gdb.base/template.c
+ @@ -15,6 +15,14 @@
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+ +#include <stdlib.h>
+ +
+ +__attribute__((constructor))
+ +static void c (void)
+ +{
+ + exit (1);
+ +}
+ +
+ int
+ main (void)
+ {
+
+ Running the modified gdb.base/template.exp shows that it exits without
+ printing any result.
+
+ Remove the line that prepends no-message to args, that should make
+ runto's behavior match its documentation.
+
+ This patch will appear to add many failures, but in reality they already
+ existed, they were just silenced.
+
+ Change-Id: I2a730d5bc72b6ef0698cd6aad962d9902aa7c3d6
+
+2021-12-09 Carl Love <cel@us.ibm.com>
+
+ gdb fix elfv1 Powerpc gdb.dwarf2/frame-inlined-in-outer-frame.exp
+ On ELFv1, the _start symbol must point to the *function descriptor* (in
+ the .opd section), not to the function code (in the .text section) like
+ with ELFv2 and other architectures.
+
+2021-12-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/maint.exp with -readnow
+ With test-case gdb.base/maint.exp and target board -readnow, I run into:
+ ...
+ FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
+ ...
+
+ The problem is that this and other regexps anchored using '^':
+ ...
+ -re "^$gdb_prompt $" {
+ ...
+ don't trigger because other regexps don't consume the entire preceding line.
+
+ This is partly due to the addition of the IS-STMT column.
+
+ Fix this by making the regexps consume entire lines.
+
+ Tested on x86_64-linux with native and target board readnow, as well as
+ check-read1 and check-readmore.
+
+2021-12-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/include-main.exp with -readnow
+ With test-case gdb.base/include-main.exp and target board readnow, I run into:
+ ...
+ FAIL: gdb.base/include-main.exp: maint info symtab
+ ...
+
+ The corresponding check in gdb.base/include-main.exp:
+ ...
+ gdb_test_no_output "maint info symtab"
+ ...
+ checks that no CU was expanded, while -readnow ensures that all CUs are
+ expanded.
+
+ Fix this by skipping the check with -readnow.
+
+ Tested on x86_64-linux, with native and target board readnow.
+
+2021-12-09 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Clarify the behavior of .option arch directive.
+ * To be consistent with -march option, removed the "=" operator when
+ user want to reset the whole architecture string. So the formats are,
+
+ .option arch, +<extension><version>, ...
+ .option arch, -<extension>
+ .option arch, <ISA string>
+
+ * Don't allow to add or remove the base extensions in the .option arch
+ directive. Instead, users should reset the whole architecture string
+ while they want to change the base extension.
+
+ * The operator "+" won't update the version of extension, if the
+ extension is already in the subset list.
+
+ bfd/
+ * elfxx-riscv.c (riscv_add_subset): Don't update the version
+ if the extension is already in the subset list.
+ (riscv_update_subset): To be consistent with -march option,
+ removed the "=" operator when user want to reset the whole
+ architecture string. Besides, Don't allow to add or remove
+ the base extensions in the .option arch directive.
+ gas/
+ * testsuite/gas/riscv/option-arch-01.s: Updated since we cannot
+ add or remove the base extensions in the .option arch directive.
+ * testsuite/gas/riscv/option-arch-02.s: Likewise.
+ * testsuite/gas/riscv/option-arch-fail.l: Likewise.
+ * testsuite/gas/riscv/option-arch-fail.s: Likewise.
+ * testsuite/gas/riscv/option-arch-01a.d: Set -misa-spec=2.2.
+ * testsuite/gas/riscv/option-arch-01b.d: Likewise.
+ * testsuite/gas/riscv/option-arch-02.d: Updated since the .option
+ arch, + won't change the version of extension, if the extension is
+ already in the subset list.
+ * testsuite/gas/riscv/option-arch-03.s: Removed the "=" operator
+ when resetting the whole architecture string.
+
+2021-12-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: use ## for automake comments
+ The ## marker tells automake to not include the comment in its
+ generated output, so use that in most places where the comment
+ only makes sense in the inputs.
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb, gdbserver: detach fork child when detaching from fork parent
+ While working with pending fork events, I wondered what would happen if
+ the user detached an inferior while a thread of that inferior had a
+ pending fork event. What happens with the fork child, which is
+ ptrace-attached by the GDB process (or by GDBserver), but not known to
+ the core? Sure enough, neither the core of GDB or the target detach the
+ child process, so GDB (or GDBserver) just stays ptrace-attached to the
+ process. The result is that the fork child process is stuck, while you
+ would expect it to be detached and run.
+
+ Make GDBserver detach of fork children it knows about. That is done in
+ the generic handle_detach function. Since a process_info already exists
+ for the child, we can simply call detach_inferior on it.
+
+ GDB-side, make the linux-nat and remote targets detach of fork children
+ known because of pending fork events. These pending fork events can be
+ stored in:
+
+ - thread_info::pending_waitstatus, if the core has consumed the event
+ but then saved it for later (for example, because it got the event
+ while stopping all threads, to present an all-stop stop on top of a
+ non-stop target)
+ - thread_info::pending_follow: if we ran to a "catch fork" and we
+ detach at that moment
+
+ Additionally, pending fork events can be in target-specific fields:
+
+ - For linux-nat, they can be in lwp_info::status and
+ lwp_info::waitstatus.
+ - For the remote target, they could be stored as pending stop replies,
+ saved in `remote_state::notif_state::pending_event`, if not
+ acknowledged yet, or in `remote_state::stop_reply_queue`, if
+ acknowledged. I followed the model of remove_new_fork_children for
+ this: call remote_notif_get_pending_events to process /
+ acknowledge any unacknowledged notification, then look through
+ stop_reply_queue.
+
+ Update the gdb.threads/pending-fork-event.exp test (and rename it to
+ gdb.threads/pending-fork-event-detach.exp) to try to detach the process
+ while it is stopped with a pending fork event. In order to verify that
+ the fork child process is correctly detached and resumes execution
+ outside of GDB's control, make that process create a file in the test
+ output directory, and make the test wait $timeout seconds for that file
+ to appear (it happens instantly if everything goes well).
+
+ This test catches a bug in linux-nat.c, also reported as PR 28512
+ ("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig()
+ const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind ==
+ TARGET_WAITKIND_SIGNALLED' failed.). When detaching a thread with a
+ pending event, get_detach_signal unconditionally fetches the signal
+ stored in the waitstatus (`tp->pending_waitstatus ().sig ()`). However,
+ that is only valid if the pending event is of type
+ TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit
+ would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean
+ the thread does not exist anymore, so we wouldn't be detaching it). Add
+ a condition in get_detach_signal to access the signal number only if the
+ wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0
+ instead (since the thread was not stopped with a signal to begin with).
+
+ Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to
+ verify that we consider events in pending stop replies in the remote
+ target. This test has many threads constantly forking, and we detach
+ from the program while the program is executing. That gives us some
+ chance that we detach while a fork stop reply is stored in the remote
+ target. To verify that we correctly detach all fork children, we ask
+ the parent to exit by sending it a SIGUSR1 signal and have it write a
+ file to the filesystem before exiting. Because the parent's main thread
+ joins the forking threads, and the forking threads wait for their fork
+ children to exit, if some fork child is not detach by GDB, the parent
+ will not write the file, and the test will time out. If I remove the
+ new remote_detach_pid calls in remote.c, the test fails eventually if I
+ run it in a loop.
+
+ There is a known limitation: we don't remove breakpoints from the
+ children before detaching it. So the children, could hit a trap
+ instruction after being detached and crash. I know this is wrong, and
+ it should be fixed, but I would like to handle that later. The current
+ patch doesn't fix everything, but it's a step in the right direction.
+
+ Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: move clearing of tp->pending_follow to follow_fork_inferior
+ A following patch will change targets so that when they detach an
+ inferior, they also detach any pending fork children this inferior may
+ have. While doing this, I hit a case where we couldn't differentiate
+ two cases, where in one we should detach the fork detach but not in the
+ other.
+
+ Suppose we continue past a fork with "follow-fork-mode == child" &&
+ "detach-on-fork on". follow_fork_inferior calls target_detach to detach
+ the parent. In that case the target should not detach the fork
+ child, as we'll continue debugging the child. As of now, the
+ tp->pending_follow field of the thread who called fork still contains
+ the details about the fork.
+
+ Then, suppose we run to a fork catchpoint and the user types "detach".
+ In that case, the target should detach the fork child in addition to the
+ parent. In that case as well, the tp->pending_follow field contains
+ the details about the fork.
+
+ To allow targets to differentiate the two cases, clear
+ tp->pending_follow a bit earlier, when following a fork. Targets will
+ then see that tp->pending_follow contains TARGET_WAITKIND_SPURIOUS, and
+ won't detach the fork child.
+
+ As of this patch, no behavior changes are expected.
+
+ Change-Id: I537741859ed712cb531baaefc78bb934e2a28153
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/remote.c: refactor pending fork status functions
+ In preparation for a following patch, refactor a few things that I did
+ find a bit awkward, and to make them a bit more reusable.
+
+ - Pass an inferior to kill_new_fork_children instead of a pid. That
+ allows iterating on only this inferior's threads and avoid further
+ filtering on the thread's pid.
+ - Change thread_pending_fork_status to return a non-nullptr value only
+ if the thread does have a pending fork status.
+ - Remove is_pending_fork_parent_thread, as one can just use
+ thread_pending_fork_status and check for nullptr.
+ - Replace is_pending_fork_parent with is_fork_status, which just
+ returns if the given target_waitkind if a fork or a vfork. Push
+ filtering on the pid to the callers, when it is necessary.
+
+ Change-Id: I0764ccc684d40f054e39df6fa5458cc4c5d1cd7b
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/remote.c: move some things up
+ Move the stop_reply and a few functions up. Some code above them in the
+ file will need to use them in a following patch. No behavior changes
+ expected here.
+
+ Change-Id: I3ca57d0e3ec253f56e1ba401289d9d167de14ad2
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb/linux-nat: factor ptrace-detach code to new detach_one_pid function
+ The following patch will add some code paths that need to ptrace-detach
+ a given PID. Factor out the code that does this and put it in its own
+ function, so that it can be re-used.
+
+ Change-Id: Ie65ca0d89893b41aea0a23d9fc6ffbed042a9705
+
+2021-12-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbserver: hide fork child threads from GDB
+ This patch aims at fixing a bug where an inferior is unexpectedly
+ created when a fork happens at the same time as another event, and that
+ other event is reported to GDB first (and the fork event stays pending
+ in GDBserver). This happens for example when we step a thread and
+ another thread forks at the same time. The bug looks like (if I
+ reproduce the included test by hand):
+
+ (gdb) show detach-on-fork
+ Whether gdb will detach the child of a fork is on.
+ (gdb) show follow-fork-mode
+ Debugger response to a program call of fork or vfork is "parent".
+ (gdb) si
+ [New inferior 2]
+ Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
+ Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
+ Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...
+ [New Thread 965190.965190]
+ [Switching to Thread 965190.965190]
+ Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): ... <long series of bytes>
+
+ The sequence of events leading to the problem is:
+
+ - We are using the all-stop user-visible mode as well as the
+ synchronous / all-stop variant of the remote protocol
+ - We have two threads, thread A that we single-step and thread B that
+ calls fork at the same time
+ - GDBserver's linux_process_target::wait pulls the "single step
+ complete SIGTRAP" and the "fork" events from the kernel. It
+ arbitrarily choses one event to report, it happens to be the
+ single-step SIGTRAP. The fork stays pending in the thread_info.
+ - GDBserver send that SIGTRAP as a stop reply to GDB
+ - While in stop_all_threads, GDB calls update_thread_list, which ends
+ up querying the remote thread list using qXfer:threads:read.
+ - In the reply, GDBserver includes the fork child created as a result
+ of thread B's fork.
+ - GDB-side, the remote target sees the new PID, calls
+ remote_notice_new_inferior, which ends up unexpectedly creating a new
+ inferior, and things go downhill from there.
+
+ The problem here is that as long as GDB did not process the fork event,
+ it should pretend the fork child does not exist. Ultimately, this event
+ will be reported, we'll go through follow_fork, and that process will be
+ detached.
+
+ The remote target (GDB-side), has some code to remove from the reported
+ thread list the threads that are the result of forks not processed by
+ GDB yet. But that only works for fork events that have made their way
+ to the remote target (GDB-side), but haven't been consumed by the core
+ yet, so are still lingering as pending stop replies in the remote target
+ (see remove_new_fork_children in remote.c). But in our case, the fork
+ event hasn't made its way to the GDB-side remote target. We need to
+ implement the same kind of logic GDBserver-side: if there exists a
+ thread / inferior that is the result of a fork event GDBserver hasn't
+ reported yet, it should exclude that thread / inferior from the reported
+ thread list.
+
+ This was actually discussed a while ago, but not implemented AFAIK:
+
+ https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t
+ https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html
+
+ Implementation details-wise, the fix for this is all in GDBserver. The
+ Linux layer of GDBserver already tracks unreported fork parent / child
+ relationships using the lwp_info::fork_relative, in order to avoid
+ wildcard actions resuming fork childs unknown to GDB. This information
+ needs to be made available to the handle_qxfer_threads_worker function,
+ so it can filter the reported threads. Add a new thread_pending_parent
+ target function that allows the Linux target to return the parent of an
+ eventual fork child.
+
+ Testing-wise, the test replicates pretty-much the sequence of events
+ shown above. The setup of the test makes it such that the main thread
+ is about to fork. We stepi the other thread, so that the step completes
+ very quickly, in a single event. Meanwhile, the main thread is resumed,
+ so very likely has time to call fork. This means that the bug may not
+ reproduce every time (if the main thread does not have time to call
+ fork), but it will reproduce more often than not. The test fails
+ without the fix applied on the native-gdbserver and
+ native-extended-gdbserver boards.
+
+ At some point I suspected that which thread called fork and which thread
+ did the step influenced the order in which the events were reported, and
+ therefore the reproducibility of the bug. So I made the test try both
+ combinations: main thread forks while other thread steps, and vice
+ versa. I'm not sure this is still necessary, but I left it there
+ anyway. It doesn't hurt to test a few more combinations.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28288
+ Change-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990
+
+2021-12-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-08 Tom Tromey <tom@tromey.com>
+
+ Use for-each more in gdb
+ There are some loops in gdb that use ARRAY_SIZE (or a wordier
+ equivalent) to loop over a static array. This patch changes some of
+ these to use foreach instead.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-12-08 Tom Tromey <tromey@adacore.com>
+
+ Fix error in file_and_directory patch
+ In my earlier C++-ization patch for file_and_directory, I introduced
+ an error:
+
+ - if (strcmp (fnd.name, "<unknown>") != 0)
+ + if (fnd.is_unknown ())
+
+ This change inverted the sense of the test, which causes failures with
+ .debug_names.
+
+ This patch fixes the bug. Regression tested on x86-64 Fedora 34. I
+ also tested it using the AdaCore internal test suite, with
+ .debug_names -- this was failing before, and now it works.
+
+2021-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: Use tp_init instead of tp_new to setup gdb.Value
+ The documentation suggests that we implement gdb.Value.__init__,
+ however, this is not currently true, we really implement
+ gdb.Value.__new__. This will cause confusion if a user tries to
+ sub-class gdb.Value. They might write:
+
+ class MyVal (gdb.Value):
+ def __init__ (self, val):
+ gdb.Value.__init__(self, val)
+
+ obj = MyVal(123)
+ print ("Got: %s" % obj)
+
+ But, when they source this code they'll see:
+
+ (gdb) source ~/tmp/value-test.py
+ Traceback (most recent call last):
+ File "/home/andrew/tmp/value-test.py", line 7, in <module>
+ obj = MyVal(123)
+ File "/home/andrew/tmp/value-test.py", line 5, in __init__
+ gdb.Value.__init__(self, val)
+ TypeError: object.__init__() takes exactly one argument (the instance to initialize)
+ (gdb)
+
+ The reason for this is that, as we don't implement __init__ for
+ gdb.Value, Python ends up calling object.__init__ instead, which
+ doesn't expect any arguments.
+
+ The Python docs suggest that the reason why we might take this
+ approach is because we want gdb.Value to be immutable:
+
+ https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new
+
+ But I don't see any reason why we should require gdb.Value to be
+ immutable when other types defined in GDB are not. This current
+ immutability can be seen in this code:
+
+ obj = gdb.Value(1234)
+ print("Got: %s" % obj)
+ obj.__init__ (5678)
+ print("Got: %s" % obj)
+
+ Which currently runs without error, but prints:
+
+ Got: 1234
+ Got: 1234
+
+ In this commit I propose that we switch to using __init__ to
+ initialize gdb.Value objects.
+
+ This does introduce some additional complexity, during the __init__
+ call a gdb.Value might already be associated with a gdb value object,
+ in which case we need to cleanly break that association before
+ installing the new gdb value object. However, the cost of doing this
+ is not great, and the benefit - being able to easily sub-class
+ gdb.Value seems worth it.
+
+ After this commit the first example above works without error, while
+ the second example now prints:
+
+ Got: 1234
+ Got: 5678
+
+ In order to make it easier to override the gdb.Value.__init__ method,
+ I have tweaked the definition of gdb.Value.__init__. The second,
+ optional argument to __init__ is a gdb.Type, if this argument is not
+ present then GDB figures out a suitable type.
+
+ However, if we want to override the __init__ method in a sub-class,
+ and still support the default argument, it is easier to write:
+
+ class MyVal (gdb.Value):
+ def __init__ (self, val, type=None):
+ gdb.Value.__init__(self, val, type)
+
+ Currently, passing None for the Type will result in an error:
+
+ TypeError: type argument must be a gdb.Type.
+
+ After this commit I now allow the type argument to be None, in which
+ case GDB figures out a suitable type just as if the type had not been
+ passed at all.
+
+ Unless a user is trying to reinitialize a value, or create sub-classes
+ of gdb.Value, there should be no user visible changes after this
+ commit.
+
+2021-12-08 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: use try/catch around a gdb_disassembler::print_insn call
+ While investigating some disassembler problems I ran into this case;
+ GDB compiled on a 32-bit arm target, with --enable-targets=all. Then
+ in GDB:
+
+ (gdb) set architecture i386
+ (gdb) disassemble 0x0,+4
+ unknown disassembler error (error = -1)
+
+ This is interesting because it shows a case where the libopcodes
+ disassembler is returning -1 without first calling the
+ memory_error_func callback. Indeed, the return from libopcodes
+ happens from this code snippet in i386-dis.c in the print_insn
+ function:
+
+ if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
+ {
+ (*info->fprintf_func) (info->stream,
+ _("64-bit address is disabled"));
+ return -1;
+ }
+
+ Notice how, prior to the return the disassembler tries to print a
+ helpful message out, but GDB doesn't print this message.
+
+ The reason this message goes missing is the call stack, it looks like
+ this:
+
+ gdb_pretty_print_disassembler::pretty_print_insn
+ gdb_disassembler::print_insn
+ gdbarch_print_insn
+ ...
+ i386-dis.c:print_insn
+
+ When i386-dis.c:print_insn returns -1 this is handled in
+ gdb_disassembler::print_insn, where an exception is thrown. However,
+ the actual printing of the disassembler output is done in
+ gdb_pretty_print_disassembler::pretty_print_insn, and is only done if
+ an exception is not thrown.
+
+ In this commit I change this. The pretty_print_insn now uses
+ try/catch around the call to gdb_disassembler::print_insn, if we catch
+ an error then we first print any pending output in the instruction
+ buffer, before rethrowing the exception. As a result, even if an
+ exception is thrown we still print any pending disassembler output to
+ the screen; in the above case the helpful message will now be shown.
+
+ Before my patch we might expect to see this output:
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x0000000000000000: unknown disassembler error (error = -1)
+ (gdb)
+
+ But now we see this:
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x0000000000000000: 64-bit address is disabled
+ unknown disassembler error (error = -1)
+
+ If the disassembler returns -1 without printing a helpful message then
+ we would still expect a change in output, something like:
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x0000000000000000:
+ unknown disassembler error (error = -1)
+
+ Which I think is still acceptable, though at this point I think a
+ strong case can be made that this is a disassembler bug (not printing
+ anything, but still returning -1).
+
+ Notice however, that the error message is always printed on a new line
+ now. This is also true for the memory error case, where before we
+ might see this:
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x00000000: Cannot access memory at address 0x0
+
+ We now get this:
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x00000000:
+ Cannot access memory at address 0x0
+
+ For me, I'm happy to accept this change, having the error on a line by
+ itself, rather than just appended to the end of the previous line,
+ seems like an improvement, but I'm aware others might feel
+ differently, so I'd appreciate any feedback.
+
+2021-12-08 Jan Vrany <jan.vrany@labware.com>
+
+ ppc: recognize all program traps
+ Permanent program breakpoints (ones inserted into the code) other than
+ the one GDB uses for POWER (0x7fe00008) did not result in stop but
+ caused GDB to loop infinitely.
+
+ This was because GDB did not recognize trap instructions other than
+ "trap". For example, "tw 12, 4, 4" was not be recognized, causing GDB
+ to loop forever.
+
+ This commit fixes this by providing POWER specific hook
+ (gdbarch_program_breakpoint_here_p) recognizing all tw, twi, td and tdi
+ instructions.
+
+ Tested on Linux on PowerPC e500 and on QEMU PPC64le.
+
+2021-12-08 Jan Vrany <jan.vrany@labware.com>
+
+ ppc: use "trap" ("tw, 31, 0, 0") as breakpoint instruction
+ Power ISA 3.0 B spec [1], sections 3.3.11 "Fixed-Point Trap Instructions"
+ and section C.6 "Trap Mnemonics" specify "tw, 31, 0, 0" (encoded as
+ 0x7fe00008) as canonical unconditional trap instruction.
+
+ This commit changes the breakpoint instruction used by GDB from
+ "tw 12, r2, r2" to unconditional "trap".
+
+ [1]: https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
+
+2021-12-08 Fangrui Song <maskray@google.com>
+
+ bfd_section_from_shdr: Support SHT_RELR sections
+ If a.so contains an SHT_RELR section, objcopy a.so will fail with:
+
+ a.so: unknown type [0x13] section `.relr.dyn'
+
+ This change allows objcopy to work.
+
+ bfd/
+ * elf.c (bfd_section_from_shdr): Support SHT_RELR.
+
+2021-12-08 Alan Modra <amodra@gmail.com>
+
+ PR28673, input file 'gcov' is the same as output file
+ PR 28673
+ * ldlang.c (open_output): Use local_sym_name when checking
+ output against input files rather than filename.
+
+2021-12-08 Tom Tromey <tom@tromey.com>
+
+ Fix bug in source.c change
+ My earlier change to source.c ("Remove an xfree from add_path")
+ introduced a regression. This patch fixes the problem.
+
+2021-12-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make struct linespect contain vectors, not pointers to vectors
+ struct linespec contains pointers to vectors, instead of containing
+ vectors directly. This is probably historical, when linespec_parser
+ (which contains a struct linespec field) was not C++-ified yet. But it
+ seems easy to change the pointers to vectors to just vectors today.
+ This simplifies the code, we don't need to manually allocate and delete
+ the vectors and there's no pointer that can be NULL.
+
+ As far as I understand, there was not meaningful distinction between a
+ NULL pointer to vector and an empty vector. So all NULL checks are
+ changed for !empty checks.
+
+ Change-Id: Ie759707da14d9d984169b93233343a86e2de9ee6
+
+2021-12-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-07 Tom Tromey <tom@tromey.com>
+
+ Remove an xfree from add_path
+ This removes a temporary \0 assignment and an xfree from add_path,
+ replacing it with a simpler use of std::string.
+
+2021-12-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/linespec.c: simplify condition
+ We can remove the empty check: if the vector has size 1, it is obviously
+ not empty. This code ended up like this because the empty check used to
+ be a NULL check.
+
+ Change-Id: I1571bd0228818ca93f6a6b444e9b010dc2da4c08
+
+2021-12-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: rename "maint agent" functions
+ Functions agent_eval_command and agent_command are used to implement
+ maintenance commands, rename them accordingly (with the maint_ prefix),
+ as well as the agent_command_1 helper function.
+
+ Change-Id: Iacf96d4a0a26298e8dd4648a0f38da649ea5ef61
+
+2021-12-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make set_raw_breakpoint static
+ set_raw_breakpoint is only used in breakpoint.c, make it static.
+
+ Change-Id: I7fbeda067685309a30b88aceaf957eff7a28e310
+
+2021-12-07 John Baldwin <jhb@FreeBSD.org>
+
+ Support AT_FXRNG and AT_KPRELOAD on FreeBSD.
+ FreeBSD's kernel has recently added two new ELF auxiliary vector
+ entries. AT_FXRNG points to a root seed version for the kernel's
+ PRNG. Userland can use this to reseed a userland PRNG after the
+ kernel's PRNG has reseeded. AT_KPRELOAD is the base address of a
+ kernel-provided vDSO.
+
+ This change displays the proper name and description of these entries
+ in 'info auxv'.
+
+ include/ChangeLog:
+
+ * elf/common.h (AT_FREEBSD_FXRNG, AT_FREEBSD_KPRELOAD): Define.
+
+2021-12-07 Tom Tromey <tromey@adacore.com>
+
+ Avoid extra work in global_symbol_searcher::expand_symtabs
+ I noticed that global_symbol_searcher::expand_symtabs always passes a
+ file matcher to expand_symtabs_matching. However, if 'filenames' is
+ empty, then this always returns true. It's slightly more efficient to
+ pass a null file matcher in this case, because that lets the "quick"
+ symbol implementations skip any filename checks.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix options arg handling in compile_jit_elf_main_as_so
+ In commit 80ad340c902 ("[gdb/testsuite] use -Ttext-segment for jit-elf tests")
+ the following change was made:
+ ...
+ proc compile_jit_elf_main_as_so {main_solib_srcfile main_solib_binfile options} {
+ - set options [concat $options debug]
+ + global jit_load_address jit_load_increment
+ +
+ + set options [list \
+ + additional_flags="-DMAIN=jit_dl_main" \
+ + additional_flags=-DLOAD_ADDRESS=$jit_load_address \
+ + additional_flags=-DLOAD_INCREMENT=$jit_load_increment \
+ + debug]
+ ...
+
+ Before the change, the options argument was used, but after the change not
+ anymore.
+
+ Fix this by reverting back to using "set options [concat $options ...]".
+
+ Fixing this gets us twice the -DMAIN=jit_dl_main bit, once from a caller, and
+ once from compile_jit_elf_main_as_so. Fix this by removing the bit from
+ compile_jit_elf_main_as_so, which makes the code similar to compile_jit_main.
+
+ Tested on x86_64-linux.
+
+2021-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.tui/basic.exp
+ On openSUSE Leap 15.2 aarch64 I ran into:
+ ...
+ FAIL: gdb.tui/basic.exp: check main is where we expect on the screen
+ ...
+ while this is passing on x86_64.
+
+ On x86_64-linux we have at the initial screen dump for "list -q main":
+ ...
+ 0 +-/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.tui/tui-layout.c--+
+ 1 | 15 You should have received a copy of the GNU General Public |
+ 2 | 16 along with this program. If not, see <http://www.gnu.org/|
+ 3 | 17 |
+ 4 | 18 int |
+ 5 | 19 main () |
+ 6 | 20 { |
+ 7 | 21 return 0; |
+ 8 | 22 } |
+ 9 | 23 |
+ ...
+ but on aarch64:
+ ...
+ 0 +-/home/tdevries/gdb/src/gdb/testsuite/gdb.tui/tui-layout.c--------------+
+ 1 | 16 along with this program. If not, see <http://www.gnu.org/|
+ 2 | 17 |
+ 3 | 18 int |
+ 4 | 19 main () |
+ 5 | 20 { |
+ 6 | 21 return 0; |
+ 7 | 22 } |
+ 8 | 23 |
+ 9 | 24 |
+ ...
+
+ The cause of the diffferent placement is that we have as line number for main
+ on x86_64:
+ ...
+ $ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
+ Line 20 of "tui-layout.c" starts at address 0x4004a7 <main> \
+ and ends at 0x4004ab <main+4>.
+ ...
+ and on aarch64 instead:
+ ...
+ $ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
+ Line 21 of "tui-layout.c" starts at address 0x4005f4 <main> \
+ and ends at 0x4005f8 <main+4>.
+ ...
+
+ Fix this by using a new source file main-one-line.c, that implements the
+ entire main function on a single line, in order to force the compiler to use
+ that line number.
+
+ Also try to do less hard-coding in the test-case.
+
+ Tested on x86_64-linux and aarch64-linux.
+
+2021-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix inferior plt calls in PIE for i386
+ Consider test-case test.c:
+ ...
+ int main (void) {
+ void *p = malloc (10);
+ return 0;
+ }
+ ...
+
+ When compiled to a non-PIE exec:
+ ...
+ $ gcc -m32 test.c
+ ...
+ the call sequence looks like:
+ ...
+ 8048447: 83 ec 0c sub $0xc,%esp
+ 804844a: 6a 0a push $0xa
+ 804844c: e8 bf fe ff ff call 8048310 <malloc@plt>
+ ...
+ which calls to:
+ ...
+ 08048310 <malloc@plt>:
+ 8048310: ff 25 0c a0 04 08 jmp *0x804a00c
+ 8048316: 68 00 00 00 00 push $0x0
+ 804831b: e9 e0 ff ff ff jmp 8048300 <.plt>
+ ...
+ where the first insn at 0x8048310 initially jumps to the following address
+ 0x8048316, read from the .got.plt @ 0x804a00c:
+ ...
+ 804a000 0c9f0408 00000000 00000000 16830408 ................
+ 804a010 26830408 &...
+ ...
+
+ Likewise, when compiled as a PIE:
+ ...
+ $ gcc -m32 -fPIE -pie test.c
+ ...
+ we have this call sequence (with %ebx setup to point to the .got.plt):
+ ...
+ 0000055d <main>:
+ 579: 83 ec 0c sub $0xc,%esp
+ 57c: 6a 0a push $0xa
+ 57e: 89 c3 mov %eax,%ebx
+ 580: e8 6b fe ff ff call 3f0 <malloc@plt>
+ ...
+ which calls to:
+ ...
+ 000003f0 <malloc@plt>:
+ 3f0: ff a3 0c 00 00 00 jmp *0xc(%ebx)
+ 3f6: 68 00 00 00 00 push $0x0
+ 3fb: e9 e0 ff ff ff jmp 3e0 <.plt>
+ ...
+ where the insn at 0x3f0 initially jumps to following address 0x3f6, read from
+ the .got.plt at offset 0xc:
+ ...
+ 2000 f41e0000 00000000 00000000 f6030000 ................
+ 2010 06040000 ....
+ ...
+
+ When instead doing an inferior call to malloc (with nosharedlib to force
+ malloc to resolve to malloc@plt rather than the functions in ld.so or libc.so)
+ with the non-PIE exec, we have the expected:
+ ...
+ $ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
+ Temporary breakpoint 1 at 0x8048444
+
+ Temporary breakpoint 1, 0x08048444 in main ()
+ $1 = 0x804b160
+ ...
+
+ But with the PIE exec, we run into:
+ ...
+ $ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
+ Temporary breakpoint 1 at 0x56c
+
+ Temporary breakpoint 1, 0x5655556c in main ()
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x565553f0 in malloc@plt ()
+ ...
+
+ The segfault happens because:
+ - the inferior call mechanism doesn't setup %ebx
+ - %ebx instead is 0
+ - the jump to "*0xc(%ebx)" reads from memory at 0xc
+
+ Fix this by setting up %ebx properly in i386_thiscall_push_dummy_call.
+
+ Fixes this failure with target board unix/-m32/-pie/-fPIE reported in
+ PR28467:
+ ...
+ FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2)
+ ...
+
+ Tested on x86_64-linux, with target board unix/-m32 and unix/-m32/-fPIE/-pie.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28467
+
+2021-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Support -readnow during reread
+ When running test-case gdb.base/cached-source-file.exp with target board
+ readnow, we run into:
+ ...
+ FAIL: gdb.base/cached-source-file.exp: rerun program (the program exited)
+ ...
+
+ The problem is that when rereading, the readnow is ignored.
+
+ Fix this by copying the readnow handling code from symbol_file_add_with_addrs
+ to reread_symbols.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26800
+
+2021-12-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Fix assert in ada_is_unconstrained_packed_array_type
+ On openSUSE Leap 42.3, with system compiler gcc 4.8.5 I run into:
+ ...
+ (gdb) print u_one_two_three^M
+ src/gdb/gdbtypes.h:1050: internal-error: field: \
+ Assertion `idx >= 0 && idx < num_fields ()' failed.^M
+ ...
+
+ We run into trouble while doing this in
+ ada_is_unconstrained_packed_array_type:
+ ...
+ 1953 return TYPE_FIELD_BITSIZE (type, 0) > 0;
+ ...
+ which tries to get field 0 from a type without fields:
+ ...
+ (gdb) p type->num_fields ()
+ $6 = 0
+ ...
+ which is the case because the type is a typedef:
+ ...
+ (gdb) p type->code ()
+ $7 = TYPE_CODE_TYPEDEF
+ ...
+
+ Fix this by using the type referenced by the typedef instead.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28323
+
+2021-12-07 Alan Modra <amodra@gmail.com>
+
+ Re: Add support for AArch64 EFI (efi-*-aarch64)
+ Commit b69c9d41e8 was broken in multiple ways regarding the realloc
+ of the target string, most notably in that "-little" wasn't actually
+ appended to the input_target or output_target. This caused asan
+ errors and "FAIL: Check if efi app format is recognized". I also
+ noticed that the input_target string wasn't being copied but rather
+ the output_target when dealing with the input target. Fix that too.
+
+ PR 26206
+ * objcopy.c (convert_efi_target): Rewrite. Allocate modified
+ target strings here..
+ (copy_main): ..rather than here. Do handle input_target,
+ not output_target for input.
+
+2021-12-07 Alan Modra <amodra@gmail.com>
+
+ Error on ld output file name matching input file name
+ It's not foolproof, for example we don't catch output to a linker
+ script, to a library specified with -l, or to an element of a thin
+ archive.
+
+ * ldlang.c (open_output): Exit with error on output file matching
+ an input file.
+ * testsuite/ld-misc/just-symbols.exp: Adjust ld -r test to suit.
+
+2021-12-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-06 Carl Love <cel@us.ibm.com>
+
+ gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame
+ This patch adds an #elif defined for PowerPC to setup the exit_0 macro.
+ This patch addes the needed macro definitionald logic to handle both elfV1
+ and elfV2.
+
+ The patch has been successfully tested on both PowerPC BE, Powerpc LE and
+ X86_64 with no regressions.
+
+2021-12-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use precise align in gdb.arch/i386-{avx,sse}.exp
+ Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require
+ the memory operands to be aligned to a certain boundary, and the test-cases
+ use C11's _Alignas to make that happen.
+
+ The draw-back of using _Alignas is that while it does enforce a minimum
+ alignment, the actual alignment may be bigger, which makes the following
+ scenario possible:
+ - copy say, gdb.arch/i386-avx.c as basis for a new test-case
+ - run the test-case and observe a PASS
+ - commit the new test-case in the supposition that the test-case is correct
+ and well-tested
+ - run later into a failure on a different test setup (which may be a setup
+ where reproduction and investigation is more difficult and time-consuming),
+ and find out that the specified alignment was incorrect and should have been
+ updated to say, 64 bytes. The initial PASS occurred only because the actual
+ alignment happened to be greater than required.
+
+ The idea of having precise alignment as a means of having more predictable
+ execution which allows flushing out bugs earlier, has been filed as PR
+ gcc/103095.
+
+ Add a new file lib/precise-aligned-alloc.c with functions
+ precise_aligned_alloc and precise_aligned_dup, to support precise alignment.
+
+ Use precise_aligned_dup in aforementioned test-cases to:
+ - verify that the specified alignment is indeed sufficient, rather
+ than too little but accidentally over-aligned.
+ - prevent the same type of problems in any new test-cases based on these
+
+ Tested on x86_64-linux, with both gcc and clang.
+
+2021-12-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix data alignment in gdb.arch/i386-{avx,sse}.exp
+ When running test-case gdb.arch/i386-avx.exp with clang I ran into:
+ ...
+ (gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main
+ continue^M
+ Continuing.^M
+ ^M
+ Program received signal SIGSEGV, Segmentation fault.^M
+ 0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M
+ 54 asm ("vmovaps 0(%0), %%ymm0\n\t"^M
+ (gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \
+ continue to first breakpoint in main
+ ...
+
+ The problem is that the vmovaps insn requires an 256-bit (or 32-byte) aligned
+ address, and it's only 16-byte aligned:
+ ...
+ (gdb) p /x $rax
+ $1 = 0x601030
+ ...
+
+ Fix this by using a sufficiently aligned address, using _Alignas.
+
+ Compile using -std=gnu11 to support _Alignas.
+
+ Likewise in gdb.arch/i386-sse.exp.
+
+ Tested on x86_64-linux, with both gcc and clang.
+
+2021-12-06 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64 inline plt sequences
+ The fixes gold failures to handle inline PLT sequences properly.
+ PowerPC gold was always turning these back into direct calls due to
+ gsym->use_plt_offset() returning false. This is fixed for dynamic
+ linking by correcting get_reference_flags, and for static linking by
+ overriding use_plt_offset() in relocate(). The rest of the patch
+ revolves around needing to create PLT entries for inline PLT calls
+ when statically linking (for gcc -mlongcall). The lplt section
+ handled that for local symbols, now it does globals too.
+
+ * powerpc.cc (Target_powerpc::plt_off): Return proper section
+ for static link.
+ (Target_powerpc::symval_for_branch): Make public.
+ (Target_powerpc::make_lplt_section): Add Symbol_table* param.
+ Adjust all calls.
+ (Target_powerpc::make_local_plt_entry): Likewise.
+ (Target_powerpc::make_local_plt_entry): New variant for global syms.
+ (Powerpc_relobj::do_relocate_sections): Don't write lplt contents.
+ (Output_data_plt_powerpc::do_write): Write lplt contents here.
+ (Output_data_plt_powerpc::Output_data_plt_powerpc): Save
+ symbol table pointer. Adjust all uses.
+ (Output_data_plt_powerpc::add_entry): Add stash parameter. Don't
+ do dynamic reloc handling when no reloc section. Save symbol
+ for local plt entries.
+ (Output_data_plt_powerpc::add_local_entry): Save symbol.
+ (Output_data_plt_powerpc::Local_plt_ent): New class.
+ (Output_data_plt_powerpc::sym_ents_): New vector.
+ (Target_powerpc::Scan::get_reference_flags): Return
+ FUNCTION_CALL|RELATIVE_REF for inline plt relocs.
+ (Target_powerpc::Scan::global): Make entries in lplt for inline
+ plt call relocation symbols.
+ (Target_powerpc::Relocate::relocate): Rename has_plt_offset to
+ use_plt_offset. Set use_plt_offset for inline plt relocs.
+
+2021-12-06 Clément Chigot <clement.chigot@atos.net>
+
+ ld: improve shared tests for AIX
+ It's now possible to refer symbols in the main program from the
+ shared library. However, it still impossible to have the same
+ overriden features between shared objects and mains than ELF,
+ without using the runtime linking feature which isn't yet fully
+ available.
+
+ ld/ChangeLog:
+
+ * testsuite/ld-shared/shared.exp: Improve XCOFF support
+ * testsuite/ld-shared/main.c: Likewise.
+ * testsuite/ld-shared/sh1.c: Likewise.
+ * testsuite/ld-shared/xcoff.dat: Likewise.
+
+2021-12-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-05 Tom Tromey <tom@tromey.com>
+
+ Preserve artificial CU name in process_psymtab_comp_unit_reader
+ This fixes a use-after-free that Simon pointed out.
+ process_psymtab_comp_unit_reader was allocating an artificial name for
+ a CU, and then discarding it. However, this name was preserved in the
+ cached file_and_directory. This patch arranges for the allocated name
+ to be preserved there.
+
+2021-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: include ansidecl.h when needed
+ Avoid implicit include deps with this to help untangle sim headers
+ so we can get rid of arch-specific sim-main.h.
+
+ sim: include stdint.h when needed
+ Avoid implicit include deps with this to help untangle sim headers
+ so we can get rid of arch-specific sim-main.h.
+
+ sim: include stdarg.h when used
+ Avoid implicit include deps with this to help untangle sim headers
+ so we can get rid of arch-specific sim-main.h.
+
+2021-12-05 Mike Frysinger <vapier@gentoo.org>
+
+ sim: reorder header includes
+ We're including system headers after local headers in a bunch of
+ places, but this leads to conflicts when our local headers happen
+ to define symbols that show up in the system headers.
+
+ Use the more standard order of:
+ * config.h (via defs.h)
+ * system headers
+ * local library headers (e.g. bfd & libiberty)
+ * sim specific headers
+
+2021-12-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: fix memory leak in create_file_handler when re-using file handler
+ ASan made me notice a memory leak, where the memory tied to the file
+ handle name string wasn't freed. When register a file handler with an
+ fd that is already registered, we re-use the file_handler object, so we
+ ended up creating a new std::string object and overwriting the
+ file_handler::name pointer, without free-ing the old std::string.
+
+ Fix this by allocating file_handler with new, deleting it with
+ delete, and making file_handler::name not a pointer.
+
+ Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43
+
+2021-12-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: moxie: hoist dtb rules up to common builds
+ These rules don't depend on the target compiler settings, so hoist
+ the build logic up to the common builds for better parallelization.
+
+ sim: m68hc11: delete unused profile flags
+ These were moved to the common configure script a while ago and have
+ the same default as these, so just delete it.
+
+ sim: msp430: delete redundant comments & settings
+ These were copied from the example docs, so aren't adding any value.
+
+ sim: erc32: drop old configure target
+ There is no configure script in here anymore to regenerate.
+
+ sim: m32c/rl78: drop redundant -Wall settings
+ We already turn these on in the configure script.
+
+2021-12-04 Tom Tromey <tom@tromey.com>
+
+ Cache the result of find_file_and_directory
+ This changes the DWARF reader to cache the result of
+ find_file_and_directory. This is not especially important now, but it
+ will help the new DWARF indexer.
+
+ Move file_and_directory to new file and C++-ize
+ This moves file_and_directory to a new file, and then C++-izes it --
+ replacing direct assignments with methods, and arranging for it to own
+ any string that must be computed. Finally, the CU's objfile will only
+ be used on demand; this is an important property for the new DWARF
+ indexer's parallel mode.
+
+ Remove Irix case from find_file_and_directory
+ find_file_and_directory has a special case for the Irix 6.2 compiler.
+ Since this is long obsolete, this patch removes it.
+
+2021-12-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: frv: split up testsuite a bit
+ Running frv's allinsn in serial is quite slow due to the sheer number
+ of tests it contains. By splitting it up and running in parallel, the
+ execution time on my system goes from ~100sec to ~60sec.
+
+2021-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: don't show deprecated aliases
+ I don't think it's very useful to show deprecated aliases to the
+ user. It encourages the user to use them, when the goal is the
+ opposite.
+
+ For example, before:
+
+ (gdb) help set index-cache enabled
+ set index-cache enabled, set index-cache off, set index-cache on
+ alias set index-cache off = set index-cache enabled off
+ alias set index-cache on = set index-cache enabled on
+ Enable the index cache.
+ When on, enable the use of the index cache.
+
+ (gdb) help set index-cache on
+ Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
+ Use 'set index-cache enabled on'.
+
+ set index-cache enabled, set index-cache off, set index-cache on
+ alias set index-cache off = set index-cache enabled off
+ alias set index-cache on = set index-cache enabled on
+ Enable the index cache.
+ When on, enable the use of the index cache.
+
+ After:
+
+ (gdb) help set index-cache enabled
+ Enable the index cache.
+ When on, enable the use of the index cache.
+ (gdb) help set index-cache on
+ Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
+ Use 'set index-cache enabled on'.
+
+ Enable the index cache.
+ When on, enable the use of the index cache.
+
+ Change-Id: I989b618a5ad96ba975367e9d16db95523cd57a4c
+
+2021-12-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix two "maint info line-table"-related tests
+ Commit 92228a334ba2 ("gdb: small "maintenance info line-table"
+ readability improvements") change the output format of "maint info
+ line-table" slightly, adding some empty lines between each
+ line-table. This causes two tests to start failing, update them to
+ account for those empty lines.
+
+ Change-Id: I9d33a58fce3e860ba0554b25f5582e8066a5c519
+
+2021-12-04 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: revert one array_view copy change in ada-lang.c
+ Commit 4bce7cdaf481 ("gdbsupport: add array_view copy function") caused
+ an internal error when running gdb.ada/packed_array_assign.exp:
+
+ print pra(1) := pr^M
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.^M
+
+ I am not sure what's the root cause of this, whether it is a GDB bug
+ exposed by using the array_view copy function or not. Back out the
+ change that triggers the internal error for now, while we investigate
+ it.
+
+ Change-Id: I055ab14143e4cfd3ca7ce8f4855c6c3c05db52a7
+
+2021-12-04 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: unify header generation rules
+ The logic between these rules are extremely similar, so unify them
+ into a single variable.
+
+2021-12-04 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: move header updates up a directory
+ The rules for rebuilding the bfd headers live in the doc/ subdir
+ (most likely) because they rely on the chew & related tools. But
+ we can collapse them into the main Makefile while keeping the tools
+ in the doc subdir easily enough. This makes the code simpler and
+ allows for rebuilding them in parallel.
+
+ Also add automake silent rule support while we're here.
+
+2021-12-04 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: convert bfdver.h to silent automake rules
+
+2021-12-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: small "maintenance info line-table" readability improvements
+ - separate each entry with a newline, to visually separate them
+ - style filenames with the filename style
+ - print the name of the compunit_symtab
+
+ A header now looks like this, with the compunit_symtab name added (and
+ the coloring, but you can't really see it here):
+
+ objfile: /home/simark/build/babeltrace/src/cli/.libs/babeltrace2 ((struct objfile *) 0x613000005980)
+ compunit_symtab: babeltrace2-cfg-cli-args.c ((struct compunit_symtab *) 0x62100da1ed10)
+ symtab: /usr/include/glib-2.0/glib/gdatetime.h ((struct symtab *) 0x62100d9ee530)
+ linetable: ((struct linetable *) 0x0):
+
+ Change-Id: Idc23e10aaa66e2e692adb0a6a74144f72c4fa1c7
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change some alias functions parameters to const-reference
+ Now that we use intrusive list to link aliases, it becomes easier to
+ pass cmd_list_element arguments by const-reference rather than by
+ pointer to some functions, change a few.
+
+ Change-Id: Id0df648ed26e9447da0671fc2c858981cda31df8
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use intrusive_list for cmd_list_element aliases list
+ Change the manually-implemented linked list to use intrusive_list. This
+ is not strictly necessary, but it makes the code much simpler.
+
+ Change-Id: Idd08090ebf2db8bdcf68e85ef72a9635f1584ccc
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: trivial changes to use array_view
+ Change a few relatively obvious spots using value contents to propagate
+ the use array_view a bit more.
+
+ Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make extract_integer take an array_view
+ I think it would make sense for extract_integer, extract_signed_integer
+ and extract_unsigned_integer to take an array_view. This way, when we
+ extract an integer, we can validate that we don't overflow the buffer
+ passed by the caller (e.g. ask to extract a 4-byte integer but pass a
+ 2-byte buffer).
+
+ - Change extract_integer to take an array_view
+ - Add overloads of extract_signed_integer and extract_unsigned_integer
+ that take array_views. Keep the existing versions so we don't
+ need to change all callers, but make them call the array_view
+ versions.
+
+ This shortens some places like:
+
+ result = extract_unsigned_integer (value_contents (result_val).data (),
+ TYPE_LENGTH (value_type (result_val)),
+ byte_order);
+
+ into
+
+ result = extract_unsigned_integer (value_contents (result_val), byte_order);
+
+ value_contents returns an array view that is of length
+ `TYPE_LENGTH (value_type (result_val))` already, so the length is
+ implicitly communicated through the array view.
+
+ Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: add array_view copy function
+ An assertion was recently added to array_view::operator[] to ensure we
+ don't do out of bounds accesses. However, when the array_view is copied
+ to or from using memcpy, it bypasses that safety.
+
+ To address this, add a `copy` free function that copies data from an
+ array view to another, ensuring that the destination and source array
+ views have the same size. When copying to or from parts of an
+ array_view, we are expected to use gdb::array_view::slice, which does
+ its own bounds check. With all that, any copy operation that goes out
+ of bounds should be caught by an assertion at runtime.
+
+ copy is implemented using std::copy and std::copy_backward, which, at
+ least on libstdc++, appears to pick memmove when copying trivial data.
+ So in the end there shouldn't be much difference vs using a bare memcpy,
+ as we do right now. When copying non-trivial data, std::copy and
+ std::copy_backward assigns each element in a loop.
+
+ To properly support overlapping ranges, we must use std::copy or
+ std::copy_backward, depending on whether the destination is before the
+ source or vice-versa. std::copy and std::copy_backward don't support
+ copying exactly overlapping ranges (where the source range is equal to
+ the destination range). But in this case, no copy is needed anyway, so
+ we do nothing.
+
+ The order of parameters of the new copy function is based on std::copy
+ and std::copy_backward, where the source comes before the destination.
+
+ Change a few randomly selected spots to use the new function, to show
+ how it can be used.
+
+ Add a test for the new function, testing both with arrays of a trivial
+ type (int) and of a non-trivial type (foo). Test non-overlapping
+ ranges as well as three kinds of overlapping ranges: source before dest,
+ dest before source, and dest == source.
+
+ Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03
+
+2021-12-03 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: change store_waitstatus to return a target_waitstatus by value
+ store_waitstatus is basically a translation function between a status
+ integer and an equivalent target_waitstatus object. It would make sense
+ for it to take the integer as a parameter and return the
+ target_waitstatus by value. Do that, and rename to
+ host_status_to_waitstatus. Users can then do:
+
+ ws = host_status_to_waitstatus (status)
+
+ which does the right thing, given the move constructor of
+ target_waitstatus.
+
+ Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b
+
+2021-12-03 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: return *this in target_waitstatus setters
+ While playing with some code creating target_waitstatus objects, I was
+ mildly annoyed by the fact that we can't just return a new
+ target_waitstatus object. We have to do:
+
+ target_waitstatus ws;
+ ws.set_exited (123);
+ return ws;
+
+ Make the setters return the "this" object as a reference, such that it's
+ possible to do:
+
+ return target_waitstatus ().set_exited (123);
+
+ I initially thought of adding static creation functions, which you would
+ use like:
+
+ return target_waitstatus::make_exited (123);
+
+ However, making the setters return a reference to the object achieves
+ pretty much the same thing, with less new code.
+
+ Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147
+
+2021-12-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make saved_filename an std::string
+ Make this variable an std::string, avoiding manual memory management.
+
+ Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947
+
+2021-12-03 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Fix uninitialised memory
+ AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B
+ are not paired with an error string, but we had an assert that the
+ error was nonnull. Previously this assert was testing uninitialised
+ memory and so could pass or fail arbitrarily.
+
+ opcodes/
+ * aarch64-opc.c (verify_mops_pme_sequence): Initialize the error
+ field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and
+ AARCH64_OPDE_A_SHOULD_FOLLOW_B.
+ * aarch64-dis.c (print_verifier_notes): Move assert.
+
+2021-12-03 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: make value_subscripted_rvalue static
+ The function value_subscripted_rvalue is only used in valarith.c, so
+ lets make it a static function.
+
+ There should be no user visible change after this commit.
+
+2021-12-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: give a test a real name
+ A test in gdb.python/py-send-packet.exp added in this commit:
+
+ commit 24b2de7b776f8f23788d855b1eec290c6e208821
+ Date: Tue Aug 31 14:04:36 2021 +0100
+
+ gdb/python: add gdb.RemoteTargetConnection.send_packet
+
+ included a large amount of binary data in the command sent to GDB. As
+ this test didn't have a real test name the binary data was included in
+ the gdb.sum file. The contents of the binary data could change
+ between different runs of GDB, and this makes comparing results
+ harder.
+
+ This commit gives the test a real test name.
+
+2021-12-03 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/remote: fix use after free bug
+ This commit:
+
+ commit 288712bbaca36bff6578bc839ebcdc3707662f81
+ Date: Mon Nov 22 15:16:27 2021 +0000
+
+ gdb/remote: use scoped_restore to control starting_up flag
+
+ introduced a use after free bug. The scoped restore added in the
+ above commit resets a flag within a remote_target's remote_state
+ object.
+
+ However, in some situations, the remote_target can be unpushed before
+ the error is thrown. If the only reference to the target is the one
+ in the target stack, then unpushing the target will cause the
+ remote_target to be deleted, which, in turn, will delete the
+ remote_state object. The scoped restore will then try to reset the
+ flag within a deleted object.
+
+ This problem was caught in the gdb.server/server-connect.exp test,
+ which, when run with the address sanitizer enabled, highlights the
+ write after free bug described above.
+
+ This commit resolves this issue by adding a new class specifically for
+ the purpose of managing the starting_up flag. As well as setting, and
+ then clearing the starting_up flag, this new class increments, and
+ then decrements the reference count on the remote_target object. This
+ prevents the remote_target from being deleted until after the flag has
+ been reset.
+
+ The gdb.server/server-connect.exp now runs cleanly with the address
+ sanitizer enabled.
+
+2021-12-03 Mike Frysinger <vapier@gentoo.org>
+
+ libctf: workaround automake bug with conditional info pages
+ It looks like automake makes assumptions about its ability to build info
+ pages based on the GNU standard behavior of shipping info pages with the
+ distributions. So even though the info pages were conditionalized, and
+ automake disabled some of the targets, it was still creeping in by way
+ of unconditional INFO_DEPS settings.
+
+ We can workaround this by adding a stub target for the info page when
+ building info pages are disabled. This tricks automake into disabling
+ its own extended generation target. I'll follow up with the automake
+ folks to see what they think.
+
+2021-12-03 Chenghua Xu <xuchenghua@loongson.cn>
+
+ Add myself and Zhensong Liu as the LoongArch port maintainer.
+
+2021-12-03 Alan Modra <amodra@gmail.com>
+
+ Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"
+ This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41.
+ The bpf sim doesn't work with a 32-bit bfd after all.
+
+2021-12-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unexpected xstrdup in _initialize_maint_test_settings
+ That xstrdup is not correct, since we are assigning an std::string. The
+ result of xstrdup is used to initialize the string, and then lost
+ forever. Remove it.
+
+ Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335
+
+2021-12-02 Nick Clifton <nickc@redhat.com>
+
+ Fix illegal memory access whilst parsing corrupt DWARF debug information.
+ PR 28645
+ * dwarf.c (process_cu_tu_index): Add test for overruning section
+ whilst processing slots.
+
+2021-12-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix avx512 -m32 support in gdbserver
+ PR27257 reports a problem that can be reproduced as follows:
+ - use x86_64 machine with avx512 support
+ - compile a hello world with -m32 to a.out
+ - start a gdbserver session with a.out
+ - use gdb to connect to the gdbserver session
+
+ This makes us run into:
+ ...
+ Listening on port 2346
+ Remote debugging from host ::1, port 34940
+ src/gdbserver/regcache.cc:257: \
+ A problem internal to GDBserver has been detected.
+ Unknown register zmm16h requested
+ ...
+
+ The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
+ register zmm16h in the register cache.
+
+ To understand how this happens, first some background.
+
+ SSE has 16 128-bit wide xmm registers.
+
+ AVX extends the SSE registers set as follows:
+ - it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
+ registers.
+
+ AVX512 extends the AVX register set as follows:
+ - it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
+ registers.
+ - it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
+ xmm subregisters added as well)
+
+ However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.
+
+ The problem we're running into is that gdbserver/i387-fp.cc uses these
+ constants to describe the size of the register file:
+ ...
+ static const int num_avx512_zmmh_low_registers = 16;
+ static const int num_avx512_zmmh_high_registers = 16;
+ static const int num_avx512_ymmh_registers = 16;
+ static const int num_avx512_xmm_registers = 16;
+ ...
+ which are all incorrect for the 32-bit case.
+
+ Fix this by replacing the constants with variables that have the appropriate
+ values in 64-bit and 32-bit mode.
+
+ Tested on x86_64-linux with native and unix/-m32.
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: update tests looking for "DWARF 2" debug format
+ Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
+ debugformat field") changes the debug format string in "info source" to
+ show the actual DWARF version, rather than always show "DWARF 2".
+
+ However, it failed to consider that some tests checked for the "DWARF 2"
+ string to see if the test program is compiled with DWARF debug
+ information. Since everything is compiled with DWARF 4 or 5 nowadays,
+ that changed the behavior of those tests. Notably, it prevent the
+ tests using skip_inline_var_tests to run.
+
+ Grep through the testsuite for "DWARF 2" and change all occurrences I
+ could find to use "DWARF [0-9]" instead (that string is passed to TCL's
+ string match).
+
+ Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
+
+2021-12-02 Joel Brobecker <brobecker@adacore.com>
+
+ (PPC64) fix handling of fixed-point values when using "return" command
+ In the gdb.ada/fixed_points_function.exp testcase, we have the following
+ Ada code...
+
+ type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
+ function Call_FP1 (F : FP1_Type) return FP1_Type is
+ begin
+ FP1_Arg := F;
+ return FP1_Arg;
+ end Call_FP1;
+
+ ... used as follow:
+
+ F1 : FP1_Type := 1.0;
+ F1 := Call_FP1 (F1);
+
+ The testcase, among other things, verifies that "return" works
+ properly as follow:
+
+ | (gdb) return 1.0
+ | Make pck.call_fp1 return now? (y or n) y
+ | [...]
+ | 9 F1 := Call_FP1 (F1);
+ | (gdb) next
+ | (gdb) print f1
+ | $1 = 0.0625
+
+ The output of the last command shows that we returned the wrong
+ value. The value printed gives a clue about the problem, since
+ it is 1/16th of the value we expected, where 1/16 is FP1_Type's
+ scaling factor.
+
+ The problem, here, comes from the fact that the function
+ handling return values for base types (ppc64_sysv_abi_return_value_base)
+ writes the return value using unpack_long which, upon seeing that
+ the value being unpacked is a fixed point type, applies the scaling
+ factor, to get the integer-representation of our fixed-point value
+ (similar to what it does with floats, for instance).
+
+ So, the fix consists in teaching ppc64_sysv_abi_return_value_base
+ about fixed-point types, and to avoid the unwanted application
+ of the scaling factor.
+
+ Note that the "finish" function, on the other hand, does not
+ suffer from this issue, simply becaue the value returned by
+ the function is read from register without the use of a type,
+ thus avoiding an unwanted application of a scaling factor.
+
+ No test added, as this change is already tested by
+ gdb.ada/fixed_points_function.exp.
+
+ Co-Authored-By: Tristan Gingold <gingold@adacore.com>
+
+2021-12-02 Joel Brobecker <brobecker@adacore.com>
+
+ (RISCV) fix handling of fixed-point type return values
+ This commit adds support for TYPE_CODE_FIXED_POINT types for
+ "finish" and "return" commands.
+
+ Consider the following Ada code...
+
+ type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
+ function Call_FP1 (F : FP1_Type) return FP1_Type is
+ begin
+ FP1_Arg := F;
+ return FP1_Arg;
+ end Call_FP1;
+
+ ... used as follow:
+
+ F1 : FP1_Type := 1.0;
+ F1 := Call_FP1 (F1);
+
+ "finish" currently behaves as follow:
+
+ | (gdb) finish
+ | [...]
+ | Value returned is $1 = 0
+
+ We expect the returned value to be "1".
+
+ Similarly, "return" makes the function return the wrong value:
+
+ | (gdb) return 1.0
+ | Make pck.call_fp1 return now? (y or n) y
+ | [...]
+ | 9 F1 := Call_FP1 (F1);
+ | (gdb) next
+ | (gdb) print f1
+ | $1 = 0.0625
+
+ (we expect it to print "1" instead).
+
+ This problem comes from the handling of integral return values
+ when the return value is actually fixed point type. Our type
+ here is actually a range of a fixed point type, but the same
+ principles should also apply to pure fixed-point types. For
+ the record, here is what the debugging info looks like:
+
+ <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
+ <239> DW_AT_lower_bound : -16
+ <23a> DW_AT_upper_bound : 16
+ <23b> DW_AT_name : pck__fp1_type
+ <23f> DW_AT_type : <0x248>
+
+ <1><248>: Abbrev Number: 4 (DW_TAG_base_type)
+ <249> DW_AT_byte_size : 1
+ <24a> DW_AT_encoding : 13 (signed_fixed)
+ <24b> DW_AT_binary_scale: -4
+ <24c> DW_AT_name : pck__Tfp1_typeB
+ <250> DW_AT_artificial : 1
+
+ ... where the scaling factor is 1/16.
+
+ Looking at the "finish" command, what happens is that riscv_arg_location
+ determines that our return value should be returned by parameter using
+ an integral convention (via builtin type long). And then,
+ riscv_return_value uses a cast to that builtin type long to
+ store the value of into a buffer with the right register size.
+ This doesn't work in our case, because the underlying value
+ returned by the function is unscaled, which means it is 16,
+ and thus the cast is like doing:
+
+ arg_val = (FP1_Type) 16
+
+ ... In other words, it is trying to create an FP1_Type enty whose
+ value is 16. Applying the scaling factor, that's 256, and because
+ the size of FP1_Type is 1 byte, we overflow and thus it ends up
+ being zero.
+
+ The same happen with the "return" function, but the other way around.
+
+ The fix consists in handling fixed-point types separately from
+ integral types.
+
+2021-12-02 Joel Brobecker <brobecker@adacore.com>
+
+ (ARM/fixed-point) wrong value shown by "finish" command:
+ Consider the following Ada code:
+
+ type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
+ FP1_Arg : FP1_Type := 0.0;
+
+ function Call_FP1 (F : FP1_Type) return FP1_Type is
+ begin
+ FP1_Arg := F;
+ return FP1_Arg;
+ end Call_FP1;
+
+ After having stopped inside function Call_FP1 as follow:
+
+ Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5
+ 5 FP1_Arg := F;
+
+ Returning from that function call using "finish" should show
+ that the function return "1.0" (the same value as was passed
+ as an argument). However, this is not the case:
+
+ (gdb) finish
+ Run till exit from #0 pck.call_fp1 (f=1)
+ [...]
+ 9 F1 := Call_FP1 (F1);
+ Value returned is $1 = 0
+
+ This patch enhances the extraction of the return value to know about
+ fixed point types.
+
+2021-12-02 Xavier Roirand <roirand@adacore.com>
+
+ (Ada/AArch64) fix fixed point argument passing in inferior funcall
+ Consider the following code:
+
+ type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary
+
+ function Call_FP1 (F : FP1_Type) return FP1_Type is
+ begin
+ return F;
+ end Call_FP1;
+
+ When the default in GCC is to generate proper DWARF info for fixed point
+ types, then in gdb, printing the result of a call to call_fp1 with a
+ decimal parameter leads to:
+
+ (gdb) p call_fp1(0.5)
+ $1 = 0
+
+ The displayed value is wrong, and we actually expected:
+
+ (gdb) p call_fp1(0.5)
+ $1 = 0.5
+
+ What happened is that our fixed point type parameter got promoted to a
+ 32bit integer because we detected that the length of that object was less
+ than 4 bytes. The compiler does not perform this promotion and therefore
+ GDB should not either.
+
+ This patch fixes the behavior described above.
+
+2021-12-02 Tom Tromey <tromey@adacore.com>
+
+ Implement 'task apply'
+ This adds a 'task apply' command, which is the Ada tasking analogue of
+ 'thread apply'. Unlike 'thread apply', it doesn't offer the
+ 'ascending' flag; but otherwise it's essentially the same.
+
+ Add "task" keyword to the "watch" command
+ Breakpoints in gdb can be made specific to an Ada task using the
+ "task" qualifier. This patch applies this same idea to watchpoints.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Update gas/NEWS for recent changes
+ gas/
+ * NEWS: Mention support for Armv8.8-A and for new system registers.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add BC instruction
+ This patch adds support for the Armv8.8-A BC instruction.
+ [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/BC-cond--Branch-Consistent-conditionally-?lang=en]
+
+ include/
+ * opcode/aarch64.h (AARCH64_FEATURE_HBC): New macro.
+ (AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_HBC.
+
+ opcodes/
+ * aarch64-tbl.h (aarch64_feature_hbc): New variable.
+ (HBC, HBC_INSN): New macros.
+ (aarch64_opcode_table): Add BC.C.
+ * aarch64-dis-2.c: Regenerate.
+
+ gas/
+ * doc/c-aarch64.texi: Document +hbc.
+ * config/tc-aarch64.c (aarch64_features): Add "hbc".
+ * testsuite/gas/aarch64/hbc.s, testsuite/gas/aarch64/hbc.d: New test.
+ * testsuite/gas/aarch64/hbc-invalid.s,
+ testsuite/gas/aarch64/hbc-invalid.l,
+ testsuite/gas/aarch64/hbc-invalid.d: New test.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Enforce P/M/E order for MOPS instructions
+ The MOPS instructions should be used as a triple, such as:
+
+ cpyfp [x0]!, [x1]!, x2!
+ cpyfm [x0]!, [x1]!, x2!
+ cpyfe [x0]!, [x1]!, x2!
+
+ The registers should also be the same for each writeback operand.
+ This patch adds a warning for code that doesn't follow this rule,
+ along similar lines to the warning that we already emit for
+ invalid uses of MOVPRFX.
+
+ include/
+ * opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E)
+ (C_SCAN_MOPS_PME): New macros.
+ (AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind.
+ (AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise.
+ (aarch64_operand_error): Make each data value a union between
+ an int and a string.
+
+ opcodes/
+ * aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags.
+ (MOPS_SET_OP1_OP2_INSN): Likewise.
+ * aarch64-opc.c (set_out_of_range_error): Update after change to
+ aarch64_operand_error.
+ (set_unaligned_error, set_reg_list_error): Likewise.
+ (init_insn_sequence): Use a 3-instruction sequence for
+ MOPS P instructions.
+ (verify_mops_pme_sequence): New function.
+ (verify_constraints): Call it.
+ * aarch64-dis.c (print_verifier_notes): Handle
+ AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+
+ gas/
+ * config/tc-aarch64.c (operand_mismatch_kind_names): Add entries
+ for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+ (operand_error_higher_severity_p): Check that
+ AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B
+ come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR;
+ their relative order is not significant.
+ (record_operand_error_with_data): Update after change to
+ aarch64_operand_error.
+ (output_operand_error_record): Likewise. Handle
+ AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+ * testsuite/gas/aarch64/mops_invalid_2.s,
+ testsuite/gas/aarch64/mops_invalid_2.d,
+ testsuite/gas/aarch64/mops_invalid_2.l: New test.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for +mops
+ This patch adds support for FEAT_MOPS, an Armv8.8-A extension
+ that provides memcpy and memset acceleration instructions.
+
+ I took the perhaps controversial decision to generate the individual
+ instruction forms using macros rather than list them out individually.
+ This becomes useful with a follow-on patch to check that code follows
+ the correct P/M/E sequence.
+ [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en]
+
+ include/
+ * opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro.
+ (AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS.
+ (AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd.
+ (AARCH64_OPND_MOPS_ADDR_Rs): Likewise.
+ (AARCH64_OPND_MOPS_WB_Rn): Likewise.
+
+ opcodes/
+ * aarch64-asm.h (ins_x0_to_x30): New inserter.
+ * aarch64-asm.c (aarch64_ins_x0_to_x30): New function.
+ * aarch64-dis.h (ext_x0_to_x30): New extractor.
+ * aarch64-dis.c (aarch64_ext_x0_to_x30): New function.
+ * aarch64-tbl.h (aarch64_feature_mops): New feature set.
+ (aarch64_feature_mops_memtag): Likewise.
+ (MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN)
+ (MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN)
+ (MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN)
+ (MOPS_SET_INSN): New macros.
+ (aarch64_opcode_table): Add MOPS instructions.
+ (aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd,
+ AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
+ * aarch64-opc.c (aarch64_print_operand): Handle
+ AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and
+ AARCH64_OPND_MOPS_WB_Rn.
+ (verify_three_different_regs): New function.
+ * aarch64-asm-2.c: Regenerate.
+ * aarch64-dis-2.c: Likewise.
+ * aarch64-opc-2.c: Likewise.
+
+ gas/
+ * doc/c-aarch64.texi: Document +mops.
+ * config/tc-aarch64.c (parse_x0_to_x30): New function.
+ (parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd,
+ AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
+ (aarch64_features): Add "mops".
+ * testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test.
+ * testsuite/gas/aarch64/mops_invalid.s,
+ * testsuite/gas/aarch64/mops_invalid.d,
+ * testsuite/gas/aarch64/mops_invalid.l: Likewise.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add Armv8.8-A system registers
+ Armv8.8-A defines two new system registers: allint and icc_nmiar1_el1.
+ Both of them were previously unmapped. allint supports a 0/1 immediate.
+ [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ALLINT--All-Interrupt-Mask-Bit?lang=en]
+ [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ICC-NMIAR1-EL1--Interrupt-Controller-Non-maskable-Interrupt-Acknowledge-Register-1?lang=en]
+
+ opcodes/
+ * aarch64-opc.c (SR_V8_8): New macro.
+ (aarch64_sys_regs): Add allint and icc_nmiar1_el1.
+ (aarch64_pstatefields): Add allint.
+
+ gas/
+ * testsuite/gas/aarch64/armv8_8-a-sysregs.s,
+ * testsuite/gas/aarch64/armv8_8-a-sysregs.d: New test.
+ * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.s,
+ * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.l,
+ * testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.d: New test.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add id_aa64isar2_el1
+ Armv8.8-A defines a read-only system register called id_aa64isar2_el1.
+ The register was previously RES0 and should therefore be accepted
+ at all architecture levels.
+ [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en]
+
+ opcodes/
+ * aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1.
+
+ gas/
+ * testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to
+ id_aa64isar2_el1.
+ * testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly.
+ * testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise.
+ * testsuite/gas/aarch64/sysreg.s: Test reads from
+ id_aa64isar2_el1.
+ * testsuite/gas/aarch64/sysreg.d: Update accordingly.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add support for Armv8.8-A
+ This patch adds skeleton support for -march=armv8.8-a, testing only
+ that it correctly inherits from armv8.7-a.
+
+ include/
+ * opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro.
+ (AARCH64_ARCH_V8_8): Likewise.
+
+ gas/
+ * doc/c-aarch64.texi: Document armv8.8-a.
+ * config/tc-aarch64.c (aarch64_archs): Add armv8-8-a
+ * testsuite/gas/aarch64/v8-8-a.s,
+ * testsuite/gas/aarch64/v8-8-a.d: New test.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Provide line info for unclosed sequences
+ We warn about MOVPRFX instructions that have no following
+ instruction. This patch adds a line number to the message,
+ which is useful if the assembly code has multiple text sections.
+
+ The new code is unconditional since OBJ_ELF is always defined
+ for aarch64.
+
+ gas/
+ * config/tc-aarch64.h (aarch64_segment_info_type): Add last_file
+ and last_line.
+ * config/tc-aarch64.c (now_instr_sequence): Delete.
+ (force_automatic_sequence_close): Provide a line number when
+ reporting unclosed sequences.
+ (md_assemble): Record the location of the instruction in
+ tc_segment_info.
+ * testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error
+ message.
+ * testsuite/gas/aarch64/sve-movprfx_7.l: Likewise.
+ * testsuite/gas/aarch64/sve-movprfx_8.l: Likewise.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Tweak insn sequence code
+ libopcodes has some code to check constraints across sequences
+ of consecutive instructions. It was added to support MOVPRFX
+ sequences but is going to be useful for the Armv8.8-A MOPS
+ feature as well.
+
+ Currently the structure has one field to record the instruction
+ that started a sequence and another to record the remaining
+ instructions in the sequence. It's more convenient for the
+ MOPS code if we put the instructions into a single array instead.
+
+ No functional change intended.
+
+ include/
+ * opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns
+ and current_insns with num_added_insns and num_allocated_insns.
+
+ opcodes/
+ * aarch64-opc.c (add_insn_to_sequence): New function.
+ (init_insn_sequence): Update for new aarch64_instr_sequence layout.
+ Add the first instruction to the inst array.
+ (verify_constraints): Update for new aarch64_instr_sequence layout.
+ Don't add the last instruction to the array.
+
+2021-12-02 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add maximum immediate value to aarch64_sys_reg
+ The immediate form of MSR has a 4-bit immediate field (in CRm).
+ However, many forms of MSR require a smaller immediate. These cases
+ are identified by value in operand_general_constraint_met_p,
+ but they're now the common case rather than the exception.
+
+ This patch therefore adds the maximum value to the sys_reg
+ description and gets the range from there. It also enforces
+ the minimum of 0, which avoids a situation in which:
+
+ msr dit, #2
+
+ would give the expected:
+
+ Error: immediate value out of range 0 to 1
+
+ whereas:
+
+ msr dit, #-1
+
+ would give:
+
+ Error: immediate value out of range 0 to 15
+
+ (from the later UIMM4 checking).
+
+ Also:
+
+ - we were reporting the first error above against the wrong operand
+ - TCO takes a single-bit immediate, but we previously allowed
+ all 16 values.
+ [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en]
+
+ opcodes/
+ * aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros.
+ * aarch64-opc.c (operand_general_constraint_met_p): Read the
+ maximum MSR immediate value from aarch64_pstatefields.
+ (aarch64_pstatefields): Add the maximum immediate value
+ for each register.
+
+ gas/
+ * testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1
+ rather than 8 for the TCO test.
+ * testsuite/gas/aarch64/sysreg-4.d: Update accordingly.
+ * testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number
+ in MSR immediate error messages.
+ * testsuite/gas/aarch64/diagnostic.l: Likewise.
+ * testsuite/gas/aarch64/pan-illegal.l: Likewise.
+ * testsuite/gas/aarch64/ssbs-illegal1.l: Likewise.
+ * testsuite/gas/aarch64/illegal-sysreg-4b.s,
+ * testsuite/gas/aarch64/illegal-sysreg-4b.d,
+ * testsuite/gas/aarch64/illegal-sysreg-4b.l: New test.
+
+2021-12-02 Marcus Nilsson <brainbomb@gmail.com>
+
+ Allow the --visualize-jumps feature to work with the AVR disassembler.
+ * avr-dis.c (avr_operand); Pass in disassemble_info and fill
+ in insn_type on branching instructions.
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb, include: replace pragmas with DIAGNOSTIC macros, fix build with g++ 4.8
+ When introducing this code, I forgot that we had some macros for this.
+ Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros,
+ provided by include/diagnostics.h.
+
+ In diagnostics.h:
+
+ - Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level.
+ - Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for
+ both gcc and clang.
+
+ Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and
+ DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these
+ errors:
+
+ CXX ada-tasks.o
+ /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks():
+ /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch]
+ switch (data->known_tasks_kind)
+ ^
+
+ Because of the POP, the diagnostic should go back to being disabled,
+ since it was disabled in the beginning, but that's not what we see
+ here. Versions of GCC >= 5 compile correctly.
+
+ Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5.
+
+ Note that this code (already as it exists in master today) enables
+ -Wswitch at the error level even if --disable-werror is passed. It
+ shouldn't be a problem, as it's not like a new enumerator will appear
+ out of nowhere and cause a build error if building with future
+ compilers. Still, for correctness, we would ideally want to ask the
+ compiler to enable -Wswitch at its default level (as if the user had
+ passed -Wswitch on the command-line). There doesn't seem to be a way to
+ do this.
+
+ Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gas: re-generate configure
+ When configuring gas, I get:
+
+ config.status: error: cannot find input file: `doc/Makefile.in'
+
+ This is because configure is out-of-date, re-generate it.
+
+ Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ libctf: re-generate configure
+ When configuring libctf, I get:
+
+ config.status: error: cannot find input file: `doc/Makefile.in'
+
+ This is because configure is out-of-date, re-generate it.
+
+ Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169
+
+2021-12-02 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Skip __[start|stop]_SECNAME for --gc-sections -z start-stop-gc
+ Don't convert memory load to immediate load on __start_SECNAME and
+ __stop_SECNAME for --gc-sections -z start-stop-gc if all SECNAME
+ sections been garbage collected.
+
+ bfd/
+
+ PR ld/27491
+ * elf32-i386.c (elf_i386_convert_load_reloc): Skip __start_SECNAME
+ and __stop_SECNAME for --gc-sections -z start-stop-gc if the input
+ section been garbage collected.
+ * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise.
+ * elfxx-x86.h (elf_x86_start_stop_gc_p): New function.
+
+ ld/
+ PR ld/27491
+ * testsuite/ld-i386/i386.exp: Run PR ld/27491 tests.
+ * testsuite/ld-x86-64/x86-64.exp: Likewise.
+ * testsuite/ld-i386/pr27491-1.s: New file.
+ * testsuite/ld-i386/pr27491-1a.d: Likewise.
+ * testsuite/ld-i386/pr27491-1b.d: Likewise.
+ * testsuite/ld-i386/pr27491-1c.d: Likewise.
+ * testsuite/ld-i386/pr27491-2.d: Likewise.
+ * testsuite/ld-i386/pr27491-2.s: Likewise.
+ * testsuite/ld-i386/pr27491-3.d: Likewise.
+ * testsuite/ld-i386/pr27491-3.s: Likewise.
+ * testsuite/ld-i386/pr27491-4.d: Likewise.
+ * testsuite/ld-i386/pr27491-4a.s: Likewise.
+ * testsuite/ld-i386/pr27491-4b.s: Likewise.
+ * testsuite/ld-x86-64/pr27491-1.s: Likewise.
+ * testsuite/ld-x86-64/pr27491-1a.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-1b.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-1c.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-2.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-2.s: Likewise.
+ * testsuite/ld-x86-64/pr27491-3.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-3.s: Likewise.
+ * testsuite/ld-x86-64/pr27491-4.d: Likewise.
+ * testsuite/ld-x86-64/pr27491-4a.s: Likewise.
+ * testsuite/ld-x86-64/pr27491-4b.s: Likewise.
+
+2021-12-02 Mike Frysinger <vapier@gentoo.org>
+
+ bfd: delete unused proto settings
+ These have been around for decades but don't appear to be used, and
+ trying to build them (e.g. `make archive.p archive.ip`) doesn't work,
+ so just delete it all.
+
+ gas: merge doc subdir up a level
+ This avoids a recursive make into the doc subdir and speeds up the
+ build slightly. It also allows for more parallelism.
+
+ libctf: merge doc subdir up a level
+ This avoids a recursive make into the doc subdir and speeds up the
+ build slightly. It also allows for more parallelism.
+
+2021-12-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use actual DWARF version in compunit's debugformat field
+ The "info source" command, with a DWARF-compile program, always show
+ that the debug info is "DWARF 2":
+
+ (gdb) info source
+ Current source file is test.c
+ Compilation directory is /home/smarchi/build/binutils-gdb/gdb
+ Located in /home/smarchi/build/binutils-gdb/gdb/test.c
+ Contains 2 lines.
+ Source language is c.
+ Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
+ Compiled with DWARF 2 debugging format.
+ Includes preprocessor macro info.
+
+ Change it to display the actual DWARF version:
+
+ (gdb) info source
+ Current source file is test.c
+ Compilation directory is /home/smarchi/build/binutils-gdb/gdb
+ Located in /home/smarchi/build/binutils-gdb/gdb/test.c
+ Contains 2 lines.
+ Source language is c.
+ Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
+ Compiled with DWARF 5 debugging format.
+ Includes preprocessor macro info.
+
+ The comp_unit_head::version field is guaranteed to be between 2 and 5,
+ thanks to the check in read_comp_unit_head. So we can still use static
+ strings to pass to record_debugformat, and keep it efficient.
+
+ In the future, when somebody will update GDB to support DWARF 6, they'll
+ hit this assert and have to update this code.
+
+ Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172
+
+2021-12-02 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Discard input .note.gnu.build-id sections
+ 1. Discard input .note.gnu.build-id sections.
+ 2. Clear the build ID field before writing.
+ 3. Use bfd_make_section_anyway_with_flags to create the output
+ .note.gnu.build-id section.
+
+ PR ld/28639
+ * ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
+ sections, excluding the first one.
+ (write_build_id): Clear the build ID field before writing.
+ (ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
+ to create the output .note.gnu.build-id section.
+ * testsuite/ld-elf/build-id.exp: New file.
+ * testsuite/ld-elf/pr28639a.rd: Likewise.
+ * testsuite/ld-elf/pr28639b.rd: Likewise.
+ * testsuite/ld-elf/pr28639c.rd: Likewise.
+ * testsuite/ld-elf/pr28639d.rd: Likewise.
+
+2021-12-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-12-01 Mike Frysinger <vapier@gentoo.org>
+
+ binutils: add missing prefix for binutils/index.html rule
+
+2021-12-01 Luca Boccassi <luca.boccassi@gmail.com>
+
+ readelf: recognize FDO Packaging Metadata ELF note. (Correcting snafu during patch application)
+
+2021-12-01 Luca Boccassi <luca.boccassi@gmail.com>
+
+ readelf: recognize FDO Packaging Metadata ELF note
+ As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/
+ this note will be used starting from Fedora 36. Allow
+ readelf --notes to pretty print it:
+
+ Displaying notes found in: .note.package
+ Owner Data size Description
+ FDO 0x00000039 FDO_PACKAGING_METADATA
+ Packaging Metadata: {"type":"deb","name":"fsverity-utils","version":"1.3-1"}
+
+2021-12-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix typo in gdb.multi/multi-arch-exec.exp
+ With gdb.multi/multi-arch-exec.exp I run into:
+ ...
+ Running src/gdb/testsuite/gdb.multi/multi-arch-exec.exp ...
+ ERROR: tcl error sourcing src/gdb/testsuite/gdb.multi/multi-arch-exec.exp.
+ ERROR: wrong # args: extra words after "else" clause in "if" command
+ while executing
+ "if [istarget "powerpc64*-*-*"] {
+ set march "-m64"
+ } else if [istarget "s390*-*-*"] {
+ set march "-m31"
+ } else {
+ set march "-m32"
+ }"
+ ...
+
+ Fix the else if -> elseif typo.
+
+ Tested on x86_64-linux.
+
+2021-12-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.arch/i386-pkru.exp on linux
+ When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory
+ Protection Keys for Userspace" support, we run into:
+ ...
+ (gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
+ print $pkru^M
+ $2 = 1431655764^M
+ (gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register
+ ...
+
+ The test-case expects the $pkru register to have the default value 0, matching
+ the "init state" of 0 defined by the XSAVE hardware.
+
+ Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys:
+ Default to a restrictive init PKRU"), the register is set to 0x55555554 by
+ default (which matches the printed decimal value above).
+
+ Fix the FAIL by accepting this value for linux.
+
+ Tested on x86_64-linux.
+
+2021-12-01 Nick Clifton <nickc@redhat.com>
+
+ Fix the fields in the x_n union inside the the x_file structure so that pointers can be stored.
+ PR 28630
+ * coff/internal.h (x_n): Use bfd_hostptr_t for the fields in this
+ structure.
+
+2021-12-01 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/remote: use scoped_restore to control starting_up flag
+ This commit makes use of a scoped_restore object to control the
+ remote_state::starting_up flag within the remote_target::start_remote
+ method.
+
+ Ideally I would have liked to create the scoped_restore inside
+ start_remote and just leave the restore in place until the end of the
+ scope, however, I'm worried that doing this would change the behaviour
+ of GDB. Specifically, in start_remote, the following code is executed
+ once the starting_up flag has been restored to its previous value:
+
+ if (breakpoints_should_be_inserted_now ())
+ insert_breakpoints ();
+
+ I think (but am not 100% sure) that calling install_breakpoints could
+ end up back inside remote_target::can_download_tracepoint, which does
+ check the value of remote_state::starting_up. And so, I'm concerned
+ that leaving the scoped_restore in place until the end of start_remote
+ will cause a possible change in behaviour.
+
+ To avoid this, and to leave things as close to the current behaviour
+ as possible, I've split remote_target::start_remote into two, there's
+ the main function body which moves into remote_target::start_remote_1,
+ this function uses the scoped_restore to change the ::starting_up
+ flag, then there's the old remote_target::start_remote, which now just
+ calls ::start_remote_1, and then does the insert_breakpoints call.
+
+ There should be no user visible changes after this commit, unless
+ there's a situation where the ::starting_up flag could previously have
+ been left set, if this was the case, then this situation should no
+ longer be possible.
+
+2021-12-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb.base/corefile-buildid.exp: fix DUPLICATEs when failing to generate a core file
+ When my system isn't properly configured to generate core files in the
+ local directory, I see these DUPLICATEs:
+
+ DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file
+
+ Fix that by having a single with_test_prefix around that message and
+ what follows.
+
+ Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba
+
+2021-12-01 Mike Frysinger <vapier@gentoo.org>
+
+ gold: enable silent build rules
+
+2021-12-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-30 Carl Love <cel@us.ibm.com>
+
+ gdb: Powerpc fix gdb.multi/multi-arch-exec.exp test
+ The expect file has a procedure append_arch_options which sets march based
+ the istarget. The current if / else statement does not check for
+ powerpc64. The else statement is hit which sets march to -m32. This
+ results in compilation errors on 64-bit PowerPC.
+
+ This patch adds an if statement to check for powerpc64 and if true sets mach
+ to -m64.
+
+ The patch was tested on a Power 10 system. No compile errors were generated.
+ The test completes with 1 expected pass and no failures.
+
+2021-11-30 Mike Frysinger <vapier@gentoo.org>
+
+ binutils: regenerate Makefile.in after doc/ changes
+
+2021-11-30 Roland McGrath <mcgrathr@google.com>
+
+ Fix missing build dependency for binutils man pages
+ binutils/
+ * doc/local.mk: Give each man page target its missing dependency on
+ doc/$(am__dirstamp).
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Add missing system registers [PR27145]
+ This patch adds support for various system registers, up to Armv8.7-A.
+ This includes all the registers that were mentioned in the PR and that
+ hadn't become supported since.
+
+ opcodes/
+ PR aarch64/27145
+ * aarch64-opc.c (SR_V8_4): Remove duplicate definition.
+ (SR_V8_6, SR_V8_7, SR_GIC, SR_AMU): New macros.
+ (aarch64_sys_regs): Add missing entries (up to Armv8.7-A).
+
+ gas/
+ PR aarch64/27145
+ * testsuite/gas/aarch64/sysreg-8.s,
+ * testsuite/gas/aarch64/sysreg-8.d,
+ * testsuite/gas/aarch64/illegal-sysreg-8.s,
+ * testsuite/gas/aarch64/illegal-sysreg-8.d,
+ * testsuite/gas/aarch64/illegal-sysreg-8.l,
+ * testsuite/gas/aarch64/illegal-sysreg-8b.s,
+ * testsuite/gas/aarch64/illegal-sysreg-8b.d,
+ * testsuite/gas/aarch64/illegal-sysreg-8b.l: New tests.
+ * testsuite/gas/aarch64/sysreg.s: Change system register numbers
+ to ones that are still unallocated.
+ * testsuite/gas/aarch64/sysreg.d: Update accordingly.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Make LOR registers conditional on +lor
+ We have a +lor feature flag for the Limited Ordering Regions
+ extension, but the associated registers didn't use it.
+
+ opcodes/
+ * aarch64-opc.c (SR_LOR): New macro.
+ (aarch64_sys_regs): Use it for lorc_el1, lorea_el1, lorn_el1 and
+ lorsa_el1.
+
+ gas/
+ * testsuite/gas/aarch64/sysreg-7.s: Enable +lor.
+ * testsuite/gas/aarch64/illegal-sysreg-7.s: Test for LOR registers
+ without +lor.
+ * testsuite/gas/aarch64/illegal-sysreg-7.d: Update accordingly.
+ * testsuite/gas/aarch64/illegal-sysreg-7.l: Likewise.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Remove ZIDR_EL1
+ ZIDR_EL1 was part of an early version of SVE, but didn't make
+ it to the final release.
+
+ opcodes/
+ * aarch64-opc.c (aarch64_sys_regs): Remove zidr_el1 entry.
+
+ gas/
+ * testsuite/gas/aarch64/sve-sysreg.s: Remove zidr_el1.
+ * testsuite/gas/aarch64/sve-sysreg.d: Update accordingly.
+ * testsuite/gas/aarch64/sve-sysreg-invalid.l: Likewise.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Allow writes to MFAR_EL3
+ MFAR_EL3 is a read/write register, but was incorrectly marked as
+ read-only
+ [https://developer.arm.com/documentation/ddi0601/2021-09/AArch64-Registers/MFAR-EL3--PA-Fault-Address-Register?lang=en]
+
+ opcodes/
+ * aarch64-opc.c (aarch64_sys_regs): Mark mfar_el3 as read-write.
+
+ gas/
+ * testsuite/gas/aarch64/rme.s: Test writing to mfar_el3.
+ * testsuite/gas/aarch64/rme.d: Update accordingly.
+ * testsuite/gas/aarch64/rme-invalid.s: Delete.
+ * testsuite/gas/aarch64/rme-invalid.l: Likewise.
+ * testsuite/gas/aarch64/rme-invalid.d: Likewise.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Mark PMSIDR_EL1 as read-only
+ We were incorrectly allowing writes to PMSIDR_EL1, which is
+ a read-only register.
+ [https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/PMSIDR-EL1--Sampling-Profiling-ID-Register?lang=en]
+
+ opcodes/
+ * aarch64-opc.c (aarch64_sys_regs): Make pmsidr_el1 as F_REG_READ.
+
+ gas/
+ * testsuite/gas/aarch64/msr.s: Remove write to pmsidr_el1.
+ * testsuite/gas/aarch64/msr.d: Update accordingly.
+ * testsuite/gas/aarch64/illegal-sysreg-2.s,
+ * testsuite/gas/aarch64/illegal-sysreg-2.d,
+ * testsuite/gas/aarch64/illegal-sysreg-2.l: New test.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Remove duplicate system register entries
+ There is a lot of overlap between the ETM and ETE system registers,
+ so some registers were listed twice.
+
+ Already tested by etm.[sd] and ete.[sd].
+
+ opcodes/
+ * aarch64-opc.c (aarch64_sys_regs): Combine ETE and ETM blocks
+ and remove redundant entries.
+
+ gas/
+ * testsuite/gas/aarch64/etm.s: Remove duplicated test.
+ * testsuite/gas/aarch64/etm.d: Update accordingly.
+
+2021-11-30 Richard Sandiford <richard.sandiford@arm.com>
+
+ aarch64: Check for register aliases before mnemonics
+ Previously we would not accept:
+
+ A .req B
+
+ if A happened to be the name of an instruction. Adding new
+ instructions could therefore invalidate existing register aliases.
+
+ I noticed this with a test that used "zero" as a register alias
+ for "xzr", where "zero" is now also the name of an SME instruction.
+ I don't have any evidence that "real" code is doing this, but it
+ seems at least plausible.
+
+ This patch switches things so that we check for register aliases
+ first. It might slow down parsing slightly, but the difference
+ is unlikely to be noticeable.
+
+ Things like:
+
+ b .req + 0
+
+ still work, since create_register_alias checks for " .req ",
+ and with the input scrubber, we'll only keep whitespace after
+ .req if it's followed by another name. If there's some valid
+ expression that I haven't thought about that is scrubbed to
+ " .req ", users could avoid the ambiguity by wrapping .req
+ in parentheses.
+
+ The new test for invalid aliases already passed. I just wanted
+ something to exercise the !dot condition.
+
+ I can't find a way of exercising the (existing) p == base condition,
+ but I'm not brave enough to say that it can never happen. If it does
+ happen, get_mnemonic_name would return an empty string.
+
+ gas/
+ * config/tc-aarch64.c (opcode_lookup): Move mnemonic extraction
+ code to...
+ (md_assemble): ...here. Check for register aliases first.
+ * testsuite/gas/aarch64/register_aliases.d,
+ testsuite/gas/aarch64/register_aliases.s: Test for a register
+ alias called "zero".
+ * testsuite/gas/aarch64/register_aliases_invalid.d,
+ testsuite/gas/aarch64/register_aliases_invalid.l,
+ testsuite/gas/aarch64/register_aliases_invalid.s: New test.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: don't use the 'p' format for parsing args
+ When running the gdb.python/py-arch.exp tests on a GDB built
+ against Python 2 I ran into some errors. The problem is that this
+ test script exercises the gdb.Architecture.integer_type method, and
+ this method uses 'p' as an argument format specifier in a call to
+ gdb_PyArg_ParseTupleAndKeywords.
+
+ Unfortunately this specified was only added in Python 3.3, so will
+ cause an error for earlier versions of Python.
+
+ This commit switches to use the 'O' specifier to collect a PyObject,
+ and then uses PyObject_IsTrue to convert the object to a boolean.
+
+ An earlier version of this patch incorrectly switched from using 'p'
+ to use 'i', however, it was pointed out during review that this would
+ cause some changes in behaviour, for example both of these will work
+ with 'p', but not with 'i':
+
+ gdb.selected_inferior().architecture().integer_type(32, None)
+ gdb.selected_inferior().architecture().integer_type(32, "foo")
+
+ The new approach of using 'O' works fine with these cases. I've added
+ some new tests to cover both of the above.
+
+ There should be no user visible changes after this commit.
+
+2021-11-30 Tom de Vries <tdevries@sdflex.arch.suse.de>
+
+ [gdb/testsuite] Fix gdb.base/style.exp with stub-termcap
+ When running test-case gdb.base/style.exp with a gdb build using
+ stub-termcap.c, we run into:
+ ...
+ (gdb) PASS: gdb.base/style.exp: all styles enabled: frame when width=20
+ ^M<et width 30^M
+ (gdb) FAIL: gdb.base/style.exp: all styles enabled: set width 30
+ ...
+
+ The problem is that we're trying to issue the command "set width 30" while
+ width is set to 20, which causes horizontal scrolling.
+
+ Fix this by resetting the width to 0 before issuing the "set width 30"
+ command.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24582
+
+2021-11-30 Nick Clifton <nickc@redhat.com>
+
+ Use dwarf_vma type for offsets, ranges and section sizes in DWARF decoder.
+ * dwarf.c (find_debug_info_for_offset): Use dwarf_vma type for
+ offsets, sizes and ranges.
+ (display_loc_list): Likewise. Also use print_dwarf_vma to print
+ the offset.
+ (display_loclists_list): Likewise.
+ (display_loc_list_dwo): Likewise.
+ (display_debug_str): Likewise.
+ (display_debug_aranges): Likewise.
+ (display_debug_ranges_list): Likewise.
+ (display_debug_rnglists_list): Likewise.
+ (display_debug_ranges): Likewise.
+
+ ld: pru: Add pru_irq_map output section
+ * scripttempl/pru.sc (.pru_irq_map): Define output section.
+ * testsuite/ld-pru/pru_irq_map-1.d: New test.
+ * testsuite/ld-pru/pru_irq_map-2.d: New test.
+ * testsuite/ld-pru/pru_irq_map.s: New test.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: check the python module is available before using it
+ The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc
+ module. When running the Python tests with a GDB built against Python
+ 2 I ran into a test failure due to the tracemalloc module not being
+ available.
+
+ This commit adds a new helper function to lib/gdb-python.exp that
+ checks if a named module is available. Using this we can then skip
+ the py-inferior-leak.exp test when the tracemalloc module is not
+ available.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix disassembler regressions for 32-bit arm
+ After this commit:
+
+ commit 76b43c9b5c2b275cbf4f927bfc25984410cb5dd5
+ Date: Tue Oct 5 15:10:12 2021 +0100
+
+ gdb: improve error reporting from the disassembler
+
+ We started seeing FAILs in the gdb.base/all-architectures*.exp tests,
+ when running on a 32-bit ARM target, though I suspect running on any
+ target that compiles such that bfd_vma is 32-bits would also trigger
+ the failures.
+
+ The problem is that the test is expected GDB's disassembler to print
+ an error like this:
+
+ Cannot access memory at address 0x0
+
+ However, after the above commit we see an error like:
+
+ unknown disassembler error (error = -1)
+
+ The reason for this is this code in opcodes/i386-dis.c (in the
+ print_insn function):
+
+ if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
+ {
+ (*info->fprintf_func) (info->stream,
+ _("64-bit address is disabled"));
+ return -1;
+ }
+
+ This code effectively disallows us from ever disassembling 64-bit x86
+ code if we compiled GDB with a 32-bit bfd_vma. Notice we return
+ -1 (indicating a failure to disassemble), but never call the
+ memory_error_func callback.
+
+ Prior to the above commit GDB, when it received the -1 return value
+ would assume that a memory error had occurred and just print whatever
+ value happened to be in the memory error address variable, the default
+ value of 0 just happened to be fine because the test had asked GDB to
+ do this 'disassemble 0x0,+4'.
+
+ If we instead change the test to do 'disassemble 0x100,+4' then GDB
+ would (previously) have still reported:
+
+ Cannot access memory at address 0x0
+
+ which makes far less sense.
+
+ In this commit I propose to fix this issue by changing the test to
+ accept either the "Cannot access memory ..." string, or the newer
+ "unknown disassembler error ..." string. With this change done the
+ test now passes.
+
+ However, there is one weakness with this strategy; if GDB broke such
+ that we _always_ reported "unknown disassembler error ..." we would
+ never notice. This clearly would be bad. To avoid this issue I have
+ adjusted the all-architectures*.exp tests so that, when we disassemble
+ for the default architecture (the one selected by "auto") we _only_
+ expect to get the "Cannot access memory ..." error string.
+
+ [ Note: In an ideal world we should be able to disassemble any
+ architecture at all times. There's no reason why the 64-bit x86
+ disassembler requires a 64-bit bfd_vma, other than the code happens
+ to be written that way. We could rewrite the disassemble to not
+ have this requirement, but, I don't plan to do that any time soon. ]
+
+ Further, I have changed the all-architectures*.exp test so that we now
+ disassemble at address 0x100, this should avoid us being able to pass
+ by printing a default address of 0x0. I did originally change the
+ address we disassembled at to 0x4, however, some architectures,
+ e.g. ia64, have a default instruction alignment that is greater than
+ 4, so would still round down to 0x0. I could have just picked 0x8 as
+ an address, but I figured that 0x100 was likely to satisfy most
+ architectures alignment requirements.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: add gdb.RemoteTargetConnection.send_packet
+ This commits adds a new sub-class of gdb.TargetConnection,
+ gdb.RemoteTargetConnection. This sub-class is created for all
+ 'remote' and 'extended-remote' targets.
+
+ This new sub-class has one additional method over its base class,
+ 'send_packet'. This new method is equivalent to the 'maint
+ packet' CLI command, it allows a custom packet to be sent to a remote
+ target.
+
+ The outgoing packet can either be a bytes object, or a Unicode string,
+ so long as the Unicode string contains only ASCII characters.
+
+ The result of calling RemoteTargetConnection.send_packet is a bytes
+ object containing the reply that came from the remote.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: make packet_command function available outside remote.c
+ In a later commit I will add a Python API to access the 'maint packet'
+ functionality, that is, sending a user specified packet to the target.
+
+ To make implementing this easier, this commit refactors how this
+ command is currently implemented so that the packet_command function
+ is now global.
+
+ The new global send_remote_packet function takes an object that is an
+ implementation of an abstract interface. Two functions within this
+ interface are then called, one just before a packet is sent to the
+ remote target, and one when the reply has been received from the
+ remote target. Using an interface object in this way allows (1) for
+ the error checking to be done before the first callback is made, this
+ means we only print out what packet it being sent once we know we are
+ going to actually send it, and (2) we don't need to make a copy of the
+ reply if all we want to do is print it.
+
+ One user visible changes after this commit are the error
+ messages, which I've changed to be less 'maint packet' command
+ focused, this will make them (I hope) better for when
+ send_remote_packet can be called from Python code.
+
+ So: "command can only be used with remote target"
+ Becomes: "packets can only be sent to a remote target"
+
+ And: "remote-packet command requires packet text as argument"
+ Becomes: "a remote packet must not be empty"
+
+ Additionally, in this commit, I've added support for packet replies
+ that contain binary data. Before this commit, the code that printed
+ the reply treated the reply as a C string, it assumed that the string
+ only contained printable characters, and had a null character only at
+ the end.
+
+ One way to show the problem with this is if we try to read the auxv
+ data from a remote target, the auxv data is binary, so, before this
+ commit:
+
+ (gdb) target remote :54321
+ ...
+ (gdb) maint packet qXfer:auxv:read::0,1000
+ sending: "qXfer:auxv:read::0,1000"
+ received: "l!"
+ (gdb)
+
+ And after this commit:
+
+ (gdb) target remote :54321
+ ...
+ (gdb) maint packet qXfer:auxv:read::0,1000
+ sending: "qXfer:auxv:read::0,1000"
+ received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
+ (gdb)
+
+ The binary contents of the reply are now printed as escaped hex.
+
+2021-11-30 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/python: introduce gdb.TargetConnection object type
+ This commit adds a new object type gdb.TargetConnection. This new
+ type represents a connection within GDB (a connection as displayed by
+ 'info connections').
+
+ There's three ways to find a gdb.TargetConnection, there's a new
+ 'gdb.connections()' function, which returns a list of all currently
+ active connections.
+
+ Or you can read the new 'connection' property on the gdb.Inferior
+ object type, this contains the connection for that inferior (or None
+ if the inferior has no connection, for example, it is exited).
+
+ Finally, there's a new gdb.events.connection_removed event registry,
+ this emits a new gdb.ConnectionEvent whenever a connection is removed
+ from GDB (this can happen when all inferiors using a connection exit,
+ though this is not always the case, depending on the connection type).
+ The gdb.ConnectionEvent has a 'connection' property, which is the
+ gdb.TargetConnection being removed from GDB.
+
+ The gdb.TargetConnection has an 'is_valid()' method. A connection
+ object becomes invalid when the underlying connection is removed from
+ GDB (as discussed above, this might be when all inferiors using a
+ connection exit, or it might be when the user explicitly replaces a
+ connection in GDB by issuing another 'target' command).
+
+ The gdb.TargetConnection has the following read-only properties:
+
+ 'num': The number for this connection,
+
+ 'type': e.g. 'native', 'remote', 'sim', etc
+
+ 'description': The longer description as seen in the 'info
+ connections' command output.
+
+ 'details': A string or None. Extra details for the connection, for
+ example, a remote connection's details might be
+ 'hostname:port'.
+
+2021-11-30 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: The vtype immediate with more than the defined 8 bits are preserved.
+ According the rvv spec,
+ https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc
+
+ The bits of vtype immediate from 8 to (xlen - 1) should be reserved.
+ Therefore, we should also dump the vtype immediate as numbers, when
+ they are set over 8-bits. I think this is a bug that we used to support
+ vediv extension and use the bit 8 and 9 of vtype, but forgot to update
+ the behavior when removing the vediv.
+
+ Consider the testcases,
+
+ vsetvli a0, a1, 0x700 # the reserved bit 10, 9 and 8 are used.
+ vsetvli a0, a1, 0x400 # the reserved bit 10 is used.
+ vsetvli a0, a1, 0x300 # the reserved bit 9 and 8 are used.
+ vsetvli a0, a1, 0x100 # the reserved bit 8 is used.
+ vsetivli a0, 0xb, 0x300 # the reserved bit 9 and 8 are used.
+ vsetivli a0, 0xb, 0x100 # the reserved bit 8 is used.
+
+ The original objdump shows the following result,
+
+ 0000000000000000 <.text>:
+ 0: 7005f557 vsetvli a0,a1,1792
+ 4: 4005f557 vsetvli a0,a1,1024
+ 8: 3005f557 vsetvli a0,a1,e8,m1,tu,mu
+ c: 1005f557 vsetvli a0,a1,e8,m1,tu,mu
+ 10: f005f557 vsetivli a0,11,e8,m1,tu,mu
+ 14: d005f557 vsetivli a0,11,e8,m1,tu,mu
+
+ But in fact the correct result should be,
+
+ 0000000000000000 <.text>:
+ 0: 7005f557 vsetvli a0,a1,1792
+ 4: 4005f557 vsetvli a0,a1,1024
+ 8: 3005f557 vsetvli a0,a1,768
+ c: 1005f557 vsetvli a0,a1,256
+ 10: f005f557 vsetivli a0,11,768
+ 14: d005f557 vsetivli a0,11,256
+
+ gas/
+ * testsuite/gas/riscv/vector-insns.d: Added testcases to
+ test the reserved bit 8 to (xlen-1) of vtype.
+ * testsuite/gas/riscv/vector-insns.s: Likewise.
+ include/
+ * opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES,
+ since they are different for operand Vc and Vb.
+ opcodes/
+ * riscv-dis.c (print_insn_args): Updated imm_vtype_res to
+ extract the reserved immediate of vtype correctly.
+
+2021-11-30 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Dump vset[i]vli immediate as numbers once vsew or vlmul is reserved.
+ Consider the following case,
+
+ vsetvli a0, a1, 0x4 # unrecognized vlmul
+ vsetvli a0, a1, 0x20 # unrecognized vsew
+ vsetivli a0, 0xb, 0x4 # unrecognized vlmul
+ vsetivli a0, 0xb, 0x20 # unrecognized vsew
+
+ For the current dis-assembler, we get the result,
+
+ 0000000000000000 <.text>:
+ 0: 0045f557 vsetvli a0,a1,e8,(null),tu,mu
+ 4: 0205f557 vsetvli a0,a1,e128,m1,tu,mu
+ 8: c045f557 vsetivli a0,11,e8,(null),tu,mu
+ c: c205f557 vsetivli a0,11,e128,m1,tu,mu
+
+ The vsew e128 and vlmul (null) are preserved according to the spec,
+ so dump these fields looks wrong. Consider that we are used to dump
+ the unrecognized csr as csr numbers directly, we should also dump
+ the whole vset[i]vli immediates as numbers, once the vsew or vlmul
+ is reserved. Therefore, following is what I expected,
+
+ 0000000000000000 <.text>:
+ 0: 0045f557 vsetvli a0,a1,4
+ 4: 0205f557 vsetvli a0,a1,32
+ 8: c045f557 vsetivli a0,11,4
+ c: c205f557 vsetivli a0,11,32
+
+ gas/
+ * testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli
+ testcases since we should dump the immediate as numbers once
+ the vsew or vlmul is reserved.
+ * testsuite/gas/riscv/vector-insns.s: Likewise.
+ opcodes/
+ * riscv-dis.c (print_insn_args): The reserved vsew and vlmul
+ are NULL string in the riscv_vsew and riscv_vlmul, so dump the
+ whole imm as numbers once one of them is NULL.
+ * riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL.
+ (riscv_vlmul): Set the reserved vlmul to NULL.
+
+2021-11-30 Mike Frysinger <vapier@gentoo.org>
+
+ zlib: enable silent build rules
+
+ ld: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+ libctf: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+ gprof: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+ binutils: merge doc subdir up a level
+ This avoids a recursive make into the doc subdir and speeds up the
+ build slightly. It also allows for more parallelism.
+
+ binutils: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+ bfd: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+ opcodes: enable silent build rules
+ Also add $(AM_V_xxx) to various manual rules in here.
+
+2021-11-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-29 Tom Tromey <tom@tromey.com>
+
+ Allow DW_ATE_UTF for Rust characters
+ The Rust compiler plans to change the encoding of a Rust 'char' type
+ to use DW_ATE_UTF. You can see the discussion here:
+
+ https://github.com/rust-lang/rust/pull/89887
+
+ However, this fails in gdb. I looked into this, and it turns out that
+ the handling of DW_ATE_UTF is currently fairly specific to C++. In
+ particular, the code here assumes the C++ type names, and it creates
+ an integer type.
+
+ This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
+ are signed in C++"). The message says:
+
+ Both places need fixing. But since I couldn't tell why dwarf2read.c
+ needs to create a new type, I've made it use the per-arch built-in
+ types instead, so that the types are only created once per arch
+ instead of once per objfile. That seems to work fine.
+
+ ... which is fine, but it seems to me that it's also correct to make a
+ new character type; and this approach is better because it preserves
+ the type name as well. This does use more memory, but first we
+ shouldn't be too concerned about the memory use of types coming from
+ debuginfo; and second, if we are, we should implement type interning
+ anyway.
+
+ Changing this code to use a character type revealed a couple of
+ oddities in the C/C++ handling of TYPE_CODE_CHAR. This patch fixes
+ these as well.
+
+ I filed PR rust/28637 for this issue, so that this patch can be
+ backported to the gdb 11 branch.
+
+2021-11-29 Aaron Merey <amerey@redhat.com>
+ Tom de Vries <tdevries@suse.de>
+
+ [PR gdb/27026] CTRL-C is ignored when debug info is downloaded
+ During debuginfod downloads, ctrl-c should result in the download
+ being cancelled and skipped. However in some cases, ctrl-c fails to
+ get delivered to gdb during downloading. This can result in downloads
+ being unskippable.
+
+ Fix this by ensuring that target_terminal::ours is in effect for the
+ duration of each download.
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3
+
+2021-11-29 Nick Clifton <nickc@redhat.com>
+
+ strings: Replace references to -u option with references to -U.
+ PR 28632
+
+2021-11-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix segfault in search_one_symtab
+ PR28539 describes a segfault in lambda function search_one_symtab due to
+ psymbol_functions::expand_symtabs_matching calling expansion_notify with a
+ nullptr symtab:
+ ...
+ struct compunit_symtab *symtab =
+ psymtab_to_symtab (objfile, ps);
+
+ if (expansion_notify != NULL)
+ if (!expansion_notify (symtab))
+ return false;
+ ...
+
+ This happens as follows. The partial symtab ps is a dwarf2_include_psymtab
+ for some header file:
+ ...
+ (gdb) p ps.filename
+ $5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h"
+ ...
+
+ The includer of ps is a shared symtab for a partial unit, with as user:
+ ...
+ (gdb) p ps.includer().user.filename
+ $11 = 0x64fc9f0 \
+ "/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp"
+ ...
+
+ The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently
+ the shared symtab), but returns nullptr because:
+ ...
+ struct dwarf2_include_psymtab : public partial_symtab
+ {
+ ...
+ compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override
+ {
+ return nullptr;
+ }
+ ...
+
+ Fix this by returning the Decl.cpp symtab instead, which fixes the segfault
+ in the PR.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28539
+
+2021-11-29 Nick Clifton <nickc@redhat.com>
+
+ Update description of string's -n option.
+ PR 28632
+ * strings.c (usage): Update desciption of -n option.
+ * doc/binutils.texi: Likewise.
+
+2021-11-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix typo in proc lines
+ Proc lines contains a typo:
+ ...
+ string_form { set $_line_string_form $value }
+ ...
+
+ Remove the incorrect '$' in '$_line_string_form'.
+
+ Tested on x86_64-linux.
+
+2021-11-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use unique files in gdb.dwarf2/dw2-lines.exp
+ While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
+ test-case generates all executables and associated temporary files using the
+ same filenames.
+
+ Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
+ test-case.
+
+ Tested on x86_64-linux.
+
+2021-11-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp with -m32
+ When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
+ we run into another instance of PR28383, where the dwarf assembler generates
+ 64-bit relocations which are not supported by the 32-bit assembler:
+ ...
+ dw2-lines-dw.S: Assembler messages:^M
+ outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
+ cannot represent relocation type BFD_RELOC_64^M
+ ...
+
+ Fix this by using _op_offset in _line_finalize_header.
+
+ Tested on x86_64-linux.
+
+2021-11-29 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: drop most specific istarget checks
+ We'll rely on the toolchain probing to determine whether each arch's
+ tests can be run rather the current configure target. This allows
+ testing all of the ports in a multitarget configuration.
+
+ For now, we don't reformat the files entirely to make it easier to
+ review, and in case we need to make adjustments. Once this feels
+ like it's stable, we can flatten the code a bit by removing the if
+ statement entirely.
+
+2021-11-29 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: support parallel execution
+ Break up the dejagnu logic so that we can parallelize the testsuite.
+ This takes a page from gcc & gdb where each .exp is run in isolation
+ instead of in serial.
+
+ For most targets, this doesn't make much of a difference as they only
+ have a single .exp. A few (like cris & frv) have multiple .exp though
+ and will see a bit of a speed up.
+
+ The real gain is when testing a multitarget build. This way we can
+ run all the targets in parallel and cut the execution time a bit.
+ On my system, it goes from ~155sec to ~100sec.
+
+ We can gain further speedups by splitting up some of the larger .exp
+ files into smaller groups. We'll do that in a followup though.
+
+2021-11-29 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: expand arch specific toolchain settings
+ Leverage the new per-port toolchain settings to initialize the env
+ for eeach set of tests. This allows us to run all the tests in a
+ multitarget build if the user sets up the vars. If they don't, we
+ can still skip all the tests.
+
+2021-11-29 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: setup per-port toolchain settings for multitarget build
+ Gas does not support multitarget builds -- it still only supports
+ a single input & output format. ld is a bit better, but requires
+ manual flags to select the right output. This makes it impossible
+ to run the complete testsuite in a multitarget build.
+
+ To address this limitation, create a suite of FOR_TARGET variables
+ so these can be set to precompiled as & ld programs. It requires
+ a bit of setup ahead of time, but it's a one-time cost, and makes
+ running the full testsuite at once much easier.
+
+2021-11-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-28 Alan Modra <amodra@gmail.com>
+
+ PR28629 NIOS2 fallout
+ The test exactly matched wrong output.
+
+ PR 28629
+ * testsuite/gas/nios2/relax.d: Update expected output.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: add checks to core headers to prevent incorrect common building
+ Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
+ which can change the size of core types. Since these haven't been
+ unified across ports, add checks to make sure they aren't accidentally
+ included when building for all ports. This caught the sim-load file
+ using poisoned headers that it didn't actually need.
+
+ sim: unify syscall.o building
+ Now that we've unified all the syscall tables, this file does not rely
+ on any port-specific settings, so move it up to building as part of the
+ common step so we only do it once in a multibuild.
+
+ sim: drop unused gentmap & nltvals.def logic
+ Now that all ports have switched to target-newlib-* files, there's
+ no need for these files & generating things at build time. So punt
+ the logic and make target-newlib-syscall a hard requirement.
+
+ sim: mcore: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and mcore has a custom syscall
+ table for its newlib/libgloss port.
+
+ sim: riscv: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and riscv has a custom syscall
+ table for its newlib/libgloss port.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cr16: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and cr16 has a custom syscall
+ table for its newlib/libgloss port.
+
+ This allows cleaning up the syscall ifdef logic. We know these will
+ always exist now.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: d10v: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and d10v has a custom syscall
+ table for its newlib/libgloss port.
+
+ This allows cleaning up the syscall ifdef logic. We know these will
+ always exist now.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and sh has a custom syscall
+ table for its newlib/libgloss port.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: switch to new target-newlib-syscall
+ Use the new target-newlib-syscall module. This is needed to merge all
+ the architectures into a single build, and v850 has a custom syscall
+ table for its newlib/libgloss port.
+
+ This allows cleaning up the syscall ifdef logic. We know these will
+ always exist now.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: iq2000/lm32/m32c/moxie/rx: switch to new target-newlib-syscall.h
+ Use the new target-newlib-syscall.h to provide the target syscall
+ defines. These code paths are written specifically for the newlib
+ ABI rather than being generalized, so switching them to the defines
+ rather than trying to go through the dynamic callback conversion
+ seems like the best trade-off for now. Might have to reconsider
+ this in the future.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: nltvals: pull target syscalls out into a dedicated source file
+ Like we just did for pulling out the errno map, pull out the syscall
+ maps into a dedicated common file. Most newlib ports are using the
+ same syscall map, but not all, which means we have to do a bit more
+ work to migrate.
+
+ This commit adds the maps and switches the ports using the common
+ default syscall table over to it. Ports using unique syscall tables
+ are still using the old targ-map.c logic.
+
+ Switching common ports over is easy by checking NL_TARGET, but the
+ ppc code needs a bit more cleanup here hence its larger diff.
+
+2021-11-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: frv: resolve syscalls dynamically
+ Avoid use of TARGET_<syscall> defines and rely on the callback layers
+ to resolve these dynamically so we can support multiple syscall layers
+ instead of assuming the newlib/libgloss numbers all the time.
+
+ sim: mn10300: resolve syscalls dynamically
+ Avoid use of TARGET_<syscall> defines and rely on the callback layers
+ to resolve these dynamically so we can support multiple syscall layers
+ instead of assuming the newlib/libgloss numbers all the time.
+
+ sim: nltvals: drop i960
+ This port was dropped from gdb/bfd/sim years ago, so stop including
+ its syscall constants too.
+
+ sim: moxie: fix datadir handling
+ Expand the value at `make` time rather than configure generation time
+ so that we handle $(datarootdir) setting properly.
+
+2021-11-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix typos in configure
+ The variable names used to restore CFLAGS and LDFLAGS here don't quite
+ match the names used above, resulting in losing the original CFLAGS and
+ LDFLAGS. Fix that.
+
+ Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: hw: mark hw_descriptors const
+
+ sim: testsuite: add dedicated flag for init toolchain tests
+ As we setup more reliable CC_FOR_TARGET variables for each target, the
+ bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
+ Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
+ can setup if they want to add custom options.
+
+ sim: testsuite: clean up arch specific toolchain settings
+ In a multitarget build, we process all targets in order, so make sure
+ the toolchain settings from one don't leak into the next.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: always search for local rvdummy tool
+ If the board info sets the sim to a basename that is found via $PATH
+ (which is the default dejagnu behavior), the logic here to use its
+ dirname to find rvdummy fails because it looks for `./rvdummy`. So
+ switch it to always use the local build of rvdummy which is the one
+ we want to be testing against in the first place.
+
+ If we get a request for testing against a different setup, we can
+ figure out & document the needs at that point, and then setup some
+ config knobs to control it.
+
+2021-11-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.base/list-missing-source.exp
+ In commit f8080fb7a44 "[gdb/testsuite] Add gdb.base/include-main.exp" a
+ file gdb.base/main.c was added, which caused the following regression:
+ ...
+ (gdb) list^M
+ <gdb.base/main.c>
+ (gdb) FAIL: gdb.base/list-missing-source.exp: list
+ ...
+
+ The problem is that the test-case does not expect to find a file main.c, but
+ now it finds gdb.base/main.c.
+
+ Fix this by using the more specific file name list-missing-source.c.
+
+ Tested on x86_64-linux.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: fix bits-gen EXEEXT handling
+ Add missing $(EXEEXT) to dependencies on bits-gen. These are actually
+ build-only tools, but automake doesn't allow for build & host tools, so
+ the rules are re-using EXEEXT.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: initial support for OS-specific tests
+ We usually test against the newlib/libgloss environment, but for a
+ few ports that also support Linux apps, we want to test that logic
+ too. A lot of the C code is written such that it works with either
+ newlib/libgloss or glibc/linux toolchains, but we have some tests
+ that end up being Linux-specific. Cris has been using the target
+ tuple as a rough proxy for this (where cris*-*-elf is assumed to be
+ newlib/libgloss, and everything else is glibc/linux), but that is a
+ bit too rough, and it doesn't work in a multitarget build.
+
+ So lets create a few stub files that we can do compile tests with
+ to detect the different setups, and then let tests declare which
+ one they require (if they require any at all).
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: unify basic C compiler checks
+ Both bfin & cris ports test the C compiler to see if it works, but in
+ their own way. Unify the checks in the common code so we can leverage
+ them in more ports in the future, and collapse the bfin & cris code.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: rework sim_init usage
+ The sim_init function was called by runtest for each test when --tool
+ was set to sim. When we changed to --tool '' to collapse the testsuite
+ dir, the init function was no longer called on every test. However, it
+ was still being called explicitly by config/default.exp. It's not clear
+ why that explicit call ever existed since, in the past, it meant it was
+ redundant.
+
+ Lets drop the single sim_init call in config/default.exp and move it out
+ to all our tests. This replicates the runtest behavior so we can setup
+ variables on a per-test basis which allows us to recollapse the sim_path
+ logic back. We'll also leverage this in the future for toolchain setup.
+
+ Also add a few comments clarifying the overall runtime behavior.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: fix testsuite hang when sim is missing
+ If the cris sim hasn't been built yet, trying to run its testsuite
+ will hang indefinitely. The common sim APIs already have this, so
+ copy it over to the cris forks of the test+run functions.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: fix objdir handling
+ The tests assume that the cwd is the objdir directory and write its
+ intermediates to there all the time. When using runtest's --objdir
+ setting though, this puts the files in the wrong place. This isn't
+ a big problem currently as we never change --objdir, but in order to
+ support parallel test execution, we're going to start setting that
+ option, so clean up the code ahead of time.
+
+ We also have to tweak some of the cris tests which were making
+ assumptions about the argv[0] value.
+
+2021-11-27 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: rename global_sim_options to SIMFLAGS_FOR_TARGET
+ Now that all the other toolchain settings have been renamed to match
+ the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
+ SIMFLAGS_FOR_TARGET too.
+
+ sim: testsuite: replace global_ld_options with LDFLAGS_FOR_TARGET
+ Only a few tests actually use global_ld_options, but we can replace the
+ sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
+ the same result.
+
+2021-11-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-26 John David Anglin <danglin@gcc.gnu.org>
+
+ Fix ifunc test fails on hppa*-*-*
+ 2021-11-26 John David Anglin <danglin@gcc.gnu.org>
+
+ PR ld/27442
+
+ ld/ChangeLog:
+
+ * ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust
+ regexp.
+ Skip static ifunc-using executable test on hppa*-*-*.
+
+2021-11-26 H.J. Lu <hjl.tools@gmail.com>
+
+ gas: Update commit 4780e5e4933
+ Update
+
+ commit 4780e5e4933a2497a5aecc4ceabbbb8e82aaf822
+ Author: Tom de Vries <tdevries@suse.de>
+ Date: Fri Nov 26 09:59:45 2021 +0100
+
+ [gas] Fix file 0 dir with -gdwarf-5
+
+ 1. Replace i with j in
+
+ for (j = 0; i < NUM_MD5_BYTES; ++j)
+
+ 2. Pass -W to readelf to force CU: in output due to:
+
+ if (do_wide || strlen (directory) < 76)
+ printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
+ else
+ printf ("%s:\n", file_table[0].name);
+
+ PR gas/28629
+ * dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit
+ 4780e5e4933.
+ * testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to
+ readelf.
+
+2021-11-26 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: replace global_as_options with ASFLAGS_FOR_TARGET
+ Only a few tests actually use global_as_options, but we can replace the
+ sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
+ the same result.
+
+2021-11-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.base/include-main.exp
+ The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with
+ -gnatG.
+
+ This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be
+ expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the
+ debug information should refer to the x.adb.dg file.
+
+ That is the case for the .debug_line part:
+ ...
+ The Directory Table is empty.
+
+ The File Name Table (offset 0x1c):
+ Entry Dir Time Size Name
+ 1 0 0 0 x.adb.dg
+ ...
+ but not for the .debug_info part:
+ ...
+ <11> DW_AT_name : $src/gdb/testsuite/gdb.ada/dgopt/x.adb
+ <15> DW_AT_comp_dir : $build/gdb/testsuite/outputs/gdb.ada/dgopt
+ ...
+
+ Filed as PR gcc/103436.
+
+ In C we can generate similar debug information, using a source file that does
+ not contain any code, but includes another one that does:
+ ...
+ $ cat gdb/testsuite/gdb.base/include-main.c
+ #include "main.c"
+ ...
+ such that in the .debug_line part we have:
+ ...
+ The Directory Table (offset 0x1c):
+ 1 /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base
+
+ The File Name Table (offset 0x57):
+ Entry Dir Time Size Name
+ 1 1 0 0 main.c
+ ...
+ and in the .debug_info part:
+ ...
+ <11> DW_AT_name : $src/gdb/testsuite/gdb.base/include-main.c
+ <15> DW_AT_comp_dir : $build/gdb/testsuite
+ ...
+
+ Add a C test-case that mimics gdb.ada/dgopt.exp, that is:
+ - generate debug info as described above,
+ - issue a list of a line in include-main.c, while the corresponding
+ CU is not expanded yet.
+
+ Tested on x86_64-linux.
+
+2021-11-26 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: drop unused global_cc_options
+ Nothing in the testsuite is using this setting, so let's drop it.
+ Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
+ instead to get the same effect.
+
+ sim: testsuite: punt unused toolchain variables
+ These haven't been used in over 20 years. The sim testsuite used to
+ run these tools itself directly, but back in ~1999 it switched to the
+ dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
+ logic only utilizes XXX_FOR_TARGET variables. Punt them here to avoid
+ confusion with dead code.
+
+2021-11-26 Andrew Burgess <aburgess@redhat.com>
+ Simon Cook <simon.cook@embecosm.com>
+
+ gdb: add risc-v disassembler options support
+ This commit adds support for RISC-V disassembler options to GDB. This
+ commit is based on this patch which was never committed:
+
+ https://sourceware.org/pipermail/binutils/2021-January/114944.html
+
+ All of the binutils refactoring has been moved to a separate, earlier,
+ commit, so this commit is pretty straight forward, just registering
+ the required gdbarch hooks.
+
+2021-11-26 Andrew Burgess <aburgess@redhat.com>
+ Simon Cook <simon.cook@embecosm.com>
+
+ opcodes/riscv: add disassembler options support to libopcodes
+ In preparation for the next commit, which will add GDB support for
+ RISC-V disassembler options, this commit restructures how the
+ disassembler options are managed within libopcodes.
+
+ The implementation provided here is based on this mailing list patch
+ which was never committed:
+
+ https://sourceware.org/pipermail/binutils/2021-January/114944.html
+
+ which in turn took inspiration from the MIPS implementation of the
+ same feature.
+
+ The biggest changes from the original mailing list post are:
+
+ 1. The GDB changes have been split into a separate patch, and
+
+ 2. The `riscv_option_args_privspec` variable, which held the valid
+ priv-spec values is now gone, instead we use the `riscv_priv_specs`
+ array from bfd/cpu-riscv.c instead.
+
+
+ include/ChangeLog:
+
+ * dis-asm.h (disassembler_options_riscv): Declare.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
+ (riscv_options): New static global.
+ (disassembler_options_riscv): New function.
+ (print_riscv_disassembler_options): Rewrite to use
+ disassembler_options_riscv.
+
+2021-11-26 Tom de Vries <tdevries@suse.de>
+
+ [gas] Fix file 0 dir with -gdwarf-5
+ In out_dir_and_file_list, if file 0 is copied from file 1, only the filename
+ is copied, and the dir and md5 fields are left to their default values.
+
+ Fix this by adding the copy of the dir and md5 fields.
+
+ gas/ChangeLog:
+
+ 2021-11-26 Tom de Vries <tdevries@suse.de>
+
+ PR 28629
+ * dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0,
+ also copy dir and md5 fields.
+ * testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output.
+
+2021-11-26 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: avoid _ namespace
+ Some C libraries export _P symbols in their headers (like older
+ newlib and its ctype.h), so use P_ instead to avoid conflicts.
+
+ ld: fix POSIX shell test usage
+ POSIX test uses = for compares, not == which is a bashism.
+
+ gas: enable silent build rules
+
+ ld: fix --disable-multiple-abs-defs alignment in help
+
+2021-11-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-25 Enze Li <lienze2010@hotmail.com>
+
+ gdb: ensure extension_language_python is always defined
+ In this commit:
+
+ commit c6a6aad52d9e839d6a84ac31cabe2b7e1a2a31a0
+ Date: Mon Oct 25 17:25:45 2021 +0100
+
+ gdb/python: make some global variables static
+
+ building without Python was broken. The extension_language_python
+ global was moved from being always defined, to only being defined when
+ the HAVE_PYTHON macro was defined. As a consequence, building without
+ Python support would result in errors like:
+
+ /usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python'
+
+ This commit fixes the problem by moving the definition of
+ extension_language_python outside of the HAVE_PYTHON macro protection.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ Revert "gdb: add assert in remote_target::wait relating to async being off"
+ This commit introduced a test failure in gdb.server/attach-flag.exp.
+ I didn't spot this failure originally as the problem is fixed by this,
+ as yet unpushed patch:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html
+
+ I unfortunately didn't test each patch in the original series
+ independently. I'll repost this patch after the above patch has been
+ merged.
+
+ This reverts commit 32b1f5e8d6b8ddd3be6e471c26dd85a1dac31dda.
+
+2021-11-25 Nick Clifton <nickc@redhat.com>
+
+ Fix building the AArch64 assembler and disassembler when assertions are disabled.
+ PR 28614
+ * aarch64-asm.c: Replace assert(0) with real code.
+ * aarch64-dis.c: Likewise.
+ * aarch64-opc.c: Likewise.
+
+2021-11-25 Bruno Larsen <blarsen@redhat.com>
+
+ PR gdb/28480: Improve ambiguous member detection
+ Basic ambiguity detection assumes that when 2 fields with the same name
+ have the same byte offset, it must be an unambiguous request. This is not
+ always correct. Consider the following code:
+
+ class empty { };
+
+ class A {
+ public:
+ [[no_unique_address]] empty e;
+ };
+
+ class B {
+ public:
+ int e;
+ };
+
+ class C: public A, public B { };
+
+ if we tried to use c.e in code, the compiler would warn of an ambiguity,
+ however, since A::e does not demand an unique address, it gets the same
+ address (and thus byte offset) of the members, making A::e and B::e have the
+ same address. however, "print c.e" would fail to report the ambiguity,
+ and would instead print it as an empty class (first path found).
+
+ The new code solves this by checking for other found_fields that have
+ different m_struct_path.back() (final class that the member was found
+ in), despite having the same byte offset.
+
+ The testcase gdb.cp/ambiguous.exp was also changed to test for this
+ behavior.
+
+2021-11-25 Jan W. Jagersma <jwjagersma@gmail.com>
+
+ coff-go32: consistent 16-byte section alignment
+ Section alignment for coff-go32 is inconsistent - The '.text' and
+ '.data' sections are 16-byte aligned, but named sections '.text.*' and
+ '.data.*' are only 4-byte aligned. '.gnu.linkonce.r.*' is aligned to
+ 16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes. For
+ '.bss' all input sections are only aligned to 4 bytes.
+
+ This primarily can cause trouble when using SSE instructions, which
+ require their memory operands to be aligned to 16-byte boundaries.
+
+ This patch solves the issue simply by setting the section alignment
+ to 16 bytes, for all code and data sections referenced in the default
+ linker script.
+
+ * coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES): Use partial
+ name match for .text, .data. Add entries for .const, .rodata,
+ .bss, .gnu.linkonce.b.
+
+2021-11-25 Alan Modra <amodra@gmail.com>
+
+ Re: AArch64: Add support for AArch64 EFI (efi-*-aarch64)
+ Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake,
+ which meant a typo in Makefile.am was not discovered and other
+ differences in Makefile.in are seen with a proper regeneration. One
+ difference was lack of an empty line between the pe-aarch64igen.c rule
+ and the following $(BFD32_LIBS) etc. dependency rule, in the
+ regenerated file. Not that it matters for proper "make" behaviour,
+ but it's nicer with a line between those rules. Moving the rule
+ earlier seems to cure the missing empty line.
+
+ * Makefile.am (BFD64_BACKENDS): Correct typo.
+ (BFD_H_DEPS, LOCAL_H_DEPS): Move earlier. Move rule using these
+ deps earlier too.
+ * Makefile.in: Regenerate.
+ * po/BLD-POTFILES.in: Regenerate.
+ * po/SRC-POTFILES.in: Regenerate.
+
+2021-11-25 Nick Clifton <nickc@redhat.com>
+
+ Updated French translation for the opcodes directory.
+ * po/fr.po; Updated French translation.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: rename source_styling_changed observer
+ In a later commit I plan to add disassembler styling. In the same way
+ that we have a source_styling_changed observer I would need to add a
+ disassembler_styling_changed observer.
+
+ However, currently, these observers would only be notified from
+ cli-style.c:set_style_enabled, and observed in tui-winsource.c,
+ tui_source_window::style_changed, as a result, having two observers
+ seems unnecessary right now, so, in this commit, I plan to rename
+ source_styling_changed to just styling_changed, then, in the later
+ commit, when disassembler styling is added, I can use the same
+ observer for both source styling, and disassembler styling.
+
+ There should be no user visible changes after this commit.
+
+2021-11-25 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: make some global variables static
+ Make a couple of global variables static in python/python.c. To do
+ this I had to move the definition of extension_language_python to
+ later in the file.
+
+ There should be no user visible changes after this commit.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add assert in remote_target::wait relating to async being off
+ While working on another patch I ended up in a situation where I had
+ async mode disabled (with 'maint set target-async off'), but the async
+ event token got marked anyway.
+
+ In this situation GDB was continually calling into
+ remote_target::wait, however, the async token would never become
+ unmarked as the unmarking is guarded by target_is_async_p.
+
+ We could just unconditionally unmark the token, but that would feel
+ like just ignoring a bug, so, instead, lets assert that if
+ !target_is_async_p, then the async token should not be marked.
+
+ This assertion would have caught my earlier mistake.
+
+ There should be no user visible changes with this commit.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: simplify remote_target::is_async_p
+ This commit simplifies remote_target::is_async_p by removing the
+ target_async_permitted check.
+
+ In previous commits I have added additional assertions around the
+ target_async_permitted flag into target.c, as a result we should now
+ be confident that if target_can_async_p returns false, a target will
+ never have async mode enabled. Given this, it should not be necessary
+ to check target_async_permitted in remote_target::is_async_p, if this
+ flag is false ::is_async_p should return false anyway. There is an
+ assert to this effect in target_is_async_p.
+
+ There should be no user visible change after this commit.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: add asserts in target.c for target_async_permitted
+ The target_async_permitted flag allows a user to override whether a
+ target can act in async mode or not. In previous commits I have moved
+ the checking of this flag out of the various ::can_async_p methods and
+ into the common target.c code.
+
+ In this commit I will add some additional assertions into
+ target_is_async_p and target_async. The rules these assertions are
+ checking are:
+
+ 1. A target that returns false for target_can_async_p should never
+ become "async enabled", and so ::is_async_p should always return
+ false. This is being checked in target_is_async_p.
+
+ 2. GDB should never try to enable async mode for a target that
+ returns false for target_can_async_p, this is checked in
+ target_async.
+
+ There are a few places where we call the ::is_async_p method directly,
+ in these cases we will obviously not pass through the assert in
+ target_is_async_p, however, there are also plenty of places where we
+ do call target_is_async_p so if GDB starts to misbehave we should
+ catch it quickly enough.
+
+ There should be no user visible changes after this commit.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: hoist target_async_permitted checks into target.c
+ This commit moves the target_async_permitted check out of each targets
+ ::can_async_p method and into the target_can_async_p wrapper function.
+
+ I've left some asserts in the two ::can_async_p methods that I
+ changed, which will hopefully catch any direct calls to these methods
+ that might be added in the future.
+
+ There should be no user visible changes after this commit.
+
+2021-11-25 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: introduce a new overload of target_can_async_p
+ There are a few places where we call the target_ops::can_async_p
+ member function directly, instead of using the target_can_async_p
+ wrapper.
+
+ In some of these places this is because we need to ask before the
+ target has been pushed, and in another location (in target.c) it seems
+ unnecessary to go through the wrapper when we are already in target.c
+ code.
+
+ However, in the next commit I'd like to hoist some common checks out
+ of target specific code into target.c. To achieve this, in this
+ commit, I introduce a new overload of target_can_async_p which takes a
+ target_ops pointer, and calls the ::can_async_p method directly. I
+ then make use of the new overload where appropriate.
+
+ There should be no user visible changes after this commit.
+
+2021-11-25 Clément Chigot <clement.chigot@atos.net>
+
+ ld/testsuite/ld-elfvsb: correctly test "weak hidden symbol DSO last"
+ The test must be done with the shared object and not with the object
+ file which is already being tested above.
+
+ ld/
+ * testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden
+ symbol DSO last"
+
+2021-11-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Add "set logging enabled", deprecate "set logging on/off"
+ Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
+ following output for "show logging file":
+ ...
+ $ gdb -q -batch -ex "set trace-commands on" \
+ -ex "set logging off" \
+ -ex "show logging file" \
+ -ex "set logging on" \
+ -ex "show logging file"
+ +set logging off
+ +show logging file
+ Future logs will be written to gdb.txt.
+ +set logging on
+ +show logging file
+ Currently logging to "gdb.txt".
+ ...
+
+ After that commit we have instead:
+ ...
+ +set logging off
+ +show logging file
+ The current logfile is "gdb.txt".
+ +set logging on
+ +show logging file
+ The current logfile is "gdb.txt".
+ ...
+
+ Before the commit, whether logging is enabled or not can be deduced from the
+ output of the command. After the commit, the message is unified and it's no
+ longer clear whether logging is enabled or not.
+
+ Fix this by:
+ - adding a new command "show logging enabled"
+ - adding a corresponding new command "set logging enabled on/off"
+ - making the commands "set logging on/off" deprecated aliases of the
+ "set logging enabled on/off" command.
+
+ Update the docs and testsuite to use "set logging enabled". Mention the new
+ and deprecated commands in NEWS.
+
+ Tested on x86_64-linux.
+
+2021-11-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Fix typo in logging overwrite help text
+ Currently we have:
+ ...
+ $ gdb -q -batch -ex "help set logging overwrite"
+ Set whether logging overwrites or appends to the log file.
+ If set, logging overrides the log file.
+ ...
+
+ Fix overrides -> overwrites typo.
+
+2021-11-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-24 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix help doc for "set index-cache enabled"
+ When implementing this command, I put "help doc" as a placeholder for
+ the help string, and forgot to update it. Change it for a real help
+ string.
+
+ Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09
+
+2021-11-24 Simon Marchi <simon.marchi@efficios.com>
+
+ Revert (part of) "gdb fix for catch-syscall.exp"
+ This reverts (par of) commit ab198279120fe7937c0970a8bb881922726678f9.
+ This commit changed what the test expects when catching the execve
+ syscall based on the behavior seen on a Linux PowerPC machine. That is,
+ we get an "entry" event, but no "return" event. This is not what we get
+ on Linux with other architectures, though, and it seems like a
+ PowerPC-specific bug.
+
+ Revert the part of the patch related to this, but not the other hunk.
+
+ Change-Id: I4248776e4299f10999487be96d4acd1b33639996
+
+2021-11-24 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access parsing a corrupt sysroff file.
+ PR 28564
+ * sysdump.c (getCHARS): Check for an out of bounds read.
+
+2021-11-24 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: fix crash when reading ECOFF debug information
+ In commit:
+
+ commit 633cf2548bcd3dafe297e21a1dd3574240280d48
+ Date: Wed May 9 15:42:28 2018 -0600
+
+ Remove cleanups from mdebugread.c
+
+ the following change was made in the function parse_partial_symbols in
+ mdebugread.c:
+
+ - fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1);
+ - old_chain = make_cleanup (xfree, fdr_to_pst);
+ + gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1);
+ + fdr_to_pst = fdr_to_pst_holder.data ();
+
+ The problem with this change is that XCNEWVEC calls xcalloc, which in
+ turn calls calloc, and calloc zero initializes the allocated memory.
+ In contrast, the new line gdb::def_vector<struct pst_map> specifically
+ does not initialize the underlying memory.
+
+ This is a problem because, later on in this same function, we
+ increment the n_globals field within 'struct pst_map' objects stored
+ in the vector. The incrementing is now being done from an
+ uninitialized starting point.
+
+ In this commit we switch from using gdb::def_vector to using
+ std::vector, this alone should be enough to ensure that the fields are
+ initialized to zero.
+
+ However, for extra clarity, I have also added initial values in the
+ 'struct pst_map' to make it crystal clear how the struct will start
+ up.
+
+ This issue was reported on the mailing list here:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html
+
+ Co-Authored-By: Lightning <lightningth@gmail.com>
+
+2021-11-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-23 Alexandra Hájková <ahajkova@redhat.com>
+
+ configure.ac: Check for the readline.h explicitly
+ When readline development package is missing make fails with
+ "configure: error: system readline is not new enough" which
+ might be confusing. This patch checks for the readline.h explicitly
+ and makes make to warn about the missing package.
+
+2021-11-23 Tamar Christina <tamar.christina@arm.com>
+
+ AArch64: Add support for AArch64 EFI (efi-*-aarch64).
+ This adds support for efi-*-aarch64 by virtue of adding a new PEI target
+ pei-aarch64-little. This is not a full target and only exists to support EFI
+ at this time.
+
+ This means that this target does not support relocation processing and is mostly
+ a container format. This format has been added to elf based aarch64 targets
+ such that efi images can be made natively on Linux.
+
+ However this target is not valid for use with gas but only with objcopy.
+
+ With these changes the resulting file is recognized as an efi image by
+ third party tools:
+
+ > pecli info hello.efi
+
+ Metadata
+ ================================================================================
+ MD5: 598c32a778b0f0deebe977fef8578c4e
+ SHA1: 4580121edd5cb4dc40f51b28f171fd15250df84c
+ SHA256: 3154bd7cf42433d1c957f6bf55a17ad8c57ed41b29df2d485703349fd6ff1d5c
+ Imphash:
+ Size: 47561 bytes
+ Type: PE32+ executable (EFI application) (stripped to external PDB), for MS Windows
+ Compile Time: 1970-01-01 00:00:00 (UTC - 0x0 )
+ Entry point: 0x2000 (section .text)
+
+ Sections
+ ================================================================================
+ Name RWX VirtSize VirtAddr RawAddr RawSize Entropy md5
+ .text R-X 0x5bb0 0x2000 0x400 0x5c00 6.39 551fbc264256a3f387de8a891500ae0d
+ .reloc R-- 0xc 0x8000 0x6000 0x200 0.02 0c45f6d812d079821c1d54c09ab89e1d
+ .data RW- 0x1d88 0x9000 0x6200 0x1e00 4.18 5d1137c09f01289dc62bf754f7290db3
+ .dynamic RW- 0xf0 0xb000 0x8000 0x200 0.34 5c94ed3206f05a277e6f04fbf131f131
+ .rela R-- 0xe58 0xc000 0x8200 0x1000 1.87 8b5c6bc30f3acb7ca7bf2e6789d68519
+ .dynsym R-- 0x138 0xd000 0x9200 0x200 0.96 bdcf5101da51aadc663ca8859f88138c
+
+ Imports
+ ================================================================================
+
+ Any magic number is based on the Microsoft PE specification [1].
+
+ [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
+
+ bfd/ChangeLog:
+
+ 2021-10-21 Tamar Christina <tamar.christina@arm.com>
+
+ PR binutils/26206
+ * .gitignore (pe-aarch64igen.c): New.
+ * Makefile.am (pei-aarch64.lo, pe-aarch64igen.lo, pei-aarch64.c,
+ pe-aarch64igen.c): Add support.
+ * Makefile.in: Likewise.
+ * bfd.c (bfd_get_sign_extend_vma): Add pei-aarch64-little.
+ * coff-aarch64.c: New file.
+ * coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
+ coff_write_object_contents) Add aarch64 (aarch64_pei_vec) support.
+ * config.bfd: Likewise.
+ * configure: Likewise.
+ * configure.ac: Likewise.
+ * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
+ GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
+ GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
+ GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
+ GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
+ GET_PDATA_ENTRY, _bfd_peAArch64_bfd_copy_private_bfd_data_common,
+ _bfd_peAArch64_bfd_copy_private_section_data,
+ _bfd_peAArch64_get_symbol_info, _bfd_peAArch64_only_swap_filehdr_out,
+ _bfd_peAArch64_print_private_bfd_data_common,
+ _bfd_peAArch64i_final_link_postscript,
+ _bfd_peAArch64i_only_swap_filehdr_out, _bfd_peAArch64i_swap_aouthdr_in,
+ _bfd_peAArch64i_swap_aouthdr_out, _bfd_peAArch64i_swap_aux_in,
+ _bfd_peAArch64i_swap_aux_out, _bfd_peAArch64i_swap_lineno_in,
+ _bfd_peAArch64i_swap_lineno_out, _bfd_peAArch64i_swap_scnhdr_out,
+ _bfd_peAArch64i_swap_sym_in, _bfd_peAArch64i_swap_sym_out,
+ _bfd_peAArch64i_swap_debugdir_in, _bfd_peAArch64i_swap_debugdir_out,
+ _bfd_peAArch64i_write_codeview_record,
+ _bfd_peAArch64i_slurp_codeview_record,
+ _bfd_peAArch64_print_ce_compressed_pdata): New.
+ * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
+ pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
+ _bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
+ Support COFF_WITH_peAArch64,
+ * pei-aarch64.c: New file.
+ * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
+ Support COFF_WITH_peAArch64.
+ (jtab): Add dummy entry that traps.
+ * targets.c (aarch64_pei_vec): New.
+
+ binutils/ChangeLog:
+
+ 2021-10-21 Tamar Christina <tamar.christina@arm.com>
+
+ PR binutils/26206
+ * NEWS: Add new support.
+ * objcopy.c (convert_efi_target): Add efi-*-aarch64 support.
+ * testsuite/binutils-all/aarch64/pei-aarch64-little.d: New test.
+ * testsuite/binutils-all/aarch64/pei-aarch64-little.s: New test.
+
+ include/ChangeLog:
+
+ 2021-10-21 Tamar Christina <tamar.christina@arm.com>
+
+ PR binutils/26206
+ * coff/aarch64.h: New file.
+ * coff/pe.h (IMAGE_FILE_MACHINE_ARM64): New.
+
+2021-11-23 Alan Modra <amodra@gmail.com>
+
+ binutils debuginfod test
+ A missing "return" resulted in this non-ELF fail:
+ x86_64-w64-mingw32 +FAIL: debuginfod (create separate debug info file)
+
+ Also, the debuginfod I have installed does not appear to handle
+ non-native ELF objects, so only run the test when native.
+
+ * testsuite/binutils-all/debuginfod.exp: Don't run test unless
+ native ELF.
+
+2021-11-23 Alan Modra <amodra@gmail.com>
+
+ Update bug reporting address
+ https://sourceware.org/bugzilla/ everywhere
+
+ bfd/
+ * configure.ac (ACX_BUGURL): Set to https://sourceware.org/bugzilla/
+ * po/Make-in (msgid-bugs-address): Likewise.
+ * README: Report bugs to the above.
+ * configure: Regenerate.
+ binutils/
+ * po/Make-in (msgid-bugs-address): Update.
+ gas/
+ * README: Update bug address. Delete mention of gcc.
+ * po/Make-in: Update bug address.
+ gold/
+ * po/Make-in: Update bug address.
+ gprof/
+ * po/Make-in: Update bug address.
+ ld/
+ * po/Make-in: Update bug address.
+ opcodes/
+ * po/Make-in: Update bug address.
+
+2021-11-23 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
+
+ gdb: more compile fixes for gnu-nat.c
+ This fixes compile errors like
+
+ ../../gdb-11.1/gdb/gnu-nat.c: In function void add_task_commands():
+ ../../gdb-11.1/gdb/gnu-nat.c:3204:17: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
+ 3204 | &setlist);
+ | ^
+ In file included from ../../gdb-11.1/gdb/completer.h:21,
+ from ../../gdb-11.1/gdb/symtab.h:36,
+ from ../../gdb-11.1/gdb/infrun.h:21,
+ from ../../gdb-11.1/gdb/target.h:42,
+ from ../../gdb-11.1/gdb/inf-child.h:23,
+ from ../../gdb-11.1/gdb/gnu-nat.h:38,
+ from ../../gdb-11.1/gdb/gnu-nat.c:24:
+ ../../gdb-11.1/gdb/command.h:160:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, void (*)(const char*, int), const char*, cmd_list_element**)
+ 160 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
+ | ^~~~~~~
+ ../../gdb-11.1/gdb/command.h:161:30: note: no known conversion for argument 3 from cmd_list_element* to void (*)(const char*, int)
+ 161 | cmd_const_cfunc_ftype *fun,
+ | ~~~~~~~~~~~~~~~~~~~~~~~^~~
+ ../../gdb-11.1/gdb/command.h:167:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, const char*, cmd_list_element**)
+ 167 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
+ | ^~~~~~~
+ ../../gdb-11.1/gdb/command.h:167:33: note: candidate expects 4 arguments, 5 provided
+ ../../gdb-11.1/gdb/gnu-nat.c:3210:18: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
+ 3210 | &showlist);
+ | ^
+
+ Change-Id: Ie9029363d3fb40e34e8f5b1ab503745bc44bfe3f
+
+2021-11-23 Andrea Monaco <andrea.monaco@autistici.org>
+
+ gnu-nat.c: fix calls to add_info_alias
+ Some time ago add_info_alias was changed (commit
+ e0f25bd9717c7973197095523db7c1cdc956cea2). These calls were not updated
+ and caused errors on compilation.
+
+ Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de
+
+2021-11-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: pass more const target_waitstatus by reference
+ While working on target_waitstatus changes, I noticed a few places where
+ const target_waitstatus objects could be passed by reference instead of
+ by pointers. And in some cases, places where a target_waitstatus could
+ be passed as const, but was not. Convert them as much as possible.
+
+ Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
+
+2021-11-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: introduce target_waitkind_str, use it in target_waitstatus::to_string
+ I would like to print target_waitkind values in debug messages, so I
+ think that a target_waitkind-to-string function would be useful. While
+ at it, use it in target_waitstatus::to_string. This changes the output
+ of target_waitstatus::to_string a bit, but I think it is for the better.
+ The debug messages will show a string matching exactly the
+ target_waitkind enumerator (minus the TARGET_WAITKIND prefix).
+
+ As a convenience, make string_appendf return the same reference to
+ string it got as a parameter. This allows doing this:
+
+ return string_appendf (str, "foo");
+
+ ... keeping the code concise.
+
+ Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7
+
+2021-11-22 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rename target_waitstatus_to_string to target_waitstatus::to_string
+ Make target_waitstatus_to_string a "to_string" method of
+ target_waitstatus, a bit like we have ptid_t::to_string already. This
+ will save a bit of typing.
+
+ Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905
+
+2021-11-22 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Removed the redundant NULL pointer check in the riscv_update_subset.
+ If we always use the .option arch to call the riscv_update_subset, then
+ it is almost impossible that the input string will be NULL. Therefore,
+ just remove the redundant NULL pointer check in the riscv_update_subset.
+
+ bfd/
+ * elfxx-riscv.c (riscv_update_subset): Removed the redundant NULL
+ pointer check.
+
+2021-11-22 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Replace .option rvc/norvc with .option arch, +c/-c.
+ Since the .option rvc/norvc directives are obsolete, replace them with
+ the new proposed diretives: .option arch, +c/-c. And also reset the
+ riscv_opts.rvc flag for the .option arch directives.
+
+ gas/
+ * config/tc-riscv.c (s_riscv_option): Reset the riscv_opts.rvc
+ for the .option arch directives.
+ * testsuite/gas/riscv/align-1.s: Replace the obsolete .option
+ rvc/norvc with .option arch, +c/-c.
+ * testsuite/gas/riscv/c-add-addi.s: Likewise.
+ * testsuite/gas/riscv/c-nonzero-imm.s: Likewise.
+ * testsuite/gas/riscv/c-nonzero-reg.s: Likewise.
+ * testsuite/gas/riscv/c-zero-imm-64.s: Likewise.
+ * testsuite/gas/riscv/c-zero-imm.s: Likewise.
+ * testsuite/gas/riscv/c-zero-reg.s: Likewise.
+ * testsuite/gas/riscv/ext.s: Likewise.
+ * testsuite/gas/riscv/mapping-01.s: Likewise.
+ * testsuite/gas/riscv/mapping-02.s: Likewise.
+ * testsuite/gas/riscv/mapping-03.s: Likewise.
+ * testsuite/gas/riscv/mapping-04.s: Likewise.
+ * testsuite/gas/riscv/no-relax-align-2.s: Likewise.
+ * testsuite/gas/riscv/shamt-32.s: Likewise.
+ * testsuite/gas/riscv/shamt-64.s: Likewise.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix x86_64 x32 build
+ A build error on x86_64 with x32 abi was reported here (
+ https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
+ ...
+ gdb/nat/amd64-linux-siginfo.c:280:42: error: \
+ 'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
+ named 'si_addr_bnd'
+ 280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
+ | ^~~~~~~~~~~
+ gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
+ 337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
+ | ^~~~~~~~~~~~
+ ...
+
+ The problem is that code added in commit d3d7d1ba3bb "[gdb/tdep] Handle
+ si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
+ setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.
+
+ Fix this conservatively by disabling the code for x32.
+
+ Tested on x86_64-linux.
+
+2021-11-22 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: PR28610, Fix ASAN heap-buffer-overflow error in riscv_update_subset.
+ The architecture parser in riscv_update_subset shouldn't check (or access)
+ the pointer space which doesn't exist.
+
+ bfd/
+ pr 28610
+ * elfxx-riscv.c (riscv_update_subset): The architecture parser
+ shouldn't access the pointer space which doesn't exist.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Support .debug_line with DW_FORM_line_strp
+ I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
+
+ With a test-case hello.c:
+ ...
+ int
+ main (void)
+ {
+ printf ("hello\n");
+ return 0;
+ }
+ ...
+ compiled like this:
+ ...
+ $ gcc -g -gdwarf64 ~/hello.c
+ ...
+ I ran into:
+ ...
+ $ gdb -q -batch a.out
+ DW_FORM_line_strp pointing outside of .debug_line_str section \
+ [in module a.out]
+ ...
+
+ Debugging gdb revealed that the string offset is:
+ ...
+ (gdb) up
+ objfile=0x182ab70, str_offset=1378684502312,
+ form_name=0xeae9b5 "DW_FORM_line_strp")
+ at src/gdb/dwarf2/section.c:208
+ 208 error (_("%s pointing outside of %s section [in module %s]"),
+ (gdb) p /x str_offset
+ $1 = 0x14100000128
+ (gdb)
+ ...
+ which is read when parsing a .debug_line entry at 0x1e0.
+
+ Looking with readelf at the 0x1e0 entry, we have:
+ ...
+ The Directory Table (offset 0x202, lines 2, columns 1):
+ Entry Name
+ 0 (indirect line string, offset: 0x128): /data/gdb_versions/devel
+ 1 (indirect line string, offset: 0x141): /home/vries
+ ...
+ which in a hexdump looks like:
+ ...
+ 0x00000200 1f022801 00004101 00000201 1f020f02
+ ...
+
+ What happens is the following:
+ - readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
+ a 4 byte value, and sees entries 0x00000128 and 0x00000141.
+ - gdb instead interprets it as an 8 byte value, and sees as first entry
+ 0x0000014100000128, which is too big so it bails out.
+
+ AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis
+ that the corresponding CU is 64-bit DWARF. However, the .debug_line
+ contribution has it's own initial_length field, and encodes there that it's
+ 32-bit DWARF.
+
+ Fix this by using the correct offset size for DW_FORM_line_strp references
+ in .debug_line.
+
+ Note: the described test-case does trigger this complaint (both with and
+ without this patch):
+ ...
+ $ gdb -q -batch -iex "set complaints 10" a.out
+ During symbol reading: intermixed 32-bit and 64-bit DWARF sections
+ ...
+
+ The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
+ gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's
+ what gas generates. Perhaps this is complaint-worthy, but I don't think it
+ is wrong.
+
+ Tested on x86_64-linux, using native and target board dwarf64.exp.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add target board dwarf64.exp
+ Add a new target board dwarf64.exp, that runs test with -gdwarf64.
+
+ Tested on x86_64-linux.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Support .debug_line v5 in dwarf assembler
+ The v5 section version for .debug_line has:
+ - two new fields address_size and segment_selector_size
+ - a different way to encode the directory and filename tables.
+
+ Add support for this in the dwarf assembler.
+
+ For now, make the v5 directory and filename tables work with the v4 type of
+ specification in the test-cases by adding duplicate entries at position 0.
+
+ This will need to be properly fixed with an intrusive fix that changes how
+ directory and filename entries are specified in the test-cases, f.i:
+ ...
+ set diridx [include_dir "${srcdir}/${subdir}"]
+ set fileidx [file_name "$srcfile" $diridx]
+ ...
+
+ Tested on x86_64-linux.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Factor out _line_finalize_header
+ Rather than generate dwarf immediately in procs include_dir and file_name,
+ postpone generation and store the data in variables. Then handle the
+ generation in a new proc _line_finalize_header.
+
+ Tested on x86-64-linux.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Support .debug_line v4 in dwarf assembler
+ The .debug_line header got a new field in v4:
+ maximum_operations_per_instruction.
+
+ Generate this field in the dwarf assembler, for now hardcoding the value to 1,
+ meaning non-VLIW.
+
+ Tested on x86_64-linux.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add test-case gdb.dwarf2/dw2-lines.exp
+ Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line
+ sections.
+
+ Tested on x86_64-linux.
+
+2021-11-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Speed up MACRO_AT_* calls
+ Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
+ following is done:
+ - $srcdir/$subdir/$srcfile is compiled to an executable using
+ flags "debug"
+ - a new gdb instance is started
+ - the new executable is loaded.
+
+ This is inefficient, because the executable is identical within the same
+ Dwarf::assemble call.
+
+ Share the gdb instance in the same Dwarf::assemble invocation, which speeds
+ up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
+ test-cases:
+ ...
+ rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
+ | xargs grep -l Dwarf::assemble))
+ ...
+ from:
+ ...
+ real 1m39.916s
+ user 1m25.668s
+ sys 0m21.377s
+ ...
+ to:
+ ...
+ real 1m29.512s
+ user 1m17.316s
+ sys 0m19.100s
+ ...
+
+ Tested on x86_64-linux.
+
+2021-11-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-21 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Remove duplicates in gdb.base/catch-signal.exp
+ When running the testsuite I have the following:
+
+ Running .../gdb/testsuite/gdb.base/catch-signal.exp ...
+ DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
+ DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
+ DUPLICATE: gdb.base/catch-signal.exp: 1: continue
+ DUPLICATE: gdb.base/catch-signal.exp: 1: continue
+ DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
+ DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
+
+ This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly
+ giving names to the offending 'gdb_test "continue"' statements to make
+ them distinct.
+
+ Tested on x86_64-linux.
+
+2021-11-21 Mike Frysinger <vapier@gentoo.org>
+
+ sim: v850: fix cpu_option testsuite handling
+ The v850 testsuite code has been testing the $opt variable, but this
+ was never actually set anywhere globally or v850-specific. Instead,
+ this was a random variable leaking out of the sh testsuite code. As
+ far as I can tell, it has always been this way. That means the code
+ only ever tested the v850 cpu target (which is the default).
+
+ This failure can be easily seen in practice by running the v850 code
+ in isolation and seeing it crash:
+ $ runtest v850/allinsns.exp
+ ...
+ Running target unix
+ Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
+ Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
+ Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file.
+ WARNING: Assuming target board is the local machine (which is probably wrong).
+ You may need to set your DEJAGNU environment variable.
+ Running ../../../sim/testsuite/v850/allinsns.exp ...
+ ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp.
+ ERROR: tcl error code TCL LOOKUP VARNAME opt
+ ERROR: can't read "opt": no such variable
+ while executing
+ "switch -regexp -- $opt {
+
+ Backing up a bit, the reason for this logic in the first place is
+ because the common sim testsuite code makes an assumption about the
+ assembler options with cpu_option -- the option and its value are
+ always separated by an =. This is not the case with v850. So tweak
+ the core sim logic a bit to support omitting the = so that we can
+ switch v850 to the standard all_machs setting and avoid opt entirely.
+
+2021-11-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-20 Jeff Law <jeffreyalaw@gmail.com>
+
+ Fix intermittent failures on the H8, particularly H8/SX tests.
+ The upstream GCC tester has showed spurious execution failures on the
+ H8 target for the H8/SX multilibs. I suspected memory corruption or an
+ uninitialized variable early as the same binary would sometimes work and
+ sometimes it got the wrong result. Worse yet, the point where the test
+ determined it was getting the wrong result would change.
+
+ Because it only happened on the H8/SX variant I was able to zero in on
+ the "mova" support and the "short form" of those instructions in particular.
+
+ As the code stands it checks if code->op3.type == 0 to try and identify cases
+ where op3 wasn't filled in and thus we've got the short form of the mova
+ instruction.
+
+ But for the short-form of those instructions we never set any of the "op3"
+ data structure. We get whatever was lying around -- it's usually zero and
+ thus things usually work, but if the stale data was nonzero, then we'd
+ fail to recognize the instruction as a short-form and fail to set up the
+ various fields appropriately.
+
+ I initially initialized the op3.type field to zero, but didn't like that
+ because it was inconsistent with how other operands were initialized.
+ Bringing consistency meant using -1 as the initializer value and adjusting
+ the check for short form mova appropriately.
+
+ I've had this in the upstream GCC tester for perhaps a year at this point
+ and haven't seen any of the intermittent failures again.
+
+2021-11-20 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUG
+ When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors
+ like:
+
+ CXX unittests/array-view-selftests.o
+ In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25,
+ from /home/smarchi/src/binutils-gdb/gdb/defs.h:630,
+ from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20:
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int:
+ /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29: required from here
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement
+ 192 | }
+ | ^
+
+ This is because constexpr functions in c++11 can only consist of a
+ single return statement, so we can't have the gdb_assert in there. Make
+ the gdb_assert presence conditional to the __cplusplus version, to
+ enable it only for c++14 and later.
+
+ Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0
+
+2021-11-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Check if libsource-highlight is usable
+ When building gdb with g++ 4.8.5, I ran into:
+ ...
+ ld: source-cache.o: in function `source_cache::ensure(symtab*)':
+ source-cache.c:207: undefined reference to \
+ srchilite::SourceHighlight::SourceHighlight(std::string const&)
+ ...
+
+ [ I configured gdb without explicit settings related to source-highlight, so
+ we're excercising the enable_source_highlight=auto scenario. ]
+
+ The problem is that:
+ - the source-highlight library is build with system compiler
+ g++ 7.5.0 which uses the new libstdc++ library abi (see
+ https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
+ - gdb is build using g++ 4.8.5 which uses the old abi.
+
+ [ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
+ for this case. Instead, it enables the opposite case where the
+ source-highlight library is build with g++ 4.8.5 and gdb is build with
+ g++ 7.5.0. ]
+
+ Fix this by checking whether the source-highlight library is usable during
+ configuration.
+
+ In the enable_source_highlight=auto scenario, this allows the build to skip
+ the unusable library and finish successfully.
+
+ In the enable_source_highlight=yes scenario, this allows the build to error
+ out earlier.
+
+ Tested on x86_64-linux.
+
+2021-11-20 Clément Chigot <clement.chigot@atos.net>
+
+ bfd: remove wrong comment in xcofflink.c
+ This comment was long time ago associated to the function
+ "xcoff_build_ldsyms" which have since been replaced by
+ "xcoff_build_ldsym".
+
+ * xcofflink.c: Remove wrong comment.
+
+2021-11-20 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bfin: fix short --env usage in testsuite
+ Now that we have more than one option that matches "--env", the test
+ config here doesn't work. Use the explicit --environment.
+
+2021-11-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-19 H.J. Lu <hjl.tools@gmail.com>
+
+ elfedit: Align --[in|out]put-abiversion usage
+ Align
+
+ --input-abiversion [0-255] Set input ABIVERSION
+ --output-abiversion [0-255] Set output ABIVERSION
+
+ instead of
+
+ --input-abiversion [0-255]
+ Set input ABIVERSION
+ --output-abiversion [0-255]
+ Set output ABIVERSION
+
+ * elfedit.c (usage): Align --[in|out]put-abiversion usage.
+
+2021-11-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle runto fail in gdb.mi/mi-var-cp.exp
+ On OBS I ran into:
+ ...
+ PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint)
+ UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target
+ ...
+ followed by 81 FAILs and two more UNRESOLVEDs.
+
+ I didn't manage to reproduce this, but I did notice that the initial
+ problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs.
+
+ I emulated the problem by commenting out the send_gdb "run\n" in
+ mi_run_cmd_full.
+
+ Fix this by:
+ - handling mi_run_cmd failure in mi_get_inline_test
+ - handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and
+ other test-cases using mi_get_inline_test
+
+ Tested on x86_64-linux.
+
+2021-11-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix 64-bit dwarf test-cases with -m32
+ When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
+ I run into:
+ ...
+ builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
+ -fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
+ loc-sec-offset-dw64.S^M
+ as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
+ loc-sec-offset-dw64.S: Assembler messages:^M
+ loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
+ BFD_RELOC_64^M
+ ...
+
+ Looking at line 29, we have:
+ ...
+ .8byte .Labbrev1_begin /* Abbrevs */
+ ...
+
+ It would be nice if the assembler could handle this somehow. But I guess
+ it's not unreasonable that an assembler for a 32-bit architecture will object
+ to handling 64-bit labels.
+
+ Instead, work around this in the dwarf assembler by emitting:
+ ...
+ .4byte .Labbrev1_begin /* Abbrevs (lsw) */
+ .4byte 0 /* Abbrevs (msw) */
+ ...
+
+ Tested on x86_64-linux with target board unix/-m32.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383
+
+2021-11-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp
+ On OBS I ran into a failure in test-case gdb.threads/thread-specific-bp.exp:
+ ...
+ (gdb) PASS: gdb.threads/thread-specific-bp.exp: non-stop: continue to end
+ info breakpoint^M
+ Num Type Disp Enb Address What^M
+ 1 breakpoint keep y 0x0000555555555167 in main at $src:36^M
+ breakpoint already hit 1 time^M
+ 2 breakpoint keep y 0x0000555555555151 in start at $src:23^M
+ breakpoint already hit 1 time^M
+ 3 breakpoint keep y 0x0000555555555167 in main at $src:36 thread 2^M
+ stop only in thread 2^M
+ 4 breakpoint keep y 0x000055555555515c in end at $src:29^M
+ breakpoint already hit 1 time^M
+ (gdb) [Thread 0x7ffff7db1640 (LWP 19984) exited]^M
+ Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
+ FAIL: gdb.threads/thread-specific-bp.exp: non-stop: \
+ thread-specific breakpoint was deleted (timeout)
+ ...
+
+ Fix this by waiting for the "[Thread 0x7ffff7db1640 (LWP 19984) exited]"
+ message before issuing the "info breakpoint command".
+
+ Tested on x86_64-linux.
+
+2021-11-19 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb/testsuite: Extend tests for print of cv qualifiers
+ This commit supplements whatis and ptype command tests for print of
+ const-volatile qualifiers.
+
+ gdb/testsuite/ChangeLog:
+ 2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
+
+ * gdb.cp/ptype-cv-cp.cc: New const and volatile typedef
+ variables.
+ * gdb.cp/ptype-cv-cp.exp: Add new tests.
+
+2021-11-19 Christina Schimpe <christina.schimpe@intel.com>
+
+ gdb: Print cv qualifiers if class attributes are substituted
+ Make ptype print const/volatile qualifiers when template or typedef
+ attributes are substituted.
+
+ For a programm like
+ ~~~
+ template<typename DataT>
+ class Cfoo
+ {
+ typedef float myfloat;
+ public:
+ DataT me0;
+ const DataT me1=1;
+ const myfloat me2=2.0;
+ };
+
+ int main()
+ {
+ Cfoo<int> cfoo;
+ return 0;
+ }
+ ~~~
+
+ gdb outputs the following type for cfoo's attributes:
+
+ ~~~
+ (gdb) b 14
+ Breakpoint 1 at 0x1170: file tmp.cc, line 14.
+ (gdb) run
+ Starting program: /tmp
+
+ Breakpoint 1, main () at tmp.cc:14
+ 14 return 0;
+ (gdb) ptype cfoo
+ type = class Cfoo<int> [with DataT = int] {
+ public:
+ DataT me0;
+ DataT me1;
+ myfloat me2;
+
+ private:
+ typedef float myfloat;
+ }
+
+ ~~~
+
+ The cv qualifiers (const in this case) are ignored for me1 and me2.
+
+ After:
+ ~~~
+ (gdb) ptype cfoo
+ type = class Cfoo<int> [with DataT = int] {
+ public:
+ DataT me0;
+ const DataT me1;
+ const myfloat me2;
+
+ private:
+ typedef float myfloat;
+ }
+ ~~~
+
+ gdb/ChangeLog:
+ 2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
+
+ * gdb/c-typeprint.c: Print cv qualifiers in case of parameter
+ substitution.
+
+ gdb/testsuite/ChangeLog:
+ 2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
+
+ * gdb.cp/templates.cc: New template class Cfoo with const,
+ template, typdef and integer attributes.
+ * gdb.cp/templates.exp: Add new test using ptype and ptype/r
+ commmands for template class CFoo.
+
+2021-11-19 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Support new .option arch directive.
+ https://github.com/riscv/riscv-asm-manual/pull/67
+
+ Format:
+ .option arch, +<extension><version>, ...
+ .option arch, -<extension>
+ .option arch, =<ISA string>
+
+ The new direcitve is used to enable/disable extensions for the specific
+ code region. For example,
+
+ .attribute arch, "rv64ic" # arch = rv64i2p0_c2p0
+ .option push
+ .option arch, +d2p0, -c # arch = rv64i2p0_f2p0_d2p0, f is added implied
+ .option arch, =rv32gc # arch = rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0
+ .option pop # arch = rv64i2p0_c2p0
+
+ Note that,
+ 1. ".option rvc/norvc" have the same behavior as ".option arch +c/-c".
+ 2. ".option arch -i" is illegal, since we cannot remove base i extension.
+ 3. If arch=rv64i2p0, then ".option arch, +i3p0" will update the i's version
+ from 2.0 to 3.0.
+ 4. If arch=rv64i3p0, then ".option arch, +i" will update the i's version
+ from 2.0 to the default one according to the chosen isa spec.
+
+ bfd/
+ * elfxx-riscv.c (riscv_add_subset): If the subset is already added,
+ and the new versions are not RISCV_UNKNOWN_VERSION, then update the
+ versions to the subset list.
+ (riscv_copy_subset): New function. Copy the subset from list.
+ (riscv_copy_subset_list): New function. Return the new copyed list.
+ (riscv_update_subset): Updated to make .option arch directives workable.
+ * elfxx-riscv.h: Updated.
+ gas/
+ * config/tc-riscv.c (riscv_subsets): Defined as a pointer.
+ (riscv_rps_as): Init the subset_list to NULL, we will set it later
+ once riscv_opts_stack is created or updated.
+ (struct riscv_option_stack, riscv_opts_stack): Moved forward.
+ (riscv_set_arch): Updated.
+ (s_riscv_option): Support new .option arch directive, to add, remove
+ or update subsets for the specific code region.
+ (riscv_write_out_attrs): Updated.
+ * doc/c-riscv.texi: Added document for new .option arch directive.
+ * testsuite/gas/riscv/option-arch-01a.d: New testcase.
+ * testsuite/gas/riscv/option-arch-01b.d: Likewise.
+ * testsuite/gas/riscv/option-arch-01.s: Likewise..
+ * testsuite/gas/riscv/option-arch-02.d: Likewise.
+ * testsuite/gas/riscv/option-arch-02.s: Likewise.
+ * testsuite/gas/riscv/option-arch-fail.d: Likewise.
+ * testsuite/gas/riscv/option-arch-fail.l: Likewise.
+ * testsuite/gas/riscv/option-arch-fail.s: Likewise.
+
+2021-11-19 Alan Modra <amodra@gmail.com>
+
+ Re: Add multibyte character warning option to the assembler.
+ On hppa*-hp-hpux* run_dump_test edits the test file, adjusting .comm
+ directives to suit those target's unusual syntax. Thus gas is passed
+ a temporary file name.
+
+ * testsuite/gas/all/multibyte1.l: Ignore file name.
+
+2021-11-19 Mike Frysinger <vapier@gentoo.org>
+
+ sim: install various doc files
+
+2021-11-19 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Support STO_RISCV_VARIANT_CC and DT_RISCV_VARIANT_CC.
+ This is the original discussion,
+ https://github.com/riscv/riscv-elf-psabi-doc/pull/190
+
+ And here is the glibc part,
+ https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html
+
+ For binutils part, we need to support a new direcitve: .variant_cc.
+ The function symbol marked by .variant_cc means it need to be resolved
+ directly without resolver for dynamic linker. We also add a new dynamic
+ entry, STO_RISCV_VARIANT_CC, to indicate there are symbols with the
+ special attribute in the dynamic symbol table of the object.
+
+ I heard that llvm already have supported this in their mainline, so
+ I think it's time to commit this.
+
+ bfd/
+ * elfnn-riscv.c (riscv_elf_link_hash_table): Added variant_cc
+ flag. It is used to check if relocations for variant CC symbols
+ may be present.
+ (allocate_dynrelocs): If the symbol has STO_RISCV_VARIANT_CC
+ flag, then raise the variant_cc flag of riscv_elf_link_hash_table.
+ (riscv_elf_size_dynamic_sections): Added dynamic entry for
+ variant_cc.
+ (riscv_elf_merge_symbol_attribute): New function, used to merge
+ non-visibility st_other attributes, including STO_RISCV_VARIANT_CC.
+ binutils/
+ * readelf.c (get_riscv_dynamic_type): New function.
+ (get_dynamic_type): Called get_riscv_dynamic_type for riscv targets.
+ (get_riscv_symbol_other): New function.
+ (get_symbol_other): Called get_riscv_symbol_other for riscv targets.
+ gas/
+ * config/tc-riscv.c (s_variant_cc): Marked symbol that it follows a
+ variant CC convention.
+ (riscv_elf_copy_symbol_attributes): Same as elf_copy_symbol_attributes,
+ but without copying st_other. If a function symbol has special st_other
+ value set via directives, then attaching an IFUNC resolver to that symbol
+ should not override the st_other setting.
+ (riscv_pseudo_table): Support variant_cc diretive.
+ * config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Defined.
+ * testsuite/gas/riscv/variant_cc-set.d: New testcase.
+ * testsuite/gas/riscv/variant_cc-set.s: Likewise.
+ * testsuite/gas/riscv/variant_cc.d: Likewise.
+ * testsuite/gas/riscv/variant_cc.s: Likewise.
+ include/
+ * elf/riscv.h (DT_RISCV_VARIANT_CC): Defined to (DT_LOPROC + 1).
+ (STO_RISCV_VARIANT_CC): Defined to 0x80.
+ ld/
+ * testsuite/ld-riscv-elf/variant_cc-1.s: New testcase.
+ * testsuite/ld-riscv-elf/variant_cc-2.s: Likewise.
+ * testsuite/ld-riscv-elf/variant_cc-now.d: Likewise.
+ * testsuite/ld-riscv-elf/variant_cc-r.d: Likewise.
+ * testsuite/ld-riscv-elf/variant_cc-shared.d: Likewise.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-11-19 Mike Frysinger <vapier@gentoo.org>
+
+ sim: use program_transform_name for libsim
+ Instead of always using target_alias as a prefix on the name, use
+ program_transform_name instead so that the library is scoped in the
+ same way as the run program.
+
+ sim: avoid installing headers when there is no sim
+ If we aren't building any sims, don't install the sim headers as they
+ won't be useful to anyone.
+
+2021-11-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-18 Kevin Buettner <kevinb@redhat.com>
+
+ dprintf-execution-x-script.exp: Adjust test for native-extended-gdbserver
+ Without this commit, doing...
+
+ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
+ TESTS="gdb.base/dprintf-execution-x-script.exp"
+
+ ...will show one failure.
+
+ Here's a snippet from gdb.log showing the circumstances - I've trimmed
+ the paths for readability:
+
+ builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
+ ...
+ Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
+ Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
+ Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
+ testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
+ Don't know how to run. Try "help target".
+ (gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
+ ...
+ GNU gdb (GDB) 12.0.50.20211118-git
+ Copyright (C) 2021 Free Software Foundation, Inc.
+ ...
+ (gdb) set height 0
+ (gdb) set width 0
+ (gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
+ Listening on port 2346
+ target extended-remote localhost:2346
+ Remote debugging using localhost:2346
+ ...
+ [Tests after this point will pass.]
+
+ Note that the command which spawns gdb prevents the gdb script from
+ using the native target via "-iex set auto-connect-native-target off".
+
+ Moreover, the script in question contains a "run" command, so GDB
+ doesn't know how to run (since it's prevented from using the native
+ target and no alternate "target" command has been issued. But, once
+ GDB finishes starting up, the test will spawn a gdbserver and then
+ connect to it. The other (two) tests after this point both pass.
+
+ I've fixed this by using gdb_test_multiple instead of gdb_test.
+ When a "Don't know how to run message" is received, the test is
+ unsupported.
+
+ I've also added a comment explaining the reason for needing to check
+ for "Don't know how to run" despite bailing out at the top of the test
+ via:
+
+ if ![target_can_use_run_cmd] {
+ return 0
+ }
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix array-view-selftests.c build with g++ 4.8
+ When building with g++ 4.8, I get:
+
+ CXX unittests/array-view-selftests.o
+ /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:123:42: error: expected 'class' before 'Container'
+ template<template<typename ...> typename Container>
+ ^
+
+ I am no C++ template expert, but it looks like if I change "typename" for
+ "class", as the compiler kind of suggests, the code compiles.
+
+ Change-Id: I9c3edd29fb2b190069f0ce0dbf3bc3604d175f48
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix ia64-tdep.c build with g++ 4.8
+ When building with g++ 4.8, I get:
+
+ CXX ia64-tdep.o
+ /home/smarchi/src/binutils-gdb/gdb/ia64-tdep.c:3862:1: error: could not convert '{ia64_allocate_new_rse_frame, ia64_store_argument_in_slot, ia64_set_function_addr}' from '<brace
+ -enclosed initializer list>' to 'const ia64_infcall_ops'
+ };
+ ^
+
+ This happens since commit 345bd07cce3 ("gdb: fix gdbarch_tdep ODR
+ violation"), which added default values for ia64_infcall_ops fields. It
+ looks like g++ 4.8 doesn't like initializing the ia64_infcall_ops object
+ using the brace-enclosed initializer list when the ia64_infcall_ops
+ fields are assigned default values.
+
+ Later compilers don't have a problem with that, so I suppose that the
+ code is correct, but still, change it to make gcc 4.8 happy. Don't
+ initialize the fields of ia64_infcall_ops directly, instead
+ default-initialize ia64_gdbarch_tdep::infcall_ops.
+
+ Change-Id: I35e3a61abd7b7bbcafe6cb207078c738c5266d76
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: move AIX_TEXT_SEGMENT_BASE to rs6000-aix-tdep.c, remove rs6000-tdep.h
+ The contents of rs6000-tdep.h (AIX_TEXT_SEGMENT_BASE) is AIX-specific,
+ so I thought that this file should be named rs6000-aix-tdep.h. But
+ there's already a rs6000-aix-tdep.h, so then I though
+ AIX_TEXT_SEGMENT_BASE should simply be moved there, and rs6000-tdep.h
+ deleted. But then I realized that AIX_TEXT_SEGMENT_BASE is only used in
+ rs6000-aix-tdep.c, so move it to the beginning of that file.
+
+ Change-Id: Ia212c6fae202f31aedb46575821cd642beeda7a3
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: rename rs6000-nat.c to rs6000-aix-nat.c
+ This file seems to be AIX-specific, according to its contents and
+ configure.nat. Rename it to rs6000-aix-nat.c, to make that clear (and
+ to follow the convention).
+
+ Change-Id: Ib418dddc6b79b2e28f64431121742b5e87f5f4f5
+
+2021-11-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/doc] Fix negative repeat count examining memory example
+ The documentation for the examining memory command x contains an example:
+ ...
+ You can also specify a negative repeat count to examine memory backward from
+ the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h)
+ at 0x54314, 0x54328, and 0x5431c.
+ ...
+
+ The 0x54328 looks like a typo, which was intended to be 0x54318.
+
+ But the series uses a 4-byte distance, while the halfword size used in the
+ command means a 2-byte distance, so the series should be:
+ ...
+ 0x5431a, 0x5431c, and 0x5431e.
+ ...
+
+ Fix this by updating the addresses in the example accordingly.
+
+ Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html
+ ).
+
+2021-11-18 Nick Clifton <nickc@redhat.com>
+
+ Add multibyte character warning option to the assembler.
+ * as.c (parse_args): Add support for --multibyte-handling.
+ * as.h (multibyte_handling): Declare.
+ * app.c (scan_for_multibyte_characters): New function.
+ (do_scrub_chars): Call the new function if multibyte warning is
+ enabled.
+ * input-scrub,c (input_scrub_next_buffer): Call the multibyte
+ scanning function if multibyte warnings are enabled.
+ * symbols.c (struct symbol_flags): Add multibyte_warned bit.
+ (symbol_init): Call the multibyte scanning function if multibyte
+ symbol warnings are enabled.
+ (S_SET_SEGMENT): Likewise.
+ * NEWS: Mention the new feature.
+ * doc/as.texi: Document the new feature.
+ * testsuite/gas/all/multibyte.s: New test source file.
+ * testsuite/gas/all/multibyte1.d: New test driver file.
+ * testsuite/gas/all/multibyte1.l: New test expected output.
+ * testsuite/gas/all/multibyte2.d: New test driver file.
+ * testsuite/gas/all/multibyte2.l: New test expected output.
+ * testsuite/gas/all/gas.exp: Run the new tests.
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: include gdbarch.h in all files extending gdbarch_tdep
+ Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") made a bunch
+ of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep
+ base. But some of these files don't include gdbarch.h, where
+ gdbarch_tdep is defined. This may cause build errors if gdbarch.h isn't
+ already included by chance by some other header file. Avoid this by
+ making them include gdbarch.h.
+
+ Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a
+
+2021-11-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: make gdb_assert_not_reached accept a format string
+ Change gdb_assert_not_reached to accept a format string plus
+ corresponding arguments. This allows giving more precise messages.
+
+ Because the format string passed by the caller is prepended with a "%s:"
+ to add the function name, the callers can no longer pass a translated
+ string (`_(...)`). Make the gdb_assert_not_reached include the _(),
+ just like the gdb_assert_fail macro just above.
+
+ Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
+
+2021-11-18 Carl Love <cel@us.ibm.com>
+
+ gdb fix for catch-syscall.exp
+ Remove check_continue "execve" from Proc test_catch_syscall_execve.
+
+ The check_continue proceedure checs that the command, execve, starts and
+ checks for the return from the command. The execve command starts a new
+ program and thus the return from the command causing the test to fail.
+
+ The call to proc check_continue "execve" is removed and replaced with
+ just the call to check_call_to_syscall "execve" to verify the command
+ executed. The next test in proc test_catch_syscall_execve verifies that
+ the new program started and hit the break point in main.
+
+ Update the check for the PowerPC architecture. Power Little Endian systems
+ include "le" in the name. The istarget "power64-*-linux*" check fails to
+ match LE sytems. The expected string is updated to capture both Big Endian
+ and Little Endian systems. Power 10 LE istarget prints as:
+ powerpc64le-unknown-linux-gnu.
+
+ This patch fixes three failures and the error:
+
+ ERROR: can't read "arch1": no such variable
+
+ Patch tested on Power 10 ppc64le GNU/Linux platform.
+
+2021-11-18 Carl Love <cel@us.ibm.com>
+
+ gdb: PowerPC fix gdb.base/break-interp.exp
+ This patch fixes eight test failures on PowerPC for the test
+ gdb.base/break-interp.exp. The patch adds a funtion and registers it to
+ setup the displaced stepping for ppc-linux platform. The patch moves the
+ struct ppc_inferior_data to the ppc-tdep.h include file to make it visible
+ to the ppc-linux-tdep.c and rs6000-tdep.c files. Additionally the function
+ get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in
+ both files.
+
+ Tested on Power 10 ppc64le-linux with no regressions.
+
+2021-11-18 Carl Love <cel@us.ibm.com>
+
+ gdb fix PowerPC test gdb.arch/ppc-longdouble.exp
+ The test complains of duplicate tests.
+
+ DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return
+
+ The do_test calls gdb_continue_to_breakpoint "return". The duplicates
+ are the result of calling do_test three times with different arguments.
+
+ This patch fixes the duplicate tests by adding $name to the
+ gdb_continue_to_breakpoint argument.
+
+ Patch tested on Power 10 ppc64le GNU/Linux, no duplicate tests reported,
+ no new regression errors.
+
+2021-11-18 H.J. Lu <hjl.tools@gmail.com>
+
+ elf/x86: Issue an error on discarded output .plt section
+ Issue an error, instead of crash, on discarded output .plt section.
+
+ bfd/
+
+ PR ld/28597
+ * elf32-i386.c (elf_i386_finish_dynamic_sections): Issue an error
+ on discarded output .plt section.
+ * elf64-x86-64.c (elf_x86_64_finish_dynamic_sections): Likewise.
+
+ ld/
+
+ PR ld/28597
+ * testsuite/ld-elf/pr28597.d: New file.
+ * testsuite/ld-elf/pr28597.s: Likewise.
+ * testsuite/ld-elf/pr28597.t: Likewise.
+
+2021-11-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing wait in gdb.base/signals-state-child.exp
+ On OBS I ran into:
+ ...
+ (gdb) shell diff -s outputs/gdb.base/signals-state-child/standalone.txt \
+ outputs/gdb.base/signals-state-child/gdb.txt^M
+ diff: outputs/gdb.base/signals-state-child/standalone.txt: \
+ No such file or directory^M
+ (gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
+ ...
+
+ I managed to reproduce this by adding "sleep (5)" at the start of main in
+ signals-state-child.c.
+
+ Fix this by waiting on the result of the spawned command.
+
+ Tested on x86_64-linux.
+
+2021-11-18 Alan Modra <amodra@gmail.com>
+
+ Re: Don't compile some opcodes files when bfd is 32-bit only
+ Put bpf back in the 32-bit targets, even though bpf requires a 64-bit
+ bfd. bpf sim support apparently works without being 64-bit.
+
+ * Makefile.am (TARGET64_LIBOPCODES_CFILES): Move bpf files..
+ (TARGET32_LIBOPCODES_CFILES): ..to here.
+ * Makefile.in: Regenerate.
+
+2021-11-18 Alan Modra <amodra@gmail.com>
+
+ Pass DEBUGINFOD_CFLAGS when compiling dwarf.c
+ Pick up the elfutils/debuginfod.h install location -I flags from
+ a variable set by debuginfod.m4 (via pkg.m4 and pkg-config).
+
+ * Makefile.am (DEBUGINFOD_CFLAGS): Define.
+ (dwarf.@OBJECT@): New rule.
+
+2021-11-18 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Add testcases for z[fdq]inx
+ Use gpr when the zfinx enable, the testcases contain float
+ instructions that reuse by z[fdq]inx.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/riscv/zdinx.d: New test.
+ * testsuite/gas/riscv/zdinx.s: New test.
+ * testsuite/gas/riscv/zfinx.d: New test.
+ * testsuite/gas/riscv/zfinx.s: New test.
+ * testsuite/gas/riscv/zqinx.d: New test.
+ * testsuite/gas/riscv/zqinx.s: New test.
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Add instructions and operand set for z[fdq]inx
+ Reuse float instructions in INSN_CLASS_F/D/Q, use riscv_subset_supports to
+ verify if z*inx enabled and use gpr instead of fpr when z*inx is enable.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_multi_subset_supports): Added support for
+ z*inx extension.
+
+ gas/ChangeLog:
+
+ * config/tc-riscv.c (riscv_ip): Added register choice for z*inx.
+
+ include/ChangeLog:
+
+ * opcode/riscv.h (enum riscv_insn_class): Reused INSN_CLASS_* for z*inx.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_insn): Added disassemble check for
+ z*inx.
+ * riscv-opc.c: Reused INSN_CLASS_* for z*inx.
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Add mininal support for z[fdq]inx
+ Minimal support for zfinx, zdinx, zqinx. Like f/d/q, the zqinx
+ imply zdinx and zdinx imply zfinx, where zfinx are not compatible
+ with f/d/q.
+
+ bfd/ChangeLog:
+
+ * elfxx-riscv.c (riscv_implicit_subsets): Added implicit rules
+ for z*inx extensions.
+ (riscv_supported_std_z_ext): Added entries for z*inx.
+ (riscv_parse_check_conflicts): Added conflict check for z*inx.
+
+ Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] SVE2 instructions added to support SME
+ This patch is adding new SVE2 instructions added to support SME extension.
+ The following SVE2 instructions are added by the SME architecture:
+ * PSEL,
+ * REVD, SCLAMP and UCLAMP.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_sme_pred_reg_with_index):
+ New parser.
+ (parse_operands): New parser.
+ * testsuite/gas/aarch64/sme-9-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-9-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-9-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-9.d: New test.
+ * testsuite/gas/aarch64/sme-9.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New operand
+ AARCH64_OPND_SME_PnT_Wm_imm.
+
+ opcodes/ChangeLog:
+
+ * aarch64-asm.c (aarch64_ins_sme_pred_reg_with_index):
+ New inserter.
+ * aarch64-dis.c (aarch64_ext_sme_pred_reg_with_index):
+ New extractor.
+ * aarch64-opc.c (aarch64_print_operand): Printout of
+ OPND_SME_PnT_Wm_imm.
+ * aarch64-opc.h (enum aarch64_field_kind): New bitfields
+ FLD_SME_Rm, FLD_SME_i1, FLD_SME_tszh, FLD_SME_tszl.
+ * aarch64-tbl.h (OP_SVE_NN_BHSD): New qualifier.
+ (OP_SVE_QMQ): New qualifier.
+ (struct aarch64_opcode): New instructions PSEL, REVD,
+ SCLAMP and UCLAMP.
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add new SME system registers
+ This patch is adding miscellaneous SME related system registers.
+
+ gas/ChangeLog:
+
+ * testsuite/gas/aarch64/sme-sysreg.d: New test.
+ * testsuite/gas/aarch64/sme-sysreg.s: New test.
+ * testsuite/gas/aarch64/sme-sysreg-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-sysreg-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-sysreg-illegal.s: New test.
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.c: New system registers id_aa64smfr0_el1,
+ smcr_el1, smcr_el12, smcr_el2, smcr_el3, smpri_el1,
+ smprimap_el2, smidr_el1, tpidr2_el0 and mpamsm_el1.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add SME mode selection and state access instructions
+ This patch is adding new SME mode selection and state access instructions:
+ * Add SMSTART and SMSTOP instructions.
+ * Add SVCR system register.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_sme_sm_za): New parser.
+ (parse_operands): New parser.
+ * testsuite/gas/aarch64/sme-8-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-8-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-8-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-8.d: New test.
+ * testsuite/gas/aarch64/sme-8.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New operand
+ AARCH64_OPND_SME_SM_ZA.
+ (enum aarch64_insn_class): New instruction classes
+ sme_start and sme_stop.
+
+ opcodes/ChangeLog:
+
+ * aarch64-asm.c (aarch64_ins_pstatefield): New inserter.
+ (aarch64_ins_sme_sm_za): New inserter.
+ * aarch64-dis.c (aarch64_ext_imm): New extractor.
+ (aarch64_ext_pstatefield): New extractor.
+ (aarch64_ext_sme_sm_za): New extractor.
+ * aarch64-opc.c (operand_general_constraint_met_p):
+ New pstatefield value for SME instructions.
+ (aarch64_print_operand): Printout for OPND_SME_SM_ZA.
+ (SR_SME): New register SVCR.
+ * aarch64-opc.h (F_REG_IN_CRM): New register endcoding.
+ * aarch64-opc.h (F_IMM_IN_CRM): New immediate endcoding.
+ (PSTATE_ENCODE_CRM): Encode CRm field.
+ (PSTATE_DECODE_CRM): Decode CRm field.
+ (PSTATE_ENCODE_CRM_IMM): Encode CRm immediate field.
+ (PSTATE_DECODE_CRM_IMM): Decode CRm immediate field.
+ (PSTATE_ENCODE_CRM_AND_IMM): Encode CRm and immediate
+ field.
+ * aarch64-tbl.h (struct aarch64_opcode): New SMSTART
+ and SMSTOP instructions.
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add LD1x, ST1x, LDR and STR instructions
+ This patch is adding new loads and stores defined by SME instructions.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_sme_address): New parser.
+ (parse_sme_za_hv_tiles_operand_with_braces): New parser.
+ (parse_sme_za_array): New parser.
+ (output_operand_error_record): Print error details if
+ present.
+ (parse_operands): Support new operands.
+ * testsuite/gas/aarch64/sme-5-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-5-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-5-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-5.d: New test.
+ * testsuite/gas/aarch64/sme-5.s: New test.
+ * testsuite/gas/aarch64/sme-6-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-6-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-6-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-6.d: New test.
+ * testsuite/gas/aarch64/sme-6.s: New test.
+ * testsuite/gas/aarch64/sme-7-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-7-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-7-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-7.d: New test.
+ * testsuite/gas/aarch64/sme-7.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New operands.
+ (enum aarch64_insn_class): Added sme_ldr and sme_str.
+ (AARCH64_OPDE_UNTIED_IMMS): New operand error kind.
+
+ opcodes/ChangeLog:
+
+ * aarch64-asm.c (aarch64_ins_sme_za_hv_tiles): New inserter.
+ (aarch64_ins_sme_za_list): New inserter.
+ (aarch64_ins_sme_za_array): New inserter.
+ (aarch64_ins_sme_addr_ri_u4xvl): New inserter.
+ * aarch64-asm.h (AARCH64_DECL_OPD_INSERTER): Added
+ ins_sme_za_list, ins_sme_za_array and ins_sme_addr_ri_u4xvl.
+ * aarch64-dis.c (aarch64_ext_sme_za_hv_tiles): New extractor.
+ (aarch64_ext_sme_za_list): New extractor.
+ (aarch64_ext_sme_za_array): New extractor.
+ (aarch64_ext_sme_addr_ri_u4xvl): New extractor.
+ * aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR): Added
+ ext_sme_za_list, ext_sme_za_array and ext_sme_addr_ri_u4xvl.
+ * aarch64-opc.c (operand_general_constraint_met_p):
+ (aarch64_match_operands_constraint): Handle sme_ldr, sme_str
+ and sme_misc.
+ (aarch64_print_operand): New operands supported.
+ * aarch64-tbl.h (OP_SVE_QUU): New qualifier.
+ (OP_SVE_QZU): New qualifier.
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add ZERO instruction
+ This patch is adding ZERO (a list of 64-bit element ZA tiles)
+ instruction.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_sme_list_of_64bit_tiles):
+ New parser.
+ (parse_operands): Handle OPND_SME_list_of_64bit_tiles.
+ * testsuite/gas/aarch64/sme-4-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-4-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-4-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-4.d: New test.
+ * testsuite/gas/aarch64/sme-4.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New operand
+ AARCH64_OPND_SME_list_of_64bit_tiles.
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.c (print_sme_za_list): New printing function.
+ (aarch64_print_operand): Handle OPND_SME_list_of_64bit_tiles.
+ * aarch64-opc.h (enum aarch64_field_kind): New bitfield
+ FLD_SME_zero_mask.
+ * aarch64-tbl.h (struct aarch64_opcode): New ZERO instruction.
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add MOV and MOVA instructions
+ This patch is adding new MOV (alias) and MOVA SME instruction.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (enum sme_hv_slice): new enum.
+ (struct reloc_entry): Added ZAH and ZAV registers.
+ (parse_sme_immediate): Immediate parser.
+ (parse_sme_za_hv_tiles_operand): ZA tile parser.
+ (parse_sme_za_hv_tiles_operand_index): Index parser.
+ (parse_operands): Added ZA tile parser calls.
+ (REGNUMS): New macro. Regs with suffix.
+ (REGSET16S): New macro. 16 regs with suffix.
+ * testsuite/gas/aarch64/sme-2-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-2-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-2-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-2.d: New test.
+ * testsuite/gas/aarch64/sme-2.s: New test.
+ * testsuite/gas/aarch64/sme-2a.d: New test.
+ * testsuite/gas/aarch64/sme-2a.s: New test.
+ * testsuite/gas/aarch64/sme-3-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-3-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-3-illegal.s: New test.
+ * testsuite/gas/aarch64/sme-3.d: New test.
+ * testsuite/gas/aarch64/sme-3.s: New test.
+ * testsuite/gas/aarch64/sme-3a.d: New test.
+ * testsuite/gas/aarch64/sme-3a.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New enums
+ AARCH64_OPND_SME_ZA_HV_idx_src and
+ AARCH64_OPND_SME_ZA_HV_idx_dest.
+ (struct aarch64_opnd_info): New ZA tile vector struct.
+
+ opcodes/ChangeLog:
+
+ * aarch64-asm.c (aarch64_ins_sme_za_hv_tiles):
+ New inserter.
+ * aarch64-asm.h (AARCH64_DECL_OPD_INSERTER):
+ New inserter ins_sme_za_hv_tiles.
+ * aarch64-dis.c (aarch64_ext_sme_za_hv_tiles):
+ New extractor.
+ * aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR):
+ New extractor ext_sme_za_hv_tiles.
+ * aarch64-opc.c (aarch64_print_operand):
+ Handle SME_ZA_HV_idx_src and SME_ZA_HV_idx_dest.
+ * aarch64-opc.h (enum aarch64_field_kind): New enums
+ FLD_SME_size_10, FLD_SME_Q, FLD_SME_V and FLD_SME_Rv.
+ (struct aarch64_operand): Increase fields size to 5.
+ * aarch64-tbl.h (OP_SME_BHSDQ_PM_BHSDQ): New qualifiers
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add SME instructions
+ Patch is adding new SME matrix instructions. Please note additional
+ instructions will be added in following patches.
+
+ gas/ChangeLog:
+
+ * config/tc-aarch64.c (parse_sme_zada_operand):
+ New parser.
+ * config/tc-aarch64.c (parse_reg_with_qual):
+ New reg parser.
+ * config/tc-aarch64.c (R_ZA): New egister type.
+ (parse_operands): New parser.
+ * testsuite/gas/aarch64/sme-illegal.d: New test.
+ * testsuite/gas/aarch64/sme-illegal.l: New test.
+ * testsuite/gas/aarch64/sme-illegal.s: New test.
+ * testsuite/gas/aarch64/sme.d: New test.
+ * testsuite/gas/aarch64/sme.s: New test.
+ * testsuite/gas/aarch64/sme-f64.d: New test.
+ * testsuite/gas/aarch64/sme-f64.s: New test.
+ * testsuite/gas/aarch64/sme-i64.d: New test.
+ * testsuite/gas/aarch64/sme-i64.s: New test.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (enum aarch64_opnd): New operands
+ AARCH64_OPND_SME_ZAda_2b, AARCH64_OPND_SME_ZAda_3b and
+ AARCH64_OPND_SME_Pm.
+ (enum aarch64_insn_class): New instruction class sme_misc.
+
+ opcodes/ChangeLog:
+
+ * aarch64-opc.c (aarch64_print_operand):
+ Print OPND_SME_ZAda_2b and OPND_SME_ZAda_3b operands.
+ (verify_constraints): Handle OPND_SME_Pm.
+ * aarch64-opc.h (enum aarch64_field_kind):
+ New bit fields FLD_SME_ZAda_2b, FLD_SME_ZAda_3b and FLD_SME_Pm.
+ * aarch64-tbl.h (OP_SME_ZADA_PN_PM_ZN_S): New qualifier set.
+ (OP_SME_ZADA_PN_PM_ZN_D): New qualifier.
+ (OP_SME_ZADA_PN_PM_ZN_ZM): New qualifier.
+ (OP_SME_ZADA_S_PM_PM_S_S): New qualifier.
+ (OP_SME_ZADA_D_PM_PM_D_D): New qualifier.
+ (OP_SME_ZADA_S_PM_PM_H_H): New qualifier.
+ (OP_SME_ZADA_S_PM_PM_B_B): New qualifier.
+ (OP_SME_ZADA_D_PM_PM_H_H): New qualifier.
+ (SME_INSN): New instruction macro.
+ (SME_F64_INSN): New instruction macro.
+ (SME_I64_INSN): New instruction macro.
+ (SME_INSNC): New instruction macro.
+ (struct aarch64_opcode): New SME instructions.
+ aarch64-asm-2.c: Regenerate.
+ aarch64-dis-2.c: Regenerate.
+ aarch64-opc-2.c: Regenerate.
+
+2021-11-17 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: [SME] Add +sme option to -march
+ This series of patches (tagged [SME]) add support for the Scalable
+ Matrix Extension. Patch introduces new command line options: +sme, +sme-f64 and
+ +sme-i64 to -march command line options.
+
+ gas/ChangeLog:
+
+ * NEWS: Updated docs.
+ * config/tc-aarch64.c: New SME command line options.
+ * doc/c-aarch64.texi: Update docs.
+
+ include/ChangeLog:
+
+ * opcode/aarch64.h (AARCH64_FEATURE_SME): New flag.
+ (AARCH64_FEATURE_SME_F64): New flag.
+ (AARCH64_FEATURE_SME_I64): New flag.
+
+ opcodes/ChangeLog:
+
+ * aarch64-tbl.h (SME): New feature object.
+
+2021-11-17 Jeremy Drake <cygwin@jdrake.com>
+
+ Set the default DLL chracteristics to 0 for Cygwin based targets.
+ * emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Set to 0 for
+ Cygwin targets.
+ * emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Likewise.
+
+2021-11-17 Nick Clifton <nickc@redhat.com>
+
+ Fix the linker script parser so that it will recognise the PT_GNU_RELRO segment type, and the linker itself so that it will gracefully handle being unable to assign any sections to such a segment.
+ PR 28452
+ bfd * elf.c (assign_file_positions_for_non_load_sections): Replace
+ assertion with a warning message.
+
+ ld * ldgram.y: Add support for PT_GNU_RELRO and PT_GNU_PROPERTY.
+ * ldgram.c: Regenerate.
+
+2021-11-17 Andreas Arnez <arnez@linux.ibm.com>
+
+ [gdb/build, s390x] Fix build after gdbarch_tdep changes
+ Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") changes a
+ declaration in s390-tdep.h from
+
+ struct gdbarch_tdep { ... };
+
+ to
+
+ struct s390_gdbarch_tdep : gdbarch_tdep { ... };
+
+ and now requires that gdbarch_tdep has been declared before. Which is
+ usually the case, except when compiling s390-linux-nat.c, where
+ s390-tdep.h is included before gdbarch.h. Thus the s390x build errors out
+ with the compiler complaining about a missing class name after the colon.
+
+ Fix this in s390-linux-nat.c, by including gdbarch.h before s390-tdep.h.
+
+2021-11-17 Luis Machado <luis.machado@linaro.org>
+
+ Expose the BTI BTYPE more explicitly in the registers
+ Augment the register description XML to expose the BTI BTYPE field contained
+ in the CPSR register. It will be displayed like so:
+
+ cpsr 0x60001000 [ EL=0 BTYPE=0 SSBS C Z ]
+
+2021-11-17 H.J. Lu <hjl.tools@gmail.com>
+
+ elfedit: Add --output-abiversion option to update ABIVERSION
+ * NEWS: Mention --output-abiversion.
+ * elfedit.c (input_elf_abiversion): New.
+ (output_elf_abiversion): Likewise.
+ (update_elf_header): Update EI_ABIVERSION.
+ (command_line_switch): Add OPTION_INPUT_ABIVERSION and
+ OPTION_OUTPUT_ABIVERSION.
+ (options): Add --input-abiversion and --output-abiversion.
+ (usage): Likewise.
+ (main): Handle --input-abiversion and --output-abiversion.
+ * doc/binutils.texi: Document --input-abiversion and
+ --output-abiversion.
+ * testsuite/binutils-all/elfedit.exp: Run elfedit-6.
+ * testsuite/binutils-all/elfedit-6.d: New file.
+
+2021-11-17 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Support rvv extension with released version 1.0.
+ 2021-11-17 Jim Wilson <jimw@sifive.com>
+ Kito Cheng <kito.cheng@sifive.com>
+ Nelson Chu <nelson.chu@sifive.com>
+
+ This patch is porting from the following riscv github,
+ https://github.com/riscv/riscv-binutils-gdb/tree/rvv-1.0.x
+
+ And here is the vector spec,
+ https://github.com/riscv/riscv-v-spec
+
+ bfd/
+ * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules
+ of v, zve and zvl extensions.
+ (riscv_supported_std_ext): Updated verison of v to 1.0.
+ (riscv_supported_std_z_ext): Added zve and zvl extensions.
+ (riscv_parse_check_conflicts): The zvl extensions need to
+ enable either v or zve extension.
+ (riscv_multi_subset_supports): Check the subset list to know
+ if the INSN_CLASS_V and INSN_CLASS_ZVEF instructions are supported.
+ gas/
+ * config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_V.
+ (enum reg_class): Added RCLASS_VECR and RCLASS_VECM.
+ (validate_riscv_insn): Check whether the rvv operands are valid.
+ (md_begin): Initialize register hash for rvv registers.
+ (macro_build): Added rvv operands when expanding rvv pseudoes.
+ (vector_macro): Expand rvv macros into one or more instructions.
+ (macro): Likewise.
+ (my_getVsetvliExpression): Similar to my_getVsetvliExpression,
+ but used for parsing vsetvli operands.
+ (riscv_ip): Parse and encode rvv operands. Besides, The rvv loads
+ and stores with EEW 64 cannot be used when zve32x is enabled.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated -march
+ to rv32ifv_zkr.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/priv-reg.s: Added rvv csr testcases.
+ * testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/march-imply-v.d: New testcase.
+ * testsuite/gas/riscv/vector-insns-fail-zve32xf.d: Likewise.
+ * testsuite/gas/riscv/vector-insns-fail-zve32xf.l: Likewise.
+ * testsuite/gas/riscv/vector-insns-fail-zvl.d: Likewise.
+ * testsuite/gas/riscv/vector-insns-fail-zvl.l: Likewise.
+ * testsuite/gas/riscv/vector-insns-vmsgtvx.d: Likewise.
+ * testsuite/gas/riscv/vector-insns-vmsgtvx.s: Likewise.
+ * testsuite/gas/riscv/vector-insns-zero-imm.d: Likewise.
+ * testsuite/gas/riscv/vector-insns-zero-imm.s: Likewise.
+ * testsuite/gas/riscv/vector-insns.d: Likewise.
+ * testsuite/gas/riscv/vector-insns.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Defined mask/match encodings and csrs for rvv.
+ * opcode/riscv.h: Defined rvv immediate encodings and fields.
+ (enum riscv_insn_class): Added INSN_CLASS_V and INSN_CLASS_ZVEF.
+ (INSN_V_EEW64): Defined.
+ (M_VMSGE, M_VMSGEU): Added for the rvv pseudoes.
+ opcodes/
+ * riscv-dis.c (print_insn_args): Dump the rvv operands.
+ * riscv-opc.c (riscv_vecr_names_numeric): Defined rvv registers.
+ (riscv_vecm_names_numeric): Likewise.
+ (riscv_vsew): Likewise.
+ (riscv_vlmul): Likewise.
+ (riscv_vta): Likewise.
+ (riscv_vma): Likewise.
+ (match_vs1_eq_vs2): Added for rvv Vu operand.
+ (match_vd_eq_vs1_eq_vs2): Added for rvv Vv operand.
+ (riscv_opcodes): Added rvv v1.0 instructions.
+
+2021-11-17 Sergei Trofimovich <siarheit@google.com>
+
+ gdb/nat/linux-osdata.c: fix build on gcc-12 (string overfow)
+ On gcc-12 build fails as:
+
+ ../../gdbserver/../gdb/nat/linux-osdata.c: In function 'void linux_xfer_osdata_processes(buffer*)':
+ ../../gdbserver/../gdb/nat/linux-osdata.c:330:39: error:
+ '__builtin___sprintf_chk' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
+ 330 | sprintf (core_str, "%d", i);
+ | ^
+
+ It's an off-by-one case in an infeasible scenario for negative
+ huge core count. The change switches to std::string for memory
+ handling.
+
+ Tested by running 'info os processes' and checking CPU cores column.
+
+2021-11-17 Aaron Merey <amerey@redhat.com>
+
+ gdb: Add aliases for read_core_file_mappings callbacks
+ Add aliases read_core_file_mappings_loop_ftype and
+ read_core_file_mappings_pre_loop_ftype. Intended for use with
+ read_core_file_mappings.
+
+ Also add build_id parameter to read_core_file_mappings_loop_ftype.
+
+2021-11-17 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: add support for $pwd replacements
+ Extend the common test framework to support $pwd replacements in
+ settings. This allows replacing the custom cris @exedir@ with it.
+
+ sim: cris: replace @srcdir@ test extension with $srcdir/$subdir
+ The common framework supports $srcdir & $subdir replacements already,
+ so replace the custom @srcdir@ logic with those. Since the replace
+ happens in slurp_options that cris already uses, we don't have any
+ logic to port over there. We have to duplicate that into the cris
+ slurp_rv helper though.
+
+2021-11-17 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: drop custom "dynamic" test field
+ This tag is used to force tests to be built dynamically (i.e. without
+ -static linking). This is because cris-sim.exp in dejagnu turns on
+ static linking in ldflags.
+
+ The default configs and runtest flags shouldn't load these boards.
+ If these settings are still needed, we should figure out a different
+ way of suppressing the stock settings wholesale. We want these to
+ all pass out of the box with little to no configuration so that they
+ can run in a multitarget build.
+
+ With dropping "dynamic", it'll be easier to merge the custom cris
+ test logic with the common sim test logic.
+
+2021-11-17 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: add more silent build rules
+ site.exp is still verbose, but that comes from automake, so have
+ to get it fixed upstream.
+
+2021-11-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-16 Sergei Trofimovich <siarheit@google.com>
+
+ sim: cr16: fix build on gcc-12 (NULL comparison)
+ On gcc-12 build fails as:
+
+ sim/cr16/interp.c: In function 'lookup_hash':
+ sim/cr16/interp.c:89:25: error:
+ the comparison will always evaluate as 'true'
+ for the address of 'mnimonic' will never be NULL [-Werror=address]
+ 89 | if ((h->ops->mnimonic != NULL) &&
+ | ^~
+
+ 'mnimonic' is a sharr array within ops. It can never be NULL.
+
+ While at it renamed 'mnimonic' to 'mnemonic'.
+
+2021-11-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix length of array view returned by some value_contents functions
+ In commit 50888e42dcd3 ("gdb: change functions returning value contents
+ to use gdb::array_view"), I believe I made a mistake with the length of
+ the array views returned by some functions. All functions return a view
+ of `TYPE_LENGTH (value_type (type))` length. This is not correct when
+ the value's enclosing type is larger than the value's type. In that
+ case, the value's contents buffer is of the size of the enclosing type,
+ and the value's actual contents is a slice of that (as returned by
+ value_contents). So, functions value_contents_all_raw,
+ value_contents_for_printing and value_contents_for_printing_const are
+ not correct. Since they are meant to return the value's contents buffer
+ as a whole, they should have the size of the enclosing type.
+
+ There is nothing that uses the returned array view size at the moment,
+ so this didn't cause a problem. But it became apparent when trying to
+ adjust some callers.
+
+ Change-Id: Ib4e8837e1069111d2b2784d3253d5f3002419e68
+
+2021-11-16 Fangrui Song <maskray@google.com>
+
+ readelf: Support SHT_RELR/DT_RELR for -r
+ The -r output for SHT_RELR looks like:
+
+ Relocation section '.relr.dyn' at offset 0x530 contains 4 entries:
+ 7 offsets
+ 00000000000028c0
+ 00000000000028c8
+ 0000000000003ad0
+ 0000000000003ad8
+ 0000000000003ae0
+ 0000000000003ae8
+ 0000000000003af0
+
+ For --use-dynamic, the header looks like
+
+ 'RELR' relocation section at offset 0x530 contains 32 bytes:
+
+ include/
+ * elf/common.h (DT_ENCODING): Bump to 38.
+ * elf/external.h (Elf32_External_Relr): New.
+ (Elf64_External_Relr): New.
+ binutils/
+ * readelf.c (enum relocation_type): New.
+ (slurp_relr_relocs): New.
+ (dump_relocations): Change is_rela to rel_type.
+ Dump RELR.
+ (dynamic_relocations): Add DT_RELR.
+ (process_relocs): Check SHT_RELR and DT_RELR.
+ (process_dynamic_section): Store into dynamic_info for
+ DT_RELR/DT_RELRENT/DT_RELRSZ.
+
+2021-11-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: remove FUNCTION_NAME
+ __func__ is standard C++11:
+
+ https://en.cppreference.com/w/cpp/language/function
+
+ Also, in C++11, __func__ expands to the demangled function name, so the
+ mention in the comment above FUNCTION_NAME doesn't apply anymore.
+ Finally, in places where FUNCTION_NAME is used, I think it's enough to
+ print the function name, no need to print the whole signature.
+ Therefore, I propose to just remove FUNCTION_NAME and update users to
+ use the standard __func__.
+
+ Change-Id: I778f28155422b044402442dc18d42d0cded1017d
+
+2021-11-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
+ The motivation is to reduce the number of places where unmanaged
+ pointers are returned from allocation type routines. All of the
+ callers are updated.
+
+ There should be no user visible changes after this commit.
+
+2021-11-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdbsupport: move xfree into its own file
+ In the next commit I'd like to reference gdb_unique_ptr within the
+ common-utils.h file. However, this requires that I include
+ gdb_unique_ptr.h, which requires that xfree be defined.
+
+ Interestingly, gdb_unique_ptr.h doesn't actually include anything that
+ defines xfree, but I was finding that when I added a gdb_unique_ptr.h
+ include to common-utils.h I was getting a dependency cycle; before my
+ change xfree was defined when gdb_unique_ptr.h was processed, while
+ after my change it was not, and this made g++ unhappy.
+
+ To break this cycle, I propose to move xfree into its own header file,
+ gdb-xfree.h, which I'll then include into gdb_unique_ptr.h and
+ common-utils.cc.
+
+2021-11-16 Andrew Burgess <aburgess@redhat.com>
+
+ gdb: throw OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR
+ While reviewing this patch:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-November/183227.html
+
+ I spotted that the patch could be improved if we threw
+ OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR in a few places.
+
+ This commit updates error_value_optimized_out and
+ require_not_optimized_out to throw OPTIMIZED_OUT_ERROR.
+
+ I ran the testsuite and saw no regressions. This doesn't really
+ surprise me, we don't usually write code like:
+
+ catch (const gdb_exception_error &ex)
+ {
+ (if ex.error == GENERIC_ERROR)
+ ...
+ else
+ ...
+ }
+
+ There are a three places where we write something like:
+
+ catch (const gdb_exception_error &ex)
+ {
+ (if ex.error == OPTIMIZED_OUT_ERROR)
+ ...
+ }
+
+ In frame.c:unwind_pc, stack.c:info_frame_command_core, and
+ value.c:value_optimized_out, but if we are hitting these cases then
+ it's not significantly changing GDB's behaviour.
+
+2021-11-16 Tom Tromey <tromey@adacore.com>
+
+ Remove config.cache in gdbserver's "distclean"
+ PR gdb/28586 points out that "make distclean" fails to delete
+ config.cache from gdbserver/. This patch fixes the bug, and removes a
+ duplicate "Makefile" deletion that was also pointed out in the PR.
+
+2021-11-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove inferior output in gdb.base/foll-vfork.exp
+ Test-case gdb.base/foll-vfork.exp has inferior output that is not needed, but
+ which makes the regexp matching more difficult (see commit 1f28b70def1
+ "[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp").
+
+ Remove the inferior output, and revert commit 1f28b70def1 to make the matching
+ more restrictive.
+
+ Tested on x86_64-linux.
+
+2021-11-16 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Don't allow KMOV in TLS code sequences
+ Don't allow KMOV in TLS code sequences which require integer MOV
+ instructions.
+
+ PR target/28595
+ * config/tc-i386.c (match_template): Don't allow KMOV in TLS
+ code sequences.
+ * testsuite/gas/i386/i386.exp: Run inval-tls and x86-64-inval-tls
+ tests.
+ * testsuite/gas/i386/inval-tls.l: New file.
+ * testsuite/gas/i386/inval-tls.s: Likewise.
+ * testsuite/gas/i386/x86-64-inval-tls.l: Likewise.
+ * testsuite/gas/i386/x86-64-inval-tls.s: Likewise.
+
+2021-11-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: run: support concise env var settings
+ Support the same syntax as other common utilities where env vars can
+ be specified before the program to be run without an explicit option.
+
+ This behavior can be suppressed by using the -- marker.
+
+2021-11-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: nrun: add --env-{set,unset,clear} command line options
+ Provide explicit control over the program's environment with the
+ basic set/unset/clear options. These are a bit clunky to use,
+ but they're functional.
+
+ The env set operation is split out into a separate function as it'll
+ be used in the next commit.
+
+ With these in place, we can adjust the custom cris testsuite to use
+ the now standard options and not its one-off hack.
+
+2021-11-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: syscall: hoist argc/argn/argnlen to common code
+ Now that the callback framework supports argv & envp, we can move
+ the Blackfin implementation of these syscalls to the common code.
+
+ sim: syscall: fix argvlen & argv implementation
+ Now that we have access to the argv & envp strings, finish implementing
+ these syscalls. Delete unused variables, fix tbuf by incrementing the
+ pointer instead of setting to the length, and make sure we don't write
+ more data than the bufsize says is available.
+
+ sim: callback: expose argv & environ
+ Pass the existing strings data to the callbacks so that common
+ libgloss syscalls can be implemented (which we'll do shortly).
+
+2021-11-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: keep track of program environment strings
+ We've been passing the environment strings to sim_create_inferior,
+ but most ports don't do anything with them. A few will use ad-hoc
+ logic to stuff the stack for user-mode programs, but that's it.
+
+ Let's formalize this across the board by storing the strings in the
+ normal sim state. This will allow (in future commits) supporting
+ more functionality in the run interface, and to unify some of the
+ libgloss syscalls.
+
+2021-11-16 Mike Frysinger <vapier@gentoo.org>
+
+ sim: iq2000: fix some missing prototypes warnings
+ Turns out some of these were hiding real bugs like not passing the
+ pc variable down.
+
+2021-11-16 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Scalar crypto instruction and entropy source CSR testcases.
+ Add testcases for Scalar Crypto extension, with total testcase contain all
+ instructions in k-ext/k-ext-64 and sub-extension testcase for zbk* zk*. Also
+ add testcase for new CSR name 'seed' which is the Entropy Source in zkr.
+
+ In fact these whole testcases can be combined into one file, after we have
+ supported the .option arch +-= directives.
+
+ gas/
+ * testsuite/gas/riscv/k-ext-64.d: New testcase for crypto instructions.
+ * testsuite/gas/riscv/k-ext-64.s: Likewise.
+ * testsuite/gas/riscv/k-ext.d: Likewise.
+ * testsuite/gas/riscv/k-ext.s: Likewise.
+ * testsuite/gas/riscv/zbkb-32.d: Likewise.
+ * testsuite/gas/riscv/zbkb-32.s: Likewise.
+ * testsuite/gas/riscv/zbkb-64.d: Likewise.
+ * testsuite/gas/riscv/zbkb-64.s: Likewise.
+ * testsuite/gas/riscv/zbkc-32.d: Likewise.
+ * testsuite/gas/riscv/zbkc-64.d: Likewise.
+ * testsuite/gas/riscv/zbkc.s: Likewise.
+ * testsuite/gas/riscv/zbkx-32.d: Likewise.
+ * testsuite/gas/riscv/zbkx-64.d: Likewise.
+ * testsuite/gas/riscv/zbkx.s: Likewise.
+ * testsuite/gas/riscv/zknd-32.d: Likewise.
+ * testsuite/gas/riscv/zknd-32.s: Likewise.
+ * testsuite/gas/riscv/zknd-64.d: Likewise.
+ * testsuite/gas/riscv/zknd-64.s: Likewise.
+ * testsuite/gas/riscv/zkne-32.d: Likewise.
+ * testsuite/gas/riscv/zkne-32.s: Likewise.
+ * testsuite/gas/riscv/zkne-64.d: Likewise.
+ * testsuite/gas/riscv/zkne-64.s: Likewise.
+ * testsuite/gas/riscv/zknh-32.d: Likewise.
+ * testsuite/gas/riscv/zknh-32.s: Likewise.
+ * testsuite/gas/riscv/zknh-64.d: Likewise.
+ * testsuite/gas/riscv/zknh-64.s: Likewise.
+ * testsuite/gas/riscv/zksed-32.d: Likewise.
+ * testsuite/gas/riscv/zksed-64.d: Likewise.
+ * testsuite/gas/riscv/zksed.s: Likewise.
+ * testsuite/gas/riscv/zksh-32.d: Likewise.
+ * testsuite/gas/riscv/zksh-64.d: Likewise.
+ * testsuite/gas/riscv/zksh.s: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-zkr.d: New testcase for zkr
+ csr check.
+ * testsuite/gas/riscv/priv-reg-fail-zkr.l: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated march to
+ rv32if_zkr.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p10.d: Added Crypto seed csr.
+ * testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+ * testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+ * testsuite/gas/riscv/priv-reg.s: Likewise.
+
+2021-11-16 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Scalar crypto instructions and operand set.
+ Add instructions in k-ext, some instruction in zbkb, zbkc is reuse from
+ zbb,zbc, we just change the class attribute to make them both support.
+ The 'aes64ks1i' and 'aes64ks2' instructions are present in both the Zknd
+ and Zkne extensions on rv64. Add new operand letter 'y' to present 'bs'
+ symbol and 'Y' to present 'rnum' symbolc for zkn instructions. Also add
+ a new Entropy Source CSR define 'seed' located at address 0x015.
+
+ bfd/
+ * elfxx-riscv.c (riscv_multi_subset_supports): Added support for
+ crypto extension.
+ gas/
+ *config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_ZKR.
+ (riscv_csr_address): Checked for CSR_CLASS_ZKR.
+ (validate_riscv_insn): Added y and Y for bs and rnum operands.
+ (riscv_ip): Handle y and Y operands.
+ include/
+ * opcode/riscv-opc.h: Added encodings of crypto instructions.
+ Also defined new csr seed, which address is 0x15.
+ * opcode/riscv.h: Defined OP_* and INSN_CLASS_* for crypto.
+ opcodes/
+ * riscv-dis.c (print_insn_args): Recognized new y and Y operands.
+ * riscv-opc.c (riscv_opcodes): Added crypto instructions.
+
+2021-11-16 jiawei <jiawei@iscas.ac.cn>
+
+ RISC-V: Minimal support of scalar crypto extension.
+ Minimal support of scalar crypto extension, add "k" in the
+ riscv_supported_std_ext, to make the order check right with
+ "zk" behind "zb".
+
+ bfd/
+ * elfxx-riscv.c (riscv_implicit_subsets): Added implicit
+ rules for zk* extensions.
+ (riscv_supported_std_ext): Added entry for k.
+ (riscv_supported_std_z_ext): Added entries for zk*.
+
+2021-11-16 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: rework "set debuginfod" commands
+ As discussed here [1], do some re-work in the "set debuginfod commands".
+
+ First, use "set debuginfod enabled on/off/ask" instead of "set
+ debuginfod on/off/ask". This is more MI-friendly, and it gives an
+ output that makes more sense in "info set", for example.
+
+ Then, make the show commands not call "error" when debuginfod support is
+ not compiled in. This makes the commands "show" and "show debuginfod"
+ stop early, breaking gdb.base/default.exp:
+
+ Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ...
+ FAIL: gdb.base/default.exp: info set
+ FAIL: gdb.base/default.exp: show
+
+ - Make the "debuginfod enabled" setting default to "off" when debuginfod
+ support is not compiled in, and "ask" otherwise.
+ - Make the setter of "debuginfod enabled" error out when debuginfod
+ support is not compiled in, so that "debuginfod enabled" will always
+ remain "off" in that case.
+ - Make the setter of "debuginfod verbose" work in any case. I don't
+ see the harm in letting the user change that setting, since the user will
+ hit an error if they try to enable the use of debuginfod.
+ - I would do the same for the "debuginfod urls" setter, but because
+ this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by
+ libdebuginfod, I made that one error out as well if debuginfod
+ support is not compiled it (otherwise, I would have left it like
+ "debuginfod verbose". Alternatively, we could hard-code
+ "DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch,
+ but I think it was an oversight, as other spots use
+ DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting,
+ but I don't really see the value in that.
+
+ Rename debuginfod_enable to debuginfod_enabled, just so it matches the
+ setting name.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html
+
+ Change-Id: I45fdb2993f668226a5639228951362b7800f09d5
+ Co-Authored-By: Aaron Merey <amerey@redhat.com>
+
+2021-11-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: adjust gdbarch_tdep calls in nat files
+ Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") forgot to
+ update the gdbarch_tdep calls in the native files other than x86-64
+ Linux. This patch updates them all (to the best of my knowledge).
+ These are the files I was able to build-test:
+
+ aarch64-linux-nat.c
+ amd64-bsd-nat.c
+ arm-linux-nat.c
+ ppc-linux-nat.c
+ windows-nat.c
+ xtensa-linux-nat.c
+
+ And these are the ones I could not build-test:
+
+ aix-thread.c
+ arm-netbsd-nat.c
+ ppc-fbsd-nat.c
+ ppc-netbsd-nat.c
+ ia64-tdep.c (the part that needs libunwind)
+ ppc-obsd-nat.c
+ rs6000-nat.c
+
+ If there are still some build problems related to gdbarch_tdep in them,
+ they should be pretty obvious to fix.
+
+ Change-Id: Iaa3d791a850e4432973757598e634e3da6061428
+
+2021-11-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unused variables in xtensa-linux-nat.c
+ While build-testing this file, the compiler complained about these two
+ unused variables, remove them.
+
+ Change-Id: I3c54f779f12c16ef6184af58aca75eaad042ce4e
+
+2021-11-16 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add arc-newlib-tdep.c to ALL_TARGET_OBS
+ This file is currently not compiled in an --enable-targets=all build,
+ but it should be. Add it to ALL_TARGET_OBS.
+
+ Update the gdbarch_tdep call that commit 345bd07cce33 ("gdb: fix
+ gdbarch_tdep ODR violation") forgot to update.
+
+ Change-Id: I86248a01493eea5e70186e9c46a298ad3994b034
+
+2021-11-16 Jim Wilson <wilson@tuliptree.org>
+
+ Update my email address.
+ I've left SiFive and have a new gmail account because it is convenient
+ to use with git send-email. I'm planning to use this for my RISC-V
+ work. My tuliptree address still works, it just isn't as convenient.
+
+ binutils:
+ * MAINTAINERS (RISC-V): Update my address.
+
+2021-11-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Don't use gdb_stdlog for inferior-events
+ The test-case gdb.base/foll-vfork.exp contains:
+ ...
+ if [gdb_debug_enabled] {
+ untested "debug is enabled"
+ return 0
+ }
+ ...
+
+ To understand what it does, I disabled this bit and ran with GDB_DEBUG=infrun,
+ like so:
+ ...
+ $ cd $build/gdb/testsuite
+ $ make check GDB_DEBUG=infrun RUNTESTFLAGS=gdb.base/foll-vfork.exp
+ ...
+ and ran into:
+ ...
+ (gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+ vfork parent follow, through step: set follow-fork parent
+ next^M
+ 33 if (pid == 0) {^M
+ (gdb) FAIL: gdb.base/foll-vfork.exp: exec: \
+ vfork parent follow, through step: step
+ ...
+
+ The problem is that the test-case expects:
+ ...
+ (gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+ vfork parent follow, through step: set follow-fork parent
+ next^M
+ [Detaching after vfork from child process 28169]^M
+ 33 if (pid == 0) {^M
+ (gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+ vfork parent follow, through step: step
+ ...
+ but the "Detaching" line has been redirected to
+ $outputs/gdb.base/foll-vfork/gdb.debug.
+
+ I looked at the documentation of "set logging debugredirect [on|off]":
+ ...
+ By default, GDB debug output will go to both the terminal and the logfile.
+ Set debugredirect if you want debug output to go only to the log file.
+ ...
+ and my interpretation of it was that "debug output" did not match the
+ "messages" description of inferior-events:
+ ...
+ The set print inferior-events command allows you to enable or disable printing
+ of messages when GDB notices that new inferiors have started or that inferiors
+ have exited or have been detached.
+ ...
+
+ Fix the discrepancy by not using gdb_stdlog for inferior-events.
+
+ Update the gdb.base/foll-vfork.exp test-case to not require
+ gdb_debug_enabled == 0.
+
+ Tested on x86_64-linux.
+
+ Tested test-case gdb.base/foll-vfork.exp with and without GDB_DEBUG=infrun.
+
+2021-11-15 Roland McGrath <mcgrathr@google.com>
+
+ ld: Fix testsuite failures under --enable-textrel-check=error
+ ld/
+ * testsuite/ld-aarch64/dt_textrel.d: Pass explicit -z notext in
+ case ld was configured with --enable-textrel-check=error.
+ * testsuite/ld-aarch64/pr22764.d: Likewise.
+ * testsuite/ld-aarch64/pr20402.d: Likewise.
+
+2021-11-15 Luis Machado <luis.machado@linaro.org>
+
+ Extend the prologue analyzer to handle the bti instruction
+ Handle the BTI instruction in the prologue analyzer. The patch handles all
+ the variations of the BTI instruction.
+
+2021-11-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix gdbarch_tdep ODR violation
+ I would like to be able to use non-trivial types in gdbarch_tdep types.
+ This is not possible at the moment (in theory), because of the one
+ definition rule.
+
+ To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
+ make them inherit from a gdbarch_tdep base class. The inheritance is
+ necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
+ objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
+
+ These objects are never deleted through a base class pointer, so I
+ didn't include a virtual destructor. In the future, if gdbarch objects
+ deletable, I could imagine that the gdbarch_tdep objects could become
+ owned by the gdbarch objects, and then it would become useful to have a
+ virtual destructor (so that the gdbarch object can delete the owned
+ gdbarch_tdep object). But that's not necessary right now.
+
+ It turns out that RISC-V already has a gdbarch_tdep that is
+ non-default-constructible, so that provides a good motivation for this
+ change.
+
+ Most changes are fairly straightforward, mostly needing to add some
+ casts all over the place. There is however the xtensa architecture,
+ doing its own little weird thing to define its gdbarch_tdep. I did my
+ best to adapt it, but I can't test those changes.
+
+ Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
+
+2021-11-15 Clément Chigot <clement.chigot@atos.net>
+
+ COFF: avoid modifications over C_FILE filename aux entries.
+ Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
+ on XCOFF") introduces C_FILE entries which can store additional
+ information.
+ However, some modifications are needed by them but not by the original
+ C_FILE entries, usually representing the filename.
+ This patch ensures that filename entries are kept as is, in order to
+ protect targets not supporting the additional entries.
+
+ * coffgen.c (coff_write_symbol): Protect filename entries
+ (coff_write_symbols): Likewise.
+ (coff_print_symbol): Likewise.
+
+2021-11-15 Eric Botcazou <ebotcazou@gcc.gnu.org>
+
+ Deal with full path in .file 0 directive
+ Gas uses the directory part, if present, of the .file 0 directive to set
+ entry 0 of the directory table in DWARF 5, which represents the "current
+ directory".
+
+ Now Gas also uses the file part of the same directive to set entry 0 of the
+ file table, which represents the "current compilation file". But the latter
+ need not be located in the former so GCC will use a full path in the file
+ part when it is passed a full path:
+
+ gcc -c /full/path/test.c -save-temps
+
+ yields:
+
+ .file 0 "/current/directory" "/full/path/test.c"
+
+ in the assembly file and:
+
+ The Directory Table (offset 0x22, lines 2, columns 1):
+ Entry Name
+ 0 (indirect line string, offset: 0x25): /current/directory
+ 1 (indirect line string, offset: 0x38): /full/path
+
+ The File Name Table (offset 0x30, lines 2, columns 2):
+ Entry Dir Name
+ 0 0 (indirect line string, offset: 0x43): /full/path/test.c
+
+ in the object file. Note the full path and the questionable Dir value in
+ the 0 entry of the file table.
+
+2021-11-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: make error message test a little more flexible
+ The point of this test is to just make sure the usage text is shown,
+ not the exact details of the usage text. So shorten the output test
+ to match the beginning. This fixes breakage when the output changed
+ slightly to include [--].
+
+ sim: run: fix crash in argc==0 error situation
+ The new argv processing code assumed that we were always passed a
+ command line. If we weren't, make sure we don't crash before we
+ get a chance to output an error message about incorrect usage.
+
+ sim: cris: touch up rvdummy handling
+ Add quiet build support and make sure it's removed with `make clean`.
+
+ sim: cris: replace custom "dest" test field with new --argv0
+ The #dest field used in the cris testsuite is a bit of hack to set the
+ argv[0] for the tests to read out later on. Now that the sim has an
+ option to set argv[0] explicitly, we don't need this custom field, so
+ let's drop it to harmonize the testsuites a little.
+
+ sim: run: add --argv0 option to control argv[0]
+ We default argv[0] to the program we run which is a standard *NIX
+ convention, but sometimes we want to be able to control the argv[0]
+ setting independently (especially for programs that inspect argv[0]
+ to change their behavior or output). Add an option to control it.
+
+2021-11-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: split program path out of argv vector
+ We use the program argv to both find the program to run (argv[0]) and
+ to hold the arguments to the program. Most of the time this is fine,
+ but if we want to let programs specify argv[0] independently (which is
+ possible in standard *NIX programs), this double duty doesn't work.
+
+ So let's split the path to the program to run out into a separate
+ field by itself. This simplifies the various sim_open funcs too.
+
+ By itself, this code is more of a logical cleanup than something that
+ is super useful. But it will open up customization of argv[0] in a
+ follow up commit. Split the changes to make it easier to review.
+
+2021-11-15 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bfin: fix mach/xfail usage in tests
+ Set the mach to the right value all the time, and update xfail to
+ say the test fails on all targets. WIth multitarget testing, the
+ idea of target here doesn't make much sense.
+
+2021-11-15 Alan Modra <amodra@gmail.com>
+
+ -Waddress fixes for gold testsuite
+ Current mainline gcc.
+ common_test_1.c: In function 'main':
+ common_test_1.c:56:14: error: comparison between two arrays [-Werror=array-compare]
+ 56 | assert (c5 > c4);
+ | ^
+ common_test_1.c:56:14: note: use '&c5[0] > &c4[0]' to compare the addresses
+
+ * testsuite/common_test_1.c: Avoid -Waddress warnings.
+ * testsuite/common_test_1_v1.c: Likewise.
+ * testsuite/common_test_1_v2.c: Likewise.
+ * testsuite/script_test_2.cc: Likewise.
+
+2021-11-15 Alan Modra <amodra@gmail.com>
+
+ PowerPC64 @notoc in non-power10 code
+ R_PPC64_REL24_P9NOTOC is a variant of R_PPC64_REL24_NOTOC for use on
+ @notoc cals from non-power10 code in the rare case that using such a
+ construct is useful. R_PPC64_REL24_P9NOTOC will be emitted by gas
+ rather than R_PPC64_REL24_NOTOC when @notoc is used in a branch
+ instruction if power10 instructions are not enabled at that point.
+ The new relocation tells the linker to not use power10 instructions on
+ any stub emitted for that branch, unless overridden by
+ --power10-stubs=yes.
+
+ The current linker heuristic of only generating power10 instructions
+ for stubs if power10-only relocations are detected, continues to be
+ used.
+
+ include/
+ * elf/ppc64.h (R_PPC64_REL24_P9NOTOC): Define.
+ bfd/
+ * reloc.c (BFD_RELOC_PPC64_REL24_P9NOTOC): Define.
+ * elf64-ppc.c (ppc64_elf_howto_raw): Add entry for new reloc.
+ (ppc64_elf_reloc_type_lookup): Handle it.
+ (enum ppc_stub_type): Delete.
+ (enum ppc_stub_main_type, ppc_stub_sub_type): New.
+ (struct ppc_stub_type): New.
+ (struct ppc_stub_hash_entry): Use the above new type.
+ (struct ppc_link_hash_table): Update stub_count.
+ (is_branch_reloc, ppc64_elf_check_relocs),
+ (toc_adjusting_stub_needed): Handle new reloc.
+ (stub_hash_newfunc, select_alt_stub, ppc_merge_stub),
+ (ppc_type_of_stub, plt_stub_size, build_plt_stub),
+ (build_tls_get_addr_head, build_tls_get_addr_tail),
+ (ppc_build_one_stub, ppc_size_one_stub, ppc64_elf_size_stubs),
+ (ppc64_elf_build_stubs, ppc64_elf_relocate_section): Handle new
+ reloc. Modify stub handling to suit new scheme.
+ * bfd-in2.h: Regenerate.
+ * libbfd.h: Regenerate.
+ gas/
+ * config/tc-ppc.c (ppc_elf_suffix): When power10 is not enabled
+ return BFD_RELOC_PPC64_REL24_P9NOTOC for @notoc.
+ (fixup_size, ppc_force_relocation, ppc_fix_adjustable): Handle
+ BFD_RELOC_PPC64_REL24_P9NOTOC.
+ ld/
+ * testsuite/ld-powerpc/callstub-2.s: Add .machine power10.
+
+2021-11-15 Alan Modra <amodra@gmail.com>
+
+ Regenerate a couple of files
+ A couple of files changed on my latest --enable-maintainer-mode
+ build. ld/Makefile.in had a missing dependency but better sorting of
+ the loongson entries.
+
+ intl/
+ * configure: Regenerate.
+ ld/
+ * Makefile.am: Sort loongson entries.
+ * Makefile.in: Regenerate.
+
+2021-11-15 Pedro Alves <pedro@palves.net>
+
+ Fix build with current GCC: EL_EXPLICIT(location) always non-NULL
+ Compiling GDB with current GCC (1b4a63593b) runs into this:
+
+ src/gdb/location.c: In function 'int event_location_empty_p(const event_location*)':
+ src/gdb/location.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' will never be NULL [-Werror=address]
+ 963 | return (EL_EXPLICIT (location) == NULL
+ | ^
+ src/gdb/location.c:57:30: note: 'event_location::<unnamed union>::explicit_loc' declared here
+ 57 | struct explicit_location explicit_loc;
+ | ^~~~~~~~~~~~
+
+ GCC is right, EL_EXPLICIT is defined as returning the address of an
+ union field:
+
+ /* An explicit location. */
+ struct explicit_location explicit_loc;
+ #define EL_EXPLICIT(P) (&((P)->u.explicit_loc))
+
+ and thus must always be non-NULL.
+
+ Change-Id: Ie74fee7834495a93affcefce03c06e4d83ad8191
+
+2021-11-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-14 Lancelot SIX <lsix@lancelotsix.com>
+
+ [PR gdb/16238] Add completer for the show user command
+ The 'show user' command (which shows the definition of non-python/scheme
+ user defined commands) is currently missing a completer. This is
+ mentioned in PR 16238. Having one can improve the user experience.
+
+ In this commit I propose an implementation for such completer as well as
+ the associated tests.
+
+ Tested on x86_64 GNU/Linux.
+
+ All feedbacks are welcome.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16238
+
+2021-11-14 Alan Modra <amodra@gmail.com>
+
+ sync libbacktrace from gcc
+
+2021-11-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-13 H.J. Lu <hjl.tools@gmail.com>
+
+ Sync Makefile.tpl with GCC
+ * Makefile.tpl: Sync with GCC.
+ * Makefile.in: Regenerate.
+
+2021-11-13 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: fix switch-bool warnings
+ This code triggers -Werror=switch-bool warnings with <=gcc-5 versions.
+ Rework it to use if statements instead as it also simplifies a bit.
+
+ sim: sh: rework carry checks to not rely on integer overflows
+ In <=gcc-7 versions, -fstrict-overflow is enabled by default, and that
+ triggers warnings in this code that relies on integer overflows to test
+ for carries. Change the logic to test against the limit directly.
+
+2021-11-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-12 Carl Love <cel@us.ibm.com>
+
+ Fix gdb.base/sigstep.exp test for ppc
+ The test stops at <signal_handler called> which is the call to the handler
+ rather than in the handler as intended. This patch replaces the
+ gdb_test "$enter_cmd to handler" with a gdb_test_multiple test. The multiple
+ test looks for the stop at <signal_handler called>. If found, the command
+ is issued again. The test passes if gdb stops in the handler as expected.
+
+ (gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, step
+ from handler: continue to signal
+ stepi
+ <signal handler called>
+ 1: x/i $pc
+ => 0x7ffff7f80440 <__kernel_start_sigtramp_rt64>: bctrl
+ (gdb) stepi
+ handler (sig=551) at sigstep.c:32
+ 32 {
+ 1: x/i $pc
+ => 0x10000097c <handler>: addis r2,r12,2
+ (gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler,
+ step from handler: stepi to handler
+
+ Patch has been tested on x86_64-linux and ppc64le-linux with no test failures.
+
+2021-11-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp
+ On OBS I ran into:
+ ...
+ (gdb) PASS: gdb.base/foll-vfork.exp: exit: \
+ vfork relations in info inferiors: continue to child exit
+ info inferiors^M
+ Num Description Connection Executable ^M
+ 1 <null> foll-vfork-exit ^M
+ * 2 <null> foll-vfork-exit ^M
+ (gdb) I'm the proud parent of child #5044!^M
+ FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: \
+ vfork relation no longer appears in info inferiors (timeout)
+ ...
+
+ Fix this by removing the '$' anchor in the corresponding '$gdb_prompt $'
+ regexps.
+
+ Tested on x86_64-linux.
+
+2021-11-12 Alan Modra <amodra@gmail.com>
+
+ Don't compile some opcodes files when bfd is 32-bit only
+ * Makefile.am (TARGET_LIBOPCODES_CFILES): Split into..
+ (TARGET64_LIBOPCODES_CFILES): ..this and..
+ (TARGET32_LIBOPCODES_CFILES): ..this.
+ (ALL_MACHINES): Likewise split to
+ (ALL64_MACHINES, ALL32_MACHINES): ..this.
+ * disassemble.c: Define some ARCH_* when ARCH_all only if BFD64.
+ * configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+ Import Makefile.def from gcc
+ * Makefile.def: Import from gcc.
+ * Makefile.in: Regenerate.
+
+2021-11-12 Alan Modra <amodra@gmail.com>
+
+ Fix demangle style usage info
+ Extract allowed styles from libiberty, so we don't have to worry about
+ our help messages getting out of date. The function probably belongs
+ in libiberty/cplus-dem.c but it can be here for a while to iron out
+ bugs.
+
+ PR 28581
+ * demanguse.c: New file.
+ * demanguse.h: New file.
+ * nm.c (usage): Break up output. Use display_demangler_styles.
+ * objdump.c (usage): Use display_demangler_styles.
+ * readelf.c (usage): Likewise.
+ * Makefile.am: Add demanguse.c and demanguse.h.
+ * Makefile.in: Regenerate.
+ * po/POTFILESin: Regenerate.
+
+2021-11-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-11 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix "set scheduler-locking" thread exit hang
+ GDB hangs when doing this:
+
+ - launch inferior with multiple threads
+ - multiple threads hit some breakpoint(s)
+ - one breakpoint hit is presented as a stop, the rest are saved as
+ pending wait statuses
+ - "set scheduler-locking on"
+ - resume the currently selected thread (because of scheduler-locking,
+ it's the only one resumed), let it execute until exit
+ - GDB hangs, not showing the prompt, impossible to interrupt with ^C
+
+ When the resumed thread exits, we expect the target to return a
+ TARGET_WAITKIND_NO_RESUMED event, and that's what we see:
+
+ [infrun] fetch_inferior_event: enter
+ [infrun] scoped_disable_commit_resumed: reason=handling event
+ [infrun] random_pending_event_thread: None found.
+ [Thread 0x7ffff7d9c700 (LWP 309357) exited]
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: -1.0.0 [process -1],
+ [infrun] print_target_wait_results: status->kind = no-resumed
+ [infrun] handle_inferior_event: status->kind = no-resumed
+ [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
+ [infrun] prepare_to_wait: prepare_to_wait
+ [infrun] reset: reason=handling event
+ [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+ [infrun] fetch_inferior_event: exit
+
+ The problem is in handle_no_resumed: we check if some other thread is
+ actually resumed, to see if we should ignore that event (see comments in
+ that function for more info). If this condition is true:
+
+ (thread->executing () || thread->has_pending_waitstatus ())
+
+ ... then we ignore the event. The problem is that there are some non-resumed
+ threads with a pending event, which makes us ignore the event. But these
+ threads are not resumed, so we end up waiting while nothing executes, hence
+ waiting for ever.
+
+ My first fix was to change the condition to:
+
+ (thread->executing ()
+ || (thread->resumed () && thread->has_pending_waitstatus ()))
+
+ ... but then it occured to me that we could simply check for:
+
+ (thread->resumed ())
+
+ Since "executing" implies "resumed", checking simply for "resumed"
+ covers threads that are resumed and executing, as well as threads that
+ are resumed with a pending status, which is what we want.
+
+ Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780
+
+2021-11-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix Wimplicit-exception-spec-mismatch in clang build
+ When building with clang 13 (and -std=gnu++17 to work around an issue in
+ string_view-selftests.c), we run into a few Wimplicit-exception-spec-mismatch
+ warnings:
+ ...
+ src/gdbsupport/new-op.cc:102:1: error: function previously declared with an \
+ explicit exception specification redeclared with an implicit exception \
+ specification [-Werror,-Wimplicit-exception-spec-mismatch]
+ operator delete (void *p)
+ ^
+ /usr/include/c++/11/new:130:6: note: previous declaration is here
+ void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
+ ^
+ ...
+
+ These are due to recent commit 5fff6115fea "Fix
+ LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".
+
+ Fix this by adding the missing noexcept.
+
+ Build on x86_64-linux, using gcc 7.5.0 and clang 13.0.0.
+
+2021-11-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with -std=c++11
+ When building with -std=c++11, we run into two Werror=missing-declarations:
+ ...
+ new-op.cc: In function 'void operator delete(void*, std::size_t)':
+ new-op.cc:114:1: error: no previous declaration for \
+ 'void operator delete(void*, std::size_t)' [-Werror=missing-declarations]
+ operator delete (void *p, std::size_t) noexcept
+ ^~~~~~~~
+ new-op.cc: In function 'void operator delete [](void*, std::size_t)':
+ new-op.cc:132:1: error: no previous declaration for \
+ 'void operator delete [](void*, std::size_t)' [-Werror=missing-declarations]
+ operator delete[] (void *p, std::size_t) noexcept
+ ^~~~~~~~
+ ...
+
+ These are due to recent commit 5fff6115fea "Fix
+ LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".
+
+ The declarations are provided by <new> (which is included) for c++14 onwards,
+ but they are missing for c++11.
+
+ Fix this by adding the missing declarations.
+
+ Tested on x86_64-linux, with gcc 7.5.0, both without (implying -std=gnu++14) and
+ with -std=c++11.
+
+2021-11-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.arch/ppc64-break-on-_exit.exp
+ Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't
+ skip system call in skip_prologue":
+ - set a breakpoint on a local copy of glibc's _exit, and
+ - verify that it triggers.
+
+ The test-case uses an assembly file by default, but also has the possibility
+ to use a C source file instead.
+
+ Tested on ppc64le-linux. Verified that the test-case fails without
+ aforementioned commit, and passes with the commit. Both with assembly
+ and C source.
+
+2021-11-11 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Dump objects according to the elf architecture attribute.
+ For now we should always generate the elf architecture attribute both for
+ elf and linux toolchains, so that we could dump the objects correctly
+ according to the generated architecture string. This patch resolves the
+ problem that we probably dump an object with c.nop instructions, but
+ in fact the c extension isn't allowed. Consider the following case,
+
+ nelson@LAPTOP-QFSGI1F2:~/test$ cat temp.s
+ .option norvc
+ .option norelax
+ .text
+ add a0, a0, a0
+ .byte 0x1
+ .balign 16
+ nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-as temp.s -o temp.o
+ nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o
+
+ temp.o: file format elf32-littleriscv
+
+ Disassembly of section .text:
+
+ 00000000 <.text>:
+ 0: 00a50533 add a0,a0,a0
+ 4: 01 .byte 0x01
+ 5: 00 .byte 0x00
+ 6: 0001 nop
+ 8: 00000013 nop
+ c: 00000013 nop
+ nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-readelf -A temp.o
+ Attribute Section: riscv
+ File Attributes
+ Tag_RISCV_arch: "rv32i2p0_m2p0_a2p0_f2p0_d2p0"
+
+ The c.nop at address 0x6 is generated for alignment, but since the rvc isn't
+ allowed for this object, dump it as a c.nop instruction looks wrong. After
+ applying this patch, I get the following result,
+
+ nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o
+
+ temp.o: file format elf32-littleriscv
+
+ Disassembly of section .text:
+
+ 00000000 <.text>:
+ 0: 00a50533 add a0,a0,a0
+ 4: 01 .byte 0x01
+ 5: 00 .byte 0x00
+ 6: 0001 .2byte 0x1
+ 8: 00000013 nop
+ c: 00000013 nop
+
+ For the current objdump, we dump data to .byte/.short/.word/.dword, and
+ dump the unknown or unsupported instructions to .2byte/.4byte/.8byte, which
+ respectively are 2, 4 and 8 bytes instructions. Therefore, we shouldn't
+ dump the 0x0001 as a c.nop instruction in the above case, we should dump
+ it to .2byte 0x1 as a unknown instruction, since the rvc is disabled.
+
+ However, consider that some people may use the new objdump to dump the old
+ objects, which don't have any elf attributes. We usually set the default
+ architecture string to rv64g by bfd/elfxx-riscv.c:riscv_set_default_arch.
+ But this will cause rvc instructions to be unrecognized. Therefore, we
+ set the default architecture string to rv64gc for disassembler, to keep
+ the previous behavior.
+
+ This patch pass the riscv-gnu-toolchain gcc/binutils regressions for
+ rv32emc-elf, rv32gc-linux, rv32i-elf, rv64gc-elf and rv64gc-linux
+ toolchains. Also, tested by --enable-targets=all and can build
+ riscv-gdb successfully.
+
+ bfd/
+ * elfnn-riscv.c (riscv_merge_arch_attr_info): Tidy the
+ codes for riscv_parse_subset_t setting.
+ * elfxx-riscv.c (riscv_get_default_ext_version): Updated.
+ (riscv_subset_supports): Moved from gas/config/tc-riscv.c.
+ (riscv_multi_subset_supports): Likewise.
+ * elfxx-riscv.h: Added extern for riscv_subset_supports and
+ riscv_multi_subset_supports.
+ gas/
+ * config/tc-riscv.c (riscv_subset_supports): Moved to
+ bfd/elfxx-riscv.c.
+ (riscv_multi_subset_supports): Likewise.
+ (riscv_rps_as): Defined for architectrue parser.
+ (riscv_set_arch): Updated.
+ (riscv_set_abi_by_arch): Likewise.
+ (riscv_csr_address): Likewise.
+ (reg_lookup_internal): Likewise.
+ (riscv_ip): Likewise.
+ (s_riscv_option): Updated.
+ * testsuite/gas/riscv/mapping-04b.d: Updated.
+ * testsuite/gas/riscv/mapping-norelax-03b.d: Likewise.
+ * testsuite/gas/riscv/mapping-norelax-04b.d: Likewise.
+ opcodes/
+ * riscv-dis.c: Include elfxx-riscv.h since we need the
+ architecture parser. Also removed the cpu-riscv.h, it
+ is already included in elfxx-riscv.h.
+ (default_isa_spec): Defined since the parser need this
+ to set the default architecture string.
+ (xlen): Moved out from riscv_disassemble_insn as a global
+ variable, it is more convenient to initialize riscv_rps_dis.
+ (riscv_subsets): Defined to recoed the supported
+ extensions.
+ (riscv_rps_dis): Defined for architectrue parser.
+ (riscv_disassemble_insn): Call riscv_multi_subset_supports
+ to make sure if the instructions are valid or not.
+ (print_insn_riscv): Initialize the riscv_subsets by parsing
+ the elf architectrue attribute. Otherwise, set the default
+ architectrue string to rv64gc.
+
+2021-11-11 Mike Frysinger <vapier@gentoo.org>
+
+ sim: testsuite: drop sim_compile cover function
+ Most code isn't using this, and the only call site (in one cris file)
+ can use target_compile directly. So switch it over to simplify.
+
+ sim: cris: stop testing a.out explicitly [ld/13900]
+ Since gcc dropped support for a.out starting with 4.4.0 in 2009, it's
+ been impossible to verify this code actually still works. Since it
+ crashes in ld, and it uses a config option that no other tests uses
+ and we want to remove, drop the test to avoid all the trouble.
+
+ sim: io: tweak compiler workaround with error output
+ Outputting an extra space broke a cris test. Change the workaround
+ to use %s with an empty string to avoid the compiler warning but not
+ output an extra space.
+
+ sim: testsuite: delete unused arm remote host logic
+ There's no need to sync testutils.inc with remote hosts. The one
+ we have in the source tree is all we need and only thing we test.
+ Delete it to simplify.
+
+ sim: synacor: simplify test generation
+ Objcopy was used to create a binary file of just the executable code
+ since the environment requires code to based at address 0. We can
+ accomplish the same thing with the -Ttext=0 flag, so switch to that
+ to get rid of custom logic.
+
+2021-11-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-10 Tom Tromey <tromey@adacore.com>
+
+ Handle PIE in .debug_loclists
+ Simon pointed out that my recent patches to .debug_loclists caused
+ some regressions. After a brief discussion we realized it was because
+ his system compiler defaults to PIE.
+
+ This patch changes this code to unconditionally apply the text offset
+ here. It also changes loclist_describe_location to work more like
+ dwarf2_find_location_expression.
+
+ I tested this by running the gdb.dwarf2 tests both with and without
+ -pie.
+
+2021-11-10 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ arm: enable Cortex-A710 CPU
+ This patch is adding support for Cortex-A710 CPU in Arm.
+
+ bfd/
+
+ * cpu-arm.c (processors): Add cortex-a710.
+
+ gas/
+
+ * NEWS: Update docs.
+ * config/tc-arm.c (arm_cpus): Add cortex-a710 to -mcpu.
+ * doc/c-arm.texi: Update docs.
+ * testsuite/gas/arm/cpu-cortex-a710.d: New test.
+
+2021-11-10 Clément Chigot <clement.chigot@atos.net>
+
+ gdb: adjust x_file fields on COFF readers
+ Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
+ on XCOFF") changes the structure associated to the internal
+ representation of files in COFF formats. However, gdb directory update
+ has been forgotten, leading to compilation errors of this kind:
+
+ CXX coffread.o
+ /home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)':
+ /home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes'
+ 1343 | if (aux_entry->x_file.x_n.x_zeroes == 0)
+ | ^~~~~~~~
+
+ Fix it by adjusting the COFF code in GDB.
+
+ Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c
+
+2021-11-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.opt/break-on-_exit.exp
+ Add a test-case to excercise the problem scenario reported in PR28527 and
+ fixed in commit a50bdb99afe "[gdb/tdep, rs6000] Don't skip system call in
+ skip_prologue":
+ - set a breakpoint on _exit, and
+ - verify that it triggers.
+
+ Note that this is not a regression test for that commit. Since the actual
+ code in _exit may vary across os instances, we cannot guarantee that the
+ problem will always trigger with this test-case.
+
+ Rather, this test-case is a version of the original test-case
+ (gdb.threads/process-dies-while-detaching.exp) that is minimal while still
+ reproducing the problem reported in PR28527, in that same setting.
+
+ The benefit of this test-case is that it exercise real-life code and may
+ expose similar problems in other settings. Also, it provides a much easier
+ test-case to investigate in case a similar problem occurs.
+
+ Tested on x86_64-linux and ppc64le-linux.
+
+2021-11-10 Mike Frysinger <vapier@gentoo.org>
+
+ sim: frv: flip trapdump default back to off
+ When I refactored this by scoping it to sim-frv-xxx in commit
+ e7954ef5e5ed90fb7d28c013518f4c2e6bcd20a1 ("sim: frv: scope the
+ unique configure flag"), I changed the default from off to on.
+ While the feature is nice for developers, it breaks a bunch of
+ tests which aren't expecting this extra output. So flip it back
+ to off by default.
+
+2021-11-10 Pekka Seppänen <pexu@sourceware.mail.kapsi.fi>
+
+ PR28575, readelf.c and strings.c use undefined type uint
+ Since --unicode support (commit b3aa80b45c4) both binutils/readelf.c
+ and binutils/strings.c use 'uint' in a few locations. It likely
+ should be 'unsigned int' since there isn't anything defining 'uint'
+ within binutils (besides zlib) and AFAIK it isn't a standard type.
+
+ * readelf.c (print_symbol): Replace uint with unsigned int.
+ * strings.c (string_min, display_utf8_char): Likewise.
+ (print_unicode_stream_body, print_unicode_stream): Likewise.
+ (print_strings): Likewise.
+ (get_unicode_byte): Wrap long line.
+
+2021-11-10 Clément Chigot <clement.chigot@atos.net>
+
+ ld: set correct flags for AIX shared tests
+ Previous flags were aimed to be run with XLC.
+ Nowadays, only GCC is being tested with GNU toolchain. Moreover,
+ recent XLC versions might also accept "-shared".
+
+ * testsuite/ld-shared/shared.exp: Adjust shared flags.
+
+2021-11-10 Clément Chigot <clement.chigot@atos.net>
+
+ PR 28447: implement multiple parameters for .file on XCOFF
+ On XCOFF, ".file" pseudo-op allows 3 extras parameters to provide
+ additional information to AIX linker, or its debugger. These are
+ stored in auxiliary entries of the C_FILE symbol.
+
+ bfd/
+ PR 28447
+ * coffcode.h (combined_entry_type): Add extrap field.
+ (coff_bigobj_swap_aux_in): Adjust names of x_file fields.
+ (coff_bigobj_swap_aux_out): Likewise.
+ * coffgen.c (coff_write_auxent_fname): New function.
+ (coff_fix_symbol_name): Write x_file using
+ coff_write_auxent_fname.
+ (coff_write_symbol): Likewise.
+ (coff_write_symbols): Add C_FILE auxiliary entries to
+ string table if needed.
+ (coff_get_normalized_symtab): Adjust names of x_file fields.
+ Normalize C_FILE auxiliary entries.
+ (coff_print_symbol): Print C_FILE auxiliary entries.
+ * coff-rs6000.c (_bfd_xcoff_swap_aux_in): Adjust names of
+ x_file fields.
+ (_bfd_xcoff_swap_aux_out): Likewise.
+ * coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Likewise.
+ (_bfd_xcoff64_swap_aux_out): Likewise.
+ * cofflink.c (_bfd_coff_final_link): Likewise.
+ (_bfd_coff_link_input_bfd): Likewise.
+ * coffswap.h (coff_swap_aux_in): Likewise.
+ * peXXigen.c (_bfd_XXi_swap_aux_in): Likewise.
+ (_bfd_XXi_swap_aux_out): Likewise.
+ * xcofflink.c (xcoff_link_input_bfd): Likewise.
+ * libcoff.h: Regenerate.
+ gas/
+ * config/tc-ppc.c (ppc_file): New function.
+ * config/tc-ppc.h (OBJ_COFF_MAX_AUXENTRIES): Change to 4.
+ * testsuite/gas/ppc/aix.exp: Add tests.
+ * testsuite/gas/ppc/xcoff-file-32.d: New test.
+ * testsuite/gas/ppc/xcoff-file-64.d: New test.
+ * testsuite/gas/ppc/xcoff-file.s: New test.
+ include/
+ * coff/internal.h (union internal_auxent): Change x_file to be a
+ struct instead of a union. Add x_ftype field.
+ * coff/rs6000.h (union external_auxent): Add x_resv field.
+ * coff/xcoff.h (XFT_FN): New define.
+ (XFT_CT): Likewise.
+ (XFT_CV): Likewise.
+ (XFT_CD): Likewise.
+
+2021-11-10 Kevin Buettner <kevinb@redhat.com>
+
+ Test case for Bug 28308
+ The purpose of this test is described in the comments in
+ dprintf-execution-x-script.exp.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
+
+ The name of this new test was based on that of an existing test,
+ bp-cmds-execution-x-script.exp. I started off by copying that test,
+ adding to it, and then rewriting almost all of it. It's different
+ enough that I decided that listing the copyright year as 2021
+ was sufficient.
+
+2021-11-10 Kevin Buettner <kevinb@redhat.com>
+
+ Fix PR 28308 - dprintf breakpoints not working when run from script
+ This commit fixes Bug 28308, titled "Strange interactions with
+ dprintf and break/commands":
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
+
+ Since creating that bug report, I've found a somewhat simpler way of
+ reproducing the problem. I've encapsulated it into the GDB test case
+ which I've created along with this bug fix. The name of the new test
+ is gdb.base/dprintf-execution-x-script.exp, I'll demonstrate the
+ problem using this test case, though for brevity, I've placed all
+ relevant files in the same directory and have renamed the files to all
+ start with 'dp-bug' instead of 'dprintf-execution-x-script'.
+
+ The script file, named dp-bug.gdb, consists of the following commands:
+
+ dprintf increment, "dprintf in increment(), vi=%d\n", vi
+ break inc_vi
+ commands
+ continue
+ end
+ run
+
+ Note that the final command in this script is 'run'. When 'run' is
+ instead issued interactively, the bug does not occur. So, let's look
+ at the interactive case first in order to see the correct/expected
+ output:
+
+ $ gdb -q -x dp-bug.gdb dp-bug
+ ... eliding buggy output which I'll discuss later ...
+ (gdb) run
+ Starting program: /mesquite2/sourceware-git/f34-master/bld/gdb/tmp/dp-bug
+ vi=0
+ dprintf in increment(), vi=0
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 in dprintf-execution-x-script.c
+ vi=1
+ dprintf in increment(), vi=1
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 in dprintf-execution-x-script.c
+ vi=2
+ dprintf in increment(), vi=2
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 in dprintf-execution-x-script.c
+ vi=3
+ [Inferior 1 (process 1539210) exited normally]
+
+ In this run, in which 'run' was issued from the gdb prompt (instead
+ of at the end of the script), there are three dprintf messages along
+ with three 'Breakpoint 2' messages. This is the correct output.
+
+ Now let's look at the output that I snipped above; this is the output
+ when 'run' is issued from the script loaded via GDB's -x switch:
+
+ $ gdb -q -x dp-bug.gdb dp-bug
+ Reading symbols from dp-bug...
+ Dprintf 1 at 0x40116e: file dprintf-execution-x-script.c, line 38.
+ Breakpoint 2 at 0x40113a: file dprintf-execution-x-script.c, line 26.
+ vi=0
+ dprintf in increment(), vi=0
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 dprintf-execution-x-script.c: No such file or directory.
+ vi=1
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 in dprintf-execution-x-script.c
+ vi=2
+
+ Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+ 26 in dprintf-execution-x-script.c
+ vi=3
+ [Inferior 1 (process 1539175) exited normally]
+
+ In the output shown above, only the first dprintf message is printed.
+ The 2nd and 3rd dprintf messages are missing! However, all three
+ 'Breakpoint 2...' messages are still printed.
+
+ Why does this happen?
+
+ bpstat_do_actions_1() in gdb/breakpoint.c contains the following
+ comment and code near the start of the function:
+
+ /* Avoid endless recursion if a `source' command is contained
+ in bs->commands. */
+ if (executing_breakpoint_commands)
+ return 0;
+
+ scoped_restore save_executing
+ = make_scoped_restore (&executing_breakpoint_commands, 1);
+
+ Also, as described by this comment prior to the 'async' field
+ in 'struct ui' in top.h, the main UI starts off in sync mode
+ when processing command line arguments:
+
+ /* True if the UI is in async mode, false if in sync mode. If in
+ sync mode, a synchronous execution command (e.g, "next") does not
+ return until the command is finished. If in async mode, then
+ running a synchronous command returns right after resuming the
+ target. Waiting for the command's completion is later done on
+ the top event loop. For the main UI, this starts out disabled,
+ until all the explicit command line arguments (e.g., `gdb -ex
+ "start" -ex "next"') are processed. */
+
+ This combination of things, the state of the static global
+ 'executing_breakpoint_commands' plus the state of the async
+ field in the main UI causes this behavior.
+
+ This is a backtrace after hitting the dprintf breakpoint for
+ the second time when doing 'run' from the script file, i.e.
+ non-interactively:
+
+ Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
+ at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
+ 4431 if (executing_breakpoint_commands)
+
+ #0 bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
+ at gdb/breakpoint.c:4431
+ #1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x1538090)
+ at gdb/breakpoint.c:13048
+ #2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x137f450, ws=0x7fffffffc718,
+ stop_chain=0x1538090) at gdb/breakpoint.c:5498
+ #3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffc6f0)
+ at gdb/infrun.c:6172
+ #4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffc6f0)
+ at gdb/infrun.c:5662
+ #5 0x0000000000763cd5 in fetch_inferior_event ()
+ at gdb/infrun.c:4060
+ #6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
+ at gdb/inf-loop.c:41
+ #7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
+ at gdb/linux-nat.c:4207
+ #8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
+ at gdbsupport/event-loop.cc:701
+ #9 0x0000000000b8d032 in gdb_wait_for_event (block=0)
+ at gdbsupport/event-loop.cc:597
+ #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
+ #11 0x00000000009d19b6 in wait_sync_command_done ()
+ at gdb/top.c:528
+ #12 0x00000000009d1a3f in maybe_wait_sync_command_done (was_sync=0)
+ at gdb/top.c:545
+ #13 0x00000000009d2033 in execute_command (p=0x7fffffffcb18 "", from_tty=0)
+ at gdb/top.c:676
+ #14 0x0000000000560d5b in execute_control_command_1 (cmd=0x13b9bb0, from_tty=0)
+ at gdb/cli/cli-script.c:547
+ #15 0x000000000056134a in execute_control_command (cmd=0x13b9bb0, from_tty=0)
+ at gdb/cli/cli-script.c:717
+ #16 0x00000000004c3bbe in bpstat_do_actions_1 (bsp=0x137f530)
+ at gdb/breakpoint.c:4469
+ #17 0x00000000004c3d40 in bpstat_do_actions ()
+ at gdb/breakpoint.c:4533
+ #18 0x00000000006a473a in command_handler (command=0x1399ad0 "run")
+ at gdb/event-top.c:624
+ #19 0x00000000009d182e in read_command_file (stream=0x113e540)
+ at gdb/top.c:443
+ #20 0x0000000000563697 in script_from_file (stream=0x113e540, file=0x13bb0b0 "dp-bug.gdb")
+ at gdb/cli/cli-script.c:1642
+ #21 0x00000000006abd63 in source_gdb_script (extlang=0xc44e80 <extension_language_gdb>, stream=0x113e540,
+ file=0x13bb0b0 "dp-bug.gdb") at gdb/extension.c:188
+ #22 0x0000000000544400 in source_script_from_stream (stream=0x113e540, file=0x7fffffffd91a "dp-bug.gdb",
+ file_to_open=0x13bb0b0 "dp-bug.gdb")
+ at gdb/cli/cli-cmds.c:692
+ #23 0x0000000000544557 in source_script_with_search (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1, search_path=0)
+ at gdb/cli/cli-cmds.c:750
+ #24 0x00000000005445cf in source_script (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1)
+ at gdb/cli/cli-cmds.c:759
+ #25 0x00000000007cf6d9 in catch_command_errors (command=0x5445aa <source_script(char const*, int)>,
+ arg=0x7fffffffd91a "dp-bug.gdb", from_tty=1, do_bp_actions=false)
+ at gdb/main.c:523
+ #26 0x00000000007cf85d in execute_cmdargs (cmdarg_vec=0x7fffffffd1b0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND,
+ ret=0x7fffffffd18c) at gdb/main.c:615
+ #27 0x00000000007d0c8e in captured_main_1 (context=0x7fffffffd3f0)
+ at gdb/main.c:1322
+ #28 0x00000000007d0eba in captured_main (data=0x7fffffffd3f0)
+ at gdb/main.c:1343
+ #29 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
+ at gdb/main.c:1368
+ #30 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
+ at gdb/gdb.c:32
+
+ There are two frames for bpstat_do_actions_1(), one at frame #16 and
+ the other at frame #0. The one at frame #16 is processing the actions
+ for Breakpoint 2, which is a 'continue'. The one at frame #0 is attempting
+ to process the dprintf breakpoint action. However, at this point,
+ the value of 'executing_breakpoint_commands' is 1, forcing an early
+ return, i.e. prior to executing the command(s) associated with the dprintf
+ breakpoint.
+
+ For the sake of comparison, this is what the stack looks like when hitting
+ the dprintf breakpoint for the second time when issuing the 'run'
+ command from the GDB prompt.
+
+ Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffccd8)
+ at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
+ 4431 if (executing_breakpoint_commands)
+
+ #0 bpstat_do_actions_1 (bsp=0x7fffffffccd8)
+ at gdb/breakpoint.c:4431
+ #1 0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x16b0290)
+ at gdb/breakpoint.c:13048
+ #2 0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x13f0e60, ws=0x7fffffffd138,
+ stop_chain=0x16b0290) at gdb/breakpoint.c:5498
+ #3 0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffd110)
+ at gdb/infrun.c:6172
+ #4 0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffd110)
+ at gdb/infrun.c:5662
+ #5 0x0000000000763cd5 in fetch_inferior_event ()
+ at gdb/infrun.c:4060
+ #6 0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
+ at gdb/inf-loop.c:41
+ #7 0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
+ at gdb/linux-nat.c:4207
+ #8 0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
+ at gdbsupport/event-loop.cc:701
+ #9 0x0000000000b8d032 in gdb_wait_for_event (block=0)
+ at gdbsupport/event-loop.cc:597
+ #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
+ #11 0x00000000007cf512 in start_event_loop ()
+ at gdb/main.c:421
+ #12 0x00000000007cf631 in captured_command_loop ()
+ at gdb/main.c:481
+ #13 0x00000000007d0ebf in captured_main (data=0x7fffffffd3f0)
+ at gdb/main.c:1353
+ #14 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
+ at gdb/main.c:1368
+ #15 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
+ at gdb/gdb.c:32
+
+ This relatively short backtrace is due to the current UI's async field
+ being set to 1.
+
+ Yet another thing to be aware of regarding this problem is the
+ difference in the way that commands associated to dprintf breakpoints
+ versus regular breakpoints are handled. While they both use a command
+ list associated with the breakpoint, regular breakpoints will place
+ the commands to be run on the bpstat chain constructed in
+ bp_stop_status(). These commands are run later on. For dprintf
+ breakpoints, commands are run via the 'after_condition_true' function
+ pointer directly from bpstat_stop_status(). (The 'commands' field in
+ the bpstat is cleared in dprintf_after_condition_true(). This
+ prevents the dprintf commands from being run again later on when other
+ commands on the bpstat chain are processed.)
+
+ Another thing that I noticed is that dprintf breakpoints are the only
+ type of breakpoint which use 'after_condition_true'. This suggests
+ that one possible way of fixing this problem, that of making dprintf
+ breakpoints work more like regular breakpoints, probably won't work.
+ (I must admit, however, that my understanding of this code isn't
+ complete enough to say why. I'll trust that whoever implemented it
+ had a good reason for doing it this way.)
+
+ The comment referenced earlier regarding 'executing_breakpoint_commands'
+ states that the reason for checking this variable is to avoid
+ potential endless recursion when a 'source' command appears in
+ bs->commands. We know that a dprintf command is constrained to either
+ 1) execution of a GDB printf command, 2) an inferior function call of
+ a printf-like function, or 3) execution of an agent-printf command.
+ Therefore, infinite recursion due to a 'source' command cannot happen
+ when executing commands upon hitting a dprintf breakpoint.
+
+ I chose to fix this problem by having dprintf_after_condition_true()
+ directly call execute_control_commands(). This means that it no
+ longer attempts to go through bpstat_do_actions_1() avoiding the
+ infinite recursion check for potential 'source' commands on the
+ command chain. I think it simplifies this code a little bit too, a
+ definite bonus.
+
+ Summary:
+
+ * breakpoint.c (dprintf_after_condition_true): Don't call
+ bpstat_do_actions_1(). Call execute_control_commands()
+ instead.
+
+2021-11-10 Alan Modra <amodra@gmail.com>
+
+ Re: Add --unicode option
+ * objdump: Whitespace fixes.
+ (long_options): Correct "ctf" entry.
+
+2021-11-10 Alan Modra <amodra@gmail.com>
+
+ Re: Add --unicode option
+ At low optimisation levels gcc may warn.
+
+ * strings.c (print_unicode_stream_body): Avoid bogus "may be
+ used unitialised" warning.
+
+2021-11-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-09 Alan Modra <amodra@gmail.com>
+
+ PR28543, readelf entered an infinite loop
+ This little tweak terminates fuzzed binary readelf output a little
+ quicker.
+
+ PR 28543
+ * dwarf.c (read_and_display_attr_value): Consume a byte when
+ form is unrecognized.
+
+2021-11-09 Alan Modra <amodra@gmail.com>
+
+ PR28542, Undefined behaviours in readelf.c
+ PR 28542
+ * readelf.c (dump_relocations): Check that section headers have
+ been read before attempting to access section name.
+ (print_dynamic_symbol): Likewise.
+ (process_mips_specific): Delete dead code.
+
+2021-11-09 Pedro Alves <pedro@palves.net>
+
+ gdb::array_view slicing/container selftest - test std::array too
+ Change-Id: I2141b0b8a09f6521a59908599eb5ba1a19b18dc6
+
+2021-11-09 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with AddressSanitizer
+ This test fails for me, showing:
+
+ ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
+ ERROR: This GDB was configured as follows:
+ configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
+ --with-auto-load-dir=$debugdir:$datadir/auto-load
+ --with-auto-load-safe-path=$debugdir:$datadir/auto-load
+ ... and much more ...
+
+ The problem is that TCL's exec throws an error as soon as the exec'ed
+ process outputs on stderr. When GDB is built with ASan, it prints some
+ warnings about pre-existing signal handlers:
+
+ warning: Found custom handler for signal 7 (Bus error) preinstalled.
+ warning: Found custom handler for signal 8 (Floating point exception) preinstalled.
+ warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
+
+ Pass --quiet to GDB to avoid these warnings.
+
+ Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f
+
+2021-11-09 Tom Tromey <tromey@adacore.com>
+
+ Correctly handle DW_LLE_start_end
+ When the code to handle DW_LLE_start_end was added (as part of some
+ DWARF 5 work), it was written to add the base address. However, this
+ seems incorrect -- the DWARF standard describes this as an address,
+ not an offset from the base address.
+
+ This patch changes a couple of spots in dwarf2/loc.c to fix this
+ problem. It then changes decode_debug_loc_addresses to return
+ DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.
+
+ This only showed up on the RISC-V target internally, due to the
+ combination of DWARF 5 and a newer version of GCC. I've updated a
+ couple of existing loclists test cases to demonstrate the bug.
+
+2021-11-09 Tom Tromey <tromey@adacore.com>
+
+ Fix build on rhES5
+ The rhES5 build failed due to an upstream import a while back. The
+ bug here is that, while the 'personality' function exists,
+ ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
+ <sys/personality.h>.
+
+ However, <linux/personality.h> does not declare the 'personality'
+ function, and <sys/personality.h> and <linux/personality.h> cannot
+ both be included.
+
+ This patch restores one of the removed configure checks and updates
+ the code to check it.
+
+ We had this as a local patch at AdaCore, because it seemed like there
+ was no interest upstream. However, now it turns out that this fixes
+ PR build/28555, so I'm sending it now.
+
+2021-11-09 H.J. Lu <hjl.tools@gmail.com>
+
+ doc/ctf-spec.texi: Remove "@validatemenus off"
+ Remove @validatemenus from ctf-spec.texi, which has been removed from
+ texinfo by
+
+ commit a16dd1a9ece08568a1980b9a65a3a9090717997f
+ Author: Gavin Smith <gavinsmith0123@gmail.com>
+ Date: Mon Oct 12 16:32:37 2020 +0100
+
+ * doc/texinfo.texi
+ (Writing a Menu, Customization Variables for @-Commands)
+ (Command List),
+ * doc/refcard/txirefcard.tex
+ Remove @validatemenus.
+ * tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead
+ of awk. Avoid discouraged "$p" usage, using "$(p)" instead.
+ * tp/Texinfo/XS/configure.ac: Check for gawk.
+
+ commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4
+ Author: Gavin Smith <gavinsmith0123@gmail.com>
+ Date: Thu Jan 3 14:51:53 2019 +0000
+
+ Update refcard.
+
+ * doc/refcard/txirefcard.tex: @setfilename is no longer
+ mandatory. Do not mention @validatemenus or explicitly giving
+ @node pointers, as these are not very important features.
+
+ PR libctf/28567
+ * doc/ctf-spec.texi: Remove "@validatemenus off".
+
+2021-11-09 Nick Clifton <nickc@redhat.com>
+
+ Add --unicode option to control how unicode characters are handled by display tools.
+ * nm.c: Add --unicode option to control how unicode characters are
+ handled.
+ * objdump.c: Likewise.
+ * readelf.c: Likewise.
+ * strings.c: Likewise.
+ * binutils.texi: Document the new feature.
+ * NEWS: Document the new feature.
+ * testsuite/binutils-all/unicode.exp: New file.
+ * testsuite/binutils-all/nm.hex.unicode
+ * testsuite/binutils-all/strings.escape.unicode
+ * testsuite/binutils-all/objdump.highlight.unicode
+ * testsuite/binutils-all/readelf.invalid.unicode
+
+2021-11-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: simplify testsuite a bit
+ Switch from the centralized list in the exp file to each test declaring
+ its own requirements which they're already (mostly) doing. This will
+ increase coverage slightly by running more tests in more configurations
+ since the hardcoded exp list was a little out of date.
+
+ We have to mark the psh* tests as shdsp only (to match what the exp
+ file was doing), mark the fsca & fsrra tests as failing (since they
+ weren't even being run by the exp file), and to fix the expected
+ output & status of the fail test.
+
+2021-11-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cris: clean up missing func prototype warnings
+ Move some unused funcs under existing #if 0 protection, mark a few
+ local funcs as static, and add missing prototypes for the rest which
+ are used from other files. This fixes all the fatal warnings in the
+ mloop files so we can turn -Werror on here fully.
+
+2021-11-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-08 Lancelot SIX <lsix@lancelotsix.com>
+
+ Improve gdb::array_view ctor from contiguous containers
+ While reading the interface of gdb::array_view, I realized that the
+ constructor that builds an array_view on top of a contiguous container
+ (such as std::vector, std::array or even gdb::array_view) can be
+ missused.
+
+ Lets consider the following code sample:
+
+ struct Parent
+ {
+ Parent (int a): a { a } {}
+ int a;
+ };
+
+ std::ostream &operator<< (std::ostream& os, const Parent & p)
+ { os << "Parent {a=" << p.a << "}"; return os; }
+
+ struct Child : public Parent
+ {
+ Child (int a, int b): Parent { a }, b { b } {}
+ int b;
+ };
+
+ std::ostream &operator<< (std::ostream& os, const Child & p)
+ { os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; }
+
+ template <typename T>
+ void print (const gdb::array_view<const T> &p)
+ {
+ std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; });
+ }
+
+ Then with the current interface nothinng prevents this usage of
+ array_view to be done:
+
+ const std::array<Child, 3> elts = {
+ Child {1, 2},
+ Child {3, 4},
+ Child {5, 6}
+ };
+ print_all<Parent> (elts);
+
+ This compiles fine and produces the following output:
+
+ Parent {a=1}
+ Parent {a=2}
+ Parent {a=3}
+
+ which is obviously wrong. There is nowhere in memory a Parent-like
+ object for which the A member is 2 and this call to print_all<Parent>
+ shold not compile at all (calling print_all<Child> is however fine).
+
+ This comes down to the fact that a Child* is convertible into a Parent*,
+ and that an array view is constructed to a pointer to the first element
+ and a size. The valid type pointed to that can be used with this
+ constructor are restricted using SFINAE, which requires that a
+ pointer to a member into the underlying container can be converted into a
+ pointer the array_view's data type.
+
+ This patch proposes to change the constraints on the gdb::array_view
+ ctor which accepts a container now requires that the (decayed) type of
+ the elements in the container match the (decayed) type of the array_view
+ being constructed.
+
+ Applying this change required minimum adjustment in GDB codebase, which
+ are also included in this patch.
+
+ Tested by rebuilding.
+
+2021-11-08 Lancelot SIX <lsix@lancelotsix.com>
+
+ Add a const version of gdb_argv:as_array_view
+ This commits adds const versions for the GET and AS_ARRAX_VIEW methods
+ of gdb_argv. Those methods will be required in the following patch of
+ the series.
+
+2021-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix nulltr -> nullptr typo
+ Change-Id: I04403bd85ec3fa75ea14130d68daba675a2a8aeb
+
+2021-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: tweak scoped_disable_commit_resumed uses when resuming all threads in non-stop
+ When doing "continue -a" in non-stop mode, each thread is individually
+ resumed while the commit resumed state is enabled. This forces the
+ target to commit each resumption immediately, instead of being able to
+ batch things.
+
+ The reason is that there is no scoped_disable_commit_resumed around the
+ loop over threads in continue_1, when "non_stop && all_threads" is true.
+ Since the proceed function is called once for each thread, the
+ scoped_disable_commit_resumed in proceed therefore forces commit-resumed
+ between each thread resumption. Add the necessary
+ scoped_disable_commit_resumed in continue_1 to avoid that.
+
+ I looked at the MI side of things, the function exec_continue, and found
+ that it was correct. There is a similar iteration over threads, and
+ there is a scoped_disable_commit_resumed at the function scope. This is
+ not wrong, but a bit more than we need. The branches that just call
+ continue_1 do not need it, as continue_1 takes care of disabling commit
+ resumed. So, move the scoped_disable_commit_resumed to the inner scope
+ where we iterate on threads and proceed them individually.
+
+ Here's an example debugging a multi-threaded program attached by
+ gdbserver (debug output trimmed for brevity):
+
+ $ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234"
+ (gdb) set debug remote
+ (gdb) set debug infrun
+ (gdb) c -a
+ Continuing.
+ [infrun] proceed: enter
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [remote] Sending packet: $vCont;c:p14388.14388#90
+ [infrun] reset: reason=proceeding
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+ [infrun] proceed: exit
+ [infrun] proceed: enter
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [remote] Sending packet: $vCont;c:p14388.1438a#b9
+ [infrun] reset: reason=proceeding
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+ [infrun] proceed: exit
+ ... and so on for each thread ...
+
+ Notice how we send one vCont;c for each thread. With the patch applied, we
+ send a single vCont;c at the end:
+
+ [infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop
+ [infrun] proceed: enter
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [infrun] reset: reason=proceeding
+ [infrun] proceed: exit
+ [infrun] clear_proceed_status_thread: Thread 85790.85792
+ [infrun] proceed: enter
+ [infrun] scoped_disable_commit_resumed: reason=proceeding
+ [infrun] reset: reason=proceeding
+ [infrun] proceed: exit
+ ... proceeding threads individually ...
+ [infrun] reset: reason=continue all threads in non-stop
+ [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+ [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+ [remote] Sending packet: $vCont;c#a8
+
+ Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb
+
+2021-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make dwarf2_find_containing_comp_unit take a dwarf2_per_bfd
+ While reading another patch, I saw that this function didn't need to
+ take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead.
+ It doesn't change the behavior, but doing this shows that this function
+ is objfile-independent (can work with only the shared per-bfd data).
+
+ Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f
+
+2021-11-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove bpstat typedef, rename bpstats to bpstat
+ I don't find that the bpstat typedef, which hides a pointer, is
+ particularly useful. In fact, it confused me many times, and I just see
+ it as something to remember that adds cognitive load. Also, with C++,
+ we might want to be able to pass bpstats objects by const-reference, not
+ necessarily by pointer.
+
+ So, remove the bpstat typedef and rename struct bpstats to bpstat (since
+ it represents one bpstat, it makes sense that it is singular).
+
+ Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
+
+2021-11-08 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: add CTF format specification
+ It's been a long time since most of this was written: it's long past
+ time to put it in the binutils source tree. It's believed correct and
+ complete insofar as it goes: it documents format v3 (the current
+ version) but not the libctf API or any earlier versions. (The
+ earlier versions can be read by libctf but not generated by it, and you
+ are highly unlikely ever to see an example of any of them.)
+
+ libctf/ChangeLog
+ 2021-11-08 Nick Alcock <nick.alcock@oracle.com>
+
+ * doc/ctf-spec.texi: New file.
+ * configure.ac (MAKEINFO): Add.
+ (BUILD_INFO): Likewise.
+ (AC_CONFIG_FILES) [doc/Makefile]: Add.
+ * Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/.
+ * doc/Makefile.am: New file.
+ * doc/Makefile.in: Likewise.
+ * configure: Regenerated.
+ * Makefile.in: Likewise.
+
+2021-11-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-07 Alan Modra <amodra@gmail.com>
+
+ Correct ld script wildcard matching description
+ Goes with commit 68bbb9f788d0
+
+ * ld.texi (Input Section Wildcards): Delete paragraph incorrectly
+ saying '*' does not match '/'.
+
+2021-11-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: fix conversion of PC to an integer
+ On LLP64 targets where sizeof(long) != sizeof(void*), this code fails:
+ sim/sh/interp.c:704:24: error: cast from pointer to integer of different size -Werror=pointer-to-int-cast]
+ 704 | do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0)
+ | ^
+
+ Since this code simply needs to check alignment, cast it using uintptr_t
+ which is the right type for this.
+
+2021-11-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: clean up time(NULL) call
+ Casting 0 to a pointer via (long *) doesn't work on LLP64 targets:
+ error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
+
+ It's also unnecessary here. We can simply pass NULL like every other
+ bit of code does.
+
+2021-11-07 Mike Frysinger <vapier@gentoo.org>
+
+ sim: sh: break utime logic out of _WIN32 check
+ Some _WIN32 targets provide utime (like mingw), so move the header
+ include out from _WIN32 and under the specific HAVE_UTIME_H check.
+
+ sim: sh: drop errno extern
+ This isn't needed on any reasonable target nowadays, and no other
+ source does this, and breaks with some mingw targets, so punt the
+ extern entirely.
+
+ sim: sh: fix isnan redefinition with mingw targets
+ The code assumes that all _WIN32 targets are the same and can
+ define isnan to _isnan. For mingw targets, they provide an isnan
+ define already, so no need for the fallback here.
+
+ sim: arm/bfin/rx: undefine page size from system headers
+ Some targets (like cygwin) will export page size defines that clash
+ with our local usage here. Undefine the system one to fix building
+ for these targets.
+
+ sim: ppc: switch to libiberty environ.h
+ Drop our compat code and assume environ exists to simplify.
+ We did this for all other targets already, but ppc was missed.
+
+ sim: sh: enable -Werror everywhere
+ With most of the warnings fixed in interp.c, we can enable -Werror
+ here too now. There are some -Wmaybe-uninitialized warnings still
+ lurking that look legitimate, but we don't flag those are fatal,
+ and I don't have the expertise to dive into each opcode to figure
+ out the right way to clean them up.
+
+ sim: sh: fix uninitialized variable usage with pdmsb
+ This block of code relies on i to control which bits to test and how
+ many times to run through the loop, but it never actually initialized
+ it. There is another chunk of code that handles the pdmsb instruction
+ that sets i to 16, so use that here too assuming it's correct. The
+ programming manual suggests this is the right value too, but I am by
+ no means a SuperH DSP expert. The tests are still passing though ...
+
+ sim: sh: constify a few read-only lookup tables
+
+ sim: sh: fix various parentheses warnings
+ Add parentheses to a bunch of places where the compiler suggests we
+ do to avoid confusion to most readers.
+
+ sim: sh: fix unused-value warnings
+ These macro expansions are deliberate in not using the computed value
+ so that they trigger side-effects (possible invalid memory accesses)
+ but while otherwise being noops. Add a (void) cast so the compiler
+ knows these are intentional.
+
+ sim: sh: rework register layout with anonymous unions & structs
+ Now that we require C11, we can leverage anonymous unions & structs
+ to fix a long standing issue with the SH register layout. The use
+ of sregs.i for sh-dsp has generated a lot of compiler warnings about
+ the access being out of bounds -- it only has 7 elements declared,
+ but code goes beyond that to reach into the fregs that follow. But
+ now that we have anonymous unions, we can reduce the nested names
+ and have sregs cover all of these registers.
+
+2021-11-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-06 Tiezhu Yang <yangtiezhu@loongson.cn>
+
+ sim: mips: use sim_fpu_to{32,64}u to fix build warnings
+ Since the first argument type is unsigned32 or unsigned64, just use
+ sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following
+ build warnings:
+
+ CC cp1.o
+ .../sim/mips/cp1.c: In function 'convert':
+ .../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+ status |= sim_fpu_to32i (&result32, &wop, round);
+ ^~~~~~~~~
+ In file included from .../sim/mips/sim-main.h:67,
+ from .../sim/mips/cp1.c:46:
+ .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+ INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+ ^~~~~~~~~~~~~
+ .../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign]
+ status |= sim_fpu_to64i (&result64, &wop, round);
+ ^~~~~~~~~
+ In file included from .../sim/mips/sim-main.h:67,
+ from .../sim/mips/cp1.c:46:
+ .../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'}
+ INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f,
+ ^~~~~~~~~~~~~
+ .../sim/mips/cp1.c: In function 'convert_ps':
+ .../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+ status_u |= sim_fpu_to32i (&res_u, &wop_u, round);
+ ^~~~~~
+ In file included from .../sim/mips/sim-main.h:67,
+ from .../sim/mips/cp1.c:46:
+ .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+ INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+ ^~~~~~~~~~~~~
+ .../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+ status_l |= sim_fpu_to32i (&res_l, &wop_l, round);
+ ^~~~~~
+ In file included from .../sim/mips/sim-main.h:67,
+ from .../sim/mips/cp1.c:46:
+ .../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+ INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+ ^~~~~~~~~~~~~
+
+2021-11-06 Alan Modra <amodra@gmail.com>
+
+ Modernise yyerror
+ Newer versions of bison emit a prototype for yyerror
+ void yyerror (const char *);
+ This clashes with some of our old code that declares yyerror to return
+ an int. Fix that in most cases by modernizing yyerror. bfin-parse.y
+ uses the return value all over the place, so for there disable
+ generation of the prototype as specified by posix.
+
+ binutils/
+ * arparse.y (yyerror): Return void.
+ * dlltool.c (yyerror): Likewise.
+ * dlltool.h (yyerror): Likewise.
+ * sysinfo.y (yyerror): Likewise.
+ * windmc.h (yyerror): Likewise.
+ * mclex.c (mc_error): Extract from ..
+ (yyerror): ..here, both now returning void.
+ gas/
+ * config/bfin-parse.y (yyerror): Define.
+ (yyerror): Make static.
+ * itbl-parse.y (yyerror): Return void.
+ ld/
+ * deffilep.y (def_error): Return void.
+
+2021-11-06 Alan Modra <amodra@gmail.com>
+
+ ubsan: undefined shift in mach-o.c
+ This one was logically wrong too. If file_ptr was 64 bits, then -1U
+ is extended to 0x00000000ffffffff, probably not what was intended
+ here.
+
+ * mach-o.c (FILE_ALIGN): Correct expression.
+
+2021-11-06 Fangrui Song <maskray@google.com>
+
+ readelf: Support RELR in -S and -d and output
+ readelf -r dumping support is not added in this patch.
+
+ include/
+ * elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT}
+ bfd/
+ * elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}.
+ binutils/
+ * readelf.c (get_dynamic_type): Add DT_RELR{,SZ,ENT}.
+ (get_section_type_name): Add SHT_RELR.
+
+2021-11-06 Fangrui Song <maskray@google.com>
+
+ readelf: Make DT_PREINIT_ARRAYSZ's output style match DT_INIT_ARRAYSZ
+ The output now looks like:
+
+ - 0x0000000000000021 (PREINIT_ARRAYSZ) 0x10
+ + 0x0000000000000021 (PREINIT_ARRAYSZ) 16 (bytes)
+ 0x0000000000000019 (INIT_ARRAY) 0xbefc90
+ 0x000000000000001b (INIT_ARRAYSZ) 536 (bytes)
+
+ * readelf.c (process_dynamic_section): Handle DT_PREINIT_ARRAYSZ.
+
+2021-11-06 Mike Frysinger <vapier@gentoo.org>
+
+ sim: clarify license text via COPYING file
+ The project has been using GPL v3 for a while now in the source files,
+ and the arm & ppc ports have carried a copy of the COPYING file. Lets
+ move those up to the top sim dir like other projects to make it clear.
+
+ Also drop the ppc/COPYING.LIB as it's not really referenced by any
+ source as everything is GPL v3.
+
+2021-11-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-05 Tom Tromey <tom@tromey.com>
+
+ Introduce make_unique_xstrndup
+ This adds a new make_unique_xstrndup function, which is the "n"
+ analogue of make_unique_xstrdup. It also updates a couple existing
+ places to use this function.
+
+2021-11-05 Pedro Alves <pedro@palves.net>
+
+ Avoid /proc/pid/mem races (PR 28065)
+ PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent
+ failure) shows that GDB can hit an unexpected scenario -- it can
+ happen that the kernel manages to open a /proc/PID/task/LWP/mem file,
+ but then reading from the file returns 0/EOF, even though the process
+ hasn't exited or execed.
+
+ "0" out of read/write is normally what you get when the address space
+ of the process the file was open for is gone, because the process
+ execed or exited. So when GDB gets the 0, it returns memory access
+ failure. In the bad case in question, the process hasn't execed or
+ exited, so GDB fails a memory access when the access should have
+ worked.
+
+ GDB has code in place to gracefully handle the case of opening the
+ /proc/PID/task/LWP/mem just while the LWP is exiting -- most often the
+ open fails with EACCES or ENOENT. When it happens, GDB just tries
+ opening the file for a different thread of the process. The testcase
+ is written such that it stresses GDB's logic of closing/reopening the
+ /proc/PID/task/LWP/mem file, by constantly spawning short lived
+ threads.
+
+ However, there's a window where the kernel manages to find the thread,
+ but the thread exits just after and clears its address space pointer.
+ In this case, the kernel creates a file successfully, but the file
+ ends up with no address space associated, so a subsequent read/write
+ returns 0/EOF too, just like if the whole process had execed or
+ exited. This is the case in question that GDB does not handle.
+
+ Oleg Nesterov gave this suggestion as workaround for that race:
+
+ gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
+ If statm reports something non-zero, then open() was "successfull".
+
+ I think that might work. However, I didn't try it, because I realized
+ we have another nasty race that that wouldn't fix.
+
+ The other race I realized is that because we close/reopen the
+ /proc/PID/task/LWP/mem file when GDB switches to a different inferior,
+ then it can happen that GDB reopens /proc/PID/task/LWP/mem just after
+ a thread execs, and before GDB has seen the corresponding exec event.
+ I.e., we can open a /proc/PID/task/LWP/mem file accessing the
+ post-exec address space thinking we're accessing the pre-exec address
+ space.
+
+ A few months back, Simon, Oleg and I discussed a similar race:
+
+ [Bug gdb/26754] Race condition when resuming threads and one does an exec
+ https://sourceware.org/bugzilla/show_bug.cgi?id=26754
+
+ The solution back then was to make the kernel fail any ptrace
+ operation until the exec event is consumed, with this kernel commit:
+
+ commit dbb5afad100a828c97e012c6106566d99f041db6
+ Author: Oleg Nesterov <oleg@redhat.com>
+ AuthorDate: Wed May 12 15:33:08 2021 +0200
+ Commit: Linus Torvalds <torvalds@linux-foundation.org>
+ CommitDate: Wed May 12 10:45:22 2021 -0700
+
+ ptrace: make ptrace() fail if the tracee changed its pid unexpectedly
+
+ This however, only applies to ptrace, not to the /proc/pid/mem file
+ opening case. Also, even if it did apply to the file open case, we
+ would want to support current kernels until such a fix is more wide
+ spread anyhow.
+
+ So all in all, this commit gives up on the idea of only ever keeping
+ one /proc/pid/mem file descriptor open. Instead, make GDB open a
+ /proc/pid/mem per inferior, and keep it open until the inferior exits,
+ is detached or execs. Make GDB open the file right after the inferior
+ is created or is attached to or forks, at which point we know the
+ inferior is stable and stopped and isn't thus going to exec, or have a
+ thread exit, and so the file open won't fail (unless the whole process
+ is SIGKILLed from outside GDB, at which point it doesn't matter
+ whether we open the file).
+
+ This way, we avoid both races described above, at the expense of using
+ more file descriptors (one per inferior).
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065
+ Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419
+
+2021-11-05 Andrew Burgess <aburgess@redhat.com>
+
+ gdb/testsuite: use gdb_get_line_number
+ Replaces a hard coded line number with a use of gdb_get_line_number.
+
+ I suspect that the line number has, over time, come adrift from where
+ it was supposed to be stopping. When the test was first added, line
+ 770 pointed at the final 'return 0' in function main. Over time, as
+ things have been added, line 770 now points at some random location in
+ the middle of main.
+
+ So, I've marked the 'return 0' with a comment, and now the test will
+ always stop there.
+
+ I also removed an old comment from 1997 talking about how these tests
+ will only pass with the HP compiler, followed by an additional comment
+ from 2000 saying that the tests now pass with GCC.
+
+ I get the same results before and after this change.
+
+2021-11-05 Alan Modra <amodra@gmail.com>
+
+ PR28541, unstable cie offset in the output of readelf
+ Calculating "0 - pointer" can indeed result in seeming randomness as
+ the pointer address varies.
+
+ PR 28541
+ * dwarf.c (display_debug_frames): Don't print cie offset when
+ invalid, print "invalid" instead. Remove now redundant warning.
+
+2021-11-05 Alan Modra <amodra@gmail.com>
+
+ Missing va_end in aarch64-dis.c
+ * aarch64-dis.c (extract_fields): Invoke va_end.
+
+2021-11-05 Alan Modra <amodra@gmail.com>
+
+ PR28530, Hang in objdump on machine with 196GB RAM
+ Investigating the PR28530 testcase, which has a fuzzed compression
+ header with an enormous size, I noticed that decompress_contents is
+ broken when the size doesn't fit in strm.avail_out. It wouldn't be
+ too hard to support larger sizes (patches welcome!) but for now just
+ stop decompress_contents from returning rubbish.
+
+ PR 28530
+ * compress.c (decompress_contents): Fail when uncompressed_size
+ is too big.
+ (bfd_init_section_decompress_status): Likewise.
+
+2021-11-05 Alan Modra <amodra@gmail.com>
+
+ asan: alpha-vms: objdump buffer overflows
+ * vms-alpha.c (evax_bfd_print_desc): Sanity check buffer access.
+ (evax_bfd_print_valspec, evax_bfd_print_typspec): Likewise.
+ (evax_bfd_print_dst): Likewise.
+
+2021-11-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce "set index-cache enabled", deprecate "set index-cache on/off"
+ The "set index-cache" command is used at the same time as a prefix
+ command (prefix for "set index-cache directory", for example), and a
+ boolean setting for turning the index-cache on and off. Even though I
+ did introduce that, I now don't think it's a good idea to do something
+ non-standard like this.
+
+ First, there's no dedicated CLI command to show whether the index-cache
+ is enabled, so it has to be custom output in the "show index-cache
+ handler". Also, it means there's no good way a MI frontend can find out
+ if the index-cache is enabled. "-gdb-show index-cache" doesn't show it
+ in the MI output record:
+
+ (gdb) interpreter-exec mi "-gdb-show index-cache"
+ ~"\n"
+ ~"The index cache is currently disabled.\n"
+ ^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
+
+ Fix this by introducing "set/show index-cache enabled on/off", regular
+ boolean setting commands. Keep commands "set index-cache on" and "set
+ index-cache off" as deprecated aliases of "set index-cache enabled",
+ with respectively the default arguments "on" and "off".
+
+ Update tests using "set index-cache on/off" to use the new command.
+ Update the regexps in gdb.base/maint.exp to figure out whether the
+ index-cache is enabled or not. Update the doc to mention the new
+ commands.
+
+ Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
+
+2021-11-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: pass/return setting setter/getter scalar values by value
+ The getter and setter in struct setting always receive and return values
+ by const reference. This is not necessary for scalar values (like bool
+ and int), but more importantly it makes it a bit annoying to write a
+ getter, you have to use a scratch static variable or something similar
+ that you can refer to:
+
+ const bool &
+ my_getter ()
+ {
+ static bool value;
+ value = function_returning_bool ();
+ return value;
+ }
+
+ Change the getter and setter function signatures to receive and return
+ value by value instead of by reference, when the underlying data type is
+ scalar. This means that string-based settings will still use
+ references, but all others will be by value. The getter above would
+ then be re-written as:
+
+ bool
+ my_getter ()
+ {
+ return function_returning_bool ();
+ }
+
+ This is useful for a patch later in this series that defines a boolean
+ setting with a getter and a setter.
+
+ Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd
+
+2021-11-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove command_class enum class_deprecated
+ The class_deprecated enumerator isn't assigned anywhere, so remove it.
+ Commands that are deprecated have cmd_list_element::cmd_deprecated set
+ instead.
+
+ Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c
+
+2021-11-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove unnecessary cmd_list_element::aliases nullptr checks
+ Remove two unnecessary nullptr checks. If aliases is nullptr, then the
+ for loops will simply be skipped.
+
+ Change-Id: I9132063bb17798391f8d019af305383fa8e0229f
+
+2021-11-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: re-generate configure
+ I get some diffs when running autoconf in gdbserver, probably leftovers
+ from commit 5dfe4bfcb969 ("Fix format_pieces selftest on Windows").
+ Re-generate configure in that directory.
+
+ Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08
+
+2021-11-04 H.J. Lu <hjl.tools@gmail.com>
+
+ Revert "bfd: Always check sections with the corrupt size"
+ This reverts commit e0f7ea91436dd308a094c4c101fd4169e8245a91.
+
+2021-11-04 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Always check sections with the corrupt size
+ Always check sections with the corrupt size for non-MMO files. Skip MMO
+ files for compress_status == COMPRESS_SECTION_NONE since MMO has special
+ handling for COMPRESS_SECTION_NONE.
+
+ PR binutils/28530
+ * compress.c (bfd_get_full_section_contents): Always check
+ sections with the corrupt size.
+
+2021-11-04 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Clarify the behavior of .option rvc or norvc.
+ Add/Remove the rvc extension to/from the riscv_subsets once the
+ .option rvc/norvc is set. So that we don't need to always check
+ the riscv_opts.rvc in the riscv_subset_supports, just call the
+ riscv_lookup_subset to search the subset list is enough.
+
+ Besides, we will need to dump the instructions according to the
+ elf architecture attributes. That means the dis-assembler needs
+ to parse the architecture string from the elf attribute before
+ dumping any instructions, and also needs to recognized the
+ INSN_CLASS* classes from riscv_opcodes. Therefore, I suppose
+ some functions will need to be moved from gas/config/tc-riscv.c
+ to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and
+ riscv_subset_supports. This is one of the reasons why we need
+ this patch.
+
+ This patch passes the gcc/binutils regressions of rv32emc-elf,
+ rv32i-elf, rv64gc-elf and rv64gc-linux toolchains.
+
+ bfd/
+ * elfxx-riscv.c (riscv_remove_subset): Remove the extension
+ from the subset list.
+ (riscv_update_subset): Add/Remove an extension to/from the
+ subset list. This is used for the .option rvc or norvc.
+ * elfxx-riscv.h: Added the extern bool riscv_update_subset.
+ gas/
+ * config/tc-riscv.c (riscv_set_options): Removed the unused
+ rve flag.
+ (riscv_opts): Likewise.
+ (riscv_set_rve): Removed.
+ (riscv_subset_supports): Removed the riscv_opts.rvc check.
+ (riscv_set_arch): Don't need to call riscv_set_rve.
+ (reg_lookup_internal): Call riscv_subset_supports to check
+ whether the rve is supported.
+ (s_riscv_option): Add/Remove the rvc extension to/from the
+ subset list once the .option rvc/norvc is set.
+
+2021-11-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: fix missing prototype in multi-run generation
+ The multi-run logic for mips involves a bit of codegen and rewriting
+ of files to include per-architecture prefixes. That can result in
+ files with missing prototypes which cause compiler errors. In the
+ case of mips-sde-elf targets, we have:
+ $srcdir/m16run.c -> $builddir/m16mips64r2_run.c
+ sim_engine_run -> m16mips64r2_engine_run
+ $srcdir/micromipsrun.c -> micromipsmicromips_run.c
+ sim_engine_run -> micromips64micromips_engine_run
+
+ micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes]
+ 80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus,
+
+ We generate headers for those prototypes in the configure script,
+ but only include them in the generated multi-run.c file. Update the
+ rewrite logic to turn the sim-engine.h include into the relevant
+ generated engine include so these files also have their prototypes.
+ $srcdir/m16run.c -> $builddir/m16mips64r2_run.c
+ sim-engine.h -> m16mips64r2_engine.h
+ $srcdir/micromipsrun.c -> micromipsmicromips_run.c
+ sim-engine.h -> micromips64micromips_engine.h
+
+2021-11-04 Alan Modra <amodra@gmail.com>
+
+ PR28540, segmentation fault on NULL byte_get
+ PR 28540
+ * objdump.c (dump_bfd): Don't attempt load_separate_debug_files
+ when byte_get is NULL.
+
+2021-11-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: inline common sim-fpu.c logic
+ We will never bother building w/out a ../common/ sim directory,
+ so drop ancient logic supporting that method.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: switch to common builds for callback objects
+ We don't need to build this anymore ourselves since the common build
+ includes it and produces the same object code. We also need to pull
+ in the split constant modules after the refactoring and pulling them
+ out of nltvals.def & targ-map.o. This doesn't matter for the sim
+ directly, but does for gdb and other users of libsim.
+
+ We also delete some conditional source tree logic since we already
+ require this be the "new" combined tree with a ../common/ dir. This
+ has been the case for decades at this point.
+
+2021-11-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix gnu-nat build
+ When building gnu-nat.c, we get:
+
+ CXX gnu-nat.o
+ gnu-nat.c: In member function 'virtual void gnu_nat_target::create_inferior(const char*, const string&, char**, int)':
+ gnu-nat.c:2117:13: error: 'struct inf' has no member named 'target_is_pushed'
+ 2117 | if (!inf->target_is_pushed (this))
+ | ^~~~~~~~~~~~~~~~
+ gnu-nat.c:2118:10: error: 'struct inf' has no member named 'push_target'
+ 2118 | inf->push_target (this);
+ | ^~~~~~~~~~~
+
+ This is because of a confusion between the generic `struct inferior`
+ variable and the gnu-nat-specific `struct inf` variable. Fix by
+ referring to `inferior`, not `inf`.
+
+ Adjust the comment on top of `struct inf` to clarify the purpose of that
+ type.
+
+ Co-Authored-By: Andrea Monaco <andrea.monaco@autistici.org>
+ Change-Id: I2fe2f7f6ef61a38d79860fd262b08835c963fc77
+
+2021-11-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests
+ We see some additional failures when running the testsuite against a GDB
+ compiled with ASan, compared to a GDB compiled without ASan. Some of
+ them are caused by the memory leak report shown by the GDB process when
+ it exits, and the fact that it makes it exit with a non-zero exit code.
+
+ I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
+ environment when running the tests, but I don't always do it. I think
+ it would be nice if the testsuite did it. I don't see any use to have
+ leak detection when running the tests. That is, unless we ever have a
+ test that ensures GDB doesn't leak memory, which isn't going to happen
+ any time soon.
+
+ Here are some tests I found that were affected by this:
+
+ gdb.base/batch-exit-status.exp
+ gdb.base/many-headers.exp
+ gdb.base/quit.exp
+ gdb.base/with-mf.exp
+ gdb.dwarf2/gdb-add-index.exp
+ gdb.dwarf2/gdb-add-index-symlink.exp
+ gdb.dwarf2/imported-unit-runto-main.exp
+
+ Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca
+
+2021-11-03 Tom Tromey <tromey@adacore.com>
+
+ Use section name in warnings in display_debug_loc
+ While looking at an apparently malformed executable with
+ "readelf --debug-dump=loc", I got this warning:
+
+ readelf: ./main: Warning: There is a hole [0x89 - 0x95] in .debug_loc section.
+
+ However, the executable only has a .debug_loclists section.
+
+ This patch fixes the warning messages in display_debug_loc to use the
+ name of the section that is being processed.
+
+ binutils/ChangeLog
+ 2021-11-03 Tom Tromey <tromey@adacore.com>
+
+ * dwarf.c (display_debug_loc): Use section name in warnings.
+
+2021-11-03 Luis Machado <luis.machado@linaro.org>
+
+ [AArch64] Make gdbserver register set selection dynamic
+ The current register set selection mechanism for AArch64 is static, based
+ on a pre-populated array of register sets.
+
+ This means that we might potentially probe register sets that are not
+ available. This is OK if the kernel errors out during ptrace, but probing the
+ tag_ctl register, for example, does not result in a ptrace error if the kernel
+ supports the tagged address ABI but not MTE (PR 28355).
+
+ Making the register set selection dynamic, based on feature checks, solves
+ this and simplifies the code a bit. It allows us to list all of the register
+ sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.
+
+ I plan to backport this fix to GDB 11 as well.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28355
+
+2021-11-03 Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
+ Currently for a binary compiled normally (without -fsanitize=address) but with
+ LD_PRELOAD of ASAN one gets:
+
+ $ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
+ =================================================================
+ ==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570
+ #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7)
+ ...
+ 0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572)
+ allocated by thread T0 here:
+ #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f)
+ #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81)
+ SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*)
+ ==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
+ ==1909567==ABORTING
+
+ Despite the code called properly operator new[] and operator delete[].
+ But GDB's new-op.cc provides its own operator new[] which gets translated into
+ malloc() (which gets recogized as operatore new(size_t)) but as it does not
+ translate also operators delete[] Address Sanitizer gets confused.
+
+ The question is how many variants of the delete operator need to be provided.
+ There could be 14 operators new but there are only 4, GDB uses 3 of them.
+ There could be 16 operators delete but there are only 6, GDB uses 2 of them.
+ It depends on libraries and compiler which of the operators will get used.
+ Currently being used:
+ U operator new[](unsigned long)
+ U operator new(unsigned long)
+ U operator new(unsigned long, std::nothrow_t const&)
+ U operator delete[](void*)
+ U operator delete(void*, unsigned long)
+
+ Tested on x86_64-linux.
+
+2021-11-03 Alan Modra <amodra@gmail.com>
+
+ asan: dlltool buffer overflow: embedded NUL in string
+ yyleng gives the pattern length, xstrdup just copies up to the NUL.
+ So it is quite possible writing at an index of yyleng-2 overflows
+ the xstrdup allocated string buffer. xmemdup quite handily avoids
+ this problem, even writing the terminating NUL over the trailing
+ quote. Use it in ldlex.l too where we'd already had a report of this
+ problem and fixed it by hand, and to implement xmemdup0 in gas.
+
+ binutils/
+ * deflex.l (single and double quote strings): Use xmemdup.
+ gas/
+ * as.h (xmemdup0): Use xmemdup.
+ ld/
+ PR 20906
+ * ldlex.l (double quote string): Use xmemdup.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mloop: mark a few conditionally used funcs as unused
+ These are marked inline, so building w/gcc at higher optimization
+ levels will automatically discard them. But building with -O0 will
+ trigger unused function warnings, so fix that.
+
+ The common before/after cover functions in the common mloop generator
+ are not used by all architecture ports. Doesn't seem to be a hard
+ requirement, so marking them optional (i.e. unused) is fine.
+
+ The cris execute function is conditionally used depending on the
+ fast-build mode settings, so mark it unused too.
+
+2021-11-03 Alan Modra <amodra@gmail.com>
+
+ asan: assert (addr_ranges) <= (start)
+ That assert would be more obvious if it were reported as
+ "addr_ranges <= end_ranges". Fix that by using the obvious variable
+ in the final loop. Stop the assertion by using a signed comparison:
+ It's possible for the rounding up of the arange pointer to exceed the
+ end of the block when the block size is fuzzed.
+
+ * dwarf.c (display_debug_aranges): Use "end_ranges" in loop
+ displaying ranges rather that "start". Simplify rounding up
+ to 2*address_size boundary. Use signed comparison in loop.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: hoist cgen mloop rules up to common builds
+ These rules don't depend on the target compiler settings, so hoist
+ the build logic up to the common builds for better parallelization.
+
+ We have to extend the genmloop.sh logic a bit to allow outputting
+ to a subdir since it always assumed cwd was the right place.
+
+ We leave the cgen maintainer rules in the subdirs for now as they
+ aren't normally run, and they rely on cgen logic that has not yet
+ been generalized.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: hoist mn10300 & v850 igen rules up to common builds
+ These rules don't depend on the target compiler settings, so hoist
+ the build logic up to the common builds for better parallelization.
+
+ We leave the mips rules in place as they depend on complicated
+ arch-specific configure logic that needs to be untangled first.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: hoist gencode & opc2c build rules up to common builds
+ These rules don't depend on the target compiler settings, so hoist
+ the build logic up to the common builds for better parallelization.
+
+2021-11-03 Mike Frysinger <vapier@gentoo.org>
+
+ opcodes: d10v: simplify header includes
+ This file doesn't use anything from bfd (sysdep.h), so drop that
+ include. This avoids an implicit dependency on the generated
+ config.h which can be problematic for build-time tools.
+
+ Also swap stdio.h for stddef.h. This file isn't doing or using
+ any I/O structures, but it does need NULL.
+
+2021-11-03 Alan Modra <amodra@gmail.com>
+
+ PR28523, ld.bfd created undefined symbols on ppc64
+ This patch removes any fake (linker created) function descriptor
+ symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic
+ symbols are not created. The change to func_desc_adjust requires that
+ it be run only once, which means ppc64_elf_tls_setup can't call it for
+ just a few selected symbols.
+
+ PR 28523
+ * elf64-ppc.c (func_desc_adjust): If a function entry sym is
+ not dynamic and has no plt entry, hide any associated fake
+ function descriptor symbol.
+ (ppc64_elf_edit): Move func_desc_adjust iteration over syms to..
+ (ppc64_elf_tls_setup): ..here.
+
+2021-11-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep, rs6000] Don't skip system call in skip_prologue
+ I ran into a case where a breakpoint on _exit never triggered, because it was
+ set past the end of the _exit prologue, past the end of the exit_group system
+ call (which does not return).
+
+ More concretely, the breakpoint was set at the last insn show here:
+ ...
+ Dump of assembler code for function _exit:
+ 0x00007ffff7e42ea0 <+0>: 12 00 4c 3c addis r2,r12,18
+ 0x00007ffff7e42ea4 <+4>: 60 43 42 38 addi r2,r2,17248
+ 0x00007ffff7e42ea8 <+8>: 00 00 00 60 nop
+ 0x00007ffff7e42eac <+12>: f8 ff e1 fb std r31,-8(r1)
+ 0x00007ffff7e42eb0 <+16>: 78 1b 7f 7c mr r31,r3
+ 0x00007ffff7e42eb4 <+20>: f0 ff c1 fb std r30,-16(r1)
+ 0x00007ffff7e42eb8 <+24>: ea 00 00 38 li r0,234
+ 0x00007ffff7e42ebc <+28>: a0 8b 22 e9 ld r9,-29792(r2)
+ 0x00007ffff7e42ec0 <+32>: 78 fb e3 7f mr r3,r31
+ 0x00007ffff7e42ec4 <+36>: 14 6a c9 7f add r30,r9,r13
+ 0x00007ffff7e42ec8 <+40>: 02 00 00 44 sc
+ 0x00007ffff7e42ecc <+44>: 26 00 00 7c mfcr r0
+ 0x00007ffff7e42ed0 <+48>: 00 10 09 74 andis. r9,r0,4096
+ ...
+
+ Fix this by treating system calls the same as branches in skip_prologue:
+ by default, don't skip, such that the breakpoint is set at 0x00007ffff7e42eb8
+ instead.
+
+ Tested on ppc64le-linux, on a power 8 machine.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28527
+
+2021-11-02 Tom de Vries <tdevries@zinfandel-3.arch.suse.de>
+
+ [gdb/testsuite] Handle SIGILL in two gdb.arch powerpc test-cases
+ On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into
+ SIGILL:
+ ...
+ (gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3"
+ stepi^M
+ ^M
+ Program terminated with signal SIGILL, Illegal instruction.^M
+ The program no longer exists.^M
+ (gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4
+ ...
+ because it's a power9 insn, and I'm running on a power8 machine.
+
+ Fix this by handling the SIGILL. Likewise in gdb.arch/powerpc-lnia.exp.
+
+ Tested on powerpc64le-linux.
+
+2021-11-02 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/sim: update my email address
+ gdb:
+
+ * MAINTAINERS (Global Maintainers): Update my address.
+ (Responsible Maintainers): Likewise.
+ (Write After Approval): Likewise.
+
+ sim:
+
+ * MAINTAINERS (Global Maintainers): Update my address.
+
+2021-11-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix stepi test-cases with unix/-m32/-fPIE/-pie
+ When running test-case gdb.base/step-indirect-call-thunk.exp with target board
+ unix/-m32/-fPIE/-pie, I run into:
+ ...
+ (gdb) stepi^M
+ 0x5655552e 22 { /* inc.1 */^M
+ (gdb) stepi^M
+ 0x56555530 22 { /* inc.1 */^M
+ (gdb) stepi^M
+ 0x565555f7 in __x86.get_pc_thunk.ax ()^M
+ (gdb) FAIL: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
+ ...
+
+ In contrast, with unix/-m32 we have instead:
+ ...
+ (gdb) stepi^M
+ 0x08048407 22 { /* inc.1 */^M
+ (gdb) stepi^M
+ 23 return x + 1; /* inc.2 */^M
+ (gdb) stepi^M
+ 0x0804840c 23 return x + 1; /* inc.2 */^M
+ (gdb) stepi^M
+ 24 } /* inc.3 */^M
+ (gdb) stepi^M
+ 0x08048410 24 } /* inc.3 */^M
+ (gdb) stepi^M
+ 0x0804848f in __x86_return_thunk ()^M
+ (gdb) PASS: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
+ ...
+
+ The test-case doesn't expect to run into __x86.get_pc_thunk.ax, which is a
+ PIC helper function for x86_64-linux.
+
+ Fix this by insn-stepping through it.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux.
+
+2021-11-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-11-01 Alan Modra <amodra@gmail.com>
+
+ ARM: match armeb output for unwind-pacbti-m test
+ * testsuite/gas/arm/unwind-pacbti-m.d: Match armeb output.
+
+2021-11-01 Bruno Larsen <blarsen@redhat.com>
+
+ [gdb/doc]: Updated manpages to be consistent with help
+ Updated manpages to be consistent with help information provided by the
+ binary. The main changes are:
+
+ * Making all long-form options have '--', instead of a single '-';
+ * added most of the missing options to the manpage;
+ * removed the information about using '+' instead of '-', since it
+ doesn't seem to be supported anymore.
+
+ This also fixes 2 upstream bugs:
+ * https://sourceware.org/bugzilla/show_bug.cgi?id=23965; by adding
+ --args to the manpage
+ * https://sourceware.org/bugzilla/show_bug.cgi?id=10619; by adding the
+ double dashes
+
+2021-11-01 Alan Modra <amodra@gmail.com>
+
+ macho-o archive sanity checks
+ Anti-fuzzing checks.
+
+ * mach-o.c (bfd_mach_o_fat_archive_p): Sanity check entry offset
+ and size against file size.
+
+2021-11-01 Alan Modra <amodra@gmail.com>
+
+ objcopy buffer overflow
+ "tocopy" in this code was an int, which when the size to be copied was
+ larger than MAXINT could result in tocopy being negative. A negative
+ value of course is less than BUFSIZE, but when converted to
+ bfd_size_type is extremely large.
+
+ PR 995
+ * objcopy.c (copy_unknown_object): Correct calculation of "tocopy".
+ Use better variable types.
+
+2021-11-01 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ arm: add armv9-a architecture to -march
+ Update also include:
+ + New value of Tag_CPU_arch EABI attribute (22) is added.
+ + Updated missing Tag_CPU_arch EABI attributes.
+ + Updated how we combine archs 'v4t_plus_v6_m' as this mechanism
+ have to handle new Armv9 as well.
+
+ Regression tested on `arm-none-eabi` cross Binutils and no issues.
+
+ bfd/
+
+ * archures.c: Define bfd_mach_arm_9.
+ * bfd-in2.h (bfd_mach_arm_9): Define bfd_mach_arm_9.
+ * cpu-arm.c: Add 'armv9-a' option to -march.
+ * elf32-arm.c (using_thumb2_bl): Update assert check.
+ (arch_has_arm_nop): Add TAG_CPU_ARCH_V9.
+ (bfd_arm_get_mach_from_attributes): Add case for TAG_CPU_ARCH_V9.
+ Update assert.
+ (tag_cpu_arch_combine): Updated table.
+ (v9): New table..
+
+ binutils/
+
+ * readelf.c (arm_attr_tag_CPU_arch): Update with
+
+ elfcpp/
+
+ * arm.h: Update TAG_CPU_ARCH_ enums with correct values.
+
+ gas/
+
+ * NEWS: Update docs.
+ * config/tc-arm.c (get_aeabi_cpu_arch_from_fset): Return Armv9-a
+ for -amarch=all.
+ (aeabi_set_public_attributes): Update assert.
+ * doc/c-arm.texi: Update docs.
+ * testsuite/gas/arm/armv9-a_arch.d: New test.
+ * testsuite/gas/arm/attr-march-all.d: Update test with v9.
+
+ include/
+
+ * elf/arm.h Update TAG_CPU_ARCH_ defines with correct values.
+ * opcode/arm.h (ARM_EXT3_V9A): New macro.
+ (ARM_ARCH_NONE): Updated with arm_feature_set.core size.
+ (FPU_NONE): Updated.
+ (ARM_ANY): Updated.
+ (ARM_ARCH_UNKNOWN): New macro.
+ (ARM_FEATURE_LOW): Updated.
+ (ARM_FEATURE_CORE): Updated.
+ (ARM_FEATURE_CORE_LOW): Updated.
+ (ARM_FEATURE_CORE_HIGH): Updated.
+ (ARM_FEATURE_COPROC): Updated.
+ (ARM_FEATURE): Updated.
+ (ARM_FEATURE_ALL): New macro.
+
+ opcodes/
+
+ * arm-dis.c (select_arm_features): Support bfd_mach_arm_9.
+ Also Update bfd_mach_arm_unknown to use new macro ARM_ARCH_UNKNOWN.
+
+2021-11-01 Mike Frysinger <vapier@gentoo.org>
+
+ sim: iq2000: reduce -Wno-error scope
+ Clean up the warnings in sim-if, then reduce the -Werror disable to
+ the files that still aren't clean that now that we require GNU make
+ and can set variables on a per-object basis.
+
+ sim: lm32: reduce -Wno-error scope
+ Clean up some warnings in dv-lm32cpu, and all in sim-if, then reduce
+ the -Werror disable to the files that still aren't clean that now that
+ we require GNU make and can set variables on a per-object basis.
+
+ sim: frv: reduce -Wno-error scope
+ Only two files in here still generates warnings, so reduce the -Werror
+ disable to that now that we require GNU make and can set variables on
+ a per-object basis.
+
+ sim: m32r: reduce -Wno-error scope
+ Only two files in here still generates warnings, so reduce the -Werror
+ disable to that now that we require GNU make and can set variables on
+ a per-object basis.
+
+ sim: mips: reduce -Wno-error scope
+ Fix a few printf warnings in sim-main.c, and then we're left with only
+ one file in here still generating warnings, so reduce the -Werror
+ disable to that alone now that we require GNU make and can set variables
+ on a per-object basis.
+
+ sim: erc32: reduce -Wno-error scope
+ Only one file in here still generates warnings, so reduce the -Werror
+ disable to that alone now that we require GNU make and can set variables
+ on a per-object basis.
+
+ sim: cris: reduce -Wno-error scope
+ Only two files in here still generates warnings, so reduce the -Werror
+ disable to that now that we require GNU make and can set variables on
+ a per-object basis.
+
+ sim: sh: reduce -Wno-error scope
+ Only one file in here still generates warnings, so reduce the -Werror
+ disable to that alone now that we require GNU make and can set variables
+ on a per-object basis.
+
+ sim: or1k: build with -Werror
+ The only warnings left in this port are a few maybe-uninitialized,
+ but we don't abort the build for them, so turn on -Werror everywhere.
+
+ sim: igen: minor build output alignment fix
+ The custom echo was off by one space relative to all the others.
+
+ sim: ppc: fix the printf fix for 32-bit systems
+ The time delta is a 64-bit value too.
+
+ sim: m68hc11: clean up pointer casts
+ The void *data field is used to past arbitrary data between event
+ handlers, and these are using it to pass an integer. Fix up the
+ casts to avoid using (long) to cast to/from pointers since there
+ is no guarantee that's the right size.
+
+ sim: d10v: clean up pointer casts
+ Use %p to print pointers instead of trying to cast them to longs.
+
+ sim: bfin: cast pointers using uintptr_t
+ We can't assume that sizeof(long) == sizeof(void*), so change all
+ these casts over to uintptr_t.
+
+ sim: ppc: clean up printf format handling
+ Don't blindly cast every possible type to (long). Change to the right
+ printf format specifier whether it be a 64-bit type or a pointer.
+
+ sim: ppc: switch core types to stdint.h types
+ There's no need to define these ourselves anymore, so switch to the
+ stdint.h types. This will be important when we start using PRI*
+ defines with printf formats.
+
+ sim: mn10300: clean up pointer casts
+ The void *data field is used to past arbitrary data between event
+ handlers, and these are using it to pass an enum. Fix up the casts
+ to avoid using (long) to cast to/from pointers since there is no
+ guarantee that's the right size.
+
+ sim: events: clean up trace casts
+ Don't blindly cast every possible type to (long). Change to the right
+ printf format specifier whether it be a 64-bit type or a pointer.
+
+ sim: ppc: handle \r in igen inputs [PR sim/28476]
+ Make sure we consume & ignore \r bytes in inputs in case the file
+ encodings are from a non-LF systems (e.g. Windows).
+
+ sim: ppc: constify strings in igen tooling
+
+2021-11-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-31 Tom Tromey <tom@tromey.com>
+
+ Fix latent bug in DWARF test case
+ On my branch that replaces the DWARF psymtab reader,
+ dw2-stack-boundary.exp started failing. However, when I look at the
+ output in gdb.log, it is correct:
+
+ file /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary
+ Reading symbols from /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary...
+ During symbol reading: location description stack overflow
+ During symbol reading: location description stack underflow
+
+ What happens to cause the failure is that the two branches in
+ gdb_test_multiple appear in this order:
+
+ -re "\r\nDuring symbol reading: location description stack underflow" {
+ [...]
+ -re "\r\nDuring symbol reading: location description stack overflow" {
+
+ The first one will match the above, without causing the second one to
+ ever match -- leading to a spurious failure.
+
+ Anchoring the regexps seems to fix the problem, and works for the
+ current gdb as well.
+
+2021-10-31 Tom Tromey <tom@tromey.com>
+
+ Fix unittest.exp failure due to 'set debuginfod' addition
+ The 'set debuginfod' change caused a regression in unittest.exp:
+
+ Running selftest help_doc_invariants.
+ help doc broken invariant: command 'info set debuginfod' help doc first line is not terminated with a '.' character
+ help doc broken invariant: command 'set debuginfod' help doc first line is not terminated with a '.' character
+ help doc broken invariant: command 'show debuginfod' help doc first line is not terminated with a '.' character
+ Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/command-def-selftests.c:100
+
+ This patch fixes the problem. I'm checking it in.
+
+2021-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: use silent build rules here too
+ The ppc codebase is unique and doesn't leverage common/, so have to
+ add silent rules to it specifically.
+
+ sim: rl78: drop obsolete manual dependency rules
+ We have GNU make generate these for us automatically now, so there's
+ no need to manually specify any deps.
+
+ sim: drop unused targ-vals.h includes
+ This is used in a few places where it's not needed. Drop the include
+ to avoid the build-time generated header file as we move to drop it.
+
+ sim: unify callback.o building
+ Now that the use of TARGET_xxx defines have been removed, we can move
+ this to the common logic so we only build it once for multi-targets.
+
+ sim: nltvals: pull target open flags out into a dedicated source file
+ Like we just did for pulling out the errno & signal maps, pull out the
+ open flag map into a dedicated common file. All newlib ports are using
+ the same map which makes it easy.
+
+ sim: nltvals: localize TARGET_<open> defines
+ Code should not be using these directly, instead they should be
+ resolving these dynamically via the open_map. Rework the common
+ callback code that was using the defines to use symbolic names
+ instead, and localize some of the defines in the ARM code (since
+ it's a bit unclear how many different APIs it supports currently),
+ then remove the defines out of the header so no new code can rely on
+ them.
+
+ sim: nltvals: pull target signal out into a dedicated source file
+ Like we just did for pulling out the errno map, pull out the signal
+ map into a dedicated common file. All newlib ports are using the
+ same signal map which makes it easy.
+
+2021-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: nltvals: pull target errno out into a dedicated source file
+ The current system maintains a list of target errno constants in the
+ nltvals.def file, then runs a build-time tool to turn that into a C
+ file. This list of errno values is the same for all arches, so we
+ don't need the arch-specific flexibility. Further, these are only
+ for newlib/libgloss environments, which makes it confusing to support
+ other userland runtimes (like Linux). Let's simplify to make this
+ easier to understand & build. We don't namespace the variables yet,
+ but sets up the framework for it.
+
+ Create a new target-newlib-errno.c template file. The template file
+ is hand written, but the inline map is still automatically generated.
+
+ This allows us to move it to the common set of objects so it's only
+ built once in a multi-target build.
+
+ Now we can remove the output from the gentmap build-time tool since
+ it's checked into the tree.
+
+ Then we stop including the errno lists in nltvals.def since nothing
+ uses it.
+
+2021-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: erc32: use silent build rules with sis linkage
+
+2021-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: erc32: fix a few more build warnings
+ Tweak the if indentation & brace style to avoid ambiguous warnings.
+
+ Add ATTRIBUTE_UNUSED to UART functions that aren't used when FAST_UART
+ is defined (which is the default).
+
+2021-10-31 Orgad Shaneh <orgads@gmail.com>
+
+ sim: erc32: fix signedness compatibility and redefinition warnings
+
+2021-10-31 Mike Frysinger <vapier@gentoo.org>
+
+ sim: add arch-specific conditional logic
+ This will make it easy to include arch-specific logic (build files)
+ as we migrate ports to the common top level build.
+
+ sim: v850: delete old gencode logic
+ The v850 port used to have a gencode helper, but it was deleted long
+ ago. Clean up the settings that no longer make sense w/out it.
+
+ sim: common: merge multiple clean commands
+ This provides a minor speedup when cleaning in a multi-target build.
+
+ sim: m32c: tighten up opc2c build output
+ Drop the single debugging line that repeats the command line option,
+ and use the silent build helpers to tighten up output.
+
+ sim: tighten up build regen rules
+ Update the makefile & configure related rules to use the silent
+ build helpers.
+
+ sim: tighten up gencode output
+ Update the gencode rules to use the silent build helpers.
+
+ sim: igen: tighten up build output
+ Add a new stamp helper for quiet builds, and don't dump the command
+ line options when it runs. That isn't standard tool behavior, and
+ doesn't really seem necessary in any way.
+
+ sim: tighten up stamp rules
+ Add a new ECHO_STAMP helper and convert existing stamp code over
+ to it. This is mostly common rules and cgen mloop rules.
+
+ sim: silence stamp touch rules
+ We pretty much never care about these stamp touches, so silence them.
+ Also switch to using $@ when it makes sense.
+
+ sim: standardize move-if-change rules
+ Use the srcroot path and make them all silent.
+
+ sim: mips/v850: remove redundant variable setup
+ The common/Make-common.in fragment already provides these variables.
+
+2021-10-31 Orgad Shaneh <orgads@gmail.com>
+
+ sim: fix compilation on mingw64 [PR sim/28476]
+ ...by reordering includes.
+
+ 1. sim-utils.c
+
+ sim/mips/sim-main.h defines UserMode, while there is a struct in winnt.h
+ which has UserMode as a member. So if sim-main.h is included before winnt.h,
+ compilation fails.
+
+ 2. ppc
+
+ registers.h defines CR, which is used as a member in winnt.h.
+
+ winsock2.h is included by sys/time.h, so sys/time.h has to be included
+ before registers.h.
+
+ Bug: https://sourceware.org/PR28476
+
+2021-10-31 Alan Modra <amodra@gmail.com>
+
+ Don't include coff/pe.h in coff-x86_64.c
+ This (and other) code from coffcode.h is broken for x86_64_coff_vec,
+ and has been ever since support was added in 2006 commit 99ad839030c1
+ Here, bfd_coff_aoutsz must match coff_swap_aouthdr_out otherwise we
+ end up writing garbage.
+
+ /* Note that peicode.h fills in a PEAOUTHDR, not an AOUTHDR.
+ include/coff/pe.h sets AOUTSZ == sizeof (PEAOUTHDR)). */
+ char * buff;
+ bfd_size_type amount = bfd_coff_aoutsz (abfd);
+
+ buff = (char *) bfd_malloc (amount);
+ if (buff == NULL)
+ return false;
+
+ coff_swap_aouthdr_out (abfd, & internal_a, buff);
+ amount = bfd_bwrite (buff, amount, abfd);
+
+ We have removed support for --target=x86_64-coff, likely because it
+ never worked properly, but still produce coff-x86_64.o with
+ --enable-targets=all. This means objcopy can recognize x86_64 COFF
+ files but will write garbage to the output file, a fact found by
+ fuzzers. I suspect x86_64 COFF is still broken after this fix, and
+ mention of coff-x86_64.* should be removed from bfd/Makefile.am.
+
+ * coff-x86_64.c: Don't include coff/pe.h.
+ (COFF_WITH_pex64): Don't define here.
+ * pe-x86_64.c: Include coff/pe.h and other headers.
+ (PEI_HEADERS): Define.
+
+2021-10-31 Alan Modra <amodra@gmail.com>
+
+ Re: PR28420, ecoff fuzzing failures
+ sym_ptr_ptr NULL results in segfaults.
+
+ PR 28420
+ * ecoff.c (ecoff_slurp_reloc_table): Don't leave sym_ptr_ptr NULL.
+
+2021-10-31 Alan Modra <amodra@gmail.com>
+
+ ubsan: alpha-vms: undefined shift
+ * vms-alpha.c (evax_bfd_print_image): Shift left 1u.
+
+ PR28518: signed integer overflow & free on unmalloced address
+ PR 28518
+ * vms-alpha.c (build_module_list): Don't lose malloc buffer address.
+ Use unsigned variables.
+
+2021-10-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix gdb.gdb/unittest.exp with C++17 compiler
+ On a machine with gcc 11, I get:
+
+ FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_v" (second tab) (timeout)
+ FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_vie" (timeout)
+
+ That's because when compiling with C++ >= 17, we use the standard
+ version of string_view, and don't have a selftest for it. So the list
+ of selftests shown by the tab completion when completing "string_v"
+ differs.
+
+ Change the test to use the copy_* tests instead.
+
+ Change-Id: I85f6aa44ee5fc9652b9bd4451e0506b89773526b
+
+2021-10-30 Aaron Merey <amerey@redhat.com>
+
+ gdb.texinfo: Expand documentation for debuginfod
+ Add section describing GDB's usage of debuginfod.
+
+ Refer to this new section in the description of the '--with-debuginfod'
+ configure option.
+
+ Mention debuginfod in the 'Separate Debug Files' section.
+
+2021-10-30 Aaron Merey <amerey@redhat.com>
+
+ gdb: add set/show commands for managing debuginfod
+ Add 'set debuginfod' command. Accepts 'on', 'off' or 'ask' as an
+ argument. 'on' enables debuginfod for the current session. 'off'
+ disables debuginfod for the current session. 'ask' will prompt
+ the user to either enable or disable debuginfod when the next query
+ is about to be performed:
+
+ This GDB supports auto-downloading debuginfo from the following URLs:
+ <URL1> <URL2> ...
+ Enable debuginfod for this session? (y or [n]) y
+ Debuginfod has been enabled.
+ To make this setting permanent, add 'set debuginfod on' to .gdbinit.
+
+ For interactive sessions, 'ask' is the default. For non-interactive
+ sessions, 'off' is the default.
+
+ Add 'show debuginfod status' command. Displays whether debuginfod
+ is set to 'on', 'off' or 'ask'.
+
+ Add 'set/show debuginfod urls' commands. Accepts a string of
+ space-separated debuginfod server URLs to be queried. The default
+ value is copied from the DEBUGINFOD_URLS environment variable.
+
+ Finally add 'set/show debuginfod verbose' commands to control whether
+ debuginfod-related output is displayed. Verbose output is enabled
+ by default.
+
+ (gdb) run
+ Starting program: /bin/sleep 5
+ Download failed: No route to host. Continuing without debug info for /lib64/libc.so.6.
+
+ If GDB is not built with debuginfod then these commands will just display
+
+ Support for debuginfod is not compiled into GDB.
+
+2021-10-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_DWARF_BLOCK
+ Remove TYPE_FIELD_DWARF_BLOCK, replace with type::field +
+ field::loc_dwarf_block.
+
+ Change-Id: I10af9410bb5f46d342b8358a7956998c7e804b64
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_STATIC_PHYSADDR
+ Remove TYPE_FIELD_STATIC_PHYSADDR replace with type::field +
+ field::loc_physaddr.
+
+ Change-Id: Ica9bc4a48f34750ec82ec86c298d3ecece81bcbd
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_STATIC_PHYSNAME
+ Remove TYPE_FIELD_STATIC_PHYSNAME, replace with type::field +
+ field::loc_physname.
+
+ Change-Id: Ie35d446b67dd1d02f39998b406001bdb7e6d5abb
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_ENUMVAL
+ Remove TYPE_FIELD_ENUMVAL, replace with type::field +
+ field::loc_enumval.
+
+ Change-Id: I2ada73e4635aad3363ce2eb22c1dc52698ee2072
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_BITPOS
+ Remove TYPE_FIELD_BITPOS, replace its uses with type::field +
+ field::loc_bitpos.
+
+ Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_LOC_KIND
+ Remove TYPE_FIELD_LOC_KIND, replace its uses with type::field +
+ field::loc_kind.
+
+ Change-Id: Ib124a26365df82ac1d23df7962d954192913bd90
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_DWARF_BLOCK macro
+ Remove FIELD_DWARF_BLOCK, replace its uses with field::loc_dwarf_block.
+
+ Change-Id: I66b7d6a960cb5e341e61e21bd3cc9a6ac26de6a8
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_STATIC_PHYSADDR macro
+ Remove FIELD_LOC_KIND_PHYSADDR, replace its uses with
+ field::loc_physaddr.
+
+ Change-Id: Ifd8b2bdaad75f42bfb1404ef8c396ffe7e10ac55
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_STATIC_PHYSNAME macro
+ Remove FIELD_STATIC_PHYSNAME, replace its uses with field::loc_physname.
+
+ Change-Id: Iaa8952410403b4eb5bbd68411feea27e2405d657
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_ENUMVAL macro
+ Remove FIELD_ENUMVAL, replace its uses with field::loc_enumval.
+
+ Change-Id: Id4861cee91a8bb583a9836f1aa5da0a320fbf4d9
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_BITPOS macro
+ Remove FIELD_BITPOD, replace its uses with field::loc_bitpos.
+
+ Change-Id: Idb99297e0170661254276c206383a7e9bf1a935a
+
+2021-10-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove FIELD_LOC_KIND macro
+ Remove FIELD_LOC_KIND, replace its uses with field::loc_kind or
+ call_site_target::loc_kind.
+
+ Change-Id: I0368d8c3ea269d491bb215aa70e32edbdf55f389
+
+2021-10-29 Tom Tromey <tromey@adacore.com>
+
+ Add gdb.Architecture.integer_type Python function
+ This adds a new Python function, gdb.Architecture.integer_type, which
+ can be used to look up an integer type of a given size and
+ signed-ness. This is useful to avoid dependency on debuginfo when a
+ particular integer type would be useful.
+
+ v2 moves this to be a method on gdb.Architecture and addresses other
+ review comments.
+
+2021-10-29 Tom Tromey <tromey@adacore.com>
+
+ Remove ada_value_print_inner
+ I noticed that the only caller of ada_value_print_inner is
+ valprint.c:do_val_print (via ada_language::value_print_inner), meaning
+ that the try/catch logic in this function is redundant. This patch
+ removes the wrapper function.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-10-29 Tom Tromey <tromey@adacore.com>
+
+ Document resolve_dynamic_type oddity
+ Today I re-learned that resolve_dynamic_type can return a type for
+ which is_dynamic_type returns true. This can happen for an array
+ whose elements have dynamic type -- the array is reported as dynamic,
+ but resolving the elements would be incorrect, because each element
+ might have a different type after resolution.
+
+ You can see the special case in resolve_dynamic_array_or_string:
+
+ if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
+ ...
+ else
+ ...
+
+ I looked into having the TYPE_CODE_ARRAY case in
+ is_dynamic_type_internal follow this same logic, but that breaks down
+ on the gdb.fortran/dynamic-ptype-whatis.exp test case. In particular
+ this code in fortran_undetermined::evaluate:
+
+ value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
+ if (noside == EVAL_AVOID_SIDE_EFFECTS
+ && is_dynamic_type (value_type (callee)))
+ callee = std::get<0> (m_storage)->evaluate (nullptr, exp, EVAL_NORMAL);
+
+ ... relies on is_dynamic_type returning true for such an array.
+
+ I wasn't really sure of the best way to fix this, so in the meantime I
+ wrote this patch, which documents the oddity so that I might have a
+ chance of remembering this in the future.
+
+2021-10-29 Tom Tromey <tromey@adacore.com>
+
+ Avoid self-test failures on x86-linux
+ The disassembly tests in "maint selftest" will fail on x86-linux.
+ This happens because opcodes rejects an attempt to disassemble for an
+ arch with a 64-bit address size when bfd_vma is 32-bit.
+
+ This patch avoids this problem by avoiding the test in this case. I
+ chose to do it this way because this seems to be the only situation
+ where opcodes checks the size of bfd_vma.
+
+ For v2 of this patch, I've also updated memory_error_test to do the
+ same thing. This is needed due to the "improve error reporting from
+ the disassembler" patch.
+
+2021-10-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with --disable-unit-tests
+ A build with --disable-unit-tests currently run into:
+ ...
+ ld: maint.o: in function \
+ `maintenance_selftest_completer(cmd_list_element*, completion_tracker&,
+ char const*, char const*)':
+ src/gdb/maint.c:1183: undefined reference to \
+ `selftests::for_each_selftest(
+ gdb::function_view<
+ void (std::__cxx11::basic_string<char,std::char_traits<char>,
+ std::allocator<char> > const&)>)'
+ ...
+
+ Fix this by guarding the call to selftests::for_each_selftest in
+ maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose"
+ completion still works.
+
+ Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp.
+
+2021-10-29 Enze Li <lienze2010@hotmail.com>
+
+ Document "memory-tag-violations".
+ * gdb/doc/gdb.texinfo: (Data): Document '-memory-tag-violations'.
+ (Command Options): Update the example.
+
+2021-10-29 Tejas Belagod <tejas.belagod@arm.com>
+
+ Support for a new pacbti unwind opcode.
+ This patch adds readelf support for decoding the exception table
+ opcode for restoring the RA_AUTH_CODE pseudo register defined by the
+ EHABI
+ (https://github.com/ARM-software/abi-aa/releases/download/2021Q1/ehabi32.pdf
+ Section 10.3).
+
+ * readelf.c (decode_arm_unwind_bytecode): Add support to decode
+ restoring RA_AUTH_CODE pseudo register.
+
+2021-10-29 Alan Modra <amodra@gmail.com>
+
+ Re: arm: add unwinder encoding support for PACBTI
+ Move the gas testsuite files to where they belong.
+
+2021-10-29 Alan Modra <amodra@gmail.com>
+
+ ELF core file size checks
+ Catch fuzzed segments where p_offset + p_filesz wraps, and limit error
+ output.
+
+ * elfcore.h (elf_core_file_p): Rewrite segment checks using
+ bfd_get_file_size. Set read_only on file size errors.
+ * elfcode.h (elf_swap_shdr_in): Don't repeat error message.
+
+2021-10-29 Alan Modra <amodra@gmail.com>
+
+ obcopy vs. files with silly section alignment
+ We already ignore stupid segment alignment when rewriting headers,
+ ignore section alignment too.
+
+ * elf.c (rewrite_elf_program_header): Ignore section alignment
+ power greater than 62.
+
+2021-10-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-28 Stafford Horne <shorne@gmail.com>
+
+ gdb: Add OpenRISC gdbserver and native config news
+ The previous patches added gdbserver and native debugging support
+ for OpenRISC targets. This patch documents that in the news.
+
+ gdb: or1k: add single step for linux native debugging
+ Needed for single stepping in Linux, this adds the or1k implementation
+ of or1k_software_single_step. Most of the implementation is borrowed
+ from the bare metal single step code from or1k_single_step_through_delay
+ which has been extracted and shared in helper function
+ or1k_delay_slot_p.
+
+2021-10-28 Stafford Horne <shorne@gmail.com>
+
+ gdb: or1k: add native linux support
+ This patch adds support for running gdb natively on OpenRISC linux.
+ Debugging support is provided via the linux PTRACE interface which is
+ mostly handled by GDB genric code. This patch provides the logic of how
+ to read and write the ptrace registers between linux and GDB.
+
+ Single stepping is privided in a separate patch.
+
+2021-10-28 Stafford Horne <shorne@gmail.com>
+
+ gdb: or1k: add generated linux descriptor file
+
+ gdb: or1k: fixup linux regcache comment
+ The old comment was not properly updated from the RISC-V example used.
+ Update it to match OpenRISC.
+
+2021-10-28 Stafford Horne <shorne@gmail.com>
+
+ gdb: or1k: implement gdb server
+ This patch adds gdbserver support for OpenRISC. This has been used for
+ debugging the glibc port that in being worked on here:
+
+ https://github.com/openrisc/or1k-glibc/tree/or1k-port-2
+
+ Hence the comment about registers definitions being inline with glibc.
+
+2021-10-28 Christian Biesinger <cbiesinger@google.com>
+
+ [sim] Include defs.h in ppc/hw_memory.c
+ To fix this error (seen on cygwin):
+ /../../sim/ppc/../common ../../../sim/ppc/hw_memory.c
+ In file included from ../../gnulib/import/stdlib.h:100,
+ from ../../../sim/ppc/hw_memory.c:28:
+ ../../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first."
+ 663 | #error "Please include config.h first."
+ | ^~~~~
+ ../../gnulib/import/unistd.h:665:24: error: expected ';' before 'extern'
+ 665 | _GL_INLINE_HEADER_BEGIN
+ | ^
+ | ;
+ ../../gnulib/import/unistd.h:2806:22: error: expected ';' before 'extern'
+ 2806 | _GL_INLINE_HEADER_END
+ | ^
+ | ;
+
+2021-10-28 Markus Klein <markus.klein@sma.de>
+
+ ARM assembler: Allow up to 32 single precision registers in the VPUSH and VPOP instructions.
+ PR 28436
+ * config/tc-arm.c (do_vfp_nsyn_push_pop_check): New function.
+ (do_vfp_nsyn_pop): Use the new function.
+ (do_vfp_nsyn_push): Use the new function.
+ * testsuite/gas/arm/v8_1m-mve.s: Add new instructions.
+ * testsuite/gas/arm/v8_1m-mve.d: Updated expected disassembly.
+
+2021-10-28 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: use ptid_t::to_string in infrun debug messages
+ In debug messages, I think it would be more helpful to print ptid using
+ the simple "pid.lwp.tid" notation in infrun debug messages. I am
+ currently debugging some fork issues, and find the pid_to_str output not
+ so useful, as it doesn't tell which process a thread belongs to.
+
+ It currently shows up like this:
+
+ [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7d95740 (LWP 892942)] at 0x55555555521f
+
+ With the patch, it shows up like this:
+
+ [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [894072.894077.0] at 0x5555555551d9
+
+ Change-Id: I130796d7dfb0d8e763b8358d8a6002701d80c4ea
+
+2021-10-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add selftest name completion
+ After the previous commit, it is easy to add completion for selftest
+ names. Again, this is not particularly high value, but I rarely touched
+ completion, so it served as a simple example to get some practice.
+
+ Change the for_each_selftest_ftype parameter to gdb::function_view, so
+ that we can pass a lambda that captures things.
+
+ Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
+
+2021-10-28 Tejas Belagod <Tejas.Belagod@arm.com>
+
+ arm: add unwinder encoding support for PACBTI
+ This patch adds support for encoding the Return Address Authentication pseudo
+ register - '.save {ra_auth_code}' as defined by the DWARF ABI - in the
+ exception tables where the opcode is defined by the EHABI
+
+ gas/Changelog:
+
+ * config/tc-arm.c (arm_reg_type): Add new type REG_TYPE_PSEUDO.
+ (reg_expected_msgs): Add message for pseudo reg type.
+ (reg_list_els): Add new reg list type REGLIST_PSEUDO.
+ (parse_reg_list): Handle new REGLIST_PSEUDO type.
+ (s_arm_unwind_save_pseudo): Encode pseudo reg list save in exception
+ tables.
+ (s_arm_unwind_save): Handle new REG_TYPE_PSEUDO.
+ (reg_names): Add ra_auth_code pseudo register.
+ * testsuite/gas/arm/unwind-pacbti-m.s: New test.
+ * testsuite/gas/arm/unwind-pacbti-m.d: New test.
+ * testsuite/gas/arm/unwind-pacbti-m-readelf.d: New test.
+
+2021-10-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add "maint set/show selftest verbose" commands and use process_options
+ I saw the new -verbose switch to "maint selftests" and thought it would
+ be nice for it to use the option framework. For example, that makes
+ having completion easy. It's not that high value, given this is a
+ maintenance command, but I had never used the framework myself, so it
+ was a good way to practice.
+
+ This patch also adds the "maint set/show selftest verbose" setting. It
+ would be possible to use option framework without adding the setting,
+ but using the framework makes adding the option almost trivial, so I
+ thought why not.
+
+ Change-Id: I6687faa0713ff3da60b398253211777100094144
+
+2021-10-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Update some test-cases to GPLv3
+ I noticed some files in the test-suite have GPLv2 notices.
+
+ Update these to GPLv3.
+
+2021-10-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add add_setshow_prefix_cmd
+ There's a common pattern to call add_basic_prefix_cmd and
+ add_show_prefix_cmd to add matching set and show commands. Add the
+ add_setshow_prefix_cmd function to factor that out and use it at a few
+ places.
+
+ Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
+
+2021-10-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require python in gdb.server/server-kill-python.exp
+ I came across this when running test-case gdb.server/server-kill-python.exp
+ with a gdb configured without python:
+ ...
+ builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 \
+ -iex set width 0 -quiet -iex set height 0 -iex set width 0 \
+ -ex source outputs/gdb.server/server-kill-python/file1.py^M
+ FAIL: gdb.server/server-kill-python.exp: ensure inferior is running
+ Executing on target: kill -9 28535 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 28535^M
+ file1.py:1: Error in sourced command file:^M
+ Undefined command: "import". Try "help".^M
+ ...
+
+ Fix this by testing for python support in the test-case.
+
+ Tested on aarch64-linux (with python support disabled) and x86_64-linux (with
+ python support enabled).
+
+2021-10-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix assembly comments in gdb.dwarf2/clang-debug-names.exp.tcl
+ On openSUSE Leap 15.2 aarch64 I ran into:
+ ...
+ clang-debug-names-debug.S:72: \
+ Error: junk at end of line, first unrecognized character is `#'
+ ...
+ due to:
+ ...
+ 71 .Ldebug_names_start:
+ 72 .short 5 # Header: version
+ ...
+
+ Fix this by using the /* ... */ comment style instead:
+ ...
+ $ sed -i 's% #\([^"]*\)%/*\1 */%' clang-debug-names.exp.tcl
+ ...
+
+ Tested on aarch64-linux and x86_64-linux.
+
+2021-10-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Handle DW_AT_string_length with location list
+ Consider a fortran routine where a string variable s is modified:
+ ...
+ subroutine f(s)
+ character*(*) s
+ print *, s
+ s(1:3) = 'oof'
+ print *, s
+ end subroutine f
+ ...
+
+ When compiling with optimization level -O1 and printing the type of
+ variable s we get:
+ ...
+ $ gdb -q -batch outputs/gdb.opt/fortran-string/fortran-string \
+ -ex "b f" \
+ -ex run \
+ -ex "ptype s"
+ Breakpoint 1 at 0x4006f7: file fortran-string.f90, line 21.
+
+ Breakpoint 1, f (s=..., _s=_s@entry=3) at fortran-string.f90:21
+ 21 subroutine f(s)
+ type = character*1
+ ...
+ while with -O0 we have instead:
+ ...
+ type = character (3)
+ ...
+
+ The problem is that the type of s is:
+ ...
+ <1><2d6>: Abbrev Number: 21 (DW_TAG_string_type)
+ <2d7> DW_AT_string_length: 0xbf (location list)
+ <2db> DW_AT_byte_size : 4
+ ...
+ where the DW_AT_string_length is a location list, a case that is not handled
+ by attr_to_dynamic_prop.
+
+ Fix this by handling attr->form_is_section_offset () in attr_to_dynamic_prop.
+
+ Tested on x86_64-linux.
+
+ The test-case is based on gdb.opt/fortran-string.exp from
+ https://src.fedoraproject.org/rpms/gdb/raw/f32/f/gdb-archer-vla-tests.patch .
+ I've updated the copyrights to stretch to 2021.
+
+ [ I've tried to create a dwarf assembly test-case for this, but didn't
+ manage. ]
+
+ Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26910
+
+2021-10-28 Kavitha Natarajan <kavitha.natarajan@amd.com>
+
+ [gdb/testsuite] Initialize anonymous union in gdb.cp/koenig.cc
+ GDB test fails while running the test case gdb.cp/koenig.exp using
+ clang compiler:
+ [...]
+ p foo (p_union)
+ No symbol "p_union" in current context.
+ (gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union)
+ [...]
+
+ In the testcase, "p_union" is an unused/uninitialized variable of
+ anonymous union type. Clang does not emit symbol for unused anonymous
+ union/struct variables at any optimization level. Since the compiler
+ itself is not emitting the symbol for "p_union", debug info is also
+ not emitted when built with debug option. If the anonymous union is
+ initialized (or used), then clang emits the symbol "p_union" which
+ enables emitting debug info for "p_union".
+ [...]
+ p foo (p_union)
+ Cannot resolve function foo to any overloaded instance
+ (gdb) PASS: gdb.cp/koenig.exp: p foo (p_union)
+ [...]
+
+2021-10-28 Alan Modra <amodra@gmail.com>
+
+ asan: mmo: NULL dereferenc in mmo_xore_32
+ mmo_get_loc can return NULL. It's commented even, and that the caller
+ then must handle a split field. mmo_xore_* don't handle split fields,
+ instead just segfault. Stop that happening, and refuse to recognise
+ fuzzed mmo files that trigger this problem.
+
+ * mmo.c (mmo_get_loc): Don't declare inline.
+ (mmo_xore_64, mmo_xore_32, mmo_xore_16): Remove forward decls.
+ Return pointer, don't dereference NULL.
+ (mmo_scan): Return error on mmo_get_loc returning NULL.
+
+2021-10-28 Alan Modra <amodra@gmail.com>
+
+ bfd: remove use of INLINE
+ No need to use anything fancy, plain inline works just as well.
+
+ * bfd-in.h (INLINE): Don't define.
+ * bfd-in2.h: Regenerate.
+ * aoutx.h: Replace use of INLINE with inline.
+ * elf-eh-frame.c: Likewise.
+ * elf32-score7.c: Likewise.
+ * elfxx-mips.c: Likewise.
+ * ihex.c: Likewise.
+ * mach-o.c: Likewise.
+ * mmo.c: Likewise.
+
+2021-10-28 Alan Modra <amodra@gmail.com>
+
+ ASSERT in empty output section with address
+ * ldlang.c (lang_do_assignments_1): Correct "dot" inside ignored
+ sections.
+ * testsuite/ld-scripts/empty-address-4.d,
+ * testsuite/ld-scripts/empty-address-4.s,
+ * testsuite/ld-scripts/empty-address-4.t: New test.
+ * testsuite/ld-scripts/empty-address.exp: Run it.
+
+2021-10-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-27 Alan Modra <amodra@gmail.com>
+
+ asan: alpha-vms: buffer overflows
+ Yet more anti-fuzzer sanity checking
+
+ * vms-alpha.c (evax_bfd_print_egsd): Sanity check record and
+ name lengths before access.
+ (evax_bfd_print_etir_stc_ir, evax_bfd_print_etir): Likewise.
+
+2021-10-27 Alan Modra <amodra@gmail.com>
+
+ ubsan: arm: undefined shift
+ left shift of 2 by 31 places cannot be represented in type 'int'
+
+ * arm-dis.c (print_insn_thumb16): Avoid undefined behaviour.
+
+2021-10-27 Tom Tromey <tromey@adacore.com>
+
+ Fix watchpoints with multiple threads on Windows
+ A recent internal change pointed out that watchpoints were not working
+ on Windows when the inferior was multi-threaded. This happened
+ because the debug registers were only updated for certain threads --
+ in particular, those that were being resumed and that were not marked
+ as suspended. In the case of single-stepping, the need to update the
+ debug registers in other threads could also be "forgotten".
+
+ This patch changes windows-nat.c to mark all threads needing a debug
+ register update. This brings the code closer to what gdbserver does
+ (though, unfortunately, it still seems more complicated than needed).
+
+2021-10-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix port detection in gdb.debuginfod/fetch_src_and_symbols.exp
+ On OBS I ran into this failure with test-case
+ gdb.debuginfod/fetch_src_and_symbols.exp:
+ ...
+ Failed to listen for connections: Address already in use^M
+ [Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M
+ ...
+ FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout
+ ...
+
+ The test-case is trying to start debuginfod on a port to see if it's
+ available, and it handles either this message:
+ "started http server on IPv4 IPv6 port=$port"
+ meaning success, or:
+ "failed to bind to port"
+ meaning failure, in which case the debuginfod instance is killed, and we try
+ the next port.
+
+ The test-case only uses the v4 address 127.0.0.1, so fix this by:
+ - accepting "started http server on IPv4 port=$port"
+ - rejecting "started http server on IPv6 port=$port"
+
+ Tested on x86_64-linux.
+
+2021-10-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: fix value.c build on 32-bits
+ When building on ARM (32-bits), we errors like this:
+
+ /home/smarchi/src/binutils-gdb/gdb/value.c: In function 'gdb::array_view<const unsigned char> value_contents_for_printing(value*)':
+ /home/smarchi/src/binutils-gdb/gdb/value.c:1252:35: error: narrowing conversion of 'length' from 'ULONGEST' {aka 'long long unsigned int'} to 'size_t' {aka 'unsigned int'} [-Werror=narrowing]
+ 1252 | return {value->contents.get (), length};
+ | ^~~~~~
+
+ Fix that by using gdb::make_array_view, which does the appropriate
+ conversion.
+
+ Change-Id: I7d6f2e75d7440d248b8fb18f8272ee92954b404d
+
+2021-10-27 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Tidy riscv assembler and disassembler.
+ Tidy the gas/config/tc-riscv.c and opcodes/riscv-dis.c, to prepare for
+ moving the released extensions (including released vendor extensions)
+ from integration branch back to mainline.
+
+ * Added parts of missing comments.
+
+ * Updated md_show_usage.
+
+ * For validate_riscv_insn, riscv_ip and print_insn_args, unify the
+ following pointer names,
+ - oparg: pointed to the parsed operand defined in the riscv_opcodes.
+ - asarg: pointed to the parsed operand from assembly.
+ - opargStart: recorded the parsed operand name from riscv_opcodes.
+ - asargStart: recorded the parsed operand name from assembly.
+
+ gas/
+ * config/tc-riscv.c: Added parts of missind comments and updated
+ the md_show_usage.
+ (riscv_multi_subset_supports): Tidy codes.
+ (validate_riscv_insn): Unify the pointer names, oparg, asarg,
+ opargStart and asargStart, to prepare for moving the released
+ extensions from integration branch back to mainline.
+ (riscv_ip): Likewise.
+ (macro_build): Added fmtStart, also used to prepare for moving
+ released extensions.
+ (md_show_usage): Added missing descriptions for new options.
+ opcodes/
+ * riscv-dis.c (print_insn_args): Unify the pointer names,
+ oparg and opargStart, to prepare for moving the released
+ extensions from integration branch back to mainline.
+
+2021-10-27 Maciej W. Rozycki <macro@embecosm.com>
+
+ opcodes: Fix RPATH not being set for dynamic libbfd dependency
+ If built as a shared library, libopcodes has a load-time dependency on
+ libbfd, which is recorded in the dynamic section, however without a
+ corresponding RPATH entry for the directory to find libbfd in. This
+ causes loading to fail whenever libbfd is only pulled by libopcodes
+ indirectly and libbfd has been installed in a directory that is not in
+ the dynamic loader's search path.
+
+ It does not happen with the programs included with binutils or GDB,
+ because they all also pull libbfd when using libopcodes, but it can
+ happen with external software, e.g.:
+
+ $ gdbserver --help
+ gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory
+ $
+
+ (not our `gdbserver').
+
+ Indirect dynamic dependencies are handled by libtool automatically by
+ adding RPATH entries as required, however our setup for libopcodes
+ prevents this from happening by linking in libbfd with an explicit file
+ reference sneaked through to the linker directly behind libtool's back
+ via the `-Wl' linker command-line option rather than via `-l' combined
+ with a suitable library search path specified via `-L', as it would be
+ usually the case, or just referring to the relevant .la file in a fully
+ libtool-enabled configuration such as ours.
+
+ According to an observation in the discussion back in 2007[1][2][3] that
+ has led to the current arrangement it is to prevent libtool from picking
+ up the wrong version of libbfd. It does not appear to be needed though,
+ not at least with our current libtool incarnation, as directly referring
+ `libbfd.la' does exactly what it should, as previously suggested[4], and
+ with no link-time reference to the installation directory other than to
+ set RPATH. Uninstalled version of libopcodes has libbfd's build-time
+ location prepended to RPATH too, as also expected.
+
+ Use a direct reference to `libbfd.la' then, making the load error quoted
+ above go away. Alternatively `-L' and `-l' could be used to the same
+ effect, but it seems an unnecessary complication and just another way to
+ circumvent rather than making use of libtool.
+
+ References:
+
+ [1] "compile failure due to undefined symbol",
+ <https://sourceware.org/ml/binutils/2007-08/msg00476.html>
+
+ [2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html>
+
+ [3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html>
+
+ [4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html>
+
+ opcodes/
+ * Makefile.am: Remove obsolete comment.
+ * configure.ac: Refer `libbfd.la' to link shared BFD library
+ except for Cygwin.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+
+2021-10-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-27 H.J. Lu <hjl.tools@gmail.com>
+
+ gold: Place .note.gnu.property section before other note sections
+ Place the .note.gnu.property section before all other note sections to
+ avoid being placed between other note sections with different alignments.
+
+ PR gold/28494
+ * layout.cc (Layout::create_note): Set order to ORDER_PROPERTY_NOTE
+ for the .note.gnu.property section.
+ * layout.h (Output_section_order): Add ORDER_PROPERTY_NOTE.
+
+2021-10-26 Tom de Vries <tdevries@suse.de>
+
+ [gdb/doc] Fix print inferior-events default
+ In the docs about print inferior-events we read:
+ ...
+ By default, these messages will not be printed.
+ ...
+
+ That used to be the case, but is no longer so since commit f67c0c91715 "Enable
+ 'set print inferior-events' and improve detach/fork/kill/exit messages".
+
+ Fix this by updating the docs.
+
+2021-10-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change functions returning value contents to use gdb::array_view
+ The bug fixed by this [1] patch was caused by an out-of-bounds access to
+ a value's content. The code gets the value's content (just a pointer)
+ and then indexes it with a non-sensical index.
+
+ This made me think of changing functions that return value contents to
+ return array_views instead of a plain pointer. This has the advantage
+ that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
+ are checked, making bugs more apparent / easier to find.
+
+ This patch changes the return types of these functions, and updates
+ callers to call .data() on the result, meaning it's not changing
+ anything in practice. Additional work will be needed (which can be done
+ little by little) to make callers propagate the use of array_view and
+ reap the benefits.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
+
+ Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
+
+2021-10-25 Simon Marchi <simon.marchi@efficios.com>
+
+ gdbsupport: add assertions in array_view
+ Add assertions to ensure we don't access an array_view out of bounds.
+ Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for
+ gdb::optional.
+
+ Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3
+
+2021-10-25 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: make target_pid_to_str return std::string
+ I wanted to write a warning that included two target_pid_to_str calls,
+ like this:
+
+ warning (_("Blabla %s, blabla %s"),
+ target_pid_to_str (ptid1),
+ target_pid_to_str (ptid2));
+
+ This doesn't work, because target_pid_to_str stores its result in a
+ static buffer, so my message would show twice the same ptid. Change
+ target_pid_to_str to return an std::string to avoid this. I don't think
+ we save much by using a static buffer, but it is more error-prone.
+
+ Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2
+
+2021-10-25 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Also handle stores for -muse-unaligned-vector-move
+ * config/tc-i386.c (encode_with_unaligned_vector_move): Also
+ handle stores.
+ * testsuite/gas/i386/unaligned-vector-move.s: Add stores.
+ * testsuite/gas/i386/unaligned-vector-move.d: Updated.
+ * testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
+
+2021-10-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix duplicate in gdb.mi/mi-var-cp.exp
+ With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
+ ...
+ PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
+ PASS: gdb.mi/mi-var-cp.exp: create varobj for s
+ PASS: gdb.mi/mi-var-cp.exp: create varobj for s
+ DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
+ ...
+
+ This is due to a duplicate test name here:
+ ...
+ $ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
+ ...
+ 100 int reference_to_struct ()
+ 101 {
+ 102 /*: BEGIN: reference_to_struct :*/
+ 103 S s = {7, 8};
+ 104 S& r = s;
+ 105 /*:
+ 106 mi_create_varobj S s "create varobj for s"
+ 107 mi_create_varobj R r "create varobj for s"
+ ...
+
+ Fix this by using "create varobj for r" instead.
+
+ Tested on x86_64-linux.
+
+2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, ld: handle nonrepresentable types better
+ ctf_type_visit (used, among other things, by the type dumping code) was
+ aborting when it saw a nonrepresentable type anywhere: even a single
+ structure member with a nonrepresentable type caused an abort with
+ ECTF_NONREPRESENTABLE. This is not useful behaviour, given that the
+ abort comes from a type-resolution we are only doing in order to
+ determine whether the type is a structure or union. We know
+ nonrepresentable types can't be either, so handle that case and
+ pass the nonrepresentable type down.
+
+ (The added test verifies that the dumper now handles this case and
+ prints nonrepresentable structure members as it already does
+ nonrepresentable top-level types, rather than skipping the whole
+ structure -- or, without the previous commit, skipping the whole types
+ section.)
+
+ ld/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * testsuite/ld-ctf/nonrepresentable-member.*: New test.
+
+ libctf/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types.
+
+2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: dump: do not stop dumping types on error
+ If dumping of a single type fails, we obviously can't dump it; but just
+ as obviously this doesn't make the other types in the types section
+ invalid or undumpable. So we should not propagate errors seen when
+ type-dumping, but rather ignore them and carry on, so we dump as many
+ types as we can (leaving out the ones we can't grok).
+
+ libctf/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * ctf-dump.c (ctf_dump_type): Do not abort on error.
+
+2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ binutils, ld: make objdump --ctf's parameter optional
+ ld by default (and always, unless adjusted with a hand-rolled linker
+ script) emits deduplicated CTF into the .ctf section. But viewing
+ it needs you to explicitly tell objdump this: it doesn't default
+ its argument, even though what you always end up typing is
+ --ctf=.ctf.
+
+ This is annoying, so make the argument optional.
+
+ binutils/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * objdump.c (usage): --ctf now has an optional argument.
+ (main): Adjust accordingly.
+ (dump_ctf): Default it.
+ * doc/ctf.options.texi: Adjust.
+
+ ld/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * testsuite/ld-ctf/array.d: Change --ctf=.ctf to --ctf.
+ * testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
+ * testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
+ * testsuite/ld-ctf/conflicting-enums.d: Likewise.
+ * testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
+ * testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
+ * testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
+ * testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
+ * testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
+ * testsuite/ld-ctf/cycle-1.d: Likewise.
+ * testsuite/ld-ctf/cycle-2.A.d: Likewise.
+ * testsuite/ld-ctf/cycle-2.B.d: Likewise.
+ * testsuite/ld-ctf/cycle-2.C.d: Likewise.
+ * testsuite/ld-ctf/data-func-conflicted.d: Likewise.
+ * testsuite/ld-ctf/diag-cttname-null.d: Likewise.
+ * testsuite/ld-ctf/diag-cuname.d: Likewise.
+ * testsuite/ld-ctf/diag-parlabel.d: Likewise.
+ * testsuite/ld-ctf/enum-forward.d: Likewise.
+ * testsuite/ld-ctf/enums.d: Likewise.
+ * testsuite/ld-ctf/forward.d: Likewise.
+ * testsuite/ld-ctf/function.d: Likewise.
+ * testsuite/ld-ctf/nonrepresentable.d: Likewise.
+ * testsuite/ld-ctf/slice.d: Likewise.
+ * testsuite/ld-ctf/super-sub-cycles.d: Likewise.
+
+2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ binutils: make objdump/readelf --ctf-parent actually useful
+ This option has been present since the very early days of the
+ development of libctf as part of binutils, and it shows. Back in the
+ earliest days, I thought we might handle ambiguous types by introducing
+ new ELF sections on the fly named things like .ctf.foo.c for ambiguous
+ types found only in foo.c, etc. This turned out to be a terrible idea,
+ so we moved to using a CTF archive in the .ctf section which contained
+ all the CTF dictionaries -- but the --ctf-parent option in objdump and
+ readelf was never adjusted, and lingered as a mechanism to specify CTF
+ parent dictionaries in sections other than .ctf, even though the linker
+ has no way to produce parent dictionaries in different sections from
+ their children, libctf's ctf_open can't handle such split-up
+ parent/child dicts, and they are never found in the wild, emitted by GNU
+ ld or by any known third-party linking tool.
+
+ Meanwhile, the actually-useful ctf_link feature (albeit not used by ld)
+ which lets you remap the names of CTF archive members (so you can end up
+ with a parent archive member named something other than ".ctf", still
+ contained with all its children in a single .ctf section) had no support
+ in objdump or readelf: there was no way to tell them that these members
+ were parents, so all the types in the associated child dicts always
+ appeared corrupted, referencing nonexistent types from a parent objdump
+ couldn't find.
+
+ So adjust --ctf-parent so that rather than taking a section name it
+ takes a member name instead (if not specified, the name is ".ctf", which
+ is what GNU ld emits). Because the option was always useless before
+ now, this is expected to have no backward-compatibility implications.
+
+ As part of this, we have to slightly adjust the code which skips the
+ archive member name if redundant: right now it skips it if it's ".ctf",
+ on the assumption that this name will almost always be at the start
+ of the objdump output and thus we'll end up with a shared dump
+ and then smaller, headed dumps for the per-TU child dicts; but if
+ the parent name has been changed, that won't be true any more.
+
+ So change the rules to "members named .ctf which appear first in the
+ first have their member name skipped". Since we now need to count
+ members, move from ctf_archive_iter (for which passing in extra
+ parameters requires defining a new struct and is clumsy) to
+ ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and
+ maintain a member count in the obvious way. In the process we fix a
+ tiny difference between readelf and objdump: if a ctf_dump ever failed,
+ readelf skipped every later member, while objdump tried to keep going as
+ much as it could. For a dumping tool the former is clearly preferable.
+
+ binutils/ChangeLog
+ 2021-10-25 Nick Alcock <nick.alcock@oracle.com>
+
+ * objdump.c (usage): --ctf-parent now takes a name, not a section.
+ (dump_ctf): Don't open a separate section; use the parent_name in
+ ctf_dict_open instead. Use ctf_archive_next, not ctf_archive_iter,
+ so we can pass down a member count.
+ (dump_ctf_archive_member): Add the member count; don't return
+ anything. Import parents into children no matter what the
+ parent's name, while still avoiding displaying the header for the
+ common parent name of ".ctf".
+ * readelf.c (usage): Adjust similarly.
+ (dump_section_as_ctf): Likewise.
+ (dump_ctf_archive_member): Likewise. Never stop iterating over
+ archive members, even if ctf_dump of one member fails.
+ * doc/ctf.options.texi: Adjust.
+
+2021-10-25 Alan Modra <amodra@gmail.com>
+
+ objdump doesn't accept -L option
+ A followup to commit ca0e11aa4b.
+
+ * objdump.c (main): Add 'L' to short options and sort them.
+
+2021-10-25 Alan Modra <amodra@gmail.com>
+
+ bfd_nonfatal_message, localise va_start
+ Nothing to see here, just a little tidier.
+
+ * bucomm.c (bfd_nonfatal_message): Localise va_list args.
+
+2021-10-25 Alan Modra <amodra@gmail.com>
+
+ ubsan: _bfd_xcoff64_swap_aux_in left shift of negative value
+ * coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Use bfd_vma for h.
+
+ asan: evax_bfd_print_image buffer overflow
+ * vms-alpha.c (evax_bfd_print_image): Sanity check printing of
+ "image activator fixup" section.
+ (evax_bfd_print_relocation_records): Sanity check buffer offsets.
+ (evax_bfd_print_address_fixups): Likewise.
+ (evax_bfd_print_reference_fixups): Likewise.
+
+2021-10-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-24 Alan Modra <amodra@gmail.com>
+
+ asan: c4x, c54x coff_canonicalize_reloc buffer overflow
+ Sometimes the investigation of a fuzzing bug report leads into areas
+ you'd rather not go. In this instance by the time I'd figured out the
+ real cause was a target variant that had never been properly supported
+ in binutils, the time needed to fix it was less than the time needed
+ to rip it out.
+
+ * coffcode.h (coff_set_alignment_hook): Call bfd_coff_swap_reloc_in
+ not coff_swap_reloc_in.
+ (coff_slurp_reloc_table): Likewise. Don't use RELOC type.
+ (ticoff0_swap_table): Use coff_swap_reloc_v0_out and
+ coff_swap_reloc_v0_in.
+ * coffswap.h (coff_swap_reloc_v0_in, coff_swap_reloc_v0_out): New.
+ * coff-tic54x.c (tic54x_lookup_howto): Don't abort.
+ * coffgen.c (coff_get_normalized_symtab): Use PTR_ADD.
+ * bfd-in.h (PTR_ADD, NPTR_ADD): Avoid warnings when passing an
+ expression.
+ * bfd-in2.h: Regenerate.
+
+2021-10-24 Alan Modra <amodra@gmail.com>
+
+ asan: arm-darwin: buffer overflow
+ PR 21813
+ * mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Sanity
+ check PAIR reloc in other branch of condition as was done for
+ PR21813. Formatting. Delete debug printf.
+
+ asan: aout: heap buffer overflow
+ * aoutx.h (aout_get_external_symbols): Sanity check before writing
+ zero index entry. Remove outdated comment.
+ * pdp11.c (aout_get_external_symbols): Likewise.
+
+2021-10-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch ld support
+ 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
+ Zhensong Liu <liuzhensong@loongson.cn>
+ Weinan Liu <liuweinan@loongson.cn>
+ Xiaolin Tang <tangxiaolin@loongson.cn>
+
+ ld/
+ * Makefile.am: Add LoongArch.
+ * NEWS: Mention LoongArch support.
+ * configure.tgt: Add LoongArch.
+ * emulparams/elf32loongarch-defs.sh: New.
+ * emulparams/elf32loongarch.sh: Likewise.
+ * emulparams/elf64loongarch-defs.sh: Likewise.
+ * emulparams/elf64loongarch.sh: Likewise.
+ * emultempl/loongarchelf.em: Likewise.
+ * Makefile.in: Regenerate.
+ * po/BLD-POTFILES.in: Regenerate.
+ ld/testsuite/
+ * ld-loongarch-elf/disas-jirl.d: New.
+ * ld-loongarch-elf/disas-jirl.s: Likewise.
+ * ld-loongarch-elf/jmp_op.d: Likewise.
+ * ld-loongarch-elf/jmp_op.s: Likewise.
+ * ld-loongarch-elf/ld-loongarch-elf.exp: Likewise.
+ * ld-loongarch-elf/macro_op.d: Likewise.
+ * ld-loongarch-elf/macro_op.s: Likewise.
+ * ld-loongarch-elf/syscall-0.s: Likewise.
+ * ld-loongarch-elf/syscall-1.s: Likewise.
+ * ld-loongarch-elf/syscall.d: Likewise.
+ * ld-srec/srec.exp: Add LoongArch.
+ * ld-unique/pr21529.d: Likewise.
+
+2021-10-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch gas support
+ 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
+ Zhensong Liu <liuzhensong@loongson.cn>
+ Weinan Liu <liuweinan@loongson.cn>
+ Xiaolin Tang <tangxiaolin@loongson.cn>
+
+ gas/
+ * Makefile.am: Add LoongArch.
+ * NEWS: Mention LoongArch support.
+ * config/loongarch-lex-wrapper.c: New.
+ * config/loongarch-lex.h: New.
+ * config/loongarch-lex.l: New.
+ * config/loongarch-parse.y: New.
+ * config/tc-loongarch.c: New.
+ * config/tc-loongarch.h: New.
+ * configure.ac: Add LoongArch.
+ * configure.tgt: Likewise.
+ * doc/as.texi: Likewise.
+ * doc/c-loongarch.texi: Likewise.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * po/POTFILES.in: Regenerate.
+ gas/testsuite/
+ * gas/all/gas.exp: Add LoongArch.
+ * gas/elf/elf.exp: Likewise.
+ * gas/loongarch/4opt_op.d: New.
+ * gas/loongarch/4opt_op.s: Likewise.
+ * gas/loongarch/fix_op.d: Likewise.
+ * gas/loongarch/fix_op.s: Likewise.
+ * gas/loongarch/float_op.d: Likewise.
+ * gas/loongarch/float_op.s: Likewise.
+ * gas/loongarch/imm_op.d: Likewise.
+ * gas/loongarch/imm_op.s: Likewise.
+ * gas/loongarch/jmp_op.d: Likewise.
+ * gas/loongarch/jmp_op.s: Likewise.
+ * gas/loongarch/load_store_op.d: Likewise.
+ * gas/loongarch/load_store_op.s: Likewise.
+ * gas/loongarch/loongarch.exp: Likewise.
+ * gas/loongarch/macro_op.d: Likewise.
+ * gas/loongarch/macro_op.s: Likewise.
+ * gas/loongarch/nop.d: Likewise.
+ * gas/loongarch/nop.s: Likewise.
+ * gas/loongarch/privilege_op.d: Likewise.
+ * gas/loongarch/privilege_op.s: Likewise.
+ * gas/loongarch/syscall.d: Likewise.
+ * gas/loongarch/syscall.s: Likewise.
+ * lib/gas-defs.exp: Add LoongArch.
+
+2021-10-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch binutils support
+ 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
+ Zhensong Liu <liuzhensong@loongson.cn>
+ Weinan Liu <liuweinan@loongson.cn>
+ binutils/
+ * NEWS: Mention LoongArch support.
+ * readelf.c: Add LoongArch.
+ * testsuite/binutils-all/objdump.exp: Add LoongArch.
+
+2021-10-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch opcodes support
+ 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
+ Zhensong Liu <liuzhensong@loongson.cn>
+ Weinan Liu <liuweinan@loongson.cn>
+
+ include/
+ * opcode/loongarch.h: New.
+ * dis-asm.h: Declare print_loongarch_disassembler_options.
+ opcodes/
+ * Makefile.am: Add LoongArch.
+ * configure.ac: Likewise.
+ * disassemble.c: Likewise.
+ * disassemble.h: Declare print_insn_loongarch.
+ * loongarch-coder.c: New.
+ * loongarch-dis.c: New.
+ * loongarch-opc.c: New.
+ * Makefile.in: Regenerate.
+ * configure: Regenerate.
+ * po/POTFILES.in: Regenerate.
+
+2021-10-24 liuzhensong <liuzhensong@loongson.cn>
+
+ LoongArch bfd support
+ 2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
+ Zhensong Liu <liuzhensong@loongson.cn>
+ Weinan Liu <liuweinan@loongson.cn>
+ bfd/
+ * Makefile.am: Add LoongArch.
+ * archures.c: Likewise.
+ * config.bfd: Likewise.
+ * configure.ac: Likewise.
+ * cpu-loongarch.c: New.
+ * elf-bfd.h: Add LoongArch.
+ * elf.c: Add LoongArch elfcore_grok_xxx.
+ * elfnn-loongarch.c: New.
+ * elfxx-loongarch.c: New.
+ * elfxx-loongarch.h: New.
+ * reloc.c: Add LoongArch BFD RELOC ENUM.
+ * targets.c: Add LoongArch target.
+ * Makefile.in: Regenerate.
+ * bfd-in2.h: Regenerate.
+ * configure: Regenerate.
+ * libbfd.h: Regenerate.
+ * po/BLD-POTFILES.in: Regenerate.
+ * po/SRC-POTFILES.in: Regenerate.
+
+ include/
+ * elf/common.h: Add NT_LARCH_{CPUCFG,CSR,LSX,LASX}.
+ * elf/loongarch.h: New.
+
+2021-10-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-22 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Add -muse-unaligned-vector-move to assembler
+ Unaligned load/store instructions on aligned memory or register are as
+ fast as aligned load/store instructions on modern Intel processors. Add
+ a command-line option, -muse-unaligned-vector-move, to x86 assembler to
+ encode encode aligned vector load/store instructions as unaligned
+ vector load/store instructions.
+
+ * NEWS: Mention -muse-unaligned-vector-move.
+ * config/tc-i386.c (use_unaligned_vector_move): New.
+ (encode_with_unaligned_vector_move): Likewise.
+ (md_assemble): Call encode_with_unaligned_vector_move for
+ -muse-unaligned-vector-move.
+ (OPTION_MUSE_UNALIGNED_VECTOR_MOVE): New.
+ (md_longopts): Add -muse-unaligned-vector-move.
+ (md_parse_option): Handle -muse-unaligned-vector-move.
+ (md_show_usage): Add -muse-unaligned-vector-move.
+ * doc/c-i386.texi: Document -muse-unaligned-vector-move.
+ * testsuite/gas/i386/i386.exp: Run unaligned-vector-move and
+ x86-64-unaligned-vector-move.
+ * testsuite/gas/i386/unaligned-vector-move.d: New file.
+ * testsuite/gas/i386/unaligned-vector-move.s: Likewise.
+ * testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
+
+2021-10-22 Tom Tromey <tromey@adacore.com>
+
+ Fix 'uninstall' target
+ This adds some missing code to the 'uninstall' targets in gdb and
+ gdbserver. It also changes gdb's uninstall target so that it no
+ longer tries to remove any man page -- this is already done (and more
+ correctly) by doc/Makefile.in.
+
+ I tested this with 'make install' followed by 'make uninstall', then
+ examining the install tree for regular files. Only the 'dir' file
+ remains, but this appears to just be how 'install-info' is intended to
+ work.
+
+2021-10-22 Tom Tromey <tromey@adacore.com>
+
+ Remove unused variables from gdbserver's Makefile
+ This removes a number of unused variables from gdbserver's Makefile.
+ I found these while working on the subsequent patches, and figured it
+ would be cleaner to have a separate patch for the deletions.
+
+2021-10-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/linux-dp.exp
+ On openSUSE Tumbleweed with glibc-debuginfo installed I get:
+ ...
+ (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
+ where^M
+ #0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
+ #1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
+ #2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
+ at pthread_create.c:435^M
+ #3 0x00007ffff7ddb640 in clone3 () \
+ at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
+ (gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
+ ...
+ while without debuginfo installed I get instead:
+ ...
+ (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
+ where^M
+ #0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
+ #1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
+ #2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
+ #3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
+ ...
+
+ The problem is that the regexp used:
+ ...
+ "\(from .*libpthread\|at pthread_create\|in pthread_create\)"
+ ...
+ expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
+ been merged into libc.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2021-10-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAILs in gdb.mi/mi-breakpoint-changed.exp
+ Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
+ mi_gdb_test" we run into:
+ ...
+ PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
+ Expecting: ^(-break-insert -f pendfunc1[^M
+ ]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
+ bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -break-insert -f pendfunc1^M
+ ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
+ addr="0x00007ffff7bd559e",func="pendfunc1",\
+ file="gdb/testsuite/gdb.mi/pendshr1.c",\
+ fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
+ times="0",original-location="pendfunc1"}^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+ -break-insert -f pendfunc1 (unexpected output)
+ ...
+
+ The regexp expects a breakpoint-created event, but that's actually suppressed
+ by the command:
+ ...
+ DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
+ &mi_suppress_notification.breakpoint),
+ ...
+
+ Fix this by updating the regexp.
+
+ Likewise for the following:
+ ...
+ PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+ -break-insert -f pendfunc1
+ Expecting: ^(-break-enable count 1 2[^M
+ ]+)?(=breakpoint-modified,\
+ bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -break-enable count 1 2^M
+ ^done^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+ -break-enable count 1 2 (unexpected out\
+ put)
+ ...
+
+ Tested on x86_64-linux.
+
+2021-10-22 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: move gdb.Membuf support into a new file
+ In a future commit I'm going to be creating gdb.Membuf objects from a
+ new file within gdb/python/py*.c. Currently all gdb.Membuf objects
+ are created directly within infpy_read_memory (as a result of calling
+ gdb.Inferior.read_memory()).
+
+ Initially I split out the Membuf creation code into a new function,
+ and left the new function in gdb/python/py-inferior.c, however, it
+ felt a little random that the Membuf creation code should live with
+ the inferior handling code.
+
+ So, then I moved all of the Membuf related code out into a new file,
+ gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
+ wraps an array of bytes into a gdb.Membuf object.
+
+ Most of the code is moved directly from py-inferior.c with only minor
+ tweaks to layout and replacing NULL with nullptr, hence, I've left the
+ copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.
+
+ Currently, the only user of this code is still py-inferior.c, but in
+ later commits this will change.
+
+ There should be no user visible changes after this commit.
+
+2021-10-22 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: new gdb.architecture_names function
+ Add a new function to the Python API, gdb.architecture_names(). This
+ function returns a list containing all of the supported architecture
+ names within the current build of GDB.
+
+ The values returned in this list are all of the possible values that
+ can be returned from gdb.Architecture.name().
+
+2021-10-22 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: make disassembler fprintf callback a static member function
+ The disassemble_info structure has four callbacks, we have three of
+ them as static member functions within gdb_disassembler, the fourth is
+ just a global static function.
+
+ However, this fourth callback, is still only used from the
+ disassemble_info struct, so there's no real reason for its special
+ handling.
+
+ This commit makes fprintf_disasm a static method within
+ gdb_disassembler.
+
+ There should be no user visible changes after this commit.
+
+2021-10-22 Lewis Revill <lewis.revill@embecosm.com>
+
+ RISC-V: Added ld testcase for pcgp relaxation.
+ Consider the the pcgp-relax-02 testcase,
+
+ .text
+ .globl _start
+ _start:
+ .L1: auipc a0, %pcrel_hi(data_a)
+ .L2: auipc a1, %pcrel_hi(data_b)
+ addi a0, a0, %pcrel_lo(.L1)
+ addi a1, a1, %pcrel_lo(.L2)
+
+ .data
+ .word 0x0
+ .globl data_a
+ data_a:
+ .word 0x1
+
+ .section .rodata
+ .globl data_b
+ data_b:
+ .word 0x2
+
+ If the first auipc is deleted, but we are still building the pcgp
+ table (connect the high and low pcrel relocations), then there is
+ an aliasing issue that we need some way to disambiguate which of
+ the two symbols we are targeting. Therefore, Palmer thought of a
+ way to use R_RISCV_DELETE to split this into two phases, so we
+ could resolve the addresses before creating the ambiguities.
+
+ This patch just add the ld testcase for the above case, in case we
+ have changed something but break this.
+
+ ld/
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax
+ to pcgp-relax-01, and added pcgp-relax-02.
+ * testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax.
+ * testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise.
+ * testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase.
+ * testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise.
+
+2021-10-22 Lewis Revill <lewis.revill@embecosm.com>
+
+ RISC-V: Don't separate pcgp relaxation to another relax pass.
+ Commit abd20cb637008da9d32018b4b03973e119388a0a and
+ ebdcad3fddf6ec21f6d4dcc702379a12718cf0c4 introduced additional
+ complexity into the paths run by the RISC-V relaxation pass in order to
+ resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo
+ pairs. The first commit split up relaxation of these relocs into a pass
+ which occurred after other relaxations in order to prevent the situation
+ where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting
+ our ability to find the corresponding pcrel_hi relocation from the
+ address attached to the pcrel_lo.
+
+ Since the relaxation was split into two passes the 'again' parameter
+ could not be used to perform the entire relaxation process again and so
+ the second commit added a way to restart ldelf_map_segments, thus
+ starting the whole process again.
+
+ Unfortunately this process could not account for the fact that we were
+ not finished with the relaxation process so in some cases - such as the
+ case where code would not fit in a memory region before the
+ R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code
+ would fail.
+
+ This patch fixes all three of these concerns by reverting back to a
+ system of having only one target relax pass but updating entries in the
+ table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus
+ we can keep track of the pairs accurately, and we can use the 'again'
+ parameter to restart the entire target relax pass, behaving in the way
+ that generic code expects. Unfortunately we must still have an
+ additional pass to delay deleting AUIPC bytes to avoid ambiguity between
+ pcrel_hi relocs stored in the table after deletion. This pass can only
+ be run once so we may potentially miss out on relaxation opportunities
+ but this is likely to be rare.
+
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28410
+
+ bfd/
+ * elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax.
+ (riscv_elf_link_hash_table_create): Updated.
+ (riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs.
+ Update the pcgp_relocs table whenever bytes are deleted.
+ (riscv_update_pcgp_relocs): Add function to update the section
+ offset of pcrel_hi and pcrel_lo, and also update the symbol value
+ of pcrel_hi.
+ (_bfd_riscv_relax_call): Need to update the pcgp_relocs table
+ when deleting codes.
+ (_bfd_riscv_relax_lui): Likewise.
+ (_bfd_riscv_relax_tls_le): Likewise.
+ (_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN,
+ we can't relax anything else, so set the sec->sec_flg0 to true.
+ Besides, we don't need to update the pcgp_relocs table at this
+ stage, so just pass NULL pointer as the pcgp_relocs table for
+ riscv_relax_delete_bytes.
+ (_bfd_riscv_relax_section): Use only one pass for all target
+ relaxations.
+ (_bfd_riscv_relax_delete): Likewise, we don't need to update
+ the pcgp_relocs table at this stage, and don't need to set
+ the `again' since restart_relax mechanism is abandoned.
+ (bfd_elfNN_riscv_restart_relax_sections): Removed.
+ (_bfd_riscv_relax_section): Updated.
+ * elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed.
+ (bfd_elf64_riscv_restart_relax_sections): Likewise.
+ ld/
+ * emultempl/riscvelf.em: Revert restart_relax changes and set
+ relax_pass to 3.
+ * testsuite/ld-riscv-elf/align-small-region.d: New testcase.
+ * testsuite/ld-riscv-elf/align-small-region.ld: Likewise.
+ * testsuite/ld-riscv-elf/align-small-region.s: Likewise.
+ * testsuite/ld-riscv-elf/restart-relax.d: Removed sine the
+ restart_relax mechanism is abandoned.
+ * testsuite/ld-riscv-elf/restart-relax.s: Likewise.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-10-22 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix remote-sim.c build
+ Commit 183be222907a ("gdb, gdbserver: make target_waitstatus safe")
+ broke the remote-sim.c build. In fact, it does some wrong changes,
+ result of a bad sed invocation.
+
+ Fix it by adjusting the code to the new target_waitstatus API.
+
+ Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91
+
+2021-10-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-21 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb, gdbserver: make target_waitstatus safe
+ I stumbled on a bug caused by the fact that a code path read
+ target_waitstatus::value::sig (expecting it to contain a gdb_signal
+ value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
+ meant that the active union field was in fact
+ target_waitstatus::value::related_pid, and contained a ptid. The read
+ signal value was therefore garbage, and that caused GDB to crash soon
+ after. Or, since that GDB was built with ubsan, this nice error
+ message:
+
+ /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
+
+ Despite being a large-ish change, I think it would be nice to make
+ target_waitstatus safe against that kind of bug. As already done
+ elsewhere (e.g. dynamic_prop), validate that the type of value read from
+ the union matches what is supposed to be the active field.
+
+ - Make the kind and value of target_waitstatus private.
+ - Make the kind initialized to TARGET_WAITKIND_IGNORE on
+ target_waitstatus construction. This is what most users appear to do
+ explicitly.
+ - Add setters, one for each kind. Each setter takes as a parameter the
+ data associated to that kind, if any. This makes it impossible to
+ forget to attach the associated data.
+ - Add getters, one for each associated data type. Each getter
+ validates that the data type fetched by the user matches the wait
+ status kind.
+ - Change "integer" to "exit_status", "related_pid" to "child_ptid",
+ just because that's more precise terminology.
+ - Fix all users.
+
+ That last point is semi-mechanical. There are a lot of obvious changes,
+ but some less obvious ones. For example, it's not possible to set the
+ kind at some point and the associated data later, as some users did.
+ But in any case, the intent of the code should not change in this patch.
+
+ This was tested on x86-64 Linux (unix, native-gdbserver and
+ native-extended-gdbserver boards). It was built-tested on x86-64
+ FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
+ files was done as a best effort. If I forgot any place to update in
+ these files, it should be easy to fix (unless the change happens to
+ reveal an actual bug).
+
+ Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
+
+2021-10-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: initialize the members of lwp_info in-class
+ Add a constructor to initialize the waitstatus members. Initialize the
+ others in the class directly.
+
+ Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
+
+2021-10-21 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbserver: make thread_info non-POD
+ Add a constructor and a destructor. The constructor takes care of the
+ initialization that happened in add_thread, while the destructor takes
+ care of the freeing that happened in free_one_thread. This is needed to
+ make target_waitstatus non-POD, as thread_info contains a member of that
+ type.
+
+ Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7
+
+2021-10-21 Andrew Pinski <apinski@marvell.com>
+
+ Fix ARMv8.4 for hw watchpoint and breakpoint
+ Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
+ this adds ARMv8.4 debug arch as being compatible for hw watchpoint
+ and breakpoints.
+
+ Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity)
+ Since the two locations which check the debug arch are the same code currently, it is
+ a good idea to factor it out to a new function and just use that function from
+ aarch64_linux_get_debug_reg_capacity. This is also the first step to support
+ ARMv8.4 debug arch.
+
+2021-10-21 Carl Love <cel@us.ibm.com>
+
+ Fixes for gdb.mi/mi-break.exp
+ Update the expected pattern for two of the tests.
+
+ Matching pattern \" doesn't work. Use .* to match the \* pattern.
+
+2021-10-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tui] Fix breakpoint display functionality
+ In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
+ body was transformed into a lambda function body:
+ ...
+ - for (bp = breakpoint_chain;
+ - bp != NULL;
+ - bp = bp->next)
+ + iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ ...
+ and consequently:
+ - a continue was replaced by a return, and
+ - a final return was added.
+
+ Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
+ transformed back to a loop body:
+ ...
+ - iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ + for (breakpoint *bp : all_breakpoints ())
+ ...
+ but without reverting the changes that introduced the two returns.
+
+ Consequently, breakpoints no longer show up in the tui source window.
+
+ Fix this by reverting the changes that introduced the two returns.
+
+ Build on x86_64-linux, tested with all .exp test-cases that contain
+ tuiterm_env.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
+
+2021-10-21 Carl Love <cel@us.ibm.com>
+
+ Fix test step-and-next-inline.cc
+ The test expect the runto_main to stop at the first line of the function.
+ Depending on the optimization level, gdb may stop in the prolog or after
+ the prolog at the first line. To ensure the test stops at the first line
+ of main, have it explicitly stop at a break point on the first line of the
+ function.
+
+ On PowerPC, the test passes when compiled with no optimization but fails
+ with all levels of optimization due to gdb stopping in the prolog.
+
+2021-10-21 Tom Tromey <tromey@adacore.com>
+
+ Fix latent Ada bug when accessing field offsets
+ The "add accessors for field (and call site) location" patch caused a
+ gdb crash when running the internal AdaCore testsuite. This turned
+ out to be a latent bug in ada-lang.c.
+
+ The immediate cause of the bug is that find_struct_field
+ unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
+ dynamic type.
+
+ This patch fixes the problem by doing two things. First, it changes
+ find_struct_field to use a dummy value for the field offset in the
+ situation where the offset is not actually needed by the caller. This
+ works because the offset isn't used in any other way -- only as a
+ result.
+
+ Second, this patch assures that calls to find_struct_field use a
+ resolved type when the offset is needed. For
+ value_tag_from_contents_and_address, this is done by resolving the
+ type explicitly. In ada_value_struct_elt, this is done by passing
+ nullptr for the out parameters when they are not needed (the second
+ call in this function already uses a resolved type).
+
+ Note that, while we believe the parent field probably can't occur at a
+ variable offset, the patch still updates this code path, just in case.
+
+ I've updated an existing test case to reproduce the crash.
+ I'm checking this in.
+
+2021-10-21 Alan Modra <amodra@gmail.com>
+
+ -Waddress warning in ldelf.c
+ ldelf.c: In function 'ldelf_after_open':
+ ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
+ 1049 | && elf_tdata (abfd)->elf_header != NULL
+ | ^~
+ In file included from ldelf.c:37:
+ ../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
+ 1957 | Elf_Internal_Ehdr elf_header[1]; /* Actual data, but ref like ptr */
+
+ * ldelf.c (ldelf_after_open): Remove useless elf_header test.
+
+2021-10-21 Alan Modra <amodra@gmail.com>
+
+ Avoid -Waddress warnings in readelf
+ Mainline gcc:
+ readelf.c: In function 'find_section':
+ readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
+ 349 | ((X) != NULL \
+ | ^~
+ readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
+ 761 | if (SECTION_NAME_VALID (filedata->section_headers + i)
+ | ^~~~~~~~~~~~~~~~~~
+
+ This will likely be fixed in gcc, but inline functions are nicer than
+ macros.
+
+ * readelf.c (SECTION_NAME, SECTION_NAME_VALID),
+ (SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
+ (GET_DYNAMIC_NAME): Delete. Replace with..
+ (section_name, section_name_valid, section_name_print),
+ (valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
+ new inline functions. Update use throughout file.
+
+2021-10-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-20 Alan Modra <amodra@gmail.com>
+
+ PR28417, std::string no longer allows accepting nullptr_t
+ PR 28417
+ * incremental.cc (Sized_relobj_incr::do_section_name): Avoid
+ std:string undefined behaviour.
+ * options.h (Search_directory::Search_directory): Likewise.
+
+2021-10-20 Alan Modra <amodra@gmail.com>
+
+ Re: PR27625, powerpc64 gold __tls_get_addr calls
+ My previous PR27625 patch had a problem or two. For one, the error
+ "__tls_get_addr call lacks marker reloc" on processing some calls
+ before hitting a call without markers typically isn't seen. Instead a
+ gold assertion fails. Either way it would be a hard error, which
+ triggers on a file contained in libphobos.a when running the gcc
+ testsuite. A warning isn't even appropriate since the call involved
+ is one built by hand without any of the arg setup relocations that
+ might result in linker optimisation.
+
+ So this patch reverts most of commit 0af4fcc25dd5, instead entirely
+ ignoring the problem of mis-optimising old-style __tls_get_addr calls
+ without marker relocs. We can't handle them gracefully without
+ another pass over relocations before decisions are made about GOT
+ entries in Scan::global or Scan::local. That seems too costly, just
+ to link object files from 2009. What's more, there doesn't seem to be
+ any way to allow the libphobos explicit __tls_get_addr call, but not
+ old TLS sequences without marker relocs. Examining instructions
+ before the __tls_get_addr call is out of the question: program flow
+ might reach the call via a branch. Putting an R_PPC64_TLSGD marker
+ with zero sym on the call might be a solution, but current linkers
+ will then merrily optimise away the call!
+
+ PR gold/27625
+ * powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
+ and tls_opt_error_ variables and accessors. Remove all uses.
+
+2021-10-20 Tom Tromey <tom@tromey.com>
+
+ Use std::string in print_one_catch_syscall
+ This changes print_one_catch_syscall to use std::string, removing a
+ bit of manual memory management.
+
+ Use unique_xmalloc_ptr in breakpoint
+ This changes struct breakpoint to use unique_xmalloc_ptr in a couple
+ of spots, removing a bit of manual memory management.
+
+ Use unique_xmalloc_ptr in bp_location
+ This changes struct bp_location to use a unique_xmalloc_ptr, removing
+ a bit of manual memory management.
+
+ Use unique_xmalloc_ptr in watchpoint
+ This changes struct watchpoint to use unique_xmalloc_ptr in a couple
+ of places, removing a bit of manual memory management.
+
+ Use unique_xmalloc_ptr in exec_catchpoint
+ This changes struct exec_catchpoint to use a unique_xmalloc_ptr,
+ removing a bit of manual memory management.
+
+ Use unique_xmalloc_ptr in solib_catchpoint
+ This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
+ removing a bit of manual memory management.
+
+2021-10-20 Christian Biesinger <cbiesinger@google.com>
+
+ Make c-exp.y work with Bison 3.8+
+ When using Bison 3.8, we get this error:
+
+ ../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]
+
+ That's because bison 3.8 removed YYPRINT support:
+ https://savannah.gnu.org/forum/forum.php?forum_id=10047
+
+ Accordingly, this patch only defines that function for Bison < 3.8.
+
+ Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad
+
+2021-10-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-19 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest
+ The test-case gdb.gdb/python-interrupts.exp:
+ - runs to captured_command_loop
+ - sets a breakpoint at set_active_ext_lang
+ - calls a python command
+ - verifies the command triggers the breakpoint
+ - sends a signal and verifies the result
+
+ The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
+ that captured_command_loop and set_active_ext_lang are available for setting
+ breakpoints.
+
+ Reimplement the test-case as unittest, using:
+ - execute_command_to_string to capture the output
+ - try/catch to catch the "Error while executing Python code" exception
+ - a new hook selftests::hook_set_active_ext_lang to raise the signal
+
+ Tested on x86_64-linux.
+
+2021-10-19 Tom Tromey <tromey@adacore.com>
+
+ Check index in type::field
+ This changes gdb to check the index that is passed to type::field.
+ This caught one bug in the Ada code when running the test suite
+ (actually I found the bug first, then realized that the check would
+ have helped), so this patch fixes that as well.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-10-19 Tom Tromey <tromey@adacore.com>
+
+ Fix Rust lex selftest when using libiconv
+ The Rust lex selftest fails on our Windows build. I tracked this down
+ to a use of UTF-32 as a parameter to convert_between_encodings. Here,
+ iconv_open succeeds, but the actual conversion of a tab character
+ fails with EILSEQ. I suspect that "UTF-32" is being interpreted as
+ big-endian, as changing the call to use "UTF-32LE" makes it work.
+ This patch implements this fix.
+
+2021-10-19 Tom Tromey <tromey@adacore.com>
+
+ Fix format_pieces selftest on Windows
+ The format_pieces selftest currently fails on Windows hosts.
+
+ The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
+ formatter may perform, but also gdbsupport was missing a configure
+ check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
+
+2021-10-19 Tom Tromey <tromey@adacore.com>
+
+ Fix bug in dynamic type resolution
+ A customer-reported problem led us to a bug in dynamic type
+ resolution. resolve_dynamic_struct will recursively call
+ resolve_dynamic_type_internal, passing it the sub-object for the
+ particular field being resolved. While it offsets the address here,
+ it does not also offset the "valaddr" -- the array of bytes describing
+ the memory.
+
+ This patch fixes the bug, by offsetting both. A test case is included
+ that can be used to reproduce the bug.
+
+2021-10-19 Tom Tromey <tromey@adacore.com>
+
+ Always use std::function for self-tests
+ Now that there is a register_test variant that accepts std::function,
+ it seems to me that the 'selftest' struct and accompanying code is
+ obsolete -- simply always using std::function is simpler. This patch
+ implements this idea.
+
+2021-10-19 Daniel Black <daniel@mariadb.org>
+
+ Fix PR gdb/17917 Lookup build-id in remote binaries
+ GDB doesn't support loading debug files using build-id from remote
+ target filesystems.
+
+ This is the case when gdbserver attached to a process and a gdb target
+ remote occurs over tcp.
+
+ With this change we make build-id lookups possible:
+
+ (gdb) show debug-file-directory
+ The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
+ (gdb) set debug-file-directory /usr/lib/debug
+ (gdb) show sysroot
+ The current system root is "target:".
+ (gdb) target extended-remote :46615
+ Remote debugging using :46615
+ warning: Can not parse XML target description; XML support was disabled at compile time
+ Reading /usr/sbin/mariadbd from remote target...
+ warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+ Reading /usr/sbin/mariadbd from remote target...
+ Reading symbols from target:/usr/sbin/mariadbd...
+ Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug...
+ Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
+ ...
+
+ Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):
+
+ (gdb) target extended-remote :46615
+ Remote debugging using :46615
+ Reading /usr/sbin/mariadbd from remote target...
+ warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+ Reading /usr/sbin/mariadbd from remote target...
+ Reading symbols from target:/usr/sbin/mariadbd...
+ Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+ Missing separate debuginfo for target:/usr/sbin/mariadbd
+ Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
+ (No debugging symbols found in target:/usr/sbin/mariadbd)
+
+ Observe it didn't look for
+ /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
+ on the remote target (where it is) and expected them to be installed
+ locally.
+
+ As a minor optimization, this also changes the build-id lookup such that
+ if sysroot is empty, no second lookup of the same location is performed.
+
+ Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917
+
+2021-10-19 Nick Clifton <nickc@redhat.com>
+
+ Fix a potential illegal memory access when testing for a special LTO symbol name.
+ bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
+ name before checking to see if the symbol is __gnu_lto_slim.
+ * archive.c (_bfd_compute_and_write_armap): Likewise.
+ binutils
+ * nm.c (filter_symbols): Test for a NULL name before checking to
+ see if the symbol is __gnu_lto_slim.
+ * objcopy.c (filter_symbols): Likewise.
+
+2021-10-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-18 Weimin Pan <weimin.pan@oracle.com>
+
+ CTF: incorrect underlying type setting for enumeration types
+ A bug was filed against the incorrect underlying type setting for
+ an enumeration type, which was caused by a copy and paste error.
+ This patch fixes the problem by setting it by calling objfile_int_type,
+ which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
+ Also add error checking on ctf_func_type_info call.
+
+2021-10-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-17 Alan Modra <amodra@gmail.com>
+
+ PR28459, readelf issues bogus warning
+ I'd missed the fact that the .debug_rnglists dump doesn't exactly
+ display the contents of the section. Instead readelf rummages through
+ .debug_info looking for DW_AT_ranges entries, then displays the
+ entries in .debug_rnglists pointed at, sorted. A simpler dump of the
+ actual section contents might be more useful and robust, but it was
+ likely done that way to detect overlap and holes.
+
+ Anyway, the headers in .debug_rnglists besides the first are ignored,
+ and limiting to the unit length of the first header fails if there is
+ more than one unit.
+
+ PR 28459
+ * dwarf.c (display_debug_ranges): Don't constrain data to length
+ in header.
+
+2021-10-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-16 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Adjust pr28158.rd for glibc 2.34
+ Adjust pr28158.rd for glibc 2.34:
+
+ $ readelf -W --dyn-syms tmpdir/pr28158
+
+ Symbol table '.dynsym' contains 4 entries:
+ Num: Value Size Type Bind Vis Ndx Name
+ 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
+ 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.34 (2)
+ 2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
+ 3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (3)
+ $
+
+ vs older glibc:
+
+ $ readelf -W --dyn-syms tmpdir/pr28158
+
+ Symbol table '.dynsym' contains 4 entries:
+ Num: Value Size Type Bind Vis Ndx Name
+ 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
+ 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (3)
+ 2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
+ 3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (2)
+
+ $
+
+ * testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.
+
+2021-10-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-14 Carl Love <cel@us.ibm.com>
+
+ Powerpc: Add support for openat and fstatat syscalls
+ [gdb] update ppc-linux-tdep.c
+
+ Add argument to ppc_canonicalize_syscall for the wordsize.
+ Add syscall entries for the openat and fstatat system calls.
+
+2021-10-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add .debug_loc support in dwarf assembler
+ Add .debug_loc support in the dwarf assembler, and use it in new test-case
+ gdb.dwarf2/loc-sec-offset.exp (which is based on
+ gdb.dwarf2/loclists-sec-offset.exp).
+
+ Tested on x86_64-linux.
+
+2021-10-14 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Re: PowerPC64: Don't pretend to support multi-toc
+ We can't get at section->address() until everything is laid out, so
+ trying to generalise the offset calculation rather than using a value
+ of 0x8000 (the old object->toc_base_offset()) was bound to fail.
+ got->g_o_t() is a little better than a hard-coded 0x8000.
+
+ * powerpc.cc (Target_powerpc::Scan::local, global): Don't use
+ toc_pointer() here.
+
+2021-10-14 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Two GOT sections for PowerPC64
+ Split .got into two piece, one with the header and entries for small
+ model got entries, the other with entries for medium/large model got
+ entries. The idea is to better support mixed pcrel/non-pcrel code
+ where non-pcrel small-model .toc entries need to be within 32k of the
+ toc pointer.
+
+ * target.h (Target::tls_offset_for_local): Add got param.
+ (Target::tls_offset_for_global): Likewise.
+ (Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
+ * output.h (Output_data_got::Got_entry::write): Add got param.
+ * output.cc (Output_data_got::Got_entry::write): Likewise, pass to
+ tls_offset_for_local/global calls.
+ (Output_data_got::do_write): Adjust to suit.
+ * s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
+ (Target_s390::do_tls_offset_for_global): Likewise.
+ * powerpc.cc (enum Got_type): Extend with small types, move from
+ class Target_powerpc.
+ (Target_powerpc::biggot_): New.
+ (Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
+ got_size, got_section, got_base_offset): Handle biggot_.
+ (Target_powerpc::do_define_standard_symbols): Adjust.
+ (Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
+ (Output_data_got_powerpc::Output_data_got_powerpc): Only make
+ 64-bit header for small got section.
+ (Output_data_got_powerpc::g_o_t): Only return a result for small
+ got section.
+ (Output_data_got_powerpc::write): Only write small got section
+ header.
+ (Target_powerpc::Scan::local, global): Select small/big Got_type
+ and section to suit reloc.
+ (Target_powerpc::Relocate::relocate): Similarly.
+ (Sort_toc_sections): Rewrite.
+
+2021-10-14 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64: Don't pretend to support multi-toc
+ Code in powerpc.cc is pretending to support a per-object toc pointer
+ value, but powerpc gold has no real support for multi-toc. This patch
+ removes the pretense, tidying quite a lot in preparation for a
+ followup patch. If multi-toc is ever to be supported, don't revert
+ this patch but start by adding object parameter to toc_pointer() and
+ an object to Branch_stub_key.
+
+ * powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
+ (Target_powerpc::toc_pointer): New function. Use throughout.
+ (Target_powerpc::got_base_offset): New function. Use throughout..
+ (Output_data_got_powerpc::got_base_offset): ..in place of
+ this. Delete.
+ (Output_data_got_powerpc::Output_data_got_powerpc): Init
+ header_index_ to -1u for 64-bit, and make header here.
+ (Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
+ make 64-bit header here.
+ (Output_data_got_powerpc::g_o_t): Return toc pointer offset in
+ section for 64-bit. Use throughout.
+ (Stub_table): Remove toc_base_off_ from Branch_stub_key, and
+ object param on add_long_branch_entry and find_long_branch_entry.
+ Adjust all uses.
+
+2021-10-14 Alan Modra <amodra@gmail.com>
+
+ Re: s12z/disassembler: call memory_error_func when appropriate
+ Adjust for commit ba7c18a48457.
+
+ * testsuite/gas/s12z/truncated.d: Update expected output.
+
+2021-10-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/exp] Improve <error reading variable> message
+ When printing a variable x in a subroutine foo:
+ ...
+ subroutine foo (x)
+ integer(4) :: x (*)
+ x(3) = 1
+ end subroutine foo
+ ...
+ where x is an array with unknown bounds, we get:
+ ...
+ $ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
+ -ex "break foo" \
+ -ex run \
+ -ex "print x"
+ Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
+
+ Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
+ 18 x(3) = 1
+ $1 = <error reading variable>
+ ...
+
+ Improve the error message by printing the details of the error, such that we
+ have instead:
+ ...
+ $1 = <error reading variable: failed to get range bounds>
+ ...
+
+ This is a change in gdb/valprint.c, and grepping through the sources reveals
+ that this is a common pattern.
+
+ Tested on x86_64-linux.
+
+2021-10-13 Carl Love <cel@us.ibm.com>
+
+ PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)
+ [gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.
+
+ The GDB record function was recording the variable addr that was passed in
+ rather than the calculated effective address (ea) by the
+ ppc_process_record_op31 function.
+
+2021-10-13 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: improve error reporting from the disassembler
+ If the libopcodes disassembler returns a negative value then this
+ indicates that the disassembly failed for some reason. In disas.c, in
+ the function gdb_disassembler::print_insn we can see how this is
+ handled; when we get a negative value back, we call the memory_error
+ function, which throws an exception.
+
+ The problem here is that the address used in the memory_error call is
+ gdb_disassembler::m_err_memaddr, which is set in
+ gdb_disassembler::dis_asm_memory_error, which is called from within
+ the libopcodes disassembler through the
+ disassembler_info::memory_error_func callback.
+
+ However, for this to work correctly, every time the libopcodes
+ disassembler returns a negative value, the libopcodes disassembler
+ must have first called the memory_error_func callback.
+
+ My first plan was to make m_err_memaddr a gdb::optional, and assert
+ that it always had a value prior to calling memory_error, however, a
+ quick look in opcodes/*-dis.c shows that there _are_ cases where a
+ negative value is returned without first calling the memory_error_func
+ callback, for example in arc-dis.c and cris-dis.c.
+
+ Now, I think that a good argument can be made that these disassemblers
+ must therefore be broken, except for the case where we can't read
+ memory, we should always be able to disassemble the memory contents to
+ _something_, even if it's just '.word 0x....'. However, I certainly
+ don't plan to go and fix all of the disassemblers.
+
+ What I do propose to do then, is make m_err_memaddr a gdb::optional,
+ but now, instead of always calling memory_error, I add a new path
+ which just calls error complaining about an unknown error. This new
+ path is only used if m_err_memaddr doesn't have a value (indicating
+ that the memory_error_func callback was not called).
+
+ To test this I just augmented one of the disassemblers to always
+ return -1, before this patch I see this:
+
+ Dump of assembler code for function main:
+ 0x000101aa <+0>: Cannot access memory at address 0x0
+
+ And after this commit I now see:
+
+ Dump of assembler code for function main:
+ 0x000101aa <+0>: unknown disassembler error (error = -1)
+
+ This doesn't really help much, but that's because there's no way to
+ report non memory errors out of the disasembler, because, it was not
+ expected that the disassembler would ever report non memory errors.
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver
+ When running test-case gdb.fortran/call-no-debug.exp with target board
+ native-gdbserver, I run into:
+ ...
+ (gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
+ call (integer) string_func_ (&'abcdefg', 3)^M
+ $2 = 0^M
+ (gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
+ ...
+
+ The problem is that gdb_test is used to match inferior output.
+
+ Fix this by using gdb_test_stdio.
+
+ Tested on x86_64-linux.
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Require use_gdb_stub == 0 where appropriate
+ When running with target board native-gdbserver, we run into a number of FAILs
+ due to use of the start command (and similar), which is not supported when
+ use_gdb_stub == 1.
+
+ Fix this by:
+ - requiring use_gdb_stub == 0 for the entire test-case, or
+ - guarding some tests in the test-case with use_gdb_stub == 0.
+
+ Tested on x86_64-linux.
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix test name in gdb.python/python.exp
+ When running test-case gdb.python/python.exp, we have:
+ ...
+ PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
+ PASS: gdb.python/python.exp: starti via interactive input
+ ...
+
+ The two tests are instances of the same test, with different values for
+ starti command argument from_tty, so it's strange that the test names are so
+ different.
+
+ This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
+ one using a different test name than the outer one. [ That could still make
+ sense if both produced passes, but that's not the case here. ]
+
+ Fix this by using $gdb_test_name, such that we have:
+ ...
+ PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
+ PASS: gdb.python/python.exp: starti via gdb.execute, from tty
+ ...
+
+ Also make this more readable by using variables.
+
+ Tested on x86_64-linux.
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver
+ When running test-case gdb.base/batch-exit-status.exp with target board
+ native-gdbserver, I run into (added missing double quotes for clarity):
+ ...
+ builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
+ -data-directory $build/gdb/testsuite/../data-directory \
+ -iex "set height 0" -iex "set width 0" \
+ -ex "set auto-connect-native-target off" \
+ -iex "set sysroot" -batch ""^M
+ : No such file or directory.^M
+ PASS: gdb.base/batch-exit-status.exp: 1x: \
+ No such file or directory: [lindex $result 2] == 0
+ FAIL: gdb.base/batch-exit-status.exp: 1x: \
+ No such file or directory: [lindex $result 3] == $expect_status
+ ...
+
+ As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
+ local-board.exp", the problem is the use of -ex for
+ "set auto-connect-native-target off", which makes that the last command to
+ be executed, and consequently determines the return status.
+
+ Fix this by using -iex instead.
+
+ Tested on x86_64-linux.
+
+2021-10-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp
+ When running test-case gdb.arch/i386-mpx.exp with target board
+ native-gdbserver, I run into:
+ ...
+ (gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
+ Remote debugging from host ::1, port 42328^M
+ quit^M
+ A debugging session is active.^M
+ ^M
+ Inferior 1 [process 19679] will be killed.^M
+ ^M
+ Quit anyway? (y or n) monitor exit^M
+ Please answer y or n.^M
+ A debugging session is active.^M
+ ^M
+ Inferior 1 [process 19679] will be killed.^M
+ ^M
+ Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
+ ...
+
+ The problem is that the test-case sends a quit at the end (without verifying
+ the result of this in any way):
+ ...
+ send_gdb "quit\n"
+ ...
+
+ Fix this by removing the quit.
+
+ Tested on x86_64-linux.
+
+2021-10-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-11 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
+
+ [ARM] Add support for M-profile MVE extension
+ This patch adds support for the M-profile MVE extension, which includes the
+ following:
+
+ - New M-profile XML feature m-profile-mve
+ - MVE vector predication status and control register (VPR)
+ - p0 pseudo register (contained in the VPR)
+ - q0 ~ q7 pseudo vector registers
+ - New feature bits
+ - Documentation update
+
+ Pseudo register p0 is the least significant bits of vpr and can be accessed
+ as $p0 or displayed through $vpr. For more information about the register
+ layout, please refer to [1].
+
+ The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers
+ per q register.
+
+ The register dump looks like this:
+
+ (gdb) info reg all
+ r0 0x0 0
+ r1 0x0 0
+ r2 0x0 0
+ r3 0x0 0
+ r4 0x0 0
+ r5 0x0 0
+ r6 0x0 0
+ r7 0x0 0
+ r8 0x0 0
+ r9 0x0 0
+ r10 0x0 0
+ r11 0x0 0
+ r12 0x0 0
+ sp 0x0 0x0 <__Vectors>
+ lr 0xffffffff -1
+ pc 0xd0c 0xd0c <Reset_Handler>
+ xpsr 0x1000000 16777216
+ d0 0 (raw 0x0000000000000000)
+ d1 0 (raw 0x0000000000000000)
+ d2 0 (raw 0x0000000000000000)
+ d3 0 (raw 0x0000000000000000)
+ d4 0 (raw 0x0000000000000000)
+ d5 0 (raw 0x0000000000000000)
+ d6 0 (raw 0x0000000000000000)
+ d7 0 (raw 0x0000000000000000)
+ d8 0 (raw 0x0000000000000000)
+ d9 0 (raw 0x0000000000000000)
+ d10 0 (raw 0x0000000000000000)
+ d11 0 (raw 0x0000000000000000)
+ d12 0 (raw 0x0000000000000000)
+ d13 0 (raw 0x0000000000000000)
+ d14 0 (raw 0x0000000000000000)
+ d15 0 (raw 0x0000000000000000)
+ fpscr 0x0 0
+ vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ]
+ s0 0 (raw 0x00000000)
+ s1 0 (raw 0x00000000)
+ s2 0 (raw 0x00000000)
+ s3 0 (raw 0x00000000)
+ s4 0 (raw 0x00000000)
+ s5 0 (raw 0x00000000)
+ s6 0 (raw 0x00000000)
+ s7 0 (raw 0x00000000)
+ s8 0 (raw 0x00000000)
+ s9 0 (raw 0x00000000)
+ s10 0 (raw 0x00000000)
+ s11 0 (raw 0x00000000)
+ s12 0 (raw 0x00000000)
+ s13 0 (raw 0x00000000)
+ s14 0 (raw 0x00000000)
+ s15 0 (raw 0x00000000)
+ s16 0 (raw 0x00000000)
+ s17 0 (raw 0x00000000)
+ s18 0 (raw 0x00000000)
+ s19 0 (raw 0x00000000)
+ s20 0 (raw 0x00000000)
+ s21 0 (raw 0x00000000)
+ s22 0 (raw 0x00000000)
+ s23 0 (raw 0x00000000)
+ s24 0 (raw 0x00000000)
+ s25 0 (raw 0x00000000)
+ s26 0 (raw 0x00000000)
+ s27 0 (raw 0x00000000)
+ s28 0 (raw 0x00000000)
+ s29 0 (raw 0x00000000)
+ s30 0 (raw 0x00000000)
+ s31 0 (raw 0x00000000)
+ q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+ p0 0x0 0
+
+ Built and regtested with a simulator.
+
+ [1] https://developer.arm.com/documentation/ddi0553/bn
+
+ Co-Authored-By: Luis Machado <luis.machado@linaro.org>
+
+2021-10-11 Luis Machado <luis.machado@linaro.org>
+
+ [ARM] Refactor pseudo register numbering
+ The pseudo register handling for ARM uses some hardcoded constants to
+ determine types and names. In preparation to the upcoming MVE support
+ patch (that will add another pseudo register), this patch refactors and
+ reorganizes things in order to simplify handling of future pseudo registers.
+
+ We keep track of the first pseudo register number in a group and the number of
+ pseudo registers in that group.
+
+ Right now we only have the S and Q pseudo registers.
+
+2021-10-11 Luis Machado <luis.machado@linaro.org>
+
+ [ARM] Small refactoring of arm gdbarch initialization
+ This is in preparation to MVE support, where we will define another
+ pseudo register. We need to define the pseudo register numbers *after*
+ accounting for all the registers in the XML description, so move
+ the call to tdesc_use_registers up.
+
+ If we don't do it, GDB's register count won't consider registers contained
+ in the XML but ignored by GDB, throwing the register numbering off.
+
+2021-10-11 Luis Machado <luis.machado@linaro.org>
+
+ [ARM] Refactor some constants
+ In preparation for the MVE extension patch, this one refactors some of
+ the register-related constants we have for ARM.
+
+ Basically I'm separating counting constants from numbering constants.
+
+ For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS
+ is a counting constant.
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp
+ When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
+ (with glibc 2.34) I run into:
+ ...
+ (gdb) ^M
+ PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
+ Expecting: ^(-var-create array \* array[^M
+ ]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -var-create array * array^M
+ &"Attempt to use a type name as an expression.\n"^M
+ ^error,msg="-var-create: unable to create variable object"^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
+ ...
+
+ The problem is that the name array is used both:
+ - as the name for a local variable
+ - as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
+ by nss/nss_files/files-hosts.c.
+
+ Fix this by ignoring the shared lib symbols.
+
+ Likewise in a couple of other fortran tests.
+
+ Tested on x86_64-linux.
+
+2021-10-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ z80/disassembler: call memory_error_func when appropriate
+ If a call to the read_memory_func fails then we should call the
+ memory_error_func to notify the user of the disassembler of the
+ address that was a problem.
+
+ Without this GDB will report all memory errors as being at address
+ 0x0.
+
+ opcodes/ChangeLog:
+
+ * z80-dis.c (fetch_data): Call memory_error_func if the
+ read_memory_func call fails.
+
+2021-10-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ s12z/disassembler: call memory_error_func when appropriate
+ If a call to the read_memory_func fails then we should call the
+ memory_error_func to notify the user of the disassembler of the
+ address that was a problem.
+
+ Without this GDB will report all memory errors as being at address
+ 0x0.
+
+ opcodes/ChangeLog:
+
+ * s12z-disc.c (abstract_read_memory): Call memory_error_func if
+ the read_memory_func call fails.
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp
+ A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range
+ in gdb.dwarf2/dw2-ref-missing-frame.exp".
+
+ Before the commit the main file was compiled with debug info, and the two
+ others not:
+ ...
+ if {[prepare_for_testing_full "failed to prepare" \
+ [list $testfile {} $srcfile {} $srcfuncfile {} \
+ $srcmainfile debug]]} {
+ ...
+
+ After the commit, all were compiled with debug info, and consequently, there
+ are two versions of debug info for $srcfuncfile. This shows up as a FAIL when
+ running the test-case with target boards readnow and cc-with-debug-names.
+
+ Fix this by using prepare_for_testing_full, as before.
+
+ Tested on x86_64-linux.
+
+ Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
+ gdb.dwarf2/dw2-ref-missing-frame.exp")
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use require for ensure_gdb_index
+ Replace:
+ ...
+ if { [ensure_gdb_index $binfile] == -1 } {
+ return -1
+ }
+ ...
+ with:
+ ...
+ require {ensure_gdb_index $binfile} != -1
+ ...
+ and consequently, add a missing UNTESTED message.
+
+ Tested on x86_64-linux, both with native and target board readnow.
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle readnow in ensure_gdb_index
+ When running test-case gdb.base/with-mf.exp with target board readnow, I run
+ into:
+ ...
+ FAIL: gdb.base/with-mf.exp: check if index present
+ ...
+ This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in
+ gdb.rust/dwindex.exp".
+
+ Before that commit, the proc ensure_gdb_index would treat the line:
+ ...
+ .gdb_index: faked for "readnow"^M
+ ...
+ as proof that an index is already present (which is incorrect).
+
+ Now, instead it generates aforementioned FAIL and continues to generate an
+ index.
+
+ Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
+ such that we bail out instead.
+
+ Tested on x86_64-linux.
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.exp
+ The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to
+ add an index as a failure to add an index for a symlink:
+ ...
+ if { [ensure_gdb_index $symlink] == -1 } {
+ fail "Unable to call gdb-add-index with a symlink to a symfile"
+ return -1
+ }
+ ...
+
+ However, it's possible that the gdb-add-index also fails with a regular
+ file. Add a check for that situation.
+
+ Tested on x86_64-linux.
+
+2021-10-11 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add proc require in lib/gdb.exp
+ Add a new proc require in lib/gdb.exp, and use it to shorten:
+ ...
+ if { [gdb_skip_xml_test] } {
+ # Valgrind gdbserver requires gdb with xml support.
+ untested "missing xml support"
+ return 0
+ }
+ ...
+ into:
+ ...
+ require gdb_skip_xml_test 0
+ ...
+
+ Tested on x86_64-linux, both with and without a trigger patch that forces
+ gdb_skip_xml_test to return 1.
+
+2021-10-11 Michael Forney <mforney@mforney.org>
+
+ bfd: Remove use of void pointer arithmetic
+ This is not valid in ISO C. Instead, use a pointer to bfd_byte.
+
+ * peicode.h (pe_bfd_object_p): Remove use of void pointer
+ arithmetic.
+
+2021-10-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Make execute_command_to_string return string on throw
+ The pattern for using execute_command_to_string is:
+ ...
+ std::string output;
+ output = execute_fn_to_string (fn, term_out);
+ ...
+
+ This results in a problem when using it in a try/catch:
+ ...
+ try
+ {
+ output = execute_fn_to_string (fn, term_out)
+ }
+ catch (const gdb_exception &e)
+ {
+ /* Use output. */
+ }
+ ...
+
+ If an expection was thrown during execute_fn_to_string, then the output
+ remains unassigned, while it could be worthwhile to known what output was
+ generated by gdb before the expection was thrown.
+
+ Fix this by returning the string using a parameter instead:
+ ...
+ execute_fn_to_string (output, fn, term_out)
+ ...
+
+ Also add a variant without string parameter, to support places where the
+ function is used while ignoring the result:
+ ...
+ execute_fn_to_string (fn, term_out)
+ ...
+
+ Tested on x86_64-linux.
+
+2021-10-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add check-readmore
+ Consider the gdb output:
+ ...
+ 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
+ (gdb) ^M
+ Thread 2 "run-attach-whil" stopped.^M
+ ...
+
+ When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $',
+ it may pass or fail.
+
+ This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's
+ currently no way to reliably find this type of FAILs.
+
+ We have check-read1, but that one actually make the test pass reliably.
+
+ We need something like the opposite of check-read1: something that makes
+ expect read a bit slower, or more exhaustively.
+
+ Add a new test target check-readmore that implements this.
+
+ There are two methods of implementing this in read1.c:
+ - the first method waits a bit before doing a read
+ - the second method does a read and then decides whether to
+ return or to wait a bit and do another read, and so on.
+
+ The second method is potentially faster, has less risc of timeout and could
+ potentially detect more problems. The first method has a simpler
+ implementation.
+
+ The second method is enabled by default. The default waiting period is 10
+ miliseconds.
+
+ The first method can be enabled using:
+ ...
+ $ export READMORE_METHOD=1
+ ...
+ and the waiting period can be specified in miliseconds using:
+ ...
+ $ export READMORE_SLEEP=9
+ ...
+
+ Also a log file can be specified using:
+ ...
+ $ export READMORE_LOG=$(pwd -P)/LOG
+ ...
+
+ Tested on x86_64-linux.
+
+ Testing with check-readmore showed these regressions:
+ ...
+ FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue)
+ FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue)
+ ...
+
+ I have not been able to find a problem in the test-case, and I think it's the
+ nature of both the test-case and readmore that makes it run longer. Make
+ these pass by increasing the alarm timeout from 60 to 120 seconds.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957
+
+2021-10-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix fortran module tests with stressed cpu
+ When running these test-cases:
+ - gdb.fortran/info-modules.exp
+ - gdb.fortran/module.exp
+ - gdb.mi/mi-fortran-modules.exp
+ in conjunction with:
+ ...
+ $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
+ ...
+ I run into timeouts.
+
+ Fix this by using:
+ - "set auto-solib-add off" to avoid symbols of shared libs
+ (which doesn't work for libc, now that libpthread_name_p has been
+ updated to match libc)
+ - "nosharedlibrary" to avoid symbols of libc
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133
+
+2021-10-09 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
+
+ PR28415, invalid read in xtensa_read_table_entries
+ PR 28415
+ PR 28416
+ * elf32-xtensa.c (xtensa_read_table_entries): Handle error
+ return from retrieve_contents.
+
+2021-10-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpu
+ When running test-case gdb.base/info-types-c++.exp in conjunction with:
+ ...
+ $ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
+ ...
+ we get:
+ ...
+ FAIL: gdb.base/info-types-c++.exp: info types (timeout)
+ ...
+
+ Fix this by setting auto-solib-add to off.
+
+ Tested on x86_64-linux.
+
+2021-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1
+ When running test-case gdb.base/info_sources_2.exp with check-read1, I run
+ into:
+ ...
+ FAIL: gdb.base/info_sources_2.exp: args: : info sources (timeout)
+ ...
+
+ Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than
+ as one whole line.
+
+ Also add the missing handling of "Objfile has no debug information".
+
+ Tested on x86_64-linux.
+
+2021-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1
+ When running test-case gdb.mi/gdb2549.exp with check-read1, I run into:
+ ...
+ FAIL: gdb.mi/gdb2549.exp: register values x (timeout)
+ ...
+
+ Fix this by applying the same fix as for "register values t" in commit
+ 478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1".
+
+ Tested on x86_64-linux.
+
+2021-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1
+ When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1,
+ I run into:
+ ...
+ (gdb) maint internal-error foobar^M
+ src/gdb/maint.c:82: internal-error: foobar^M
+ A problem internal to GDB has been detectedFAIL: \
+ gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \
+ scan for backtrace (GDB internal error)
+ Resyncing due to internal error.
+ ,^M
+ ...
+
+ The corresponding gdb_test_multiple in the test-case contains:
+ ...
+ -early -re "^A problem internal to GDB has been detected,\r\n" {
+ incr header_lines
+ exp_continue
+ }
+ ...
+ but instead this one triggers in gdb_test_multiple:
+ ...
+ -re ".*A problem internal to GDB has been detected" {
+ fail "$message (GDB internal error)"
+ gdb_internal_error_resync
+ set result -1
+ }
+ ...
+
+ Fix this by likewise shortening the regexp to before the comma.
+
+ Tested on x86_64-linux.
+
+2021-10-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add nopie in two test-cases
+ When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with
+ gcc-PIE installed (switching compiler default to -fPIE/-pie), I get:
+ ...
+ gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \
+ warning: relocation in read-only section `.text'
+ ld: warning: creating DT_TEXTREL in a PIE
+ UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare
+ ...
+
+ This is due to using a hardcoded .S file that was generated with -fno-PIE.
+
+ Fix this by adding the missing nopie.
+
+ Likewise in gdb.arch/amd64-tailcall-noret.exp.
+
+ Tested on x86_64-linux.
+
+2021-10-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34
+ When running test-case gdb.threads/check-libthread-db.exp on openSUSE
+ Tumbleweed (with glibc 2.34) I get:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib64/libthread_db.so.1".^M
+ Stopped due to shared library event:^M
+ Inferior loaded /lib64/libm.so.6^M
+ /lib64/libc.so.6^M
+ (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue
+ ...
+
+ The check expect the inferior to load libpthread, but since glibc 2.34
+ libpthread has been integrated into glibc, and consequently it's no longer
+ a dependency:
+ ...
+ $ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db
+ linux-vdso.so.1 (0x00007ffe4cae4000)
+ libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000)
+ libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000)
+ /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000)
+ ...
+
+ Fix this by updating the regexp to expect libpthread or libc.
+
+ Tested on x86_64-linux.
+
+2021-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8
+ With gcc 7.5.0, I get:
+ ...
+ (gdb) guile (print (type-range (field-type (type-field (value-type \
+ (value-dereference f)) "items"))))^M
+ = (0 0)^M
+ (gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \
+ on flexible array member: $cmd
+ ...
+ but with gcc 4.8.5, I get instead:
+ ...
+ (gdb) guile (print (type-range (field-type (type-field (value-type \
+ (value-dereference f)) "items"))))^M
+ = (0 -1)^M
+ (gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \
+ on flexible array member: $cmd
+ ...
+
+ There's a difference in debug info. With gcc 4.8.5, we have:
+ ...
+ <2><224>: Abbrev Number: 15 (DW_TAG_member)
+ <225> DW_AT_name : items
+ <22b> DW_AT_type : <0x231>
+ <1><231>: Abbrev Number: 4 (DW_TAG_array_type)
+ <232> DW_AT_type : <0x105>
+ <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type)
+ <23b> DW_AT_type : <0x11a>
+ <23f> DW_AT_upper_bound : 0xffffffffffffffff
+ ...
+ and with gcc 7.5.0, we have instead:
+ ...
+ <2><89f>: Abbrev Number: 12 (DW_TAG_member)
+ <8a0> DW_AT_name : items
+ <8a6> DW_AT_type : <0x8ac>
+ <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type)
+ <8ad> DW_AT_type : <0x29d>
+ <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type)
+ <2><8b6>: Abbrev Number: 0
+ ...
+
+ As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust
+ gdb.python/flexible-array-member.exp expected pattern":
+ ...
+ Ideally, GDB would present a consistent and documented value for an
+ array member declared with size 0, regardless of how the debug info
+ looks like.
+ ...
+
+ As in gdb.python/flexible-array-member.exp, change the test to accept the two
+ values.
+
+ Tested on x86_64-linux.
+
+2021-10-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add accessors for field (and call site) location
+ Add accessors for the various location values in struct field. This
+ lets us assert that when we get a location value of a certain kind (say,
+ bitpos), the field's location indeed contains a value of that kind.
+
+ Remove the SET_FIELD_* macros, instead use the new setters directly.
+ Update the FIELD_* macros used to access field locations to go through
+ the getters. They will be removed in a subsequent patch.
+
+ There are places where the FIELD_* macros are used on call_site_target
+ structures, because it contains members of the same name (loc_kind and
+ loc). For now, I have replicated the getters/setters in
+ call_site_target. But we could perhaps eventually factor them in a
+ "location" structure that can be used at both places.
+
+ Note that the field structure, being zero-initialized, defaults to a
+ bitpos location with value 0. While writing this patch, I tried to make
+ it default to an "unset" location, to catch places where we would miss
+ setting a field's location. However, I found that some places relied on
+ the default being "bitpos 0", so I left it as-is. This change could
+ always be done as follow-up work, making these places explicitly set the
+ "bitpos 0" location.
+
+ I found two issues to fix:
+
+ - I got some failures in the gdb.base/infcall-nested-structs-c++.exp
+ test. They were caused by two functions in amd64-tdep.c using
+ TYPE_FIELD_BITPOS before checking if the location is of the bitpos
+ kind, which they do indirectly through `field_is_static`. Simply
+ move getting the bitpos below the field_is_static call.
+
+ - I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in
+ make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
+ and later access them through FIELD_ENUMVAL. Fix that by using
+ set_loc_enumval to set the value.
+
+ Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
+
+2021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Support aliases for Zbs instructions
+ Add aliases for the non-immediate mnemonics of b{set,clr,inv,ext} to
+ yencode the respective immediate insn b{set,clr,inv,ext}i when the
+ second source operand is an immediate.
+
+ 2021-01-11 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ gas/
+ * testsuite/gas/riscv/b-ext.d: Add tests.
+ * testsuite/gas/riscv/b-ext.s: Likewise.
+ * testsuite/gas/riscv/b-ext-64.d: Likewise.
+ * testsuite/gas/riscv/b-ext-64.s: Likewise.
+ opcodes/
+ * riscv-opc.c (riscv_opcodes): Add aliases for Zbs.
+
+ Suggested-by: Jan Beulich <jbeulich@suse.com>
+
+2021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Add support for Zbs instructions
+ This change adds the Zbs instructions from the Zbs 1.0.0 specification.
+ See
+ https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0
+ for the frozen specification.
+
+ 2021-01-09 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Added zbs.
+ gas/
+ * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZBS.
+ * testsuite/gas/riscv/b-ext.d: Test Zbs instructions.
+ * testsuite/gas/riscv/b-ext.s: Likewise.
+ * testsuite/gas/riscv/b-ext-64.d: Likewise.
+ * testsuite/gas/riscv/b-ext-64.s: Likewise.
+ include/
+ * opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for Zbs.
+ * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZBS.
+ opcodes/
+ * riscv-opc.c (riscv_supported_std_z_ext): Add zbs.
+
+2021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Update extension version for Zb[abc] to 1.0.0
+ 2021-10-06 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ bfd/
+ * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
+ number for zba, zbb and zbc to 1.0.0
+
+
+ Version-changes: 3
+ - Updated version numbers for zba, zbb and zbc to 1.0.0
+
+2021-10-07 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ RISC-V: Split Zb[abc] into commented sections
+ The Zb[abc] opcodes are bundled just below the Privileged opcodes in
+ riscv_opcodes, possibly giving the appearance that they are part of
+ the Privileged spec for an uninitiated reader. This separates them
+ out and adds comments above each section to clearly identify them as
+ Zba, Zbb or Zbc opcodes.
+
+ 2021-10-04 Philipp Tomsich <philipp.tomsich@vrull.eu>
+
+ opcodes/
+ * riscv-opc.c: Split of Zb[abc] instructions and add comments.
+
+2021-10-07 Alan Modra <amodra@gmail.com>
+
+ PR28423, use-after-free in objdump
+ XCOFF archives use a bi-directional linked list for file members. So
+ one member points to both the previous member and the next member.
+ Members may not be sequentially ordered in the file. This of course
+ is over-engineered nonsense and an attractive target for fuzzers.
+ (There is even a free list of members!) The testcase in PR28423 is an
+ XCOFF archive with one member pointing to itself, which results in
+ lots of bad behaviour. For example, "ar t" never terminates.
+
+ The use-after-free with "objdump -r" happens like this: The first
+ archive element is opened, its symbols are read and "canonicalized"
+ for objdump, then relocations are read and printed. Those relocations
+ use the canonicalized symbols, and also happen to be cached by the
+ coff bfd backend support. objdump frees the symbols. The next
+ archive element is then opened. This must be done before the first
+ element is closed, because finding the next element uses data held in
+ the currect element. Unfortunately the next element happens to be the
+ original, so we aren't opening, we're reopening a bfd which has cached
+ data. When the relocations are printed they use the cached copy
+ containing references to the freed canonical symbols.
+
+ This patch adds a little sanity checking to the XCOFF "open next
+ archive file" support, so that it rejects archive members pointing at
+ themselves. That is sufficient to cure this problem. Anything more
+ is overkill. If someone deliberately fuzzes an XCOFF archive with an
+ element loop then reports an "ar" bug when it runs forever, they will
+ find their bug report closed WONTFIX.
+
+ PR 28423
+ * coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied
+ by member name in areltdata.extra_size.
+ (_bfd_xcoff_openr_next_archived_file): Sanity check nextoff.
+ * coff64-rs6000.c (xcoff64_openr_next_archived_file): Call
+ _bfd_xcoff_openr_next_archived_file.
+
+2021-10-07 Alan Modra <amodra@gmail.com>
+
+ PR28422, build_id use-after-free
+ This fixes a bug in commit 5d9bbb73c1df. All fields preserved from a
+ bfd in struct bfd_preserve need to be cleared in bfd_reinit.
+
+ PR 28422
+ * format.c (bfd_reinit): Clear build_id.
+
+2021-10-07 Alan Modra <amodra@gmail.com>
+
+ Change ridiculous section size error
+ Rather than reporting "memory exhausted", report "file truncated".
+ You can hit this error on small fuzzed object files, or on files that
+ are actually truncated. In either case sizes can be such that an out
+ of memory error is a little confusing.
+
+ * compress.c (bfd_get_full_section_contents): Set
+ bfd_error_file_truncated rather than bfd_error_no_memory when
+ section size exceeds file size.
+
+2021-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.base/annota1.exp
+ On openSUSE tumbleweed I run into:
+ ...
+ FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+ ...
+ due to a message related to libthread_db:
+ ...
+ ^Z^Zstarting^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib64/libthread_db.so.1".^M
+ ^M
+ ^Z^Zframes-invalid^M
+ ...
+ which is not matched by the regexp.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2021-10-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Refactor regexp in gdb.base/annota1.exp
+ Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition.
+
+ Tested on x86_64-linux.
+
+2021-10-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-06 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/doc: improve 'show print elements' description
+ The documentation for 'show print elements' contains the line:
+
+ If the number is 0, then the printing is unlimited.
+
+ However, this line is now out of date as can be seen by this GDB
+ session:
+
+ (gdb) set print elements 0
+ (gdb) show print elements
+ Limit on string chars or array elements to print is unlimited.
+
+ The value 0 does indeed mean unlimited, and this is described in the
+ 'set print elements' section, however, for 'show print elements' the
+ user will never see the value 0, so lets just remove that bit from the
+ docs.
+
+2021-10-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.exp
+ When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed,
+ I run into:
+ ...
+ PASS: gdb.tui/corefile-run.exp: load corefile
+ FAIL: gdb.tui/corefile-run.exp: run until the end
+ ...
+
+ What's going on is easier to see when also doing dump_screen if
+ check_contents passes, and inspecting state at the preceding PASS:
+ ...
+ +-------------------------------------------------------------------------+
+ exec No process In: L?? PC: ??
+ [New LWP 16629]
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib64/libthread_db.so.1".
+ Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output
+ s/gdb.tui/corefile-run/corefi'.
+ Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+ #0 main ()
+ --Type <RET> for more, q to quit, c to continue without paging--
+ ...
+
+ The problem is that we're getting a pagination prompt, and the subsequent run
+ command is interpreted as an answer to that prompt.
+
+ Fix this by:
+ - detecting the gdb prompt in response to "load corefile", such that
+ we detect the failure earlier, and
+ - doing a "set pagination off" in Term::clean_restart.
+
+ Tested on x86_64-linux.
+
+2021-10-06 Alan Modra <amodra@gmail.com>
+
+ PR28420, ecoff fuzzing failures
+ PR 28420
+ * coff-mips.c (mips_adjust_reloc_in): Replace abort with error
+ message and return.
+ * ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts,
+ instead handle errors gracefully.
+
+2021-10-06 Alan Modra <amodra@gmail.com>
+
+ PR28402, fail to allocate line number array
+ This fixes a situation where the COFF code allocated memory for
+ internal representaion arrays before reading the external file data.
+ That meant the allocation didn't have any sanity check against file
+ size.
+
+ PR 28402
+ * coffcode.h (buy_and_read): Malloc rather than alloc memory.
+ (coff_slurp_line_table): Read native line number info before
+ allocating memory for internal line number array. Adjust error
+ paths to suit. Remove now unnecessary line number count check.
+ (coff_slurp_reloc_table): Adjust to suit buy_and_read change.
+
+2021-10-06 Alan Modra <amodra@gmail.com>
+
+ PR28403, null pointer dereference in disassemble_bytes
+ Indexing of symbol and howto arrays wasn't checked in aout targets.
+
+ PR 28403
+ * aout-ns32k.c (MY (reloc_howto)): Sanity check howto_table index.
+ Make r_index unsigned.
+ (MY_swap_std_reloc_in): Make r_index unsigned.
+ * aoutx.h (MOVE_ADDRESS): Sanity check symbol r_index.
+ (aout_link_input_section_std): Make r_index unsigned.
+ (aout_link_input_section_ext): Likewise.
+ * i386lynx.c (MOVE_ADDRESS): Sanity check symbol r_index.
+ (swap_ext_reloc_in, swap_std_reloc_in): Make r_index unsigned.
+ * pdp11.c (MOVE_ADDRESS): Sanity check symbol r_index.
+
+2021-10-06 Alan Modra <amodra@gmail.com>
+
+ PR28401, invalid section name lookup
+ The PR28401 testcase has a section named "", ie. an empty string.
+ This results in some silly behaviour in load_debug_section, and
+ dump_dwarf_section. Fix that. Note that this patch doesn't correct
+ the main complaint in PR28401, "failed to allocate", since malloc
+ failures on sections having huge bogus sizes are to be expected. We
+ can't safely catch all such cases by comparing with file size, for
+ example, where sections contain compressed data.
+
+ PR 28401
+ * objdump.c (load_debug_section): Don't attempt to retrieve
+ empty name sections.
+ (dump_dwarf_section): Likewise.
+
+2021-10-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Make tui testing less verbose
+ Currently, tui testing is rather verbose. When using these RUNTESTFLAGS to
+ pick up all tui tests (17 in total):
+ ...
+ rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \
+ | xargs grep -l tuiterm_env) )
+ ...
+ we have:
+ ...
+ $ wc -l gdb.log
+ 120592 gdb.log
+ ...
+
+ Most of the output is related to controlling the tui screen, but that does
+ not give a top-level sense of how the test-case progresses.
+
+ Put differently: a lot of bandwith is used to describe how we arrive at a
+ certain tui screen state. But we don't actually always show the state we
+ arrive at, unless there's a FAIL.
+
+ And if there's say, a PASS that should actually be FAILing, it's hard to
+ detect.
+
+ Fix this by:
+ - dropping the -log on the call to verbose in _log. We still can get the
+ same info back using runtest -v.
+ - dumping the screen or box that we're checking, also when the test passes.
+
+ Brings down verbosity to something more reasonable:
+ ...
+ $ wc -l gdb.log
+ 3221 gdb.log
+ ...
+
+ Tested on x86_64-linux.
+
+2021-10-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add Term::dump_box in lib/tuiterm.exp
+ Factor out new proc Term::get_region and use it to implement a
+ new proc Term::dump_box, similar to Term::dump_screen.
+
+ Tested on x86_64-linux.
+
+2021-10-05 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Remove deprecated assertion in setting::get
+ The commit 702991711a91bd47b209289562843a11e7009396 (gdb: Have setter
+ and getter callbacks for settings) makes it possible for a setting not
+ to be backed by a memory buffer but use callback functions instead to
+ retrieve or set the setting's value.
+
+ An assertion was not properly updated to take into account that the
+ m_var member (which points to a memory buffer, if used) might be nullptr
+ if the setting uses callback functions. If the setting is backed by a
+ memory buffer, the m_var has to be non nullptr, which is already checked
+ before the pointer is dereferenced.
+
+ This commit removes this assertion as it is not valid anymore.
+
+2021-10-05 Tom Tromey <tromey@adacore.com>
+
+ Remove 'varsize-limit'
+ This makes the Ada-specific "varsize-limit" a synonym for
+ "max-value-size", and removes the Ada-specific checks of the limit.
+
+ I am not certain of the history here, but it seems to me that this
+ code is fully obsolete now. And, removing this makes it possible to
+ index large Ada arrays without triggering an error. A new test case
+ is included to demonstrate this.
+
+2021-10-05 Tom Tromey <tromey@adacore.com>
+
+ Allow lazy 'zero' value
+ This changes value_zero to create a lazy value. In many cases,
+ value_zero is called in expression evaluation to wrap a type in a
+ non-eval context. It seems senseless to allocate a buffer in these
+ cases.
+
+ A new 'is_zero' flag is added so we can preserve the existing
+ assertions in value_fetch_lazy.
+
+ A subsequent patch will add a test where creating a zero value would
+ fail, due to the variable size check. However, the contents of this
+ value are never needed, and so creating a lazy value avoids the error
+ case.
+
+2021-10-05 Tom Tromey <tromey@adacore.com>
+
+ Add lval_funcs::is_optimized_out
+ This adds an is_optimized_out function pointer to lval_funcs, and
+ changes value_optimized_out to call it. This new function lets gdb
+ determine if a value is optimized out without necessarily fetching the
+ value. This is needed for a subsequent patch, where an attempt to
+ access a lazy value would fail due to the value size limit -- however,
+ the access was only needed to determine the optimized-out state.
+
+2021-10-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAIL in gdb.mi/mi-nsmoribund.exp
+ Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
+ mi_gdb_test" we run into:
+ ...
+ PASS: gdb.mi/mi-nsmoribund.exp: print done = 1
+ Expecting: ^(.*[^M
+ ]+)?([^
+ ]*^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"^M
+ \*running,thread-id="[0-9]+"[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ 103-exec-continue --all^M
+ =library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\
+ host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\
+ ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M
+ 103^running^M
+ *running,thread-id="5"^M
+ (gdb) ^M
+ FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output)
+ ...
+
+ The regexp expect running messages for all threads, but we only get one for
+ thread 5.
+
+ The test-case uses non-stop mode, and when the exec-continue --all command is
+ issued, thread 5 is stopped and all other threads are running. Consequently,
+ only thread 5 is resumed, and reported as running.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2021-10-05 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: fix memory leak in python inferior code
+ When a user creates a gdb.Inferior object for the first time a new
+ Python object is created. This object is then cached within GDB's
+ inferior object using the registry mechanism (see
+ inferior_to_inferior_object in py-inferior.c, specifically the calls
+ to inferior_data and set_inferior_data).
+
+ The Python Reference to the gdb.Inferior object held within the real
+ inferior object ensures that the reference count on the Python
+ gdb.Inferior object never reaches zero while the GDB inferior object
+ continues to exist.
+
+ At the same time, the gdb.Inferior object maintains a C++ pointer back
+ to GDB's real inferior object. We therefore end up with a system that
+ looks like this:
+
+ Python Reference
+ |
+ |
+ .----------. | .--------------.
+ | |------------------->| |
+ | inferior | | gdb.Inferior |
+ | |<-------------------| |
+ '----------' | '--------------'
+ |
+ |
+ C++ Pointer
+
+ When GDB's inferior object is deleted (say the inferior exits) then
+ py_free_inferior is called (thanks to the registry system), this
+ function looks up the Python gdb.Inferior object and sets the C++
+ pointer to nullptr and finally reduces the reference count on the
+ Python gdb.Inferior object.
+
+ If at this point the user still holds a reference to the Python
+ gdb.Inferior object then nothing happens. However, the gdb.Inferior
+ object is now in the non-valid state (see infpy_is_valid in
+ py-inferior.c), but otherwise, everything is fine.
+
+ However, if there are no further references to the Python gdb.Inferior
+ object, or, once the user has given up all their references to the
+ gdb.Inferior object, then infpy_dealloc is called.
+
+ This function currently checks to see if the inferior pointer within
+ the gdb.Inferior object is nullptr or not. If the pointer is nullptr
+ then infpy_dealloc immediately returns.
+
+ Only when the inferior point in the gdb.Inferior is not nullptr do
+ we (a) set the gdb.Inferior reference inside GDB's inferior to
+ nullptr, and (b) call the underlying Python tp_free function.
+
+ There are a number things wrong here:
+
+ 1. The Python gdb.Inferior reference within GDB's inferior object
+ holds a reference count, thus, setting this reference to nullptr
+ without first decrementing the reference count would leak a
+ reference, however...
+
+ 2. As GDB's inferior holds a reference then infpy_dealloc will never
+ be called until GDB's inferior object is deleted. Deleting a GDB
+ inferior ohject calls py_free_inferior, and so gives up the
+ reference. At this point there is no longer a need to call
+ set_inferior_data to set the field back to NULL, that field must
+ have been cleared in order to get the reference count to zero, which
+ means...
+
+ 3. If we know that py_free_inferior must be called before
+ infpy_dealloc, then we know that the inferior pointer in
+ gdb.Inferior will always be nullptr when infpy_dealloc is called,
+ this means that the call to the underlying tp_free function will
+ always be skipped. Skipping this call will cause Python to leak the
+ memory associated with the gdb.Inferior object, which is what we
+ currently always do.
+
+ Given all of the above, I assert that the C++ pointer within
+ gdb.Inferior will always be nullptr when infpy_dealloc is called.
+ That's what this patch does.
+
+ I wrote a test for this issue making use of Pythons tracemalloc
+ module, which allows us to spot this memory leak.
+
+2021-10-05 Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>
+
+ [gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp
+ Following 2 test points are failing with clang compiler
+
+ (gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_nofb print
+ (gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_loopfb print
+
+ As in commit f677852bbda "[gdb/testsuite] Use function_range in
+ gdb.dwarf2/dw2-abs-hi-pc.exp", the problem is that the CU and functions
+ have an empty address range, due to using asm labels in global scope,
+ which is a known source of problems, as explained in the comment of proc
+ function_range in gdb/testsuite/lib/dwarf.exp. Hence fix this also by
+ using function_range.
+
+ Tested on x86_64-linux with gcc and clang.
+
+2021-10-05 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: add a new gdb_exiting event
+ Add a new event, gdb.events.gdb_exiting, which is called once GDB
+ decides it is going to exit.
+
+ This event is not triggered in the case that GDB performs a hard
+ abort, for example, when handling an internal error and the user
+ decides to quit the debug session, or if GDB hits an unexpected,
+ fatal, signal.
+
+ This event is triggered if the user just types 'quit' at the command
+ prompt, or if GDB is run with '-batch' and has processed all of the
+ required commands.
+
+ The new event type is gdb.GdbExitingEvent, and it has a single
+ attribute exit_code, which is the value that GDB is about to exit
+ with.
+
+ The event is triggered before GDB starts dismantling any of its own
+ internal state, so, my expectation is that most Python calls should
+ work just fine at this point.
+
+ When considering this functionality I wondered about using the
+ 'atexit' Python module. However, this is triggered when the Python
+ environment is shut down, which is done from a final cleanup. At
+ this point we don't know for sure what other GDB state has already
+ been cleaned up.
+
+2021-10-05 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: update events test to handle missing exit_code
+ The test gdb.python/py-events.exp sets up a handler for the gdb.exited
+ event. Unfortunately the handler is slightly broken, it assumes that
+ the exit_code attribute will always be present. This is not always
+ the case.
+
+ In a later commit I am going to add more tests to py-events.exp test
+ script, and in so doing I expose the bug in our handling of gdb.exited
+ events.
+
+ Just to be clear, GDB itself is fine, it is the test that is not
+ written correctly according to the Python Events API.
+
+ So, in this commit I fix the Python code in the test, and extend the
+ test case to exercise more paths through the Python code.
+
+ Additionally, I noticed that the gdb.exited event is used as an
+ example in the documentation for how to write an event handler.
+ Unfortunately the same bug that we had in our test was also present in
+ the example code in the manual.
+
+ So I've fixed that too.
+
+ After this commit there is no functional change to GDB.
+
+2021-10-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-04 Tom Tromey <tromey@adacore.com>
+
+ Use unique_xmalloc_ptr<char> when demangling
+ I noticed that some methods in language_defn could use
+ unique_xmalloc_ptr<char> rather than a plain 'char *'. This patch
+ implements this change, fixing up the fallout and changing
+ gdb_demangle to also return this type. In one spot, std::string is
+ used to simplify some related code, and in another, an auto_obstack is
+ used to avoid manual management.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-10-04 Tom Tromey <tromey@adacore.com>
+
+ Minor boolean fix in windows-nat.c
+ I noticed a spot in windows-nat.c that used '1' rather than the more
+ appropriate 'true'. This patch fixes it.
+
+2021-10-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Add CXX_DIALECT to CXX
+ Say we use a gcc version that (while supporting c++11) does not support c++11
+ by default, and needs an -std setting to enable it.
+
+ If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
+ we'd have:
+ ...
+ CXX="g++ -std=gnu++11"
+ ...
+
+ That mechanism however has the following problem (quoting from commit
+ 0bcda685399):
+ ...
+ the top level Makefile passes CXX down to subdirs, and that overrides whatever
+ gdb/Makefile may set CXX to. The result would be that a make invocation from
+ the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a
+ make invocation at the top level would not.
+ ...
+
+ Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
+ does:
+ ...
+ CXX=g++
+ CXX_DIALECT=-std=gnu++11
+ ...
+
+ The problem reported in PR28318 is that using the custom instead of the
+ default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
+ support fail.
+
+ We could simply add $CXX_DIALECT to the test for std::thread support, but
+ that would have to be repeated for each added c++ support test.
+
+ Instead, fix this by doing:
+ ...
+ CXX="g++ -std=gnu++11"
+ CXX_DIALECT=-std=gnu++11
+ ...
+
+ This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
+ some situations:
+ ...
+ $ touch src/gdb/dwarf2/read.c
+ $ ( cd build/gdb; make V=1 dwarf2/read.o )
+ g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
+ ...
+
+ However, both settings are needed:
+ - the switch in CXX for the std::thread tests (and other tests)
+ - the switch in CXX_DIALECT so it can be appended in Makefiles, to
+ counteract the fact that the top-level Makefile overrides CXX
+
+ The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
+ AX_CXX_COMPILE_STDCXX from autoconf-archive.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318
+
+2021-10-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ [gdb/symtab] Use unrelocated addresses in call_site
+ Consider test-case gdb.trace/entry-values.exp with target board
+ unix/-fPIE/-pie.
+
+ Using this command we have an abbreviated version, and can see the correct
+ @entry values for foo:
+ ...
+ $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
+ -ex start \
+ -ex "break foo" \
+ -ex "set print entry-values both" \
+ -ex continue
+ Temporary breakpoint 1 at 0x679
+
+ Temporary breakpoint 1, 0x0000555555554679 in main ()
+ Breakpoint 2 at 0x55555555463e
+
+ Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3)
+ ...
+
+ Now, let's try the same again, but run directly to foo rather than stopping at
+ main:
+ ...
+ $ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
+ -ex "break foo" \
+ -ex "set print entry-values both" \
+ -ex run
+ Breakpoint 1 at 0x63e
+
+ Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=<optimized out>, \
+ j=2, j@entry=<optimized out>)
+ ...
+
+ So, what explains the difference? Noteworthy, this is a dwarf assembly
+ test-case, with debug info for foo and bar, but not for main.
+
+ In the first case:
+ - we run to main
+ - this does not trigger expanding debug info, because there's none for main
+ - we set a breakpoint at foo
+ - this triggers expanding debug info. Relocated addresses are used in
+ call_site info (because the exec is started)
+ - we continue to foo, and manage to find the call_site info
+
+ In the second case:
+ - we set a breakpoint at foo
+ - this triggers expanding debug info. Unrelocated addresses are used in
+ call_site info (because the exec is not started)
+ - we run to foo
+ - this triggers objfile_relocate1, but it doesn't update the call_site
+ info addresses
+ - we don't manage to find the call_site info
+
+ We could fix this by adding the missing call_site relocation in
+ objfile_relocate1.
+
+ This solution however is counter-trend in the sense that we're trying to
+ work towards the situation where when starting two instances of an executable,
+ we need only one instance of debug information, implying the use of
+ unrelocated addresses.
+
+ So, fix this instead by using unrelocated addresses in call_site info.
+
+ Tested on x86_64-linux.
+
+ This fixes all remaining unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie
+ regressions, like f.i. PR24892.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24892
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ [gdb/symtab] C++-ify call_site
+ - add constructor
+ - add member function call_site::pc ()
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Add call_site_eq and call_site_hash
+ In commit b4c919f7525 "[gdb/symtab] Fix htab_find_slot call in
+ read_call_site_scope" , I removed the comment:
+ ...
+ It must be the first field as we overload core_addr_hash and core_addr_eq for
+ it.
+ ...
+ for field pc of struct call_site.
+
+ However, this was not tested, and when indeed moving field pc to the second
+ location, we run into a testsuite failure in gdb.trace/entry-values.exp.
+
+ This is caused by core_addr_eq (the eq_f function for the htab) being
+ called with a pointer to the pc field (as passed into htab_find_slot) and a
+ pointer to a hash table element. Now that pc is no longer the first field,
+ the pointer to hash table element no longer points to the pc field.
+
+ This could be fixed by simply reinstating the comment, but we're trying to
+ get rid of this kind of tricks that make refactoring more difficult.
+
+ Instead, fix this by:
+ - reverting commit b4c919f7525, apart from the comment removal, such that
+ we're passing a pointer to element to htab_find_slot
+ - updating the htab_find_slot call in compunit_symtab::find_call_site
+ in a similar manner
+ - adding a call_site_eq and call_site_hash, and using these in the hash table
+ instead of core_addr_eq and core_addr_hash.
+
+ Tested on x86_64-linux, both with and without a trigger patch that moves pc to
+ the second location in struct call_site.
+
+2021-10-04 Tom Tromey <tromey@adacore.com>
+
+ Fix remote-sim.c compilation
+ The change "make string-like set show commands use std::string
+ variable" caused remote-sim.c to fail to build. The issue is that the
+ code does:
+
+ const std::string &sysroot = gdb_sysroot;
+ if (is_target_filename (sysroot))
+ sysroot += strlen (TARGET_SYSROOT_PREFIX);
+
+ ... which isn't valid.
+
+ This patch changes this code to use a 'const char *' again, fixing the
+ build.
+
+2021-10-04 Bruno Larsen <blarsen@redhat.com>
+
+ [gdb/testsuite] update analyze-racy-logs.py to python3
+ Since python 2 is no longer supported on most distributions, update the
+ script to run under python while while still being runnable under
+ python2.
+
+2021-10-04 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdbsupport: remove attempt to define TARGET_WORD_SIZE
+ In the gdbsupport configure.ac file, there is an attempt to define
+ TARGET_WORD_SIZE. This is done by running grep on the file
+ ../bfd/bfd-in3.h.
+
+ The problem with this is, the file bfd-in3.h is generated into the bfd
+ build directory when bfd is configured, and there is no dependency
+ between the gdbsupport module and the bfd module, so, for example, if
+ I do:
+
+ $ ../src/configure
+ $ make all-gdbsupport
+
+ Then bfd will neither be configured, or built. In this case
+ TARGET_WORD_SIZE ends up being defined, but with no value because the
+ grep on bfd-in3.h fails.
+
+ However, it turns out that this doesn't matter; we don't actually use
+ TARGET_WORD_SIZE anywhere.
+
+ My proposal in this commit is to just remove the definition of
+ TARGET_WORD_SIZE, the alternative would be to add a dependency between
+ configure-gdbsupport and configure-bfd into Makefile.def, but adding a
+ dependency for something we don't need seems pretty pointless.
+
+2021-10-04 Mike Frysinger <vapier@gentoo.org>
+
+ sim: add --info-target for listing supported BFD targets
+ It can be difficult to guess the exact bfd name, so add an option to
+ list all the targets that the current build supports. This aligns with
+ other simulator options like --info-architecture.
+
+2021-10-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-03 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Setting setter return a bool to tell if the value changed
+ GDB can notify observers when a parameter is changed.
+
+ To do that, do_set_command (in gdb/cli/cli-setshow.c) compares the new
+ value against the old one before updating it, and based on that notifies
+ observers. This looks like something like:
+
+ int valuechanged = 0;
+ switch (cmd->var.type ())
+ {
+ case var_integer:
+ {
+ LONGEST new_val = parse_and_eval_long (arg)
+ if (new_val != cmd->var.get<int> ())
+ {
+ cmd->var.get<int> (new_val);
+ value_changes = 1;
+ }
+ }
+ case var_uinteger:
+ case var_zuinteger:
+ {
+ unsigned int val
+ = parse_cli_var_uinteger (c->var->type (), &arg, true);
+ if (c->var->get<unsigned int> () != val)
+ {
+ c->var->set<unsigned int> (val);
+ option_changed = true;
+ }
+ }
+ case...
+ /* And so on for all possible var_types. */
+ }
+
+ This comparison is done for each possible var_type, which leads to
+ unnecessary logic duplication.
+
+ In this patch I propose to move all those checks in one place within the
+ setting setter method. This limits the code duplication and simplifies
+ the do_set_command implementation.
+
+ This patch also changes slightly the way a value change is detected.
+ Instead of comparing the user provided value against the current value
+ of the setting, we compare the value of the setting before and after the
+ set operation. This is meant to handle edge cases where trying to set
+ an unrecognized value would be equivalent to a noop (the actual value
+ remains unchanged). Doing this requires that the original value needs
+ to be copied before the update, which can be non trivial for
+ std::string.
+
+ There should be no user visible change introduced by this commit.
+
+ Tested on x86_64 GNU/Linux.
+
+ [1] https://review.lttng.org/c/binutils-gdb/+/5831/41
+
+ Change-Id: If064b9cede3eb56275aacd2b286f74eceb1aed11
+
+2021-10-03 Lancelot SIX <lsix@lancelotsix.com>
+ Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: Have setter and getter callbacks for settings
+ The main motivation behind this improvement is to help the
+ implementation of a patch Simon Marchi is preparing to fix a bug when
+ MI or Python try to access parameters that are inferior dependent (see
+ PR/28085).
+
+ This commit extends the previous ones, which introduces the setting
+ object to represent a static variable whose value can be set or shown
+ with the appropriate commands. This patch proposes that a setting can
+ either contain a pointer to a static variable holding a setting, or
+ pointers to a pair of setter and getter callback functions.
+
+ The callbacks functions can be used to retrieve or change the value with
+ custom logic. This is useful when the source of truth for a given
+ setting is not contained in the variable pointed to by the setting
+ instance.
+
+ Given that the callback function call is hidden within the setting
+ abstraction introduced earlier, none of the sites accessing the setting
+ needs to be updated. The registered getter or setter is used whatever
+ the way to access it is (through MI, Python, Guile, the "with" command
+ and the $_gdb_setting / $_gdb_setting_str convenience functions).
+
+ All the add_setshow_*_cmd are given a new overload that will accept the
+ pair of function pointers (set / get functions) instead of the pointer
+ to a global variable.
+
+ Tested on GNU/Linux x86_64 with no regression observed.
+
+ Change-Id: Ieb81fef57550632ff66e6aa85f637372a226be8c
+
+2021-10-03 Simon Marchi <simon.marchi@efficios.com>
+ Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: make string-like set show commands use std::string variable
+ String-like settings (var_string, var_filename, var_optional_filename,
+ var_string_noescape) currently take a pointer to a `char *` storage
+ variable (typically global) that holds the setting's value. I'd like to
+ "mordernize" this by changing them to use an std::string for storage.
+
+ An obvious reason is that string operations on std::string are often
+ easier to write than with C strings. And they avoid having to do any
+ manual memory management.
+
+ Another interesting reason is that, with `char *`, nullptr and an empty
+ string often both have the same meaning of "no value". String settings
+ are initially nullptr (unless initialized otherwise). But when doing
+ "set foo" (where `foo` is a string setting), the setting now points to
+ an empty string. For example, solib_search_path is nullptr at startup,
+ but points to an empty string after doing "set solib-search-path". This
+ leads to some code that needs to check for both to check for "no value".
+ Or some code that converts back and forth between NULL and "" when
+ getting or setting the value. I find this very error-prone, because it
+ is very easy to forget one or the other. With std::string, we at least
+ know that the variable is not "NULL". There is only one way of
+ representing an empty string setting, that is with an empty string.
+
+ I was wondering whether the distinction between NULL and "" would be
+ important for some setting, but it doesn't seem so. If that ever
+ happens, it would be more C++-y and self-descriptive to use
+ optional<string> anyway.
+
+ Actually, there's one spot where this distinction mattered, it's in
+ init_history, for the test gdb.base/gdbinit-history.exp. init_history
+ sets the history filename to the default ".gdb_history" if it sees that
+ the setting was never set - if history_filename is nullptr. If
+ history_filename is an empty string, it means the setting was explicitly
+ cleared, so it leaves it as-is. With the change to std::string, this
+ distinction doesn't exist anymore. This can be fixed by moving the code
+ that chooses a good default value for history_filename to
+ _initialize_top. This is ran before -ex commands are processed, so an
+ -ex command can then clear that value if needed (what
+ gdb.base/gdbinit-history.exp tests).
+
+ Another small improvement, in my opinion is that we can now easily
+ give string parameters initial values, by simply initializing the global
+ variables, instead of xstrdup-ing it in the _initialize function.
+
+ In Python and Guile, when registering a string-like parameter, we
+ allocate (with new) an std::string that is owned by the param_smob (in
+ Guile) and the parmpy_object (in Python) objects.
+
+ This patch started by changing all relevant add_setshow_* commands to
+ take an `std::string *` instead of a `char **` and fixing everything
+ that failed to build. That includes of course all string setting
+ variable and their uses.
+
+ string_option_def now uses an std::string also, because there's a
+ connection between options and settings (see
+ add_setshow_cmds_for_options).
+
+ The add_path function in source.c is really complex and twisted, I'd
+ rather not try to change it to work on an std::string right now.
+ Instead, I added an overload that copies the std:string to a `char *`
+ and back. This means more copying, but this is not used in a hot path
+ at all, so I think it is acceptable.
+
+ Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93
+
+2021-10-03 Lancelot SIX <lsix@lancelotsix.com>
+ Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: Introduce setting construct within cmd_list_element
+ cmd_list_element can contain a pointer to data that can be set and / or
+ shown. This is achieved with the void* VAR member which points to the
+ data that can be accessed, while the VAR_TYPE member (of type enum
+ var_types) indicates how to interpret the data pointed to.
+
+ With this pattern, the user of the cmd_list_element needs to know what
+ is the storage type associated with a given VAR_TYPES in order to do
+ the proper casting. No automatic safeguard is available to prevent
+ miss-use of the pointer. Client code typically looks something like:
+
+ switch (c->var_type)
+ {
+ case var_zuinteger:
+ unsigned int v = *(unsigned int*) c->var;
+ ...
+ break;
+ case var_boolean:
+ bool v = *(bool *) c->var;
+ ...
+ break;
+ ...
+ }
+
+ This patch proposes to add an abstraction around the var_types and void*
+ pointer pair. The abstraction is meant to prevent the user from having
+ to handle the cast and verify that the data is read or written as a type
+ that is coherent with the setting's var_type. This is achieved by
+ introducing the struct setting which exposes a set of templated get /
+ set member functions. The template parameter is the type of the
+ variable that holds the referred variable.
+
+ Using those accessors allows runtime checks to be inserted in order to
+ ensure that the data pointed to has the expected type. For example,
+ instantiating the member functions with bool will yield something
+ similar to:
+
+ const bool &get<bool> () const
+ {
+ gdb_assert (m_var_type == var_boolean);
+ gdb_assert (m_var != nullptr);
+ return *static_cast<bool *> (m_var);
+ }
+ void set<bool> (const bool &var)
+ {
+ gdb_assert (m_var_type == var_boolean);
+ gdb_assert (m_var != nullptr);
+ *static_cast<bool *> (m_var) = var;
+ }
+
+ Using the new abstraction, our initial example becomes:
+
+ switch (c->var_type)
+ {
+ case var_zuinteger:
+ unsigned int v = c->var->get<unsigned int> ();
+ ...
+ break;
+ case var_boolean:
+ bool v = c->var->get<bool> ();
+ ...
+ break;
+ ...
+ }
+
+ While the call site is still similar, the introduction of runtime checks
+ help ensure correct usage of the data.
+
+ In order to avoid turning the bulk of add_setshow_cmd_full into a
+ templated function, and following a suggestion from Pedro Alves, a
+ setting can be constructed from a pre validated type erased reference to
+ a variable. This is what setting::erased_args is used for.
+
+ Introducing an opaque abstraction to describe a setting will also make
+ it possible to use callbacks to retrieve or set the value of the setting
+ on the fly instead of pointing to a static chunk of memory. This will
+ be done added in a later commit.
+
+ Given that a cmd_list_element may or may not reference a setting, the
+ VAR and VAR_TYPES members of the struct are replaced with a
+ gdb::optional<setting> named VAR.
+
+ Few internal function signatures have been modified to take into account
+ this new abstraction:
+
+ -The functions value_from_setting, str_value_from_setting and
+ get_setshow_command_value_string used to have a 'cmd_list_element *'
+ parameter but only used it for the VAR and VAR_TYPE member. They now
+ take a 'const setting &' parameter instead.
+ - Similarly, the 'void *' and a 'enum var_types' parameters of
+ pascm_param_value and gdbpy_parameter_value have been replaced with a
+ 'const setting &' parameter.
+
+ No user visible change is expected after this patch.
+
+ Tested on GNU/Linux x86_64, with no regression noticed.
+
+ Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
+
+2021-10-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: filter out SIGSTKSZ [PR sim/28302]
+ We map target signals to host signals so we can propagate signals
+ between the host & simulated worlds. That means we need to know
+ the symbolic names & values of all signals that might be sent.
+
+ The tools that generate that list use signal.h and include all
+ symbols that start with "SIG" so as to automatically include any
+ new symbols that the C library might add. Unfortunately, this
+ also picks up "SIGSTKSZ" which is not actually a signal itself,
+ but a signal related setting -- it's the size of the stack when
+ a signal is handled.
+
+ By itself this doesn't super matter as we will never see a signal
+ with that same value (since the range of valid signals tend to be
+ way less than 1024, and the size of the default signal stack will
+ never be that small). But with recent glibc changes that make this
+ into a dynamic value instead of a compile-time constant, some users
+ see build failures when building the sim.
+
+ As suggested by Adam Sampson, update our scripts to ignore this
+ symbol to simplify everything and avoid the build failure.
+
+ Bug: https://sourceware.org/PR28302
+
+2021-10-03 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: fallback when ln is not available [PR sim/18864]
+ Not all systems have easy access to hard links or symlinks, so add
+ fallback logic to the run->psim build code to handle those.
+
+ Bug: https://sourceware.org/PR18864
+
+2021-10-03 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Fix comment in riscv_scan_prologue
+ I found an inaccurate comment in riscv_scan_prologue. This commit fixes
+ it.
+
+2021-10-03 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Support the c.mv insn in the riscv prologue scanner.
+ While working on other problems, I encountered situations where GDB
+ fails to properly unwind the stack because some functions use the C.MV
+ instruction in the prologue. The prologue scanner stops when it hits
+ this instruction assuming its job is done at this point. Unfortunately
+ the prologue is not necessarily finished yet, preventing GDB to properly
+ unwind.
+
+ This commit adds support for handling such instruction in
+ riscv_scan_prologue.
+
+ Note that C.MV is part of the compressed instruction set. The MV
+ counterpart from the base ISA is a pseudo instruction that expands to
+ 'ADDI RD,RS1,0' which is already supported.
+
+ Tested on riscv64-linux-gnu.
+
+ All feedback are welcome.
+
+2021-10-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ [gdb/symtab] Remove COMPUNIT_CALL_SITE_HTAB
+ Remove macro COMPUNIT_CALL_SITE_HTAB, and provide access to the htab using
+ member functions:
+ - compunit_symtab::find_call_site
+ - compunit_symtab::set_call_site_htab
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-02 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/python: fix a few flake8 warnings
+ Fix these rather obvious warnings reported by flake8:
+
+ ./lib/gdb/FrameIterator.py:16:1: F401 'gdb' imported but unused
+ ./lib/gdb/FrameIterator.py:17:1: F401 'itertools' imported but unused
+ ./lib/gdb/command/prompt.py:55:26: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+ ./lib/gdb/command/explore.py:526:9: F841 local variable 'has_explorable_fields' is assigned to but never used
+ ./lib/gdb/command/explore.py:697:56: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+ ./lib/gdb/command/explore.py:736:62: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+ ./lib/gdb/command/explore.py:767:61: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+ ./lib/gdb/command/frame_filters.py:21:1: F401 'copy' imported but unused
+ ./lib/gdb/command/frame_filters.py:22:1: F401 'gdb.FrameIterator.FrameIterator' imported but unused
+ ./lib/gdb/command/frame_filters.py:23:1: F401 'gdb.FrameDecorator.FrameDecorator' imported but unused
+ ./lib/gdb/command/frame_filters.py:25:1: F401 'itertools' imported but unused
+ ./lib/gdb/command/frame_filters.py:179:17: E712 comparison to True should be 'if cond is True:' or 'if cond:'
+
+ Change-Id: I4f49c0cb430359ee872222600c61d9c5283b09ab
+
+2021-10-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-10-01 Luis Machado <luis.machado@linaro.org>
+
+ Fix build failure for 32-bit targets
+ When building master GDB, I ran into the following:
+
+ binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)':
+ binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=]
+ snprintf (buf, sizeof (buf), "0x%lx ", pc);
+
+ Fix this by using %PRIxPTR as opposed to %lx.
+
+2021-10-01 Nick Clifton <nickc@redhat.com>
+
+ Fix mistake in RX assembler documentation (special section names)
+
+2021-10-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ [gdb/symtab] Fix htab_find_slot call in read_call_site_scope
+ In read_call_site_scope we have:
+ ...
+ call_site_local.pc = pc;
+ slot = htab_find_slot (cu->call_site_htab, &call_site_local, INSERT);
+ ...
+
+ The call passes a call_site pointer as element. OTOH, the hashtab is created
+ using hash_f == core_addr_hash and eq_f == core_addr_eq, so the element
+ will be accessed through a CORE_ADDR pointer.
+
+ This is not wrong (at least in C), given that pc is the first field in
+ call_site.
+
+ Nevertheless, as in call_site_for_pc, make the htab_find_slot call match the
+ used hash_f and eq_f by using &pc instead:
+ ...
+ slot = htab_find_slot (cu->call_site_htab, &pc, INSERT);
+ ...
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-01 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH bfd: Fix linker warning for recently introduced arm attributes
+ 2021-09-27 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf-bfd.h (NUM_KNOWN_OBJ_ATTRIBUTES): Update value to cover
+ 'Tag_BTI_use' and 'Tag_PACRET_use'.
+
+2021-10-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/dwarf: use options for rnglists/loclists procs
+ Change how rnglists and loclists procs to align them with how procs for
+ aranges (and other things in the DWARF assembler) work. Instead of
+ using "args" (variable number of parameters in TCL) and command-line
+ style option arguments, use one leading "option" parameters, used as a
+ kind of key/value dictionary of options parsed using `parse_options`.
+
+ Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a
+
+2021-10-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite/dwarf: don't define nested procs for rnglists/loclists
+ When I wrote support for rnglists and loclists in the testsuite's DWARF
+ assembler, I made it with nested procs, for example proc "table" inside
+ proc "rnglists". The intention was that this proc "table" could only be
+ used by the user while inside proc "rnglists"'s body. I had chosen very
+ simple names, thinking there was no chance of name clashes. I recently
+ learned that this is not how TCL works. This ends up defining a proc
+ "table" in the current namespace ("Dwarf" in this case).
+
+ Things still work if you generate rnglists and loclists in the same
+ file, as each redefines its own procedures when executing. But if a
+ user of the assembler happened to define a convenience "table" or
+ "start_end" procedure, for example, it would get overriden.
+
+ I'd like to change how this works to reduce the chances of a name clash.
+
+ - Move the procs out of each other, so they are not defined in a nested
+ fashion.
+ - Prefix them with "_rnglists_" or "_loclists_".
+ - While calling $body in the various procs, temporarily make the procs
+ available under their "short" name. For example, while in rngllists'
+ body, make _rnglists_table available as just "table". This allows
+ existing code to keep working and keeps it not too verbose.
+ - Modify with_override to allow the overriden proc to not exist. In
+ that case, the temporary proc is deleted on exit.
+
+ Note the non-conforming indentation when calling with_override in
+ _loclists_list. This is on purpose: as we implement more loclists (and
+ rnglists) entry types, the indentation would otherwise get larger and
+ larger without much value for readability. So I think it's reasonable
+ here to put them on the same level.
+
+ Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328
+
+2021-10-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove TYPE_FIELD_NAME and FIELD_NAME macros
+ Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
+ call sites to use field::name directly.
+
+ Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
+
+2021-10-01 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add field::name / field::set_name
+ Add the `name` and `set_name` methods on `struct field`, in order to
+ remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the
+ macros are changed to use `field::name`, so all the call sites that are
+ used to set the field's name are changed to use `field::set_name`.
+ The next patch will remove the macros completely.
+
+ Note that because of the name clash between the existing field named
+ `name` and the new method, I renamed the field `m_name`. It is not
+ private per-se, because we can't make `struct field` a non-POD yet, but
+ it should be considered private anyway (not accessed outside `struct
+ field`).
+
+ Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
+
+2021-10-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-30 Sergio Durigan Junior <sergiodj@sergiodj.net>
+
+ [PR gdb/28369] Use get_shell on gdb/ser-pipe.c
+ PR gdb/28369 reports that gdb/ser-pipe.c has an 'execl' function call
+ with a hard-coded "/bin/sh" as its argument. We've had 'get_shell'
+ for a while now, which is conscious about the SHELL environment and a
+ better alternative to always calling "/bin/sh".
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28369
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add untested for missing xml support in gdb.base/valgrind*.exp
+ Add untested in case missing xml support is detected in test-cases
+ gdb.base/valgrind*.exp.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ arm: enable Cortex-R52+ CPU
+ Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
+ flag for -mcpu option.
+
+ bfd/
+
+ * cpu-arm.c: New Cortex-R52+ CPU.
+
+ gas/
+
+ * NEWS: Update docs.
+ * config/tc-arm.c: New Cortex-R52+ CPU.
+ * doc/c-arm.texi: Update docs.
+ * testsuite/gas/arm/cpu-cortex-r52plus.d: New test.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: Enable Cortex-X2 CPU
+ This patch is adding support for Cortex-X2 CPU.
+
+ gas:
+
+ * NEWS: Update docs.
+ * config/tc-aarch64.c: Add Cortex-X2.
+ * doc/c-aarch64.texi: Update docs.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: Enable Cortex-A710 CPU
+ This patch is adding support for Cortex-A710 CPU.
+
+ gas/
+
+ * NEWS: Update docs.
+ * config/tc-aarch64.c: Add Cortex-A710.
+ * doc/c-aarch64.texi: Update docs.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: Enable Cortex-A510 CPU
+ This patch is adding support for Cortex-A510 CPU.
+
+ gas/
+
+ * NEWS: Update docs.
+ * config/tc-aarch64.c: Add Cortex-A510.
+ * doc/c-aarch64.texi: Update docs.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: Update AArch64 features command line options docs 2/2
+ Patch is only sorting by 'Extension` column 'Architecture Extension'
+ table.
+
+ gas/
+
+ * doc/c-aarch64.texi: Update docs.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: Update AArch64 features command line options docs 1/2
+ Patch is improving entries in "Architecture extensions" table in GAS
+ documentation.
+
+ gas/
+
+ * doc/c-aarch64.texi: Update docs.
+
+2021-09-30 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
+
+ aarch64: add armv9-a architecture to -march
+ Patch is adding new 'armv9-a` command line flag to -march for AArch64.
+
+ gas/
+
+ * config/tc-aarch64.c: Add 'armv9-a' command line flag.
+ * docs/c-aarch64.text: Update docs.
+ * NEWS: Update docs.
+
+ include/
+
+ * opcode/aarch64.h (AARCH64_FEATURE_V9): New define.
+ (AARCH64_ARCH_V9): New define.
+
+2021-09-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: make runto_main not pass no-message to runto
+ As follow-up to this discussion:
+
+ https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
+
+ ... make runto_main not pass no-message to runto. This means that if we
+ fail to run to main, for some reason, we'll emit a FAIL. This is the
+ behavior we want the majority of (if not all) the time.
+
+ Without this, we rely on tests logging a failure if runto_main fails,
+ otherwise. They do so in a very inconsisteny mannet, sometimes using
+ "fail", "unsupported" or "untested". The messages also vary widly.
+ This patch removes all these messages as well.
+
+ Also, remove a few "fail" where we call runto (and not runto_main). by
+ default (without an explicit no-message argument), runto prints a
+ failure already. In two places, gdb.multi/multi-re-run.exp and
+ gdb.python/py-pp-registration.exp, remove "message" passed to runto.
+ This removes a few PASSes that we don't care about (but FAILs will still
+ be printed if we fail to run to where we want to). This aligns their
+ behavior with the rest of the testsuite.
+
+ Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
+
+2021-09-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: make gdb_mkostemp_cloexec return a scoped_fd
+ This encourages the callers to use automatic file descriptor management.
+
+ Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344
+
+2021-09-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: make gdb_open_cloexec return scoped_fd
+ Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
+ management of the file descriptor closing. Except in the most trivial
+ cases, I changed the callers to just release the fd, which retains their
+ existing behavior. That will allow the transition to using scoped_fd
+ more to go gradually, one caller at a time.
+
+ Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
+
+2021-09-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: move gdb_file_up to its own file
+ The following patches wants to change gdb_fopen_cloexec and
+ gdb_mkostemp_cloexec to return a scoped_fd. Doing this causes a cyclic
+ include between scoped_fd.h and filestuff.h, that both want to include
+ each other. scoped_fd.h includes filestuff.h because of the
+ scoped_fd::to_file method's return value. filestuff.h would then
+ include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's
+ return values.
+
+ To fix that, move gdb_file_up to its own file, gdb_file.h.
+
+ Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d
+
+2021-09-30 Dimitar Dimitrov <dimitar@dinux.eu>
+
+ ld: pru: Fix resource_table output section alignment
+ My commit 261980de18b added alignment for the resource table symbol.
+ But it is wrong. The Linux remoteproc driver loads and interprets the
+ contents of the .resource_table ELF section, not of a table symbol.
+
+ Without this patch, if the linker happens to output padding for symbol
+ alignment, then the resource table contents as viewed by the kernel
+ loader would "shift" and look corrupted.
+
+ ld/ChangeLog:
+
+ * scripttempl/pru.sc (.resource_table): Align the output
+ section, not the first symbol.
+
+2021-09-30 Tom Tromey <tromey@adacore.com>
+
+ Fix Windows crash from stop_pc change
+ The "make thread_suspend_state::stop_pc optional" patch caused a
+ regression on Windows when using shared libraries. I tracked this
+ down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED
+ case of handle_inferior_event. This patch fixes the bug by ensuring
+ that the stop PC is set at this point.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use untested in gdb.debuginfod/fetch_src_and_symbols.exp
+ With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
+ board unix/-bad, I get:
+ ...
+ gcc: error: unrecognized command line option '-bad'^M
+ compiler exited with status 1
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile
+ ...
+
+ Replace the FAIL with the usual:
+ ...
+ UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove redundant FAIL in gdb.base/info-os.exp
+ When running test-case gdb.base/info-os.exp with target board unix/-bad, I run
+ into:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.base/info-os.exp: failed to prepare
+ FAIL: gdb.base/info-os.exp: cannot compile test program
+ ...
+
+ Remove the redundant FAIL.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.base/info-os.exp
+ When running test-case gdb.base/info-os.exp, I run into:
+ ...
+ PASS: gdb.base/info-os.exp: get threads
+ PASS: gdb.base/info-os.exp: get threads
+ DUPLICATE: gdb.base/info-os.exp: get threads
+ ...
+
+ Fix this not doing pass followed by exp_continue in gdb_test_multiple.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check compilation result in gdb.dwarf2/dw2-opt-structptr.exp
+ When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board
+ unix/-bad, I get:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp
+ UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile
+ ERROR: (dw2-opt-structptr) No such file or directory
+ UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on
+ ...
+
+ Merge the two UNTESTEDs.
+
+ Fix the UNRESOLVED by checking result of compilation.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check compilation result in gdb.base/structs.exp
+ When running test-case gdb.base/structs.exp with target board unix/-bad, I
+ get:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.base/structs.exp: failed to prepare
+ ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp.
+ ERROR: can't read "use_gdb_stub": no such variable
+ ...
+
+ Fix this by checking the compilation result.
+
+ Fix the resulting DUPLICATEs using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Prepare nodebug exec in gdb.base/cvexpr.exp
+ When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp.
+ ERROR: can't read "use_gdb_stub": no such variable
+ ...
+
+ This is triggered in a part of the test that claims to require no debug
+ information, but uses the exec containing either dwarf or ctf.
+
+ Fix this by preparing another executable compiled with nodebug, and using
+ that one instead.
+
+ Also use with_test_prefix to mark the nodebug part, such that we have:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.base/cvexpr.exp
+ Fix:
+ ...
+ DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict
+ ...
+ using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check compilation result in gdb.base/call-sc.exp
+ When running test-case gdb.base/call-sc.exp with target board unix/-bad, I
+ get:
+ ...
+ gdb compile failed, gcc: error: unrecognized command line option '-bad'
+ UNTESTED: gdb.base/call-sc.exp: failed to prepare
+ ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp.
+ ERROR: can't read "use_gdb_stub": no such variable
+ ...
+
+ Fix this by checking the compilation result.
+
+ Fix the resulting DUPLICATE:
+ ...
+ DUPLICATE: gdb.base/call-sc.exp: failed to prepare
+ ...
+ using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix untested messages in gdb.mi/*.exp
+ The effect of:
+ ...
+ untested "y.exp"
+ ...
+ in a gdb.x/y.exp is:
+ ...
+ UNTESTED: gdb.x/y.exp: y.exp
+ ...
+ which is a bit pointless.
+
+ Replace these untested messages in gdb.mi/*.exp with the usual "failed to
+ compile".
+
+ Likewise for an:
+ ...
+ untested $testname
+ ...
+ where the variable is undefined.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Nick Clifton <nickc@redhat.com>
+
+ make objcopy fail if it is asked to redefine symbols in an object file containing LTO information.
+ * objcopy.c (filter_symbols): Fail if attempting to dredefine
+ symbols in an LTO object file.
+
+2021-09-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp
+ On ubuntu 18.04.5, I run into:
+ ...
+ (gdb) mt print objfiles dwindex^M
+ ^M
+ Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex: \
+ Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M
+ ^M
+ Psymtabs:^M
+ vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M
+ ...
+ library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M
+ ERROR: internal buffer is full.
+ UNRESOLVED: gdb.rust/dwindex.exp: check if index present
+ ...
+
+ Fix this by using -lbl in proc ensure_gdb_index.
+
+ Tested on x86_64-linux.
+
+2021-09-30 Libor Bukata <libor.bukata@oracle.com>
+
+ Add Solaris specific ELF note processing
+ Add elfcore_grok_solaris_note function that enables to
+ obtain process status, register values, and program info
+ from Solaris's core files.
+
+ bfd/
+ * elf.c (elfcore_grok_solaris_note): Solaris specific ELF
+ note parser. Better GDB's coredump analysis on Solaris...
+ (elfcore_grok_solaris_note_impl): New function.
+ (elfcore_grok_solaris_prstatus): New function.
+ (elfcore_grok_solaris_info): New function.
+ (elfcore_grok_solaris_lwpstatus): New function.
+ (elf_parse_notes): Added "CORE" groker element.
+ include/
+ * elf/common.h: Add note segment constants for core files on
+ Solaris systems.
+
+2021-09-30 Frederic Cambus <fred@statdns.com>
+
+ Add support to readelf for reading OpenBSD ELF core notes.
+ * readelf.c (get_openbsd_elfcore_note_type): New function.
+ (process_note): Add support for OpenBSD core notes.
+
+2021-09-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug
+ When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get:
+ ...
+ (gdb) info addr dl_main^M
+ Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M
+ (gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main
+ ...
+ while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."
+
+ Fix this by also accepting this variant.
+
+ Tested on x86_64-linux.
+
+2021-09-29 H.J. Lu <hjl.tools@gmail.com>
+
+ Add a testcase for PR binutils/27202
+ PR binutils/27202
+ * testsuite/gas/elf/dwarf-5-loc0.d: New file.
+ * testsuite/gas/elf/dwarf-5-loc0.s: Likewise.
+ * testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.
+
+2021-09-29 Pedro Alves <pedro@palves.net>
+
+ Fix gdb.multi/multi-term-settings.exp race
+ The gdb.multi/multi-term-settings.exp testcase sometimes fails like so:
+
+ Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ...
+ FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)
+
+ It's easier to reproduce if you stress the machine at the same time, like e.g.:
+
+ $ stress -c 24
+
+ Looking at gdb.log, we see:
+
+ (gdb) attach 60422
+ Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422
+ [New Thread 60422.60422]
+ Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
+ Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
+ Reading symbols from /lib64/ld-linux-x86-64.so.2...
+ (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+ 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
+ 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
+ (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach
+ set schedule-multiple on
+ (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on
+ info inferiors
+ Num Description Connection Executable
+ 1 process 60404 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
+ * 2 process 60422 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
+ (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors
+ pid=60422, count=46
+ pid=60422, count=47
+ pid=60422, count=48
+ pid=60422, count=49
+ pid=60422, count=50
+ pid=60422, count=51
+ pid=60422, count=52
+ pid=60422, count=53
+ pid=60422, count=54
+ pid=60422, count=55
+ pid=60422, count=56
+ pid=60422, count=57
+ pid=60422, count=58
+ pid=60422, count=59
+ pid=60422, count=60
+ pid=60422, count=61
+ pid=60422, count=62
+ pid=60422, count=63
+ pid=60422, count=64
+ pid=60422, count=65
+ pid=60422, count=66
+ pid=60422, count=67
+ pid=60422, count=68
+ pid=60422, count=69
+ pid=60404, count=54
+ pid=60404, count=55
+ pid=60404, count=56
+ pid=60404, count=57
+ pid=60404, count=58
+ PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue
+ Quit
+ (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)
+
+ If you look at the testcase's sources, you'll see that the intention
+ is to resumes the program with "continue", wait to see a few of those
+ "pid=..., count=..." lines, and then interrupt the program with
+ Ctrl-C. But somehow, that resulted in GDB printing "Quit", instead of
+ the Ctrl-C stopping the program with SIGINT.
+
+ Here's what is happening:
+
+ #1 - those "pid=..., count=..." lines we see above weren't actually
+ output by the inferior after it has been continued (see #1).
+ Note that "inf1_how" and "inf2_how" are "attach". What happened
+ is that those "pid=..., count=..." lines were output by the
+ inferiors _before_ they were attached to. We see them at that
+ point instead of earlier, because that's where the testcase
+ reads from the inferiors' spawn_ids.
+
+ #2 - The testcase mistakenly thinks those "pid=..., count=..." lines
+ happened after the continue was processed by GDB, meaning it has
+ waited enough, and so sends the Ctrl-C. GDB hasn't yet passed
+ the terminal to the inferior, so the Ctrl-C results in that
+ Quit.
+
+ The fix here is twofold:
+
+ #1 - flush inferior output right after attaching
+
+ #2 - consume the "Continuing" printed by "continue", indicating the
+ inferior has the terminal. This is the same as done throughout
+ the testsuite to handle this exact problem of sending Ctrl-C too
+ soon.
+
+ gdb/testsuite/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net <mailto:pedro@palves.net>>
+
+ * gdb.multi/multi-term-settings.exp (create_inferior): Flush
+ inferior output.
+ (coretest): Use $gdb_test_name. After issuing "continue", wait
+ for "Continuing".
+
+ Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9
+
+2021-09-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Disable vgdb tests if xml not supported
+ I build gdb without xml support using --without-expat, and ran into:
+ ...
+ (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
+ Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
+ relaying data between gdb and process 22032^M
+ warning: Can not parse XML target description; XML support was disabled at \
+ compile time^M
+ ...
+ (gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1
+ p gdb_test_infcall ()^M
+ Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M
+ (gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
+ ...
+
+ After googling the error message with context valgrind gdbserver, I found
+ indications that the Remote 'g' packet reply error is due to missing xml
+ support.
+
+ And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I
+ found:
+ ...
+ GDB version needed for ARM and PPC32/64.
+
+ You must use a GDB version which is able to read XML target description sent
+ by a gdbserver. This is the standard setup if GDB was configured and built
+ with the "expat" library. If your GDB was not configured with XML support, it
+ will report an error message when using the "target" command. Debugging will
+ not work because GDB will then not be able to fetch the registers from the
+ Valgrind gdbserver.
+ ...
+
+ So I guess I'm running into the same problem for x86_64.
+
+ Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not
+ available. Although only the gdb.base/valgrind-infcall*.exp produce fails,
+ the Remote 'g' packet reply error occurs in all tests, so it seems prudent to
+ disable them all.
+
+ Tested on x86_64-linux.
+
+2021-09-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2
+ With a gdb build using python 2.7, I run into:
+ ...
+ (gdb) python \
+ gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
+ File "<string>", line 1^M
+ gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
+ ^^M
+ SyntaxError: invalid syntax^M
+ Error while executing Python code.^M
+ (gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \
+ trap breakpoint_modified event
+ ...
+
+ This is caused by the following:
+ - a lambda function body needs to be an expression
+ - in python 2, print is a statement, while in python 3 it's a function
+ - a function call is an expression, and a statement is not.
+
+ Fix this by defining a function print_bp_enabled:
+ ...
+ def print_bp_enabled (bp):
+ print (bp.enabled)
+ end
+ ...
+ and using that instead.
+
+ Tested on x86_64-linux.
+
+2021-09-29 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp
+ With a gdb configured to be somewhat minimal, while still supporting python:
+ ...
+ $ gdb --configuration
+ This GDB was configured as follows:
+ configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
+ --with-auto-load-dir=$debugdir:$datadir/auto-load
+ --with-auto-load-safe-path=$debugdir:$datadir/auto-load
+ --without-expat
+ --with-gdb-datadir=$install/share/gdb (relocatable)
+ --with-jit-reader-dir=$install/lib64/gdb (relocatable)
+ --without-libunwind-ia64
+ --without-lzma
+ --without-babeltrace
+ --without-intel-pt
+ --with-mpfr
+ --without-xxhash
+ --with-python=/usr
+ --with-python-libdir=/usr/lib
+ --with-debuginfod
+ --without-guile
+ --disable-source-highlight
+ --with-separate-debug-dir=/usr/lib/debug
+ --with-system-gdbinit=$devel/system-gdbinit
+ ...
+ and using gcc 4.8 to build gdb (causing std::thread not to be used due to
+ PR28318) I ran into:
+ ...
+ (gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb
+ print 1^M
+ ^M
+ Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M
+ 1174 scoped_value_mark free_values;^M
+ (xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout)
+ ...
+
+ The problem is that the regexp expects "hit Breakpoint $decimal". The "hit"
+ part is missing.
+
+ The "hit" is printed by maybe_print_thread_hit_breakpoint, when
+ show_thread_that_caused_stop returns true:
+ ...
+ int
+ show_thread_that_caused_stop (void)
+ {
+ return highest_thread_num > 1;
+ }
+ ...
+ Apparently, that's not the case.
+
+ Fix this by removing "hit" from the regexp, making the regexp more similar to
+ what is used in say, continue_to_breakpoint.
+
+ Tested on x86_64-linux.
+
+2021-09-29 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: fix build when libbacktrace and execinfo backtrace are not available
+ In this commit:
+
+ commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
+ Date: Wed Aug 11 13:24:33 2021 +0100
+
+ gdb: use libbacktrace to create a better backtrace for fatal signals
+
+ The build of GDB was broken iff, the execinfo backtrace API is not
+ available, and, libbacktrace is either disabled, or not usable. In
+ this case you'll see build errors like this:
+
+ CXX bt-utils.o
+ /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()':
+ /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope
+ gdb_internal_backtrace_1 ();
+ ^~~~~~~~~~~~~~~~~~~~~~~~
+
+ This commit fixes the issue by guarding the call to
+ gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE',
+ which is only defined when one of the backtrace libraries are
+ available.
+
+2021-09-29 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/doc: use 'standard error stream' instead of 'stderr' in some places
+ With this commit:
+
+ commit 91f2597bd24d171c1337a4629f8237aa47c59082
+ Date: Thu Aug 12 18:24:59 2021 +0100
+
+ gdb: print backtrace for internal error/warning
+
+ I included some references to 'stderr', which, it was pointed out,
+ would be better written as 'standard error stream'. See:
+
+ https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html
+
+ This commit replaces the two instances of 'stderr' that I introduced.
+
+2021-09-29 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: fix manor -> manner typo in some comments
+ In a recent commit I used 'manor' in some comments rather than
+ 'manner'. This commit fixes those two mistakes.
+
+ I also looked through the gdb/ tree and found one additional instance
+ of this mistake that this commit also fixes.
+
+2021-09-29 Alan Modra <amodra@gmail.com>
+
+ PR27202, readelf -wL doesn't work on ".loc 0"
+ For DWARF revision 4 and earlier, display_debug_lines_decoded
+ populates the file_table array with entries read from .debug_line
+ after the directory table. file_table[0] contains the first entry.
+ DWARF rev 4 line number programs index this entry as file number one.
+ DWARF revision 5 changes .debug_line format quite extensively, and in
+ particular gives file number zero a meaning.
+
+ PR 27202
+ * dwarf.c (display_debug_lines_decoded): Correct indexing used
+ for DWARF5 files.
+
+2021-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: enable target_async around stop_all_threads call in process_initial_stop_replies
+ The following scenario hangs:
+
+ - maint set target-non-stop on
+ - `gdbserver --attach`
+ - a multi-threaded program
+
+ For example:
+
+ Terminal 1:
+
+ $ gnome-calculator&
+ [1] 495731
+ $ ../gdbserver/gdbserver --once --attach :1234 495731
+ Attached; pid = 495731
+ Listening on port 1234
+
+ Terminal 2:
+
+ $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234"
+ Reading symbols from /usr/bin/gnome-calculator...
+ (No debugging symbols found in /usr/bin/gnome-calculator)
+ Remote debugging using :1234
+ * hangs *
+
+ What happens is:
+
+ - The protocol between gdb and gdbserver is in non-stop mode, but the
+ user-visible behavior is all-stop
+ - On connect, gdbserver sends one stop reply for one thread that is
+ stops, the others stay running
+ - In process_initial_stop_replies, gdb calls stop_all_threads to stop
+ these other threads, because we are using the all-stop user-visible
+ mode
+ - stop_all_threads sends a stop request for all the running threads and
+ then waits for resulting events
+ - At this point, the remote target is in target_async(0) mode, which
+ makes stop_all_threads not consider it for events
+ - stop_all_threads loops indefinitely (it does not even block
+ indefinitely, it is in an infinite busy loop) because there are no
+ event sources. wait_one_event returns a TARGET_WAITKIND_NO_RESUMED
+ wait status.
+
+ Fix that by making the remote target async around the stop_all_threads
+ call.
+
+ I haven't implemented it because I'm not sure how to do it, but I think
+ it would be a good idea to have, in stop_all_threads / wait_one /
+ handle_one, an assert to check that if we are expecting one or more
+ event, then there are some targets that are in a state where they can
+ supply some events. Otherwise, we'll necessarily be stuck in this
+ infinite loop, and it's probably due to a bug in GDB. I'm not too sure
+ where to put this or how to express it though. Perhaps in
+ stop_all_threads, here:
+
+ for (int i = 0; i < waits_needed; i++)
+ {
+ wait_one_event event = wait_one ();
+ *here*
+ if (handle_one (event))
+ break;
+ }
+
+ If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED,
+ there's a problem. We expect some event, because we've asked some
+ threads to stop, but all targets are answering that they won't have any
+ events for us. That's a contradiction, and a sign that something has
+ gone wrong. It could perhaps event be:
+
+ gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED);
+
+ in handle_one, as the idea is the same in prepare_for_detach.
+
+ A bit more sophisticated would be: we know which targets we are
+ expecting waits from, since we know which threads we have asked to
+ stop. So if any of these targets returns TARGET_WAITKIND_NO_RESUMED,
+ something is fishy.
+
+ Add a test that tests attaching with gdbserver's --attach flag to a
+ multi-threaded program, and then connecting to it. Without the fix, the
+ test reproduces the hang.
+
+ Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f
+
+2021-09-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix darwin-nat build (again)
+ I made a mistake in the previous patch. Adjust the format string to
+ match the arguments.
+
+ Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba
+
+2021-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix darwin-nat build
+ There are two errors of this kind:
+
+ CXX darwin-nat.o
+ /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat]
+ ptid.pid (), ptid.tid ());
+ ^~~~~~~~~~~
+
+ Fix them by using ptid_t's to_string method.
+
+ Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7
+
+2021-09-29 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb.base/foll-fork.exp: accept "info breakpoints" output in any order
+ The test currently requires the "inf 1" breakpoint to be before the "inf
+ 2" breakpoint. This is not always the case:
+
+ info breakpoints 2
+ Num Type Disp Enb Address What
+ 2 breakpoint keep y <MULTIPLE>
+ 2.1 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2
+ 2.2 y 0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1
+ (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints
+
+ Since add_location_to_breakpoint uses only the address as a criterion to
+ sort locations, the order of locations at the same address is not
+ stable: it will depend on the insertion order. Here, the insertion
+ order comes from the order of SALs when creating the breakpoint, which
+ can vary from machine to machine. While it would be more user-friendly
+ to have a more stable order for printed breakpoint locations, it doesn't
+ really matter for this test, and it would be hard to define an order
+ that will be the same everywhere, all the time.
+
+ So, loosen the regexp to accept "inf 1" and "inf 2" in any order.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+ Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16
+
+2021-09-28 Cooper Qu <cooper.qu@linux.alibaba.com>
+
+ RISC-V: Fix wrong version number when arch contains 'p'.
+ When specify a default version for p extension in
+ riscv_supported_std_ext[](elfxx-riscv.c) and assembling with
+ -march=rv32imacp, the c extension's version in attribute will become
+ 0p0, the expectation is 2p0.
+
+ TODO: Remember to add testcase when we have supported standrad p in
+ the future.
+
+ bfd/
+ PR gas/28372
+ * elfxx-riscv.c (riscv_parsing_subset_version): Break if p
+ represent the 'p' extension.
+
+ Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59
+
+2021-09-28 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Allow to add numbers in the prefixed extension names.
+ We need to allow adding numbers in the prefixed extension names, since
+ the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec
+ recently. But there are two restrictions as follows,
+
+ * The extension name ends with <number>p is invalid, since this may
+ be confused with extension with <number>.0 version. We report errors
+ for this case.
+
+ Invalid format: [z|h|s|zvm|x][0-9a-z]+[0-9]+p
+
+ * The extension name ends with numbers is valid, but the numbers will
+ be parsed as major version, so try to avoid naming extensions like this.
+
+ bfd/
+ * elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from
+ riscv_valid_prefixed_ext/
+ (riscv_parsing_subset_version): The extensions end with <number>p
+ is forbidden, we already report the detailed errors in the
+ riscv_parse_prefixed_ext, so clean the code and unused parameters.
+ (riscv_parse_std_ext): Updated.
+ (riscv_parse_prefixed_ext): Rewrite the parser to allow numbers
+ in the prefixed extension names.
+ gas/
+ * testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases.
+ * testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise.
+ * testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise.
+ * testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise.
+ * testsuite/gas/riscv/march-fail-invalid.l: Likewise.
+ * testsuite/gas/riscv/march-fail-version-x.d: Removed.
+ * testsuite/gas/riscv/march-fail-version-z.d: Likewise.
+ * testsuite/gas/riscv/march-fail-version.l: Likewise.
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: print backtrace for internal error/warning
+ This commit builds on previous work to allow GDB to print a backtrace
+ of itself when GDB encounters an internal-error or internal-warning.
+ This fixes PR gdb/26377.
+
+ There's not many places where we call internal_warning, and I guess in
+ most cases the user would probably continue their debug session. And
+ so, in order to avoid cluttering up the output, by default, printing
+ of a backtrace is off for internal-warnings.
+
+ In contrast, printing of a backtrace is on by default for
+ internal-errors, as I figure that in most cases hitting an
+ internal-error is going to be the end of the debug session.
+
+ Whether a backtrace is printed or not can be controlled with the new
+ settings:
+
+ maintenance set internal-error backtrace on|off
+ maintenance show internal-error backtrace
+
+ maintenance set internal-warning backtrace on|off
+ maintenance show internal-warning backtrace
+
+ Here is an example of what an internal-error now looks like with the
+ backtrace included:
+
+ (gdb) maintenance internal-error blah
+ ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ ----- Backtrace -----
+ 0x5c61ca gdb_internal_backtrace_1
+ ../../src.dev-3/gdb/bt-utils.c:123
+ 0x5c626d _Z22gdb_internal_backtracev
+ ../../src.dev-3/gdb/bt-utils.c:165
+ 0xe33237 internal_vproblem
+ ../../src.dev-3/gdb/utils.c:393
+ 0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
+ ../../src.dev-3/gdb/utils.c:470
+ 0x1549652 _Z14internal_errorPKciS0_z
+ ../../src.dev-3/gdbsupport/errors.cc:55
+ 0x9c7982 maintenance_internal_error
+ ../../src.dev-3/gdb/maint.c:82
+ 0x636f57 do_simple_func
+ ../../src.dev-3/gdb/cli/cli-decode.c:97
+ .... snip, lots more backtrace lines ....
+ ---------------------
+ ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n) y
+
+ This is a bug, please report it. For instructions, see:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Create a core file of GDB? (y or n) n
+
+ My hope is that this backtrace might make it slightly easier to
+ diagnose GDB issues if all that is provided is the console output, I
+ find that we frequently get reports of an assert being hit that is
+ located in pretty generic code (frame.c, value.c, etc) and it is not
+ always obvious how we might have arrived at the assert.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: use libbacktrace to create a better backtrace for fatal signals
+ GDB recently gained the ability to print a backtrace when a fatal
+ signal is encountered. This backtrace is produced using the backtrace
+ and backtrace_symbols_fd API available in glibc.
+
+ However, in order for this API to actually map addresses to symbol
+ names it is required that the application (GDB) be compiled with
+ -rdynamic, which GDB is not by default.
+
+ As a result, the backtrace produced often looks like this:
+
+ Fatal signal: Bus error
+ ----- Backtrace -----
+ ./gdb/gdb[0x80ec00]
+ ./gdb/gdb[0x80ed56]
+ /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0]
+ /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f]
+ ./gdb/gdb[0x15495ba]
+ ./gdb/gdb[0x15489b8]
+ ./gdb/gdb[0x9b794d]
+ ./gdb/gdb[0x9b7a6d]
+ ./gdb/gdb[0x9b943b]
+ ./gdb/gdb[0x9b94a1]
+ ./gdb/gdb[0x4175dd]
+ /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3]
+ ./gdb/gdb[0x4174de]
+ ---------------------
+
+ This is OK if you have access to the exact same build of GDB, you can
+ manually map the addresses back to symbols, however, it is next to
+ useless if all you have is a backtrace copied into a bug report.
+
+ GCC uses libbacktrace for printing a backtrace when it encounters an
+ error. In recent commits I added this library into the binutils-gdb
+ repository, and in this commit I allow this library to be used by
+ GDB. Now (when GDB is compiled with debug information) the backtrace
+ looks like this:
+
+ ----- Backtrace -----
+ 0x80ee08 gdb_internal_backtrace
+ ../../src/gdb/event-top.c:989
+ 0x80ef0b handle_fatal_signal
+ ../../src/gdb/event-top.c:1036
+ 0x7f24539dd6af ???
+ 0x7f2453a97a5f ???
+ 0x154976f gdb_wait_for_event
+ ../../src/gdbsupport/event-loop.cc:613
+ 0x1548b6d _Z16gdb_do_one_eventv
+ ../../src/gdbsupport/event-loop.cc:237
+ 0x9b7b02 start_event_loop
+ ../../src/gdb/main.c:421
+ 0x9b7c22 captured_command_loop
+ ../../src/gdb/main.c:481
+ 0x9b95f0 captured_main
+ ../../src/gdb/main.c:1353
+ 0x9b9656 _Z8gdb_mainP18captured_main_args
+ ../../src/gdb/main.c:1368
+ 0x4175ec main
+ ../../src/gdb/gdb.c:32
+ ---------------------
+
+ Which seems much more useful.
+
+ Use of libbacktrace is optional. If GDB is configured with
+ --disable-libbacktrace then the libbacktrace directory will not be
+ built, and GDB will not try to use this library. In this case GDB
+ would try to use the old backtrace and backtrace_symbols_fd API.
+
+ All of the functions related to writing the backtrace of GDB itself
+ have been moved into the new files gdb/by-utils.{c,h}.
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS
+ After the previous commit that imported libbacktrace from gcc, this
+ commit updates src-release.sh so that the libbacktrace directory is
+ included in the gdb release tar file.
+
+ ChangeLog:
+
+ * src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace.
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ Copy in libbacktrace from gcc
+ This copies in libbacktrace from the gcc repository as it was in the
+ commit 62e420293a293608f383d9b9c7f2debd666e9fc9. GDB is going to
+ start using this library soon.
+
+ A dependency between GDB and libbacktrace has already been added to
+ the top level Makefile, so, after this commit, when building GDB,
+ libbacktrace will be built first. However, libbacktrace is not yet
+ linked into GDB, or used by GDB in any way.
+
+ It is possible to stop libbacktrace being built by configuring the
+ tree with --disable-libbacktrace.
+
+ This commit does NOT update src-release.sh, that will be done in the
+ next commit, this commit ONLY imports libbacktrace from gcc. This
+ means that if you try to make a release of GDB from exactly this
+ commit then the release tar file will not include libbacktrace.
+ However, as libbacktrace is an optional dependency this is fine.
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: Add a dependency between gdb and libbacktrace
+ GDB is going to start using libbacktrace, so add a build dependency.
+
+ ChangeLog:
+
+ * Makefile.def: Add all-gdb dependency on all-libbacktrace.
+ * Makefile.in: Regenerate.
+
+2021-09-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ top-level configure: setup target_configdirs based on repository
+ The top-level configure script is shared between the gcc repository
+ and the binutils-gdb repository.
+
+ The target_configdirs variable in the configure.ac script, defines
+ sub-directories that contain components that should be built for the
+ target using the target tools.
+
+ Some components, e.g. zlib, are built as both host and target
+ libraries.
+
+ This causes problems for binutils-gdb. If we run 'make all' in the
+ binutils-gdb repository we end up trying to build a target version of
+ the zlib library, which requires the target compiler be available.
+ Often the target compiler isn't immediately available, and so the
+ build fails.
+
+ The problem with zlib impacted a previous attempt to synchronise the
+ top-level configure scripts from gcc to binutils-gdb, see this thread:
+
+ https://sourceware.org/pipermail/binutils/2019-May/107094.html
+
+ And I'm in the process of importing libbacktrace in to binutils-gdb,
+ which is also a host and target library, and triggers the same issues.
+
+ I believe that for binutils-gdb, at least at the moment, there are no
+ target libraries that we need to build.
+
+ In the configure script we build three lists of things we want to
+ build, $configdirs, $build_configdirs, and $target_configdirs, we also
+ build two lists of things we don't want to build, $skipdirs and
+ $noconfigdirs. We then remove anything that is in the lists of things
+ not to build, from the list of things that should be built.
+
+ My proposal is to add everything in target_configdirs into skipdirs,
+ if the source tree doesn't contain a gcc/ sub-directory. The result
+ is that for binutils-gdb no target tools or libraries will be built,
+ while for the gcc repository, nothing should change.
+
+ If a user builds a unified source tree, then the target tools and
+ libraries should still be built as the gcc/ directory will be present.
+
+ I've tested a build of gcc on x86-64, and the same set of target
+ libraries still seem to get built. On binutils-gdb this change
+ resolves the issues with 'make all'.
+
+ ChangeLog:
+
+ * configure: Regenerate.
+ * configure.ac (skipdirs): Add the contents of target_configdirs if
+ we are not building gcc.
+
+2021-09-28 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
+
+ PR28391, strip/objcopy --preserve-dates *.a: cannot set time
+ After commit 985e0264516 copy_archive function began to pass invalid
+ values to the utimensat(2) function when it tries to preserve
+ timestamps in ar archives. This happens because the bfd_stat_arch_elt
+ implementation for ar archives fills only the st_mtim.tv_sec part of
+ the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part
+ and the whole st_atim timespec untouched leaving them uninitialized
+
+ PR 28391
+ * ar.c (extract_file): Clear buf for preserve_dates.
+ * objcopy.c (copy_archive): Likewise.
+
+2021-09-28 Mike Frysinger <vapier@gentoo.org>
+
+ sim: drop weak func attrs on module inits
+ When I first wrote this, I was thinking we'd scan all source files
+ that existed and generate a complete init list. That means for any
+ particular build, we'd probably have a few functions that didn't
+ exist, so weak attributes was necessary. What I ended up scanning
+ though was only the source files that went into a particular build.
+
+ There was another concern too: a source file might be included, but
+ the build settings would cause all of its contents to be skipped
+ (via CPP defines). So scanning via naive grep would pick up names
+ not actually available. A check of the source tree shows that we
+ never do this, and it's pretty easy to institute a policy that we
+ don't start (by at the very least including a stub init func).
+
+ The use of weak symbols ends up causing a problem in practice: for
+ a few modules (like profiling), nothing else pulls it in, so the
+ linker omits it entirely, which leads to the profiling module never
+ being available. So drop the weak markings since we know all these
+ funcs will be available.
+
+2021-09-28 Cui,Lili <lili.cui@intel.com>
+
+ x86: Print {bad} on invalid broadcast in OP_E_memory
+ Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast.
+
+ gas/
+
+ PR binutils/28381
+ * testsuite/gas/i386/bad-bcast.s: Add a new testcase.
+ * testsuite/gas/i386/bad-bcast.d: Likewise.
+ * testsuite/gas/i386/bad-bcast-intel.d: New.
+
+ opcodes/
+
+ PR binutils/28381
+ * i386-dis.c (static struct): Add no_broadcast.
+ (OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it.
+ (intel_operand_size): mark invalid broadcast with no_broadcast=1.
+ (OP_XMM): Mark scalar_mode with no_broadcast=1.
+
+2021-09-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use intrusive_list for linux-nat lwp_list
+ Replace the manually maintained linked list of lwp_info objects with
+ intrusive_list. Replace the ALL_LWPS macro with all_lwps, which returns
+ a range. Add all_lwps_safe as well, for use in iterate_over_lwps, which
+ currently iterates in a safe manner.
+
+ Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c
+
+2021-09-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add destructor to lwp_info
+ Replace the lwp_free function with a destructor. Make lwp_info
+ non-copyable, since there is now a destructor (we wouldn't want an
+ lwp_info object getting copied and this->arch_private getting deleted
+ twice).
+
+ Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa
+
+2021-09-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make lwp_info non-POD
+ Initialize all fields in the class declaration directly. This opens the
+ door to using intrusive_list, done in the following patch.
+
+ Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05
+
+2021-09-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"
+ We found that when handling forks, two inferiors can unexpectedly share
+ their program space and address space. To reproduce:
+
+ 1. Using a test program that forks...
+ 2. "set follow-fork-mode child"
+ 3. "set detach-on-fork on" (the default)
+ 4. run to a breakpoint somewhere after the fork
+
+ Step 4 should have created a new inferior:
+
+ (gdb) info inferiors
+ Num Description Connection Executable
+ 1 <null> /home/smarchi/build/wt/amd/gdb/fork
+ * 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork
+
+ By inspecting the state of GDB, we can see that the two inferiors now
+ share one program space and one address space:
+
+ Inferior 1:
+
+ (top-gdb) p inferior_list.m_front.num
+ $2 = 1
+ (top-gdb) p inferior_list.m_front.aspace
+ $3 = (struct address_space *) 0x5595e2520400
+ (top-gdb) p inferior_list.m_front.pspace
+ $4 = (struct program_space *) 0x5595e2520440
+
+ Inferior 2:
+
+ (top-gdb) p inferior_list.m_front.next.num
+ $5 = 2
+ (top-gdb) p inferior_list.m_front.next.aspace
+ $6 = (struct address_space *) 0x5595e2520400
+ (top-gdb) p inferior_list.m_front.next.pspace
+ $7 = (struct program_space *) 0x5595e2520440
+
+ You can then run inferior 1 again and the two inferiors will still
+ erroneously share their spaces, but already at this point this is wrong.
+
+ The cause of the bad {a,p}space sharing is in follow_fork_inferior.
+ When following the child and detaching from the parent, we just re-use
+ the parent's spaces, rather than cloning them. When we switch back to
+ inferior 1 and run again, we find ourselves with two unrelated inferiors
+ sharing spaces.
+
+ Fix that by creating new spaces for the parent after having moved them
+ to the child. My initial implementation created new spaces for the
+ child instead. Doing this breaks doing "next" over fork(). When "next"
+ start, we record the symtab of the starting location. When the program
+ stops, we compare that symtab with the symtab the program has stopped
+ at. If the symtab or the line number has changed, we conclude the
+ "next" is done. If we create a new program space for the child and copy
+ the parent's program space to it with clone_program_space, it creates
+ new symtabs for the child as well. When the child stop, but still on
+ the fork() line, GDB thinks the "next" is done because the symtab
+ pointers no longer match. In reality they are two symtab instances that
+ represent the same file. But moving the spaces to the child and
+ creating new spaces for the parent, we avoid this problem.
+
+ Note that the problem described above happens today with "detach-on-fork
+ off" and "follow-fork-mode child", because we create new spaces for the
+ child. This will have to be addressed later.
+
+ Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
+ expected to have a location in each inferiors. Without the fix, when
+ the two inferiors erroneously share a program space, GDB reports a
+ single location.
+
+ Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixes
+ No behavior change in the test expected, other than in the test names.
+
+ Change-Id: I111137483858ab0f23138439f2930009779a2b3d
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.base/foll-fork.exp: rename variables
+ Rename the variables / parameters used to match the corresponding GDB
+ setting name, I find that easier to follow.
+
+ Change-Id: Idcbddbbb369279fcf1e808b11a8c478f21b2a946
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.base/foll-fork.exp: refactor to restart GDB between each portion of the test
+ This test is difficult to follow and modify because the state of GDB is
+ preserved some tests. Add a setup proc, which starts a new GDB and runs
+ to main, and use it in all test procs. Use proc_with_prefix to avoid
+ duplicates.
+
+ The check_fork_catchpoints proc also seems used to check for follow-fork
+ support by checking if catchpoints are supported. If they are not, it
+ uses "return -code return", which makes its caller return. I find this
+ unnecessary complex, versus just returning a boolean. Modify it to do
+ so.
+
+ Change-Id: I23e62b204286c5e9c5c86d2727f7d33fb126ed08
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.base/foll-fork.exp: remove gating based on target triplet
+ It looks like this test has some code to check at runtime the support of
+ fork handling of the target (see check_fork_catchpoints). So, it seems
+ to me that the check based on target triplet at the beginning of the
+ test is not needed. This kind of gating is generally not desirable,
+ because we wouldn't think of updating it when adding fork support to a
+ target. For example, FreeBSD supports fork, but it wasn't listed here.
+
+ Change-Id: I6b55f2298edae6b37c3681fb8633d8ea1b5aabee
+
+2021-09-27 Simon Marchi <simon.marchi@efficios.com>
+
+ gdb.base/foll-fork.exp: remove DUPLICATEs
+ Remove DUPLICATEs, and and at the same time replace two uses of
+ gdb_test_multiple with gdb_test. I don't think using gdb_test_multiple
+ is necessary here.
+
+ Change-Id: I8dcf097c3364e92d4f0e11f0c0f05dbb88e86742
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, lookup: fix bounds of pptrtab lookup
+ An off-by-one bug in the check for pptrtab lookup meant that we could
+ access the pptrtab past its bounds (*well* past its bounds),
+ particularly if we called ctf_lookup_by_name in a child dict with "*foo"
+ where "foo" is a type that exists in the parent but not the child and no
+ previous lookups by name have been carried out. (Note that "*foo" is
+ not even a valid thing to call ctf_lookup_by_name with: foo * is.
+ Nonetheless, users sometimes do call ctf_lookup_by_name with invalid
+ content, and it should return ECTF_NOTYPE, not crash.)
+
+ ctf_pptrtab_len, as its name suggests (and as other tests of it in
+ ctf-lookup.c confirm), is one higher than the maximum valid permissible
+ index, so the comparison is wrong.
+
+ (Test added, which should fail pretty reliably in the presence of this
+ bug on any machine with 4KiB pages.)
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * ctf-lookup.c (ctf_lookup_by_name_internal): Fix pptrtab bounds.
+ * testsuite/libctf-writable/pptrtab-writable-page-deep-lookup.*:
+ New test.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf, testsuite: fix various warnings in tests
+ These warnings are all off by default, but if they do fire you get
+ spurious ERRORs when running make check-libctf.
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * testsuite/libctf-lookup/enum-symbol.c: Remove unused label.
+ * testsuite/libctf-lookup/conflicting-type-syms.c: Remove unused
+ variables.
+ * testsuite/libctf-regression/pptrtab.c: Likewise.
+ * testsuite/libctf-regression/type-add-unnamed-struct.c: Likewise.
+ * testsuite/libctf-writable/pptrtab.c: Likewise.
+ * testsuite/libctf-writable/reserialize-strtab-corruption.c:
+ Likewise.
+ * testsuite/libctf-regression/nonstatic-var-section-ld-r.c: Fix
+ format string.
+ * testsuite/libctf-regression/nonstatic-var-section-ld.c:
+ Likewise.
+ * testsuite/libctf-regression/nonstatic-var-section-ld.lk: Adjust.
+ * testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Fix
+ initializer.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: fix handling of CTF symtypetab sections emitted by older GCC
+ Older (pre-upstreaming) GCC emits a function symtypetab section of a
+ format never read by any extant libctf. We can detect such CTF dicts by
+ the lack of the CTF_F_NEWFUNCINFO flag in their header, and we do so
+ when reading in the symtypetab section -- but if the set of symbols with
+ types is sufficiently sparse, even an older GCC will emit a function
+ index section.
+
+ In NEWFUNCINFO-capable compilers, this section will always be the exact
+ same length as the corresponding function section (each is an array of
+ uint32_t, associated 1:1 with each other). But this is not true for the
+ older compiler, for which the sections are different lengths. We check
+ to see if the function symtypetab section and its index are the same
+ length, but we fail to skip this check when this is not a NEWFUNCINFO
+ dict, and emit a spurious corruption error for a CTF dict we could
+ have perfectly well opened and used.
+
+ Fix trivial: check the flag (and fix the terrible grammar of the error
+ message at the same time).
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * ctf-open.c (ctf_bufopen_internal): Don't complain about corrupt
+ function index symtypetab sections if this is an old-format
+ function symtypetab section (which should be ignored in any case).
+ Fix bad grammar.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ configure: regenerate in all projects that use libtool.m4
+ (including sim/, which has no changelog.)
+
+ bfd/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ binutils/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ gas/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ gprof/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ ld/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+ * Makefile.in: Regenerate.
+
+ opcodes/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+ zlib/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ * configure: Regenerate.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: try several possibilities for linker versioning flags
+ Checking for linker versioning by just grepping ld --help output for
+ mentions of --version-script is inadequate now that Solaris 11.4
+ implements a --version-script with different semantics. Try linking a
+ test program with a small wildcard-using version script with each
+ supported set of flags in turn, to make sure that linker versioning is
+ not only advertised but actually works.
+
+ The Solaris "GNU-compatible" linker versioning is not quite
+ GNU-compatible enough, but we can work around the differences by
+ generating a new version script that removes the comments from the
+ original (Solaris ld requires #-style comments), and making another
+ version script for libctf-nonbfd in particular which doesn't mention any
+ of the symbols that appear in libctf.la, to avoid Solaris ld introducing
+ corresponding new NOTYPE symbols to match the version script.
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ PR libctf/27967
+ * configure.ac (VERSION_FLAGS): Replace with...
+ (ac_cv_libctf_version_script): ... this multiple test.
+ (VERSION_FLAGS_NOBFD): Substitute this too.
+ * Makefile.am (libctf_nobfd_la_LDFLAGS): Use it. Split out...
+ (libctf_ldflags_nover): ... non-versioning flags here.
+ (libctf_la_LDFLAGS): Use it.
+ * libctf.ver: Give every symbol not in libctf-nobfd a comment on
+ the same line noting as much.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libtool.m4: fix nm BSD flag detection
+ Libtool needs to get BSD-format (or MS-format) output out of the system
+ nm, so that it can scan generated object files for symbol names for
+ -export-symbols-regex support. Some nms need specific flags to turn on
+ BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
+ Unfortunately the code to do this has a pair of interlocking flaws:
+
+ - it runs the test by doing an nm of /dev/null. Some platforms
+ reasonably refuse to do an nm on a device file, but before now this
+ has only been worked around by assuming that the error message has a
+ specific textual form emitted by Tru64 nm, and that getting this
+ error means this is Tru64 nm and that nm -B would work to produce
+ BSD-format output, even though the test never actually got anything
+ but an error message out of nm -B. This is fixable by nm'ing *nm
+ itself* (since we necessarily have a path to it).
+
+ - the test is entirely skipped if NM is set in the environment, on the
+ grounds that the user has overridden the test: but the user cannot
+ reasonably be expected to know that libtool wants not only nm but
+ also flags forcing BSD-format output. Worse yet, one such "user" is
+ the top-level Cygnus configure script, which neither tests for
+ nor specifies any BSD-format flags. So platforms needing BSD-format
+ flags always fail to set them when run in a Cygnus tree, breaking
+ -export-symbols-regex on such platforms. Libtool also needs to
+ augment $LD on some platforms, but this is done unconditionally,
+ augmenting whatever the user specified: the nm check should do the
+ same.
+
+ One wrinkle: if the user has overridden $NM, a path might have been
+ provided: so we use the user-specified path if there was one, and
+ otherwise do the path search as usual. (If the nm specified doesn't
+ work, this might lead to a few extra pointless path searches -- but
+ the test is going to fail anyway, so that's not a problem.)
+
+ (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
+ symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
+ *that* is a symlink to /usr/bin/nm.)
+
+ ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ PR libctf/27967
+ * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
+ NM, if there is one. Run nm on itself, not on /dev/null, to avoid
+ errors from nms that refuse to work on non-regular files. Remove
+ other workarounds for this problem. Strip out blank lines from the
+ nm output.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libtool.m4: augment symcode for Solaris 11
+ This reports common symbols like GNU nm, via a type code of 'C'.
+
+ ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ PR libctf/27967
+ * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
+ Solaris 11.
+
+2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ libctf: link against libiberty before linking in libbfd or libctf-nobfd
+ This ensures that the CTF_LIBADD, which always contains at least this
+ when doing a shared link:
+
+ -L`pwd`/../libiberty/pic -liberty
+
+ appears in the link line before any requirements pulled in by libbfd.la,
+ which include -liberty but because it is install-time do not include the
+ -L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path
+ comes from the libbfd.la file, and is an install path). libiberty also
+ appears after libbfd in the link line by virtue of libctf-nobfd.la,
+ because libctf-nobfd has to follow libbfd in the link line, and that
+ needs symbols from libiberty too.
+
+ Without this, an installed liberty might well be pulled in by libbfd,
+ and if --enable-install-libiberty is not specified this libiberty might
+ be completely incompatible with what is being installed and break either
+ or boht of libbfd and libctf. (The specific problem observed here is
+ that bsearch_r was not present, but other problems might easily be
+ observed in future too.)
+
+ Because ld links against libctf, this has a tendency to break the system
+ linker at install time too, if installing with --prefix=/usr. That's
+ quite unpleasant to recover from.
+
+ libctf/ChangeLog
+ 2021-09-27 Nick Alcock <nick.alcock@oracle.com>
+
+ PR libctf/27360
+ * Makefile.am (libctf_la_LIBADD): Link against libiberty
+ before pulling in libbfd.la or pulling in libctf-nobfd.la.
+ * Makefile.in: Regenerate.
+
+2021-09-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with g++-4.8
+ When building g++-4.8, we run into:
+ ...
+ src/gdb/dwarf2/read.c:919:5: error: multiple fields in union \
+ 'partial_die_info::<anonymous union>' initialized
+ ...
+
+ This is due to:
+ ...
+ union
+ {
+ struct
+ {
+ CORE_ADDR lowpc = 0;
+ CORE_ADDR highpc = 0;
+ };
+ ULONGEST ranges_offset;
+ };
+ ...
+
+ The error looks incorrect, given that only one union member is initialized,
+ and does not reproduce with newer g++.
+
+ Nevertheless, work around this by moving the initialization to a constructor.
+
+ [ I considered just removing the initialization, with the idea that access
+ should be guarded by has_pc_info, but I ran into one failure in the testsuite,
+ for gdb.base/check-psymtab.exp due to add_partial_symbol using lowpc without
+ checking has_pc_info. ]
+
+ Tested on x86_64-linux.
+
+2021-09-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: add setting to disable reading source code files
+ In some situations it is possible that a user might not want GDB to
+ try and access source code files, for example, the source code might
+ be stored on a slow to access network file system.
+
+ It is almost certainly possible that using some combination of 'set
+ directories' and/or 'set substitute-path' a user can trick GDB into
+ being unable to find the source files, but this feels like a rather
+ crude way to solve the problem.
+
+ In this commit a new option is add that stops GDB from opening and
+ reading the source files. A user can run with source code reading
+ disabled if this is required, then re-enable later if they decide
+ that they now want to view the source code.
+
+2021-09-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: remove duplicate cmd_list_element declarations
+ For some reason we have two locations where cmd_list_elements are
+ declared, cli/cli-cmds.h and gdbcmd.h. Worse still there is
+ duplication between these two locations.
+
+ In this commit I have moved all of the cmd_list_element declarations
+ from gdbcmd.h into cli/cli-cmds.h and removed the duplicates.
+
+ There should be no user visible changes after this commit.
+
+2021-09-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: prevent an assertion when computing the frame_id for an inline frame
+ I ran into this assertion while GDB was trying to unwind the stack:
+
+ gdb/inline-frame.c:173: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed.
+
+ That is, when building the frame_id for an inline frame, GDB asks for
+ the frame_id of the previous frame. Unfortunately, no valid frame_id
+ was returned for the previous frame, and so the assertion triggers.
+
+ What is happening is this, I had a stack that looked something like
+ this (the arrows '->' point from caller to callee):
+
+ normal_frame -> inline_frame
+
+ However, for whatever reason (e.g. broken debug information, or
+ corrupted stack contents in the inferior), when GDB tries to unwind
+ "normal_frame", it ends up getting back effectively the same frame,
+ thus the call stack looks like this to GDB:
+
+ .-> normal_frame -> inline_frame
+ | |
+ '-----'
+
+ Given such a situation we would expect GDB to terminate the stack with
+ an error like this:
+
+ Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+
+ However, the inline_frame causes a problem, and here's why:
+
+ When unwinding we start from the sentinel frame and call
+ get_prev_frame. We eventually end up in get_prev_frame_if_no_cycle,
+ in here we create a raw frame, and as this is frame #0 we immediately
+ return.
+
+ However, eventually we will try to unwind the stack further. When we
+ do this we inevitably needing to know the frame_id for frame #0, and
+ so, eventually, we end up in compute_frame_id.
+
+ In compute_frame_id we first find the right unwinder for this frame,
+ in our case (i.e. for inline_frame) the $pc is within the function
+ normal_frame, but also within a block associated with the inlined
+ function inline_frame, as such the inline frame unwinder claims this
+ frame.
+
+ Back in compute_frame_id we next compute the frame_id, for our
+ inline_frame this means a call to inline_frame_this_id.
+
+ The ID of an inline frame is based on the id of the previous frame, so
+ from inline_frame_this_id we call get_prev_frame_always, this
+ eventually calls get_prev_frame_if_no_cycle again, which creates
+ another raw frame and calls compute_frame_id (for frames other than
+ frame 0 we immediately compute the frame_id).
+
+ In compute_frame_id we again identify the correct unwinder for this
+ frame. Our $pc is unchanged, however, the fact that the next frame is
+ of type INLINE_FRAME prevents the inline frame unwinder from claiming
+ this frame again, and so, the standard DWARF frame unwinder claims
+ normal_frame.
+
+ We return to compute_frame_id and call the standard DWARF function to
+ build the frame_id for normal_frame.
+
+ With the frame_id of normal_frame figured out we return to
+ compute_frame_id, and then to get_prev_frame_if_no_cycle, where we add
+ the ID for normal_frame into the frame_id cache, and return the frame
+ back to inline_frame_this_id.
+
+ From inline_frame_this_id we build a frame_id for inline_frame and
+ return to compute_frame_id, and then to get_prev_frame_if_no_cycle,
+ which adds the frame_id for inline_frame into the frame_id cache.
+
+ So far, so good.
+
+ However, as we are trying to unwind the complete stack, we eventually
+ ask for the previous frame of normal_frame, remember, at this point
+ GDB doesn't know the stack is corrupted (with a cycle), GDB still
+ needs to figure that out.
+
+ So, we eventually end up in get_prev_frame_if_no_cycle where we create
+ a raw frame and call compute_frame_id, remember, this is for the frame
+ before normal_frame.
+
+ The first task for compute_frame_id is to find the unwinder for this
+ frame, so all of the frame sniffers are tried in order, this includes
+ the inline frame sniffer.
+
+ The inline frame sniffer asks for the $pc, this request is sent up the
+ stack to normal_frame, which, due to its cyclic behaviour, tells GDB
+ that the $pc in the previous frame was the same as the $pc in
+ normal_frame.
+
+ GDB spots that this $pc corresponds to both the function normal_frame
+ and also the inline function inline_frame. As the next frame is not
+ an INLINE_FRAME then GDB figures that we have not yet built a frame to
+ cover inline_frame, and so the inline sniffer claims this new frame.
+ Our stack is now looking like this:
+
+ inline_frame -> normal_frame -> inline_frame
+
+ But, we have not yet computed the frame id for the outer most (on the
+ left) inline_frame. After the frame sniffer has claimed the inline
+ frame GDB returns to compute_frame_id and calls inline_frame_this_id.
+
+ In here GDB calls get_prev_frame_always, which eventually ends up
+ in get_prev_frame_if_no_cycle again, where we create a raw frame and
+ call compute_frame_id.
+
+ Just like before, compute_frame_id tries to find an unwinder for this
+ new frame, it sees that the $pc is within both normal_frame and
+ inline_frame, but the next frame is, again, an INLINE_FRAME, so, just
+ like before the standard DWARF unwinder claims this frame. Back in
+ compute_frame_id we again call the standard DWARF function to build
+ the frame_id for this new copy of normal_frame.
+
+ At this point the stack looks like this:
+
+ normal_frame -> inline_frame -> normal_frame -> inline_frame
+
+ After compute_frame_id we return to get_prev_frame_if_no_cycle, where
+ we try to add the frame_id for the new normal_frame into the frame_id
+ cache, however, unlike before, we fail to add this frame_id as it is
+ a duplicate of the previous normal_frame frame_id. Having found a
+ duplicate get_prev_frame_if_no_cycle unlinks the new frame from the
+ stack, and returns nullptr, the stack now looks like this:
+
+ inline_frame -> normal_frame -> inline_frame
+
+ The nullptr result from get_prev_frame_if_no_cycle is fed back to
+ inline_frame_this_id, which forwards this to get_frame_id, which
+ immediately returns null_frame_id. As null_frame_id is not considered
+ a valid frame_id, this is what triggers the assertion.
+
+ In summary then:
+
+ - inline_frame_this_id currently assumes that as the inline frame
+ exists, we will always get a valid frame back from
+ get_prev_frame_always,
+
+ - get_prev_frame_if_no_cycle currently assumes that it is safe to
+ return nullptr when it sees a cycle.
+
+ Notice that in frame.c:compute_frame_id, this code:
+
+ fi->this_id.value = outer_frame_id;
+ fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
+ gdb_assert (frame_id_p (fi->this_id.value));
+
+ The assertion makes it clear that the this_id function must always
+ return a valid frame_id (e.g. null_frame_id is not a valid return
+ value), and similarly in inline_frame.c:inline_frame_this_id this
+ code:
+
+ *this_id = get_frame_id (get_prev_frame_always (this_frame));
+ /* snip comment */
+ gdb_assert (frame_id_p (*this_id));
+
+ Makes it clear that every inline frame expects to be able to get a
+ previous frame, which will have a valid frame_id.
+
+ As I have discussed above, these assumptions don't currently hold in
+ all cases.
+
+ One possibility would be to move the call to get_prev_frame_always
+ forward from inline_frame_this_id to inline_frame_sniffer, however,
+ this falls foul of (in frame.c:frame_cleanup_after_sniffer) this
+ assertion:
+
+ /* No sniffer should extend the frame chain; sniff based on what is
+ already certain. */
+ gdb_assert (!frame->prev_p);
+
+ This assert prohibits any sniffer from trying to get the previous
+ frame, as getting the previous frame is likely to depend on the next
+ frame, I can understand why this assertion is a good thing, and I'm in
+ no rush to alter this rule.
+
+ The solution proposed here takes onboard feedback from both Pedro, and
+ Simon (see the links below). The get_prev_frame_if_no_cycle function
+ is renamed to get_prev_frame_maybe_check_cycle, and will now not do
+ cycle detection for inline frames, even when we spot a duplicate frame
+ it is still returned. This is fine, as, if the normal frame has a
+ duplicate frame-id then the inline frame will also have a duplicate
+ frame-id. And so, when we reject the inline frame, the duplicate
+ normal frame, which is previous to the inline frame, will also be
+ rejected.
+
+ In inline-frame.c the call to get_prev_frame_always is no longer
+ nested inside the call to get_frame_id. There are reasons why
+ get_prev_frame_always can return nullptr, for example, if there is a
+ memory error while trying to get the previous frame, if this should
+ happen then we now give a more informative error message.
+
+ Historical Links:
+
+ Patch v2: https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
+ Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/180651.html
+ https://sourceware.org/pipermail/gdb-patches/2021-July/180663.html
+
+ Patch v3: https://sourceware.org/pipermail/gdb-patches/2021-July/181029.html
+ Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/181035.html
+
+ Additional input: https://sourceware.org/pipermail/gdb-patches/2021-September/182040.html
+
+2021-09-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/dcache-flush.exp
+ When running test-case gdb.base/dcache-flush.exp on ubuntu 18.04.5, I run into:
+ ...
+ (gdb) PASS: gdb.base/dcache-flush.exp: p var2
+ info dcache^M
+ Dcache 4096 lines of 64 bytes each.^M
+ Contains data for Thread 0x7ffff7fc6b80 (LWP 3551)^M
+ Line 0: address 0x7fffffffd4c0 [47 hits]^M
+ Line 1: address 0x7fffffffd500 [31 hits]^M
+ Line 2: address 0x7fffffffd5c0 [7 hits]^M
+ Cache state: 3 active lines, 85 hits^M
+ (gdb) FAIL: gdb.base/dcache-flush.exp: check dcache before flushing
+ ...
+ The regexp expects "Contains data for process $decimal".
+
+ This is another case of thread_db_target::pid_to_str being used.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2021-09-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp
+ The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s
+ when using hw watchpoints, but when forcing sw watchpoints (using the patch
+ mentioned in PR28375#c0), the test-case takes instead 3m14s.
+
+ Also, it show a FAIL:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ Cannot find user-level thread for LWP 10324: generic error^M
+ (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process:
+ continue: watchpoint: continue
+ ...
+ for which PR28375 was filed.
+
+ Modify the test-case to:
+ - add the hw/sw axis to the watchpoint testing, to ensure that we
+ observe the sw watchpoint behaviour also on can-use-hw-watchpoints
+ architectures.
+ - skip the hw breakpoint testing if not supported
+ - set the sw watchpoint later to avoid making the test
+ too slow. This still triggers the same PR, but now takes just 24s.
+
+ This patch adds a KFAIL for PR28375.
+
+ Tested on x86_64-linux.
+
+2021-09-27 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix indentation in gdbtypes.c
+ Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771
+
+2021-09-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-26 Peter Bergner <bergner@linux.ibm.com>
+
+ PowerPC: Enable mfppr mfppr32, mtppr and mtppr32 extended mnemonics on POWER5
+ SPR 896 and the mfppr mfppr32, mtppr and mtppr32 extended mnemonics were added
+ in ISA 2.03, so enable them on POWER5 and later.
+
+ opcodes/
+ * ppc-opc.c (powerpc_opcodes) <mfppr, mfppr32, mtppr, mtppr32>: Enable
+ on POWER5 and later.
+
+ gas/
+ * testsuite/gas/ppc/power5.s: New test.
+ * testsuite/gas/ppc/power5.d: Likewise.
+ * testsuite/gas/ppc/ppc.exp: Run it.
+ * testsuite/gas/ppc/power7.s: Remove tests for mfppr, mfppr32, mtppr
+ and mtppr32.
+ * testsuite/gas/ppc/power7.d: Likewise.
+
+2021-09-25 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Minimize gdb restarts
+ Minimize gdb restarts, applying the following rules:
+ - don't use prepare_for_testing unless necessary
+ - don't use clean_restart unless necessary
+
+ Also, if possible, replace build_for_executable + clean_restart
+ with prepare_for_testing for brevity.
+
+ Touches 68 test-cases.
+
+ Tested on x86_64-linux.
+
+2021-09-25 Alan Modra <amodra@gmail.com>
+
+ PR28346, segfault attempting to disassemble raw binary
+ Don't attempt to access elf_section_data for non-ELF sections.
+
+ PR 28346
+ * elf32-xtensa.c (xtensa_read_table_entries): Return zero entries
+ for non-ELF.
+
+2021-09-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-24 Hans-Peter Nilsson <hp@axis.com>
+
+ gas/testsuite/ld-elf/dwarf2-21.d: Pass -W
+ Required for the expected "CU:" to be emitted for long
+ source-paths. See binutils/dwarf.c:
+
+ if (do_wide || strlen (directory) < 76)
+ printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
+ else
+ printf ("%s:\n", file_table[0].name);
+
+ See also commit 5f410aa50ce2c, "testsuite/ld-elf/pr26936.d:
+ Pass -W."
+
+ gas/ChangeLog:
+ * testsuite/ld-elf/dwarf2-21.d: Pass -W.
+
+2021-09-24 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: change thread_info::name to unique_xmalloc_ptr, add helper function
+ This started out as changing thread_info::name to a unique_xmalloc_ptr.
+ That showed that almost all users of that field had the same logic to
+ get a thread's name: use thread_info::name if non-nullptr, else ask the
+ target. Factor out this logic in a new thread_name free function. Make
+ the field private (rename to m_name) and add some accessors.
+
+ Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc
+
+2021-09-24 Tom Tromey <tom@tromey.com>
+
+ Move value_true to value.h
+ I noticed that value_true is declared in language.h and defined in
+ language.c. However, as part of the value API, I think it would be
+ better in one of those files. And, because it is very short, I
+ changed it to be an inline function in value.h. I've also removed a
+ comment from the implementation, on the basis that it seems obsolete
+ -- if the change it suggests was needed, it probably would have been
+ done by now; and if it is needed in the future, odds are it would be
+ done differently anyway.
+
+ Finally, this patch also changes value_true and value_logical_not to
+ return a bool, and updates some uses.
+
+2021-09-24 Pedro Alves <pedro@palves.net>
+
+ Make dcache multi-target-safe
+ By inspection, I noticed that this code in dcache.c is not
+ multi-target-aware:
+
+ /* If this is a different inferior from what we've recorded,
+ flush the cache. */
+
+ if (inferior_ptid != dcache->ptid)
+
+ This doesn't take into account that threads of different targets may
+ have the same ptid.
+
+ Fixed by also storing/comparing the process_stratum_target.
+
+ Tested on x86-64-linux-gnu, native and gdbserver.
+
+ Change-Id: I4d9d74052c696b72d28cb1c77b697b911725c8d3
+
+2021-09-24 Pedro Alves <pedro@palves.net>
+
+ Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()'
+ We currently have one FAIL while running "make check-perf":
+
+ PerfTest::assemble, run ...
+ python Disassemble().run()
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run
+ self.warm_up()
+ File "<string>", line 25, in warm_up
+ gdb.error: No symbol "ada_evaluate_subexp" in current context.
+ Error while executing Python code.
+ (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run()
+ ...
+
+ The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to
+ main, and then disassembles a few GDB functions. The problem is that
+ most(!) functions it is trying to disassemble are now gone...
+
+ This commit fixes the issue by simply picking some other functions to
+ disassemble.
+
+ It would perhaps be better to come up with some test program to
+ disassemble, one that would stay the same throughout the years,
+ instead of disassembling GDB itself. I don't know why that wasn't
+ done to begin with. I'll have to leave that for another rainy day,
+ though.
+
+ gdb/testsuite/
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ * gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble
+ evaluate_subexp_do_call instead of ada_evaluate_subexp.
+ (Disassemble::warm_up): Disassemble "captured_main",
+ "run_inferior_call" and "update_global_location_list" instead of
+ "evaluate_subexp_standard" and "c_parse_internal".
+
+ Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df
+
+2021-09-24 Pedro Alves <pedro@palves.net>
+
+ Fix all PATH problems in testsuite/gdb.perf/
+ Currently "make check-perf" triggers ~40 PATH messages in gdb.sum:
+
+ ...
+ PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+ PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+ ...
+
+ This commit fixes them. E.g. before/after gdb.sum diff:
+
+ -PASS: gdb.perf/backtrace.exp: python import os, sys
+ -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+ -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+ -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+ -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+ +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys
+ +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib"))
+ +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ())
+
+ gdb/testsuite/
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ * lib/perftest.exp (PerfTest::_setup_perftest): Use
+ with_test_prefix. Add explicit test names to python invocations,
+ with "$srcdir" not expanded.
+
+ Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4
+
+2021-09-24 Pedro Alves <pedro@palves.net>
+
+ Fix all DUPLICATE problems in testsuite/gdb.perf/
+ Currently running "make check-perf" shows:
+
+ ...
+ # of duplicate test names 6008
+ ...
+
+ All those duplicate test names come from gdb.perf/skip-command.exp.
+ This commit fixes them, using with_test_prefix.
+
+ gdb/testsuite/
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ * gdb.perf/skip-command.exp (run_skip_bench): Wrap each for
+ iteration in with_test_prefix.
+
+ Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b
+
+2021-09-24 Tom Tromey <tromey@adacore.com>
+
+ Fix handling of DW_AT_data_bit_offset
+ A newer version of GCC will now emit member locations using just
+ DW_AT_data_bit_offset, like:
+
+ <3><14fe>: Abbrev Number: 1 (DW_TAG_member)
+ <14ff> DW_AT_name : (indirect string, offset: 0x215e): nb_bytes
+ <1503> DW_AT_decl_file : 1
+ <1503> DW_AT_decl_line : 10
+ <1504> DW_AT_decl_column : 7
+ <1505> DW_AT_type : <0x150b>
+ <1509> DW_AT_bit_size : 31
+ <150a> DW_AT_data_bit_offset: 64
+
+ whereas earlier versions would emit something like:
+
+ <3><164f>: Abbrev Number: 7 (DW_TAG_member)
+ <1650> DW_AT_name : (indirect string, offset: 0x218d): nb_bytes
+ <1654> DW_AT_decl_file : 1
+ <1655> DW_AT_decl_line : 10
+ <1656> DW_AT_decl_column : 7
+ <1657> DW_AT_type : <0x165f>
+ <165b> DW_AT_byte_size : 4
+ <165c> DW_AT_bit_size : 31
+ <165d> DW_AT_bit_offset : 1
+ <165e> DW_AT_data_member_location: 8
+
+ That is, DW_AT_data_member_location is not emitted any more. This is
+ a change due to the switch to DWARF 5 by default.
+
+ This change pointed out an existing bug in gdb, namely that the
+ attr_to_dynamic_prop depends on the presence of
+ DW_AT_data_member_location. This patch moves the handling of
+ DW_AT_data_bit_offset into handle_data_member_location, and updates
+ attr_to_dynamic_prop to handle this new case.
+
+ A new test case is included. This test fails with GCC 11, but passes
+ with an earlier version of GCC.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Don't leave gdb instance running after function_range
+ A typical dwarf assembly test-case start like this:
+ ...
+ standard_testfile .c -debug.S
+
+ set asm_file [standard_output_file $srcfile2]
+ Dwarf::assemble $asm_file {
+ ...
+ }
+
+ if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list $srcfile $asm_file] {nodebug}] } {
+ return -1
+ }
+ ...
+
+ When accidentally using build_for_executable instead of
+ prepare_for_testing (or intentionally using it but forgetting to add
+ clean_restart $binfile or some such) the mistake may not be caught, because
+ another gdb instance is still running, and we may silently end up testing
+ compiler-generated DWARF.
+
+ This can be caused by something relatively obvious, like an earlier
+ prepare_for_testing or clean_restart, but also by something more obscure like
+ function_range, which may even be triggered by dwarf assembly like this:
+ ...
+ {MACRO_AT_func {main}}
+ ...
+
+ Fix this by calling gdb_exit at the end of function_range.
+
+ Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a
+ get_sizeof call used the gdb instance left lingering by function_range.
+
+ [ A better and more complete fix would add a new proc get_exec_info, that would
+ be called at the start of the dwarf assembly body:
+ ...
+ Dwarf::assemble $asm_file {
+ get_exec_info {main foo} {int void*}
+ ...
+ that would:
+ - do a prepare_for_testing with $srcfile (roughtly equivalent to what
+ MACRO_AT_func does,
+ - call function_range for all functions main and foo, without starting a
+ new gdb instance
+ - set corresponding variables at the call-site: main_start, main_len,
+ main_end, foo_start, foo_len, foo_end.
+ - get size for types int and void*
+ - set corresponding variables at the call-site: int_size, void_ptr_size.
+ - do a gdb_exit. ]
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use pie instead of -fpie/-pie
+ I noticed two test-cases where -fpie is used. Using the canonical pie option
+ will usually get one -fPIE instead.
+
+ That choice is justified here in gdb_compile:
+ ...
+ # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC
+ # and SPARC, fpie can cause compile errors due to the GOT exceeding
+ # a maximum size. On other architectures the two flags are
+ # identical (see the GCC manual). Note Debian9 and Ubuntu16.10
+ # onwards default GCC to using fPIE. If you do require fpie, then
+ # it can be set using the pie_flag.
+ set flag "additional_flags=-fPIE"
+ ...
+
+ There is no indication that using -fpie rather than -fPIE is on purpose, so
+ use pie instead.
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.exp
+ Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp,
+ and in the process:
+ - fix a few typos
+ - remove unnecessary "test -r /proc/cpuinfo"
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2021-09-24 Pedro Alves <pedro@palves.net>
+
+ gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclists
+ It is currently not possible to use variables in locations lists. For
+ example, with:
+
+ diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+ index 6b4f5c8cbb8..cdbf948619f 100644
+ --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+ +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+ @@ -30,6 +30,8 @@ if {![dwarf2_support]} {
+ return 0
+ }
+
+ +set myconst 0x123456
+ +
+ # Test with 32-bit and 64-bit DWARF.
+ foreach_with_prefix is_64 {false true} {
+ if { $is_64 } {
+ @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} {
+ global func1_addr func1_len
+ global func2_addr func2_len
+ global is_64
+ + global myconst
+
+ # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists
+ # section.
+ @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} {
+ list_ {
+ # When in func1.
+ start_length $func1_addr $func1_len {
+ - DW_OP_constu 0x123456
+ + DW_OP_constu $myconst
+ DW_OP_stack_value
+ }
+
+ we get:
+
+ $ make check TESTS="*/loclists-multiple-cus.exp"
+ ...
+ gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages:
+ build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst
+ ...
+
+ That means $myconst was copied literally to the generated assembly
+ file.
+
+ This patch fixes it, by running subst on the location list body, in
+ the context of the caller. The fix is applied to both
+ Dwarf::loclists::table::list_::start_length and
+ Dwarf::loclists::table::list_::start_end.
+
+ Reported-by: Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Change-Id: I615a64431857242d9f477d5699e3732df1b31322
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.exp
+ When running test-case gdb.dwarf2/implptr-64bit.exp with target board
+ unix/-m32, I noticed:
+ ...
+ DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare
+ ...
+
+ Fix this by using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.exp
+ Fix these DUPLICATEs by using with_test_prefix:
+ ...
+ DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1
+ DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.exp
+ When doing a testrun with:
+ ...
+ $ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp)
+ ...
+ I ran into:
+ ...
+ ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp.
+ ERROR: expected integer but got "dw2-abs-hi-pc-world.c"
+ while executing
+ "incr i"
+ ...
+
+ The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to
+ gdb.dwarf2/dw2-is-stmt.exp. It's not removed by gdb_cleanup_globals because i
+ is set as global variable by runtest.exp, which does:
+ ...
+ for { set i 0 } { $i < $argc } { incr i } {
+ ...
+ at toplevel but forgets to unset the variable.
+
+ Fix this by removing '$' in front of the variable name when doing set:
+ ...
+ -set $i 0
+ +set i 0
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.exp
+ Fix this duplicate:
+ ...
+ DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable
+ ...
+ by using with_test_prefix.
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pie
+ I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of
+ the canonical pie and nopie options, which would typically also add
+ additional_flags=-fPIE respectively additional_flags=-fno-pie.
+
+ There is no indication that this is on purpose, so replace these with pie and
+ nopie.
+
+ Tested on x86_64-linux.
+
+2021-09-24 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp
+ When interpreting the testsuite results, it's often relevant what kind of
+ machine the testsuite ran on. On a local machine one can just do
+ /proc/cpuinfo, but in case of running tests using a remote system
+ that distributes test runs to other remote systems that are not directly
+ accessible, that's not possible.
+
+ Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a
+ and uname -a.
+
+ We could do this at the start of each test run, by putting it into unix.exp
+ or some such. However, this might be too verbose, so we choose to put it into
+ its own test-case, such that it get triggered in a full testrun, but not when
+ running one or a subset of tests.
+
+ We put the test-case into the gdb.testsuite directory, which is currently the
+ only place in the testsuite where we do not test gdb. [ Though perhaps this
+ could be put into a new gdb.info directory, since the test-case doesn't
+ actually test the testsuite. ]
+
+ Tested on x86_64-linux.
+
+2021-09-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-23 Tom Tromey <tom@tromey.com>
+
+ Change pointer_type to a method of struct type
+ I noticed that pointer_type is declared in language.h and defined in
+ language.c. However, it really has to do with types, so it should
+ have been in gdbtypes.h all along.
+
+ This patch changes it to be a method on struct type. And, I went
+ through uses of TYPE_IS_REFERENCE and updated many spots to use the
+ new method as well. (I didn't update ones that were in arch-specific
+ code, as I couldn't readily test that.)
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Support -fPIE/-fno-PIE/-pie/-no-pie in gdb_compile_rust
+ When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I
+ run into:
+ ...
+ builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \
+ -g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M
+ error: Unrecognized option: 'f'^M
+ ^M
+ compiler exited with status 1
+ ...
+
+ The problem is that -fPIE and -fpie are gcc options, but for rust we use
+ rustc, which has different compilation options.
+
+ Fix this by translating the gcc options to rustc options in gdb_compile_rust,
+ similar to how that is done for ada in target_compile_ada_from_dir.
+
+ Likewise for unix/-fno-PIE/-no-pie.
+
+ Tested on x86_64-linux, with:
+ - native
+ - unix/-fPIE/-pie
+ - unix/-fno-PIE/-no-pie
+ specifically, on openSUSE Leap 15.2 both with package gcc-PIE:
+ - installed (making gcc default to PIE)
+ - uninstalled (making gcc default to non-PIE).
+ and rustc 1.52.1.
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use pie instead of -fPIE -pie
+ Replace {additional_flags=-fPIE ldflags=-pie} with {pie}.
+
+ This makes sure that the test-cases properly error out when using target board
+ unix/-fno-PIE/-no-pie.
+
+ Tested on x86_64-linux.
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix probe test in gdb.base/break-interp.exp
+ When running test-case gdb.base/break-interp.exp on ubuntu 18.04.5, we have:
+ ...
+ (gdb) bt^M
+ #0 0x00007eff7ad5ae12 in ?? () from break-interp-LDprelinkNOdebugNO^M
+ #1 0x00007eff7ad71f50 in ?? () from break-interp-LDprelinkNOdebugNO^M
+ #2 0x00007eff7ad59128 in ?? () from break-interp-LDprelinkNOdebugNO^M
+ #3 0x00007eff7ad58098 in ?? () from break-interp-LDprelinkNOdebugNO^M
+ #4 0x0000000000000002 in ?? ()^M
+ #5 0x00007fff505d7a32 in ?? ()^M
+ #6 0x00007fff505d7a94 in ?? ()^M
+ #7 0x0000000000000000 in ?? ()^M
+ (gdb) FAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: \
+ first backtrace: dl bt
+ ...
+
+ Using the backtrace, the test-case tries to establish that we're stopped in
+ dl_main.
+
+ However, the backtrace only shows an address, because:
+ - the dynamic linker contains no minimal symbols and no debug info, and
+ - gdb is build without --with-separate-debug-dir so it can't find the
+ corresponding .debug file, which does contain the mimimal symbols and
+ debug info.
+
+ As in "[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp",
+ fix this by doing info probes and grepping for the address.
+
+ Tested on x86_64-linux.
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp
+ When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
+ ...
+ (gdb) run^M
+ Starting program: break-probes^M
+ Stopped due to shared library event (no libraries added or removed)^M
+ (gdb) bt^M
+ #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #4 0x0000000000000001 in ?? ()^M
+ #5 0x00007fffffffdaac in ?? ()^M
+ #6 0x0000000000000000 in ?? ()^M
+ (gdb) UNSUPPORTED: gdb.base/break-probes.exp: probes not present on this system
+ ...
+
+ Using the backtrace, the test-case tries to establish that we're stopped in
+ dl_main, which is used as proof that we're using probes.
+
+ However, the backtrace only shows an address, because:
+ - the dynamic linker contains no minimal symbols and no debug info, and
+ - gdb is build without --with-separate-debug-dir so it can't find the
+ corresponding .debug file, which does contain the mimimal symbols and
+ debug info.
+
+ Fix this by instead printing the pc and grepping for the value in the
+ info probes output:
+ ...
+ (gdb) p /x $pc^M
+ $1 = 0x7ffff7dd6e12^M
+ (gdb) info probes^M
+ Type Provider Name Where Object ^M
+ ...
+ stap rtld init_start 0x00007ffff7dd6e12 /lib64/ld-linux-x86-64.so.2 ^M
+ ...
+ (gdb)
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle failing probe detection in gdb.base/break-probes.exp
+ When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
+ ...
+ (gdb) bt^M
+ #0 0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #1 0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #2 0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #3 0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+ #4 0x0000000000000001 in ?? ()^M
+ #5 0x00007fffffffdaac in ?? ()^M
+ #6 0x0000000000000000 in ?? ()^M
+ (gdb) FAIL: gdb.base/break-probes.exp: ensure using probes
+ ...
+
+ The test-case intends to emit an UNTESTED in this case, but fails to do so
+ because it tries to do it in a regexp clause in a gdb_test_multiple, which
+ doesn't trigger. Instead, a default clause triggers which produces the FAIL.
+
+ Also the use of UNTESTED is not appropriate, and we should use UNSUPPORTED
+ instead.
+
+ Fix this by silencing the FAIL, and emitting an UNSUPPORTED after the
+ gdb_test_multiple:
+ ...
+ if { ! $using_probes } {
+ + unsupported "probes not present on this system"
+ return -1
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use early-out style in gdb.base/break-probes.exp
+ Reduce indentation and improve readability in test-case
+ gdb.base/break-probes.exp by replacing:
+ ...
+ if { <cond> } {
+ <lots-of-code>
+ }
+ ...
+ with:
+ ...
+ if { ! <cond> } {
+ return -1
+ }
+ <lots-of-code>
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-23 Pedro Alves <pedro@palves.net>
+
+ Test that frame info/IDs are stable/consistent
+ This adds a testcase that tests that the unwinder produces consistent
+ frame info and frame IDs by making sure that "info frame" shows the
+ same result when stopped at a function (level == 0), compared to when
+ we find the same frame in the stack at a level > 0.
+
+ E.g., on x86-64, right after running to main, we see:
+
+ (gdb) info frame
+ Stack level 0, frame at 0x7fffffffd340:
+ rip = 0x555555555168 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
+ source language c.
+ Arglist at 0x7fffffffd330, args:
+ Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
+ Saved registers:
+ rbp at 0x7fffffffd330, rip at 0x7fffffffd338
+ (gdb)
+
+ and then after continuing to a function called by main, and selecting
+ the "main" frame again, we see:
+
+ (gdb) info frame
+ Stack level 3, frame at 0x7fffffffd340:
+ rip = 0x555555555172 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
+ caller of frame at 0x7fffffffd330
+ source language c.
+ Arglist at 0x7fffffffd330, args:
+ Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
+ Saved registers:
+ rbp at 0x7fffffffd330, rip at 0x7fffffffd338
+ (gdb)
+
+ The only differences should be in the stack level, the 'rip = '
+ address, and the presence of the "caller of frame at" info. All the
+ rest should be the same. If it isn't, it probably means that the
+ frame base, the frame ID, etc. aren't stable & consistent.
+
+ The testcase exercises both the DWARF and the heuristic unwinders,
+ using "maint set dwarf unwinder on/off".
+
+ Tested on {x86-64 -m64, x86-64 -m32, Aarch64, Power8} GNU/Linux.
+
+ Change-Id: I795001c82cc70d543d197415e3f80ce5dc7f3452
+
+2021-09-23 Tom Tromey <tromey@adacore.com>
+
+ Change get_ada_task_ptid parameter type
+ get_ada_task_ptid currently takes a 'long' as its 'thread' parameter
+ type. However, on some platforms this is actually a pointer, and
+ using 'long' can sometimes end up with the value being sign-extended.
+ This sign extension can cause problems later, if the tid is then later
+ used as an address again.
+
+ This patch changes the parameter type to ULONGEST and updates all the
+ uses. This approach preserves sign extension on the targets where it
+ is apparently intended, while avoiding it on others.
+
+ Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-09-23 Tom Tromey <tromey@adacore.com>
+
+ Change ptid_t::tid to ULONGEST
+ The ptid_t 'tid' member is normally used as an address in gdb -- both
+ bsd-uthread and ravenscar-thread use it this way. However, because
+ the type is 'long', this can cause problems with sign extension.
+
+ This patch changes the type to ULONGEST to ensure that sign extension
+ does not occur.
+
+2021-09-23 Tom Tromey <tromey@adacore.com>
+
+ Remove defaulted 'tid' parameter to ptid_t constructor
+ I wanted to find, and potentially modify, all the spots where the
+ 'tid' parameter to the ptid_t constructor was used. So, I temporarily
+ removed this parameter and then rebuilt.
+
+ In order to make it simpler to search through the "real" (nonzero)
+ uses of this parameter, something I knew I'd have to do multiple
+ times, I removed any ", 0" from constructor calls.
+
+ Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-09-23 Tom Tromey <tom@tromey.com>
+
+ Style the "XXX" text in ptype/o
+ This patch changes gdb to use the 'highlight' style on the "XXX" text
+ in the output of ptype/o.
+
+2021-09-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.python/py-events.exp
+ With test-case gdb.python/py-events.exp on ubuntu 18.04.5 we run into:
+ ...
+ (gdb) info threads^M
+ Id Target Id Frame ^M
+ * 1 Thread 0x7ffff7fc3740 (LWP 31467) "py-events" do_nothing () at \
+ src/gdb/testsuite/gdb.python/py-events-shlib.c:19^M
+ (gdb) FAIL: gdb.python/py-events.exp: get current thread
+ ...
+
+ The info thread commands uses "Thread" instead of "process" because
+ libpthread is already loaded:
+ ...
+ new objfile name: /lib/x86_64-linux-gnu/libdl.so.2^M
+ [Thread debugging using libthread_db enabled]^M
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
+ event type: new_objfile^M
+ new objfile name: /lib/x86_64-linux-gnu/libpthread.so.0^M
+ ...
+ and consequently thread_db_target::pid_to_str is used.
+
+ Fix this by parsing the "Thread" expression.
+
+ Tested on x86_64-linux.
+
+2021-09-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Add maint selftest -verbose option
+ The print_one_insn selftest in gdb/disasm-selftests.c contains:
+ ...
+ /* If you want to see the disassembled instruction printed to gdb_stdout,
+ set verbose to true. */
+ static const bool verbose = false;
+ ...
+
+ Make this parameter available in the maint selftest command using a new option
+ -verbose, such that we can do:
+ ...
+ (gdb) maint selftest -verbose print_one_insn
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-22 Alan Modra <amodra@gmail.com>
+
+ dwarf2 sub-section test
+ This is a testcase for the bug fixed by commit 5b4846283c3d. When
+ running the testcase on ia64 targets I found timeouts along with lots
+ of memory being consumed, due to ia64 gas not tracking text
+ sub-sections. Trying to add nops for ".nop 16" in ".text 1" resulting
+ in them being added to subsegment 0, with no increase to subsegment 1
+ size. This patch also fixes that problem.
+
+ Note that the testcase fails on ft32-elf, mn10200-elf, score-elf,
+ tic5x-elf, and xtensa-elf. The first two are relocation errors, the
+ last three appear to be the .nop directive failing to emit the right
+ number of nops. I didn't XFAIL any of them.
+
+ * config/tc-ia64.c (md): Add last_text_subseg.
+ (ia64_flush_insns, dot_endp): Use last_text_subseg.
+ (ia64_frob_label, md_assemble): Set last_text_subseg.
+ * testsuite/gas/elf/dwarf2-21.d,
+ * testsuite/gas/elf/dwarf2-21.s: New test.
+ * testsuite/gas/elf/elf.exp: Run it.
+
+2021-09-22 Alan Modra <amodra@gmail.com>
+
+ Fix x86 "FAIL: TLS -fno-pic -shared"
+ Fix a typo in commit 5d0869d9872a
+
+ * testsuite/ld-i386/tlsnopic.rd: Typo fix.
+
+2021-09-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-21 Nick Clifton <nickc@redhat.com>
+
+ Change the linker's heuristic for computing the entry point for binaries so that shared libraries default to an entry point of 0.
+ * ldlang.c (lang_end): When computing the entry point, only
+ try the start address of the entry section when creating an
+ executable.
+ * ld.texi (Entry point): Update description of heuristic used to
+ choose the entry point.
+ testsuite/ld-alpha/tlspic.rd: Update expected entry point address.
+ testsuite/ld-arm/tls-gdesc-got.d: Likewise.
+ testsuite/ld-i386/tlsnopic.rd: Likewise.
+ testsuite/ld-ia64/tlspic.rd: Likewise.
+ testsuite/ld-sparc/gotop32.rd: Likewise.
+ testsuite/ld-sparc/gotop64.rd: Likewise.
+ testsuite/ld-sparc/tlssunnopic32.rd: Likewise.
+ testsuite/ld-sparc/tlssunnopic64.rd: Likewise.
+ testsuite/ld-sparc/tlssunpic32.rd: Likewise.
+ testsuite/ld-sparc/tlssunpic64.rd: Likewise.
+ testsuite/ld-tic6x/shlib-1.rd: Likewise.
+ testsuite/ld-tic6x/shlib-1b.rd: Likewise.
+ testsuite/ld-tic6x/shlib-1r.rd: Likewise.
+ testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
+ testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
+ testsuite/ld-x86-64/pr14207.d: Likewise.
+ testsuite/ld-x86-64/tlsdesc.rd: Likewise.
+ testsuite/ld-x86-64/tlspic.rd: Likewise.
+ testsuite/ld-x86-64/tlspic2.rd: Likewise.
+
+2021-09-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.exp
+ In test-case gdb.base/gdb-caching-proc.exp, we run all procs declared with
+ gdb_caching_proc. Some of these require a gdb instance, some not.
+
+ We could just do a clean_restart every time, but that would amount to 44 gdb
+ restarts. We try to minimize this by doing this only for the few procs that
+ need it, and hardcoding those in the test-case.
+
+ For those procs, we do a clean_restart, execute the proc, and then do a
+ gdb_exit, to make sure the gdb instance doesn't linger such that we detect
+ procs that need a gdb instance but are not listed in the test-case.
+
+ However, that doesn't work in the case of gnat_runtime_has_debug_info. This
+ proc doesn't require a gdb instance because it starts its own. But it doesn't
+ clean up the gdb instance, and since it's not listed, the test-case
+ doesn't clean up the gdb instance eiter. Consequently, the proc
+ supports_memtag (which should be listed, but isn't) uses the gdb instance
+ started by gnat_runtime_has_debug_info rather than throwing an error. Well,
+ unless gnat_runtime_has_debug_info fails before starting a gdb instance, in
+ which case we do run into the error.
+
+ Fix this by:
+ - doing gdb_exit unconditionally
+ - fixing the resulting error by adding supports_memtag in the test-case to
+ the "needing gdb instance" list
+
+ Tested on x86_64-linux.
+
+2021-09-21 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, doc: Add ieee_half and bfloat16 to list of predefined target types.
+ For some reason these two weren't added to the list when they were orginally
+ added to GDB.
+
+ gdb/doc/ChangeLog:
+ 2021-09-21 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ * gdb.texinfo (Predefined Target Types): Mention ieee_half and bfloat16.
+
+2021-09-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/interface.exp with gcc-9
+ When running test-case gdb.ada/interface.exp with gcc-9, we run into:
+ ...
+ (gdb) info locals^M
+ s = (x => 1, y => 2, w => 3, h => 4)^M
+ r = (x => 1, y => 2, w => 3, h => 4)^M
+ (gdb) FAIL: gdb.ada/interface.exp: info locals
+ ...
+
+ The failure is caused by the regexp expecting variable r followed by
+ variable s.
+
+ Fix this by allowing variable s followed by variable r as well.
+
+ Tested on x86_64-linux.
+
+2021-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/mi_prot.exp
+ When running test-case gdb.ada/mi_prot.exp with gcc 8.5.0, we run into:
+ ...
+ (gdb) ^M
+ Expecting: ^(-stack-list-arguments --no-frame-filters 1[^M
+ ]+)?(\^done,stack=.*[^M
+ ]+[(]gdb[)] ^M
+ [ ]*)
+ -stack-list-arguments --no-frame-filters 1^M
+ ^done,stack-args=[frame={level="0",args=[{name="<_object>",value="(ceiling_priority =\
+ > 97, local => 0)"},{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={le\
+ vel="1",args=[{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={level="2\
+ ",args=[]}]^M
+ (gdb) ^M
+ FAIL: gdb.ada/mi_prot.exp: -stack-list-arguments --no-frame-filters 1 (unexpected out\
+ put)
+ ...
+
+ Fix this by updating the regexp to expect "^done,stack-args=" instead of
+ "^done,stack=".
+
+ Tested on x86_64-linux.
+
+2021-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Register test for each arch separately in register_test_foreach_arch
+ In gdb/disasm-selftests.c we have:
+ ...
+ selftests::register_test_foreach_arch ("print_one_insn",
+ selftests::print_one_insn_test);
+ ...
+ and we get:
+ ...
+ $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \
+ | grep ^Running
+ Running selftest print_one_insn.
+ $
+ ...
+
+ Change the semantics register_test_foreach_arch such that a version of
+ print_one_insn is registered for each architecture, such that we have:
+ ...
+ $ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \
+ | grep ^Running
+ Running selftest print_one_insn::A6.
+ Running selftest print_one_insn::A7.
+ Running selftest print_one_insn::ARC600.
+ ...
+ $
+ ...
+
+ This makes it f.i. possible to do:
+ ...
+ $ gdb -q -batch a.out -ex "maint selftest print_one_insn::armv8.1-m.main"
+ Running selftest print_one_insn::armv8.1-m.main.
+ Self test failed: self-test failed at src/gdb/disasm-selftests.c:165
+ Ran 1 unit tests, 1 failed
+ ...
+
+ Tested on x86_64-linux with an --enable-targets=all build.
+
+2021-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Change register_test to use std::function arg
+ Change register_test to use std::function arg, such that we can do:
+ ...
+ register_test (test_name, [=] () { SELF_CHECK (...); });
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-20 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.ada/big_packed_array.exp xfail for -m32
+ With test-case gdb.ada/big_packed_array.exp and target board unix/-m32 I run
+ into:
+ ...
+ (gdb) print bad^M
+ $2 = (0 => 0 <repeats 24 times>, 160)^M
+ (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+ ...
+
+ The problem is that while the variable is an array of 196 bits (== 24.5 bytes),
+ the debug information describes it as 25 unsigned char. This is PR
+ gcc/101643, and the test-case contains an xfail for this, which catches only:
+ ...
+ (gdb) print bad^M
+ $2 = (0 => 0 <repeats 25 times>)^M
+ ...
+
+ Fix this by updating the xfail pattern.
+
+ Tested on x86_64-linux.
+
+2021-09-20 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport/gdb_proc_service.h: use decltype instead of typeof
+ Bug 28341 shows that GDB fails to compile when built with -std=c++11.
+ I don't know much about the use case, but according to the author of the
+ bug:
+
+ I encountered the scenario where CXX is set to "g++ -std=c++11" when
+ I try to compile binutils under GCC as part of the GCC 3-stage
+ compilation, which is common for building a cross-compiler.
+
+ The author of the bug suggests using __typeof__ instead of typeof. But
+ since we're using C++, we might as well use decltype, which is standard.
+ This is what this patch does.
+
+ The failure (and fix) can be observed by configuring GDB with CXX="g++
+ -std=c++11":
+
+ CXX linux-low.o
+ In file included from /home/simark/src/binutils-gdb/gdbserver/gdb_proc_service.h:22,
+ from /home/simark/src/binutils-gdb/gdbserver/linux-low.h:27,
+ from /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:20:
+ /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:177:50: error: expected constructor, destructor, or type conversion before (token
+ 177 | __attribute__((visibility ("default"))) typeof (SYM) SYM
+ | ^
+ /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:179:1: note: in expansion of macro PS_EXPORT
+ 179 | PS_EXPORT (ps_get_thread_area);
+ | ^~~~~~~~~
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28341
+ Change-Id: I84fbaae938209d8d935ca08dec9b7e6a0dd1bda0
+
+2021-09-20 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ riscv: print .2byte or .4byte before an unknown instruction encoding
+ When the RISC-V disassembler encounters an unknown instruction, it
+ currently just prints the value of the bytes, like this:
+
+ Dump of assembler code for function custom_insn:
+ 0x00010132 <+0>: addi sp,sp,-16
+ 0x00010134 <+2>: sw s0,12(sp)
+ 0x00010136 <+4>: addi s0,sp,16
+ 0x00010138 <+6>: 0x52018b
+ 0x0001013c <+10>: 0x9c45
+
+ My proposal, in this patch, is to change the behaviour to this:
+
+ Dump of assembler code for function custom_insn:
+ 0x00010132 <+0>: addi sp,sp,-16
+ 0x00010134 <+2>: sw s0,12(sp)
+ 0x00010136 <+4>: addi s0,sp,16
+ 0x00010138 <+6>: .4byte 0x52018b
+ 0x0001013c <+10>: .2byte 0x9c45
+
+ Adding the .4byte and .2byte opcodes. The benefit that I see here is
+ that in the patched version of the tools, the disassembler output can
+ be fed back into the assembler and it should assemble to the same
+ binary format. Before the patch, the disassembler output is invalid
+ assembly.
+
+ I've started a RISC-V specific test file under binutils so that I can
+ add a test for this change.
+
+ binutils/ChangeLog:
+
+ * testsuite/binutils-all/riscv/riscv.exp: New file.
+ * testsuite/binutils-all/riscv/unknown.d: New file.
+ * testsuite/binutils-all/riscv/unknown.s: New file.
+
+ opcodes/ChangeLog:
+
+ * riscv-dis.c (riscv_disassemble_insn): Print a .%dbyte opcode
+ before an unknown instruction, '%d' is replaced with the
+ instruction length.
+
+2021-09-20 Alan Modra <amodra@gmail.com>
+
+ Fix allocate_filenum last dir/file checks
+ * dwarf2dbg.c (allocate_filenum) Correct use of last_used_dir_len.
+
+2021-09-20 Alan Modra <amodra@gmail.com>
+
+ Re: PR28149, debug info with wrong file association
+ Fixes segfaults when building aarch64-linux kernel, due to only doing
+ part of the work necessary when allocating file numbers late. I'd
+ missed looping over subsegments, which resulted in some u.filename
+ entries left around and later interpreted as u.view.
+
+ PR 28149
+ * dwarf2dbg.c (purge_generated_debug): Iterate over subsegs too.
+ (dwarf2_finish): Call do_allocate_filenum for all subsegs too,
+ in a separate loop before subsegs are chained.
+
+2021-09-20 Alan Modra <amodra@gmail.com>
+
+ Move eelf_mipsel_haiki.c to ALL_64_EMULATION_SOURCES
+ --enable-targets=all on a 32-bit host results in a link failure with
+ undefined references due to elfxx-mips.c not being compiled. This
+ patch fixes that by putting eelf_mipsel_haiki.c in the correct
+ EMULATION_SOURCES Makefile variable. I've also added a bunch of
+ missing file dependencies and sorted a few things so that it's easier
+ to verify dependencies are present.
+
+ * Makfile.am: Add missing haiku dependencies, sort.
+ (ALL_EMULATION_SOURCES): Sort. Move eelf_mipsel_haiku.c to..
+ (ALL_64_EMULATION_SOURCES): ..here. Sort.
+ * Makfile.in: Regenerate.
+
+2021-09-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-19 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Don't set version info on unversioned symbols
+ Don't set version info on unversioned symbols when seeing a hidden
+ versioned symbol after an unversioned definition and the default
+ versioned symbol.
+
+ bfd/
+
+ PR ld/28348
+ * elflink.c (elf_link_add_object_symbols): Don't set version info
+ on unversioned symbols.
+
+ ld/
+
+ PR ld/28348
+ * testsuite/ld-elf/pr28348.rd: New file.
+ * testsuite/ld-elf/pr28348.t: Likewise.
+ * testsuite/ld-elf/pr28348a.c: Likewise.
+ * testsuite/ld-elf/pr28348b.c: Likewise.
+ * testsuite/ld-elf/pr28348c.c: Likewise.
+ * testsuite/ld-elf/shared.exp: Run PR ld/28348 tests.
+
+2021-09-19 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: manual: update @inforef to @xref
+ The @inforef command is deprecated, and @xref does the samething.
+ Also had to update the text capitalization to match current manual.
+ Verified that info & HTML links work.
+
+2021-09-19 Weimin Pan <weimin.pan@oracle.com>
+
+ CTF: multi-CU and archive support
+ Now gdb is capable of debugging executable, which consists of multiple
+ compilation units (CUs) with the CTF debug info. An executable could
+ potentially have one or more archives, which, in CTF context, contain
+ conflicting types.
+
+ all changes were made in ctfread.c in which elfctf_build_psymtabs was
+ modified to handle archives, via the ctf archive iterator and its callback
+ build_ctf_archive_member and scan_partial_symbols was modified to scan
+ archives, which are treated as subfiles, to build the psymtabs.
+
+ Also changes were made to handle CTF's data object section and function
+ info section which now share the same format of their contents - an array
+ of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by
+ ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries,
+ which is called by add_stt_obj and add_stt_func when setting up psymtabs
+ and full symtab, respectively.
+
+2021-09-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.server/server-kill.exp with -m32
+ When running test-case gdb.server/server-kill.exp with target board unix/-m32,
+ I run into:
+ ...
+ 0xf7fd6b20 in _start () from /lib/ld-linux.so.2^M
+ (gdb) Executing on target: kill -9 13082 (timeout = 300)
+ builtin_spawn -ignore SIGHUP kill -9 13082^M
+ bt^M
+ (gdb) FAIL: gdb.server/server-kill.exp: kill_pid_of=server: test_unwind_syms: bt
+ ...
+
+ The test-case expects the backtrace command to trigger remote communication,
+ which then should result in a "Remote connection closed" or similar.
+
+ However, no remote communication is triggered, because we hit the "Check that
+ this frame is unwindable" case in get_prev_frame_always_1.
+
+ We don't hit this problem in the kill_pid_of=inferior case, because there we
+ run to main before doing the backtrace.
+
+ Fix this by doing the same in the kill_pid_of=server case.
+
+ Tested on x86_64-linux.
+
+2021-09-18 Tom de Vries <tdevries@suse.de>
+
+ [gdb/ada] Handle artificial local symbols
+ With current master and gcc 7.5.0/8.5.0, we have this timeout:
+ ...
+ (gdb) print s^M
+ Multiple matches for s^M
+ [0] cancel^M
+ [1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M
+ [2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M
+ > FAIL: gdb.ada/interface.exp: print s (timeout)
+ ...
+
+ [ The FAIL doesn't reproduce with gcc 9.3.1. This difference in
+ behaviour bisects to gcc commit d70ba0c10de.
+
+ The FAIL with earlier gcc bisects to gdb commit ba8694b650b. ]
+
+ The FAIL is caused by gcc generating this debug info describing a named
+ artificial variable:
+ ...
+ <2><1204>: Abbrev Number: 31 (DW_TAG_variable)
+ <1205> DW_AT_name : s.14
+ <1209> DW_AT_type : <0x1213>
+ <120d> DW_AT_artificial : 1
+ <120d> DW_AT_location : 5 byte block: 91 e0 7d 23 18 \
+ (DW_OP_fbreg: -288; DW_OP_plus_uconst: 24)
+ ...
+
+ An easy way to fix this would be to simply not put named artificial variables
+ into the symbol table. However, that causes regressions for Ada. It relies
+ on being able to get the value from such variables, using a named reference.
+
+ Fix this instead by marking the symbol as artificial, and:
+ - ignoring such symbols in ada_resolve_variable, which fixes the FAIL
+ - ignoring such ada symbols in do_print_variable_and_value, which prevents
+ them from showing up in "info locals"
+
+ Note that a fix for the latter was submitted here (
+ https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and
+ this patch borrows from it.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Joel Brobecker <brobecker@adacore.com>
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180
+
+2021-09-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ PR28149 part 2, purge generated line info
+ Mixing compiler generated line info with gas generated line info is
+ generally just confusing. Also .loc directives with non-zero view
+ fields might reference a previous .loc. It becomes a little more
+ tricky to locate that previous .loc if there might be gas generated
+ line info present too. Mind you, we turn off gas generation of line
+ info on seeing compiler generated line info, so any reference back
+ won't hit gas generated line info. At least, if the view info is
+ sane. Unfortunately, gas needs to handle mangled source.
+
+ PR 28149
+ * dwarf2dbg.c (purge_generated_debug): New function.
+ (dwarf2_directive_filename): Call the above.
+ (out_debug_line): Don't segfault after purging.
+ * testsuite/gas/i386/dwarf2-line-4.d: Update expected output.
+ * testsuite/gas/i386/dwarf4-line-1.d: Likewise.
+ * testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+ * testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ PR28149, debug info with wrong file association
+ gcc-11 and gcc-12 pass -gdwarf-5 to gas, in order to prime gas for
+ DWARF 5 level debug info. Unfortunately it seems there are cases
+ where the compiler does not emit a .file or .loc dwarf debug directive
+ before any machine instructions. (Note that the .file directive
+ typically emitted as the first line of assembly output doesn't count as
+ a dwarf debug directive. The dwarf .file has a file number before the
+ file name string.)
+
+ This patch delays allocation of file numbers for gas generated line
+ debug info until the end of assembly, thus avoiding any clashes with
+ compiler generated file numbers. Two fixes for test case source are
+ necessary; A .loc can't use a file number that hasn't already been
+ specified with .file.
+
+ A followup patch will remove all the gas generated line info on
+ seeing a .file directive.
+
+ PR 28149
+ * dwarf2dbg.c (num_of_auto_assigned): Delete.
+ (current): Update initialisation.
+ (set_or_check_view): Replace all accesses to view with u.view.
+ (dwarf2_consume_line_info): Likewise.
+ (dwarf2_directive_loc): Likewise. Assert that we aren't generating
+ line info.
+ (dwarf2_gen_line_info_1): Don't call set_or_check_view on
+ gas generated line entries.
+ (dwarf2_gen_line_info): Set and track filenames for gas generated
+ line entries. Simplify generation of labels.
+ (get_directory_table_entry): Use filename_cmp when comparing dirs.
+ (do_allocate_filenum): New function.
+ (dwarf2_where): Set u.filename and filenum to -1 for gas generated
+ line entries.
+ (dwarf2_directive_filename): Remove num_of_auto_assigned handling.
+ (process_entries): Update view field access. Call
+ do_allocate_filenum.
+ * dwarf2dbg.h (struct dwarf2_line_info): Add filename field in
+ union aliasing view.
+ * testsuite/gas/i386/dwarf2-line-3.s: Add .file directive.
+ * testsuite/gas/i386/dwarf2-line-4.s: Likewise.
+ * testsuite/gas/i386/dwarf2-line-4.d: Update expected output.
+ * testsuite/gas/i386/dwarf4-line-1.d: Likewise.
+ * testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+ * testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64 support for sym+addend GOT entries
+ Pass addends to all the GOT handling functions, plus remove some
+ extraneous asserts.
+
+ PR 28192
+ * powerpc.cc (Output_data_got_powerpc): Add addend parameter to
+ all methods creating got entries.
+ (Target_powerpc::Scan::local): Pass reloc addend to got handling
+ functions, and when creating dynamic got relocations.
+ (Target_powerpc::Scan::global): Likewise.
+ (Target_powerpc::Relocate::relocate): Likewise. Remove extraneous
+ assertions.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Got_entry::write addends
+ This takes care of writing out GOT entries with addends. The local
+ symbol case was already largely handled, except for passing the addend
+ to tls_offset_for_local which might need the addend in a
+ local_got_offset call. That's needed also in tls_offset_for_global.
+
+ I'm assuming here that GOT entries for function symbols won't ever
+ have addends, and in particular that a GOT entry referencing PLT call
+ stub code won't want an offset into the code.
+
+ PR 28192
+ * output.cc (Output_data_got::Got_entry::write): Include addend
+ in global symbol value. Pass addend to tls_offset_for_*.
+ * powerpc.cc (Target_powerpc::do_tls_offset_for_local): Handle addend.
+ (Target_powerpc::do_tls_offset_for_global): Likewise.
+ * s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
+ (Target_s390::do_tls_offset_for_global): Likewise.
+ * target.h (Target::tls_offset_for_local): Add addend param.
+ (Target::tls_offset_for_global): Likewise.
+ (Target::do_tls_offset_for_local): Likewise.
+ (Target::do_tls_offset_for_global): Likewise.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Output_data_got create entry method addends
+ This patch makes all the Output_data_got methods that create new
+ entries accept an optional addend.
+
+ PR 28192
+ * output.h (Output_data_got::add_global): Add optional addend
+ parameter. Update comment. Delete overload without addend.
+ (Output_data_got::add_global_plt): Likewise.
+ (Output_data_got::add_global_tls): Likewise.
+ (Output_data_got::add_global_with_rel): Likewise.
+ (Output_data_got::add_global_pair_with_rel): Likewise.
+ (Output_data_got::add_local_plt): Likewise.
+ (Output_data_got::add_local_tls): Likewise.
+ (Output_data_got::add_local_tls_pair): Likewise.
+ (Output_data_got::reserve_local): Likewise.
+ (Output_data_got::reserve_global): Likewise.
+ (Output_data_got::Got_entry): Include addend in global sym
+ constructor. Delete local sym constructor without addend.
+ * output.cc (Output_data_got::add_global): Add addend param,
+ pass to got handling methods.
+ (Output_data_got::add_global_plt): Likewise.
+ (Output_data_got::add_global_with_rel): Likewise.
+ (Output_data_got::add_global_pair_with_rel): Likewise.
+ (Output_data_got::add_local_plt): Likewise.
+ (Output_data_got::add_local_tls_pair): Likewise.
+ (Output_data_got::reserve_local): Likewise.
+ (Output_data_got::reserve_global): Likewise.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Output_data_got tidy
+ Some Output_data_got methods already have support for addends, but
+ were implemented as separate methods. This removes unnecessary code
+ duplication.
+
+ Relobj::local_has_got_offset and others there get a similar treatment.
+ Comments are removed since it should be obvious without a comment, and
+ the existing comments are not precisely what the code does. For
+ example, a local_has_got_offset call without an addend does not return
+ whether the local symbol has *a* GOT offset of type GOT_TYPE, it
+ returns whether there is a GOT entry of type GOT_TYPE for the symbol
+ with addend of zero.
+
+ PR 28192
+ * output.h (Output_data_got::add_local): Make addend optional.
+ (Output_data_got::add_local_with_rel): Likewise.
+ (Output_data_got::add_local_pair_with_rel): Likewise.
+ * output.cc (Output_data_got::add_local): Delete overload
+ without addend.
+ (Output_data_got::add_local_with_rel): Likewise.
+ (Output_data_got::add_local_pair_with_rel): Likewise.
+ * object.h (Relobj::local_has_got_offset): Make addend optional.
+ Delete overload without addend later. Update comment.
+ (Relobj::local_got_offset): Likewise.
+ (Relobj::set_local_got_offset): Likewise.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Remove addend from Local_got_entry_key
+ This patch removes the addend from Local_got_entry_key, which is
+ unnecessary now that Got_offset_list has an addend. Note that it
+ might be advantageous to keep the addend in Local_got_entry_key when
+ linking objects containing a large number of section_sym+addend@got
+ relocations. I opted to save some memory by removing the field but
+ left the class there in case we might need to restore {sym,addend}
+ lookup. That's also why this change is split out from the
+ Got_offset_list change.
+
+ PR 28192
+ * object.h (Local_got_entry_key): Delete addend_ field.
+ Adjust constructor and methods to suit.
+ * object.cc (Sized_relobj::do_for_all_local_got_entries):
+ Update key.
+
+2021-09-17 Alan Modra <amodra@gmail.com>
+
+ [GOLD] Got_offset_list: addend field
+ This is the first in a series of patches aimed at supporting GOT
+ entries against symbol plus addend generally for PowerPC64 rather than
+ just section symbol plus addend as gold has currently.
+
+ This patch adds an addend field to Got_offset_list, so that both local
+ and global symbols can have GOT entries with addend.
+
+ PR 28192
+ * object.h (Got_offset_list): Add addend_ field, init in both
+ constructors. Adjust all accessors to suit.
+ (Sized_relobj::do_local_has_got_offset): Adjust to suit.
+ (Sized_relobj::do_local_got_offset): Likewise.
+ (Sized_relobj::do_set_local_got_offset): Likewise.
+ * symtab.h (Symbol::has_got_offset): Add optional addend param.
+ (Symbol::got_offset, Symbol::set_got_offset): Likewise.
+ * incremental.cc (Local_got_offset_visitor::visit): Add unused
+ uint64_t parameter with FIXME.
+ (Global_got_offset_visitor::visit): Add unused uint64_t parameter.
+
+2021-09-17 Henry Castro <hcvcastro@gmail.com>
+
+ Fix segfault when running ia16-elf-gdb
+ "A problem internal to GDB has been detected,
+ further debugging may prove unreliable."
+
+ Segmentation fault
+
+2021-09-17 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Merged extension string tables and their version tables into one.
+ There are two main reasons for this patch,
+
+ * In the past we had two extension tables, one is used to record all
+ supported extensions in bfd/elfxx-riscv.c, another is used to get the
+ default extension versions in gas/config/tc-riscv.c. It is hard to
+ maintain lots of tables in different files, but in fact we can merge
+ them into just one table. Therefore, we now define many riscv_supported_std*
+ tables, which record names and versions for all supported extensions.
+ We not only use these tables to initialize the riscv_ext_order, but
+ also use them to get the default versions of extensions, and decide if
+ the extensions should be enbaled by default.
+
+ * We add a new filed `default_enable' for the riscv_supported_std* tables,
+ to decide if the extension should be enabled by default. For now if the
+ `default_enable' field of the extension is set to EXT_DEFAULT, then we
+ should enable the extension when the -march and elf architecture attributes
+ are not set. In the future, I suppose the `default_enable' can be set
+ to lots of EXT_<VENDOR>, each vendor can decide to open which extensions,
+ when the target triple of vendor is chosen.
+
+ The elf/linux regression tests of riscv-gnu-toolchain are passed.
+
+ bfd/
+ * elfnn-riscv.c (cpu-riscv.h): Removed sine it is included in
+ bfd/elfxx-riscv.h.
+ (riscv_merge_std_ext): Updated since the field of rpe is changed.
+ * elfxx-riscv.c (cpu-riscv.h): Removed.
+ (riscv_implicit_subsets): Added implicit extensions for g.
+ (struct riscv_supported_ext): Used to be riscv_ext_version. Moved
+ from gas/config/tc-riscv.c, and added new field `default_enable' to
+ decide if the extension should be enabled by default.
+ (EXT_DEFAULT): Defined for `default_enable' field.
+ (riscv_supported_std_ext): It used to return the supported standard
+ architecture string, but now we move ext_version_table from
+ gas/config/tc-riscv.c to here, and rename it to riscv_supported_std_ext.
+ Currently we not only use the table to initialize riscv_ext_order, but
+ also get the default versions of extensions, and decide if the extensions
+ should be enbaled by default.
+ (riscv_supported_std_z_ext): Likewise, but is used for z* extensions.
+ (riscv_supported_std_s_ext): Likewise, but is used for s* extensions.
+ (riscv_supported_std_h_ext): Likewise, but is used for h* extensions.
+ (riscv_supported_std_zxm_ext): Likewise, but is used for zxm* extensions.
+ (riscv_all_supported_ext): Includes all supported extension tables.
+ (riscv_known_prefixed_ext): Updated.
+ (riscv_valid_prefixed_ext): Updated.
+ (riscv_init_ext_order): Init the riscv_ext_order table according to
+ riscv_supported_std_ext.
+ (riscv_get_default_ext_version): Moved from gas/config/tc-riscv.c.
+ Get the versions of extensions from riscv_supported_std* tables.
+ (riscv_parse_add_subset): Updated.
+ (riscv_parse_std_ext): Updated.
+ (riscv_set_default_arch): Set the default subset list according to
+ the default_enable field of riscv_supported_*ext tables.
+ (riscv_parse_subset): If the input ARCH is NULL, then we call
+ riscv_set_default_arch to set the default subset list.
+ * elfxx-riscv.h (cpu-riscv.h): Included.
+ (riscv_parse_subset_t): Removed get_default_version field, and added
+ isa_spec field to replace it.
+ (extern riscv_supported_std_ext): Removed.
+ gas/
+ * (bfd/cpu-riscv.h): Removed.
+ (struct riscv_ext_version): Renamed and moved to bfd/elfxx-riscv.c.
+ (ext_version_table): Likewise.
+ (riscv_get_default_ext_version): Likewise.
+ (ext_version_hash): Removed.
+ (init_ext_version_hash): Removed.
+ (riscv_set_arch): Updated since the field of rps is changed. Besides,
+ report error when the architecture string is empty.
+ (riscv_after_parse_args): Updated.
+
+2021-09-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-16 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix interrupted sleep in multi-threaded test-cases
+ When running test-case gdb.threads/continue-pending-status.exp with native, I
+ have:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c
+ ^C^M
+ Thread 1 "continue-pendin" received signal SIGINT, Interrupt.^M
+ [Switching to Thread 0x7ffff7fc4740 (LWP 1276)]^M
+ 0x00007ffff758e4c0 in __GI___nanosleep () at nanosleep.c:27^M
+ 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
+ (gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: caught interrupt
+ ...
+ but with target board unix/-m32, I run into:
+ ...
+ (gdb) continue^M
+ Continuing.^M
+ PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c
+ [Thread 0xf74aeb40 (LWP 31957) exited]^M
+ [Thread 0xf7cafb40 (LWP 31956) exited]^M
+ [Inferior 1 (process 31952) exited normally]^M
+ (gdb) Quit^M
+ ...
+
+ The problem is that the sleep (300) call at the end of main is interrupted,
+ which causes the inferior to exit before the ctrl-c can be send.
+
+ This problem is described at "Interrupted System Calls" in the docs, and the
+ suggested solution (using a sleep loop) indeed fixes the problem.
+
+ Fix this instead using the more prevalent:
+ ...
+ alarm (300);
+ ...
+ while (1) sleep (1);
+ ...
+ which is roughly equivalent because the sleep is called at the end of main,
+ but slightly better because it guards against hangs from the start rather than
+ from the end of main.
+
+ Likewise in gdb.base/watch_thread_num.exp.
+
+ Likewise in gdb.btrace/enable-running.exp, but use the sleep loop there,
+ because the sleep is not called at the end of main.
+
+ Tested on x86_64-linux.
+
+2021-09-16 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: manual: fix werrors typo
+
+2021-09-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use function_range in gdb.dwarf2/dw2-abs-hi-pc.exp
+ When I run test-case gdb.dwarf2/dw2-abs-hi-pc.exp with gcc, we have:
+ ...
+ (gdb) break hello^M
+ Breakpoint 1 at 0x4004c0: file dw2-abs-hi-pc-hello.c, line 24.^M
+ (gdb) PASS: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello
+ ...
+ but with clang, I run into:
+ ...
+ (gdb) break hello^M
+ Breakpoint 1 at 0x4004e4^M
+ (gdb) FAIL: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello
+ ...
+
+ The problem is that the CU and function both have an empty address range:
+ ...
+ <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
+ <108> DW_AT_name : dw2-abs-hi-pc-hello.c
+ <123> DW_AT_low_pc : 0x4004e0
+ <127> DW_AT_high_pc : 0x4004e0
+ <1><12f>: Abbrev Number: 2 (DW_TAG_subprogram)
+ <131> DW_AT_name : hello
+ <13a> DW_AT_low_pc : 0x4004e0
+ <13e> DW_AT_high_pc : 0x4004e0
+ ...
+
+ The address ranges are set like this in dw2-abs-hi-pc-hello-dbg.S:
+ ...
+ .4byte .hello_start /* DW_AT_low_pc */
+ .4byte .hello_end /* DW_AT_high_pc */
+ ...
+ where the labels refer to dw2-abs-hi-pc-hello.c:
+ ...
+ extern int v;
+
+ asm (".hello_start: .globl .hello_start\n");
+ void
+ hello (void)
+ {
+ asm (".hello0: .globl .hello0\n");
+ v++;
+ asm (".hello1: .globl .hello1\n");
+ }
+ asm (".hello_end: .globl .hello_end\n");
+ ...
+
+ Using asm labels in global scope is a known source of problems, as explained
+ in the comment of proc function_range in gdb/testsuite/lib/dwarf.exp.
+
+ Fix this by using function_range instead.
+
+ Tested on x86_64-linux with gcc and clang-7 and clang-12.
+
+2021-09-15 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Fix got-weak linker test
+ Use regular expressions to fix the got-weak linker test.
+
+ ld/
+ * testsuite/got-weak.d: Update test.
+
+2021-09-15 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ bfd: fix incorrect type used in sizeof
+ Noticed in passing that we used 'sizeof (char **)' when calculating
+ the size of a list of 'char *' pointers. Of course, this isn't really
+ going to make a difference anywhere, but we may as well be correct.
+
+ There should be no user visible changes after this commit.
+
+ bfd/ChangeLog:
+
+ * archures.c (bfd_arch_list): Use 'char *' instead of 'char **'
+ when calculating space for a string list.
+
+2021-09-15 Tom de Vries <tdevries@suse.de>
+
+ [gdb/doc] Fix typo in maint selftest entry
+ Fix typo "will by" -> "will be".
+
+2021-09-15 Tom de Vries <tdevries@suse.de>
+
+ [bfd] Ensure unique printable names for bfd archs
+ Remove duplicate entry in bfd_ft32_arch and bfd_rx_arch.
+
+ Fix printable name for bfd_mach_n1: "nh1" -> "n1".
+
+ PR 28336
+ * cpu-ft32.c (arch_info_struct): Remove "ft32" entry.
+ * cpu-rx.c (arch_info_struct): Remove "rx" entry.
+ * cpu-nds32.c (bfd_nds32_arch): Fix printable name for bfd_mach_n1
+ entry.
+
+2021-09-15 Alan Modra <amodra@gmail.com>
+
+ PR28328, dlltool ice
+ PR 28328
+ * archive.c (bfd_ar_hdr_from_filesystem): Don't use bfd_set_input_error
+ here, our caller will do that.
+
+2021-09-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb_load_no_complaints with gnu-debuglink
+ When running test-case gdb.dwarf2/dw2-ranges-psym-warning.exp with target
+ board gnu-debuglink I run into:
+ ...
+ (gdb) file dw2-ranges-psym-warning^M
+ Reading symbols from dw2-ranges-psym-warning...^M
+ Reading symbols from .debug/dw2-ranges-psym-warning.debug...^M
+ (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: No complaints
+ ...
+
+ Fix this by updating the regexp in gdb_load_no_complaints.
+
+ Tested on x86_64-linux.
+
+2021-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix function range handling in psymtabs
+ Consider the test-case from this patch.
+
+ We run into:
+ ...
+ (gdb) PASS: gdb.dwarf2/dw2-ranges-psym-warning.exp: continue
+ bt^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+ ^M
+ read in psymtab, but not in symtab.)^M
+ ^M
+ )^M
+ (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: bt
+ ...
+
+ This happens as follows.
+
+ The function foo:
+ ...
+ <1><31>: Abbrev Number: 4 (DW_TAG_subprogram)
+ <33> DW_AT_name : foo
+ <37> DW_AT_ranges : 0x0
+ ...
+ has these ranges:
+ ...
+ 00000000 00000000004004c1 00000000004004d2
+ 00000000 00000000004004ae 00000000004004af
+ 00000000 <End of list>
+ ...
+ which have a hole at at [0x4004af,0x4004c1).
+
+ However, the address map of the partial symtabs incorrectly maps addresses
+ in the hole (such as 0x4004b6 in the backtrace) to the foo CU.
+
+ The address map of the full symbol table of the foo CU however does not
+ contain the addresses in the hole, which is what the warning / internal error
+ complains about.
+
+ Fix this by making sure that ranges of functions are read correctly.
+
+ The patch adds a bit to struct partial_die_info, in this hole (shown for
+ x86_64-linux):
+ ...
+ /* 11: 7 | 4 */ unsigned int canonical_name : 1;
+ /* XXX 4-byte hole */
+ /* 16 | 8 */ const char *raw_name;
+ ...
+ So there's no increase in size for 64-bit, but AFAIU there will be an increase
+ for 32-bit.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-08-10 Tom de Vries <tdevries@suse.de>
+
+ PR symtab/28200
+ * dwarf2/read.c (struct partial_die_info): Add has_range_info and
+ range_offset field.
+ (add_partial_subprogram): Handle pdi->has_range_info.
+ (partial_die_info::read): Set pdi->has_range_info.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-10 Tom de Vries <tdevries@suse.de>
+
+ PR symtab/28200
+ * gdb.dwarf2/dw2-ranges-psym-warning-main.c: New test.
+ * gdb.dwarf2/dw2-ranges-psym-warning.c: New test.
+ * gdb.dwarf2/dw2-ranges-psym-warning.exp: New file.
+
+2021-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix CU list in .debug_names for dummy CUs
+ With current trunk and target board cc-with-debug-names we have:
+ ...
+ (gdb) file dw2-ranges-psym^M
+ Reading symbols from dw2-ranges-psym...^M
+ warning: Section .debug_names in dw2-ranges-psym has abbreviation_table of \
+ size 1 vs. written as 28, ignoring .debug_names.^M
+ (gdb) set complaints 0^M
+ (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
+ ...
+
+ The executable has 8 compilation units:
+ ...
+ $ readelf -wi dw2-ranges-psym | grep @
+ Compilation Unit @ offset 0x0:
+ Compilation Unit @ offset 0x2e:
+ Compilation Unit @ offset 0xa5:
+ Compilation Unit @ offset 0xc7:
+ Compilation Unit @ offset 0xd2:
+ Compilation Unit @ offset 0x145:
+ Compilation Unit @ offset 0x150:
+ Compilation Unit @ offset 0x308:
+ ...
+ of which the ones at 0xc7 and 0x145 are dummy CUs (that is, they do not
+ contain a single DIE), which were added by recent commit 5ef670d81fd
+ "[gdb/testsuite] Add dummy start and end CUs in dwarf assembly".
+
+ The .debug_names section contains this CU table:
+ ...
+ [ 0] 0x0
+ [ 1] 0x2e
+ [ 2] 0xa5
+ [ 3] 0xd2
+ [ 4] 0x150
+ [ 5] 0x308
+ [ 6] 0x1
+ [ 7] 0x0
+ ...
+ The last two entries are incorrect, and the entries for the dummy CUs are
+ missing.
+
+ The last two entries are incorrect because here in write_debug_names we write
+ the dimension of the CU list as 8:
+ ...
+ /* comp_unit_count - The number of CUs in the CU list. */
+ header.append_uint (4, dwarf5_byte_order,
+ per_objfile->per_bfd->all_comp_units.size ()
+ - per_objfile->per_bfd->tu_stats.nr_tus);
+ ...
+ while the actual dimension of the CU list is 6.
+
+ The discrepancy is caused by this code which skips the dummy CUs:
+ ...
+ for (int i = 0; i < per_objfile->per_bfd->all_comp_units.size (); ++i)
+ {
+ ...
+ /* CU of a shared file from 'dwz -m' may be unused by this main
+ file. It may be referenced from a local scope but in such
+ case it does not need to be present in .debug_names. */
+ if (psymtab == NULL)
+ continue;
+ ...
+ because they have a null partial symtab.
+
+ We can fix this by writing the actual dimension of the CU list, but that still
+ leaves the dummy CUs out of the CU list. The purpose of having these is to
+ delimit the end of preceding CUs.
+
+ So, fix this by:
+ - removing the code that skips the dummy CUs (note that the same change
+ was done for .gdb_index in commit efba5c2319d '[gdb/symtab] Handle PU
+ without import in "save gdb-index"'.
+ - verifying that all units are represented in the CU/TU lists
+ - using the actual CU list size when writing the dimension of the CU list
+ (and likewise for the TU list).
+
+ Tested on x86_64-linux with native and target board cc-with-debug-names.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28261
+
+2021-09-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Generate .debug_aranges in gdb.dwarf2/locexpr-data-member-location.exp
+ When running test-case gdb.dwarf2/locexpr-data-member-location.exp with target
+ board cc-with-debug-names, all tests pass but we run into PR28261:
+ ...
+ (gdb) run ^M
+ Starting program: locexpr-data-member-location ^M
+ warning: Section .debug_names in locexpr-data-member-location-lib.so has \
+ abbreviation_table of size 1 vs. written as 37, ignoring .debug_names.^M
+ ...
+
+ Using a patch that fixes PR28261, the warning is gone, but we run into:
+ ...
+ FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
+ ...
+
+ This is due a missing .debug_aranges contribution for the CU declared in
+ gdb.dwarf2/locexpr-data-member-location.exp.
+
+ Fix this by adding the missing .debug_aranges contribution.
+
+ Tested on x86_64-linux.
+
+2021-09-14 Claudiu Zissulescu <claziss@synopsys.com>
+
+ arc: Fix potential invalid pointer access when fixing got symbols.
+ When statically linking, it can arrive to an undefined weak symbol of
+ which its value cannot be determined. However, we are having pieces of
+ code which doesn't take this situation into account, leading to access
+ a structure which may not be initialized. Fix this situation and add a
+ test.
+
+ bfd/
+ xxxx-xx-xx Cupertino Miranda <cmiranda@synopsys.com>
+ Claudiu Zissulescu <claziss@synopsys.com>
+
+ * arc-got.h (arc_static_sym_data): New structure.
+ (get_static_sym_data): New function.
+ (relocate_fix_got_relocs_for_got_info): Move the computation fo
+ symbol value and section to above introduced function, and use
+ this new function.
+
+ ld/testsuite/
+ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
+
+ * ld-arc/got-weak.d: New file.
+ * ld-arc/got-weak.s: Likewise.
+
+
+ fix
+
+2021-09-14 Mike Frysinger <vapier@gentoo.org>
+
+ sim: bfin: add support for SDL2
+ This probably should have been ported long ago, but better late than
+ never. We keep support for both versions for now since both projects
+ tend to have long lifetimes. Maybe consider dropping SDL1 in another
+ ten years.
+
+2021-09-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-14 Tom Tromey <tom@tromey.com>
+
+ Remove use of __CYGNUSCLIB__
+ I found a check of __CYGNUSCLIB__ in dbxread.c. I think this is dead
+ code. This patch removes it.
+
+2021-09-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check for valid test name
+ When running gdb.base/batch-exit-status.exp I noticed that the test name
+ contains a newline:
+ ...
+ PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+ : No such file or directory\.: [lindex $result 2] == 0
+ ...
+
+ Check for this in ::CheckTestNames::check, such that we have a warning:
+ ...
+ PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+ : No such file or directory\.: [lindex $result 2] == 0
+ WARNING: Newline in test name
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Fix exec check in gdb_print_insn_arm
+ With a gdb build with --enable-targets=all we run into a KFAIL:
+ ...
+ KFAIL: gdb.gdb/unittest.exp: executable loaded: maintenance selftest, \
+ failed none (PRMS: gdb/27891)
+ ...
+ due to:
+ ...
+ Running selftest print_one_insn.^M
+ Self test failed: arch armv8.1-m.main: self-test failed at \
+ disasm-selftests.c:165^M
+ ...
+
+ The test fails because we expect disassembling of one arm insn to consume 4
+ bytes and produce (using verbose = true in disasm-selftests.c):
+ ...
+ arm mov r0, #0
+ ...
+ but instead the disassembler uses thumb mode and only consumes 2
+ bytes and produces:
+ ...
+ arm movs r0, r0
+ ...
+
+ The failure does not show up in the "no executable loaded" variant because
+ this code in gdb_print_insn_arm isn't triggered:
+ ...
+ if (current_program_space->exec_bfd () != NULL)
+ info->flags |= USER_SPECIFIED_MACHINE_TYPE;
+ ...
+ and consequently we do this in print_insn:
+ ...
+ if ((info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0)
+ info->mach = bfd_mach_arm_unknown;
+ ...
+ and don't set force_thumb to true in select_arm_features.
+
+ The code in gdb_print_insn_arm makes the assumption that the disassembly
+ architecture matches the exec architecture, which in this case is incorrect,
+ because the exec architecture is x86_64, and the disassembly architecture is
+ armv8.1-m.main. Fix that by explicitly checking it:
+ ...
+ if (current_program_space->exec_bfd () != NULL
+ && (current_program_space->exec_bfd ()->arch_info
+ == gdbarch_bfd_arch_info (gdbarch)))
+ ...
+
+ This fixes the print_one_insn failure, so remove the KFAIL.
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27891
+
+2021-09-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/tdep] Reset force_thumb in parse_arm_disassembler_options
+ With a gdb build with --enable-targets=all, we have 2 arch-specific failures
+ in selftest print_one_insn:
+ ...
+ $ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \
+ | grep "Self test failed: arch "
+ Self test failed: arch armv8.1-m.main: self-test failed at \
+ disasm-selftests.c:165
+ Self test failed: arch arm_any: self-test failed at disasm-selftests.c:165
+ $
+ ...
+
+ During the first failed test, force_thumb is set to true, and remains so until
+ and during the second test, which causes the second failure.
+
+ Fix this by resetting force_thumb to false in parse_arm_disassembler_options,
+ such that we get just one failure:
+ ...
+ $ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \
+ | grep "Self test failed: arch "
+ Self test failed: arch armv8.1-m.main: self-test failed at \
+ disasm-selftests.c:165
+ $
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-13 Tom Tromey <tromey@adacore.com>
+
+ Fix no-Python build
+ A build without Python will currently fail, because
+ selftests::test_python uses gdb_python_initialized, which is only
+ conditionally defined.
+
+ This patch fixes the build by making test_python also be conditionally
+ defined. I chose this approach because the selftest will fail if
+ Python is not enabled, so it didn't seem useful to leave it defined.
+
+2021-09-13 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Update the assembler insn testcase.
+ Since the 0x57 is preserved for the vadd.vv instruction in the integration
+ branch, remove it to make sure the testcase can work.
+
+ gas/
+ * testsuite/gas/riscv/insn.d: Remove 0x57 since it is preserved
+ for vadd.vv instruction.
+ * testsuite/gas/riscv/insn.s: Likewise.
+
+2021-09-13 Jan Beulich <jbeulich@suse.com>
+
+ MIPS: don't use get_symbol_name() for section parsing. With s_change_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.
+ gas * config/tc-mips.c (s_change_section): Use obj_elf_section_name to
+ parse the section name.
+
+ ia64: don't use get_symbol_name() for section parsing. With cross_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.
+ gas * config/tc-ia64.c (cross_section): Use obj_elf_section_name to
+ parse the section name.
+
+2021-09-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.gdb/selftest.exp
+ With a gdb build with CFLAGS "-O2 -g -flto=auto", I run into:
+ ...
+ #7 gdb_main (args=0x7fffffffd220) at src/gdb/main.c:1368^M
+ #8 main (argc=<optimized out>, argv=<optimized out>) at src/gdb/gdb.c:32^M
+ (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
+ ...
+ which means that this regexp in proc test_with_self fails:
+ ...
+ -re "#0.*(read|poll).*in main \\(.*\\) at .*gdb\\.c.*$gdb_prompt $" {
+ ...
+
+ The problem is that gdb_main has been inlined into main, and consequently the
+ backtrace uses:
+ ...
+ #x <fn> ...
+ ...
+ instead of
+ ...
+ #x <address> in <fn> ...
+ ...
+
+ Fix this by updating the regexp to not require "in" before " main".
+
+ Tested on x86_64-linux.
+
+2021-09-13 Alan Modra <amodra@gmail.com>
+
+ Re: Deprecate a.out support for NetBSD targets
+ * config.bfd: Correct m68-*-*bsd* obsolete target match.
+
+2021-09-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix test name in gdb.base/batch-exit-status.exp
+ When running gdb.base/batch-exit-status.exp I noticed that the test name
+ contains a newline:
+ ...
+ PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+ : No such file or directory\.: [lindex $result 2] == 0
+ ...
+
+ The mistake is that I passed an output regexp argument to a parameter
+ interpreted as testname prefix. Fix this by passing a testname prefix
+ instead.
+
+ Add support for checking output, to be able to handle the output regexp
+ argument.
+
+ Tested on x86_64-linux.
+
+2021-09-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Set sysroot earlier in local-board.exp
+ When running test-case gdb.base/batch-exit-status.exp for native, it passes.
+ But with target board cc-with-debug-names, we run into (added missing double
+ quotes for clarity):
+ ...
+ builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
+ -data-directory $build/gdb/testsuite/../data-directory \
+ -iex "set height 0" -iex "set width 0" -ex "set sysroot" -batch ""^M
+ : No such file or directory.^M
+ PASS: gdb.base/batch-exit-status.exp: \
+ : No such file or directory\.: [lindex $result 2] == 0
+ FAIL: gdb.base/batch-exit-status.exp: \
+ : No such file or directory\.: [lindex $result 3] == $expect_status
+ ...
+
+ The difference between the passing and failing case is that with native we
+ have (leaving out set height/width for brevity):
+ ...
+ $ gdb -batch ""; echo $?
+ : No such file or directory.
+ 1
+ ...
+ and with target board cc-with-debug-names:
+ ...
+ $ gdb -ex "set sysroot" -batch ""; echo $?
+ : No such file or directory.
+ 0
+ ...
+
+ The difference is expected. GDB returns the exit status of the last executed
+ command. In the former case that's 'file ""', which fails. In the latter case,
+ that's 'set sysroot', which succeeds.
+
+ Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such
+ that we have the expected:
+ ...
+ $ gdb -iex "set sysroot" -batch ""; echo $?
+ : No such file or directory.
+ 1
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-11 Mike Frysinger <vapier@gentoo.org>
+
+ sim: run: change help short option to -h
+ It's unclear why -H was picked over the more standard -h, but since
+ -h is still not used, just change -H to -h to match pretty much every
+ other tool in the sourceware tree.
+
+2021-09-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Reimplement gdb.gdb/python-selftest.exp as unittest
+ The test-case gdb.gdb/python-selftest.exp:
+ - patches the gdb_python_initialized variable in gdb to 0
+ - checks that the output of a python command is "Python not initialized"
+
+ Reimplement gdb.gdb/python-selftest.exp as unittest, using:
+ - execute_command_to_string to capture the output
+ - try/catch to catch the "Python not initialized" exception.
+
+ Tested on x86_64-linux.
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp
+ Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp by naming commands more
+ uniquely.
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix DUPLICATE in gdb.base/skip-solib.exp
+ Fix DUPLICATE in gdb.base/skip-solib.exp by using with_test_prefix.
+
+ Also fix indentation style and long lines, remove outdated question/answer
+ bits, and use multi_line.
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_test
+ The documentation of mi_gdb_test states that the command, pattern and message
+ arguments are mandatory:
+ ...
+ # mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb;
+ # test the result.
+ ...
+
+ However, this is not checked, and when mi_gdb_test is called with less than 3
+ arguments, it passes or fails silently.
+
+ Fix this by using the following semantics:
+ - if there are 1 or 2 arguments, use the command as the message.
+ - if there is 1 argument, use ".*" as the pattern.
+ - if there are no or too much arguments, error out.
+
+ Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as
+ message. Fix a few other trivial-looking FAILs.
+
+ There are 11 less trivial-looking FAILs left in gdb.mi in test-cases:
+ - mi-nsmoribund.exp
+ - mi-breakpoint-changed.exp
+ - mi-break.exp.
+
+ Tested on x86_64-linux.
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add string_list_to_regexp
+ A regexp pattern with escapes like this is hard to read:
+ ...
+ set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done"
+ ...
+
+ We can make it more readable by spacing out parts (which allows us to also use
+ the curly braces where that's convenient):
+ ...
+ set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"]
+ set re [join $re ""]
+ ...
+ or by using string_to_regexp:
+ ...
+ set re [list \
+ [string_to_regexp {~"$}] \
+ $decimal \
+ [string_to_regexp " = 1\\n\"\r\n^done"]]
+ set re [join $re ""]
+ ...
+ Note: we have to avoid applying string_to_list to decimal, which is already a
+ regexp.
+
+ Add a proc string_list_to_regexp to make it easy to do both:
+ ...
+ set re [list \
+ [string_list_to_regexp ~ {"} $] \
+ $decimal \
+ [string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]]
+ ...
+
+ Also add a test-case gdb.testsuite/string_to_regexp.exp.
+
+2021-09-10 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle unrecognized command line option in gdb_compile_test
+ When running the gdb testsuite with gnatmake-4.8, I get many fails of the
+ following form:
+ ...
+ gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
+ gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
+ compiler exited with status 1
+ compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
+ gcc: error: unrecognized command line option '-fgnat-encodings=all'
+ gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
+ FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
+ ...
+
+ Fix this by marking the test unsupported instead, such that we have:
+ ...
+ UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
+ (unsupported option '-fgnat-encodings=all')
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-10 Alan Modra <amodra@gmail.com>
+
+ PowerPC, sanity check r_offset in relocate_section
+ * elf32-ppc.c (offset_in_range): New function.
+ (ppc_elf_vle_split16): Sanity check r_offset before accessing
+ section contents. Return status.
+ (ppc_elf_relocate_section): Sanity check r_offset before
+ accessing section contents. Don't segfault on NULL howto.
+
+ Re: gas: Use the directory name in .file 0
+ PR gas/28266
+ * testsuite/gas/elf/dwarf-5-file0-2.s: Use %object rather than
+ @object, .4byte instead of .long, and .asciz instead of .string.
+
+2021-09-10 Mike Frysinger <vapier@gentoo.org>
+
+ etc: switch to automake
+ There's no content in here currently, so switching to automake is
+ pretty easy with a stub file.
+
+ etc: rename configure.in to configure.ac
+ The .in name has been deprecated for a long time in favor of .ac.
+
+2021-09-10 H.J. Lu <hjl.tools@gmail.com>
+
+ gas: Use the directory name in .file 0
+ DWARF5 allows .file 0 to take an optional directory name. Set the entry
+ 0 of the directory table to the directory name in .file 0.
+
+ PR gas/28266
+ * dwarf2dbg.c (get_directory_table_entry): Add an argument for
+ the directory name in .file 0 and use it, instead of PWD.
+ (allocate_filenum): Pass NULL to get_directory_table_entry.
+ (allocate_filename_to_slot): Pass the incoming dirname to
+ get_directory_table_entry.
+ * testsuite/gas/elf/dwarf-5-file0-2.d: New file.
+ * testsuite/gas/elf/dwarf-5-file0-2.s: Likewise.
+ * testsuite/gas/elf/elf.exp: Run dwarf-5-file0-2.
+
+2021-09-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-09 Yoshinori Sato <ysato@users.sourceforge.jp>
+
+ gdb: Enable target rx-*-*linux.
+ I added rx-*-linux in binutils few yaers ago.
+ But missing this changes,
+
+2021-09-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip
+ On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into:
+ ...
+ (gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile
+ First line of eu-unstrip: \
+ 0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe]
+ FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id
+ ...
+
+ The test expects an actual file name instead of '[exe]', but that only got
+ introduced with eu-unstrip 0.161. Before it printed '[exe]' or '[pie]'.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+2021-09-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp
+ I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8:
+ ...
+ FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
+ (unexpected output)
+ ...
+ due to function f2 instead of f3 being listed.
+
+ AFAICT, this is caused by a difference in debug info:
+ ...
+ $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
+ | egrep "DW_AT_name.*: f[1-3]"
+ <72> DW_AT_name : f1
+ <a1> DW_AT_name : f2
+ <d0> DW_AT_name : f3
+ ...
+ vs:
+ ...
+ $ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
+ | egrep "DW_AT_name.*: f[1-3]"
+ <f4> DW_AT_name : f3
+ <123> DW_AT_name : f2
+ <152> DW_AT_name : f1
+ ...
+ and the command documentation does not mention an imposed order, so fix this
+ by allowing f2 as well.
+
+ Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re
+ variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern
+ overall.
+
+ Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix
+ by updating the regexp.
+
+ Then I ran with clang and found another FAIL, fix by updating the regexp.
+
+ Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and
+ clang-12.0.1.
+
+2021-09-09 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Reimplement gdb.gdb/complaints.exp as unittest
+ When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+ ...
+ (gdb) call clear_complaints()^M
+ No symbol "clear_complaints" in current context.^M
+ (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
+ ...
+
+ The problem is that lto has optimized away the clear_complaints function
+ and consequently the selftest doesn't work.
+
+ Fix this by reimplementing the selftest as a unit test.
+
+ Factor out two new functions:
+ - void
+ execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn);
+ - std::string
+ execute_fn_to_string (std::function<void(void)> fn, bool term_out);
+ and use the latter to capture the complaints output.
+
+ Tested on x86_64-linux.
+
+2021-09-09 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITER
+ Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
+ part of the tp_flags field when defining a new object type. This flag
+ is not defined in Python 3 and so we define it to 0 in
+ python-internal.h (when IS_PY3K is defined).
+
+ The meaning of this flag is that the object has the fields tp_iter and
+ tp_iternext. Note the use of "has" here, the flag says nothing about
+ the values in those fields, just that the type object has the fields.
+
+ In early versions of Python 2 these fields were no part of the
+ PyTypeObject struct, they were added in version 2.2 (see
+ https://docs.python.org/release/2.3/api/type-structs.html). And so,
+ there could be a some code compiled out there which has a PyTypeObject
+ structure within it that doesn't even have the tp_iter and tp_iternext
+ fields, attempting to access these fields would be undefined
+ behaviour.
+
+ And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is
+ present then Python is free to access the tp_iter and tp_iternext
+ fields.
+
+ If we consider GDB then we always assume that the tp_iter and
+ tp_iternext fields are part of PyTypeObject. If someone was crazy
+ enough to try and compile GDB against Python 2.1 then we'd get lots of
+ build errors saying that we were passing too many fields when
+ initializing PyTypeObject structures. And so, I claim, we can be sure
+ that GDB will always be compiled with a version of Python that has the
+ tp_iter and tp_iternext fields in PyTypeObject.
+
+ Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each
+ time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
+ flag would be defined to indicate whether those flags are present or
+ not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And
+ so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
+ includes Py_TPFLAGS_HAVE_ITER (see
+ https://docs.python.org/2.7/c-api/typeobj.html).
+
+ In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
+ objects we define.
+
+ And so, in this commit, I propose to remove all uses of
+ Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.
+
+ There should be no user visible changes after this commit.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: accept -EB/-EL short options
+ Many GNU tools accept -EB/-EL as short options for selecting big &
+ little endian modes. While the sim has an -E option, it requires
+ spelling out "big" and "little". Adding support for -EB & -EL is
+ thus quite trivial, so lets round it out to be less annoying.
+
+ sim: ppc: drop support for std-config.h overrides
+ Only the ppc arch supports this kind of source file override logic.
+ All the others expose knobs via configure flags, and for some of
+ these, the ppc code does as well. For others, it doesn't make sense
+ to ever change them. Since it's unlikely anyone is using this, drop
+ it all to simplify the code (and to get us a little closer to the
+ common sim code).
+
+ sim: ppc: enable use of gnulib
+ All other sim arches are using this now, so finish up the logic in
+ the ppc arch to enable gnulib usage here too.
+
+ sim: drop old O_NDELAY & FNBLOCK support
+ We use these older names inconsistently in the sim codebase, and time
+ has moved on long ago, so drop support for these non-standard names.
+ POSIX provides O_NONBLOCK for us, so use it everywhere.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: dv-sockser: enable for mingw targets too
+ We have enough functionality from gnulib now to build sockser on
+ all platforms.
+
+ Non-blocking I/O is supported when F_GETFL/F_SETFL are unavailable,
+ but we can address that in a follow up commit. This mirrors what
+ is done in other places in the sim already.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: cgen: workaround Windows VOID define
+ The cgen framework provides a "VOID" type for code to use, but this
+ defines ends up conflicting with the standard Windows VOID define.
+ Since they actually define to the same thing ("void"), undef it here
+ to fix the Windows build.
+
+ We might want to reconsider the need for "VOID" in cgen, but that
+ will take larger discussion & coordination with the cgen project.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: dv-sockser: move sim-main.h include after system includes
+ The sim-main.h header is a bit of a dumping ground. Every arch can
+ (and many do) define all sorts of weird & common names that end up
+ conflicting with system headers. So including it before the system
+ headers sets us up for pain. v850 is a good example of this -- when
+ building for mingw, we see weird failures:
+
+ $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/v850/../common/dv-sockser.c
+ In file included from ../../../../sim/v850/sim-main.h:11,
+ from ../../../../sim/v850/../common/dv-sockser.c:24:
+ ../../../../sim/v850/../common/sim-base.h:97:32: error: expected ')' before '->' token
+ 97 | # define STATE_CPU(sd, n) ((sd)->cpu[0])
+ | ^~
+
+ While gcc is unhelpful at first, running it through the preprocessor
+ by hand shows more details:
+
+ $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/v850/../common/dv-sockser.c
+ $ i686-w64-mingw32-gcc -c dv-sockser.i
+ In file included from /usr/i686-w64-mingw32/usr/include/minwindef.h:163,
+ from /usr/i686-w64-mingw32/usr/include/windef.h:9,
+ from /usr/i686-w64-mingw32/usr/include/windows.h:69,
+ from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+ from ../../gnulib/import/sys/socket.h:684,
+ from ../../gnulib/import/netinet/in.h:43,
+ from ../../../../sim/v850/../common/dv-sockser.c:39:
+ /usr/i686-w64-mingw32/usr/include/winnt.h:4803:25: error: expected ')' before '->' token
+ 4803 | DWORD State;
+ | ^
+ | )
+
+ This is because v850 sets up this common name:
+
+ All of this needs cleaning up someday, but since the dv-sockser code
+ definitely should be fixed in this way, lets do that now and unblock
+ the v850 code.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: mips: delete unused PSIZE define
+ It's unclear what this define is for as it appears to be unused, and
+ has never been used in the history of the mips sim. Delete it to tidy
+ up, and to fix build errors for Windows targets that have a standard
+ "PSIZE" struct in their system headers. This doesn't show up yet as
+ most sim files don't include many system headers, but enabling sockser
+ code for mingw uncovers the conflict.
+
+ Unfortunately the error produced by gcc is inscrutable, but running
+ it through the preprocessor manually manages to provide a pointer to
+ the underlying issue.
+
+ $ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/mips/../common/dv-sockser.c
+ <command-line>: error: expected identifier or '(' before numeric constant
+ In file included from /usr/i686-w64-mingw32/usr/include/windows.h:71,
+ from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+ from ../../gnulib/import/sys/socket.h:684,
+ from ../../gnulib/import/netinet/in.h:43,
+ from ../../../../sim/mips/../common/dv-sockser.c:39:
+ /usr/i686-w64-mingw32/usr/include/wingdi.h:2934:59: error: unknown type name 'LPSIZE'; did you mean 'LPSIZEL'?
+ 2934 | WINGDIAPI WINBOOL WINAPI GetAspectRatioFilterEx(HDC hdc,LPSIZE lpsize);
+ | ^~~~~~
+ | LPSIZEL
+ ...
+
+ $ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/mips/../common/dv-sockser.c
+ $ i686-w64-mingw32-gcc -c dv-sockser.i
+ In file included from /usr/i686-w64-mingw32/usr/include/windows.h:69,
+ from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+ from ../../gnulib/import/sys/socket.h:684,
+ from ../../gnulib/import/netinet/in.h:43,
+ from ../../../../sim/mips/../common/dv-sockser.c:39:
+ /usr/i686-w64-mingw32/usr/include/windef.h:104:9: error: expected identifier or '(' before numeric constant
+ 104 | } SIZE,*PSIZE,*LPSIZE;
+ | ^~
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: switch to common warning flags
+ Now that the ppc code has been cleaned up enough to use the same set
+ of warning flags as the common code, delete the ppc-specific configure
+ logic so we can leverage what the common code already defined for us.
+
+2021-09-09 Tom de Vries <tdevries@suse.de>
+
+ sim: ppc: enable -Wpointer-sign warnings
+ When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
+ ...
+ src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address':
+ src/sim/ppc/hw_memory.c:204:7: error: pointer targets in passing argument 4 \
+ of 'device_find_integer_array_property' differ in signedness \
+ [-Werror=pointer-sign]
+ &new_chunk->size);
+ ^
+ ...
+
+ Fix these by adding an explicit pointer cast. It's a bit ugly to use APIs
+ based on signed integers to read out unsigned values, but in practice, this
+ is par for the course in the ppc code.
+
+ We already use signed APIs and assign the result to unsigned values a lot:
+ see how device_find_integer_property returns a signed integer (cell), but
+ then assign it to unsigned types. The array APIs are not used that often
+ which is why we don't see many warnings, and we disable warnings when we
+ assign signed integers to unsigned integers in general.
+
+ The dtc/libfdt project (which is the standard in other projects) processes
+ the fdt blob as a series of bytes without any type information. Typing is
+ left to the caller. They have core APIs that read/write bytes, and a few
+ helper functions to cast/convert those bytes to the right value (e.g. u32).
+ In this ppc sim code, the core APIs use signed integers, and the callers
+ convert to unsigned, usually implicitly.
+
+ We could add some core APIs to the ppc sim that deal with raw bytes and then
+ add some helpers to convert to the right type, but that seems like a lot of
+ lifting for what boils down to a cast, and is effectively equivalent to all
+ the implicit assignments we use elsewhere. Long term, a lot of the ppc code
+ should either get converted to existing sim common code, or we should stand
+ up proper APIs in the common code first, or use standard libraries to do all
+ the processing (e.g. libfdt). Either way, this device.c code would all get
+ deleted, and callers (like these hw_*.c files) would get converted. Which
+ is also why we go with a cast rather new (but largely unused) APIs.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: enable -Wmissing-declarations & -Wmissing-prototypes
+ This aligns with common code which already uses this flag. We have
+ to add another local prototype to fix the failure, and add another
+ local decl for the SIM_DESC type. Unwinding these will require a
+ lot more work & conversions in the process, so going with the decl
+ for now unblocks the warning unification.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: microblaze: replace custom basic types with common ones
+ The basic "byte" type conflicts with Windows headers, and we already
+ have common types that provide the right sizes. So replace these with
+ the common ones to avoid issues.
+
+ CC dv-sockser.o
+ In file included from /usr/i686-w64-mingw32/usr/include/wtypes.h:8,
+ from /usr/i686-w64-mingw32/usr/include/winscard.h:10,
+ from /usr/i686-w64-mingw32/usr/include/windows.h:97,
+ from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+ from ../../gnulib/import/sys/socket.h:684,
+ from ../../gnulib/import/netinet/in.h:43,
+ from .../build/sim/../../../sim/microblaze/../common/dv-sockser.c:39:
+ /usr/i686-w64-mingw32/usr/include/rpcndr.h:63:25: error: conflicting types for 'byte'; have 'unsigned char'
+ 63 | typedef unsigned char byte;
+ | ^~~~
+ In file included from .../buildsim/../../../sim/microblaze/sim-main.h:21,
+ from .../buildsim/../../../sim/microblaze/../common/dv-sockser.c:24:
+ .../buildsim/../../../sim/microblaze/microblaze.h:94:25: note: previous declaration of 'byte' with type 'byte' {aka 'char'}
+ 94 | typedef char byte;
+ | ^~~~
+ make: *** [Makefile:513: dv-sockser.o] Error 1
+
+2021-09-09 Jim Wilson <jimw@sifive.com>
+
+ RISC-V: Pretty print values formed with lui and addiw.
+ The disassembler has support to pretty print values created by an lui/addi
+ pair, but there is no support for addiw. There is also no support for
+ c.addi and c.addiw. This patch extends the pretty printing support to
+ handle these 3 instructions in addition to addi. Existing testcases serve
+ as tests for the new feature.
+
+ opcodes/
+ * riscv-dis.c (maybe_print_address): New arg wide. Sign extend when
+ wide is true.
+ (print_insn_args): Fix calls to maybe_print_address. Add checks for
+ c.addi, c.addiw, and addiw, and call maybe_print_address for them.
+
+ gas/
+ * testsuite/gas/riscv/insn.d: Update for disassembler change.
+ * testsuite/gas/li32.d, testsuite/gas/li64.d: Likwise.
+ * testsuite/gas/lla64.d: Likewise.
+
+2021-09-09 Mike Frysinger <vapier@gentoo.org>
+
+ sim: ppc: align format string settings with common code
+ This copies logic used in the common sim warning configure code to fix
+ build errors for mingw targets. Turning format warnings on triggers
+ a failure in the debug.c file, so apply a minor fix at the same time.
+
+ sim: ppc: drop unnecessary config includes
+ This file is compiled for the --host & --build system which leads to
+ including the configure generated config.h in both environments.
+ This obviously doesn't work when the two targets don't look alike at
+ all and can cause build failures here (e.g. a mingw host & a linux
+ build). Since we don't actually need any config settings in this
+ very simple file, drop the includes entirely.
+
+2021-09-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-08 Mike Frysinger <vapier@gentoo.org>
+
+ gnulib: import various network functions
+ Some sim ports use these to provide networking functionality via the
+ dv-sockser module or via direct emulation for a few ports.
+
+ Gdb seems to build just fine still too.
+
+2021-09-08 Tom Tromey <tromey@adacore.com>
+
+ Fix unit test build on Windows
+ Like Tom de Vries' earlier patch to fix the no-CXX_STD_THREAD case in
+ maint.c, this patch fixes a similar problem in
+ parallel-for-selftests.c. This fixes a build failure on Windows.
+
+2021-09-08 Alan Modra <amodra@gmail.com>
+
+ PowerPC64, sanity check r_offset in relocate_section
+ This hardens the powerpc64 linker code transformations.
+
+ * elf64-ppc.c (is_8byte_reloc, offset_in_range): New functions.
+ (ppc64_elf_relocate_section): Sanity check r_offset before
+ accessing section contents for various code transformations.
+
+2021-09-08 Alan Modra <amodra@gmail.com>
+
+ PowerPC64: Avoid useless work on R_PPC64_TPREL34
+ _bfd_elf_ppc_at_tprel_transform doesn't handle prefix instructions,
+ and I'm not inclined to implement code editing for them.
+
+ * elf64-ppc.c (ppc64_elf_relocate_section): Don't attempt tprel
+ transform for R_PPC64_TPREL34.
+
+2021-09-08 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: make thread_suspend_state::stop_pc optional
+ Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and
+ when we want to indicate that there is no stop_pc available we set
+ this field back to a special value.
+
+ There are actually two special values used, in post_create_inferior
+ the stop_pc is set to 0. This is a little unfortunate, there are
+ plenty of embedded targets where 0 is a valid pc value. The more
+ common special value for stop_pc though, is set in
+ thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used.
+
+ This commit changes things so that the stop_pc is instead a
+ gdb::optional. We can now explicitly reset the field to an
+ uninitialised state, we also have asserts that we don't read the
+ stop_pc when its in an uninitialised state (both in
+ gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG
+ defined, and in thread_info::stop_pc).
+
+ One situation where a thread will not have a stop_pc value is when the
+ thread is stopped as a consequence of GDB being in all stop mode, and
+ some other thread stopped at an interesting event. When GDB brings
+ all the other threads to a stop those other threads will not have a
+ stop_pc set (thus avoiding an unnecessary read of the pc register).
+
+ Previously, when GDB passed through handle_one (in infrun.c) the
+ threads executing flag was set to false and the stop_pc field was left
+ unchanged, i.e. it would (previous) have been left as ~0.
+
+ Now, handle_one leaves the stop_pc with no value.
+
+ This caused a problem when we later try to set these threads running
+ again, in proceed() we compare the current pc with the cached stop_pc.
+ If the thread was stopped via handle_one then the stop_pc would have
+ been left as ~0, and the compare (in proceed) would (likely) fail.
+ Now however, this compare tries to read the stop_pc when it has no
+ value and this would trigger an assert.
+
+ To resolve this I've added thread_info::stop_pc_p() which returns true
+ if the thread has a cached stop_pc. We should only ever call
+ thread_info::stop_pc() if we know that there is a cached stop_pc,
+ however, this doesn't mean that every call to thread_info::stop_pc()
+ needs to be guarded with a call to thread_info::stop_pc_p(), in most
+ cases we know that the thread we are looking at stopped due to some
+ interesting event in that thread, and so, we know that the stop_pc is
+ valid.
+
+ After running the testsuite I've seen no other situations where
+ stop_pc is read uninitialised.
+
+ There should be no user visible changes after this commit.
+
+2021-09-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Fix build with undefined CXX_STD_THREAD
+ When building gdb on openSUSE Leap 42.3, we trigger the case that
+ CXX_STD_THREAD is undefined, and run into:
+ ...
+ gdb/maint.c: In function 'void maintenance_show_worker_threads \
+ (ui_file*, int, cmd_list_element*, const char*)':
+ gdb/maint.c:877:14: error: 'gdb::thread_pool' has not been declared
+ gdb::thread_pool::g_thread_pool->thread_count ());
+ ^
+ Makefile:1647: recipe for target 'maint.o' failed
+ make[1]: *** [maint.o] Error 1
+ ...
+
+ Fix this by handling the undefined CXX_STD_THREAD case in
+ maintenance_show_worker_threads, such that we get:
+ ...
+ $ gdb -q -batch -ex "maint show worker-thread"
+ The number of worker threads GDB can use is 0.
+ ...
+
+ Tested on x86_64-linux.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28312
+
+2021-09-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: update configure target list
+ Fix sorting of the list, and update the globs to match the list used
+ in gdb's configure script.
+
+ gdb: cris: enable sim integration
+ The sim side is already ready to go for cris, so wire it up.
+
+ gdb: aarch64: enable sim integration
+ The sim side is already ready to go for aarch64, so wire it up.
+
+ gdb: sim: consolidate configure settings
+ Moving all the sim settings to one section makes it easier to track,
+ and makes it easier to keep it aligned with the sim target tests.
+ The gdb logic was duplicating this when handling different OS targets
+ instead of having a single cpu check. Now it's more obvious that the
+ sim is tied to a cpu and not related to the OS.
+
+2021-09-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-07 Tom Tromey <tromey@adacore.com>
+
+ Remove unused declaration from gdbserver/win32-low.h
+ I noticed that gdbserver/win32-low.h has an unused declaration. This
+ code was changed a while ago, but this declaration slipped through.
+ This patch removes it. Tested by rebuilding.
+
+2021-09-07 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: make use of std::string in utils.c
+ Replace some of the manual string management (malloc/free) with
+ std::string when creating commands in utils.c.
+
+ Things are a little bit messy as, creating the prefix commands (using
+ add_basic_prefix_cmd and add_show_prefix_cmd), doesn't copy the doc
+ string, while creating the actual set/show commands (using
+ add_setshow_enum_cmd) does copy the doc string.
+
+ As a result, I have retained the use of xstrprintf when creating the
+ prefix command doc strings, but switched to using std::string when
+ creating the actual set/show commands.
+
+ There should be no user visible changes after this commit.
+
+2021-09-07 Luis Machado <luis.machado@linaro.org>
+
+ Revert: [AArch64] MTE corefile support
+ bfd * elf.c (elfcore_make_memtag_note_section): New function.
+ (elfcore_grok_note): Handle NT_MEMTAG note types.
+
+ binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types.
+
+ include * elf/common.h (NT_MEMTAG): New constant.
+ (NT_MEMTAG_TYPE_AARCH_MTE): New constant.
+
+2021-09-07 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: use bool instead of int in struct internal_problem
+ Change struct internal_problem (gdb/utils.c) to use bool instead of
+ int, update the 3 static instances of this structure that we create to
+ use true/false instead of 1/0.
+
+ I've also updated the comments on struct internal_problem as the
+ existing comment doesn't seem to be referring to the structure, it
+ talks about returning something, which doesn't make sense in this
+ context.
+
+ There should be no user visible changes after this commit.
+
+2021-09-07 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: make thread_info::executing private
+ Rename thread_info::executing to thread_info::m_executing, and make it
+ private. Add a new get/set member functions, and convert GDB to make
+ use of these.
+
+ The only real change of interest in this patch is in thread.c where I
+ have deleted the helper function set_executing_thread, and now just
+ use the new set function thread_info::set_executing. However, the old
+ helper function set_executing_thread included some code to reset the
+ thread's stop_pc, so I moved this code into the new function
+ thread_info::set_executing. However, I don't believe there is
+ anywhere that this results in a change of behaviour, previously the
+ executing flag was always set true through a call to
+ set_executing_thread anyway.
+
+2021-09-07 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access triggered by an atempt to disassemble a corrupt xtensa binary.
+ PR 28305
+ * elf32-xtensa.c (elf_xtensa_do_reloc): Add check for put of range
+ reloc.
+
+2021-09-07 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/python: new function to add values into GDB's history
+ The guile API has (history-append! <value>) to add values into GDB's
+ history list. There is currently no equivalent in the Python API.
+
+ This commit adds gdb.add_history(<value>) to the Python API, this
+ function takes <value> a gdb.Value (or anything that can be passed to
+ the constructor of gdb.Value), and adds the value it represents to
+ GDB's history list. The index of the newly added value is returned.
+
+2021-09-07 Nick Clifton <nickc@redhat.com>
+
+ Fix illegal memory access triggered by an attempt to disassemble a corrupt RISC-V binary.
+ PR 28303
+ * elfxx-riscv.c (riscv_elf_add_sub_reloc): Add check for out of
+ range relocs.
+
+2021-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle internal-error in gdb_unload
+ When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar"
+ to trigger the internal-error in test-case
+ gdb.dwarf2/locexpr-data-member-location.exp, we run into:
+ ...
+ ERROR: couldn't unload file in $gdb (timeout).
+ ...
+ and the test-case takes about 1 minute.
+
+ Fix this by handling internal-error in gdb_unload, such that we have:
+ ...
+ ERROR: Couldn't unload file in $gdb (GDB internal error).
+ ERROR: Could not resync from internal error (eof)
+ ...
+ within 2 seconds.
+
+ Tested on x86_64-linux.
+
+2021-09-07 Alan Modra <amodra@gmail.com>
+
+ PR28307, segfault in ppc64_elf_toc64_reloc
+ Adds missing bfd_reloc_offset_in_range checks to various relocation
+ special_functions.
+
+ PR 28307
+ * elf32-ppc.c (ppc_elf_addr16_ha_reloc): Range check reloc offset.
+ * elf64-ppc.c (ppc64_elf_ha_reloc, ppc64_elf_brtaken_reloc): Likewise.
+ (ppc64_elf_toc64_reloc, ppc64_elf_prefix_reloc): Likewise.
+
+2021-09-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-07 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle internal-error in gdb_run_cmd
+ When reverting commit 5a20fadc841 the test-case
+ gdb.dwarf2/locexpr-data-member-location.exp fails like this:
+ ...
+ FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+ (GDB internal error)
+ ERROR: Could not resync from internal error (eof)
+ ...
+ and takes 1 minute to run.
+
+ The long running time is caused by running into a timeout in gdb_run_cmd, at
+ this point:
+ ...
+ (gdb) run ^M
+ The program being debugged has been started already.^M
+ Start it from the beginning? (y or n) y^M
+ /home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
+ Unexpected type field location kind: 4^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ Quit this debugging session? (y or n)
+ ...
+
+ Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it
+ in gdb_run_cmd, but stash the gdb output back into the buffer using
+ -notransfer, and let the caller proc runto deal with it.
+
+ After the fix, the test-case just takes 2 seconds.
+
+ Tested on x86_64-linux.
+
+2021-09-06 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: rename gdb/testsuite/gdb.arch/riscv64-unwind-prologue-with-ld-lw.c
+ A previous commit added the
+ gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its
+ associated file was named after a previous version of the test.
+
+ This commit fixes this and makes sure that all the files linked to this
+ testcase share the same prefix in the name.
+
+ Tested on riscv64 GNU/Linux.
+
+2021-09-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Handle eof in gdb_internal_error_resync
+ Before commit 5a20fadc841 the test-case
+ gdb.dwarf2/locexpr-data-member-location.exp fails like this:
+ ...
+ FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+ (GDB internal error)
+ ERROR: : spawn id exp9 not open
+ while executing
+ "expect {
+ -i exp9 -timeout 10
+ -re "Quit this debugging session\\? \\(y or n\\) $" {
+ send_gdb "n\n" answer
+ incr count
+ }
+ -re "Create ..."
+ ("uplevel" body line 1)
+ invoked from within
+ "uplevel $body" NONE : spawn id exp9 not open
+ ERROR: Could not resync from internal error (timeout)
+ ...
+
+ Fix the:
+ ...
+ ERROR: : spawn id exp9 not open
+ ...
+ by handling eof in gdb_internal_error_resync, such that we have instead:
+ ...
+ FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+ (GDB internal error)
+ ERROR: Could not resync from internal error (eof)
+ ...
+
+ Tested on x86_64-linux.
+
+2021-09-06 Tom Tromey <tom@tromey.com>
+
+ Remove some complaints.h includes
+ There are a few includes of complaints.h that aren't necessary. This
+ patch removes them. Tested by rebuilding.
+
+2021-09-06 Nick Clifton <nickc@redhat.com>
+
+ Fix an illegal memory access triggered by disassembling corrupt s390x binaries.
+ PR 28304
+ * elfxx-score7.c (score_elf_gprel15_reloc): If there is no output bfd
+ treat the reloc as undefined.
+
+ Fix potential use on an uninitialised vairable in the MCore assembler.
+
+ Fix potential uninitialised variable in microblaze assembler code.
+
+2021-09-06 Yinjun Zhang <yinjun.zhang@corigine.com>
+
+ Add a sanity check to the init_nfp6000_mecsr_sec() function in the NFP disassembler.
+
+2021-09-06 Alexandra Hájková <ahajkova@redhat.com>
+
+ gdbtypes.c: Add the case for FIELD_LOC_KIND_DWARF_BLOCK
+ The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for
+ switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error
+ under some circumstances.
+
+ Fixes bug 28030.
+
+2021-09-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp
+ On a machine on Open Build Service I'm running into a SIGILL for test-case
+ gdb.arch/amd64-disp-step-avx.exp:
+ ...
+ Program received signal SIGILL, Illegal instruction.^M
+ test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
+ 40 vmovsd ro_var(%rip),%xmm0^M
+ (gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
+ continue to test_rip_vex2_end
+ ...
+ The SIGILL happens when trying to execute the first avx instruction in the
+ executable.
+
+ I can't directly access the machine, but looking at the log for test-case
+ gdb.arch/i386-avx.exp, it seems that there's no avx support:
+ ...
+ Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
+ 68 if (have_avx ())^M
+ (gdb) print have_avx ()^M
+ $1 = 0^M
+ ...
+
+ Fix this by:
+ - adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
+ function from gdb.arch/i386-avx.c
+ - using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
+ and gdb/testsuite/gdb.arch/i386-avx.exp.
+
+ Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-09-04 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/26950
+ * gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
+ (have_avx): Move ...
+ * gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc.
+ * gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
+ * gdb/testsuite/gdb.arch/i386-avx.exp: Same.
+
+2021-09-04 Mike Frysinger <vapier@gentoo.org>
+
+ gnulib: import sys_wait
+ A few sims use this to emulate process syscalls.
+ Gdb builds seem to still be fine.
+
+2021-09-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-03 Tom Tromey <tromey@adacore.com>
+
+ Use CORE_ADDR as return type from x86_dr_low_get_addr
+ On a Windows build locally, watchpoints started failing. I tracked
+ this down to x86_dr_low_get_addr returning an 'unsigned long'... in
+ this particular build, this is a 32-bit type, but the inferior is a
+ 64-bit program.
+
+ This patch fixes the problem by changing the return type. No other
+ change is required, because this matches the function pointer in
+ struct x86_dr_low_type.
+
+2021-09-03 Kevin Buettner <kevinb@redhat.com>
+
+ Test case reproducing PR28030 bug
+ The original reproducer for PR28030 required use of a specific
+ compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR,
+ though it seems probable that other gcc versions might also be able to
+ reproduce the bug as well. This commit introduces a test case which,
+ using the DWARF assembler, provides a reproducer which is independent
+ of the compiler version. (Well, it'll work with whatever compilers
+ the DWARF assembler works with.)
+
+ To the best of my knowledge, it's also the first test case which uses
+ the DWARF assembler to provide debug info for a shared object. That
+ being the case, I provided more than the usual commentary which should
+ allow this case to be used as a template when a combo shared
+ library / DWARF assembler test case is required in the future.
+
+ I provide some details regarding the bug in a comment near the
+ beginning of locexpr-dml.exp.
+
+ This problem was difficult to reproduce; I found myself constantly
+ referring to the backtrace while trying to figure out what (else) I
+ might be missing while trying to create a reproducer. Below is a
+ partial backtrace which I include for posterity.
+
+ #0 internal_error (
+ file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575,
+ fmt=0xc520c0 "Unexpected type field location kind: %d")
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51
+ #1 0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930,
+ type=0x274c260, copied_types=0x30bb290)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575
+ #2 0x00000000006ef382 in copy_type_recursive (objfile=0x1635930,
+ type=0x274ca10, copied_types=0x30bb290)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602
+ #3 0x0000000000a7409a in preserve_one_value (value=0x24269f0,
+ objfile=0x1635930, copied_types=0x30bb290)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529
+ #4 0x000000000072012a in gdbscm_preserve_values (
+ extlang=0xc55720 <extension_language_guile>, objfile=0x1635930,
+ copied_types=0x30bb290)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94
+ #5 0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930,
+ copied_types=0x30bb290)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568
+ #6 0x0000000000a7428d in preserve_values (objfile=0x1635930)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579
+ #7 0x000000000082d514 in objfile::~objfile (this=0x1635930,
+ __in_chrg=<optimized out>)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549
+ #8 0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580)
+ at /usr/include/c++/11/bits/shared_ptr_base.h:348
+ #9 0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168
+ #10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>)
+ at /usr/include/c++/11/bits/shared_ptr_base.h:705
+ #11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>)
+ at /usr/include/c++/11/bits/shared_ptr_base.h:1154
+ #12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr (
+ this=0x190bb80, __in_chrg=<optimized out>)
+ at /usr/include/c++/11/bits/shared_ptr.h:122
+ #13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00,
+ __p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168
+ #14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=...,
+ __p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531
+ #15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position=
+ std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
+ at /usr/include/c++/11/bits/stl_list.h:1925
+ #16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position=
+ std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
+ at /usr/include/c++/11/bits/list.tcc:158
+ #17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0,
+ objfile=0x1635930)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210
+ #18 0x000000000082d3ae in objfile::unlink (this=0x1635930)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487
+ #19 0x000000000082e68c in objfile_purge_solibs ()
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875
+ #20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236
+ #21 0x00000000009a37fe in target_pre_inferior (from_tty=1)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496
+ #22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1,
+ run_how=RUN_NORMAL)
+ at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437
+
+ I'll note a few points regarding this backtrace:
+
+ Frame #1 is where the internal error occurs. It's caused by an
+ unhandled case for FIELD_LOC_KIND_DWARF_BLOCK. The fix for this bug
+ adds support for this case.
+
+ Frame #22 - it's a partial backtrace - shows that GDB is attempting to
+ (re)run the program. You can see the exact command sequence that was
+ used for reproducing this problem in the PR (at
+ https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a
+ nutshell, after starting the program and advancing to the appropriate
+ source line, GDB was asked to step into libstdc++; a "finish" command
+ was issued, returning a value. The fact that a value was returned is
+ very important. GDB was then used to step back into libstdc++. A
+ breakpoint was set on a source line in the library after which a "run"
+ command was issued.
+
+ Frame #19 shows a call to objfile_purge_solibs. It's aptly named.
+
+ Frame #7 is a call to the destructor for one of the objfile solibs; it
+ turned out to be the one for libstdc++.
+
+ Frames #6 thru #3 show various value preservation frames. If you look
+ at preserve_values() in gdb/value.c, the value history is preserved
+ first, followed by internal variables, followed by values for the
+ extension languages (python and guile).
+
+2021-09-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add untested case in gdb.gdb/complaints.exp
+ When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+ ...
+ (gdb) call clear_complaints()^M
+ No symbol "clear_complaints" in current context.^M
+ (gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
+ ...
+
+ The problem is that lto has optimized away clear_complaints, and consequently
+ the selftests cannot run.
+
+ Fix this by:
+ - using info function to detect presence of clear_complaints
+ - handling the absence of clear_complaints by calling untested
+ ...
+ (gdb) UNTESTED: gdb.gdb/complaints.exp: \
+ Cannot find clear_complaints, skipping test
+ ...
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-09-03 Tom de Vries <tdevries@suse.de>
+
+ * gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
+ be found.
+
+2021-09-03 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb: Enable finish command and inferior calls for _Float16 on amd64 and i386.
+ Values of type _Float16 and _Float16 _Complex can now be used on CPUs with
+ AVX512-FP16 support. Return values of those types are located in XMM0.
+ Compiler support for gcc and clang is in progress, see e.g.:
+ https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html
+
+ gdb/ChangeLog:
+ 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * amd64-tdep.c (amd64_classify): Classify _Float16 and
+ _Float16 _Complex as AMD64_SSE.
+ * i386-tdep.c (i386_extract_return_value): Read _Float16 and
+ _Float16 _Complex from xmm0.
+
+ gdb/testsuite/ChangeLog:
+ 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * gdb.arch/x86-avx512fp16-abi.c: New file.
+ * gdb.arch/x86-avx512fp16-abi.exp: New file.
+
+2021-09-03 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ Add half support for AVX512 register view.
+ This adds support for the half datatype, FP16, to the AVX512 register printing.
+
+ gdb/ChangeLog:
+ 2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * i386-tdep.c (i386_zmm_type) <v32_half>: New field.
+ (i386_ymm_type) <v16_half>: New field.
+ (i386_gdbarch_init): Add set_gdbarch_half_format.
+ * features/i386/64bit-avx512.xml: Add half type.
+ * features/i386/64bit-avx512.c: Regenerated.
+ * features/i386/64bit-sse.xml: Add half type.
+ * features/i386/64bit-sse.c: Regenerated.
+
+ gdb/testsuite/ChangeLog:
+ 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * gdb.arch/x86-avx512fp16.c: New file.
+ * gdb.arch/x86-avx512fp16.exp: New file.
+ * lib/gdb.exp (skip_avx512fp16_tests): New function.
+
+2021-09-03 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, i386: Enable AVX512-bfloat16 for i386 targets.
+ Values of type bfloat16 can also be used on 32-bit targets, which was missed
+ in the original enablement. This also adjusts the testcase to pass with
+ "unix/-m32", where only the lower 8 AVX registers are available.
+
+ gdb/ChangeLog:
+ 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * features/i386/32bit-sse.xml: Add bfloat16 type.
+ * features/i386/32bit-sse.c: Regenerated.
+
+ gdb/testsuite/ChangeLog:
+ 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
+
+ * gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
+
+2021-09-03 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add untested case in selftest_setup
+ When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+ ...
+ FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
+ (got interactive prompt)
+ FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
+ WARNING: Couldn't test self
+ ...
+ and similar in gdb.gdb/selftest.exp.
+
+ The first FAIL in more detail:
+ ...
+ (gdb) break captured_main^M
+ Function "captured_main" not defined.^M
+ Make breakpoint pending on future shared library load? (y or [n]) n^M
+ (gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
+ (got interactive prompt)
+ ...
+
+ The problem is that lto has optimized away the captured_main function
+ and consequently the selftests dependent on that cannot run.
+
+ Fix this by:
+ - using gdb_breakpoint to detect failure to set the breakpoint
+ - handling the failure to set a breakpoint by calling untested
+ - not emitting the warning if we've already got untested
+ such that we have:
+ ...
+ (gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
+ captured_main, skipping testcase.
+ ...
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-09-02 Tom de Vries <tdevries@suse.de>
+
+ * lib/selftest-support.exp: Emit untested when not being able to set
+ breakpoint.
+
+2021-09-03 Alan Modra <amodra@gmail.com>
+
+ ld testsuite tidy
+ Fixes a few issues:
+ 1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile
+ attempt to trim off -fsanitize options left us with ",undefined".
+ 2) ld_compile adds CFLAGS_FOR_TARGET itself, no need to pass it.
+ 3) CFLAGS might be needed linking bootstrap test.
+
+ * Makefile.am (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Trim off
+ all -fsanitize=*.
+ * Makefile.in: Regenerate.
+ * testsuite/ld-bootstrap/bootstrap.exp: Use CFLAGS when linking.
+ * testsuite/ld-cdtest/cdtest.exp: Use CFLAGS_FOR_TARGET when
+ linking.
+ * testsuite/ld-auto-import/auto-import.exp: Don't pass
+ CFLAGS_FOR_TARGET to ld_compile.
+ * testsuite/ld-cygwin/exe-export.exp: Likewise.
+ * testsuite/ld-elfvers/vers.exp: Likewise.
+ * testsuite/ld-elfvsb/elfvsb.exp: Likewise.
+ * testsuite/ld-elfweak/elfweak.exp: Likewise.
+ * testsuite/ld-gc/gc.exp: Likewise.
+ * testsuite/ld-pe/pe-compile.exp: Likewise.
+ * testsuite/ld-pe/pe-run.exp: Likewise.
+ * testsuite/ld-pe/pe-run2.exp: Likewise.
+ * testsuite/ld-plugin/plugin.exp: Likewise.
+ * testsuite/ld-shared/shared.exp: Likewise.
+ * testsuite/ld-elfcomm/elfcomm.exp: Likewise, and don't allow
+ nios2 testing to trash CFLAGS_FOR_TARGET.
+ * testsuite/ld-scripts/crossref.exp: Don't pass options in
+ CC_FOR_TARGET, do so in CFLAGS_FOR_TARGET instead.
+ * testsuite/ld-srec/srec.exp: Likewise, and for CXX.
+
+2021-09-03 Alan Modra <amodra@gmail.com>
+
+ CC_FOR_TARGET et al
+ The top level Makefile, the ld Makefile and others, define
+ CC_FOR_TARGET to be a compiler for the binutils target machine. This
+ is the compiler that should be used for almost all tests with C
+ source. There are _FOR_TARGET versions of CFLAGS, CXX, and CXXFLAGS
+ too. This was all supposed to work with the testsuite .exp files
+ using CC for the target compiler, and CC_FOR_HOST for the host
+ compiler, with the makefiles passing CC=$CC_FOR_TARGET and
+ CC_FOR_HOST=$CC to the runtest invocation.
+
+ One exception to the rule of using CC_FOR_TARGET is the native-only ld
+ bootstrap test, which uses the newly built ld to link a copy of
+ itself. Since the files being linked were created with the host
+ compiler, the boostrap test should use CC and CFLAGS, in case some
+ host compiler option provides needed libraries automatically.
+ However, bootstrap.exp used CC where it should have used CC_FOR_HOST.
+ I set about fixing that problem, then decided that playing games in
+ the makefiles with CC was a bad idea. Not only is it confusing, but
+ other dejagnu code knows about CC_FOR_TARGET. See dejagnu/target.exp.
+
+ So this patch gets rid of the makefile variable renaming and changes
+ all the .exp files to use the correct _FOR_TARGET variables.
+ CC_FOR_HOST and CFLAGS_FOR_HOST disappear. A followup patch will
+ correct bootstrap.exp to use CFLAGS, and a number of other things I
+ noticed.
+
+ binutils/
+ * testsuite/lib/binutils-common.exp (run_dump_test): Use
+ CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
+ ld/
+ * Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET
+ and similar. Pass variables with unchanged names. Don't set
+ CC_FOR_HOST or CFLAGS_FOR_HOST.
+ * Makefile.in: Regenerate.
+ * testsuite/config/default.exp: Update default CC and similar.
+ (compiler_supports, plug_opt): Use CC_FOR_TARGET.
+ * testsuite/ld-cdtest/cdtest.exp: Replace all uses of CC with
+ CC_FOR_TARGET, and similarly for CFLAGS, CXX and CXXFLAGS.
+ * testsuite/ld-auto-import/auto-import.exp: Likewise.
+ * testsuite/ld-cygwin/exe-export.exp: Likewise.
+ * testsuite/ld-elf/dwarf.exp: Likewise.
+ * testsuite/ld-elf/indirect.exp: Likewise.
+ * testsuite/ld-elf/shared.exp: Likewise.
+ * testsuite/ld-elfcomm/elfcomm.exp: Likewise.
+ * testsuite/ld-elfvers/vers.exp: Likewise.
+ * testsuite/ld-elfvsb/elfvsb.exp: Likewise.
+ * testsuite/ld-elfweak/elfweak.exp: Likewise.
+ * testsuite/ld-gc/gc.exp: Likewise.
+ * testsuite/ld-ifunc/ifunc.exp: Likewise.
+ * testsuite/ld-mn10300/mn10300.exp: Likewise.
+ * testsuite/ld-pe/pe-compile.exp: Likewise.
+ * testsuite/ld-pe/pe-run.exp: Likewise.
+ * testsuite/ld-pe/pe-run2.exp: Likewise.
+ * testsuite/ld-pie/pie.exp: Likewise.
+ * testsuite/ld-plugin/lto.exp: Likewise.
+ * testsuite/ld-plugin/plugin.exp: Likewise.
+ * testsuite/ld-scripts/crossref.exp: Likewise.
+ * testsuite/ld-selective/selective.exp: Likewise.
+ * testsuite/ld-sh/sh.exp: Likewise.
+ * testsuite/ld-shared/shared.exp: Likewise.
+ * testsuite/ld-srec/srec.exp: Likewise.
+ * testsuite/ld-undefined/undefined.exp: Likewise.
+ * testsuite/ld-unique/unique.exp: Likewise.
+ * testsuite/ld-x86-64/tls.exp: Likewise.
+ * testsuite/lib/ld-lib.exp: Likewise.
+ libctf/
+ * Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET.
+ Pass CC and CC_FOR_TARGET. Don't set CC_FOR_HOST.
+ * Makefile.in: Regenerate.
+ * testsuite/config/default.exp: Update default CC and similar.
+ * testsuite/lib/ctf-lib.exp (run_native_host_cmd): Use CC rather
+ than CC_FOR_HOST.
+ (run_lookup_test): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET.
+
+2021-09-03 Alan Modra <amodra@gmail.com>
+
+ pj: asan: out of bounds, ubsan: left shift of negative
+ * pj-dis.c: Include libiberty.h.
+ (print_insn_pj): Don't index op->arg past array bound. Don't
+ left shift negative int.
+
+ ubsan: alpha: member access within null pointer
+ * elf64-alpha.c (elf64_alpha_relax_with_lituse): Avoid UB.
+
+ ubsan: libctf: applying zero offset to null pointer
+ * ctf-open.c (init_symtab): Avoid ubsan error.
+
+2021-09-03 Alan Modra <amodra@gmail.com>
+
+ haiku tidy
+ --enable-maintainer-mode showed a number of files needing to be
+ regenerated, and in the case of ld/Makefile.in that the file was
+ regenerated by hand. Nothing to see here really.
+
+ ld/
+ * Makefile.am (ALL_64_EMULATION_SOURCES): Sort haiku entry.
+ * Makefile.in: Regenerate.
+ * po/BLD-POTFILES.in: Regenerate.
+ libctf/
+ * configure: Regenerate.
+ zlib/
+ * configure: Regenerate.
+
+2021-09-03 Fangrui Song <maskray@google.com>
+
+ gold: --export-dynamic-symbol: don't imply -u
+ to match GNU ld.
+
+ gold/
+ * archive.cc (Library_base::should_include_member): Don't handle
+ --export-dynamic-symbol.
+ * symtab.cc (Symbol_table::do_add_undefined_symbols_from_command_line):
+ Likewise.
+
+2021-09-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-02 Alexander von Gluck IV <kallisti5@unixzen.com>
+
+ Add support for the haiku operating system. These are the os support patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org. All of these architectures are working and most have been stable for quite some time.
+
+2021-09-02 Nick Clifton <nickc@redhat.com>
+
+ Fix the V850 assembler's generation of relocations for the st.b instruction.
+ PR 28292
+ gas * config/tc-v850.c (handle_lo16): Also accept
+ BFD_RELOC_V850_LO16_SPLIT_OFFSET.
+ * testsuite/gas/v850/split-lo16.s: Add extra line.
+ * testsuite/gas/v850/split-lo16.d: Update expected disassembly.
+
+ opcodes * v850-opc.c (D16): Use BFD_RELOC_V850_LO16_SPLIT_OFFSET in place
+ of BFD_RELOC_16.
+
+2021-09-02 Alan Modra <amodra@gmail.com>
+
+ SHT_SYMTAB_SHNDX handling
+ .symtab_shndx section contents is an array, one entry for each symbol
+ in .symtab, present when the number of symbols exceeds a little less
+ than 64k. Since the mapping is 1-1 with symbols there is no need to
+ keep both dest_index and destshndx_index in elf_sym_strtab. Instead,
+ just make sure that the shndx pointers to the swap functions are kept
+ NULL when .symtab_shndx does not exist. Also, strtabcount in the
+ linker's elf hash table is incremented in lock-step with the output
+ symcount, so that can disappear too.
+
+2021-09-02 Alan Modra <amodra@gmail.com>
+
+ PTR_ADD and NPTR_ADD for bfd.h
+ This defines a couple of macros used to avoid ubsan complaints about
+ calculations involving NULL pointers. PTR_ADD should be used in the
+ case where it is known that the offset is always zero with a NULL
+ pointer, and you'd like to know if a non-zero offset is ever used.
+ NPTR_ADD should be rarely used, but is defined for cases where a
+ non-zero offset is expected and should be ignored if the pointer is
+ NULL.
+
+ bfd/
+ * bfd-in.h (PTR_ADD, NPTR_ADD): Define.
+ * bfd-in2.h: Regenerate.
+ * elf-eh-frame.c (adjust_eh_frame_local_symbols): Avoid NULL
+ pointer calculations.
+ * elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise.
+ (bfd_elf_add_dt_needed_tag, elf_finalize_dynstr): Likewise.
+ (elf_link_add_object_symbols, elf_link_input_bfd): Likewise.
+ (bfd_elf_final_link, bfd_elf_gc_record_vtinherit): Likewise.
+ binutils/
+ * objdump.c (disassemble_section): Use PTR_ADD for rel_ppend.
+
+2021-09-02 Alan Modra <amodra@gmail.com>
+
+ obstack.h __PTR_ALIGN vs. ubsan
+ Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is
+ as large as a pointer), due to making calculations relative to a NULL
+ pointer. This patch avoids the problem by extracting out and
+ simplifying __BPTR_ALIGN for the usual case. I've continued to use
+ ptrdiff_t here, where it might be better to throw away __BPTR_ALIGN
+ entirely and just assume uintptr_t exists.
+
+ * obstack.h (__PTR_ALIGN): Expand and simplify __BPTR_ALIGN
+ rather than calculating relative to a NULL pointer.
+
+2021-09-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-09-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix dwo path in fission-*.S
+ [ Using $build for /home/vries/gdb_versions/devel/build to make things a bit
+ more readable. ]
+
+ When using make check// to run test-case gdb.dwarf2/fission-base.exp:
+ ...
+ ( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" )
+ ...
+ we run into:
+ ...
+ (gdb) file \
+ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M
+ Reading symbols from \
+ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M
+ warning: Could not find DWO CU \
+ $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \
+ (0x807060504030201) referenced by CU at offset 0xc7 [in module \
+ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M
+ ...
+
+ The problem is that the executable refers to the dwo file using path name
+ $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo,
+ while the actual dwo file is at
+ $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo.
+
+ This is caused by this trick in fission-base.S:
+ ...
+ #define XSTR(s) STR(s)
+ #define STR(s) #s
+ ...
+ .asciz XSTR(DWO) # DW_AT_GNU_dwo_name
+ ...
+ and:
+ ...
+ $ echo | gcc -E -dD - | grep "define unix"
+ ...
+
+ I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was
+ concerned that there could be quoting issues.
+
+ However, I've found other uses of this pattern, f.i. in
+ gdb/testsuite/gdb.base/corefile-buildid.exp:
+ ...
+ additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"]
+ ...
+
+ So, fix this by:
+ - using additional_flags=-DDWO=\"$dwo\" and
+ - using plain DWO instead of XSTR(DWO)
+
+ Likewise in other gdb.dwarf2/fission*.exp test-cases.
+
+ Tested on x86_64-linux, using make check//unix.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-09-01 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/28298
+ * gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO).
+ * gdb.dwarf2/fission-loclists-pie.S: Same.
+ * gdb.dwarf2/fission-loclists.S: Same.
+ * gdb.dwarf2/fission-reread.S: Same.
+ * gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\".
+ * gdb.dwarf2/fission-loclists-pie.exp: Same.
+ * gdb.dwarf2/fission-loclists.exp: Same.
+ * gdb.dwarf2/fission-reread.exp: Same.
+
+2021-09-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol search
+ On openSUSE Tumbleweed I ran into:
+ ...
+ (gdb) ptype outstring_func.part^M
+ No symbol "outstring_func" in current context.^M
+ (gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part
+ ...
+ while on openSUSE Leap 15.2 I have instead:
+ ...
+ (gdb) ptype string_func_^M
+ type = <unknown return type> ()^M
+ (gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_
+ ...
+
+ The difference is caused by the result for "info function string_func", which
+ is this for the latter:
+ ...
+ (gdb) info function string_func^M
+ All functions matching regular expression "string_func":^M
+ ^M
+ Non-debugging symbols:^M
+ 0x000000000040089c string_func_^M
+ ...
+ but this for the former:
+ ...
+ (gdb) info function string_func^M
+ All functions matching regular expression "string_func":^M
+ ^M
+ Non-debugging symbols:^M
+ 0x00000000004012bb string_func_^M
+ 0x00007ffff7bac5b0 outstring_func.part^M
+ 0x00007ffff7bb1a00 outstring_func.part^M
+ ...
+
+ The extra symbols are part of glibc:
+ ...
+ $ nm /lib64/libc.so.6 | grep string_func
+ 00000000000695b0 t outstring_func.part.0
+ 000000000006ea00 t outstring_func.part.0
+ ...
+
+ If glibc debug info is installed, we get instead:
+ ...
+ (gdb) info function string_func^M
+ All functions matching regular expression "string_func":^M
+ ^M
+ File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M
+ 236: static int outstring_func(int, size_t, const unsigned int *, FILE *);^M
+ ^M
+ File vfprintf-internal.c:^M
+ 236: static int outstring_func(int, size_t, const unsigned char *, FILE *);^M
+ ^M
+ Non-debugging symbols:^M
+ 0x00000000004012bb string_func_^M
+ ...
+ and the FAIL doesn't trigger.
+
+ Fix this by calling "info function string_func" before starting the exec, such
+ that only symbols of the exec are taken into account.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-09-01 Tom de Vries <tdevries@suse.de>
+
+ * gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for
+ find_mangled_name calls.
+
+2021-09-01 Yinjun Zhang <yinjun.zhang@corigine.com>
+
+ nfp: add validity check of island and me
+ AddressSanitizer detects heap-buffer-overflow when running
+ "objdump -D" for nfp .nffw files.
+
+ PR 27854
+ * nfp-dis.c (_NFP_ISLAND_MAX, _NFP_ME_MAX): Define.
+ (nfp_priv_data): ..and use here.
+ (_print_instrs): Sanity check island and menum.
+
+2021-09-01 Alan Modra <amodra@gmail.com>
+
+ PR28250, Null pointer dereference in debug_class_type_samep
+ Typo fix, obviously should be m1->variants != NULL, not
+ m1->variants == NULL.
+
+ PR 28250
+ * debug.c (debug_class_type_samep): Correct m1->variants test.
+
+2021-09-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-31 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove breakpoint_find_if
+ Remove breakpoint_find_if, replace its sole usage with using
+ all_breakpoints directly instead. At the same time, change return
+ types to use bool.
+
+ Change-Id: I9ec392236b4804b362d16ab563330b9c07311106
+
+2021-08-31 Nick Clifton <nickc@redhat.com>
+
+ Update the how-to-make-a-release document so that a check for empty manual pages is included. cf PR 28144
+
+2021-08-31 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Extend .insn directive to support hardcode encoding.
+ The .insn directive can let users use their own instructions, or
+ some new instruction, which haven't supported in the old binutils.
+ For example, if users want to use sifive cache instruction, they
+ cannot just write "cflush.d1.l1" in the assembly code, they should
+ use ".insn i SYSTEM, 0, x0, x10, -0x40". But the .insn directive
+ may not easy to use for some cases, and not so friendly to users.
+ Therefore, I believe most of the users will use ".word 0xfc050073",
+ to encode the instructions directly, rather than use .insn. But
+ once we have supported the mapping symbols, the .word directives
+ are marked as data, so disassembler won't dump them as instructions
+ as usual. I have discussed this with Kito many times, we all think
+ extend the .insn direcitve to support the hardcode encoding, is the
+ easiest way to resolve the problem. Therefore, there are two more
+ .insn formats are proposed as follows,
+
+ (original) .insn <type>, <operand1>, <operand2>, ...
+ .insn <insn-length>, <value>
+ .insn <value>
+
+ The <type> is string, and the <insn-length> and <value> are constants.
+
+ gas/
+ * config/tc-riscv.c (riscv_ip_hardcode): Similar to riscv_ip,
+ but assembles an instruction according to the hardcode values
+ of .insn directive.
+ * doc/c-riscv.texi: Document two new .insn formats.
+ * testsuite/gas/riscv/insn-fail.d: New testcases.
+ * testsuite/gas/riscv/insn-fail.l: Likewise.
+ * testsuite/gas/riscv/insn-fail.s: Likewise.
+ * testsuite/gas/riscv/insn.d: Updated.
+ * testsuite/gas/riscv/insn.s: Likewise.
+
+2021-08-31 John Baldwin <jhb@FreeBSD.org>
+
+ Use gdbfmt for vprintf_filtered.
+ gdbfmt was already used for printf_filtered, so using it for
+ vprintf_filtered is more consistent.
+
+ As a result, all callers of vfprintf_maybe_filtered now use gdbfmt, so
+ the function can be simplified to assume the gdbfmt case and remove
+ the associated bool argument. Similary, vprintf_filtered is now a
+ simple wrapper around vfprintf_filtered.
+
+2021-08-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-30 John Baldwin <jhb@FreeBSD.org>
+
+ fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.
+ The handler for 'info proc status' for native processes on FreeBSD
+ uses the 'j' size modifier along with uintmax_t / intmax_t casts to
+ output integer values for types such as off_t that are not aliases of
+ a basic C type such as 'int' or 'long'. printf_filtered does not
+ support the 'j' modifer, so this resulted in runtime errors in
+ practice:
+
+ (gdb) info proc stat
+ process 8674
+ Name: ls
+ State: T (stopped)
+ Parent process: 8673
+ Process group: 8674
+ Session id: 2779
+ Unrecognized format specifier 'j' in printf
+
+ Instead, use plongest and pulongest to generate the output strings of
+ these integer values.
+
+2021-08-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix build error in unittests/parallel-for-selftests.c
+ We get this error when building GDB on some platforms. I get it using
+ g++-10 on Ubuntu 20.04 (installed using the distro package). It was
+ also reported by John Baldwin, using a clang that uses libc++.
+
+ CXX unittests/parallel-for-selftests.o
+ cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++
+ /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c: In function 'void selftests::parallel_for::test(int)':
+ /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:53:30: error: use of deleted function 'std::atomic<int>::atomic(const std::atomic<int>&)'
+ 53 | std::atomic<int> counter = 0;
+ | ^
+ In file included from /usr/include/c++/9/future:42,
+ from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/thread-pool.h:29,
+ from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:26,
+ from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22:
+ /usr/include/c++/9/atomic:755:7: note: declared here
+ 755 | atomic(const atomic&) = delete;
+ | ^~~~~~
+ /usr/include/c++/9/atomic:759:17: note: after user-defined conversion: 'constexpr std::atomic<int>::atomic(std::atomic<int>::__integral_type)'
+ 759 | constexpr atomic(__integral_type __i) noexcept : __base_type(__i) { }
+ | ^~~~~~
+
+ I haven't dug to know why it does not happen everywhere, but this patch
+ fixes it by using the constructor to initialize the variable, rather
+ than the assignment operator.
+
+ Change-Id: I6b27958171bf6187f6a875657395fd10441db7e6
+
+2021-08-30 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: PR28291, Fix the gdb fails that PR27916 caused.
+ * According to PR28291, we get the following unexpected gdb behavior,
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x0000000000000000:
+ 0x0000000000000001:
+ 0x0000000000000002:
+ 0x0000000000000003:
+ End of assembler dump.
+
+ * This patch should fix it to the right behavior,
+
+ (gdb) disassemble 0x0,+4
+ Dump of assembler code from 0x0 to 0x4:
+ 0x0000000000000000: Cannot access memory at address 0x0
+
+ opcodes/
+ pr 28291
+ * riscv-dis.c (print_insn_riscv): Return STATUS if it is not zero.
+
+2021-08-30 Tom Tromey <tom@tromey.com>
+
+ Add some parallel_for_each tests
+ Tom de Vries noticed that a patch in the DWARF scanner rewrite series
+ caused a regression in parallel_for_each -- it started crashing in the
+ case where the number of threads is 0 (there was an unchecked use of
+ "n-1" that was used to size an array).
+
+ He also pointed out that there were no tests of parallel_for_each.
+ This adds a few tests of parallel_for_each, primarily testing that
+ different settings for the number of threads will work. This test
+ catches the bug that he found in that series.
+
+2021-08-30 Tom Tromey <tom@tromey.com>
+
+ Add a show function for "maint show worker-threads"
+ I wanted to see how many threads gdb thought it was using, but
+ "maint show worker-threads" only reported "unlimited". This patch
+ adds a show function so that it will now report the number of threads
+ gdb has started.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-08-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/cli] Don't assert on empty string for core-file
+ With current gdb we run into:
+ ...
+ $ gdb -batch '' ''
+ : No such file or directory.
+ pathstuff.cc:132: internal-error: \
+ gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \
+ Assertion `path != NULL && path[0] != '\0'' failed.
+ ...
+
+ Fix this by skipping the call to gdb_abspath in core_target_open in the
+ empty-string case, such that we have instead:
+ ...
+ $ gdb -batch '' ''
+ : No such file or directory.
+ : No such file or directory.
+ $
+ ...
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-08-30 Tom de Vries <tdevries@suse.de>
+
+ PR cli/28290
+ * gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the
+ empty-string case.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-30 Tom de Vries <tdevries@suse.de>
+
+ PR cli/28290
+ * gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests.
+
+2021-08-30 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: PR27916, Support mapping symbols.
+ Similar to ARM/AARCH64, we add mapping symbols in the symbol table,
+ to mark the start addresses of data and instructions. The $d means
+ data, and the $x means instruction. Then the disassembler uses these
+ symbols to decide whether we should dump data or instruction.
+
+ Consider the mapping-04 test case,
+ $ cat tmp.s
+ .text
+ .option norelax
+ .option norvc
+ .fill 2, 4, 0x1001
+ .byte 1
+ .word 0
+ .balign 8
+ add a0, a0, a0
+ .fill 5, 2, 0x2002
+ add a1, a1, a1
+ .data
+ .word 0x1 # No need to add mapping symbols.
+ .word 0x2
+
+ $ riscv64-unknown-elf-as tmp.s -o tmp.o
+ $ riscv64-unknown-elf-objdump -d tmp.o
+
+ Disassembly of section .text:
+
+ 0000000000000000 <.text>:
+ 0: 00001001 .word 0x00001001 # Marked $d, .fill directive.
+ 4: 00001001 .word 0x00001001
+ 8: 00000001 .word 0x00000001 # .byte + part of .word.
+ c: 00 .byte 0x00 # remaining .word.
+ d: 00 .byte 0x00 # Marked $d, odd byte of alignment.
+ e: 0001 nop # Marked $x, nops for alignment.
+ 10: 00a50533 add a0,a0,a0
+ 14: 20022002 .word 0x20022002 # Marked $d, .fill directive.
+ 18: 20022002 .word 0x20022002
+ 1c: 2002 .short 0x2002
+ 1e: 00b585b3 add a1,a1,a1 # Marked $x.
+ 22: 0001 nop # Section tail alignment.
+ 24: 00000013 nop
+
+ * Use $d and $x to mark the distribution of data and instructions.
+ Alignments of code are recognized as instructions, since we usually
+ fill nops for them.
+
+ * If the alignment have odd bytes, then we cannot just fill the nops
+ into the spaces. We always fill an odd byte 0x00 at the start of
+ the spaces. Therefore, add a $d mapping symbol for the odd byte,
+ to tell disassembler that it isn't an instruction. The behavior
+ is same as Arm and Aarch64.
+
+ The elf/linux toolchain regressions all passed. Besides, I also
+ disable the mapping symbols internally, but use the new objudmp, the
+ regressions passed, too. Therefore, the new objudmp should dump
+ the objects corretly, even if they don't have any mapping symbols.
+
+ bfd/
+ pr 27916
+ * cpu-riscv.c (riscv_elf_is_mapping_symbols): Define mapping symbols.
+ * cpu-riscv.h: extern riscv_elf_is_mapping_symbols.
+ * elfnn-riscv.c (riscv_maybe_function_sym): Do not choose mapping
+ symbols as a function name.
+ (riscv_elf_is_target_special_symbol): Add mapping symbols.
+ binutils/
+ pr 27916
+ * testsuite/binutils-all/readelf.s: Updated.
+ * testsuite/binutils-all/readelf.s-64: Likewise.
+ * testsuite/binutils-all/readelf.s-64-unused: Likewise.
+ * testsuite/binutils-all/readelf.ss: Likewise.
+ * testsuite/binutils-all/readelf.ss-64: Likewise.
+ * testsuite/binutils-all/readelf.ss-64-unused: Likewise.
+ gas/
+ pr 27916
+ * config/tc-riscv.c (make_mapping_symbol): Create a new mapping symbol.
+ (riscv_mapping_state): Decide whether to create mapping symbol for
+ frag_now. Only add the mapping symbols to text sections.
+ (riscv_add_odd_padding_symbol): Add the mapping symbols for the
+ riscv_handle_align, which have odd bytes spaces.
+ (riscv_check_mapping_symbols): Remove any excess mapping symbols.
+ (md_assemble): Marked as MAP_INSN.
+ (riscv_frag_align_code): Marked as MAP_INSN.
+ (riscv_init_frag): Add mapping symbols for frag, it usually called
+ by frag_var. Marked as MAP_DATA for rs_align and rs_fill, and
+ marked as MAP_INSN for rs_align_code.
+ (s_riscv_insn): Marked as MAP_INSN.
+ (riscv_adjust_symtab): Call riscv_check_mapping_symbols.
+ * config/tc-riscv.h (md_cons_align): Defined to riscv_mapping_state
+ with MAP_DATA.
+ (TC_SEGMENT_INFO_TYPE): Record mapping state for each segment.
+ (TC_FRAG_TYPE): Record the first and last mapping symbols for the
+ fragments. The first mapping symbol must be placed at the start
+ of the fragment.
+ (TC_FRAG_INIT): Defined to riscv_init_frag.
+ * testsuite/gas/riscv/mapping-01.s: New testcase.
+ * testsuite/gas/riscv/mapping-01a.d: Likewise.
+ * testsuite/gas/riscv/mapping-01b.d: Likewise.
+ * testsuite/gas/riscv/mapping-02.s: Likewise.
+ * testsuite/gas/riscv/mapping-02a.d: Likewise.
+ * testsuite/gas/riscv/mapping-02b.d: Likewise.
+ * testsuite/gas/riscv/mapping-03.s: Likewise.
+ * testsuite/gas/riscv/mapping-03a.d: Likewise.
+ * testsuite/gas/riscv/mapping-03b.d: Likewise.
+ * testsuite/gas/riscv/mapping-04.s: Likewise.
+ * testsuite/gas/riscv/mapping-04a.d: Likewise.
+ * testsuite/gas/riscv/mapping-04b.d: Likewise.
+ * testsuite/gas/riscv/mapping-norelax-04a.d: Likewise.
+ * testsuite/gas/riscv/mapping-norelax-04b.d: Likewise.
+ * testsuite/gas/riscv/no-relax-align.d: Updated.
+ * testsuite/gas/riscv/no-relax-align-2.d: Likewise.
+ include/
+ pr 27916
+ * opcode/riscv.h (enum riscv_seg_mstate): Added.
+
+ opcodes/
+ pr 27916
+ * riscv-dis.c (last_map_symbol, last_stop_offset, last_map_state):
+ Added to dump sections with mapping symbols.
+ (riscv_get_map_state): Get the mapping state from the symbol.
+ (riscv_search_mapping_symbol): Check the sorted symbol table, and
+ then find the suitable mapping symbol.
+ (riscv_data_length): Decide which data size we should print.
+ (riscv_disassemble_data): Dump the data contents.
+ (print_insn_riscv): Handle the mapping symbols.
+ (riscv_symbol_is_valid): Marked mapping symbols as invalid.
+
+2021-08-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Improve argument syntax of proc arange
+ The current syntax of proc arange is:
+ ...
+ proc arange { arange_start arange_length {comment ""} {seg_sel ""} } {
+ ...
+ and a typical call looks like:
+ ...
+ arange $start $len
+ ...
+
+ This style is somewhat annoying because if you want to specify the last
+ parameter, you need to give the default values of all the other optional ones
+ before as well:
+ ...
+ arange $start $len "" $seg_sel
+ ...
+
+ Update the syntax to:
+ ...
+ proc arange { options arange_start arange_length } {
+ parse_options {
+ { comment "" }
+ { seg_sel "" }
+ }
+ ...
+ such that a typical call looks like:
+ ...
+ arange {} $start $len
+ ...
+ and a call using seg_sel looks like:
+ ...
+ arange {
+ seg_sel $seg_sel
+ } $start $len
+ ...
+
+ Also update proc aranges, which already has an options argument, to use the
+ new proc parse_options.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2021-08-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-28 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Change indirect symbol from IR to undefined
+ bfd/
+
+ PR ld/28264
+ * elflink.c (_bfd_elf_merge_symbol): Change indirect symbol from
+ IR to undefined.
+
+ ld/
+
+ PR ld/28264
+ * testsuite/ld-plugin/lto.exp: Run PR ld/28264 test.
+ * testsuite/ld-plugin/pr28264-1.d: New file.
+ * testsuite/ld-plugin/pr28264-2.d: Likewise.
+ * testsuite/ld-plugin/pr28264-3.d: Likewise.
+ * testsuite/ld-plugin/pr28264-4.d: Likewise.
+ * testsuite/ld-plugin/pr28264.c: Likewise.
+ * testsuite/ld-plugin/pr28264.ver: Likewise.
+
+2021-08-28 Alan Modra <amodra@gmail.com>
+
+ PR28264, ld.bfd crash on linking efivar with LTO
+ PR 28264
+ PR 26978
+ * linker.c (_bfd_generic_link_add_one_symbol <MIND>): Check
+ that string is non-NULL.
+
+2021-08-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Don't write .gdb_index symbol table with empty entries
+ When comparing the sizes of the index files generated for shlib
+ outputs/gdb.dwarf2/dw2-zero-range/shr1.sl, I noticed a large difference
+ between .debug_names:
+ ...
+ $ gdb -q -batch $shlib -ex "save gdb-index -dwarf-5 ."
+ $ du -b -h shr1.sl.debug_names shr1.sl.debug_str
+ 61 shr1.sl.debug_names
+ 0 shr1.sl.debug_str
+ ...
+ and .gdb_index:
+ ...
+ $ gdb -q -batch $shlib -ex "save gdb-index ."
+ $ du -b -h shr1.sl.gdb-index
+ 8.2K shr1.sl.gdb-index
+ ...
+
+ The problem is that the .gdb_index contains a non-empty symbol table with only
+ empty entries.
+
+ Fix this by making the symbol table empty, such that we have instead:
+ ...
+ $ du -b -h shr1.sl.gdb-index
+ 184 shr1.sl.gdb-index
+ ...
+
+ Tested on x86_64-linux.
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.exp
+ Before commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in
+ dwarf assembly" we had in exec outputs/gdb.dlang/watch-loc/watch-loc a D
+ compilation unit at offset 0xc7:
+ ...
+ Compilation Unit @ offset 0xc7:
+ Length: 0x4c (32-bit)
+ Version: 4
+ Abbrev Offset: 0x64
+ Pointer Size: 8
+ <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
+ <d3> DW_AT_language : 19 (D)
+ ...
+ with a corresponding .debug_aranges entry:
+ ...
+ Offset into .debug_info: 0xc7
+ Pointer Size: 4
+ Segment Size: 0
+
+ Address Length
+ 004004a7 0000000b
+ 00000000 00000000
+ ...
+
+ After that commit we have a dummy CU at offset 0xc7 and the D compilation unit
+ at offset 0xd2:
+ ...
+ Compilation Unit @ offset 0xc7:
+ Length: 0x7 (32-bit)
+ Version: 4
+ Abbrev Offset: 0x64
+ Pointer Size: 8
+ Compilation Unit @ offset 0xd2:
+ Length: 0x4c (32-bit)
+ Version: 4
+ Abbrev Offset: 0x65
+ Pointer Size: 8
+ <0><dd>: Abbrev Number: 2 (DW_TAG_compile_unit)
+ <de> DW_AT_language : 19 (D)
+ ...
+ while the .debug_aranges entry still points to 0xc7.
+
+ The problem is that the test-case uses a hack (quoting from
+ commit 75f06e9dc59):
+ ...
+ [ Note: this is a non-trivial test-case. The file watch-loc-dw.S contains a
+ .debug_info section, but not an .debug_aranges section or any actual code.
+ The file watch-loc.c contains code and a .debug_aranges section, but no other
+ debug section. So, the intent for the .debug_aranges section in watch-loc.c
+ is to refer to a compilation unit in the .debug_info section in
+ watch-loc-dw.S. ]
+ ...
+ and adding the dummy CU caused that hack to stop working.
+
+ Fix this by moving the generation of .debug_aranges from watch-loc.c to
+ watch-loc.exp, such that we have:
+ ...
+ Offset into .debug_info: 0xd2
+ Pointer Size: 4
+ Segment Size: 0
+
+ Address Length
+ 004004a7 0000000b
+ 00000000 00000000
+ ...
+
+ Tested on x86_64-linux.
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Generate .debug_aranges entry for dummy CU
+ A best practise for DWARF [1] is to generate .debug_aranges entries for CUs
+ even if they have no address range.
+
+ Generate .debug_arange entries for the dummy CUs added by the DWARF assembler.
+
+ Tested on x86_64-linux.
+
+ [1] http://wiki.dwarfstd.org/index.php?title=Best_Practices
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add .debug_aranges in more test-cases
+ A couple of test-cases fail when run with target board cc-with-debug-names due
+ to missing .debug_aranges entries for the CUs added by the dwarf assembler.
+
+ Add a .debug_aranges entry for those CUs.
+
+ Tested on x86_64-linux.
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Support .debug_aranges in dwarf assembly
+ Add a proc aranges such that we can generate .debug_aranges sections in dwarf
+ assembly using:
+ ...
+ cu { label cu_label } {
+ ...
+ }
+
+ aranges {} cu_label {
+ arange $addr $len [<comment>] [$segment_selector]
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+2021-08-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add label option to proc cu
+ We can use current dwarf assembly infrastructure to declare a label that marks
+ the start of the CU header:
+ ...
+ declare_labels header_start_cu_a
+ _section ".debug_info"
+ header_start_cu_a : cu {} {
+ }
+ _section ".debug_info"
+ header_start_cu_b : cu {} {
+ }
+ ...
+ on the condition that we switch to the .debug_info section before, which makes
+ this style of use fragile.
+
+ Another way to achieve the same is to use the label as generated by the cu
+ proc itself:
+ ...
+ variable _cu_label
+ cu {} {
+ }
+ set header_start_cu_a $_cu_label
+ cu {} {
+ }
+ set header_start_cu_b $_cu_label
+ ...
+ but again that seems fragile given that adding a new CU inbetween will
+ silently result in the wrong value for the label.
+
+ Add a label option to proc cu such that we can simply do:
+ ...
+ cu { label header_start_cu_a } {
+ }
+ cu { label header_start_cu_b } {
+ }
+ ...
+
+ Tested on x86_64-linux.
+
+2021-08-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-26 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: remove some stray newlines in debug output
+ I spotted a couple of stray newlines that were left at the end of
+ debug message during conversion to the new debug output scheme. These
+ messages are part of the 'set debug lin-lwp 1' output.
+
+2021-08-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-24 Tom Tromey <tom@tromey.com>
+
+ Fix two regressions caused by CU / TU merging
+ PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test
+ suite when using the "fission" target board. They are both caused by
+ the patches that merge the list of CUs with the list of TUs (and to a
+ lesser degree by the patches to share DWARF data across objfiles), and
+ the underlying issue is the same: it turns out that reading a DWO can
+ cause new type units to be created. This means that the list of
+ dwarf2_per_cu_data objects depends on precisely which CUs have been
+ expanded. However, because the type units can be created while
+ expanding a CU means that the vector of CUs can expand while it is
+ being iterated over -- a classic mistake. Also, because a TU can be
+ added later, it means the resize_symtabs approach is incorrect.
+
+ This patch fixes resize_symtabs by removing it, and having set_symtab
+ resize the vector on demand. It fixes the iteration problem by
+ introducing a safe (index-based) iterator and changing the relevant
+ spots to use it.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893
+
+2021-08-24 Alan Modra <amodra@gmail.com>
+
+ Real programmers don't configure gcc using --with-ld
+ * testsuite/lib/ld-lib.exp (run_host_cmd): Give a clue as to why
+ gcc -B doesn't pick up the ld under test.
+
+2021-08-24 Alan Modra <amodra@gmail.com>
+
+ objdump -S test fail on mingw
+ FAIL: objdump -S
+ FAIL: objdump --source-comment
+ is seen on mingw for the simple reason that gcc adds a .exe suffix on
+ the output file if not already present. Fix that, and tidy some objcopy
+ tests.
+
+ * testsuite/lib/binutils-common.exp (exeext): New proc.
+ * testsuite/binutils-all/objcopy.exp (exe, test_prog): Use it here.
+ (objcopy_remove_relocations_from_executable): Catch objcopy errors.
+ Only run on ELF targets.
+ * testsuite/binutils-all/objdump.exp (exe): Set variable.
+ (test_build_id_debuglink, test_objdump_S): Use exe file suffix.
+
+2021-08-24 James Bowman (FTDI-UK) <james.bowman@ftdichip.com>
+
+ FT32: Remove recursion in ft32_opcode
+ The function ft32_opcode used recursion. This could cause a stack
+ overflow. Replaced with a pair of non-recursive functions.
+
+ PR 28169
+ * ft32-dis.c: Formatting.
+ (ft32_opcode1): Split out from..
+ (ft32_opcode): ..here.
+
+2021-08-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-23 Tom Tromey <tom@tromey.com>
+
+ Fix a latent bug in dw2-ranges-overlap.exp
+ dw2-ranges-overlap.exp creates a program where a psymtab has two
+ address ranges, and a function without debug info whose address is
+ between these two ranges. Then it sets a breakpoint on this function
+ and runs to it, expecting that the language should remain "auto; c"
+ when stopped.
+
+ However, this test case also has a "main" function described (briefly)
+ in the DWARF, and this function is given language C++. Also, a
+ breakpoint stop sets the current language to the language that was
+ used when setting the breakpoint.
+
+ My new DWARF scanner decides that this "main" is the main program and
+ sets the current language to C++ at startup, causing this test to
+ fail.
+
+ This patch fixes the test in a simple way, by introducing a new
+ function that takes the place of "main" in the DWARF. I think this
+ still exercises the original problem, but also avoids problems with my
+ branch.
+
+ It seemed safe to me to submit this separately.
+
+2021-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb] Fix 'not in executable format' error message
+ With trying to load a non-executable file into gdb, we run into PR26880:
+ ...
+ $ gdb -q -batch test.c
+ "0x7ffc87bfc8d0s": not in executable format: \
+ file format not recognized
+ ...
+
+ The problem is caused by using %ps in combination with the error function
+ (note that confusingly, it does work in combination with the warning
+ function).
+
+ Fix this by using plain "%s" instead.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-08-22 Tom de Vries <tdevries@suse.de>
+
+ PR gdb/26880
+ * gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to
+ error function.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-22 Tom de Vries <tdevries@suse.de>
+
+ PR gdb/26880
+ * gdb.base/non-executable.exp: New file.
+
+2021-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Use compiler-generated instead of gas-generated stabs
+ The test-case gdb.dwarf2/dw2-ranges.exp is the only one in the gdb testsuite
+ that uses gas-generated stabs.
+
+ While the use seems natural alongside the use of gas-generated dwarf in the
+ same test-case, there are a few known issues, filed on the gdb side as:
+ - PR symtab/12497 - "stabs: PIE relocation does not work"
+ - PR symtab/28221 - "[readnow, stabs] FAIL: gdb.dwarf2/dw2-ranges.exp: \
+ info line func"
+ and on the gas side as:
+ - PR gas/28233 - "[gas, --gstabs] Generate stabs more similar to gcc"
+
+ The test-case contains a KFAIL for PR12497, but it's outdated and fails to
+ trigger.
+
+ The intention of the test-case is to test gas-generated dwarf, and using
+ gcc-generated stabs instead of gas-generated stabs works fine.
+
+ Supporting compiler-generated stabs is already a corner-case for gdb, and
+ there's no current commitment/incentive to support/workaround gas-generated
+ stabs, which can be considered a corner-case of a corner-case.
+
+ Work around these problem by using compiler-generated stabs in the test-case.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-22 Tom de Vries <tdevries@suse.de>
+
+ * gdb.dwarf2/dw2-ranges.exp: Use compiler-generated stabs.
+
+2021-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add dummy start and end CUs in dwarf assembly
+ Say one compiles a hello.c:
+ ...
+ $ gcc -g hello.c
+ ...
+
+ On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the
+ first in .debug_info, nor the last, due to presence of debug information in
+ objects for sources like:
+ - ../sysdeps/x86_64/start.S
+ - init.c
+ - ../sysdeps/x86_64/crti.S
+ - elf-init.c
+ - ../sysdeps/x86_64/crtn.S.
+
+ On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the
+ first and the last in .debug_info.
+
+ This difference has caused me to find some errors in the dwarf assembly
+ using openSUSE, that didn't show up on other platforms.
+
+ Force the same situation on other platforms by adding a dummy start
+ and end CU.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-22 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/28235
+ * lib/dwarf.exp (Dwarf::dummy_cu): New proc.
+ (Dwarf::assemble): Add dummy start and end CU.
+
+2021-08-23 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix dw2-ranges-psym.exp with -readnow
+ When running test-case gdb.dwarf2/dw2-ranges-psym.exp with target board
+ -readnow, I run into:
+ ...
+ (gdb) file dw2-ranges-psym^M
+ Reading symbols from dw2-ranges-psym...^M
+ Expanding full symbols from dw2-ranges-psym...^M
+ (gdb) set complaints 0^M
+ (gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
+ ...
+
+ The problem is that the regexp expects a gdb prompt immediately after the
+ "Reading symbols" line.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-22 Tom de Vries <tdevries@suse.de>
+
+ * lib/gdb.exp (gdb_load_no_complaints): Update regexp to allow
+ "Expanding full symbols" Line.
+
+2021-08-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-22 Mike Frysinger <vapier@gentoo.org>
+
+ sim: m32r: add __linux__ hack for non-Linux hosts
+ The m32r Linux syscall emulation logic assumes the host environment
+ directly matches -- it's being run on 32-bit little endian Linux.
+ This breaks building for non-Linux systems, so put all the code in
+ __linux__ ifdef checks. This code needs a lot of love to make it
+ work everywhere, but let's at least unbreak it for non-Linux hosts.
+
+2021-08-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-20 Mike Frysinger <vapier@gentoo.org>
+
+ sim: nltvals: switch output mode to a directory
+ In preparation for this script generating more files, change the output
+ argument to specify a directory. This drops the stdout behavior, but
+ since no one really runs this tool directly, it's not a big deal.
+
+2021-08-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use bool in notify_command_param_changed_p and do_set_command
+ Trivial patch to use bool instead of int.
+
+ Change-Id: I9e5f8ee4305272a6671cbaaaf2f0484eff0d1ea5
+
+2021-08-19 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Put back 3 aborts in OP_E_memory
+ Put back 3 aborts where invalid lengths should have been filtered out.
+
+ gas/
+
+ PR binutils/28247
+ * testsuite/gas/i386/bad-bcast.s: Add a comment.
+
+ opcodes/
+
+ PR binutils/28247
+ * * i386-dis.c (OP_E_memory): Put back 3 aborts.
+
+2021-08-19 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Avoid abort on invalid broadcast
+ Print "{bad}" on invalid broadcast instead of abort.
+
+ gas/
+
+ PR binutils/28247
+ * testsuite/gas/i386/bad-bcast.d: New file.
+ * testsuite/gas/i386/bad-bcast.s: Likewise.
+ * testsuite/gas/i386/i386.exp: Run bad-bcast.
+
+ opcodes/
+
+ PR binutils/28247
+ * i386-dis.c (OP_E_memory): Print "{bad}" on invalid broadcast
+ instead of abort.
+
+2021-08-19 Aaron Merey <amerey@redhat.com>
+
+ gdb/solib: Refactor scan_dyntag
+ scan_dyntag is unnecessarily duplicated in solib-svr4.c and solib-dsbt.c.
+
+ Move this function to solib.c and rename it to gdb_bfd_scan_elf_dyntag.
+ Also add it to solib.h so it is included in both solib-svr4 and solib-dsbt.
+
+2021-08-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-18 Will Schmidt <will_schmidt@vnet.ibm.com>
+
+ [gdb] [rs6000] Add ppc64_linux_gcc_target_options method.
+ Add a method to set the gcc target options for the ppc64 targets.
+ This change sets an empty value, which allows the gcc
+ default values (-mcmodel=medium) be used, instead of -mcmodel=large
+ which is set by the default_gcc_target_options hook.
+
+ [gdb] [rs6000] Add ppc64*_gnu_triplet_regexp methods.
+ Add methods to set the target triplet so we can
+ find the proper gcc when our gcc is named of
+ the form powerpc64{le}-<foo>-gcc or ppc64{le}-<foo>-gcc.
+
+2021-08-18 Alan Modra <amodra@gmail.com>
+
+ Re: as: Replace the removed symbol with the versioned symbol
+ Some targets, typically embedded without shared libraries, replace the
+ relocation symbol with a section symbol (see tc_fix_adjustable).
+ Allow the test to pass for such targets. Fixes the following.
+
+ avr-elf +FAIL: symver symver16
+ d10v-elf +FAIL: symver symver16
+ dlx-elf +FAIL: symver symver16
+ ip2k-elf +FAIL: symver symver16
+ m68k-elf +FAIL: symver symver16
+ mcore-elf +FAIL: symver symver16
+ pj-elf +FAIL: symver symver16
+ s12z-elf +FAIL: symver symver16
+ visium-elf +FAIL: symver symver16
+ z80-elf +FAIL: symver symver16
+
+ PR gas/28157
+ * testsuite/gas/symver/symver16.d: Relax reloc match.
+
+2021-08-18 Alan Modra <amodra@gmail.com>
+
+ [GOLD] PowerPC64 relocation overflow for -Os register save/restore funcs
+ Fixes a silly mistake in calculating the address of -Os out-of-line
+ register save/restore function copies. Copies of these linker defined
+ functions are added to stub sections when the original (in
+ target->savres_section) can't be reached.
+
+ * powerpc.cc (Target_powerpc::Relocate::relocate): Correct address
+ calculation of out-of-line save/restore function copies.
+
+2021-08-18 Alan Modra <amodra@gmail.com>
+
+ Another ld script backtrack
+ * ldgram.y (length_spec): Throw away look-ahead NAME.
+
+2021-08-18 Mike Frysinger <vapier@gentoo.org>
+
+ gdb: fix spacing on CCLD silent rules
+
+ sim: nltvals: localize TARGET_<ERRNO> defines
+ Code should not be using these directly, instead they should be
+ resolving these dynamically via cb_host_to_target_errno maps.
+ Fix the Blackfin code and remove the defines out of the header
+ so no new code can rely on them.
+
+2021-08-18 Mike Frysinger <vapier@gentoo.org>
+
+ sim: rename ChangeLog files to ChangeLog-2021
+ Now that ChangeLog entries are no longer used for sim patches,
+ this commit renames all relevant sim ChangeLog to ChangeLog-2021,
+ similar to what we would do in the context of the "Start of New
+ Year" procedure.
+
+ The purpose of this change is to avoid people merging ChangeLog
+ entries by mistake when applying existing commits that they are
+ currently working on.
+
+ Also throw in a .gitignore entry to keep people from adding new
+ ChangeLog files anywhere in the sim tree.
+
+2021-08-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-17 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix thread_step_over_chain_length
+ If I debug a single-thread program and look at the infrun debug logs, I
+ see:
+
+ [infrun] start_step_over: stealing global queue of threads to step, length = 2
+
+ That makes no sense... turns out there's a buglet in
+ thread_step_over_chain_length, "num" should be initialized to 0. I
+ think this bug is a leftover from an earlier version of the code (not
+ merged upstream) that manually walked the list, where the first item was
+ implicitly counted (hence the 1).
+
+ Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
+
+2021-08-17 Shahab Vahedi <shahab@synopsys.com>
+
+ opcodes: Fix the auxiliary register numbers for ARC HS
+ The numbers for the auxiliary registers "tlbindex" and
+ "tlbcommand" of ARCv2HS are incorrect. This patch makes
+ the following changes to correct that error.
+
+ ,------------.-----------------.---------------.
+ | aux. reg. | old (incorrect) | new (correct) |
+ |------------+-----------------+---------------|
+ | tlbindex | 0x463 | 0x464 |
+ | tlbcommand | 0x464 | 0x465 |
+ `------------^-----------------^---------------'
+
+ opcodes/
+ 2021-08-17 Shahab Vahedi <shahab@synopsys.com>
+
+ * arc-regs.h (DEF): Fix the register numbers.
+
+2021-08-17 H.J. Lu <hjl.tools@gmail.com>
+
+ gdb: Don't assume r_ldsomap when r_version > 1 on Linux
+ The r_ldsomap field is specific to Solaris (part of librtld_db), and
+ should never be accessed for Linux. glibc is planning to add a field
+ to support multiple namespaces. But there will be no r_ldsomap when
+ r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets
+ to set r_ldsomap_offset to -1 and use them for Linux targets.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
+
+2021-08-17 H.J. Lu <hjl.tools@gmail.com>
+
+ gdbserver: Check r_version < 1 for Linux debugger interface
+ Update gdbserver to check r_version < 1 instead of r_version != 1 so
+ that r_version can be bumped for a new field in the glibc debugger
+ interface to support multiple namespaces. Since so far, the gdbserver
+ only reads fields defined for r_version == 1, it is compatible with
+ r_version >= 1.
+
+ All future glibc debugger interface changes will be backward compatible.
+ If there is ever the need for backward incompatible change to the glibc
+ debugger interface, a new DT_XXX element will be provided to access the
+ new incompatible interface.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11839
+
+2021-08-17 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [4/4] arm: Add Tag_PACRET_use build attribute
+ bfd/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+ 'Tag_PACRET_use' case.
+
+ binutils/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * readelf.c (arm_attr_tag_PAC_extension): Declare.
+ (arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+ elfcpp/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm.h: Define 'Tag_PACRET_use' enum.
+
+ gas/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (arm_convert_symbolic_attribute): Add
+ 'Tag_PACRET_use' to the attribute_table.
+
+ include/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PACRET_use'.
+
+2021-08-17 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [3/4] arm: Add Tag_BTI_use build attribute
+ bfd/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+ 'Tag_BTI_use' case.
+
+ binutils/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * readelf.c (arm_attr_tag_PAC_extension): Declare.
+ (arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+ elfcpp/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm.h: Define 'Tag_BTI_use' enum.
+
+ gas/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (arm_convert_symbolic_attribute): Add
+ 'Tag_BTI_use' to the attribute_table.
+
+ include/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_use'.
+
+2021-08-17 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [2/4] arm: Add Tag_BTI_extension build attribute
+ bfd/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+ 'Tag_BTI_extension' case.
+
+ binutils/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * readelf.c (arm_attr_tag_PAC_extension): Declare.
+ (arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+ elfcpp/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm.h: Define 'Tag_BTI_extension' enum.
+
+ gas/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (arm_convert_symbolic_attribute): Add
+ 'Tag_BTI_extension' to the attribute_table.
+
+ include/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_extension'.
+
+2021-08-17 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [1/4] arm: Add Tag_PAC_extension build attribute
+ bfd/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+ 'Tag_PAC_extension' case.
+
+ binutils/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * readelf.c (arm_attr_tag_PAC_extension): Declare.
+ (arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+ elfcpp/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm.h: Define 'Tag_PAC_extension' enum.
+
+ gas/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (arm_convert_symbolic_attribute): Add
+ 'Tag_PAC_extension' to the attribute_table.
+
+ include/
+ 2021-07-06 Andrea Corallo <andrea.corallo@arm.com>
+
+ * elf/arm.h (elf_arm_reloc_type): Add 'Tag_PAC_extension'.
+
+2021-08-17 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Always run fp tests
+ Always run fp tests since the size of .tfloat, .ds.x, .dc.x and .dcb.x
+ directive outputs is always 10 bytes. There is no need for fp-elf32 nor
+ fp-elf64.
+
+ PR gas/28230
+ * testsuite/gas/i386/fp-elf32.d: Removed.
+ * testsuite/gas/i386/fp-elf64.d: Likewise.
+ * testsuite/gas/i386/fp.s: Remove NO_TFLOAT_PADDING codes.
+ * testsuite/gas/i386/i386.exp: Don't run fp-elf32 nor fp-elf64.
+ Always run fp.
+
+2021-08-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-16 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Don't pad .tfloat directive output
+ .tfloat output should always be 10 bytes without padding, independent
+ of psABIs. In glibc, x86 assembly codes expect 10-byte .tfloat output.
+ This also reduces .ds.x output and .tfloat output with hex input from
+ 12 bytes to 10 bytes to match .tfloat output.
+
+ PR gas/28230
+ * NEWS: Mention changes of .ds.x output and .tfloat output with
+ hex input.
+ * config/tc-i386.c (x86_tfloat_pad): Removed.
+ * config/tc-i386.h (X_PRECISION_PAD): Changed to 0.
+ (x86_tfloat_pad): Removed.
+ * testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined,
+ add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x
+ directives.
+ * testsuite/gas/i386/i386.exp (ASFLAGS): Append
+ "--defsym NO_TFLOAT_PADDING=1" when running the fp test.
+
+2021-08-16 Tom Tromey <tromey@adacore.com>
+
+ Fix register regression in DWARF evaluator
+ On an internal test case, using an arm-elf target, commit ba5bc3e5a92
+ ("Make DWARF evaluator return a single struct value") causes a
+ regression. (It doesn't happen for any of the other cross targets
+ that I test when importing upstream gdb.)
+
+ I don't know if there's an upstream gdb test case showing the same
+ problem... I can only really run native tests with dejagnu AFAIK.
+
+ The failure manifests like this:
+
+ Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5
+
+ Whereas when it works it looks like:
+
+ Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5
+
+ The difference is that the new code uses the passed-in gdbarch,
+ whereas the old code used the frame's gdbarch, when handling
+ DWARF_VALUE_REGISTER.
+
+ This patch restores the use of the frame's arch.
+
+2021-08-16 Tom Tromey <tromey@adacore.com>
+
+ Fix Ada regression due to DWARF expression series
+ Commit 0579205aec4 ("Simplify dwarf_expr_context class interface")
+ caused a regression in the internal AdaCore test suite. I didn't try
+ to reproduce this with the GDB test suite, but the test is identical
+ to gdb.dwarf2/dynarr-ptr.exp.
+
+ The problem is that this change:
+
+ case DW_OP_push_object_address:
+ /* Return the address of the object we are currently observing. */
+ - if (this->data_view.data () == nullptr
+ - && this->obj_address == 0)
+ + if (this->m_addr_info == nullptr)
+
+ ... slightly changes the logic here. In particular, it's possible for
+ the caller to pass in a non-NULL m_addr_info, but one that looks like:
+
+ (top) p *this.m_addr_info
+ $15 = {
+ type = 0x29b7a70,
+ valaddr = {
+ m_array = 0x0,
+ m_size = 0
+ },
+ addr = 0,
+ next = 0x0
+ }
+
+ In this case, an additional check is needed. With the current code,
+ what happens instead is that the computation computes an incorrect
+ address -- but one that does not fail in read_memory, due to the
+ precise memory map of the embedded target in question.
+
+ This patch restores the old logic.
+
+2021-08-16 Patrick Monnerat <patrick@monnerat.net>
+
+ Notify observer of breakpoint auto-disabling
+ As breakpoint_modified observer is currently notified upon breakpoint stop
+ before handling auto-disabling when enable count is reached, the observer
+ is never notified of the disabling.
+
+ The problem affects:
+ - The MI interpreter enabled= value when reporting =breakpoint-modified
+ - A Python event handler for breakpoint_modified using the "enabled"
+ member of its parameter
+ - insight: breakpoint GUI window is not properly updated upon auto-disable
+
+ This patch moves the observer notification after the auto-disabling
+ code and implements corresponding tests for the MI and Python cases.
+
+ Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=23336
+
+ Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61
+
+2021-08-16 H.J. Lu <hjl.tools@gmail.com>
+
+ as: Replace the removed symbol with the versioned symbol
+ When a symbol removed by .symver is used in relocation and there is one
+ and only one versioned symbol, don't remove the symbol. Instead, mark
+ it to be removed and replace the removed symbol used in relocation with
+ the versioned symbol before generating relocation.
+
+ PR gas/28157
+ * symbols.c (symbol_flags): Add removed.
+ (symbol_entry_find): Updated.
+ (symbol_mark_removed): New function.
+ (symbol_removed_p): Likewise.
+ * symbols.h (symbol_mark_removed): New prototype.
+ (symbol_removed_p): Likewise.
+ * write.c (write_relocs): Call obj_fixup_removed_symbol on
+ removed fixp->fx_addsy and fixp->fx_subsy if defined.
+ (set_symtab): Don't add a symbol if symbol_removed_p returns true.
+ * config/obj-elf.c (elf_frob_symbol): Don't remove the symbol
+ if it is used on relocation. Instead, mark it as to be removed
+ and issue an error if the symbol has more than one versioned name.
+ (elf_fixup_removed_symbol): New function.
+ * config/obj-elf.h (elf_fixup_removed_symbol): New prototype.
+ (obj_fixup_removed_symbol): New.
+ * testsuite/gas/symver/symver11.d: Updated expected error
+ message.
+ * testsuite/gas/symver/symver16.d: New file.
+ * testsuite/gas/symver/symver16.s: Likewise.
+
+2021-08-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-14 Alan Modra <amodra@gmail.com>
+
+ ld script fill pattern expression
+ It turns out we do need to backtrack when parsing after all. The
+ fill_opt component in the section rule swiches to EXPRESSION and back
+ to SCRIPT, and to find the end of an expression it is necessary to
+ look ahead one token.
+
+ * ldgram.y (section): Throw away lookahead NAME token.
+ (overlay_section): Likewise.
+ * testsuite/ld-elf/overlay.t: Add fill pattern on overlays.
+ Test fill pattern before stupidly named normal sections too,
+ and before /DISCARD/.
+
+2021-08-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ ld lexer tidy, possibly break the world
+ This tidies the states in which ld lexer rules are enabled.
+ This change will quite likely trip over issues similar to those
+ mentioned in the new ldlex.l comments, so please test it out.
+
+ * ldgram.y (wildcard_name): Remove now unnecessary components.
+ * ldlex.l: Restrict many rules' states. Remove -l expression
+ state rule. Comment on lookahead state madness and need for
+ /DISCARD/ in expression state.
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ ld script lower-case absolute and sizeof_headers
+ I think these happened by accident, so let's see what breaks if they
+ are removed.
+
+ * ldlex.l: Remove lower case "absolute" and "sizeof_headers"
+ in non-mri mode.
+ * ld.texi: Remove sizeof_headers index.
+ * testsuite/ld-mmix/mmohdr1.ld: Use SIZEOF_HEADERS.
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ tidy mri script extern
+ MRI mode generally doesn't flip lexer states, so let's make MRI mode
+ "extern" not do so either.
+
+ * ldgram.y (extern_name_list): Don't change lex state here.
+ (ifile_p1): Change state here on EXTERN instead.
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ Re: PR28217, Syntax error when memory region contains a hyphen
+ I discovered some more errors when tightening up the lexer rules.
+ Just because we INCLUDE a file doesn't mean we've switched states.
+
+ PR 28217
+ * ldgram.y (statement): Don't switch lexer state on INCLUDE.
+ (mri_script_command, ifile_p1, memory_spec, section): Likewise.
+
+2021-08-13 Lifang Xia <lifang_xia@c-sky.com>
+
+ PR28168: [CSKY] Fix stack overflow in disassembler
+ PR 28168:
+ Stack overflow with a large float. %f is not a goot choice for this.
+ %f should be replaced with %.7g.
+
+ gas/
+ * testsuite/gas/csky/pr28168.d: New testcase for PR 28168.
+ * testsuite/gas/csky/pr28168.s: Likewise.
+ * testsuite/gas/csky/v2_float_part2.d: Following the new format.
+ * opcodes/csky-dis.c (csky_output_operand): %.7g replaces %f.
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ PR28217, Syntax error when memory region contains a hyphen
+ The saga of commit 40726f16a8d7 continues. This attacks the problem
+ of switching between SCRIPT and EXPRESSION state lexing by removing
+ the need to do so for phdrs like ":text". Instead {WILDCHAR}*
+ matching, the reason why ":text" lexed as one token, is restricted to
+ within the braces of a section or overlay statement. The new WILD
+ lexer state is switched at the non-optional brace tokens, so
+ ldlex_backup is no longer needed. I've also removed the BOTH state,
+ which doesn't seem to be needed any more. Besides rules involving
+ error reporting, there was just one place where SCRIPT appeared
+ without BOTH, the {WILDCHAR}* rule, three where BOTH appears without
+ SCRIPT for tokens that only need EXPRESSION state, and two where BOTH
+ appears alongside INPUT_LIST. (Since I'm editing the wild and
+ filename rules, removing BOTH and adding WILD can also be seen as
+ renaming the old BOTH state to SCRIPT and renaming the old SCRIPT
+ state to WILD with a reduced scope.)
+
+ As a followup, I'll look at removing EXPRESSION state from some lexer
+ rules that no longer need it due to this cleanup.
+
+ PR 28217
+ * ldgram.y (exp <ORIGIN, LENGTH>): Use paren_script_name.
+ (section): Parse within braces of section in wild mode, and
+ after brace back in script mode. Remove ldlex_backup call.
+ Similarly for OVERLAY.
+ (overlay_section): Similarly.
+ (script_file): Replace ldlex_both with ldlex_script.
+ * ldlex.h (ldlex_wild): Declare.
+ (ldlex_both): Delete.
+ * ldlex.l (BOTH): Delete. Remove state from all rules.
+ (WILD): New state. Enable many tokens in this state.
+ Enable filename match in SCRIPT mode. Enable WILDCHAR match
+ in WILD state, disable in SCRIPT mode.
+ (ldlex_wild): New function.
+ * ldfile.c (ldfile_try_open_bfd): Replace ldlex_both call with
+ ldlex_script.
+
+2021-08-13 Alan Modra <amodra@gmail.com>
+
+ ns32k configury
+ Since ns32k-netbsd is as yet not removed, just marked obsolete,
+ the target should still be accepted with --enable-obsolete.
+
+ I also enabled ns32k-openbsd in ld since there doesn't seem to be a
+ good reason why that target is not supported there but is elsewhere.
+
+ bfd/
+ * config.bfd: Allow ns32k-netbsd.
+ ld/
+ * configure.tgt: Allow ns32k-openbsd.
+
+2021-08-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-13 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: riscv_scan_prologue: handle LD and LW instructions
+ While working on the testsuite, I ended up noticing that GDB fails to
+ produce a full backtrace from a thread waiting in pthread_join. When
+ selecting the waiting thread and using the 'bt' command, the following
+ result can be observed:
+
+ (gdb) bt
+ #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
+ #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
+ Backtrace stopped: frame did not save the PC
+
+ On my platform, I do not have debug symbols for glibc, so I need to rely
+ on prologue analysis in order to unwind stack.
+
+ Here is what the function prologue looks like:
+
+ (gdb) disassemble __pthread_clockjoin_ex
+ Dump of assembler code for function __pthread_clockjoin_ex:
+ 0x0000003ff7fc42de <+0>: addi sp,sp,-144
+ 0x0000003ff7fc42e0 <+2>: sd s5,88(sp)
+ 0x0000003ff7fc42e2 <+4>: auipc s5,0xd
+ 0x0000003ff7fc42e6 <+8>: ld s5,-2(s5) # 0x3ff7fd12e0
+ 0x0000003ff7fc42ea <+12>: ld a5,0(s5)
+ 0x0000003ff7fc42ee <+16>: sd ra,136(sp)
+ 0x0000003ff7fc42f0 <+18>: sd s0,128(sp)
+ 0x0000003ff7fc42f2 <+20>: sd s1,120(sp)
+ 0x0000003ff7fc42f4 <+22>: sd s2,112(sp)
+ 0x0000003ff7fc42f6 <+24>: sd s3,104(sp)
+ 0x0000003ff7fc42f8 <+26>: sd s4,96(sp)
+ 0x0000003ff7fc42fa <+28>: sd s6,80(sp)
+ 0x0000003ff7fc42fc <+30>: sd s7,72(sp)
+ 0x0000003ff7fc42fe <+32>: sd s8,64(sp)
+ 0x0000003ff7fc4300 <+34>: sd s9,56(sp)
+ 0x0000003ff7fc4302 <+36>: sd a5,40(sp)
+
+ As far as prologue analysis is concerned, the most interesting part is
+ done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores
+ the RA (return address) register on the stack, which is the information
+ we are looking for in order to identify the caller.
+
+ In the current implementation of the prologue scanner, GDB stops when
+ hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do
+ with the 'ld' instruction. GDB thinks it reached the end of the
+ prologue but have not yet reached the important part, which explain
+ GDB's inability to unwind past this point.
+
+ The section of the prologue starting at <+4> until <+12> is used to load
+ the stack canary[1], which will then be placed on the stack at <+36> at
+ the end of the prologue.
+
+ In order to have the prologue properly handled, this commit proposes to
+ add support for the ld instruction in the RISC-V prologue scanner.
+ I guess riscv32 would use lw in such situation so this patch also adds
+ support for this instruction.
+
+ With this patch applied, gdb is now able to unwind past pthread_join:
+
+ (gdb) bt
+ #0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
+ #1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
+ #2 0x0000002aaaaaa88e in bar() ()
+ #3 0x0000002aaaaaa8c4 in foo() ()
+ #4 0x0000002aaaaaa8da in main ()
+
+ I have had a look to see if I could reproduce this easily, but in my
+ simple testcases using '-fstack-protector-all', the canary is loaded
+ after the RA register is saved. I do not have a reliable way of
+ generating a prologue similar to the problematic one so I forged one
+ instead.
+
+ The testsuite have been run on riscv64 ubuntu 21.01 with no regression
+ observed.
+
+ [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
+
+2021-08-12 Tom Tromey <tromey@adacore.com>
+
+ Update documentation to mention Pygments
+ Philippe Blain pointed out that the gdb documentation does not mention
+ that Pygments may be used for source highlighting. This patch updates
+ the docs to reflect how highlighting is actually done.
+
+2021-08-12 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make gdbarch_printable_names return a vector
+ I noticed that gdbarch_selftest::operator() leaked the value returned by
+ gdbarch_printable_names. Make gdbarch_printable_names return an
+ std::vector and update callers. That makes it easier for everyone
+ involved, less manual memory management.
+
+ Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
+
+2021-08-12 Carl Love <cel@us.ibm.com>
+
+ Improve forward progress test in python.exp
+ The test steps into func2 and than does an up to get back to the previous
+ frame. The test checks that the line number you are at after the up command
+ is greater than the line where the function was called from. The
+ assembly/codegen for the powerpc target includes a NOP after the
+ branch-link.
+
+ func2 (); /* Break at func2 call site. /
+ 10000694: 59 00 00 48 bl 100006ec
+ 10000698: 00 00 00 60 nop
+ return 0; / Break to end. */
+ 1000069c: 00 00 20 39 li r9,0
+
+ The PC at the instruction following the branch-link is 0x10000698 which
+ GDB.find_pc_line() maps to the same line number as the bl instruction.
+ GDB did move past the branch-link location thus making forward progress.
+
+ The following proposed fix adds an additional PC check to see if forward
+ progress was made. The line test is changed from greater than to greater
+ than or equal.
+
+2021-08-12 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ gdb:csky rm tdesc_has_registers in csky_register_name
+ As CSKY arch has not parsed target-description.xml in csky_gdbarch_init,
+ when a remote server, like csky-qemu or gdbserver, send a target-description.xml
+ to gdb, tdesc_has_registers will return ture, but tdesc_register_name (gdbarch, 0)
+ will return NULL, so a cmd "info registers r0" will not work.
+
+ Function of parsing target-description.xml will be add later for CSKY arch,
+ now it is temporarily removed to allow me to do other supported tests.
+
+ 2021-07-15 Jiangshuai Li <jiangshuai_li@c-sky.com>
+
+ * csky-tdep.c : not using tdesc funtions in csky_register_name
+
+2021-08-12 Alan Modra <amodra@gmail.com>
+
+ Re: gas: support NaN flavors
+ Fixes tic4x-coff FAIL: simple FP constants
+
+ * testsuite/gas/all/float.s: Make NaN tests conditional on hasnan.
+ * testsuite/gas/all/gas.exp: Define hasnan.
+
+2021-08-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-11 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Update the pass and fail strings of PR ld/28138 test
+ PR ld/28138
+ * testsuite/ld-plugin/lto.exp: Update the pass and fail strings
+ of PR ld/28138 test to indicate which part of the test passed
+ and failed.
+
+2021-08-11 Darius Galis <darius.galis@cyberthorstudios.com>
+
+ Fix a typo in the RX asse,bler. The Double-precision floating-point exception handling control register name is DECNT not DCENT.
+ * config/rx-parse.y (DECNT): Fixed typo.
+ * testsuite/gas/rx/dpopm.sm (DECNT): Fixed typo.
+ * testsuite/gas/rx/dpushm.sm (DECNT): Fixed typo.
+ * testsuite/gas/rx/macros.inc (DECNT): Fixed typo.
+
+2021-08-11 Nick Clifton <nickc@redhat.com>
+
+ Fix an internal error in the CSKY assembler when asked to resolve an overlarge constant.
+ PR 28215
+ * config/tc-csky.c (md_apply_fix): Correctly handle a fixup that
+ involves an overlarge constant.
+
+2021-08-11 Luis Machado <luis.machado@linaro.org>
+
+ Add 3 new PAC-related ARM note types
+ The following patch synchronizes includes/objdump/readelf with the Linux
+ Kernel in terms of ARM regset notes.
+
+ We're currently missing 3 of them:
+
+ NT_ARM_PACA_KEYS
+ NT_ARM_PACG_KEYS
+ NT_ARM_PAC_ENABLED_KEYS
+
+ We don't need GDB to bother with this at the moment, so this doesn't update
+ bfd/elf.c. If needed, we can do it in the future.
+
+ binutils/
+
+ * readelf.c (get_note_type): Handle new ARM PAC notes.
+
+ include/elf/
+
+ * common.h (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS)
+ (NT_ARM_PAC_ENABLED_KEYS): New constants.
+
+2021-08-11 Nick Clifton <nickc@redhat.com>
+
+ Updated Portuguese translation for the binutils sub-directory.
+
+2021-08-11 John Ericson <git@JohnEricson.me>
+
+ Deprecate a.out support for NetBSD targets.
+ As discussed previously, a.out support is now quite deprecated, and in
+ some cases removed, in both Binutils itself and NetBSD, so this legacy
+ default makes little sense. `netbsdelf*` and `netbsdaout*` still work
+ allowing the user to be explicit about there choice. Additionally, the
+ configure script warns about the change as Nick Clifton requested.
+
+ One possible concern was the status of NetBSD on NS32K, where only a.out
+ was supported. But per [1] NetBSD has removed support, and if it were to
+ come back, it would be with ELF. The binutils implementation is
+ therefore marked obsolete, per the instructions in the last message.
+
+ With that patch and this one applied, I have confirmed the following:
+
+ --target=i686-unknown-netbsd
+ --target=i686-unknown-netbsdelf
+ builds completely
+
+ --target=i686-unknown-netbsdaout
+ properly fails because target is deprecated.
+
+ --target=vax-unknown-netbsdaout builds completely except for gas, where
+ the target is deprecated.
+
+ [1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
+ ---
+ bfd/config.bfd | 43 +++++++++++++--------
+ bfd/configure.ac | 5 +--
+ binutils/testsuite/binutils-all/nm.exp | 2 +-
+ binutils/testsuite/lib/binutils-common.exp | 7 +---
+ config/picflag.m4 | 4 +-
+ gas/configure.tgt | 9 +++--
+ gas/testsuite/gas/arm/blx-bl-convert.d | 2 +-
+ gas/testsuite/gas/arm/blx-local-thumb.d | 2 +-
+ gas/testsuite/gas/sh/basic.exp | 2 +-
+ gdb/configure.host | 34 +++++++----------
+ gdb/configure.tgt | 2 +-
+ gdb/testsuite/gdb.asm/asm-source.exp | 6 +--
+ intl/configure | 2 +-
+ ld/configure.tgt | 44 +++++++++++-----------
+ ld/testsuite/ld-arm/arm-elf.exp | 4 +-
+ ld/testsuite/ld-elf/elf.exp | 2 +-
+ ld/testsuite/ld-elf/shared.exp | 4 +-
+ libiberty/configure | 4 +-
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: don't print backtrace when dumping core after an internal error
+ Currently, when GDB hits an internal error, and the user selects to
+ dump core, the recently added feature to write a backtrace to the
+ console will kick in, and print a backtrace as well as dumping the
+ core.
+
+ This was certainly not my intention when adding the backtrace on fatal
+ signal functionality, this feature was intended to produce a backtrace
+ when GDB crashes due to some fatal signal, internal errors should have
+ continued to behave as they did before, unchanged.
+
+ In this commit I set the signal disposition of SIGABRT back to SIG_DFL
+ just prior to the call to abort() that GDB uses to trigger the core
+ dump, this prevents GDB reaching the code that writes the backtrace to
+ the console.
+
+ I've also added a test that checks we don't see a backtrace on the
+ console after an internal error.
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: register SIGBUS, SIGFPE, and SIGABRT handlers
+ Register handlers for SIGBUS, SIGFPE, and SIGABRT. All of these
+ signals are setup as fatal signals that will cause GDB to terminate.
+ However, by passing these signals through the handle_fatal_signal
+ function, a user can arrange to see a backtrace when GDB
+ terminates (see maint set backtrace-on-fatal-signal).
+
+ In normal use of GDB there should be no user visible changes after
+ this commit. Only if GDB terminates with one of the above signals
+ will GDB change slightly, potentially printing a backtrace before
+ aborting.
+
+ I've added new tests for SIGFPE, SIGBUS, and SIGABRT.
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: print backtrace on fatal SIGSEGV
+ This commit adds a new maintenance feature, the ability to print
+ a (limited) backtrace if GDB dies due to a fatal signal.
+
+ The backtrace is produced using the backtrace and backtrace_symbols_fd
+ functions which are declared in the execinfo.h header, and both of
+ which are async signal safe. A configure check has been added to
+ check for these features, if they are not available then the new code
+ is not compiled into GDB and the backtrace will not be printed.
+
+ The motivation for this new feature is to aid in debugging GDB in
+ situations where GDB has crashed at a users site, but the user is
+ reluctant to share core files, possibly due to concerns about what
+ might be in the memory image within the core file. Such a user might
+ be happy to share a simple backtrace that was written to stderr.
+
+ The production of the backtrace is on by default, but can switched off
+ using the new commands:
+
+ maintenance set backtrace-on-fatal-signal on|off
+ maintenance show backtrace-on-fatal-signal
+
+ Right now, I have hooked this feature in to GDB's existing handling of
+ SIGSEGV only, but this will be extended to more signals in a later
+ commit.
+
+ One additional change I have made in this commit is that, when we
+ decide GDB should terminate due to the fatal signal, we now
+ raise the same fatal signal rather than raising SIGABRT.
+
+ Currently, this is only effecting our handling of SIGSEGV. So,
+ previously, if GDB hit a SEGV then we would terminate GDB with a
+ SIGABRT. After this commit we will terminate GDB with a SIGSEGV.
+
+ This feels like an improvement to me, we should still get a core dump,
+ but in many shells, the user will see a more specific message once GDB
+ exits, in bash for example "Segmentation fault" rather than "Aborted".
+
+ Finally then, here is an example of the output a user would see if GDB
+ should hit an internal SIGSEGV:
+
+ Fatal signal: Segmentation fault
+ ----- Backtrace -----
+ ./gdb/gdb[0x8078e6]
+ ./gdb/gdb[0x807b20]
+ /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20]
+ /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f]
+ ./gdb/gdb[0x1540f4c]
+ ./gdb/gdb[0x154034a]
+ ./gdb/gdb[0x9b002d]
+ ./gdb/gdb[0x9b014d]
+ ./gdb/gdb[0x9b1aa6]
+ ./gdb/gdb[0x9b1b0c]
+ ./gdb/gdb[0x41756d]
+ /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3]
+ ./gdb/gdb[0x41746e]
+ ---------------------
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ Segmentation fault (core dumped)
+
+ It is disappointing that backtrace_symbols_fd does not actually map
+ the addresses back to symbols, this appears, in part, to be due to GDB
+ not being built with -rdynamic as the manual page for
+ backtrace_symbols_fd suggests, however, even when I do add -rdynamic
+ to the build of GDB I only see symbols for some addresses.
+
+ We could potentially look at alternative libraries to provide the
+ backtrace (e.g. libunwind) however, the solution presented here, which
+ is available as part of glibc is probably a good baseline from which
+ we might improve things in future.
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: rename async_init_signals to gdb_init_signals
+ The async_init_signals has, for some time, dealt with async and sync
+ signals, so removing the async prefix makes sense I think.
+
+ Additionally, as pointed out by Pedro:
+
+ .....
+
+ The comments relating to SIGTRAP and SIGQUIT within this function are
+ out of date.
+
+ The comments for SIGTRAP talk about the signal disposition (SIG_IGN)
+ being passed to the inferior, meaning the signal disposition being
+ inherited by GDB's fork children. However, we now call
+ restore_original_signals_state prior to forking, so the comment on
+ SIGTRAP is redundant.
+
+ The comments for SIGQUIT are similarly out of date, further, the
+ comment on SIGQUIT talks about problems with BSD4.3 and vfork,
+ however, we have not supported BSD4.3 for several years now.
+
+ Given the above, it seems that changing the disposition of SIGTRAP is
+ no longer needed, so I've deleted the signal() call for SIGTRAP.
+
+ Finally, the header comment on the function now called
+ gdb_init_signals was getting quite out of date, so I've updated it
+ to (hopefully) better reflect reality.
+
+ There should be no user visible change after this commit.
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: register signal handler after setting up event token
+ This commit fixes the smallest of small possible bug related to signal
+ handling. If we look in async_init_signals we see code like this:
+
+ signal (SIGQUIT, handle_sigquit);
+ sigquit_token =
+ create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+
+ Then if we look in handle_sigquit we see code like this:
+
+ mark_async_signal_handler (sigquit_token);
+ signal (sig, handle_sigquit);
+
+ Finally, in mark_async_signal_handler we have:
+
+ async_handler_ptr->ready = 1;
+
+ Where async_handler_ptr will be sigquit_token.
+
+ What this means is that if a SIGQUIT arrive in async_init_signals
+ after handle_sigquit has been registered, but before sigquit_token has
+ been initialised, then GDB will most likely crash.
+
+ The chance of this happening is tiny, but fixing this is trivial, just
+ ensure we call create_async_signal_handler before calling signal, so
+ lets do that.
+
+ There are no tests for this. Trying to land a signal in the right
+ spot is pretty hit and miss. I did try changing the current HEAD GDB
+ like this:
+
+ signal (SIGQUIT, handle_sigquit);
+ raise (SIGQUIT);
+ sigquit_token =
+ create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+
+ And confirmed that this did result in a crash, after my change I tried
+ this:
+
+ sigquit_token =
+ create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+ signal (SIGQUIT, handle_sigquit);
+ raise (SIGQUIT);
+
+ And GDB now starts up just fine.
+
+ gdb/ChangeLog:
+
+ * event-top.c (async_init_signals): For each signal, call signal
+ only after calling create_async_signal_handler.
+
+2021-08-11 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: terminate upon receipt of SIGFPE
+ GDB's SIGFPE handling is broken, this is PR gdb/16505 and
+ PR gdb/17891.
+
+ We currently try to use an async event token to process SIGFPE. So,
+ when a SIGFPE arrives the signal handler calls
+ mark_async_signal_handler then returns, effectively ignoring the
+ signal (for now).
+
+ The intention is that later the event loop will see that the async
+ token associated with SIGFPE has been marked and will call the async
+ handler, which just throws an error.
+
+ The problem is that SIGFPE is not safe to ignore. Ignoring a
+ SIGFPE (unless it is generated artificially, e.g. by raise()) is
+ undefined behaviour, after ignoring the signal on many targets we
+ return to the instruction that caused the SIGFPE to be raised, which
+ immediately causes another SIGFPE to be raised, we get stuck in an
+ infinite loop. The behaviour is certainly true on x86-64.
+
+ To view this behaviour I simply added some dummy code to GDB that
+ performed an integer divide by zero, compiled this on x86-64
+ GNU/Linux, ran GDB and saw GDB hang.
+
+ In this commit, I propose to remove all special handling of SIGFPE and
+ instead just let GDB make use of the default SIGFPE action, that is,
+ to terminate the process.
+
+ The only user visible change here should be:
+
+ - If a user sends a SIGFPE to GDB using something like kill,
+ previously GDB would just print an error and remain alive, now GDB
+ will terminate. This is inline with what happens if the user
+ sends GDB a SIGSEGV from kill though, so I don't see this as an
+ issue.
+
+ - If a bug in GDB causes a real SIGFPE, previously the users GDB
+ session would hang. Now the GDB session will terminate. Again,
+ this is inline with what happens if GDB receives a SIGSEGV due to
+ an internal bug.
+
+ In bug gdb/16505 there is mention that it would be nice if GDB did
+ more than just terminate when receiving a fatal signal. I haven't
+ done that in this commit, but later commits will move in that
+ direction.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891
+
+2021-08-11 Alan Modra <amodra@gmail.com>
+
+ PR28198, Support # as linker script comment marker
+ PR 28198
+ * ldlex.l: Combine rules for handling newline, whitespace and
+ comments. Extend # comment handling to all states.
+
+2021-08-11 Alan Modra <amodra@gmail.com>
+
+ ldgram.y tidies
+ I've been tripped up before thinking the "end" rule was the "END"
+ token. Let's use a better name. The formatting changes are for
+ consistency within rules, and making it a little easier to visually
+ separate tokens from mid-rule actions.
+
+ * ldgram.y (separator): Rename from "end". Update uses.
+ (statement): Formatting. Move ';' match to beginning.
+ (paren_script_name): Formatting. Simplify.
+ (must_be_exp, section): Formatting.
+
+2021-08-11 Alan Modra <amodra@gmail.com>
+
+ Mention whitespace in script expressions
+ Inside an output section statement, ld's parser can't tell whether a
+ line
+ .+=4;
+ is an assignment to dot or a file named ".+=4".
+
+ * ld.texi (expressions): Mention need for whitespace.
+
+2021-08-11 Matt Jacobson <mhjacobson@me.com>
+
+ Add a -mno-dollar-line-separator command line option to the AVR assembler.
+ Some frontends, like the gcc Objective-C frontend, emit symbols with $
+ characters in them. The AVR target code in gas treats $ as a line separator,
+ so the code doesn?t assemble correctly.
+
+ Provide a machine-specific option to disable treating $ as a line separator.
+
+ * config/tc-avr.c (enum options): Add option flag.
+ (struct option): Add option -mno-dollar-line-separator.
+ (md_parse_option): Adjust treatment of $ when option is present.
+ * config/tc-avr.h: Use avr_line_separator_chars.
+
+2021-08-11 Nick Clifton <nickc@redhat.com>
+
+ Fix typo in previous delta
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ gas: fold IEEE encoding of -Inf with that of +Inf
+ The respective results differ only by the sign bits - there's no need to
+ have basically identical (partially even arch-specific) logic twice.
+ Simply set the sign bit at the end of encoding the various formats.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ gas: support NaN flavors
+ Like for infinity, there isn't just a single NaN. The sign bit may be
+ of interest and, going beyond infinity, whether the value is quiet or
+ signalling may be even more relevant to be able to encode.
+
+ Note that an anomaly with x86'es double extended precision NaN values
+ gets taken care of at the same time: For all other formats a positive
+ value with all mantissa bits set was used, while here a negative value
+ with all non-significant mantissa bits clear was chose for an unknown
+ reason.
+
+ For m68k, since I don't know their X_PRECISION floating point value
+ layout, a warning gets issued if any of the new flavors was attempted
+ to be encoded that way. However likely it may be that, given that the
+ code lives in a source file supposedly implementing IEEE-compliant
+ formats, the bit patterns of the individual words match x86'es, I didn't
+ want to guess so. And my very, very old paper doc doesn't even mention
+ floating point formats other than single and double.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ Arm64: leave .bfloat16 processing to common code
+ With x86 support having been implemented by extending atof-ieee.c, avoid
+ unnecessary code duplication in md_atof(). This will then also allow to
+ take advantage of adjustments made there without needing to mirror them
+ here.
+
+ Arm32: leave more .bfloat16 processing to common code
+ With x86 support having been implemented by extending atof-ieee.c, avoid
+ unnecessary code duplication in md_atof(). This will then also allow to
+ take advantage of adjustments made there without needing to mirror them
+ here.
+
+ gas: make 2nd argument of .dcb.* consistently optional
+ Unlike the forms consuming/producing integer data, the floating point
+ ones so far required the 2nd argument to be present, contrary to
+ documentation. To avoid code duplication, split float_length() out of
+ hex_float() (taking the opportunity to adjust error message wording).
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: introduce .bfloat16 directive
+ This is to be able to generate data acted upon by AVX512-BF16 and
+ AMX-BF16 insns. While not part of the IEEE standard, the format is
+ sufficiently standardized to warrant handling in config/atof-ieee.c.
+ Arm, where custom handling was implemented, may want to leverage this as
+ well. To be able to also use the hex forms supported for other floating
+ point formats, a small addition to the generic hex_float() is needed.
+
+ Extend existing x86 testcases.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86: introduce .hfloat directive
+ This is to be able to generate data passed to {,V}CVTPH2PS and acted
+ upon by AVX512-FP16 insns. To be able to also use the hex forms
+ supported for other floating point formats, a small addition to the
+ generic hex_float() is needed.
+
+ Extend existing x86 testcases.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86/ELF: fix .tfloat output with hex input
+ The ELF psABI-s are quite clear here: On 32-bit the data type is 12
+ bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
+ bytes long (with 6 bytes of padding). Make hex_float() capable of
+ handling such padding.
+
+ Note that this brings the emitted data size of .dc.x / .dcb.x in line
+ also for non-ELF targets; so far they were different depending on input
+ format (dec vs hex).
+
+ Extend the existing x86 testcases.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86/ELF: fix .ds.x output
+ The ELF psABI-s are quite clear here: On 32-bit the underlying data type
+ is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it
+ is 16 bytes long (with 6 bytes of padding). Make s_space() capable of
+ handling 'x' (and 'p') type floating point being other than 12 bytes
+ wide (also adjusting documentation). This requires duplicating the
+ definition of X_PRECISION in the target speciifc header; the compiler
+ would complain if this was out of sync with config/atof-ieee.c.
+
+ Note that for now padding space doesn't get separated from actual
+ storage, which means that things will work correctly only for little-
+ endian cases, and which also means that by specifying large enough
+ numbers padding space can be set to non-zero. Since the logic is needed
+ for a single little-endian architecture only for now, I'm hoping that
+ this might be acceptable for the time being; otherwise the change will
+ become more intrusive.
+
+ Note also that this brings the emitted data size of .ds.x vs .tfloat in
+ line for non-ELF targets as well; the issue will be even more obvious
+ when further taking into account a subsequent patch fixing .dc.x/.dcb.x
+ (where output sizes currently differ depending on input format).
+
+ Extend existing x86 testcases.
+
+2021-08-11 Jan Beulich <jbeulich@suse.com>
+
+ x86/ELF: fix .tfloat output
+ The ELF psABI-s are quite clear here: On 32-bit the data type is 12
+ bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
+ bytes long (with 6 bytes of padding). Make ieee_md_atof() capable of
+ handling such padding, and specify the needed padding for x86 (leaving
+ non-ELF targets alone for now). Split the existing x86 testcase.
+
+ x86: have non-PE/COFF BEOS be recognized as ELF
+ BEOS, unless explicitly requesting *-*-beospe* targets, uses standard
+ ELF. None of the newly enabled tests in the testsuite fail for me.
+
+2021-08-11 Alan Modra <amodra@gmail.com>
+
+ PR28163, Segment fault in function rl78_special_reloc
+ Relocation offset checks were completely missing in the rl78 backend,
+ allowing a relocation to write over memory anywhere. This was true
+ for rl78_special_reloc, a function primarily used when applying debug
+ relocations, and in rl78_elf_relocate_section used by the linker.
+
+ This patch fixes those problems by correcting inaccuracies in the
+ relocation howtos, then uses those howtos to sanity check relocation
+ offsets before applying relocations. In addition, the patch
+ implements overflow checking using the howto information rather than
+ the ad-hoc scheme implemented in relocate_section. I implemented the
+ overflow checking in rl78_special_reloc too.
+
+ * elf32-rl78.c (RL78REL, RL78_OP_REL): Add mask parameter.
+ (rl78_elf_howto_table): Set destination masks. Correct size and
+ bitsize of DIR32_REV. Correct complain_on_overflow for many relocs
+ as per tests in relocate_section. Add RH_SFR. Correct bitsize
+ for RH_SADDR. Set size to 3 and bitsize to 0 for all OP relocs.
+ (check_overflow): New function.
+ (rl78_special_reloc): Check that reloc address is within section.
+ Apply relocations using reloc howto. Check for overflow.
+ (RANGE): Delete.
+ (rl78_elf_relocate_section): Sanity check r_offset. Perform
+ overflow checking using reloc howto.
+
+2021-08-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-10 Tom Tromey <tom@tromey.com>
+
+ Ignore .debug_types when reading .debug_aranges
+ I noticed that the fission-reread.exp test case can cause a complaint
+ when run with --target_board=cc-with-debug-names:
+
+ warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
+
+ The bug here is that this executable has both .debug_info and
+ .debug_types, and both have a CU at offset 0x0. This triggers the
+ duplicate warning.
+
+ Because .debug_types doesn't provide any address ranges, these CUs can
+ be ignored. That is, this bug turns out to be another regression from
+ the info/types merger patch.
+
+ This patch fixes the problem by having this loop igore type units.
+ fission-reread.exp is updated to test for the bug.
+
+2021-08-10 Tom Tromey <tom@tromey.com>
+
+ Generalize addrmap dumping
+ While debugging another patch series, I wanted to dump an addrmap. I
+ came up with this patch, which generalizes the addrmap-dumping code
+ from psymtab.c and moves it to addrmap.c. psymtab.c is changed to use
+ the new code.
+
+2021-08-10 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit
+ I spotted what I think is a buglet in proceed_after_vfork_done. After a
+ vfork child exits or execs, we resume all the threads of the parent. To
+ do so, we iterate on all threads using iterate_over_threads with the
+ proceed_after_vfork_done callback. Each thread is resumed if the
+ following condition is true:
+
+ if (thread->ptid.pid () == pid
+ && thread->state == THREAD_RUNNING
+ && !thread->executing
+ && !thread->stop_requested
+ && thread->stop_signal () == GDB_SIGNAL_0)
+
+ where `pid` is the pid of the vfork parent. This is not multi-target
+ aware: since it only filters on pid, if there is an inferior with the
+ same pid in another target, we could end up resuming a thread of that
+ other inferior. The chances of the stars aligning for this to happen
+ are tiny, but still.
+
+ Fix that by iterating only on the vfork parent's threads, instead of on
+ all threads. This is more efficient, as we iterate on just the required
+ threads (inferiors have their own thread list), and we can drop the pid
+ check. The resulting code is also more straightforward in my opinion,
+ so it's a win-win.
+
+ Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a
+
+2021-08-10 Nick Clifton <nickc@redhat.com>
+
+ Updated Serbian and Russian translations for various sub-directories
+
+2021-08-10 George Barrett <bob@bob131.so>
+
+ guile: fix smob exports
+ Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added
+ the created class to the exports list of (oop goops); v2.1+ does not
+ implicitly create bindings in any modules. This means that the GDB
+ manual subsection documenting exported types is not quite right when GDB
+ is linked against Guile <v2.1 (types are exported from (oop goops))
+ instead of (gdb)) and incorrect when linked against Guile v2.1+ (types
+ are not bound to any variables at all!).
+
+ There is a range of cases in which it's necessary or convenient to be
+ able to refer to a GDB smob type, for instance:
+
+ - Pattern matching based on the type of a value.
+ - Defining GOOPS methods handling values from GDB (GOOPS methods
+ typically use dynamic dispatch based on the types of the arguments).
+ - Type-checking assertions when applying some defensive programming on
+ an interface.
+ - Generally any other situation one might encounter in a dynamically
+ typed language that might need some introspection.
+
+ If you're more familiar with Python, it would be quite similar to being
+ unable to refer to the classes exported from the GDB module (which is to
+ say: not crippling for the most part, but makes certain tasks more
+ difficult than necessary).
+
+ This commit makes a small change to GDB's smob registration machinery
+ to make sure registered smobs get exported from the current
+ module. This will likely cause warnings to the user about conflicting
+ exports if they load both (gdb) and (oop goops) from a GDB linked
+ against Guile v2.0, but it shouldn't impact functionality (and seemed
+ preferable to trying to un-export bindings from (oop goops) if v2.0
+ was detected).
+
+ [1]: This changed with Guile commit
+ 28d0871b553a3959a6c59e2e4caec1c1509f8595
+
+ gdb/ChangeLog:
+
+ 2021-06-07 George Barrett <bob@bob131.so>
+
+ * guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered
+ smob type from the current module.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-06-07 George Barrett <bob@bob131.so>
+
+ * gdb.guile/scm-gsmob.exp (test exports): Add tests to make
+ sure the smob types currently listed in the GDB manual get
+ exported from the (gdb) module.
+
+ Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7
+
+2021-08-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-09 Nick Clifton <nickc@redhat.com>
+
+ GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory.
+ * dwarf2dbg.c (get_directory_table_entry): Ensure that dir[0]
+ contains current working directory.
+ (out_dir_and_file_list): Likewise.
+ * testsuite/gas/elf/dwarf-5-dir0.s: New test source file.
+ * testsuite/gas/elf/dwarf-5-dir0.d: New test driver.
+ * testsuite/gas/elf/elf.exp: Run the new test.
+ * testsuite/gas/elf/dwarf-5-file0.d: Adjust expected output.
+ * testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+ * testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-08-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-08 Tom Tromey <tom@tromey.com>
+
+ Include objfiles.h in a few .c files
+ I found a few .c files that rely on objfiles.h, but that only include
+ it indirectly, via dwarf2/read.h -> psympriv.h. If that include is
+ removed (something my new DWARF indexer series does), then the build
+ will break.
+
+ It seemed harmless and correct to add these includes now, making the
+ eventual series a little smaller.
+
+2021-08-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-07 Alan Modra <amodra@gmail.com>
+
+ PR28186, SEGV elf.c:7991:30 in _bfd_elf_fixup_group_sections
+ PR 28186
+ * elf.c (_bfd_elf_fixup_group_sections): Don't segfault on
+ objcopy/strip with NULL output_section.
+
+2021-08-07 Alan Modra <amodra@gmail.com>
+
+ PR28176, rl78 complex reloc divide by zero
+ This is a bit more than just preventing the divide by zero. Most of
+ the patch is tidying up error reporting, so that for example, linking
+ an object file with a reloc stack underflow produces a linker error
+ rather than just displaying a message that might be ignored.
+
+ PR 28176
+ * elf32-rl78.c (RL78_STACK_PUSH, RL78_STACK_POP): Delete.
+ (rl78_stack_push, rl78_stack_pop): New inline functions.
+ (rl78_compute_complex_reloc): Add status and error message params.
+ Use new inline stack handling functions. Report stack overflow
+ or underflow, and divide by zero.
+ (rl78_special_reloc): Return status and error message from
+ rl78_compute_complex_reloc.
+ (rl78_elf_relocate_section): Similarly. Modernise reloc error
+ reporting. Delete unused bfd_reloc_other case. Don't assume
+ DIR24S_PCREL overflow is due to undefined function.
+ (rl78_offset_for_reloc): Adjust to suit rl78_compute_complex_reloc.
+
+2021-08-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Recognize .gdb_index symbol table with empty entries as empty
+ When reading a .gdb_index that contains a non-empty symbol table with only
+ empty entries, gdb doesn't recognize it as empty.
+
+ Fix this by recognizing that the constant pool is empty, and then setting the
+ symbol table to empty.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ PR symtab/28159
+ * dwarf2/read.c (read_gdb_index_from_buffer): Handle symbol table
+ filled with empty entries.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ PR symtab/28159
+ * gdb.dwarf2/dw2-zero-range.exp: Remove kfail.
+
+2021-08-06 Tom Tromey <tromey@adacore.com>
+
+ Unconditionally define _initialize_addrmap
+ The way that init.c is generated does not allow for an initialization
+ function to be conditionally defined -- doing so will result in a link
+ error.
+
+ This patch fixes a build problem that arises from such a conditional
+ definition. It can be reproduce with --disable-unit-tests.
+
+2021-08-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix zero address complaint for shlib
+ In PR28004 the following warning / Internal error is reported:
+ ...
+ $ gdb -q -batch \
+ -iex "set sysroot $(pwd -P)/repro" \
+ ./repro/gdb \
+ ./repro/core \
+ -ex bt
+ ...
+ Program terminated with signal SIGABRT, Aborted.
+ #0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
+ [Current thread is 1 (LWP 1762498)]
+ #1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
+ warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
+ but not in symtab.)
+ warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
+ but not in symtab.)
+ ...
+ #2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
+ [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
+ psymtab, but not in symtab.)
+
+ ) from repro/usr/lib/libstdc++.so.6
+ ...
+
+ The warning is about the following:
+ - in find_pc_sect_compunit_symtab we try to find the address
+ (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
+ - that fails, so we try again in the partial symtabs.
+ - we find a matching partial symtab
+ - however, the partial symtab has a full symtab, so
+ we should have found a matching symtab in the first step.
+
+ The addresses are:
+ ...
+ (gdb) info sym 0x7ff8feb2c218
+ __gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
+ section .text of repro/usr/lib/libstdc++.so.6
+ (gdb) info sym 0x7ff8feb2c21d
+ __gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
+ section .text of repro/usr/lib/libstdc++.so.6
+ ...
+ which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
+ ...
+ $ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
+ 000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
+ [clone .cold]
+ ...
+ which belong to function __gnu_debug::_Error_formatter::_M_error() in
+ /build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
+
+ The partial symtab that is found for the addresses is instead the one for
+ /build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
+ incorrect.
+
+ This happens as follows.
+
+ The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50:
+ ...
+ 00004b50 0000000000000000 0000000000000056
+ 00004b5a 00000000000a4790 00000000000a479c
+ 00004b64 00000000000a47a0 00000000000a47ac
+ ...
+
+ When reading the first range 0x0..0x56, it doesn't trigger the "start address
+ of zero" complaint here:
+ ...
+ /* A not-uncommon case of bad debug info.
+ Don't pollute the addrmap with bad data. */
+ if (range_beginning + baseaddr == 0
+ && !per_objfile->per_bfd->has_section_at_zero)
+ {
+ complaint (_(".debug_rnglists entry has start address of zero"
+ " [in module %s]"), objfile_name (objfile));
+ continue;
+ }
+ ...
+ because baseaddr != 0, which seems incorrect given that when loading the
+ shared library individually in gdb (and consequently baseaddr == 0), we do see
+ the complaint.
+
+ Consequently, we run into this case in dwarf2_get_pc_bounds:
+ ...
+ if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
+ return PC_BOUNDS_INVALID;
+ ...
+ which then results in this code in process_psymtab_comp_unit_reader being
+ called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
+ argument to 1:
+ ...
+ scan_partial_symbols (first_die, &lowpc, &highpc,
+ cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
+ ...
+ and consequently, the CU addrmap gets build using address info from the
+ functions.
+
+ During that process, addrmap_set_empty is called with a range that includes
+ 0x9c218 and 0x9c21d:
+ ...
+ (gdb) p /x start
+ $7 = 0x9989c
+ (gdb) p /x end_inclusive
+ $8 = 0xb200d
+ ...
+ but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
+ ...
+ 000040ae 00000000000b1ee0 00000000000b200e
+ 000040b9 000000000009989c 00000000000998c4
+ 000040c3 <End of list>
+ ...
+ and neither range includes 0x9c218 and 0x9c21d.
+
+ This is caused by this code in partial_die_info::read:
+ ...
+ if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
+ nullptr, tag))
+ has_pc_info = 1;
+ ...
+ which pretends that the function is located at addresses 0x9989c..0xb200d,
+ which is indeed not the case.
+
+ This patch fixes the first problem encountered: fix the "start address of
+ zero" complaint warning by removing the baseaddr part from the condition.
+ Same for dwarf2_ranges_process.
+
+ The effect is that:
+ - the complaint is triggered, and
+ - the warning / Internal error is no longer triggered.
+
+ This does not fix the observed problem in partial_die_info::read, which is
+ filed as PR28200.
+
+ Tested on x86_64-linux.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/ChangeLog:
+
+ 2021-07-29 Simon Marchi <simon.marchi@polymtl.ca>
+ Tom de Vries <tdevries@suse.de>
+
+ PR symtab/28004
+ * gdb/dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
+ Fix zero address complaint.
+ * gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test.
+ * gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test.
+ * gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ Re: Add tests for Intel AVX512_FP16 instructions
+ * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Pass with
+ mingw section padding.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ chew ubsan warning
+ It matters not at all if pc is incremented from its initial NULL
+ value, but avoid this silly runtime ubsan error.
+
+ * doc/chew.c (perform): Avoid incrementing NULL pc.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ bfd_reloc_offset_in_range overflow
+ This patch is more about the style of bounds checking we ought to use,
+ rather than a real problem. An overflow of "octet + reloc_size" can
+ only happen with huge sections which would certainly cause out of
+ memory errors.
+
+ * reloc.c (bfd_reloc_offset_in_range): Avoid possible overflow.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ PR28175, Segment fault in coff-tic30.c reloc_processing
+ The obj_convert table shouldn't be accessed without first checking the
+ index against the table size.
+
+ PR 28175
+ * coff-tic30.c (reloc_processing): Sanity check reloc symbol index.
+ * coff-z80.c (reloc_processing): Likewise.
+ * coff-z8k.c (reloc_processing): Likewise.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ PR28173, nds32_elf_howto_table index out of bounds
+ Indexing the howto table was seriously broken by a missing entry, and
+ use of assertions about user input rather than testing the input.
+
+ PR 28173
+ * elf32-nds32.c (nds32_elf_howto_table): Add missing empty howto.
+ (bfd_elf32_bfd_reloc_type_table_lookup): Replace assertions with
+ range checks. Return NULL if unsupported reloc type. Remove
+ dead code. Take an unsigned int param.
+ (nds32_info_to_howto_rel): Test for NULL howto or howto name
+ return from lookup. Remove assertion.
+ (nds32_info_to_howto): Remove unnecessary ATTRIBUTE_UNUSED.
+ Test for NULL howto or howto name return from lookup.
+
+2021-08-06 Alan Modra <amodra@gmail.com>
+
+ PR28172, bfin_pcrel24_reloc heap-buffer-overflow
+ bfin pcrel24 relocs are weird, they apply to the reloc address minus
+ two. That means reloc addresses of 0 and 1 are invalid. Check that,
+ and fix other reloc range checking.
+
+ PR 28172
+ * elf32-bfin.c (bfin_pcrel24_reloc): Correct reloc range check.
+ (bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc): Likewise.
+ (bfin_final_link_relocate): Likewise.
+
+2021-08-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-05 Will Schmidt <will_schmidt@vnet.ibm.com>
+
+ [PATCH] GDB Testsuite, update compile-cplus.exp
+ [PATCH] GDB Testsuite, update compile-cplus.exp
+
+ Update the gdb.compile/compile-cplus.exp test to
+ handle errors generated when passing bad arguments
+ into the gdb-compile command.
+ This matches changes made to gdb.compile/compile.exp
+ in the past as part of
+ "Migrate rest of compile commands to new options framework"
+ e6ed716cd5514c08b9d7c469d185b1aa177dbc22
+
+2021-08-05 Will Schmidt <will_schmidt@vnet.ibm.com>
+
+ [gdb] Handle .TOC. sections during gdb-compile for rs6000 target.
+ [gdb] Handle .TOC. sections during gdb-compile for rs6000 target.
+
+ When we encounter a .TOC. symbol in the object we are loading,
+ we need to associate this with the .toc section in order to
+ properly resolve other symbols in the object. IF a .toc section
+ is not found, iterate the sections until we find one with the
+ SEC_ALLOC flag. If that also fails, fall back to using
+ the *ABS* section, pointed to by bfd_abs_section_ptr.
+
+2021-08-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: gdb.base/attach.exp: expose bug when testing with native-extended-gdbserver
+ In gdb.base/attach.exp, proc do_attach_failure_tests, we attach to a
+ process. When then try to attach to the same process in another
+ inferior, expecting it to fail. We then come back to the first inferior
+ and try to kill it, to clean up the test. When using the
+ native-extended-gdbserver board, this "kill" test passes, even though it
+ didn't actually work:
+
+ add-inferior
+ [New inferior 2]
+ Added inferior 2 on connection 1 (extended-remote localhost:2347)
+ (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: add empty inferior 2
+ inferior 2
+ [Switching to inferior 2 [<null>] (<noexec>)]
+ (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 2
+ attach 817032
+ Attaching to process 817032
+ Attaching to process 817032 failed
+ (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
+ inferior 1
+ [Switching to inferior 1 [process 817032] (/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/attach/attach)]
+ [Switching to thread 1.1 (Thread 817032.817032)]
+ #0 main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
+ 19 while (! should_exit)
+ (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
+ kill
+ Kill the program being debugged? (y or n) y
+ Remote connection closed <==== That's unexpected
+ (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures
+
+ When the second attach fails, gdbserver seems to break the connection
+ (it hangs up on the existing remote target) and start listening again
+ for incoming connections. This is documented in PR 19558 [1].
+
+ Make the expected output regexp for the kill command tighter (it
+ currently accepts anything). Use "set confirm off" so we don't have to
+ deal with the confirmation. And to be really sure the extended-remote
+ target still works, try to run the inferior again after killing. The
+ now tests are kfail'ed when the target is gdbserver.
+
+ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19558
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.base/attach.exp (do_attach_failure_tests): Make kill
+ regexp tighter, run inferior after killing it. Kfail when
+ target is gdbserver.
+
+ Change-Id: I99c5cd3968ce2ec962ace35b016f842a243b7a0d
+
+2021-08-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run
+ When running this test with the native-extended-gdbserver, we get:
+
+ main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
+ 19 while (! should_exit)
+ The program being debugged has been started already.
+ Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt
+ y
+ Don't know how to run. Try "help target".
+ (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main
+
+ This test tests using both "-p <pid>" and "-ex start" on the command line,
+ making sure that we first attach and then run.
+
+ Normally, after that "y", we should see the program running again.
+ However, a particuliarity of the native-extended-gdbserver is that it
+ uses "set auto-connect-native-target off" on the command line. The full
+ GDB command line is:
+
+ ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \
+ -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \
+ -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start
+
+ The attach succeeds. I guess it is done before "set
+ auto-connect-native-target off", or it somehow bypasses it. When the
+ "start" is executed, the native target is unpushed, while killing the
+ existing process, but not re-pushed, due to "set
+ auto-connect-native-target off". So we get that "Don't know how to run"
+ message.
+
+ Really, I think it's a case of the test doing things incompatible with
+ the board, I think it should just be skipped. And as we can see with
+ the current code, there were some attempts at doing this, just using the
+ wrong checks:
+
+ - isnative: this is a dejagnu proc which checks if the target board has
+ the same triplet as the build machine. In the case of
+ native-extended-gdbserver, it does.
+ - is_remote target: this checks whether the target board is remote, as
+ in executing on a different machin. native-extended-gdbserver is not
+ remote.
+
+ Since the --pid option specifically attaches to a process using the
+ native target, change the test to use gdb_is_target_native instead.
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.base/attach.exp (test_command_line_attach_run): Use
+ gdb_is_target_native to check if test is supported.
+
+ Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0
+
+2021-08-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: target_waitstatus_to_string: print extra info for FORKED, VFORKED, EXECD
+ Print the extra information contained in target_waitstatus for these
+ events. For TARGET_WAITKIND_{FORKED,VFORKED}, the extra information is
+ contained in related_pid, and is the ptid of the new process. For
+ TARGET_WAITKIND_EXECD, it,s the exec'd path name in execd_pathname.
+ Print it using the same format used for TARGET_WAITKIND_STOPPED and
+ others.
+
+ Here are sample outputs for all three events:
+
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 726890.726890.0 [process 726890],
+ [infrun] print_target_wait_results: status->kind = vforked, related_pid = 726894.726894.0
+
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 727045.727045.0 [process 727045],
+ [infrun] print_target_wait_results: status->kind = forked, related_pid = 727049.727049.0
+
+ [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+ [infrun] print_target_wait_results: 727119.727119.0 [process 727119],
+ [infrun] print_target_wait_results: status->kind = execd, execd_pathname = /usr/bin/ls
+
+ Change-Id: I4416a74e3bf792a625a68bf26c51689e170f2184
+
+2021-08-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use ptid_t::to_string in print_target_wait_results
+ The ptid_t::to_string method was introduced recently, to format a ptid_t
+ for debug purposes. It formats the ptid exactly as is done in
+ print_target_wait_results, so make print_target_wait_results use it.
+
+ Change-Id: I0a81c8040d3e1858fb304cb28366b34d94eefe4d
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Add as_lval argument to expression evaluator
+ There are cases where the result of the expression evaluation is
+ expected to be in a form of a value and not location description.
+
+ One place that has this requirement is dwarf_entry_parameter_to_value
+ function, but more are expected in the future. Until now, this
+ requirement was fulfilled by extending the evaluated expression with
+ a DW_OP_stack_value operation at the end.
+
+ New implementation, introduces a new evaluation argument instead.
+
+ * dwarf2/expr.c (dwarf_expr_context::fetch_result): Add as_lval
+ argument.
+ (dwarf_expr_context::eval_exp): Add as_lval argument.
+ * dwarf2/expr.h (struct dwarf_expr_context): Add as_lval
+ argument to fetch_result and eval_exp methods.
+ * dwarf2/frame.c (execute_stack_op): Add as_lval argument.
+ * dwarf2/loc.c (dwarf_entry_parameter_to_value): Remove
+ DWARF expression extension.
+ (dwarf2_evaluate_loc_desc_full): Add as_lval argument support.
+ (dwarf2_evaluate_loc_desc): Add as_lval argument support.
+ (dwarf2_locexpr_baton_eval): Add as_lval argument support.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Simplify dwarf_expr_context class interface
+ Idea of this patch is to get a clean and simple public interface for
+ the dwarf_expr_context class, looking like:
+
+ - constructor,
+ - destructor,
+ - push_address method and
+ - evaluate method.
+
+ Where constructor should only ever require a target architecture
+ information. This information is held in per object file
+ (dwarf2_per_objfile) structure, so it makes sense to keep that
+ structure as a constructor argument. It also makes sense to get the
+ address size from that structure, but unfortunately that interface
+ doesn't exist at the moment, so the dwarf_expr_context class user
+ needs to provide that information.
+
+ The push_address method is used to push a CORE_ADDR as a value on
+ top of the DWARF stack before the evaluation. This method can be
+ later changed to push any struct value object on the stack.
+
+ The evaluate method is the method that evaluates a DWARF expression
+ and provides the evaluation result, in a form of a single struct
+ value object that describes a location. To do this, the method requires
+ a context of the evaluation, as well as expected result type
+ information. If the type information is not provided, the DWARF generic
+ type will be used instead.
+
+ To avoid storing the gdbarch information in the evaluator object, that
+ information is now always acquired from the per_objfile object.
+
+ All data members are now private and only visible to the evaluator
+ class, so a m_ prefix was added to all of their names to reflect that.
+ To make this distinction clear, they are also accessed through objects
+ this pointer, wherever that was not the case before.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add
+ address size argument.
+ (dwarf_expr_context::read_mem): Change to use property_addr_info
+ structure.
+ (dwarf_expr_context::evaluate): New function.
+ (dwarf_expr_context::execute_stack_op): Change to use
+ property_addr_info structure.
+ * dwarf2/expr.h (struct dwarf_expr_context): New evaluate
+ declaration. Change eval and fetch_result method to private.
+ (dwarf_expr_context::gdbarch): Remove member.
+ (dwarf_expr_context::stack): Make private and add m_ prefix.
+ (dwarf_expr_context::addr_size): Make private and add
+ m_ prefix.
+ (dwarf_expr_context::recursion_depth): Make private and add
+ m_ prefix.
+ (dwarf_expr_context::max_recursion_depth): Make private and
+ add m_ prefix.
+ (dwarf_expr_context::len): Make private and add m_ prefix.
+ (dwarf_expr_context::data): Make private and add m_ prefix.
+ (dwarf_expr_context::initialized): Make private and add
+ m_ prefix.
+ (dwarf_expr_context::pieces): Make private and add m_ prefix.
+ (dwarf_expr_context::per_objfile): Make private and add
+ m_ prefix.
+ (dwarf_expr_context::frame): Make private and add m_ prefix.
+ (dwarf_expr_context::per_cu): Make private and add m_ prefix.
+ (dwarf_expr_context::addr_info): Make private and add
+ m_ prefix.
+ * dwarf2/frame.c (execute_stack_op): Change to call evaluate
+ method.
+ * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to call
+ evaluate method.
+ (dwarf2_locexpr_baton_eval): Change to call evaluate method.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Make DWARF evaluator return a single struct value
+ The patch is addressing the issue of class users writing and reading
+ the internal data of the dwarf_expr_context class.
+
+ At this point, all conditions are met for the DWARF evaluator to return
+ an evaluation result in a form of a single struct value object.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (pieced_value_funcs): Chenge to static
+ function.
+ (allocate_piece_closure): Change to static function.
+ (dwarf_expr_context::fetch_result): New function.
+ * dwarf2/expr.h (struct piece_closure): Remove declaration.
+ (struct dwarf_expr_context): fetch_result new declaration.
+ fetch, fetch_address and fetch_in_stack_memory members move
+ to private.
+ (allocate_piece_closure): Remove.
+ * dwarf2/frame.c (execute_stack_op): Change to use
+ fetch_result.
+ * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to use
+ fetch_result.
+ (dwarf2_locexpr_baton_eval): Change to use fetch_result.
+ * dwarf2/loc.h (invalid_synthetic_pointer): Expose function.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Make value_copy also copy the stack data member
+ Fixing a bug where the value_copy function did not copy the stack data
+ and initialized members of the struct value. This is needed for the
+ next patch where the DWARF expression evaluator is changed to return a
+ single struct value object.
+
+ * value.c (value_copy): Change to also copy the stack data
+ and initialized members.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move piece_closure and its support to expr.c
+ Following 5 patches series is trying to clean up the interface of the
+ DWARF expression evaluator class (dwarf_expr_context).
+
+ After merging all expression evaluators into one class, the next
+ logical step is to make a clean user interface for that class. To do
+ that, we first need to address the issue of class users writing and
+ reading the internal data of the class directly.
+
+ Fixing the case of writing is simple, it makes sense for an evaluator
+ instance to be per architecture basis. Currently, the best separation
+ seems to be per object file, so having that data (dwarf2_per_objfile)
+ as a constructor argument makes sense. It also makes sense to get the
+ address size from that object file, but unfortunately that interface
+ does not exist at the moment.
+
+ Luckily, address size information is already available to the users
+ through other means. As a result, the address size also needs to be a
+ class constructor argument, at least until a better interface for
+ acquiring that information from an object file is implemented.
+
+ The rest of the user written data comes down to a context of an
+ evaluated expression (compilation unit context, frame context and
+ passed in buffer context) and a source type information that a result
+ of evaluating expression is representing. So, it makes sense for all of
+ these to be arguments of an evaluation method.
+
+ To address the problem of reading the dwarf_expr_context class
+ internal data, we first need to understand why it is implemented that
+ way?
+
+ This is actualy a question of which existing class can be used to
+ represent both values and a location descriptions and why it is not
+ used currently?
+
+ The answer is in a struct value class/structure, but the problem is
+ that before the evaluators were merged, only one evaluator had an
+ infrastructure to resolve composite and implicit pointer location
+ descriptions.
+
+ After the merge, we are now able to use the struct value to represent
+ any result of the expression evaluation. It also makes sense to move
+ all infrastructure for those location descriptions to the expr.c file
+ considering that that is the only place using that infrastructure.
+
+ What we are left with in the end is a clean public interface of the
+ dwarf_expr_context class containing:
+
+ - constructor,
+ - destructor,
+ - push_address method and
+ - eval_exp method.
+
+ The idea with this particular patch is to move piece_closure structure
+ and the interface that handles it (lval_funcs) to expr.c file.
+
+ While implicit pointer location descriptions are still not useful in
+ the CFI context (of the AMD's DWARF standard extensions), the composite
+ location descriptions are certainly necessary to describe a results of
+ specific compiler optimizations.
+
+ Considering that a piece_closure structure is used to represent both,
+ there was no benefit in splitting them.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (struct piece_closure): Add from loc.c.
+ (allocate_piece_closure): Add from loc.c.
+ (bits_to_bytes): Add from loc.c.
+ (rw_pieced_value): Add from loc.c.
+ (read_pieced_value): Add from loc.c.
+ (write_pieced_value): Add from loc.c.
+ (check_pieced_synthetic_pointer): Add from loc.c.
+ (indirect_pieced_value): Add from loc.c.
+ (coerce_pieced_ref): Add from loc.c.
+ (copy_pieced_value_closure): Add from loc.c.
+ (free_pieced_value_closure): Add from loc.c.
+ (sect_variable_value): Add from loc.c.
+ * dwarf2/loc.c (sect_variable_value): Move to expr.c.
+ (struct piece_closure): Move to expr.c.
+ (allocate_piece_closure): Move to expr.c.
+ (bits_to_bytes): Move to expr.c.
+ (rw_pieced_value): Move to expr.c.
+ (read_pieced_value): Move to expr.c.
+ (write_pieced_value): Move to expr.c.
+ (check_pieced_synthetic_pointer): Move to expr.c.
+ (indirect_pieced_value): Move to expr.c.
+ (coerce_pieced_ref): Move to expr.c.
+ (copy_pieced_value_closure): Move to expr.c.
+ (free_pieced_value_closure): Move to expr.c.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Merge evaluate_for_locexpr_baton evaluator
+ The evaluate_for_locexpr_baton is the last derived class from the
+ dwarf_expr_context class. It's purpose is to support the passed in
+ buffer functionality.
+
+ Although, it is not really necessary to merge this class with it's
+ base class, doing that simplifies new expression evaluator design.
+
+ Considering that this functionality is going around the DWARF standard,
+ it is also reasonable to expect that with a new evaluator design and
+ extending the push object address functionality to accept any location
+ description, there will be no need to support passed in buffers.
+
+ Alternatively, it would also makes sense to abstract the interaction
+ between the evaluator and a given resource in the near future. The
+ passed in buffer would then be a specialization of that abstraction.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::read_mem): Merge with
+ evaluate_for_locexpr_baton implementation.
+ * dwarf2/loc.c (class evaluate_for_locexpr_baton): Remove
+ class.
+ (evaluate_for_locexpr_baton::read_mem): Move to
+ dwarf_expr_context.
+ (dwarf2_locexpr_baton_eval): Instantiate dwarf_expr_context
+ instead of evaluate_for_locexpr_baton class.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Remove empty frame and full evaluators
+ There are no virtual methods that require different specialization in
+ dwarf_expr_context class. This means that derived classes
+ dwarf_expr_executor and dwarf_evaluate_loc_desc are not needed any
+ more.
+
+ As a result of this, the evaluate_for_locexpr_baton class base class
+ is now the dwarf_expr_context class.
+
+ There might be a need for a better class hierarchy when we know more
+ about the direction of the future DWARF versions and gdb extensions,
+ but that is out of the scope of this patch series.
+
+ gdb/ChangeLog:
+
+ * dwarf2/frame.c (class dwarf_expr_executor): Remove class.
+ (execute_stack_op): Instantiate dwarf_expr_context instead of
+ dwarf_evaluate_loc_desc class.
+ * dwarf2/loc.c (class dwarf_evaluate_loc_desc): Remove class.
+ (dwarf2_evaluate_loc_desc_full): Instantiate dwarf_expr_context
+ instead of dwarf_evaluate_loc_desc class.
+ (struct evaluate_for_locexpr_baton): Derive from
+ dwarf_expr_context.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Inline get_reg_value method of dwarf_expr_context
+ The get_reg_value method is a small function that is only called once,
+ so it can be inlined to simplify the dwarf_expr_context class.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::get_reg_value): Remove
+ method.
+ (dwarf_expr_context::execute_stack_op): Inline get_reg_value
+ method.
+ * dwarf2/expr.h (dwarf_expr_context::get_reg_value): Remove
+ method.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move push_dwarf_reg_entry_value to expr.c
+ Following the idea of merging the evaluators, the
+ push_dwarf_reg_entry_value method can be moved from
+ dwarf_expr_executor and dwarf_evaluate_loc_desc classes
+ to their base class dwarf_expr_context.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c
+ (dwarf_expr_context::push_dwarf_reg_entry_value): Move from
+ dwarf_evaluate_loc_desc.
+ * dwarf2/frame.c
+ (dwarf_expr_executor::push_dwarf_reg_entry_value): Remove
+ method.
+ * dwarf2/loc.c (dwarf_expr_reg_to_entry_parameter): Expose
+ function.
+ (dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value): Move to
+ dwarf_expr_context.
+ * dwarf2/loc.h (dwarf_expr_reg_to_entry_parameter): Expose
+ function.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move read_mem to dwarf_expr_context
+ Following the idea of merging the evaluators, the read_mem method can
+ be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes
+ to their base class dwarf_expr_context.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::read_mem): Move from
+ dwarf_evaluate_loc_desc.
+ * dwarf2/frame.c (dwarf_expr_executor::read_mem): Remove
+ method.
+ * dwarf2/loc.c (dwarf_evaluate_loc_desc::read_mem): Move to
+ dwarf_expr_context.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Move get_object_address to dwarf_expr_context
+ Following the idea of merging the evaluators, the get_object_address
+ and can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
+ classes to their base class dwarf_expr_context.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::get_object_address): Move
+ from dwarf_evaluate_loc_desc.
+ (class dwarf_expr_context): Add object address member to
+ dwarf_expr_context.
+ * dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
+ method.
+ * dwarf2/frame.c (dwarf_expr_executor::get_object_address):
+ Remove method.
+ * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_object_address):
+ move to dwarf_expr_context.
+ (class dwarf_evaluate_loc_desc): Move object address member to
+ dwarf_expr_context.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move dwarf_call to dwarf_expr_context
+ Following the idea of merging the evaluators, the dwarf_call and
+ get_frame_pc method can be moved from dwarf_expr_executor and
+ dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context.
+ Once this is done, the get_frame_pc can be replace with lambda
+ function.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::dwarf_call): Move from
+ dwarf_evaluate_loc_desc.
+ (dwarf_expr_context::get_frame_pc): Replace with lambda.
+ * dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
+ method.
+ * dwarf2/frame.c (dwarf_expr_executor::dwarf_call): Remove
+ method.
+ (dwarf_expr_executor::get_frame_pc): Remove method.
+ * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_pc): Remove
+ method.
+ (dwarf_evaluate_loc_desc::dwarf_call): Move to
+ dwarf_expr_context.
+ (per_cu_dwarf_call): Inline function.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move compilation unit info to dwarf_expr_context
+ This patch moves the compilation unit context information and support
+ from dwarf_expr_executor and dwarf_evaluate_loc_desc to
+ dwarf_expr_context evaluator. The idea is to report an error when a
+ given operation requires a compilation unit information to be resolved,
+ which is not available.
+
+ With this change, it also makes sense to always acquire ref_addr_size
+ information from the compilation unit context, considering that all
+ DWARF operations that refer to that information require a compilation
+ unit context to be present during their evaluation.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (ensure_have_per_cu): New function.
+ (dwarf_expr_context::dwarf_expr_context): Add compilation unit
+ context information.
+ (dwarf_expr_context::get_base_type): Move from
+ dwarf_evaluate_loc_desc.
+ (dwarf_expr_context::get_addr_index): Remove method.
+ (dwarf_expr_context::dwarf_variable_value): Remove method.
+ (dwarf_expr_context::execute_stack_op): Call compilation unit
+ context info check. Inline get_addr_index and
+ dwarf_variable_value methods.
+ * dwarf2/expr.h (struct dwarf_expr_context): Add compilation
+ context info.
+ (dwarf_expr_context::get_addr_index): Remove method.
+ (dwarf_expr_context::dwarf_variable_value): Remove method.
+ (dwarf_expr_context::ref_addr_size): Remove member.
+ * dwarf2/frame.c (dwarf_expr_executor::get_addr_index): Remove
+ method.
+ (dwarf_expr_executor::dwarf_variable_value): Remove method.
+ * dwarf2/loc.c (sect_variable_value): Expose function.
+ (dwarf_evaluate_loc_desc::get_addr_index): Remove method.
+ (dwarf_evaluate_loc_desc::dwarf_variable_value): Remove method.
+ (class dwarf_evaluate_loc_desc): Move compilation unit context
+ information to dwarf_expr_context class.
+ * dwarf2/loc.h (sect_variable_value): Expose function.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Remove get_frame_cfa from dwarf_expr_context
+ Following the idea of merging the evaluators, the get_frame_cfa method
+ can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
+ classes to their base class dwarf_expr_context. Once this is done,
+ it becomes apparent that the method is only called once and it can be
+ inlined.
+
+ It is also necessary to check if the frame context information was
+ provided before the DW_OP_call_frame_cfa operation is executed.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::get_frame_cfa): Remove
+ method.
+ (dwarf_expr_context::execute_stack_op): Call frame context info
+ check for DW_OP_call_frame_cfa. Remove use of get_frame_cfa.
+ * dwarf2/expr.h (dwarf_expr_context::get_frame_cfa): Remove
+ method.
+ * dwarf2/frame.c (dwarf_expr_context::get_frame_cfa): Remove
+ method.
+ * dwarf2/loc.c (dwarf_expr_context::get_frame_cfa): Remove
+ method.
+
+2021-08-05 Zoran Zaric <zoran.zaric@amd.com>
+
+ Move frame context info to dwarf_expr_context
+ Following 15 patches in this patch series is cleaning up the design of
+ the DWARF expression evaluator (dwarf_expr_context) to make future
+ extensions of that evaluator easier and cleaner to implement.
+
+ There are three subclasses of the dwarf_expr_context class
+ (dwarf_expr_executor, dwarf_evaluate_loc_desc and
+ evaluate_for_locexpr_baton). Here is a short description of each class:
+
+ - dwarf_expr_executor is evaluating a DWARF expression in a context
+ of a Call Frame Information. The overridden methods of this subclass
+ report an error if a specific DWARF operation, represented by that
+ method, is not allowed in a CFI context. The source code of this
+ subclass lacks the support for composite as well as implicit pointer
+ location description.
+
+ - dwarf_evaluate_loc_desc can evaluate any expression with no
+ restrictions. All of the methods that this subclass overrides are
+ actually doing what they are intended to do. This subclass contains
+ a full support for all location description types.
+
+ - evaluate_for_locexpr_baton subclass is a specialization of the
+ dwarf_evaluate_loc_desc subclass and it's function is to add
+ support for passed in buffers. This seems to be a way to go around
+ the fact that DWARF standard lacks a bit offset support for memory
+ location descriptions as well as using any location description for
+ the push object address functionality.
+
+ It all comes down to this question: what is a function of a DWARF
+ expression evaluator?
+
+ Is it to evaluate the expression in a given context or to check the
+ correctness of that expression in that context?
+
+ Currently, the only reason why there is a dwarf_expr_executor subclass
+ is to report an invalid DWARF expression in a context of a CFI, but is
+ that what the evaluator is supposed to do considering that the evaluator
+ is not tied to a given DWARF version?
+
+ There are more and more vendor and GNU extensions that are not part of
+ the DWARF standard, so is it that impossible to expect that some of the
+ extensions could actually lift the previously imposed restrictions of
+ the CFI context? Not to mention that every new DWARF version is lifting
+ some restrictions anyway.
+
+ The thing that makes more sense for an evaluator to do, is to take the
+ context of an evaluation and checks the requirements of every operation
+ evaluated against that context. With this approach, the evaluator would
+ report an error only if parts of the context, necessary for the
+ evaluation, are missing.
+
+ If this approach is taken, then the unification of the
+ dwarf_evaluate_loc_desc, dwarf_expr_executor and dwarf_expr_context
+ is the next logical step. This makes a design of the DWARF expression
+ evaluator cleaner and allows more flexibility when supporting future
+ vendor and GNU extensions.
+
+ Additional benefit here is that now all evaluators have access to all
+ location description types, which means that a vendor extended CFI
+ rules could support composite location description as well. This also
+ means that a new evaluator interface can be changed to return a single
+ struct value (that describes the result of the evaluation) instead of
+ a caller poking around the dwarf_expr_context internal data for answers
+ (like it is done currently).
+
+ This patch starts the merging process by moving the frame context
+ information and support from dwarf_expr_executor and
+ dwarf_evaluate_loc_desc to dwarf_expr_context evaluator. The idea
+ is to report an error when a given operation requires a frame
+ information to be resolved, if that information is not present.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (ensure_have_frame): New function.
+ (read_addr_from_reg): Add from frame.c.
+ (dwarf_expr_context::dwarf_expr_context): Add frame info to
+ dwarf_expr_context.
+ (dwarf_expr_context::read_addr_from_reg): Remove.
+ (dwarf_expr_context::get_reg_value): Move from
+ dwarf_evaluate_loc_desc.
+ (dwarf_expr_context::get_frame_base): Move from
+ dwarf_evaluate_loc_desc.
+ (dwarf_expr_context::execute_stack_op): Call frame context info
+ check. Remove use of read_addr_from_reg method.
+ * dwarf2/expr.h (struct dwarf_expr_context): Add frame info
+ member, read_addr_from_reg, get_reg_value and get_frame_base
+ declaration.
+ (read_addr_from_reg): Move to expr.c.
+ * dwarf2/frame.c (read_addr_from_reg): Move to
+ dwarf_expr_context.
+ (dwarf_expr_executor::read_addr_from_reg): Remove.
+ (dwarf_expr_executor::get_frame_base): Remove.
+ (dwarf_expr_executor::get_reg_value): Remove.
+ (execute_stack_op): Use read_addr_from_reg function instead of
+ read_addr_from_reg method.
+ * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_base): Move
+ to dwarf_expr_context.
+ (dwarf_evaluate_loc_desc::get_reg_value): Move to
+ dwarf_expr_context.
+ (dwarf_evaluate_loc_desc::read_addr_from_reg): Remove.
+ (dwarf2_locexpr_baton_eval):Use read_addr_from_reg function
+ instead of read_addr_from_reg method.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Cleanup of the dwarf_expr_context constructor
+ Move the initial values for dwarf_expr_context class data members
+ to the class declaration in expr.h.
+
+ gdb/ChangeLog:
+
+ * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context):
+ Remove initial data members values.
+ * dwarf2/expr.h (dwarf_expr_context): Add initial values
+ to the class data members.
+
+2021-08-05 Zoran Zaric <Zoran.Zaric@amd.com>
+
+ Replace the symbol needs evaluator with a parser
+ This patch addresses a design problem with the symbol_needs_eval_context
+ class. It exposes the problem by introducing two new testsuite test
+ cases.
+
+ To explain the issue, I first need to explain the dwarf_expr_context
+ class that the symbol_needs_eval_context class derives from.
+
+ The intention behind the dwarf_expr_context class is to commonize the
+ DWARF expression evaluation mechanism for different evaluation
+ contexts. Currently in gdb, the evaluation context can contain some or
+ all of the following information: architecture, object file, frame and
+ compilation unit.
+
+ Depending on the information needed to evaluate a given expression,
+ there are currently three distinct DWARF expression evaluators:
+
+ - Frame: designed to evaluate an expression in the context of a call
+ frame information (dwarf_expr_executor class). This evaluator doesn't
+ need a compilation unit information.
+
+ - Location description: designed to evaluate an expression in the
+ context of a source level information (dwarf_evaluate_loc_desc
+ class). This evaluator expects all information needed for the
+ evaluation of the given expression to be present.
+
+ - Symbol needs: designed to answer a question about the parts of the
+ context information required to evaluate a DWARF expression behind a
+ given symbol (symbol_needs_eval_context class). This evaluator
+ doesn't need a frame information.
+
+ The functional difference between the symbol needs evaluator and the
+ others is that this evaluator is not meant to interact with the actual
+ target. Instead, it is supposed to check which parts of the context
+ information are needed for the given DWARF expression to be evaluated by
+ the location description evaluator.
+
+ The idea is to take advantage of the existing dwarf_expr_context
+ evaluation mechanism and to fake all required interactions with the
+ actual target, by returning back dummy values. The evaluation result is
+ returned as one of three possible values, based on operations found in a
+ given expression:
+
+ - SYMBOL_NEEDS_NONE,
+ - SYMBOL_NEEDS_REGISTERS and
+ - SYMBOL_NEEDS_FRAME.
+
+ The problem here is that faking results of target interactions can yield
+ an incorrect evaluation result.
+
+ For example, if we have a conditional DWARF expression, where the
+ condition depends on a value read from an actual target, and the true
+ branch of the condition requires a frame information to be evaluated,
+ while the false branch doesn't, fake target reads could conclude that a
+ frame information is not needed, where in fact it is. This wrong
+ information would then cause the expression to be actually evaluated (by
+ the location description evaluator) with a missing frame information.
+ This would then crash the debugger.
+
+ The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this
+ scenario, with the following DWARF expression:
+
+ DW_OP_addr $some_variable
+ DW_OP_deref
+
+ # conditional jump to DW_OP_bregx
+ DW_OP_bra 4
+ DW_OP_lit0
+
+ # jump to DW_OP_stack_value
+ DW_OP_skip 3
+ DW_OP_bregx $dwarf_regnum 0
+ DW_OP_stack_value
+
+ This expression describes a case where some variable dictates the
+ location of another variable. Depending on a value of some_variable, the
+ variable whose location is described by this expression is either read
+ from a register or it is defined as a constant value 0. In both cases,
+ the value will be returned as an implicit location description on the
+ DWARF stack.
+
+ Currently, when the symbol needs evaluator fakes a memory read from the
+ address behind the some_variable variable, the constant value 0 is used
+ as the value of the variable A, and the check returns the
+ SYMBOL_NEEDS_NONE result.
+
+ This is clearly a wrong result and it causes the debugger to crash.
+
+ The scenario might sound strange to some people, but it comes from a
+ SIMD/SIMT architecture where $some_variable is an execution mask. In
+ any case, it is a valid DWARF expression, and GDB shouldn't crash while
+ evaluating it. Also, a similar example could be made based on a
+ condition of the frame base value, where if that value is concluded to
+ be 0, the variable location could be defaulted to a TLS based memory
+ address.
+
+ The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second
+ scenario. This scenario is a bit more abstract due to the DWARF
+ assembler lacking the CFI support, but it exposes a different
+ manifestation of the same problem. Like in the previous scenario, the
+ DWARF expression used in the test is valid:
+
+ DW_OP_lit1
+ DW_OP_addr $some_variable
+ DW_OP_deref
+
+ # jump to DW_OP_fbreg
+ DW_OP_skip 4
+ DW_OP_drop
+ DW_OP_fbreg 0
+ DW_OP_dup
+ DW_OP_lit0
+ DW_OP_eq
+
+ # conditional jump to DW_OP_drop
+ DW_OP_bra -9
+ DW_OP_stack_value
+
+ Similarly to the previous scenario, the location of a variable A is an
+ implicit location description with a constant value that depends on a
+ value held by a global variable. The difference from the previous case
+ is that DWARF expression contains a loop instead of just one branch. The
+ end condition of that loop depends on the expectation that a frame base
+ value is never zero. Currently, the act of faking the target reads will
+ cause the symbol needs evaluator to get stuck in an infinite loop.
+
+ Somebody could argue that we could change the fake reads to return
+ something else, but that would only hide the real problem.
+
+ The general impression seems to be that the desired design is to have
+ one class that deals with parsing of the DWARF expression, while there
+ are virtual methods that deal with specifics of some operations.
+
+ Using an evaluator mechanism here doesn't seem to be correct, because
+ the act of evaluation relies on accessing the data from the actual
+ target with the possibility of skipping the evaluation of some parts of
+ the expression.
+
+ To better explain the proposed solution for the issue, I first need to
+ explain a couple more details behind the current design:
+
+ There are multiple places in gdb that handle DWARF expression parsing
+ for different purposes. Some are in charge of converting the expression
+ to some other internal representation (decode_location_expression,
+ disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are
+ analysing the expression for specific information
+ (compute_stack_depth_worker) and some are in charge of evaluating the
+ expression in a given context (dwarf_expr_context::execute_stack_op
+ and decode_locdesc).
+
+ The problem is that all those functions have a similar (large) switch
+ statement that handles each DWARF expression operation. The result of
+ this is a code duplication and harder maintenance.
+
+ As a step into the right direction to solve this problem (at least for
+ the purpose of a DWARF expression evaluation) the expression parsing was
+ commonized inside of an evaluator base class (dwarf_expr_context). This
+ makes sense for all derived classes, except for the symbol needs
+ evaluator (symbol_needs_eval_context) class.
+
+ As described previously the problem with this evaluator is that if the
+ evaluator is not allowed to access the actual target, it is not really
+ evaluating.
+
+ Instead, the desired function of a symbol needs evaluator seems to fall
+ more into expression analysis category. This means that a more natural
+ fit for this evaluator is to be a symbol needs analysis, similar to the
+ existing compute_stack_depth_worker analysis.
+
+ Another problem is that using a heavyweight mechanism of an evaluator
+ to do an expression analysis seems to be an unneeded overhead. It also
+ requires a more complicated design of the parent class to support fake
+ target reads.
+
+ The reality is that the whole symbol_needs_eval_context class can be
+ replaced with a lightweight recursive analysis function, that will give
+ more correct result without compromising the design of the
+ dwarf_expr_context class. The analysis treats the expression byte
+ stream as a DWARF operation graph, where each graph node can be
+ visited only once and each operation can decide if the frame context
+ is needed for their evaluation.
+
+ The downside of this approach is adding of one more similar switch
+ statement, but at least this way the new symbol needs analysis will be
+ a lightweight mechnism and it will provide a correct result for any
+ given DWARF expression.
+
+ A more desired long term design would be to have one class that deals
+ with parsing of the DWARF expression, while there would be a virtual
+ methods that deal with specifics of some DWARF operations. Then that
+ class would be used as a base for all DWARF expression parsing mentioned
+ at the beginning.
+
+ This however, requires a far bigger changes that are out of the scope
+ of this patch series.
+
+ The new analysis requires the DWARF location description for the
+ argc argument of the main function to change in the assembly file
+ gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression
+ ended with a 0 value byte, which was never reached by the symbol needs
+ evaluator, because it was detecting a stack underflow when evaluating
+ the operation before. The new approach does not simulate a DWARF
+ stack anymore, so the 0 value byte needs to be removed because it
+ makes the DWARF expression invalid.
+
+ gdb/ChangeLog:
+
+ * dwarf2/loc.c (class symbol_needs_eval_context): Remove.
+ (dwarf2_get_symbol_read_needs): New function.
+ (dwarf2_loc_desc_get_symbol_read_needs): Remove.
+ (locexpr_get_symbol_read_needs): Use
+ dwarf2_get_symbol_read_needs.
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.python/amd64-py-framefilter-invalidarg.S : Update argc
+ DWARF location expression.
+ * lib/dwarf.exp (_location): Handle DW_OP_fbreg.
+ * gdb.dwarf2/symbol_needs_eval.c: New file.
+ * gdb.dwarf2/symbol_needs_eval_fail.exp: New file.
+ * gdb.dwarf2/symbol_needs_eval_timeout.exp: New file.
+
+2021-08-05 Cui,Lili <lili.cui@intel.com>
+
+ [PATCH 2/2] Add tests for Intel AVX512_FP16 instructions
+ Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
+ in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
+ in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
+ There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
+ operands predated our current conventions; those instructions moved to map 3.
+ FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
+ is very sparsely populated. Most of the FP16 instructions share opcodes and
+ prefix (EVEX.pp) bits with the related FP32 operations.
+
+ Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
+ to the public software developer manual for detail information.
+
+ gas/
+
+ 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Wei Xiao <wei3.xiao@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ * testsuite/gas/i386/i386.exp: Run FP16 tests.
+ * testsuite/gas/i386/avx512_fp16-intel.d: New test.
+ * testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl.d: Ditto.
+ * testsuite/gas/i386/avx512_fp16_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto.
+ * testsuite/gas/i386/x86-64-avx512_fp16-bad.s: Ditto.
+ * testsuite/gas/i386/x86-64-default-suffix-avx.d: Add new testcase.
+ * testsuite/gas/i386/x86-64-default-suffix.d: Ditto.
+ * testsuite/gas/i386/x86-64-default-suffix.s: Ditto.
+ * testsuite/gas/i386/xmmword.l: Ditto.
+ * testsuite/gas/i386/xmmword.s: Ditto.
+
+2021-08-05 Cui,Lili <lili.cui@intel.com>
+
+ [PATCH 1/2] Enable Intel AVX512_FP16 instructions
+ Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
+ in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
+ in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
+ There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
+ operands predated our current conventions; those instructions moved to map 3.
+ FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
+ is very sparsely populated. Most of the FP16 instructions share opcodes and
+ prefix (EVEX.pp) bits with the related FP32 operations.
+
+ Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
+ to the public software developer manual for detail information.
+
+ gas/
+
+ 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Wei Xiao <wei3.xiao@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ * config/tc-i386.c (struct Broadcast_Operation): Adjust comment.
+ (cpu_arch): Add .avx512_fp16.
+ (cpu_noarch): Add noavx512_fp16.
+ (pte): Add evexmap5 and evexmap6.
+ (build_evex_prefix): Handle EVEXMAP5 and EVEXMAP6.
+ (check_VecOperations): Handle {1to32}.
+ (check_VecOperands): Handle CheckRegNumb.
+ (check_word_reg): Handle Toqword.
+ (i386_error): Add invalid_dest_and_src_register_set.
+ (match_template): Handle invalid_dest_and_src_register_set.
+ * doc/c-i386.texi: Document avx512_fp16, noavx512_fp16.
+
+ opcodes/
+
+ 2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com>
+ H.J. Lu <hongjiu.lu@intel.com>
+ Wei Xiao <wei3.xiao@intel.com>
+ Lili Cui <lili.cui@intel.com>
+
+ * i386-dis.c (EXwScalarS): New.
+ (EXxh): Ditto.
+ (EXxhc): Ditto.
+ (EXxmmqh): Ditto.
+ (EXxmmqdh): Ditto.
+ (EXEvexXwb): Ditto.
+ (DistinctDest_Fixup): Ditto.
+ (enum): Add xh_mode, evex_half_bcst_xmmqh_mode, evex_half_bcst_xmmqdh_mode
+ and w_swap_mode.
+ (enum): Add PREFIX_EVEX_0F3A08_W_0, PREFIX_EVEX_0F3A0A_W_0,
+ PREFIX_EVEX_0F3A26, PREFIX_EVEX_0F3A27, PREFIX_EVEX_0F3A56,
+ PREFIX_EVEX_0F3A57, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3A67,
+ PREFIX_EVEX_0F3AC2, PREFIX_EVEX_MAP5_10, PREFIX_EVEX_MAP5_11,
+ PREFIX_EVEX_MAP5_1D, PREFIX_EVEX_MAP5_2A, PREFIX_EVEX_MAP5_2C,
+ PREFIX_EVEX_MAP5_2D, PREFIX_EVEX_MAP5_2E, PREFIX_EVEX_MAP5_2F,
+ PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, PREFIX_EVEX_MAP5_59,
+ PREFIX_EVEX_MAP5_5A_W_0, PREFIX_EVEX_MAP5_5A_W_1,
+ PREFIX_EVEX_MAP5_5B_W_0, PREFIX_EVEX_MAP5_5B_W_1,
+ PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, PREFIX_EVEX_MAP5_5E,
+ PREFIX_EVEX_MAP5_5F, PREFIX_EVEX_MAP5_78, PREFIX_EVEX_MAP5_79,
+ PREFIX_EVEX_MAP5_7A, PREFIX_EVEX_MAP5_7B, PREFIX_EVEX_MAP5_7C,
+ PREFIX_EVEX_MAP5_7D_W_0, PREFIX_EVEX_MAP6_13, PREFIX_EVEX_MAP6_56,
+ PREFIX_EVEX_MAP6_57, PREFIX_EVEX_MAP6_D6, PREFIX_EVEX_MAP6_D7
+ (enum): Add EVEX_MAP5 and EVEX_MAP6.
+ (enum): Add EVEX_W_MAP5_5A, EVEX_W_MAP5_5B,
+ EVEX_W_MAP5_78_P_0, EVEX_W_MAP5_78_P_2, EVEX_W_MAP5_79_P_0,
+ EVEX_W_MAP5_79_P_2, EVEX_W_MAP5_7A_P_2, EVEX_W_MAP5_7A_P_3,
+ EVEX_W_MAP5_7B_P_2, EVEX_W_MAP5_7C_P_0, EVEX_W_MAP5_7C_P_2,
+ EVEX_W_MAP5_7D, EVEX_W_MAP6_13_P_0, EVEX_W_MAP6_13_P_2,
+ (get_valid_dis386): Properly handle new instructions.
+ (intel_operand_size): Handle new modes.
+ (OP_E_memory): Ditto.
+ (OP_EX): Ditto.
+ * i386-dis-evex.h: Updated for AVX512_FP16.
+ * i386-dis-evex-mod.h: Updated for AVX512_FP16.
+ * i386-dis-evex-prefix.h: Updated for AVX512_FP16.
+ * i386-dis-evex-reg.h : Updated for AVX512_FP16.
+ * i386-dis-evex-w.h : Updated for AVX512_FP16.
+ * i386-gen.c (cpu_flag_init): Add CPU_AVX512_FP16_FLAGS,
+ and CPU_ANY_AVX512_FP16_FLAGS. Update CPU_ANY_AVX512F_FLAGS
+ and CPU_ANY_AVX512BW_FLAGS.
+ (cpu_flags): Add CpuAVX512_FP16.
+ (opcode_modifiers): Add DistinctDest.
+ * i386-opc.h (enum): (AVX512_FP16): New.
+ (i386_opcode_modifier): Add reqdistinctreg.
+ (i386_cpu_flags): Add cpuavx512_fp16.
+ (EVEXMAP5): Defined as a macro.
+ (EVEXMAP6): Ditto.
+ * i386-opc.tbl: Add Intel AVX512_FP16 instructions.
+ * i386-init.h: Regenerated.
+ * i386-tbl.h: Ditto.
+
+2021-08-05 Alan Modra <amodra@gmail.com>
+
+ PR28167, vms-alpha build_module_list
+ PR 28167
+ * vms-alpha.c (build_module_list): Malloc and free section contents.
+ Don't read past end of section.
+
+2021-08-05 Alan Modra <amodra@gmail.com>
+
+ PR28166, _bfd_elf_mips_get_relocated_section_contents
+ Some of the code paths unpacking mips relocs left arelent->sym_ptr_ptr
+ uninitialised.
+
+ PR 28166
+ * elf64-mips.c (mips_elf64_slurp_one_reloc_table): Don't leave
+ sym_ptr_ptr uninitialised.
+
+2021-08-05 Alan Modra <amodra@gmail.com>
+
+ PR28165, buffer overflow in elf32-rx.c:rx_info_to_howto_rela
+ PR 28165
+ * elf32-rx.c (rx_elf_howto_table): Add missing empty entries.
+ (rx_info_to_howto_rela): Assert rx_elf_howto_table is correct size.
+ Use actual size when sanity checking r_type.
+
+2021-08-05 Alan Modra <amodra@gmail.com>
+
+ Re: elf: Treat undefined version as hidden
+ Fix fallout in cris testsuite
+
+ PR binutils/28158
+ * ld-cris/libdso-1c.d: Update for version display change.
+ * ld-cris/libdso-15b.d: Likewise.
+
+2021-08-05 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/testsuite: update test gdb.base/step-over-syscall.exp
+ I was looking at PR gdb/19675 and the related test
+ gdb.base/step-over-syscall.exp. This test includes a call to kfail
+ when we are testing a displaced step over a clone syscall.
+
+ While looking at the test I removed the call to kfail and ran the
+ test, and was surprised that the test passed.
+
+ I ran the test a few times and it does sometimes fail, but mostly it
+ passed fine.
+
+ PR gdb/19675 describes how, when we displaced step over a clone, the
+ new thread is created with a $pc in the displaced step buffer. GDB
+ then fails to "fix" this $pc (for the new thread), and the thread will
+ be set running with its current $pc value. This means that the new
+ thread will just start executing from whatever happens to be after the
+ displaced stepping buffer.
+
+ In the original PR gdb/19675 bug report Yao Qi was seeing the new
+ thread cause a segfault, the problem is, what actually happens is
+ totally undefined.
+
+ On my machine, I'm seeing the new thread reenter main, it then starts
+ trying to run the test again (in the new thread). This just happens
+ to be safe enough (in this simple test) that most of the time the
+ inferior doesn't crash.
+
+ In this commit I try to make the test slightly more likely to fail by
+ doing a couple of things.
+
+ First, I added a static variable to main, this is set true when the
+ first thread enters main, if a second thread ever enters main then I
+ force an abort.
+
+ Second, when the test is finishing I want to ensure that the new
+ threads have had a chance to do "something bad" if they are going to.
+ So I added a global counter, as each thread starts successfully it
+ decrements the counter. The main thread does not proceed to the final
+ marker function (where GDB has placed a breakpoint) until all threads
+ have started successfully. This means that if the newly created
+ thread doesn't successfully enter clone_fn then the counter will never
+ reach zero and the test will timeout.
+
+ With these two changes my hope is that the test should fail more
+ reliably, and so, I have also changed the test to call setup_kfail
+ before the specific steps that we expect to misbehave instead of just
+ calling kfail and skipping parts of the test completely. The benefit
+ of this is that if/when we fix GDB this test will start to KPASS and
+ we'll know to update this test to remove the setup_kfail call.
+
+2021-08-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-05 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Use unwinder name in frame_info::to_string
+ While working on a stack unwinding issue using 'set debug frame on', I
+ noticed the frame_info::to_string method could be slightly improved.
+
+ Unwinders have been given a name in
+ a154d838a70e96d888620c072e2d6ea8bdf044ca. Before this patch, frame_info
+ debug output prints the host address of the used unwinder, which is not
+ easy to interpret. This patch proposes to use the unwinder name
+ instead since we now have it.
+
+ Before the patch:
+
+ {level=1,type=NORMAL_FRAME,unwind=0x2ac1763ec0,pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}
+
+ With the patch:
+
+ {level=1,type=NORMAL_FRAME,unwinder="riscv prologue",pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}
+
+ Tested on riscv64-linux-gnu.
+
+2021-08-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: fix gdb.base/info-macros.exp with clang
+ The test gdb.base/info-macros.exp says that it doesn't pass the "debug"
+ option to prepare_for_testing because that would cause -g to appear
+ after -g3 on the command line, and that would cause some gcc versions to
+ not include macro info. I don't know what gcc versions this refers to.
+ I tested with gcc 4.8, and that works fine with -g after -g3.
+
+ The current state is problematic when testing with CC_FOR_TARGET=clang,
+ because then only -fdebug-macro is included. No -g switch if included,
+ meaning we get a binary without any debug info, and the test fails.
+
+ One way to fix it would be to add "debug" to the options when the
+ compiler is clang.
+
+ However, the solution I chose was to specify "debug" in any case, even
+ for gcc. Other macro tests such as gdb.base/macscp.exp do perfectly
+ fine with it. Also, this lets the test use the debug flag specified by
+ the board file. For example, we can test with GCC and DWARF 5, with:
+
+ $ make check RUNTESTFLAGS="--target_board unix/gdb:debug_flags=-gdwarf-5" TESTS="gdb.base/info-macros.exp"
+
+ With the hard-coded -g3, this wouldn't actually test with DWARF 5.
+
+ Change-Id: I33fa92ee545007d3ae9c52c4bb2d5be6b5b698f1
+
+2021-08-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: avoid dereferencing empty str_offsets_base optional in dwarf_decode_macros
+ Since 4d7188abfdf2 ("gdbsupport: add debug assertions in
+ gdb::optional::get"), some macro-related tests fail on Ubuntu 20.04 with
+ the system gcc 9.3.0 compiler when building with _GLIBCXX_DEBUG. For
+ example, gdb.base/info-macros.exp results in:
+
+ (gdb) break -qualified main
+ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = long unsigned int]: Assertion `this->has_value ()' failed.
+
+ The binary contains DWARF 4 debug info and includes a pre-standard
+ (pre-DWARF 5) .debug_macro section. The CU doesn't have a
+ DW_AT_str_offsets_base attribute (which doesn't exist in DWARF 4). The
+ field dwarf2_cu::str_offsets_base is therefore empty. At
+ dwarf2/read.c:24138, we unconditionally read the value in the optional,
+ which triggers the assertion shown above.
+
+ The same thing happens when building the test program with DWARF 5 with
+ the same gcc compiler, as that version of gcc doesn't use indirect
+ string forms, even with DWARF 5. So it still doesn't add a
+ DW_AT_str_offsets_base attribute on the CU.
+
+ Fix that by propagating down a gdb::optional<ULONGEST> for the str
+ offsets base instead of ULONGEST. That value is only used in
+ dwarf_decode_macro_bytes, when encountering an "strx" macro operation
+ (DW_MACRO_define_strx or DW_MACRO_undef_strx). Add a check there that
+ we indeed have a value in the optional before reading it. This is
+ unlikely to happen, but could happen in theory with an erroneous file
+ that uses DW_MACRO_define_strx but does not provide a
+ DW_AT_str_offsets_base (in practice, some things would probably have
+ failed before and stopped processing of debug info). I tested the
+ complaint by inverting the condition and using a clang-compiled binary,
+ which uses the strx operators. This is the result:
+
+ During symbol reading: use of DW_MACRO_define_strx with unknown string offsets base [in module /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/info-macros/info-macros]
+
+ The test now passes cleanly with the setup mentioned above, and the
+ testsuite looks on par with how it was before 4d7188abfdf2.
+
+ Change-Id: I7ebd2724beb7b9b4178872374c2a177aea696e77
+
+2021-08-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix typo in complaint in dwarf2/macro.c
+ I saw this complaint when my code had some bug, and spotted the typo.
+ Fix it, and while at it mention DW_MACRO as well (it would be confusing
+ to only see DW_MACINFO with a file that uses a DWARF 5 .debug_macro
+ section). I contemplated the idea of passing the knowledge of whether
+ we are dealing with a .debug_macro section or .debug_macinfo section, to
+ print only the right one. But in the end, I don't think that trouble is
+ necessary for a complaint nobody is going to see.
+
+ Change-Id: I276ce8da65c3eac5304f64a1e246358ed29cdbbc
+
+2021-08-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix warnings in bsd-kvm.c
+ Building on OpenBSD, I get warnings like:
+
+ CXX bsd-kvm.o
+ /home/simark/src/binutils-gdb/gdb/bsd-kvm.c:241:18: error: ISO C++11 does not allow conversion from string literal to 'char *' [-Werror,-Wwritable-strings]
+ nl[0].n_name = "_dumppcb";
+ ^
+
+ Silence those by adding casts.
+
+ Change-Id: I2bef4eebcc306762a4e3e5b5c52f67ecf2820503
+
+2021-08-04 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM Z: Remove lpswey parameter
+ opcodes/
+ * s390-opc.c (INSTR_SIY_RD): New instruction format.
+ (MASK_SIY_RD): New instruction mask.
+ * s390-opc.txt: Change instruction format of lpswey to SIY_RD.
+
+ gas/
+ * testsuite/gas/s390/zarch-arch14.d: Remove last operand of
+ lpswey.
+ * testsuite/gas/s390/zarch-arch14.s: Likewise.
+
+2021-08-04 Alan Modra <amodra@gmail.com>
+
+ PR28162, segment fault in mips_elf_assign_gp
+ For the testcase in the PR, _bfd_mips_elf32_gprel16_reloc is passed a
+ NULL output_bfd. As expected for reloc special functions if called by
+ objdump or when final linking. The function attempts to find the
+ output by
+ output_bfd = symbol->section->output_section->owner;
+ That makes some sense, since when handling a gp-relative reloc we need
+ the relevant gp to which the symbol is relative. Possibly the gp
+ value can be one for a shared library? But that doesn't seem useful
+ or supported by the various abi docs and won't work as written.
+ Symbols defined in shared libraries have section->output_section
+ NULL, and what's more the code in mips_elf_assign_gp isn't set up to
+ look at shared library symbols.
+
+ Also, if the symbol is a SHN_ABS one the owner of *ABS* section is
+ NULL, which will result in the testcase segfault. The only gp to
+ which an absolute symbol can be relative is the linker output bfd when
+ linking, or the input bfd when not. This patch arranges to do that
+ for all gp-relative reloc symbols.
+
+ * elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Don't use the
+ section symbol to find the output bfd, use input_section.
+ (mips_elf_gprel32_reloc, mips16_gprel_reloc): Likewise.
+ * elf64-mips.c (mips_elf64_gprel16_reloc): Likewise.
+ (mips_elf64_literal_reloc, mips_elf64_gprel32_reloc): Likewise.
+ (mips16_gprel_reloc): Likewise.
+
+2021-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Use lambda function instead of addrmap_foreach_check
+ Use a lambda function instead of addrmap_foreach_check,
+ which removes the need for static variables.
+
+ Also remove unnecessary static on local var temp_obstack in test_addrmap.
+
+ gdb/ChangeLog:
+
+ 2021-08-04 Tom de Vries <tdevries@suse.de>
+
+ * addrmap.c (addrmap_foreach_check): Remove.
+ (array, val1, val2): Move ...
+ (test_addrmap): ... here. Remove static on temp_obstack. Use lambda
+ function instead of addrmap_foreach_check.
+
+2021-08-04 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Treat undefined version as hidden
+ Since undefined version can't be used to resolve any references without
+ the original definition, treat it as hidden.
+
+ bfd/
+
+ PR binutils/28158
+ * elf.c (_bfd_elf_get_symbol_version_string): Treat undefined
+ version as hidden.
+
+ ld/
+
+ PR binutils/28158
+ * testsuite/ld-elf/linux-x86.exp: Run PR binutils/28158 tests.
+ * testsuite/ld-elf/pr28158-1.c: New file.
+ * testsuite/ld-elf/pr28158-2.S: Likewise.
+ * testsuite/ld-elf/pr28158.nd: Likewise.
+ * testsuite/ld-elf/pr28158.rd: Likewise.
+ * testsuite/ld-elf/pr28158.t: Likewise.
+ * testsuite/ld-elfvers/vers2.dsym: Updated.
+ * testsuite/ld-elfvers/vers3.dsym: Likewise.
+ * testsuite/ld-elfvers/vers6.dsym: Likewise.
+ * testsuite/ld-elfvers/vers19.dsym: Likewise.
+ * testsuite/ld-elfvers/vers22.dsym: Likewise.
+ * testsuite/ld-elfvers/vers23.dsym: Likewise.
+ * testsuite/ld-elfvers/vers23d.dsym: Likewise.
+ * testsuite/ld-elfvers/vers27d4.dsym: Likewise.
+ * testsuite/ld-elfvers/vers28c.dsym: Likewise.
+
+2021-08-04 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Implement addrmap_mutable_find
+ Currently addrmap_mutable_find is not implemented:
+ ...
+ static void *
+ addrmap_mutable_find (struct addrmap *self, CORE_ADDR addr)
+ {
+ /* Not needed yet. */
+ internal_error (__FILE__, __LINE__,
+ _("addrmap_find is not implemented yet "
+ "for mutable addrmaps"));
+ }
+ ...
+
+ I implemented this because I needed it during debugging, to be able to do:
+ ...
+ (gdb) p ((dwarf2_psymtab *)addrmap_find (map, addr))->filename
+ ...
+ before and after a call to addrmap_set_empty.
+
+ Since this is not used otherwise, added addrmap unit test.
+
+ Build on x86_64-linux, tested by doing:
+ ...
+ $ gdb -q -batch -ex "maint selftest addrmap"
+ Running selftest addrmap.
+ Ran 1 unit tests, 0 failed
+ ...
+
+ gdb/ChangeLog:
+
+ 2021-08-03 Tom de Vries <tdevries@suse.de>
+
+ * gdb/addrmap.c (addrmap_mutable_find): Implement
+ [GDB_SELF_TESTS] (CHECK_ADDRMAP_FIND): New macro.
+ [GDB_SELF_TESTS] (core_addr, addrmap_foreach_check, test_addrmap)
+ (_initialize_addrmap): New function.
+
+2021-08-04 Clément Chigot <clement.chigot@atos.net>
+
+ gas: correctly output XCOFF tbss symbols with XTY_CM type.
+ Global tbss symbols weren't correctly handled and were generating
+ a symbol with XTY_SD instead of XTY_CM as expected.
+
+ gas/
+ * config/tc-ppc.c (ppc_frog_symbol): Generate a XTY_CM when
+ a symbol has a storage class of XMC_UL.
+
+2021-08-04 Clément Chigot <clement.chigot@atos.net>
+
+ gas: always add dummy symbols when creating XCOFF sections.
+ Most of the algorithms for XCOFF in tc-ppc.c assume that
+ the csects field of a ppc_xcoff_section isn't NULL.
+ This was already made for most of the sections with the creation
+ of a dummy symbol.
+ This patch simply mades it default when creating a xcoff_section.
+
+ gas/
+ * config/tc-ppc.c (ppc_init_xcoff_section): Always create
+ the dummy symbol.
+ (md_begin): Adjust ppc_init_xcoff_section call.
+ (ppc_comm): Likewise.
+ (ppc_change_csect): Likewise.
+
+2021-08-04 Alan Modra <amodra@gmail.com>
+
+ PR28156, rename.c doesn't compile with MinGW
+ Guard against lack of struct timespec definition.
+
+ PR 28156
+ * rename.c (get_stat_atime, get_stat_mtime): Don't compile
+ unless HAVE_UTIMENSAT is defined.
+
+2021-08-04 Alan Modra <amodra@gmail.com>
+
+ PR28155, Superfluous "the" in the man page
+ PR 28155
+ * ld.texi (Options <runtime library name>): Correct grammar.
+
+ revise PE IMAGE_SCN_LNK_NRELOC_OVFL test
+ * coffcode.h (coff_set_alignment_hook): Test that the resulting
+ reloc count is not less than 0xffff.
+
+2021-08-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: follow-fork: push target and add thread in target_follow_fork
+ In the context of ROCm-gdb [1], the ROCm target sits on top of the
+ linux-nat target. when a process forks, it needs to carry over some
+ data from the forking inferior to the fork child inferior. Ideally, the
+ ROCm target would implement the follow_fork target_ops method, but there
+ are some small problems. This patch fixes these, which helps the ROCm
+ target, but also makes things more consistent and a bit nicer in
+ general, I believe.
+
+ The main problem is: when follow-fork-mode is "parent",
+ target_follow_fork is called with the parent as the current inferior.
+ When it's "child", target_follow_fork is called with the child as the
+ current inferior. This means that target_follow_fork is sometimes
+ called on the parent's target stack and sometimes on the child's target
+ stack.
+
+ The parent's target stack may contain targets above the process target,
+ such as the ROCm target. So if follow-fork-child is "parent", the ROCm
+ target would get notified of the fork and do whatever is needed. But
+ the child's target stack, at that moment, only contains the exec and
+ process target copied over from the parent. The child's target stack is
+ set up by follow_fork_inferior, before calling target_follow_fork. In
+ that case, the ROCm target wouldn't get notified of the fork.
+
+ For consistency, I think it would be good to always call
+ target_follow_fork on the parent inferior's target stack. I think it
+ makes sense as a way to indicate "this inferior has called fork, do
+ whatever is needed". The desired outcome of the fork (whether an
+ inferior is created for the child, do we need to detach from the child)
+ can be indicated by passed parameter.
+
+ I therefore propose these changes:
+
+ - make follow_fork_inferior always call target_follow_fork with the
+ parent as the current inferior. That lets all targets present on the
+ parent's target stack do some fork-related handling and push
+ themselves on the fork child's target stack if needed.
+
+ For this purpose, pass the child inferior down to target_follow_fork
+ and follow_fork implementations. This is nullptr if no inferior is
+ created for the child, because we want to detach from it.
+
+ - as a result, in follow_fork_inferior, detach from the parent inferior
+ (if needed) only after the target_follow_fork call. This is needed
+ because we want to call target_follow_fork before the parent's
+ target stack is torn down.
+
+ - hand over to the targets in the parent's target stack (including the
+ process target) the responsibility to push themselves, if needed, to
+ the child's target stack. Also hand over the responsibility to the
+ process target, at the same time, to create the child's initial
+ thread (just like we do for follow_exec).
+
+ - pass the child inferior to exec_on_vfork, so we don't need to swap
+ the current inferior between parent and child. Nothing in
+ exec_on_vfork depends on the current inferior, after this change.
+
+ Although this could perhaps be replaced with just having the exec
+ target implement follow_fork and push itself in the child's target
+ stack, like the process target does... We would just need to make
+ sure the process target calls beneath()->follow_fork(...). I'm not
+ sure about this one.
+
+ gdb/ChangeLog:
+
+ * target.h (struct target_ops) <follow_fork>: Add inferior*
+ parameter.
+ (target_follow_fork): Likewise.
+ * target.c (default_follow_fork): Likewise.
+ (target_follow_fork): Likewise.
+ * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
+ (fbsd_nat_target::follow_fork): Likewise, and call
+ inf_ptrace_target::follow_fork.
+ * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
+ * linux-nat.c (linux_nat_target::follow_fork): Likewise, and
+ call inf_ptrace_target::follow_fork.
+ * obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise.
+ * obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call
+ inf_ptrace_target::follow_fork.
+ * remote.c (class remote_target) <follow_fork>: Likewise.
+ (remote_target::follow_fork): Likewise, and call
+ process_stratum_target::follow_fork.
+ * process-stratum-target.h (class process_stratum_target)
+ <follow_fork>: New.
+ * process-stratum-target.c
+ (process_stratum_target::follow_fork): New.
+ * target-delegates.c: Re-generate.
+
+ [1] https://github.com/ROCm-Developer-Tools/ROCgdb
+
+ Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929
+
+2021-08-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-03 Carl Love <cel@us.ibm.com>
+
+ Fixes for mi-fortran-modules.exp fixes
+ Output has additional information for a given filename.
+
+ gdb/testsuite/ChangeLog
+ * gdb.mi/mi-fortran-modules.exp (system_modules_pattern,
+ system_module_symbols_pattern): Add check for additional symbols
+ on the line
+
+2021-08-03 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport: add debug assertions in gdb::optional::get
+ The libstdc++ version of optional contains some runtime checks enabled
+ when _GLIBCXX_DEBUG is defined. I think it would be useful if our
+ version contained similar checks.
+
+ Add checks in the two `get` methods, also conditional on _GLIBCXX_DEBUG.
+ I think it's simpler to use that macro rather than introducing a new
+ GDB-specific one, as I think that if somebody is interested in enabling
+ these runtime checks, they'll also be interested in enabling the
+ libstdc++ runtime checks (and vice-versa).
+
+ I implemented these checks using gdb_assert. Note that gdb_assert
+ throws (after querying the user), and we are in noexcept methods. That
+ means that std::terminate / abort will immediately be called. I think
+ this is ok, since if those were "real" _GLIBCXX_DEBUG checks, abort
+ would be called straight away.
+
+ If I add a dummy failure, it looks like so:
+
+ $ ./gdb -q -nx --data-directory=data-directory
+ /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = int]: Assertion `this->has_value ()' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n) n
+ [1] 658767 abort (core dumped) ./gdb -q -nx --data-directory=data-directory
+
+ Change-Id: Iadfdcd131425bd2ca6a2de30d7b22e9b3cc67793
+
+2021-08-03 Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
+
+ [gdb/testsuite] templates.exp to accept clang++ output
+ Please consider below testcase with intended error.
+ ``````````
+ constexpr const char cstring[] = "Eta";
+ template <const char*, typename T> class Column {};
+ using quick = Column<cstring,double>; // cstring without '&'
+
+ void lookup() {
+ quick c1;
+ c1.ls();
+ }
+ ``````````
+ It produces below error.
+ ``````````
+ no member named 'ls' in 'Column<&cstring, double>'.
+ ``````````
+ Please note that error message contains '&' for cstring, which is absent
+ in actual program.
+ Clang++ does not generate & in such cases and this should also be
+ accepted as correct output.
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.cp/templates.exp: Accept different but correct output
+ from the Clang++ compiled binary also.
+
+2021-08-03 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Handle compiler-generated suffixes in Ada names
+ The compiler may add a suffix to a mangled name. A typical example
+ would be splitting a function and creating a ".cold" variant.
+
+ This patch changes Ada decoding (aka demangling) to handle these
+ suffixes. It also changes the encoding process to handle them as
+ well.
+
+ A symbol like "function.cold" will now be displayed to the user as
+ "function[cold]". The "." is not simply preserved because that is
+ already used in Ada.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Remove uses of fprintf_symbol_filtered
+ I believe that many calls to fprintf_symbol_filtered are incorrect.
+ In particular, there are some that pass a symbol's print name, like:
+
+ fprintf_symbol_filtered (gdb_stdout, sym->print_name (),
+ current_language->la_language, DMGL_ANSI);
+
+ fprintf_symbol_filtered uses the "demangle" global to decide whether
+ or not to demangle -- but print_name does this as well. This can lead
+ to double-demangling. Normally this could be innocuous, except I also
+ plan to change Ada demangling in a way that causes this to fail.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Handle type qualifier for enumeration name
+ Pierre-Marie noticed that the Ada expression "TYPE'(NAME)" resolved
+ incorrectly when "TYPE" was an enumeration type. Here, "NAME" should
+ be unambiguous.
+
+ This patch fixes this problem. Note that the patch is not perfect --
+ it does not give an error if TYPE is an enumeration type but NAME is
+ not an enumerator but does have some other meaning in scope. Fixing
+ this proved difficult, and so I've left it out.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Remove the type_qualifier global
+ The type_qualifier global is no longer needed in the Ada expression
+ parser, so this removes it.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Defer Ada character literal resolution
+ In Ada, an enumeration type can use a character literal as one of the
+ enumerators. The Ada expression parser handles the appropriate
+ conversion.
+
+ It turns out, though, that this conversion was handled incorrectly.
+ For an expression like TYPE'(EXP), the conversion would be done for
+ any such literal appearing in EXP -- but only the outermost such
+ expression should really be affected.
+
+ This patch defers the conversion until the resolution phase, fixing
+ the bug.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Refactor Ada resolution
+ In a subsequent patch, it will be convenient if an Ada expression
+ operation can supply its own replacement object. This patch refactors
+ Ada expression resolution to make this possible.
+
+ Remove add_symbols_from_enclosing_procs
+ I noticed that add_symbols_from_enclosing_procs is empty, and can be
+ removed. The one caller, ada_add_local_symbols, can also be
+ simplified, removing some code that, I think, was an incorrect attempt
+ to handle nested functions.
+
+2021-08-02 Tom Tromey <tromey@adacore.com>
+
+ Avoid crash in varobj deletion
+ PR varobj/28131 points out a crash in the varobj deletion code. It
+ took a while to reproduce this, but essentially what happens is that a
+ top-level varobj deletes its root object, then deletes the "dynamic"
+ object. However, deletion of the dynamic object may cause
+ ~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:
+
+ gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
+ : gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
+ {
+ }
+
+ However, because var->root has already been destroyed, this is
+ invalid.
+
+ I've added a new test case. This doesn't reliably crash, but the
+ problem can easily be seen under valgrind (and, I presume, with ASAN,
+ though I did not try this).
+
+ Tested on x86-64 Fedora 32. I also propose putting this on the GDB 11
+ branch, with a suitable ChangeLog entry of course.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131
+
+2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-dwz-m
+ When running with target board cc-with-dwz-m, we run into:
+ ...
+ (gdb) file dw2-using-debug-str-no-debug-str^M
+ Reading symbols from dw2-using-debug-str-no-debug-str...^M
+ (gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
+ ...
+
+ With native, the .debug_str section is present in the
+ dw2-using-debug-str executable, and removed from the
+ dw2-using-debug-str-no-debug-str executable. When loading the latter, a dwarf
+ error is triggered.
+
+ With cc-with-dwz-m, the .debug_str section is not present in the
+ dw2-using-debug-str executable, because it's already moved to
+ .tmp/dw2-using-debug-str.dwz. Consequently, the removal has no effect, and no
+ dwarf error is triggered, which causes the FAIL.
+
+ The same problem arises with target board cc-with-gnu-debuglink.
+
+ Fix this by detecting whether the .debug_str section is missing, and skipping
+ the remainder of the test-case.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ * gdb.dwarf2/dw2-using-debug-str.exp: Handle missing .debug_str
+ section in dw2-using-debug-str.
+
+2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-gdb-index
+ When running with target board cc-with-gdb-index, we run into:
+ ...
+ (gdb) file dw2-using-debug-str-no-debug-str^M
+ Reading symbols from dw2-using-debug-str-no-debug-str...^M
+ Dwarf Error: DW_FORM_strp used without required section^M
+ (gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
+ ...
+
+ The test expects the dwarf error, but has no matching pattern for the entire
+ output.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ * gdb.dwarf2/dw2-using-debug-str.exp: Update regexp to match
+ cc-with-gdb-index output.
+
+2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp with cc-with-gdb-index
+ When running with target board cc-with-gdb-index, we run into:
+ ...
+ rm: cannot remove '/tmp/tmp.JmYTeiuFjj/*.gdb-index': \
+ No such file or directory^M
+ FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
+ couldn't remove files in temporary cache dir
+ ...
+
+ Fix this, as in gdb.base/index-cache.exp, by only FAILing when
+ $expecting_index_cache_use.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ * gdb.dwarf2/per-bfd-sharing.exp: Only expect index-cache files
+ when $expecting_index_cache_use.
+
+2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/gdb-index-nodebug.exp with cc-with-gdb-index
+ When running with target board cc-with-gdb-index, we run into:
+ ...
+ (gdb) save gdb-index .^M
+ Error while writing index for `gdb-index-nodebug': \
+ Cannot use an index to create the index^M
+ (gdb) FAIL: gdb.dwarf2/gdb-index-nodebug.exp: try to save gdb index
+ ...
+
+ Fix this by detecting an already present index, and marking the test
+ unsupported.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ * gdb.dwarf2/gdb-index-nodebug.exp: Mark unsupported when index
+ already present.
+
+2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.dwarf2/fission-relative-dwo.exp with cc-with-gdb-index
+ When running with target board cc-with-gdb-index, we run into:
+ ...
+ gdb compile failed, warning: Could not find DWO CU \
+ fission-relative-dwo.dwo(0x1234) referenced by CU at offset 0xc7 \
+ [in module outputs/gdb.dwarf2/fission-relative-dwo/.tmp/fission-relative-dwo]
+ UNTESTED: gdb.dwarf2/fission-relative-dwo.exp: fission-relative-dwo.exp
+ ERROR: failed to compile fission-relative-dwo
+ ...
+
+ The problem is that:
+ - the .dwo file is found relative to the executable, and
+ - cc-with-tweaks.sh moves the executable to a temp dir, but not
+ the .dwo file.
+
+ Fix this by copying the .dwo file alongside the executable in the temp dir.
+
+ Verified changes using shellcheck.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-08-02 Tom de Vries <tdevries@suse.de>
+
+ * contrib/cc-with-tweaks.sh: Copy .dwo files alongside executable.
+
+2021-08-02 Shahab Vahedi <shahab@synopsys.com>
+
+ gdb: Make the builtin "boolean" type an unsigned type
+ When printing the fields of a register that is of a custom struct type,
+ the "unpack_bits_as_long ()" function is used:
+
+ do_val_print (...)
+ cp_print_value_fields (...)
+ value_field_bitfield (...)
+ unpack_value_bitfield (...)
+ unpack_bits_as_long (...)
+
+ This function may sign-extend the extracted field while returning it:
+
+ val >>= lsbcount;
+
+ if (...)
+ {
+ valmask = (((ULONGEST) 1) << bitsize) - 1;
+ val &= valmask;
+ if (!field_type->is_unsigned ())
+ if (val & (valmask ^ (valmask >> 1)))
+ val |= ~valmask;
+ }
+
+ return val;
+
+ lsbcount: Number of lower bits to get rid of.
+ bitsize: The bit length of the field to be extracted.
+ val: The register value.
+ field_type: The type of field that is being handled.
+
+ While the logic here is correct, there is a problem when it is
+ handling "field_type"s of "boolean". Those types are NOT marked
+ as "unsigned" and therefore they end up being sign extended.
+ Although this is not a problem for "false" (0), it definitely
+ causes trouble for "true".
+
+ This patch constructs the builtin boolean type as such that it is
+ marked as an "unsigned" entity.
+
+ The issue tackled here was first encountered for arc-elf32 target
+ running on an x86_64 machine. The unit-test introduced in this change
+ has passed for all the targets (--enable-targets=all) running on the
+ same x86_64 host.
+
+ Fixes: https://sourceware.org/PR28104
+
+2021-08-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/maint.exp with cc-with-gdb-index
+ With target board cc-with-gdb-index we run into:
+ ...
+ FAIL: gdb.base/maint.exp: maint print statistics
+ ...
+
+ The output that is checked is:
+ ...
+ Statistics for 'maint':^M
+ Number of "minimal" symbols read: 53^M
+ Number of "full" symbols read: 40^M
+ Number of "types" defined: 60^M
+ Number of symbol tables: 7^M
+ Number of symbol tables with line tables: 2^M
+ Number of symbol tables with blockvectors: 2^M
+ Number of read CUs: 2^M
+ Number of unread CUs: 5^M
+ Total memory used for objfile obstack: 20320^M
+ Total memory used for BFD obstack: 4064^M
+ Total memory used for string cache: 4064^M
+ ...
+ and the regexp doesn't match because it expects the "Number of read/unread
+ CUs" lines in a different place.
+
+ Fix this by updating the regexp.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ * gdb.base/maint.exp: Update "maint print statistics" to match
+ output with target board cc-with-gdb-index.
+
+2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/index-cache.exp with cc-with-gdb-index
+ With target board cc-with-gdb-index we run into:
+ ...
+ FAIL: gdb.base/index-cache.exp: couldn't remove files in temporary cache dir
+ ...
+
+ The problem is that there are no files to remove, because the index cache
+ isn't used, as indicated by $expecting_index_cache_use.
+
+ Fix this by only FAILing when $expecting_index_cache_use.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-08-01 Tom de Vries <tdevries@suse.de>
+
+ * gdb.base/index-cache.exp:
+
+2021-08-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-30 Tom Tromey <tom@tromey.com>
+
+ Use iterator_range in more places
+ This changes a couple of spots to replace custom iterator range
+ classes with a specialization of iterator_range.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-07-30 Tom Tromey <tom@tromey.com>
+
+ Replace exception_print_same with operator!=
+ I noticed that exception_print_same is only used in a single spot, and
+ it seemed to be better as an operator!= method attached to
+ gdb_exception.
+
+ Regression tested on x86-64 Fedora 34.
+
+2021-07-30 Tom de Vries <tdevries@suse.de>
+
+ [gdb/build] Disable attribute nonnull
+ With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
+ breaker in gdb, which caused a broader review of the usage of the nonnull
+ attribute.
+
+ The current conclusion is that it's best to disable this. This is explained
+ at length in the gdbsupport/common-defs.h comment.
+
+ Tested by building with trunk gcc.
+
+ gdb/ChangeLog:
+
+ 2021-07-29 Tom de Vries <tdevries@suse.de>
+
+ * gdbsupport/common-defs.h (ATTRIBUTE_NONNULL): Disable.
+
+2021-07-30 Clément Chigot <clement.chigot@atos.net>
+
+ gas: ensure XCOFF DWARF subsection are initialized to 0
+ debug_abbrev doesn't use end_exp to compute its size. However, it must
+ be NULL. Otherwise, ppc_xcoff_end might try to access uninitialized
+ memory.
+
+ gas/
+ * config/tc-ppc.c (ppc_dwsect): Use XCNEW instead of XNEW when creating
+ a new subsection.
+
+2021-07-30 Clément Chigot <clement.chigot@atos.net>
+
+ bfd: ensure that symbols targeted by DWARF relocations are kept in XCOFF
+ This patch improves XCOFF garbage collector pass, in order to keep
+ symbols being referenced only by special sections like DWARF sections.
+
+ bfd/
+ * xcofflink.c (xcoff_mark): Replace SEC_MARK by gc_mark.
+ Look through relocations even if xcoff_section_data is NULL.
+ (xcoff_sweep): Check if any sections of a file is kept before
+ adding its special sections.
+ Call xcoff_mark for special sessions being kept instead of just
+ marking them.
+ (SEC_MARK): Remove
+ (xcoff_mark_symbol): Replace SEC_MARK by gc_mark.
+ (xcoff_keep_symbol_p): Likewise.
+ (bfd_xcoff_size_dynamic_sections): Likewise.
+ (xcoff_find_tc0): Likewise.
+
+2021-07-30 Clément Chigot <clement.chigot@atos.net>
+
+ bfd: avoid a crash when debug_section isn't created in XCOFF
+ bfd/
+ * xcofflink.c (bfd_xcoff_size_dynamic_sections):
+ Add check to know if debug_section is initialized.
+
+2021-07-30 Alan Modra <amodra@gmail.com>
+
+ readelf: catch archive_file_size of -1
+ Fuzzers might put -1 in arhdr.ar_size. If the size is rounded up to
+ and even number of bytes we get zero.
+
+ * readelf.c (process_archive): Don't round up archive_file_size.
+ Do round up next_arhdr_offset calculation.
+
+2021-07-30 Alan Modra <amodra@gmail.com>
+
+ reloc_upper_bound size calculations
+ Section reloc_count is an unsigned int. Adding one for a NULL
+ terminator to an array of arelent pointers can wrap the count to
+ zero. Avoid that by doing the addition as longs.
+
+ * coffgen.c (coff_get_reloc_upper_bound): Don't overflow unsigned
+ int expression.
+ * elf.c (_bfd_elf_get_reloc_upper_bound): Likewise.
+ * elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Likewise.
+ * mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
+ * vms-alpha.c (alpha_vms_get_reloc_upper_bound): Likewise.
+
+2021-07-30 Alan Modra <amodra@gmail.com>
+
+ Sanity check _bfd_coff_read_string_table
+ * coffgen.c (_bfd_coff_read_string_table): Catch overflows
+ when calculating string table file location.
+
+2021-07-30 Alan Modra <amodra@gmail.com>
+
+ IMAGE_SCN_LNK_NRELOC_OVFL
+ From microsoft docs: It is an error if IMAGE_SCN_LNK_NRELOC_OVFL is
+ set and there are fewer than 0xffff relocations in the section.
+
+ * coffcode.h (coff_set_alignment_hook): Sanity check overflow
+ reloc count.
+
+2021-07-30 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fix nr_bits gdb_assert in append_flags_type_field
+ The assertion
+
+ gdb_assert (nr_bits >= 1 && nr_bits <= type_bitsize);
+
+ is not correct. Well, it's correct in that we do want the number of
+ bits to be in the range [1, type_bitsize]. But we don't check anywhere
+ that the end of the specified flag is within the containing type.
+
+ The following code should generate a failed assertion, as the flag goes
+ past the 32 bits of the underlying type, but it's currently not caught:
+
+ static void
+ test_print_flag (gdbarch *arch)
+ {
+ type *flags_type = arch_flags_type (arch, "test_type", 32);
+ type *field_type = builtin_type (arch)->builtin_uint32;
+ append_flags_type_field (flags_type, 31, 2, field_type, "invalid");
+ }
+
+ (You can test this by registering it as a selftest using
+ selftests::register_test_foreach_arc and running.)
+
+ Change the assertion to verify that the end bit is within the range of
+ the underlying type. This implicitly verifies that nr_bits is not
+ too big as well, so we don't need a separate assertion for that.
+
+ Change-Id: I9be79e5fd7a5917bf25b03b598727e6274c892e8
+ Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
+
+2021-07-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-29 John Baldwin <jhb@FreeBSD.org>
+
+ obsd-nat: Report both thread and PID in ::pid_to_str.
+ This improves the output of info threads when debugging multiple
+ inferiors (e.g. after a fork with detach_on_fork disabled).
+
+2021-07-29 John Baldwin <jhb@FreeBSD.org>
+
+ obsd-nat: Various fixes for fork following.
+ - Don't use #ifdef's on ptrace ops. obsd-nat.h didn't include
+ <sys/ptrace.h>, so the virtual methods weren't always overridden
+ causing the fork following to not work. In addition, the thread and
+ fork code is intertwined in ::wait and and the lack of #ifdef's
+ there already assumed both were present. Finally, both of these
+ ptrace ops have been present in OpenBSD for at least 10 years.
+
+ - Move duplicated code to enable PTRACE_FORK event reporting to a
+ single function and invoke it on new child processes reported via
+ PTRACE_FORK.
+
+ - Don't return early from PTRACE_FORK handling, but instead reset
+ wptid to the correct ptid if the child reports its event before the
+ parent. This allows the ptid fixup code to add thread IDs if the
+ first event for a process is a PTRACE_FORK event. This also
+ properly returns ptid's with thread IDs when reporting PTRACE_FORK
+ events.
+
+ - Handle detach_fork by skipping the PT_DETACH.
+
+2021-07-29 John Baldwin <jhb@FreeBSD.org>
+
+ obsd-nat: Various fixes to obsd_nat_target::wait.
+ - Call inf_ptrace_target::wait instead of duplicating the code.
+ Replace a check for WIFSTOPPED on the returned status from waitpid
+ by checking for TARGET_WAITKIND_STOPPED in the parsed status as is
+ done in fbsd_nat_target::wait.
+
+ - Don't use inferior_ptid when deciding if a new process is a child vs
+ parent of the fork. Instead, use find_inferior_pid and assume that
+ if an inferior already exists, the pid in question is the parent;
+ otherwise, the pid is the child.
+
+ - Don't use inferior_ptid when deciding if the ptid of the process
+ needs to be updated with an LWP ID, or if this is a new thread.
+ Instead, use the approach from fbsd-nat which is to check if a ptid
+ without an LWP exists and if so update the ptid of that thread
+ instead of adding a new thread.
+
+2021-07-29 John Baldwin <jhb@FreeBSD.org>
+
+ x86-bsd-nat: Only define gdb_ptrace when using debug registers.
+ This fixes an unused function warning on OpenBSD which does not
+ support PT_GETDBREGS.
+
+2021-07-29 John Baldwin <jhb@FreeBSD.org>
+
+ Don't compile x86 debug register support on OpenBSD.
+ Simon Marchi tried gdb on OpenBSD, and it immediately segfaults when
+ running a program. Simon tracked down the problem to x86_dr_low.get_status
+ being nullptr at this point:
+
+ (lldb) print x86_dr_low.get_status
+ (unsigned long (*)()) $0 = 0x0000000000000000
+ (lldb) bt
+ * thread #1, stop reason = step over
+ * frame #0: 0x0000033b64b764aa gdb`x86_dr_stopped_data_address(state=0x0000033d7162a310, addr_p=0x00007f7ffffc5688) at x86-dregs.c:645:12
+ frame #1: 0x0000033b64b766de gdb`x86_dr_stopped_by_watchpoint(state=0x0000033d7162a310) at x86-dregs.c:687:10
+ frame #2: 0x0000033b64ea5f72 gdb`x86_stopped_by_watchpoint() at x86-nat.c:206:10
+ frame #3: 0x0000033b64637fbb gdb`x86_nat_target<obsd_nat_target>::stopped_by_watchpoint(this=0x0000033b65252820) at x86-nat.h:100:12
+ frame #4: 0x0000033b64d3ff11 gdb`target_stopped_by_watchpoint() at target.c:468:46
+ frame #5: 0x0000033b6469b001 gdb`watchpoints_triggered(ws=0x00007f7ffffc61c8) at breakpoint.c:4790:32
+ frame #6: 0x0000033b64a8bb8b gdb`handle_signal_stop(ecs=0x00007f7ffffc61a0) at infrun.c:6072:29
+ frame #7: 0x0000033b64a7e3a7 gdb`handle_inferior_event(ecs=0x00007f7ffffc61a0) at infrun.c:5694:7
+ frame #8: 0x0000033b64a7c1a0 gdb`fetch_inferior_event() at infrun.c:4090:5
+ frame #9: 0x0000033b64a51921 gdb`inferior_event_handler(event_type=INF_REG_EVENT) at inf-loop.c:41:7
+ frame #10: 0x0000033b64a827c9 gdb`infrun_async_inferior_event_handler(data=0x0000000000000000) at infrun.c:9384:3
+ frame #11: 0x0000033b6465bd4f gdb`check_async_event_handlers() at async-event.c:335:4
+ frame #12: 0x0000033b65070917 gdb`gdb_do_one_event() at event-loop.cc:216:10
+ frame #13: 0x0000033b64af0db1 gdb`start_event_loop() at main.c:421:13
+ frame #14: 0x0000033b64aefe9a gdb`captured_command_loop() at main.c:481:3
+ frame #15: 0x0000033b64aed5c2 gdb`captured_main(data=0x00007f7ffffc6470) at main.c:1353:4
+ frame #16: 0x0000033b64aed4f2 gdb`gdb_main(args=0x00007f7ffffc6470) at main.c:1368:7
+ frame #17: 0x0000033b6459d787 gdb`main(argc=5, argv=0x00007f7ffffc6518) at gdb.c:32:10
+ frame #18: 0x0000033b6459d521 gdb`___start + 321
+
+ On BSDs, get_status is set in _initialize_x86_bsd_nat, but only if
+ HAVE_PT_GETDBREGS is defined. PT_GETDBREGS doesn't exist on OpenBSD, so
+ get_status (and the other fields of x86_dr_low) are left as nullptr.
+
+ OpenBSD doesn't support getting or setting the x86 debug registers, so
+ fix by omitting debug register support entirely on OpenBSD:
+
+ - Change x86bsd_nat_target to only inherit from x86_nat_target if
+ PT_GETDBREGS is supported.
+
+ - Don't include x86-nat.o and nat/x86-dregs.o for OpenBSD/amd64. They
+ were already omitted for OpenBSD/i386.
+
+2021-07-29 Carl Love <cel@us.ibm.com>
+
+ Fix for gdb.tui/tui-layout-asm.exp
+ The width of the window is too narrow to display the entire assembly line.
+ The width of the columns in the window changes as the test walks thru the
+ terminal window output. The column change results in the first and second
+ reads of the same line to differ thus causing the test to fail. Increasing
+ the width of the window keeps the column width consistent thru the test.
+
+ If the test fails, the added check prints an message to the log file if
+ the failure may be due to the window being too narrow.
+
+ gdb/testsuite/ChangeLog
+
+ * gdb.tui/tui-layout-asm.exp: Replace window width of 80 with the
+ tui_asm_window_width variable for the width. Add if
+ count_whitespace check.
+ (count_whitespace): New proc
+
+2021-07-29 George Barrett <bob@bob131.so>
+
+ guile/scm-math: indentation fixes
+ Changes the indenting of a few expressions in
+ vlscm_convert_typed_number to be better in line with the prevailing
+ code style.
+
+ gdb/ChangeLog:
+
+ 2021-07-30 George Barrett <bob@bob131.so>
+
+ * guile/scm-math.c (vlscm_convert_typed_number): Fix the
+ indentation of calls to gdbscm_make_out_of_range_error.
+
+ Change-Id: I7463998b77c17a00e88058e89b52fa029ee40e03
+
+2021-07-29 George Barrett <bob@bob131.so>
+
+ guile: fix make-value with pointer type
+ Calling the `make-value' procedure with an integer value and a pointer
+ type for the #:type argument triggers a failed assertion in
+ `get_unsigned_type_max', as that function doesn't consider pointers to
+ be an unsigned type. This commit fixes the issue by adding a separate
+ code path for pointers.
+
+ As previously suggested, range checking is done using a new helper
+ function in gdbtypes.
+
+ gdb/ChangeLog:
+
+ 2021-07-30 George Barrett <bob@bob131.so>
+
+ * gdbtypes.h (get_pointer_type_max): Add declaration.
+ * gdbtypes.c (get_pointer_type_max): Add definition for new
+ helper function.
+ * guile/scm-math.c (vlscm_convert_typed_number): Add code path
+ for handling conversions to pointer types without failing an
+ assert.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-30 George Barrett <bob@bob131.so>
+
+ * gdb.guile/scm-math.exp (test_value_numeric_ops): Add test
+ for creating pointers with make-value.
+ (test_make_pointer_value, test_pointer_numeric_range): Add
+ test procedures containing checks for integer-to-pointer
+ validation.
+
+ Change-Id: I9994dd1c848840a3d995f745e6d72867732049f0
+
+2021-07-29 George Barrett <bob@bob131.so>
+
+ gdbtypes: return value from get_unsigned_type_max
+ Changes the signature of get_unsigned_type_max to return the computed
+ value rather than returning void and writing the value into a pointer
+ passed by the caller.
+
+ gdb/ChangeLog:
+
+ 2021-07-30 George Barrett <bob@bob131.so>
+
+ * gdbtypes.h (get_unsigned_type_max): Change signature to
+ return the result instead of accepting a pointer argument in
+ which to store the result.
+ * gdbtypes.c (get_unsigned_type_max): Likewise.
+ * guile/scm-math.c (vlscm_convert_typed_number): Update caller
+ of get_unsigned_type_max.
+ (vlscm_integer_fits_p): Likewise.
+
+ Change-Id: Ibb1bf0c0fa181fac7853147dfde082a7d1ae2323
+
+2021-07-29 Clément Chigot <clement.chigot@atos.net>
+
+ gas: improve C_BSTAT and C_STSYM symbols handling on XCOFF
+ A C_BSTAT debug symbol specifies the beginning of a static block.
+ Its n_value is the index of the csect containing static symbols.
+ A C_STSYM debug symbol represents the stabstring of a statically
+ allocated symbol. Its n_value is the offset in the csect pointed
+ by the containing C_BSTAT.
+
+ These two special n_value were not correctly handled both when
+ generating object files with gas or when reading them with objdump.
+ This patch tries to improve that and, above all, to allow gas-generated
+ object files with such symbols to be accepted by AIX ld.
+
+ bfd/
+ * coff-bfd.c (bfd_coff_get_syment): Adjust n_value of symbols
+ having fix_value = 1 in order to be an index and not a memory
+ offset.
+ * coffgen.c (coff_get_symbol_info): Likewize.
+ (coff_print_symbol): Likewize.
+
+ gas/
+ * config/tc-ppc.c (ppc_frob_label): Don't change within if
+ already set.
+ (ppc_stabx): Remove workaround changing exp.X_add_symbol's
+ within.
+ * config/tc-ppc.h (struct ppc_tc_sy): Update comments.
+ * symbols.c (resolve_symbol_value): Remove symbol update
+ when final_val is 0 and it's an AIX debug symbol.
+ * testsuite/gas/ppc/aix.exp: Add new tests.
+ * testsuite/gas/ppc/xcoff-stsym-32.d: New test.
+ * testsuite/gas/ppc/xcoff-stsym-64.d: New test.
+ * testsuite/gas/ppc/xcoff-stsym.s: New test.
+
+2021-07-29 George Barrett <bob@bob131.so>
+
+ Guile: temporary breakpoints
+ Adds API to the Guile bindings for creating temporary breakpoints and
+ querying whether an existing breakpoint object is temporary. This is
+ effectively a transliteration of the Python implementation.
+
+ It's worth noting that the added `is_temporary' flag is ignored in the
+ watchpoint registration path. This replicates the behaviour of the
+ Python implementation, but might be a bit surprising for users.
+
+ gdb/ChangeLog:
+
+ 2021-06-09 George Barrett <bob@bob131.so>
+
+ * guile/scm-breakpoint.c (gdbscm_breakpoint_object::spec): Add
+ is_temporary field.
+ (temporary_keyword): Add keyword object for make-breakpoint
+ argument parsing.
+ (gdbscm_make_breakpoint): Accept #:temporary keyword argument
+ and store the value in the allocated object's
+ spec.is_temporary.
+ (gdbscm_register_breakpoint_x): Pass the breakpoint's
+ spec.is_temporary value to create_breakpoint.
+ (gdbscm_breakpoint_temporary): Add breakpoint-temporary?
+ procedure implementation.
+ (breakpoint_functions::make-breakpoint): Update documentation
+ string and fix a typo.
+ (breakpoint_functions::breakpoint-temporary?): Add
+ breakpoint-temporary? procedure.
+ (gdbscm_initialize_breakpoints): Initialise temporary_keyword
+ variable.
+ NEWS (Guile API): Mention new temporary breakpoints API.
+
+ gdb/doc/ChangeLog:
+
+ 2021-06-09 George Barrett <bob@bob131.so>
+
+ * guile.texi (Breakpoints In Guile): Update make-breakpoint
+ documentation to reflect new #:temporary argument.
+ Add documentation for new breakpoint-temporary? procedure.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-06-09 George Barrett <bob@bob131.so>
+
+ * gdb.guile/scm-breakpoint.exp: Add additional tests for
+ temporary breakpoints.
+
+ Change-Id: I2de332ee7c256f5591d7141ab3ad50d31b871d17
+
+2021-07-29 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-28 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: clean up some things in features/Makefile
+ Clean up some things I noticed:
+
+ - we generate a regformats/microblaze-with-stack-protect.dat file. I
+ don't think this is used. It could be used by a GDBserver built for
+ Microblaze, but GDBserver isn't ported to Microblaze. So I don't
+ think that's used at all. Remove the entry in features/Makefile and
+ the file itself.
+
+ - There are a bunch of *-expedite values in features/Makefile for
+ architectures for which we don't generate dat files. AFAIK, these
+ *-expedite values are only used when generating dat files. Remove
+ those that are not necessary.
+
+ - 32bit-segments.xml is not listed in the Makfile, but it's used. This
+ means that it wouldn't get re-generated if we were to change how C
+ files are generated from the XML. It looks like it was simply
+ forgotten, add it.
+
+ Change-Id: I112d00db317102270e1df924473c37122ccb6c3a
+
+2021-07-28 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Simplify check for distinct TMM register operands
+ If any pair of operands in AMX instructions with 3 TMM register operands
+ are the same, the instruction will UD. Don't call register_number to
+ check for distinct TMM register operands since all TMM register operands
+ have the same size.
+
+ * config/tc-i386.c (check_VecOperands): Remove register_number
+ call when checking for distinct TMM register operands.
+
+2021-07-28 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Run tmpdir/pr28138 only for native build
+ * PR ld/28138
+ * testsuite/ld-plugin/lto.exp: Run tmpdir/pr28138 only for
+ native build.
+
+2021-07-28 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Close the file descriptor if there is no archive fd
+ Close the file descriptor if there is no archive plugin file descriptor
+ to avoid running out of file descriptors on thin archives with many
+ archive members.
+
+ bfd/
+
+ PR ld/28138
+ * plugin.c (bfd_plugin_close_file_descriptor): Close the file
+ descriptor there is no archive plugin file descriptor.
+
+ ld/
+
+ PR ld/28138
+ * testsuite/ld-plugin/lto.exp: Run ld/28138 tests.
+ * testsuite/ld-plugin/pr28138.c: New file.
+ * testsuite/ld-plugin/pr28138-1.c: Likewise.
+ * testsuite/ld-plugin/pr28138-2.c: Likewise.
+ * testsuite/ld-plugin/pr28138-3.c: Likewise.
+ * testsuite/ld-plugin/pr28138-4.c: Likewise.
+ * testsuite/ld-plugin/pr28138-5.c: Likewise.
+ * testsuite/ld-plugin/pr28138-6.c: Likewise.
+ * testsuite/ld-plugin/pr28138-7.c: Likewise.
+
+2021-07-28 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Report error reason when a library cannot be found
+ With "ulimit -n 20", report:
+
+ ld: cannot find -lgcc: Too many open files
+
+ instead of
+
+ ld: cannot find -lgcc
+
+ * ldfile.c (ldfile_open_file): Rport error reason when a library
+ cannot be found.
+
+2021-07-28 Sergei Trofimovich <siarheit@google.com>
+
+ texi2pod.pl: add no-op --no-split option support [PR28144]
+ Change 2faf902da ("generate single html manual page by default")
+ added use of --no-split option to makeinfo. binutils reuses
+ makeinfo options for texi2pod.pl wrapper. Unsupported option
+ led to silent manpage truncation.
+
+ The change adds no-op option support.
+
+ etc/
+
+ * texi2pod.pl: Handle no-op --no-split option.
+
+2021-07-28 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: fix missing space in some info variables output
+ Fixes PR gdb/28121. When a user declares an array like this:
+
+ int * const foo_1[3];
+
+ And in GDB the user does this:
+
+ (gdb) info variables foo
+ All variables matching regular expression "foo":
+
+ File test.c:
+ 1: int * constfoo_1[3];
+
+ Notice the missing space between 'const' and 'foo_1'. This is fixed
+ in c_type_print_varspec_prefix (c-typeprint.c) by passing through the
+ flag that indicates if a trailing space is needed, rather than hard
+ coding the flag to false as we currently do.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28121
+
+2021-07-28 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5
+ [ I've confused things by forgetting to add -gdwarf-4 in $subject of
+ commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with
+ gcc-11". So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is
+ the default for gcc-11. I keep getting confused because of working with a
+ system gcc-11 compiler that was patched to switch the default back to
+ -gdwarf-4. ]
+
+ When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default
+ -gdwarf-5), I run into:
+ ...
+ (gdb) print pa_ptr.all^M
+ Unhandled dwarf expression opcode 0xff^M
+ (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all
+ ...
+
+ What happens is that pa_ptr:
+ ...
+ <2><1523>: Abbrev Number: 3 (DW_TAG_variable)
+ <1524> DW_AT_name : pa_ptr
+ <1529> DW_AT_type : <0x14fa>
+ ...
+ has type:
+ ...
+ <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef)
+ <14fb> DW_AT_name : foo__packed_array_ptr
+ <1500> DW_AT_type : <0x1504>
+ <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type)
+ <1505> DW_AT_byte_size : 8
+ <1505> DW_AT_type : <0x1509>
+ ...
+ which is a pointer to a subrange:
+ ...
+ <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type)
+ <150a> DW_AT_lower_bound : 0
+ <150b> DW_AT_upper_bound : 0x3fffffffffffffffff
+ <151b> DW_AT_name : foo__packed_array
+ <151f> DW_AT_type : <0x15cc>
+ <1523> DW_AT_artificial : 1
+ <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type)
+ <15cd> DW_AT_byte_size : 16
+ <15ce> DW_AT_encoding : 7 (unsigned)
+ <15cf> DW_AT_name : long_long_long_unsigned
+ <15d3> DW_AT_artificial : 1
+ ...
+ with upper bound of form DW_FORM_data16.
+
+ In gdb/dwarf/attribute.h we have:
+ ...
+ /* Return non-zero if ATTR's value falls in the 'constant' class, or
+ zero otherwise. When this function returns true, you can apply
+ the constant_value method to it.
+ ...
+ DW_FORM_data16 is not considered as constant_value cannot handle
+ that. */
+ bool form_is_constant () const;
+ ...
+ so instead we have attribute::form_is_block (DW_FORM_data16) == true.
+
+ Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR
+ instead of a PROP_CONST and end up trying to evaluate the constant
+ 0x3fffffffffffffffff as if it were a locexpr, which causes the
+ "Unhandled dwarf expression opcode 0xff".
+
+ In contrast, with -gdwarf-4 we have:
+ ...
+ <164c> DW_AT_upper_bound : 18 byte block: \
+ 9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \
+ (DW_OP_implicit_value 16 byte block: \
+ ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 )
+ ...
+
+ Fix the dwarf error by translating the DW_FORM_data16 constant into a
+ PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same
+ result as with -gdwarf-4:
+ ...
+ (gdb) print pa_ptr.all^M
+ That operation is not available on integers of more than 8 bytes.^M
+ (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \
+ (PRMS: gdb/20991)
+ ...
+
+ Tested on x86_64-linux, with gcc-11 and target board
+ unix/gdb:debug_flags=-gdwarf-5.
+
+ gdb/ChangeLog:
+
+ 2021-07-25 Tom de Vries <tdevries@suse.de>
+
+ * dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.
+
+2021-07-28 will schmidt <will_schmidt@vnet.ibm.com>
+
+ Externalize the _bfd_set_gp_value function
+ This change adds an external-visible wrapper for the _bfd_set_gp_value
+ function. This is a prerequisite for some gdb patches that better
+ handle powerpc64le relocations against ".TOC.".
+
+ * bfd.c (bfd_set_gp_value): New externally visible wrapper
+ for _bfd_set_gp_value.
+ * bfd-in2.h: Regenerate.
+
+2021-07-28 Alan Modra <amodra@gmail.com>
+
+ PowerPC: ignore sticky options for .machine
+ PowerPC gas and objdump for a long time have allowed certain -m/-M
+ options that extend a base cpu with extra functional units to be
+ specified before the base cpu. For example, "-maltivec -mpower4" is
+ the same as "-mpower4 -maltivec". See
+ https://sourceware.org/pipermail/binutils/2008-January/054935.html
+
+ It doesn't make as much sense that .machine keep any of these
+ "sticky" flags when handling a new base cpu. See gcc PR101393. I
+ think that instead .machine ought to override the command line.
+ That's what this patch does. It is still possible to extend cpu
+ functionality with .machine. For example the following can be
+ assembled when selecting a basic -mppc on the command line:
+ .machine power5
+ .machine altivec
+ frin 1,2
+ lvsr 3,4,5
+ Here, ".machine altivec" extends the ".machine power5" so that both
+ the power5 "frin" instruction and the altivec "lvsr" instruction are
+ enabled. Swapping the two ".machine" directives would result in
+ failure to assemble "lvsr".
+
+ This change will expose some assembly errors, such as the one in
+ glibc/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c, a file
+ compiled with -maltivec but containing
+ asm volatile (".machine push;\n"
+ ".machine \"power5\";\n"
+ "vspltisb %0,0;\n"
+ "vspltisb %1,-1;\n"
+ "vpkuwus %0,%0,%1;\n"
+ "mfvscr %0;\n"
+ "stvx %0,0,%2;\n"
+ ".machine pop;"
+ : "=v" (v0), "=v" (v1)
+ : "r" (vscr_ptr)
+ : "memory");
+ It's just wrong to choose power5 for a bunch of altivec instructions
+ and in fact all of those .machine directives are unnecessary.
+
+ * config/tc-ppc.c (ppc_machine): Don't use command line
+ sticky options.
+
+2021-07-28 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail for PR gcc/101643
+ With gcc 8.5.0 I run into:
+ ...
+ (gdb) print bad^M
+ $2 = (0 => 0 <repeats 25 times>)^M
+ (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+ ...
+ while with gcc 9.3.1 we have instead:
+ ...
+ (gdb) print bad^M
+ $2 = (false <repeats 196 times>)^M
+ (gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+ ...
+
+ This is caused by gcc PR, which I've filed at
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array
+ not described as packed".
+
+ Fix by marking this as XFAIL.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-07-27 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/26904
+ * gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail.
+
+2021-07-27 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add xfail for PR gcc/101633
+ With gcc 7.5.0, I run into:
+ ...
+ (gdb) print objects^M
+ $1 = ((tag => object, values => ()), (tag => unused))^M
+ (gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
+ ...
+ while with gcc 8.5.0 we have:
+ ...
+ (gdb) print objects^M
+ $1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
+ (gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
+ ...
+
+ This is due to a gcc PR, which I've filed at
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug]
+ DW_TAG_subrange_type missing DW_AT_upper_bound".
+
+ Fix by marking this and related FAILs as XFAIL.
+
+ Tested on x86_64-linux.
+
+ gdb/ChangeLog:
+
+ 2021-07-27 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/26903
+ * gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails.
+
+2021-07-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: remove VALUE_FRAME_ID and fix another frame debug issue
+ This commit was originally part of this patch series:
+
+ (v1): https://sourceware.org/pipermail/gdb-patches/2021-May/179357.html
+ (v2): https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
+ (v3): https://sourceware.org/pipermail/gdb-patches/2021-July/181028.html
+
+ However, that series is being held up in review, so I wanted to break
+ out some of the non-related fixes in order to get these merged.
+
+ This commit addresses two semi-related issues, both of which are
+ problems exposed by using 'set debug frame on'.
+
+ The first issue is in frame.c in get_prev_frame_always_1, and was
+ introduced by this commit:
+
+ commit a05a883fbaba69d0f80806e46a9457727fcbe74c
+ Date: Tue Jun 29 12:03:50 2021 -0400
+
+ gdb: introduce frame_debug_printf
+
+ This commit replaced fprint_frame with frame_info::to_string.
+ However, the former could handle taking a nullptr while the later, a
+ member function, obviously requires a non-nullptr in order to make the
+ function call. In one place we are not-guaranteed to have a
+ non-nullptr, and so, there is the possibility of triggering undefined
+ behaviour.
+
+ The second issue addressed in this commit has existed for a while in
+ GDB, and would cause this assertion:
+
+ gdb/frame.c:622: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed.
+
+ We attempt to get the frame_id for a frame while we are computing the
+ frame_id for that same frame.
+
+ What happens is that when GDB stops we create a frame_info object for
+ the sentinel frame (frame #-1) and then we attempt to unwind this
+ frame to create a frame_info object for frame #0.
+
+ In the test case used here to expose the issue we have created a
+ Python frame unwinder. In the Python unwinder we attemt to read the
+ program counter register.
+
+ Reading this register will initially create a lazy register value.
+ The frame-id stored in the lazy register value will be for the
+ sentinel frame (lazy register values hold the frame-id for the frame
+ from which the register will be unwound).
+
+ However, the Python unwinder does actually want to examine the value
+ of the program counter, and so the lazy register value is resolved
+ into a non-lazy value. This sends GDB into value_fetch_lazy_register
+ in value.c.
+
+ Now, inside this function, if 'set debug frame on' is in effect, then
+ we want to print something like:
+
+ frame=%d, regnum=%d(%s), ....
+
+ Where 'frame=%d' will be the relative frame level of the frame for
+ which the register is being fetched, so, in this case we would expect
+ to see 'frame=0', i.e. we are reading a register as it would be in
+ frame #0. But, remember, the lazy register value actually holds the
+ frame-id for frame #-1 (the sentinel frame).
+
+ So, to get the frame_info for frame #0 we used to call:
+
+ frame = frame_find_by_id (VALUE_FRAME_ID (val));
+
+ Where VALUE_FRAME_ID is:
+
+ #define VALUE_FRAME_ID(val) (get_prev_frame_id_by_id (VALUE_NEXT_FRAME_ID (val)))
+
+ That is, we start with the frame-id for the next frame as obtained by
+ VALUE_NEXT_FRAME_ID, then call get_prev_frame_id_by_id to get the
+ frame-id of the previous frame.
+
+ The get_prev_frame_id_by_id function finds the frame_info for the
+ given frame-id (in this case frame #-1), calls get_prev_frame to get
+ the previous frame, and then calls get_frame_id.
+
+ The problem here is that calling get_frame_id requires that we know
+ the frame unwinder, so then have to try each frame unwinder in turn,
+ which would include the Python unwinder.... which is where we started,
+ and thus we have a loop!
+
+ To prevent this loop GDB has an assertion in place, which is what
+ actually triggers.
+
+ Solving the assertion failure is pretty easy, if we consider the code
+ in value_fetch_lazy_register and get_prev_frame_id_by_id then what we
+ do is:
+
+ 1. Start with a frame_id taken from a value,
+ 2. Lookup the corresponding frame,
+ 3. Find the previous frame,
+ 4. Get the frame_id for that frame, and
+ 5. Lookup the corresponding frame
+ 6. Print the frame's level
+
+ Notice that steps 3 and 5 give us the exact same result, step 4 is
+ just wasted effort. We could shorten this process such that we drop
+ steps 4 and 5, thus:
+
+ 1. Start with a frame_id taken from a value,
+ 2. Lookup the corresponding frame,
+ 3. Find the previous frame,
+ 6. Print the frame's level
+
+ This will give the exact same frame as a result, and this is what I
+ have done in this patch by removing the use of VALUE_FRAME_ID from
+ value_fetch_lazy_register.
+
+ Out of curiosity I looked to see how widely VALUE_FRAME_ID was used,
+ and saw it was only used in one other place in valops.c:value_assign,
+ where, once again, we take the result of VALUE_FRAME_ID and pass it to
+ frame_find_by_id, thus introducing a redundant frame_id lookup.
+
+ I don't think the value_assign case risks triggering the assertion
+ though, as we are unlikely to call value_assign while computing the
+ frame_id for a frame, however, we could make value_assign slightly
+ more efficient, with no real additional complexity, by removing the
+ use of VALUE_FRAME_ID.
+
+ So, in this commit, I completely remove VALUE_FRAME_ID, and replace it
+ with a use of VALUE_NEXT_FRAME_ID, followed by a direct call to
+ get_prev_frame_always, this should make no difference in either case,
+ and resolves the assertion issue from value.c.
+
+ As I said, this patch was originally part of another series, the
+ original test relied on the fixes in that original series. However, I
+ was able to create an alternative test for this issue by enabling
+ frame debug within an existing test script.
+
+ This commit probably fixes bug PR gdb/27938, though the bug doesn't
+ have a reproducer attached so it is not possible to know for sure.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27938
+
+2021-07-27 Chenghua Xu <xuchenghua@loongson.cn>
+
+ Correct gs264e bfd_mach in mips_arch_choices.
+ opcodes/
+ * mips-dis.c (mips_arch_choices): Correct gs264e bfd_mach.
+
+2021-07-27 Roland McGrath <mcgrathr@google.com>
+
+ Fix ld test case that assumes --enable-textrel-check
+ ld/
+ * testsuite/ld-x86-64/x86-64.exp (Build textrel-1): Use --warn-textrel.
+
+2021-07-27 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-27 H.J. Lu <hjl.tools@gmail.com>
+
+ bfd: Set error to bfd_error_malformed_archive only if unset
+ When reading an archive member, set error to bfd_error_malformed_archive
+ on open_nested_file failure only if the error is unset.
+
+ PR ld/28138
+ * archive.c (_bfd_get_elt_at_filepos): Don't set error to
+ bfd_error_malformed_archive if it has been set.
+
+2021-07-26 Carl Love <cel@us.ibm.com>
+
+ Fix for mi-reverse.exp
+ This test fails on PPC64 because PPC64 prints the value of 3.5 with
+ more significant digits than on Intel. The patch updates the regular
+ expression to allow for more significant digits on the constant.
+
+ gdb/testsuite/ChangeLog
+
+ * gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check
+ for additional digits.
+
+2021-07-26 Tom Tromey <tromey@adacore.com>
+
+ Fix the Windows build
+ The gdb build was broken on Windows after the patch to change
+ get_inferior_cwd. This patch fixes the build.
+
+2021-07-26 Shahab Vahedi <shahab@synopsys.com>
+
+ gdb: Fix numerical field extraction for target description "flags"
+ The "val_print_type_code_flags ()" function is responsible for
+ extraction of fields for "flags" data type. These data types are
+ used when describing a custom register type in a target description
+ XML. The logic used for the extraction though is not sound:
+
+ unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
+ ULONGEST field_val
+ = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
+
+ TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
+ TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
+ val: The register value.
+
+ Imagine you have a field that starts at position 1 and its length
+ is 4 bits. According to the third line of the code snippet the
+ shifting right would become "val >> -2", or "val >> 0xfff...fe"
+ to be precise. That will result in a "field_val" of 0.
+
+ The correct extraction should be:
+
+ ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
+
+ The rest of the algorithm that masks out the higher bits is OK.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [10/10] arm: Alias 'ra_auth_code' to r12 for pacbti.
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (reg_names): Alias 'ra_auth_code' to r12.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [9/10] arm: add 'pacg' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (T16_32_TAB): Add '_pacg'.
+ (do_t_pacbti_pacg): New function.
+ (insns): Define 'pacg' insn.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacg' test.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'pacg'.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [8/10] arm: add 'autg' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (T16_32_TAB): Add '_autg'.
+ (insns): Define 'autg' insn.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Add autg test.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'autg'.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [7/10] arm: add 'bxaut' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (T16_32_TAB): Add '_bxaut'.
+ (do_t_pacbti_nonop): New function.
+ (insns): Define 'bxaut' insn.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'bxaut' test.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'bxaut'.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [6/10] arm: Add -march=armv8.1-m.main+pacbti flag
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (pacbti_ext): Define.
+ (BAD_PACBTI): New macro.
+ (armv8_1m_main_ext_table): Add 'pacbti' extension.
+
+ include/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * opcode/arm.h (ARM_EXT3_PACBTI, ARM_AEXT3_V8_1M_MAIN_PACBTI): New
+ macro.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [5/10] arm: Extend again arm_feature_set struct to provide more bits
+ include/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * opcode/arm.h (arm_feature_set): Extend 'core' field.
+ (ARM_CPU_HAS_FEATURE, ARM_FSET_CPU_SUBSET, ARM_CPU_IS_ANY)
+ (ARM_MERGE_FEATURE_SETS, ARM_CLEAR_FEATURE, ARM_FEATURE_EQUAL)
+ (ARM_FEATURE_ZERO, ARM_FEATURE_CORE_EQUAL): Account for
+ 'core[2]'.
+ (ARM_FEATURE_CORE_HIGH_HIGH): New macro.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [4/10] arm: add 'pac' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (T16_32_TAB): Add '_pac'.
+ (insns): Add 'pac' insn.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add pac tests.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'pac'.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [3/10] arm: add 'aut' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (insns): Add 'aut.'
+ (T16_32_TAB): Add '_aut'.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add 'aut' tests.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'aut'.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [2/10] arm: add 'pacbti' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c
+ (enum operand_parse_code): Add OP_SP and OP_R12.
+ (parse_operands): Add switch cases for OP_SP and OP_R12.
+ (T16_32_TAB): Add '_pacbti'.
+ (do_t_pacbti): New function.
+ (insns): Add 'pacbti'.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.d: New file.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacbti' to testcase.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add 'pacbti' instruction.
+
+2021-07-26 Andrea Corallo <andrea.corallo@arm.com>
+
+ PATCH [1/10] arm: add 'bti' instruction for Armv8.1-M pacbti extension
+ gas/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * config/tc-arm.c (insns): Add 'bti' insn.
+ * testsuite/gas/arm/armv8_1-m-pacbti.d: New file.
+ * testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+ opcodes/
+ 2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
+
+ * arm-dis.c (thumb32_opcodes): Add bti instruction.
+
+2021-07-26 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb: move remaining ChangeLogs to legacy files
+ In commit:
+
+ commit f069ea46a03ae868581d1c852da28e979ea1245a
+ Date: Sat Jul 3 16:29:08 2021 -0700
+
+ Rename gdb/ChangeLog to gdb/ChangeLog-2021
+
+ The gdb/ChangeLog file was renamed, but all of the other ChangeLog
+ files relating to gdb were left in place.
+
+ As I understand things, the no ChangeLogs policy applies to all the
+ GDB related directories, so this commit renames all of the remaining
+ GDB related ChangeLog files.
+
+ As with the original commit, the intention behind this commit is to
+ hopefully stop people merging ChangeLog entries by mistake.
+
+ The renames carried out in this commit are:
+
+ gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
+ gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
+ gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
+ gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
+ gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021
+
+2021-07-26 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ gdb/mi: handle no condition argument case for -break-condition
+ As reported in PR gdb/28076 [1], passing no condition argument to the
+ -break-condition command (e.g.: "-break-condition 2") should clear the
+ condition for breakpoint 2, just like CLI's "condition 2", but instead
+ an error message is returned:
+
+ ^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
+
+ The current implementation of the -break-condition command's argument
+ handling (79aabb7308c "gdb/mi: add a '--force' flag to the
+ '-break-condition' command") was done according to the documentation,
+ where the condition argument seemed mandatory. However, the
+ -break-condition command originally (i.e. before the 79aabb7308c
+ patch) used the CLI's "cond" command, and back then not passing a
+ condition argument was clearing out the condition. So, this is a
+ regression in terms of the behavior.
+
+ Fix the argument handling of the -break-condition command to allow not
+ having a condition argument, and also update the document to make the
+ behavior clear. Also add test cases to test the scenarios which were
+ previously not covered.
+
+ [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
+
+2021-07-26 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-25 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-24 Alan Modra <amodra@gmail.com>
+
+ Revert: PowerPC: Don't generate unused section symbols
+ Blindly following x86 broke linux kernel builds.
+
+ bfd/
+ * elf32-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define as true.
+ * elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Likewise.
+ gas/
+ * testsuite/gas/ppc/power4.d: Adjust for section sym change.
+ * testsuite/gas/ppc/test1elf32.d: Likewise.
+ * testsuite/gas/ppc/test1elf64.d: Likewise.
+ ld/
+ * testsuite/ld-powerpc/tlsexe.r: Adjust for section sym change.
+ * testsuite/ld-powerpc/tlsexe32.r: Likewise.
+ * testsuite/ld-powerpc/tlsexe32no.r: Likewise.
+ * testsuite/ld-powerpc/tlsexeno.r: Likewise.
+ * testsuite/ld-powerpc/tlsexenors.r: Likewise.
+ * testsuite/ld-powerpc/tlsexers.r: Likewise.
+ * testsuite/ld-powerpc/tlsexetoc.r: Likewise.
+ * testsuite/ld-powerpc/tlsexetocrs.r: Likewise.
+ * testsuite/ld-powerpc/tlsget.d: Likewise.
+ * testsuite/ld-powerpc/tlsget.wf: Likewise.
+ * testsuite/ld-powerpc/tlsget2.d: Likewise.
+ * testsuite/ld-powerpc/tlsget2.wf: Likewise.
+ * testsuite/ld-powerpc/tlsso.r: Likewise.
+ * testsuite/ld-powerpc/tlsso32.r: Likewise.
+ * testsuite/ld-powerpc/tlstocso.r: Likewise.
+
+2021-07-24 Alan Modra <amodra@gmail.com>
+
+ Re: ld script expression parsing
+ Commit 40726f16a8d7 broke references to sections within ADDR(), and
+ overlays with weird section names.
+
+ * ldgram.y (paren_script_name): New rule.
+ (exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR. Similarly
+ ensure script mode parsing for section name in SEGMENT_START.
+ (overlay_section): Delete unnecessary ldlex_script call. Backup
+ on a lookahead NAME parsed in expression mode.
+ * testsuite/ld-elf/overlay.s: Add more sections.
+ * testsuite/ld-elf/overlay.t: Test '-' in section names.
+
+2021-07-24 Frederic Cambus <fred@statdns.com>
+
+ Update the NetBSD system call table to match NetBSD-current.
+ Generated from sys/sys/syscall.h revision 1.319.
+
+ We can safely remove the _lwp_gettid syscall, which was never exposed
+ in libc and never made it into a release.
+
+ gdb/ChangeLog:
+
+ 2021-07-23 Frederic Cambus <fred@statdns.com>
+
+ * syscalls/netbsd.xml: Regenerate.
+
+2021-07-24 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: test get/set value of unregistered Guile parameter
+ When creating a parameter in Guile, you have to create it using
+ make-parameter and then register it with GDB with register-parameter!.
+ In between, it's still possible (though not documented) to set the
+ parameter's value. I broke this use case by mistake while writing this
+ series, so thought it would be good to have a test for it.
+
+ I suppose that people could use this "feature" to give their parameter
+ an initial value, even though make-parameter has an initial-value
+ parameter for this. Nevertheless, changing this behavior could break
+ some scripts, which is why I think it's important for it to be tested.
+
+ Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove cmd_list_element::function::sfunc
+ I don't understand what the sfunc function type in
+ cmd_list_element::function is for. Compared to cmd_simple_func_ftype,
+ it has an extra cmd_list_element parameter, giving the callback access
+ to the cmd_list_element for the command being invoked. This allows
+ registering the same callback with many commands, and alter the behavior
+ using the cmd_list_element's context.
+
+ From the comment in cmd_list_element, it sounds like at some point it
+ was the callback function type for set and show functions, hence the
+ "s". But nowadays, it's used for many more commands that need to access
+ the cmd_list_element object (see add_catch_command for example).
+
+ I don't really see the point of having sfunc at all, since do_sfunc is
+ just a trivial shim that changes the order of the arguments. All
+ commands using sfunc could just as well set cmd_list_element::func to
+ their callback directly.
+
+ Therefore, remove the sfunc field in cmd_list_element and everything
+ that goes with it. Rename cmd_const_sfunc_ftype to cmd_func_ftype and
+ use it for cmd_list_element::func, as well as for the add_setshow
+ commands.
+
+ Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: rename cfunc to simple_func
+ After browsing the CLI code for quite a while and trying really hard, I
+ reached the conclusion that I can't give a meaningful explanation of
+ what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't
+ see a logic at all. That makes it very difficult to do any kind of
+ change. Unless somebody can make sense out of all that, I'd like to try
+ to retro-fit some logic in the cmd_list_element callback function code
+ so that we can understand what is going on, do some cleanups and add new
+ features.
+
+ The first change is about "cfunc". I can't figure out what the "c" in
+ cfunc means. It's not const, because there's already "const" in
+ "cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
+ const.. It's not "cmd" or "command", because there's already "cmd" in
+ "cmd_const_cfunc_ftype".
+
+ The "main" command callback, cmd_list_element::func, has three
+ parameters, whereas cfunc has two. It is missing the cmd_list_element
+ parameter. So the only reason I see for cfunc to exist is to be a shim
+ between the three and two parameter versions. Most commands don't need
+ to receive the cmd_list_element object, so adding it everywhere would be
+ long and would just add more unnecessary boilerplate. So since this is
+ the "simple" version of the callback, compared to the "full", I suggest
+ renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
+ everything (like the utility functions) that goes with it.
+
+ Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make inferior::m_terminal an std::string
+ Same idea as the previous patch, but for m_terminal.
+
+ Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make inferior::m_cwd an std::string
+ Same idea as the previous patch, but for m_cwd.
+
+ To keep things consistent across the board, change get_inferior_cwd as
+ well, which is shared with GDBserver. So update the related GDBserver
+ code too.
+
+ Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make inferior::m_args an std::string
+ With the current code, both a NULL pointer and an empty string can mean
+ "no arguments". We don't need this distinction. Changing to a string
+ has the advantage that there is now a single state for that (an empty
+ string), which makes the code a bit simpler in my opinion.
+
+ Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add setter/getter for inferior cwd
+ Add cwd/set_cwd to the inferior class, remove set_inferior_args.
+ Keep get_inferior_args, because it is used from fork_inferior, in shared
+ code. The cwd could eventually be passed as a parameter eventually,
+ though, I think that would be cleaner.
+
+ Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add setter/getter for inferior arguments
+ Add args/set_args to the inferior class, remove the set_inferior_args
+ and get_inferior_args functions, that would just be wrappers around
+ them.
+
+ Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: remove inferior::{argc,argv}
+ There are currently two states that the inferior args can be stored.
+ The main one is the `args` field, where they are stored as a single
+ string. The other one is the `argc`/`argv` fields.
+
+ This last one is only used for arguments passed in GDB's
+ command line. And the only outcome is that when get_inferior_args is
+ called, `argc`/`argv` are serialized into `args`. So really,
+ `argc`/`argv` is just a staging area before moving the arguments in
+ `args`.
+
+ Simplify this by only keeping the `args` field. Change
+ set_inferior_args_vector to immediately serialize the arguments into
+ `args`, work that would be done in get_inferior_args later anyway.
+
+ The only time where this work would be "wasted" is when the user passes
+ some arguments on the command line, but does not end up running the
+ program. But that just seems unlikely. And it's not that much work.
+
+ Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: un-share set_inferior_cwd declaration
+ The declaration of set_inferior_cwd is currently shared between gdb and
+ gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as
+ set_inferior_cwd is not called from common code. Only get_inferior_cwd
+ needs to.
+
+ The motivation for this is that a future patch will change the prototype
+ of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
+ unnecessarily. I see this as a good cleanup in any case, to reduce to
+ just the essential what is shared between GDB and GDBserver.
+
+ Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb.base/setshow.exp: fix duplicate test name
+ Fix:
+
+ DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args
+
+ by giving some explicit test names.
+
+ Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb.base/setshow.exp: split in procs
+ Split in multiple procs, one per topic, and start with a fresh GDB in
+ each. I find it easier to work on a test with multiple smaller
+ independent test procedures. For example, it's possible to comment all
+ but one when working on one. It's also easier to add things without
+ having to think about the impact on existing tests, and vice-versa.
+
+ Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb.base/setshow.exp: use save_vars to save/restore gdb_prompt
+ Using save_vars is a bit better than what we have now, as it ensures the
+ variable gets restored if the code within it throws an error.
+
+ Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27
+
+2021-07-23 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: split gdb.python/py-parameter.exp in procs
+ Split the file into multiple independent test procs, where each proc
+ starts with a fresh GDB. I find it easier to understand what a test is
+ doing when each part of the test is isolated and self-contained. It
+ makes it easier to comment out some parts of the test while working /
+ debugging a specific part. It also makes it easier to add new things
+ (which a subsequent patch will do) without fear of impacting another part
+ of the test.
+
+ Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d
+
+2021-07-23 Carl Love <cel@us.ibm.com>
+
+ Fix for gdb.python/py-breakpoint.exp
+ Not all systems have hardware breakpoint support. Add a check
+ to see if the system supports hardware breakpoints.
+
+ gdb/testsuite/ChangeLog
+
+ * gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add
+ check for hardware breakpoint support.
+
+2021-07-23 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ gdb/testsuite: don't error when trying to unset last_spawn_tty_name
+ In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
+ last_spawn_tty_name depending on whether spawn_out(slave,name) exists
+ or not.
+
+ One situation that might cause spawn_out(slave,name) to not exists is
+ if the spawn function is called with the argument -leaveopen, which is
+ how it is called when processes are created as part of a pipeline, the
+ created process has no tty, instead its output is written to a file
+ descriptor.
+
+ If a pipeline is created consisting of multiple processes then there
+ will be multiple sequential calls to spawn, all using -leaveopen. The
+ first of these calls is fine, spawn_out(slave,name) is not set, and so
+ in spawn_capture_tty_name we unset last_spawn_tty_name. However, on
+ the second call to spawn, spawn_out(slave,name) is still not set and
+ so in spawn_capture_tty_name we again try to unset
+ last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
+ is already unset).
+
+ Fix this issue by using -nocomplain with the call to unset in
+ spawn_capture_tty_name.
+
+ Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
+ pass, and 1 unsupported test. After this commit I now see 16 passes
+ from this test script.
+
+ I have also improved the code that used to do this:
+
+ if { [info exists spawn_out] } {
+ set ::last_spawn_tty_name $spawn_out(slave,name)
+ } else {
+ ...
+ }
+
+ The problem here is that we check for the existence of spawn_out, and
+ then unconditionally read spawn_out(slave,name). A situation could
+ arise where some other element of spawn_out is set,
+ e.g. spawn_out(foo), in which case we would enter the if block and try
+ to read a non-existent variable. After this commit we now check
+ specifically for spawn_out(slave,name).
+
+ Finally, it is worth noting that before this issue was fixed runtest
+ itself, or rather the expect process behind runtest, would segfault
+ while exiting. I haven't looked at all into what the problem is here
+ that caused expect to crash, as fixing the bug in GDB's testing
+ scripts made the segfault go away.
+
+2021-07-23 Jan Beulich <jbeulich@suse.com>
+
+ x86: express unduly set rounding control bits in disassembly
+ While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE,
+ EVEX.b itself is not ignored when an insn permits neither rounding
+ control nor SAE.
+
+ While changing this aspect of EVEX.b handling, also alter unduly set
+ embedded broadcast: Don't call BadOp(), screwing up subsequent
+ disassembly, but emit "{bad}" instead.
+
+2021-07-23 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-22 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAILs due to PR gcc/101575
+ When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
+ unix/gdb:debug_flags=-gdwarf-4 we run into:
+ ...
+ (gdb) print/x s^M
+ No definition of "s" in current context.^M
+ (gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
+ ...
+ which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
+ ...
+ (gdb) break defs.adb:20^M
+ Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
+ (gdb) run ^M
+ Starting program: formatted_ref ^M
+ ^M
+ Breakpoint 1, defs__struct1IP () at defs.adb:20^M
+ 20 return s.x; -- Set breakpoint marker here.^M
+ (gdb) print s1'access^M
+ ...
+ instead of the expected defs.f1:
+ ...
+ (gdb) break defs.adb:20^M
+ Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
+ (gdb) run ^M
+ Starting program: formatted_ref ^M
+ ^M
+ Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
+ 20 return s.x; -- Set breakpoint marker here.^M
+ ...
+
+ This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
+ -gdwarf-4] Missing .file <n> directive causes invalid line info".
+
+ Fix this by when landing in defs__struct1IP:
+ - xfailing the runto, and
+ - issuing a continue to land in defs.f1.
+
+ Likewise in a few other test-cases.
+
+ Tested on x86_64-linux, with:
+ - system gcc.
+ - gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
+ unix/gdb:debug_flags=-gdwarf-5.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-22 Tom de Vries <tdevries@suse.de>
+
+ * gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
+ * gdb.ada/iwide.exp: Same.
+ * gdb.ada/pkd_arr_elem.exp: Same.
+
+2021-07-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop dq{b,d}_mode
+ Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for
+ consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly
+ reflecting REX.W / VEX.W is not in line with the assembler's opcode
+ table having NoRex64 / VexWIG in all respective templates, i.e. assembly
+ input isn't being honored there either. Obviously the 0FC5 encodings of
+ {,V}PEXTRW then also need adjustment for consistency reasons.
+
+ x86: drop vex_scalar_w_dq_mode
+ It has only a single use and can easily be represented by dq_mode
+ instead. Plus its handling in intel_operand_size() was duplicating
+ that of vex_vsib_{d,q}_w_dq_mode anyway.
+
+ x86: drop xmm_m{b,w,d,q}_mode
+ They're effectively redundant with {b,w,d,q}_mode.
+
+ x86: fold duplicate vector register printing code
+ The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the
+ shared logic out of the function, and invoke the new helper from both
+ places.
+
+ x86: drop vex_mode and vex_scalar_mode
+ These are fully redundant with, respectively, x_mode and scalar_mode.
+
+ x86: correct EVEX.V' handling outside of 64-bit mode
+ Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored
+ outside of 64-bit mode. Oddly enough there already are tests for these
+ cases, but their expectations were wrong. (This may have been based on
+ an old SDM version, where the restriction wasn't properly spelled out.)
+
+ x86: fold duplicate code in MOVSXD_Fixup()
+ There's no need to have two paths printing the "xd" mnemonic suffix.
+
+ x86: fold duplicate register printing code
+ What so far was OP_E_register() can be easily reused also for OP_G().
+ Add suitable parameters to the function and move the invocation of
+ swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was
+ a need to use movsxd_mode there, and its use gets in the way of the code
+ folding.
+
+ x86-64: properly bounds-check %bnd<N> in OP_G()
+ The restriction to %bnd0-%bnd3 requires to also check REX.R is clear,
+ just like OP_E_Register() also includes REX.B in its check.
+
+ x86-64: generalize OP_G()'s EVEX.R' handling
+ EVEX.R' is invalid to be clear not only for mask registers, but also for
+ GPRs - IOW everything handled in this function.
+
+2021-07-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: correct VCVT{,U}SI2SD rounding mode handling
+ With EVEX.W clear the instruction doesn't ignore the rounding mode, but
+ (like for other insns without rounding semantics) EVEX.b set causes #UD.
+ Hence the handling of EVEX.W needs to be done when processing
+ evex_rounding_64_mode, not at the decode stages.
+
+ Derive a new 64-bit testcase from the 32-bit one to cover the different
+ EVEX.W treatment in both cases.
+
+2021-07-22 Jan Beulich <jbeulich@suse.com>
+
+ x86: drop OP_Mask()
+ By moving its vex.r check there it becomes fully redundant with OP_G().
+
+2021-07-22 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11
+ When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
+ into:
+ ...
+ KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
+ (PRMS symtab/25507)
+ FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
+ KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
+ (PRMS symtab/25507)
+ ...
+
+ [ Note that I get the same result with gcc-11 and target board
+ unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]
+
+ With gcc-10, I have this trace:
+ ...
+ 64 get_alias_set (&xx);
+ get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
+ 51 if (t != NULL
+ 40 if (t->x != i)
+ 52 && TREE_TYPE (t).z != 1
+ 43 return x;
+ 53 && TREE_TYPE (t).z != 2
+ 43 return x;
+ 54 && TREE_TYPE (t).z != 3)
+ 43 return x;
+ main () at step-and-next-inline.cc:65
+ 65 return 0;
+ ...
+ and with gcc-11, I have instead:
+ ...
+ 64 get_alias_set (&xx);
+ get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
+ 51 if (t != NULL
+ 52 && TREE_TYPE (t).z != 1
+ 43 return x;
+ 53 && TREE_TYPE (t).z != 2
+ 43 return x;
+ 54 && TREE_TYPE (t).z != 3)
+ 43 return x;
+ main () at step-and-next-inline.cc:65
+ 65 return 0;
+ ...
+ and with clang-10, I have instead:
+ ...
+ 64 get_alias_set (&xx);
+ get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
+ 51 if (t != NULL
+ 52 && TREE_TYPE (t).z != 1
+ 53 && TREE_TYPE (t).z != 2
+ 54 && TREE_TYPE (t).z != 3)
+ 51 if (t != NULL
+ 57 }
+ main () at step-and-next-inline.cc:65
+ 65 return 0;
+ ...
+
+ The test-case tries to verify that we don't step into inlined function
+ tree_check (lines 40-43) (so, with the clang trace we get that right).
+
+ The test-case then tries to kfail the problems when using gcc, but this is
+ done in such a way that the testing still gets out of sync after a failure.
+ That is: the "next step 2" check that is supposed to match
+ "TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
+ ...
+ (gdb) next^M
+ 52 && TREE_TYPE (t).z != 1^M
+ (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
+ ...
+
+ Fix this by issuing extra nexts to arrive at the required lines.
+
+ Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
+ and clang-12.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-20 Tom de Vries <tdevries@suse.de>
+
+ * gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
+ Tag closing brace with comment.
+ * gdb.cp/step-and-next-inline.h: Update to keep identical with
+ step-and-next-inline.cc.
+ * gdb.cp/step-and-next-inline.exp: Issue extra next when required.
+
+2021-07-21 Nick Clifton <nickc@redhat.com>
+
+ Updated Russian translation for the bfd library
+
+2021-07-21 Luca Boccassi <luca.boccassi@microsoft.com>
+
+ Allows linker scripts to set the SEC_READONLY flag.
+ * ld.texi: Document new output section type.
+ * ldgram.y: Add new token.
+ * ldlang.c: Handle the new flag.
+ * ldlang.h: Add readonly_section to list of section types.
+ * ldlex.l: Add a new identifier.
+ * testsuite/ld-scripts/output-section-types.t: New example linker script.
+ * testsuite/ld-scripts/output-section-types.d: Test driver.
+ * testsyute/ld-scripts/script.exp: Run the new test.
+
+2021-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix FAILs due to PR gcc/101452
+ When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
+ default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
+ into this regression:
+ ...
+ (gdb) ptype/o static_member^M
+ /* offset | size */ type = struct static_member {^M
+ - static static_member Empty;^M
+ /* 0 | 4 */ int abc;^M
+ ^M
+ /* total size (bytes): 4 */^M
+ }^M
+ -(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+ +(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
+ ...
+
+ This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
+ dwarf-5] undefined static member removed by
+ -feliminate-unused-debug-symbols".
+
+ It's not clear yet whether this is a bug or a feature, but work around this in
+ the test-cases by:
+ - defining the static member
+ - adding additional_flags=-fno-eliminate-unused-debug-types.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-20 Tom de Vries <tdevries@suse.de>
+
+ * lib/gdb.exp (gcc_major_version): New proc.
+ * gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
+ * gdb.cp/templates.exp: Define static member using -DGCC_BUG.
+ * gdb.cp/m-static.exp: Add
+ additional_flags=-fno-eliminate-unused-debug-types.
+ * gdb.cp/pr-574.exp: Same.
+ * gdb.cp/pr9167.exp: Same.
+
+2021-07-21 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11
+ With gcc-11 we run into:
+ ...
+ (gdb) print pa_ptr.all^M
+ That operation is not available on integers of more than 8 bytes.^M
+ (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
+ ...
+
+ This is due to PR exp/20991 - "__int128 type support". Mark this and similar
+ FAILs as KFAIL.
+
+ Also mark this FAIL:
+ ....
+ (gdb) print pa_ptr(3)^M
+ cannot subscript or call something of type `foo__packed_array_ptr'^M
+ (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
+ ...
+ as a KFAIL for PR ada/28115 - "Support packed array encoded as
+ DW_TAG_subrange_type".
+
+ Tested on x86_64-linux, with gcc-10 and gcc-11.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-21 Tom de Vries <tdevries@suse.de>
+
+ * gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
+ * gdb.ada/exprs.exp: Add KFAILs for PR20991.
+ * gdb.ada/packed_array_assign.exp: Same.
+
+2021-07-21 Alan Modra <amodra@gmail.com>
+
+ as_bad_subtract
+ Many places report errors of the nature "can't resolve a - b".
+ This provides a utility function to report such errors consistently.
+ I removed the section reporting and quotes around symbol names while I
+ was at it. Compare
+ ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section}
+ with
+ ifunc-2.s:4: Error: can't resolve bar1 - foo1
+
+ In many cases the section names don't help the user very much in
+ figuring out what went wrong, and the quotes if present arguably ought
+ to be placed around the entire expression:
+ can't resolve `bar1 - foo1'
+
+ The patch also tidies some tc_get_reloc functions that leak memory on
+ error paths.
+
+ * write.h (as_bad_subtract): Declare.
+ * write.c (as_bad_subtract): New function.
+ (fixup_segment): Use as_bad_subtract.
+ * config/tc-arc.c (md_apply_fix): Likewise.
+ * config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise.
+ * config/tc-cris.c (md_apply_fix): Likewise.
+ * config/tc-d10v.c (md_apply_fix): Likewise.
+ * config/tc-d30v.c (md_apply_fix): Likewise.
+ * config/tc-ft32.c (md_apply_fix): Likewise.
+ * config/tc-h8300.c (tc_gen_reloc): Likewise.
+ * config/tc-m68hc11.c (md_apply_fix): Likewise.
+ * config/tc-mmix.c (mmix_frob_file): Likewise.
+ * config/tc-mn10200.c (tc_gen_reloc): Likewise.
+ * config/tc-nds32.c (nds32_apply_fix): Likewise.
+ * config/tc-pru.c (md_apply_fix): Likewise.
+ * config/tc-riscv.c (md_apply_fix): Likewise.
+ * config/tc-s12z.c (md_apply_fix): Likewise.
+ * config/tc-s390.c (md_apply_fix): Likewise.
+ * config/tc-tilegx.c (md_apply_fix): Likewise.
+ * config/tc-tilepro.c (md_apply_fix): Likewise.
+ * config/tc-v850.c (md_apply_fix): Likewise.
+ * config/tc-vax.c (md_apply_fix): Likewise.
+ * config/tc-xc16x.c (tc_gen_reloc): Likewise.
+ * config/tc-xgate.c (md_apply_fix): Likewise.
+ * config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise.
+ * config/tc-xtensa.c (md_apply_fix): Likewise.
+ * config/tc-z80.c (tc_gen_reloc): Likewise.
+ * config/tc-spu.c (md_apply_fix): Likewise.
+ (tc_gen_reloc): Delete dead code. Free memory on error.
+ * config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract. Free
+ on error.
+ * config/tc-crx.c (tc_gen_reloc): Likewise.
+ * config/tc-ppc.c (tc_gen_reloc): Likewise.
+ * testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message.
+ * testsuite/gas/mips/lui-2.l: Likewise.
+ * testsuite/gas/tic6x/reloc-bad-1.l: Likewise.
+
+2021-07-21 John Ericson <git@JohnEricson.me>
+
+ Remove `netbsdpe` support
+ netbsdpe was deprecated in c2ce831330e10dab4703094491f80b6b9a5c2289.
+ Since then, a release has passed (2.37), and it was marked obselete in
+ 5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that
+ means we can now remove support altogether.
+
+ All branches in the "active" code are remove, and the target is
+ additionally marked as obsolete next to the other removed ones for
+ libbfd and gdb.
+
+ Per [1] from the NetBSD toolchain list, PE/COFF support was removed a
+ decade ago. Furthermore, the sole mention of this target in the binutils
+ commit history was in 2002. Together, I'm led to believe this target
+ hasn't seen much attention in quite a while.
+
+ [1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html
+
+ bfd/
+ * config.bfd: Remove netbsdpe entry.
+ binutils/
+ * configure.ac: Remove netbsdpe entry.
+ * testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise.
+ * configure: Regenerate.
+ gas/
+ * configure.tgt: Remove netbsdpe entry.
+ gdb/
+ * configure.tgt: Add netbsdpe to removed targets.
+ ld/
+ * configure.tgt: Remove netbsdpe entry.
+ * testsuite/ld-bootstrap/bootstrap.exp: Likewise.
+
+2021-07-21 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-20 Alan Modra <amodra@gmail.com>
+
+ PR28106, build of 2.37 fails on FreeBSD and Clang
+ https://en.cppreference.com/w/cpp/types/NULL says NULL might be
+ defined as nullptr.
+ https://en.cppreference.com/w/cpp/language/reinterpret_cast says
+ reinterpret_cast can't be used on nullptr.
+
+ PR gold/28106
+ PR gold/27815
+ * gc.h (gc_process_relocs): Use static_cast in Section_id constructor.
+
+2021-07-20 Luis Machado <luis.machado@linaro.org>
+
+ Fix printing of non-address types when memory tagging is enabled
+ When the architecture supports memory tagging, we handle
+ pointer/reference types in a special way, so we can validate tags and
+ show mismatches.
+
+ Unfortunately, the currently implementation errors out when the user
+ prints non-address values: composite types, floats, references, member
+ functions and other things.
+
+ Vector registers:
+
+ (gdb) p $v0
+ Value can't be converted to integer.
+
+ Non-existent internal variables:
+
+ (gdb) p $foo
+ Value can't be converted to integer.
+
+ The same happens for complex types and printing struct/union types.
+
+ There are a few problems here.
+
+ The first one is that after print_command_1 evaluates the expression
+ to print, the tag validation code call value_as_address
+ unconditionally, without making sure we have have a suitable type
+ where it makes to sense to call it. That results in value_as_address
+ (if it isn't given a pointer-like type) trying to treat the value as
+ an integer and convert it to an address, which #1 - doesn't make sense
+ (i.e., no sense in validating tags after "print 1"), and throws for
+ non-integer-convertible types. We fix this by making sure we have a
+ pointer or reference type first, and only if so then proceed to check
+ if the address-like value has tags.
+
+ The second is that we're calling value_as_address even if we have an
+ optimized out or unavailable value, which throws, because the value's
+ contents aren't fully accessible/readable. This error currently
+ escapes out and aborts the print. This case is fixed by checking for
+ optimized out / unavailable explicitly.
+
+ Third, the tag checking process does not gracefully handle exceptions.
+ If any exception is thrown from the tag validation code, we abort the
+ print. E.g., the target may fail to access tags via a running thread.
+ Or the needed /proc files aren't available. Or some other untold
+ reason. This is a bit too rigid. This commit changes print_command_1
+ to catch errors, print them, and still continue with the normal
+ expression printing path instead of erroring out and printing nothing
+ useful.
+
+ With this patch, printing works correctly again:
+
+ (gdb) p $v0
+ $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
+ 3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
+ 791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
+ 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
+ 0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
+ 12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
+ 62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
+ (gdb) p $foo
+ $2 = void
+ (gdb) p 2 + 2i
+ $3 = 2 + 2i
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110
+
+2021-07-20 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Minor updates for architecture parser.
+ * Two add subset functions is redundant. Keep the riscv_add_implicit_subset,
+ and renamed it to riscv_add_subset. Besides, if the subset is added in order,
+ then we just add it at the tail of the subset list.
+
+ * Removed the "-march:" prefix from the error messages. Since not only the
+ -march= option will use the parser, but also the architecture elf attributes,
+ the default architecture setting and linker will use the same parser.
+
+ * Use a function, riscv_parse_check_conflicts, to check the conflicts
+ of extensions, including the rv64e and rv32q.
+
+ The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions
+ are tested and passed.
+
+ bfd/
+ * elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list
+ first. If the subset is added in order, then we can just add it to
+ the tail without searching the whole list.
+ (riscv_add_subset): Replaced by riscv_add_implicit_subset.
+ (riscv_add_implicit_subset): Renamed to riscv_add_subset.
+ (riscv_parse_add_subset): Updated.
+ (riscv_parsing_subset_version): Removed the "-march:" prefix from
+ the error message.
+ (riscv_parse_prefixed_ext): Likewise.
+ (riscv_parse_std_ext): Likewise. And move the rv<xlen>e check
+ to riscv_parse_check_conflicts.
+ (riscv_parse_check_conflicts): New function used to check conflicts.
+ (riscv_parse_subset): Updated.
+ gas/
+ * testsuite/gas/riscv/march-fail-base-02.l: Updated.
+ * testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
+
+2021-07-20 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-19 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: set current thread in btrace_compute_ftrace_{bts,pt}
+ As documented in bug 28086, test gdb.btrace/enable-new-thread.exp
+ started failing with commit 0618ae414979 ("gdb: optimize
+ all_matching_threads_iterator"):
+
+ (gdb) record btrace^M
+ (gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace
+ break 24^M
+ Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M
+ (gdb) continue^M
+ Continuing.^M
+ /home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M
+ A problem internal to GDB has been detected,^M
+ further debugging may prove unreliable.^M
+ Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error)
+
+ Note that I only see the failure if GDB is compiled without libipt
+ support. This is because GDB then makes use BTS instead of PT, so
+ exercises different code paths.
+
+ I think that the commit above just exposed an existing problem. The
+ stack trace of the internal error is:
+
+ #8 0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
+ #9 0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303
+ #10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317
+ #11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487
+ #12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125
+ #13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42
+ #14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243
+ #15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411
+ #16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437
+ #17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504
+ #18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635
+ #19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664
+ #20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721
+ #21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974
+ #22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014
+ #23 0x0000561cb7ef809f in target_read_code (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869
+ #24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139
+ #25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194
+ #26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628
+ #27 0x0000561cb80adbd8 in print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587
+ #28 0x0000561cb80abe4f in print_insn_i386 (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894
+ #29 0x0000561cb7744a19 in default_print_insn (memaddr=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029
+ #30 0x0000561cb7b33067 in i386_print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013
+ #31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478
+ #32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795
+ #33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850
+ #34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859
+ #35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107
+ #36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527
+ #37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560
+ #38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589
+ #39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629
+ #40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294
+ #41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60
+ #42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153
+ #43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291
+ #44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622
+ #45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
+ #46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263
+ #47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272
+ #48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380
+ #49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429
+ #50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447
+ #51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981
+ #52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920
+ #53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202
+ #54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440
+ #55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412
+ #56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547
+ #57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608
+ #58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640
+ #59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701
+ #60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720
+ #61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069
+ #62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41
+ #63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227
+ #64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575
+ #65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701
+ #66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212
+ #67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421
+ #68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481
+ #69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353
+ #70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368
+ #71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
+
+ At frame 45, the new_thread observable is fired. At this moment, the
+ new thread isn't the current thread, inferior_ptid is null_ptid. I
+ think this is ok: the new_thread observable doesn't give any guarantee
+ on the global context when observers are invoked. Frame 35,
+ btrace_compute_ftrace_bts, calls gdb_insn_length. gdb_insn_length
+ doesn't have a thread_info or other parameter what could indicate where
+ to read memory from, it implicitly uses the global context
+ (inferior_ptid).
+
+ So we reach the all_non_exited_threads_range in
+ record_btrace_target::record_is_replaying with a null inferior_ptid.
+ The previous implemention of all_non_exited_threads_range didn't care,
+ but the new one does. The problem of calling gdb_insn_length and
+ ultimately trying to read memory with a null inferior_ptid already
+ existed, but the commit mentioned above made it visible.
+
+ Something between frames 40 (record_btrace_enable_warn) and 35
+ (btrace_compute_ftrace_bts) needs to be switching the global context to
+ make TP the current thread. Since btrace_compute_ftrace_bts takes the
+ thread_info to work with as a parameter, that typically means that it
+ doesn't require its caller to also set the global current context
+ (current thread) when calling. If it needs to call other functions
+ that do require the global current thread to be set, then it needs to
+ temporarily change the current thread while calling these other
+ functions. Therefore, switch and restore the current thread in
+ btrace_compute_ftrace_bts.
+
+ By inspection, it looks like btrace_compute_ftrace_pt may also call
+ functions sensitive to the global context: it installs the
+ btrace_pt_readmem_callback callback in the PT instruction decoder. When
+ this function gets called, inferior_ptid must be set appropriately. Add
+ a switch and restore in there too.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28086
+ Change-Id: I407fbfe41aab990068bd102491aa3709b0a034b3
+
+2021-07-19 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-18 Nick Clifton <nickc@redhat.com>
+
+ Move pending-obsolesence targets onto the obsolete list.
+ * config.bfd: Move pending obsoletion targets to obsolete list.
+
+ Update how-to-make-a-release checklist with latest changes from 2.37 release
+
+2021-07-18 Michael Krasnyk <mkrasnyk@argo.ai>
+
+ PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting
+ PR gold/28098
+ * reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries
+ with r_sym of zero without counting in advance method.
+
+2021-07-18 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: convert nat/x86-dregs.c macros to functions
+ I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because
+ x86_dr_low.get_status is nullptr. It would have been useful to be able
+ to break on x86_dr_low_get_status, so I thought it would be a good
+ reason to convert these function-like macros into functions.
+
+ Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721
+
+2021-07-18 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-17 Tom Tromey <tom@tromey.com>
+
+ Fix file-name handling regression with DWARF index
+ When run with the gdb-index or debug-names target boards, dup-psym.exp
+ fails. This came up for me because my new DWARF scanner reuses this
+ part of the existing index code, and so it registers as a regression.
+ This is PR symtab/25834.
+
+ Looking into this, I found that the DWARF index code here is fairly
+ different from the psymtab code. I don't think there's a deep reason
+ for this, and in fact, it seemed to me that the index code could
+ simply mimic what the psymtab code already does.
+
+ That is what this patch implements. The DW_AT_name and DW_AT_comp_dir
+ are now stored in the quick file names table. This may require
+ allocating a quick file names table even when DW_AT_stmt_list does not
+ exist. Then, the functions that work with this data are changed to
+ use find_source_or_rewrite, just as the psymbol code does. Finally,
+ line_header::file_full_name is removed, as it is no longer needed.
+
+ Currently, the index maintains a hash table of "quick file names".
+ The hash table uses a deletion function to free the "real name"
+ components when necessary. There's also a second such function to
+ implement the forget_cached_source_info method.
+
+ This bug fix patch will create a quick file name object even when
+ there is no DW_AT_stmt_list, meaning that the object won't be entered
+ in the hash table. So, this patch changes the memory management
+ approach so that the entries are cleared when the per-BFD object is
+ destroyed. (A dwarf2_per_cu_data destructor is not introduced,
+ because we have been avoiding adding a vtable to that class.)
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
+
+2021-07-17 Tom Tromey <tom@tromey.com>
+
+ Check for debug-types in map_symbol_filenames
+ map_symbol_filenames can skip type units -- in fact I think it has to,
+ due to the assertion at the top of dw2_get_file_names. This may be a
+ regression due to the TU/CU unification patch, I did not check.
+
+ Simplify DWARF file name caching
+ The DWARF index file name caching code only records when a line table
+ has been read and the reading failed. However, the code would be
+ simpler if it recorded any attempt, which is what this patch
+ implements.
+
+ Introduce find_source_or_rewrite
+ The final bug fix in this series would duplicate the logic in
+ psymtab_to_fullname, so this patch extracts the body of this function
+ into a new function.
+
+ Simplify file_and_directory storage management
+ file_and_directory carries a std::string in case the compilation
+ directory is computed, but a subsequent patch wants to preserve this
+ string without also having to maintain the storage for it. So, this
+ patch arranges for the compilation directory string to be stored in
+ the per-BFD string bcache instead.
+
+ Pass file_and_directory through DWARF line-decoding code
+ This patch removes the redundant "comp_unit" parameter from
+ compute_include_file_name, and arranges to pass a file_and_directory
+ object from the readers down to this function. It also changes the
+ partial symtab reader to use find_file_and_directory, rather than
+ reimplement this functionality by hand.
+
+ Rename and refactor psymtab_include_file_name
+ In order to fix an index-related regression, I want to use
+ psymtab_include_file_name in the DWARF index file-handling code. This
+ patch renames this function and changes it to no longer require a
+ partial symtab to be passed in. A subsequent patch will further
+ refactor this code to remove the redundant parameter (which was always
+ there but is now more obvious).
+
+2021-07-17 Sergey Belyashov <Sergey.Belyashov@gmail.com>
+
+ Add basic Z80 CPU support
+ Supported ISAs:
+ - Z80 (all undocumented instructions)
+ - Z180
+ - eZ80 (Z80 mode only)
+
+ Datasheets:
+ Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf
+ Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf
+ eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt
+
+ To debug Z80 programs using GDB you must configure and embed
+ z80-stub.c to your program (SDCC compiler is required). Or
+ you may use some simulator with GDB support.
+
+ gdb/ChangeLog:
+
+ * Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c.
+ * NEWS: Mention z80 support.
+ * configure.tgt: Handle z80*.
+ * features/Makefile (XMLTOC): Add z80.xml.
+ * features/z80-cpu.xml: New.
+ * features/z80.c: Generate.
+ * features/z80.xml: New.
+ * z80-tdep.c: New file.
+ * z80-tdep.h: New file.
+
+ gdb/stubs/ChangeLog:
+
+ * z80-stub.c: New file.
+
+ Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
+
+2021-07-17 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make all_inferiors_safe actually work
+ The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78
+ ("gdb: make inferior_list use intrusive_list"):
+
+ FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
+
+ Looking at the log, we see that we are left with a bunch of inferiors in
+ the detach-on-fork=off case:
+
+ info inferiors^M
+ Num Description Connection Executable ^M
+ * 1 <null> <snip>/fork-plus-threads ^M
+ 2 <null> <snip>/fork-plus-threads ^M
+ 3 <null> <snip>/fork-plus-threads ^M
+ 4 <null> <snip>/fork-plus-threads ^M
+ 5 <null> <snip>/fork-plus-threads ^M
+ 6 <null> <snip>/fork-plus-threads ^M
+ 7 <null> <snip>/fork-plus-threads ^M
+ 8 <null> <snip>/fork-plus-threads ^M
+ 9 <null> <snip>/fork-plus-threads ^M
+ 10 <null> <snip>/fork-plus-threads ^M
+ 11 <null> <snip>/fork-plus-threads ^M
+ (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
+
+ when we expect to have just one. The problem is prune_inferiors not
+ pruning inferiors. And this is caused by all_inferiors_safe not
+ actually iterating on inferiors. The current implementation:
+
+ inline all_inferiors_safe_range
+ all_inferiors_safe ()
+ {
+ return {};
+ }
+
+ default-constructs an all_inferiors_safe_range, which default-constructs
+ an all_inferiors_safe_iterator as its m_begin field, which
+ default-constructs a all_inferiors_iterator. A default-constructed
+ all_inferiors_iterator is an end iterator, which means we have
+ constructed an (end,end) all_inferiors_safe_range.
+
+ We actually need to pass down the list on which we want to iterator
+ (that is the inferior_list global), so that all_inferiors_iterator's
+ first constructor is chosen. We also pass nullptr as the proc_target
+ filter. In this case, we don't do any filtering, but if in the future
+ all_inferiors_safe needed to allow filtering on process target (like
+ all_inferiors does), we could pass down a process target pointer.
+
+ basic_safe_iterator's constructor needs to be changed to allow
+ constructing the wrapped iterator with multiple arguments, not just one.
+
+ With this, gdb.threads/fork-plus-threads.exp is passing once again for
+ me.
+
+ Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
+
+2021-07-17 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-16 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb: Support stepping out from signal handler on riscv*-linux
+ Currently, gdb cannot step outside of a signal handler on RISC-V
+ platforms. This causes multiple failures in gdb.base/sigstep.exp:
+
+ FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout)
+ FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout)
+ FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout)
+ FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout)
+ FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline
+ FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline
+
+ === gdb Summary ===
+
+ # of expected passes 587
+ # of unexpected failures 6
+
+ This patch adds support for stepping outside of a signal handler on
+ riscv*-*-linux*.
+
+ Implementation is heavily inspired from mips_linux_syscall_next_pc and
+ surroundings as advised by Pedro Alves.
+
+ After this patch, all tests in gdb.base/sigstep.exp pass.
+
+ Build and tested on riscv64-linux-gnu.
+
+2021-07-16 Lancelot SIX <lsix@lancelotsix.com>
+
+ gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_step
+ Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on
+ riscv64-linux-gnu. Those tests check that when stepping, if the
+ debuggee received a signal it should step inside the signal handler.
+
+ This feature requires hardware support for single stepping (or at least
+ kernel support), but none are available on riscv*-linux-gnu hosts, at
+ the moment at least.
+
+ This patch adds RISC-V to the list of configurations that does not
+ have hardware single step capability, disabling tests relying on such
+ feature.
+
+ Tested on riscv64-linux-gnu.
+
+2021-07-16 Tom Tromey <tom@tromey.com>
+
+ Document quick_symbol_functions::expand_symtabs_matching invariant
+ While working on my series to replace the DWARF psymbol reader, I
+ noticed that the expand_symtabs_matching has an undocumented
+ invariant. I think that, if this invariant is not followed, then GDB
+ will crash. So, this patch documents this in the relevant spots and
+ introduces some asserts to make it clear.
+
+ Regression tested on x86-64 Fedora 32.
+
+2021-07-16 Tom Tromey <tromey@adacore.com>
+
+ Fix array stride bug
+ Investigation of using the Python API with an Ada program showed that
+ an array of dynamic types was not being handled properly. I tracked
+ this down to an oddity of how array strides are handled.
+
+ In gdb, an array stride can be attached to the range type, via the
+ range_bounds object. However, the stride can also be put into the
+ array's first field. From create_range_type_with_stride:
+
+ else if (bit_stride > 0)
+ TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride;
+
+ It's hard to be sure why this is done, but I would guess a combination
+ of historical reasons plus a desire (mentioned in a comment somewhere)
+ to avoid modifying the range type.
+
+ This patch fixes the problem by changing type::bit_stride to
+ understand this convention. It also fixes one spot that reproduces
+ this logic.
+
+ Regression tested on x86-64 Fedora 32.
+
+2021-07-16 Giulio Benetti <giulio.benetti@benettiengineering.com>
+
+ or1k: fix pc-relative relocation against dynamic on PC relative 26 bit relocation.
+ bfd * elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry
+ in switch case R_OR1K_INSN_REL_26 where we need to check for
+ !SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL().
+
+2021-07-16 Nick Clifton <nickc@redhat.com>
+
+ Updated Swedish translation for the binutils sub-directory
+
+2021-07-16 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-15 Tom Tromey <tromey@adacore.com>
+
+ Avoid expression parsing crash with unknown language
+ PR gdb/28093 points out that gdb crashes when language is set to
+ "unknown" and expression parsing is attempted. At first I thought
+ this was a regression due to the expression rewrite, but it turns out
+ that older versions crash as well.
+
+ This patch avoids the crash by changing the default expression parser
+ to throw an exception. I think this is preferable -- the current
+ behavior of silently doing nothing does not really make sense.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
+
+2021-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: pass child_ptid and fork kind to target_ops::follow_fork
+ This is a small cleanup I think would be nice, that I spotted while
+ doing the following patch.
+
+ gdb/ChangeLog:
+
+ * target.h (struct target_ops) <follow_fork>: Add ptid and
+ target_waitkind parameters.
+ (target_follow_fork): Likewise.
+ * target.c (default_follow_fork): Likewise.
+ (target_follow_fork): Likewise.
+ * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
+ * fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise.
+ * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
+ * linux-nat.c (linux_nat_target::follow_fork): Likewise.
+ * obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise.
+ * obsd-nat.c (obsd_nat_target::follow_fork): Likewise.
+ * remote.c (class remote_target) <follow_fork>: Likewise.
+ * target-debug.h (target_debug_print_target_waitkind): New.
+ * target-delegates.c: Re-generate.
+
+ Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8
+
+2021-07-15 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: call post_create_inferior at end of follow_fork_inferior
+ GDB doesn't handle well the case of an inferior using the JIT interface
+ to register JIT-ed objfiles and forking. If an inferior registers a
+ code object using the JIT interface and then forks, the child process
+ conceptually has the same code object loaded, so GDB should look it up
+ and learn about it (it currently doesn't).
+
+ To achieve this, I think it would make sense to have the
+ inferior_created observable called when an inferior is created due to a
+ fork in follow_fork_inferior. The inferior_created observable is
+ currently called both after starting a new inferior and after attaching
+ to an inferior, allowing various sub-components to learn about that new
+ executing inferior. We can see handling a fork child just like
+ attaching to it, so any work done when attaching should also be done in
+ the case of a fork child.
+
+ Instead of just calling the inferior_created observable, this patch
+ makes follow_fork_inferior call the whole post_create_inferior function.
+ This way, the attach and follow-fork code code paths are more alike.
+
+ Given that post_create_inferior calls solib_create_inferior_hook,
+ follow_fork_inferior doesn't need to do it itself, so those calls to
+ solib_create_inferior_hook are removed.
+
+ One question you may have: why not just call post_create_inferior at the
+ places where solib_create_inferior_hook is currently called, instead of
+ after target_follow_fork?
+
+ - there's something fishy for the second solib_create_inferior_hook
+ call site: at this point we have switched the current program space
+ to the child's, but not the current inferior nor the current thread.
+ So solib_create_inferior_hook (and everything under, including
+ check_for_thread_db, for example) is called with inferior 1 as the
+ current inferior and inferior 2's program space as the current
+ program space. I think that's wrong, because at this point we are
+ setting up inferior 2, and all that code relies on the current
+ inferior. We could just add a switch_to_thread call before it to
+ make inferior 2 the current one, but there are other problems (see
+ below).
+
+ - solib_create_inferior_hook is currently not called on the
+ `follow_child && detach_fork` path. I think we need to call it,
+ because we still get a new inferior in that case (even though we
+ detach the parent). If we only call post_create_inferior where
+ solib_create_inferior_hook used to be called, then the JIT
+ subcomponent doesn't get informed about the new inferior, and that
+ introduces a failure in the new gdb.base/jit-elf-fork.exp test.
+
+ - if we try to put the post_create_inferior just after the
+ switch_to_thread that was originally at line 662, or just before the
+ call to target_follow_fork, we introduce a subtle failure in
+ gdb.threads/fork-thread-pending.exp. What happens then is that
+ libthread_db gets loaded (somewhere under post_create_inferior)
+ before the linux-nat target learns about the LWPs (which happens in
+ linux_nat_target::follow_fork). As a result, the ALL_LWPS loop in
+ try_thread_db_load_1 doesn't see the child LWP, and the thread-db
+ target doesn't have the chance to fill in thread_info::priv. A bit
+ later, when the test does "info threads", and
+ thread_db_target::pid_to_str is called, the thread-db target doesn't
+ recognize the thread as one of its own, and delegates the request to
+ the target below. Because the pid_to_str output is not the expected
+ one, the test fails.
+
+ This tells me that we need to call the process target's follow_fork
+ first, to make the process target create the necessary LWP and thread
+ structures. Then, we can call post_create_inferior to let the other
+ components of GDB do their thing.
+
+ But then you may ask: check_for_thread_db is already called today,
+ somewhere under solib_create_inferior_hook, and that is before
+ target_follow_fork, why don't we see this ordering problem!? Well,
+ because of the first bullet point: when check_for_thread_db /
+ thread_db_load are called, the current inferior is (erroneously)
+ inferior 1, the parent. Because libthread_db is already loaded for
+ the parent, thread_db_load early returns. check_for_thread_db later
+ gets called by linux_nat_target::follow_fork. At this point, the
+ current inferior is the correct one and the child's LWP exists, so
+ all is well.
+
+ Since we now call post_create_inferior after target_follow_fork, which
+ calls the inferior_created observable, which calls check_for_thread_db,
+ I don't think linux_nat_target needs to explicitly call
+ check_for_thread_db itself, so that is removed.
+
+ In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp
+ test. It makes an inferior register a JIT code object and then fork.
+ It then verifies that whatever the detach-on-fork and follow-fork-child
+ parameters are, GDB knows about the JIT code object in all the inferiors
+ that survive the fork. It verifies that the inferiors can unload that
+ code object.
+
+ There isn't currently a way to get visibility into GDB's idea of the JIT
+ code objects for each inferior. For the purpose of this test, add the
+ "maintenance info jit" command. There isn't much we can print about the
+ JIT code objects except their load address. So the output looks a bit
+ bare, but it's good enough for the test.
+
+ gdb/ChangeLog:
+
+ * NEWS: Mention "maint info jit" command.
+ * infrun.c (follow_fork_inferior): Don't call
+ solib_create_inferior_hook, call post_create_inferior if a new
+ inferior was created.
+ * jit.c (maint_info_jit_cmd): New.
+ (_initialize_jit): Register new command.
+ * linux-nat.c (linux_nat_target::follow_fork): Don't call
+ check_for_thread_db.
+ * linux-nat.h (check_for_thread_db): Remove declaration.
+ * linux-thread-db.c (check_thread_signals): Make static.
+
+ gdb/doc/ChangeLog:
+
+ * gdb.texinfo (Maintenance Commands): Mention "maint info jit".
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.base/jit-elf-fork-main.c: New test.
+ * gdb.base/jit-elf-fork-solib.c: New test.
+ * gdb.base/jit-elf-fork.exp: New test.
+
+ Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c
+
+2021-07-15 Libor Bukata <libor.bukata@oracle.com>
+
+ [gdb/procfs.c] Fix build failure in find_stop_signal
+ It fixes a regression caused by commit
+ 1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was
+ made private.
+
+ The public thread_info API has to be used to get stop signal and avoid
+ build failures.
+
+ gdb/ChangeLog:
+
+ 2021-07-14 Libor Bukata <libor.bukata@oracle.com>
+
+ * gdb/procfs.c (find_stop_signal): Use thread_info API.
+
+ Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904
+
+2021-07-15 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-14 H.J. Lu <hjl.tools@gmail.com>
+
+ x86: Add int1 as one byte opcode 0xf1
+ Also change the x86 disassembler to disassemble 0xf1 as int1, instead of
+ icebp.
+
+ gas/
+
+ PR gas/28088
+ * testsuite/gas/i386/opcode.s: Add int1.
+ * testsuite/gas/i386/x86-64-opcode.s: Add int1, int3 and int.
+ * testsuite/gas/i386/opcode-intel.d: Updated.
+ * testsuite/gas/i386/opcode-suffix.d: Likewise.
+ * testsuite/gas/i386/opcode.d: Likewise.
+ * testsuite/gas/i386/x86-64-opcode.d: Likewise.
+
+ opcodes/
+
+ PR gas/28088
+ * i386-dis.c (dis386): Replace icebp with int1.
+ * i386-opc.tbl: Add int1.
+ * i386-tbl.h: Regenerate.
+
+2021-07-14 Alan Modra <amodra@gmail.com>
+
+ gas: default TC_VALIDATE_FIX_SUB to 0
+ gas/write.c provides a fallback TC_VALIDATE_FIX_SUB define that can be
+ a problem for some targets, the problem being that a non-zero
+ definition of TC_VALIDATE_FIX_SUB says that some uses of fx_subsy are
+ OK, in effect that the target will handle fx_subsy in md_apply_fix
+ and/or tc_gen_reloc. A lot of targets don't have the necessary
+ md_apply_fix and tc_gen_reloc support. So a safer default is to
+ disallow fx_subsy by default.
+
+ I've had a good look over target usage of fx_subsy, and think I've
+ caught all the cases where targets need TC_VALIDATE_FIX_SUB. Possible
+ failures would be limited to alpha, microblaze, ppc and s390 (the
+ targets that define UNDEFINED_DIFFERENCE_OK), or targets that generate
+ fixups with BFD_RELOC_GPREL32/16 and use a syntax explicitly showing
+ a difference expression.
+
+ * write.c (TC_VALIDATE_FIX_SUB): Default to 0.
+ * config/tc-hppa.h (TC_VALIDATE_FIX_SUB): Define.
+ * config/tc-microblaze.h (TC_VALIDATE_FIX_SUB): Define.
+ * config/tc-alpha.h (TC_VALIDATE_FIX_SUB): Define for ECOFF.
+ * config/tc-ppc.h (TC_VALIDATE_FIX_SUB): Don't define for ELF.
+ Do define for XCOFF.
+
+2021-07-14 Clément Chigot <clement.chigot@atos.net>
+
+ objdump: add DWARF support for AIX
+ DWARF sections have special names on AIX which need be handled
+ by objdump in order to correctly print them.
+ This patch also adds the correlation in bfd for future uses.
+
+ bfd/
+ * libxcoff.h (struct xcoff_dwsect_name): Add DWARF name.
+ * coff-rs6000.c (xcoff_dwsect_names): Update.
+ * coffcode.h (sec_to_styp_flags): Likewise.
+ (coff_new_section_hook): Likewise.
+ binutils/
+ * dwarf.h (struct dwarf_section): Add XCOFF name.
+ * dwarf.c (struct dwarf_section_display): Update.
+ * objdump.c (load_debug_section): Add XCOFF name handler.
+ (dump_dwarf_section): Likewise.
+ gas/
+ * config/tc-ppc.c (ppc_change_debug_section): Update to
+ match new name's field.
+
+2021-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.base/gold-gdb-index.exp
+ When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
+ I run into:
+ ...
+ FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
+ ...
+
+ This is due to a dummy .gdb_index:
+ ...
+ Contents of the .gdb_index section:
+
+ Version 7
+
+ CU table:
+
+ TU table:
+
+ Address table:
+
+ Symbol table:
+ ...
+
+ The dummy .gdb_index is ignored when loading the symbols, and instead partial
+ symbols are used. Consequently, we get the same result as if we'd removed
+ -Wl,--gdb-index from the compilation.
+
+ Presumably, gold fails to generate a proper .gdb_index because it lacks
+ DWARF5 support.
+
+ Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
+ trying to excercise. Fix this by detecting whether we actually used a
+ .gdb_index for symbol loading.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-14 Tom de Vries <tdevries@suse.de>
+
+ * lib/gdb.exp (have_index): New proc.
+ * gdb.base/gold-gdb-index.exp: Use have_index.
+
+2021-07-14 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Add missing skip_tui_tests
+ When building gdb with --disable-tui, we run into:
+ ...
+ (gdb) frame apply all -- -^M
+ Undefined command: "-". Try "help".^M
+ (gdb) ERROR: Undefined command "frame apply all -- -".
+ UNRESOLVED: gdb.base/options.exp: test-frame-apply: frame apply all -- -
+ ...
+
+ Fix this by detecting whether tui is supported, and skipping the tui-related
+ tests otherwise. Same in some gdb.tui test-cases.
+
+ Tested on x86_64-linux.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-13 Tom de Vries <tdevries@suse.de>
+
+ * gdb.base/options.exp: Skip tui-related tests when tui is not
+ supported.
+ * gdb.python/tui-window-disabled.exp: Same.
+ * gdb.python/tui-window.exp: Same.
+
+2021-07-14 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-13 Lancelot SIX <lsix@lancelotsix.com>
+
+ Use /bin/sh as shebang in gdb/make-init-c
+ While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the
+ following error:
+
+ [...]
+ CXX aarch32-tdep.o
+ CXX gdb.o
+ GEN init.c
+ /nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory
+ make[2]: *** [Makefile:1866: stamp-init] Error 126
+ make[2]: *** Waiting for unfinished jobs....
+ make[2]: Leaving directory '/build/gdb-11.0.90/gdb'
+ make[1]: *** [Makefile:9814: all-gdb] Error 2
+ make[1]: Leaving directory '/build/gdb-11.0.90'
+ make: *** [Makefile:903: all] Error 2
+ builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2
+ error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed
+
+ In the nix build environment, /usr/bin/env is not present, only /bin/sh
+ is. This patch makes sure that gdb/make-init-c uses '/bin/sh' as
+ interpreter as this is the only one available on this platform.
+
+ I do not think this change will cause regressions on any other
+ configuration.
+
+ [1] https://nixos.org/
+
+ gdb/Changelog
+
+ * make-init-c: Use /bin/sh as shebang.
+
+2021-07-13 John Baldwin <jhb@FreeBSD.org>
+
+ arm-fbsd-nat: Use fetch_register_set and store_register_set.
+
+ aarch64-fbsd-nat: Use fetch_register_set and store_register_set.
+
+ riscv-fbsd-nat: Use fetch_register_set and store_register_set.
+
+ fbsd-nat: Add helper functions to fetch and store register sets.
+ In particular, this supports register sets described by a regcache_map
+ which are fetched and stored with dedicated ptrace operations. These
+ functions are intended to be used in architecture-specific
+ fetch_registers and store_registers target methods.
+
+ Add regcache_map_supplies helper routine.
+ This helper can be used in the fetch_registers and store_registers
+ target methods to determine if a register set includes a specific
+ register.
+
+2021-07-13 Pedro Alves <pedro@palves.net>
+
+ Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)
+ Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
+ like this:
+
+ (gdb) detach
+ Detaching from program: target:/any/program, process 3671843
+ Detaching from process 3671843
+ Ending remote debugging.
+ [Inferior 1 (process 3671843) detached]
+ In main
+ terminate called after throwing an instance of 'gdb_exception_error'
+ Aborted (core dumped)
+
+ Here's the exception above being thrown:
+
+ (top-gdb) bt
+ #0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
+ #1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
+ #2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
+ #3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
+ #4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
+ #5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
+ #6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
+ this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
+ #7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
+ #8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
+ #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
+ #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
+ #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
+ #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
+ #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
+ #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+ #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
+ #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
+ #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
+ #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
+ #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
+ #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
+ #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
+ #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
+ #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
+ #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
+ #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
+ #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
+ #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
+ #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
+
+ Note frame #14:
+
+ #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+
+ That's a dtor, thus noexcept. That's the reason for the
+ std::terminate.
+
+ The previous patch fixed things such that the exception above isn't
+ thrown anymore. However, it's possible that e.g., the remote
+ connection drops just while a user types "nosharedlibrary", or some
+ other reason that leads to objfile::~objfile, and then we end up the
+ same std::terminate problem.
+
+ Also notice that frames #9-#11 are BFD frames:
+
+ #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599
+ #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847
+ #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814
+
+ BFD is written in C and thus throwing exceptions over such frames may
+ either not clean up properly, or, may abort if bfd is not compiled
+ with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
+ all GCC ports do).
+
+ Thus frame #8 seems like a good place to swallow exceptions. More so
+ since in this spot we already ignore target_fileio_close return
+ errors. That's what this commit does. Without the previous fix, we'd
+ see:
+
+ (gdb) detach
+ Detaching from program: target:/any/program, process 2197701
+ Ending remote debugging.
+ [Inferior 1 (process 2197701) detached]
+ warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed
+
+ Note it prints a warning, which would still be a regression compared
+ to GDB 10, if it weren't for the previous fix.
+
+ gdb/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ PR gdb/28080
+ * gdb_bfd.c (gdb_bfd_close_warning): New.
+ (gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
+ try/catch and print warning on exception.
+ (gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.
+
+ Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7
+
+2021-07-13 Pedro Alves <pedro@palves.net>
+
+ Fix detach with target remote (PR gdb/28080)
+ Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
+ with threads running") regressed "detach" with "target remote":
+
+ (gdb) detach
+ Detaching from program: target:/any/program, process 3671843
+ Detaching from process 3671843
+ Ending remote debugging.
+ [Inferior 1 (process 3671843) detached]
+ In main
+ terminate called after throwing an instance of 'gdb_exception_error'
+ Aborted (core dumped)
+
+ Here's the exception above being thrown:
+
+ (top-gdb) bt
+ #0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
+ #1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
+ #2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
+ #3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
+ #4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
+ #5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
+ #6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
+ this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
+ #7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
+ #8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
+ #9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
+ #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
+ #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
+ #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
+ #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
+ #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+ #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
+ #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
+ #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
+ #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
+ #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
+ #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
+ #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
+ #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
+ #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
+ #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
+ #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
+ #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
+ #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
+ #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
+
+ So frame #28 already detached the remote process, and then we're
+ purging the shared libraries. GDB had opened remote shared libraries
+ via the target: sysroot, so it tries closing them. GDBserver is
+ tearing down already, so remote communication breaks down and we close
+ the remote target and throw TARGET_CLOSE_ERROR.
+
+ Note frame #14:
+
+ #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+
+ That's a dtor, thus noexcept. That's the reason for the
+ std::terminate.
+
+ Stepping back a bit, why do we still have open remote files if we've
+ managed to detach already, and, we're debugging with "target remote"?
+ The reason is that commit 408f66864a1a823591b26420410c982174c239a2
+ makes detach_command hold a reference to the target, so the remote
+ target won't be finally closed until frame #28 returns. It's closing
+ the target that invalidates target file I/O handles.
+
+ This commit fixes the issue by not relying on target_close to
+ invalidate the target file I/O handles, instead invalidate them
+ immediately in remote_unpush_target. So when GDB purges the solibs,
+ and we end up in target_fileio_close (frame #7 above), there's nothing
+ to do, and we don't try to talk with the remote target anymore.
+
+ The regression isn't seen when testing with
+ --target_board=native-gdbserver, because that does "set sysroot" to
+ disable the "target:" sysroot, for test run speed reasons. So this
+ commit adds a testcase that explicitly tests detach with "set sysroot
+ target:".
+
+ gdb/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ PR gdb/28080
+ * remote.c (remote_unpush_target): Invalidate file I/O target
+ handles.
+ * target.c (fileio_handles_invalidate_target): Make extern.
+ * target.h (fileio_handles_invalidate_target): Declare.
+
+ gdb/testsuite/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ PR gdb/28080
+ * gdb.base/detach-sysroot-target.exp: New.
+ * gdb.base/detach-sysroot-target.c: New.
+
+ Reported-By: Jonah Graham <jonah@kichwacoders.com>
+
+ Change-Id: I851234910172f42a1b30e731161376c344d2727d
+
+2021-07-13 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33
+ When running test-case gdb.threads/check-libthread-db.exp on openSUSE
+ Tumbleweed with glibc 2.33, I get:
+ ...
+ (gdb) maint check libthread-db^M
+ Running libthread_db integrity checks:^M
+ Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
+ libthread_db integrity checks passed.^M
+ (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \
+ libpthread.so not initialized (pattern 2)
+ ...
+
+ The test-case expects instead:
+ ...
+ Got thread 0x0 => 9354 => 0x0 ... OK^M
+ ...
+ which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
+ described in the test-case like this:
+ ...
+ # libthread_db should fake a single thread with th_unique == NULL.
+ ...
+
+ Using a breakpoint on check_thread_db_callback we can compare the two
+ scenarios, and find that in the latter case we hit this code in glibc function
+ iterate_thread_list in nptl_db/td_ta_thr_iter.c:
+ ...
+ if (next == 0 && fake_empty)
+ {
+ /* __pthread_initialize_minimal has not run. There is just the main
+ thread to return. We cannot rely on its thread register. They
+ sometimes contain garbage that would confuse us, left by the
+ kernel at exec. So if it looks like initialization is incomplete,
+ we only fake a special descriptor for the initial thread. */
+ td_thrhandle_t th = { ta, 0 };
+ return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
+ }
+ ...
+ while in the former case we don't because this preceding statement doesn't
+ result in next == 0:
+ ...
+ err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
+ ...
+
+ Note that the comment mentions __pthread_initialize_minimal, but in both cases
+ it has already run before we hit the callback, so it's possible the comment is
+ no longer accurate.
+
+ The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack
+ list variables into _rtld_global", which moves the initialization of stack
+ list variables such as __stack_user to an earlier moment, which explains well
+ enough the observed difference.
+
+ Fix this by updating the regexp patterns to agree with what libthread-db is
+ telling us.
+
+ Tested on x86_64-linux, both with glibc 2.33 and 2.26.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-07 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/27690
+ * gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.
+
+2021-07-13 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ gdb, dwarf: Don't follow the parent of a subprogram to get a prefix.
+ During prefix resolution, if the parent is a subprogram, there is no need
+ to go to the parent of the subprogram. The DIE will be local.
+
+ For a program like:
+ ~~~
+ class F1
+ {
+ public:
+ int a;
+ int
+ vvv ()
+ {
+ class F2
+ {
+ int f;
+ };
+ F2 abcd;
+ return 1;
+ }
+ };
+ ~~~
+
+ The class F2 should not be seen as a member of F1.
+
+ Before:
+ ~~~
+ (gdb) ptype abcd
+ type = class F1::F2 {
+ private:
+ int f;
+ }
+ ~~~
+
+ After:
+ ~~~
+ (gdb) ptype abcd
+ type = class F2 {
+ private:
+ int f;
+ }
+ ~~~
+
+ gdb/ChangeLog:
+ 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ * dwarf2/read.c (determine_prefix): Return an empty prefix if the
+ parent is a subprogram.
+
+ gdb/testsuite/ChangeLog:
+ 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com>
+
+ * gdb.cp/nested-class-func-class.cc: New file.
+ * gdb.cp/nested-class-func-class.exp: New file.
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: disable commit-resumed on -exec-interrupt --thread-group
+ As reported in PR gdb/28077, we hit an internal error when using
+ -exec-interrupt with --thread-group:
+
+ info threads
+ &"info threads\n"
+ ~" Id Target Id Frame \n"
+ ~"* 1 process 403312 \"loop\" (running)\n"
+ ^done
+ (gdb)
+ -exec-interrupt --thread-group i1
+ ~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
+
+ This is because this code path never disables commit-resumed (a
+ requirement for calling target_stop, as documented in
+ process_stratum_target::»commit_resumed_state) before calling
+ target_stop.
+
+ The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
+ which does it. But the --thread-group code path uses its own thing
+ which doesn't do it. Fix this by adding a scoped_disable_commit_resumed
+ in this code path.
+
+ Calling -exec-interrupt with --thread-group is apparently not tested at
+ the moment (which is why this bug could creep in). Add a new test for
+ that. The test runs two inferiors and tries to interrupt them with
+ "-exec-interrupt --thread-group X".
+
+ This will need to be merged in the gdb-11-branch, so here are ChangeLog
+ entries:
+
+ gdb/ChangeLog:
+
+ * mi/mi-main.c (mi_cmd_exec_interrupt): Use
+ scoped_disable_commit_resumed in the --thread-group case.
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.mi/interrupt-thread-group.c: New.
+ * gdb.mi/interrupt-thread-group.exp: New.
+
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
+ Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb
+
+2021-07-13 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Enable elf attributes when default configure option isn't set.
+ Since gcc commit, 3c70b3ca1ef58f302bf8c16d9e7c7bb8626408bf, we now enable
+ elf attributes for all riscv targets by default in gcc. Therefore, I
+ think binutils should have the same behavior, in case users are writing
+ assembly files. If --enable-default-riscv-attribute isn't set, then we
+ enable the elf attributes for all riscv targets by default.
+
+ ChangLog:
+
+ binutils/
+
+ * testsuite/binutils-all/readelf.s: Add comments for riscv.
+ * testsuite/binutils-all/readelf.s-64: Likewise.
+ * testsuite/binutils-all/readelf.s-64-unused: Likewise.
+ * testsuite/binutils-all/readelf.ss: Likewise.
+ * testsuite/binutils-all/readelf.ss-64: Likewise.
+ * testsuite/binutils-all/readelf.ss-64-unused: Likewise.
+
+ gas/
+
+ * configure.ac: If --enable-default-riscv-attribute isn't set,
+ then we enable the elf attributes for all riscv targets by
+ default.
+ * configure: Regenerated.
+
+2021-07-13 John Ericson <git@JohnEricson.me>
+
+ Fix some dangling references to `netbsd-tdep`
+ These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10,
+ but evidentially a few dangling references were left behind. This causes
+ builds to fail:
+
+ $ ./configure --target i686-netbsdelf
+ $ make
+ make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'. Stop.
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: optimize all_matching_threads_iterator
+ all_matching_threads_iterator is used extensively in some pretty fast
+ paths, often under the all_non_exited_threads function.
+
+ If a filter target and thread-specific ptid are given, it iterates on
+ all threads of all inferiors of that target, to ultimately yield exactly
+ on thread. And this happens quite often, which means we unnecessarily
+ spend time iterating on threads to find the one we are looking for. The
+ same thing happens if an inferior-specific ptid is given, although there
+ the iterator yields all the threads of that inferior.
+
+ In those cases, the callers of all_non_exited_threads could have
+ different behaviors depending on the kind of ptid, to avoid this
+ inefficiency, but that would be very tedious. Using
+ all_non_exited_threads has the advantage that one simple implementation
+ can work seamlessly on multiple threads or on one specific thread, just
+ by playing with the ptid.
+
+ Instead, optimize all_matching_threads_iterator directly to detect these
+ different cases and limiting what we iterate on to just what we need.
+
+ - if filter_ptid is minus_one_ptid, do as we do now: filter inferiors
+ based on filter_target, iterate on all of the matching inferiors'
+ threads
+ - if filter_ptid is a pid-only ptid (then a filter_target must
+ necessarily be given), look up that inferior and iterate on all its
+ threads
+ - otherwise, filter_ptid is a thread-specific ptid, so look up that
+ specific thread and "iterate" only on it
+
+ For the last case, what was an iteration on all threads of the filter
+ target now becomes a call to find_thread_ptid, which is quite efficient
+ now thanks to inferior::ptid_thread_map.
+
+ gdb/ChangeLog:
+
+ * thread-iter.h (class all_matching_threads_iterator)
+ <all_matching_threads_iterator>: Use default.
+ <enum class mode>: New.
+ <m_inf, m_thr>: Initialize.
+ <m_filter_ptid>: Remove.
+ * thread-iter.c (all_matching_threads_iterator::m_inf_matches):
+ Don't filter on m_filter_ptid.
+ (all_matching_threads_iterator::all_matching_threads_iterator):
+ Choose path based on filter_ptid (all threads, all threads of
+ inferior, single thread).
+ (all_matching_threads_iterator::advance): Likewise.
+
+ Change-Id: Ic6a19845f5f760fa1b8eac8145793c0ff431bbc9
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: maintain ptid -> thread map, optimize find_thread_ptid
+ When debugging a large number of threads (thousands), looking up a
+ thread by ptid_t using the inferior::thread_list linked list can add up.
+
+ Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and
+ change the find_thread_ptid function to look up a thread using
+ std::unordered_map::find, instead of iterating on all of the
+ inferior's threads. This should make it faster to look up a thread
+ from its ptid.
+
+ Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c
+ Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: optimize selection of resumed thread with pending event
+ Consider a case where many threads (thousands) keep hitting a breakpoint
+ whose condition evaluates to false. random_pending_event_thread is
+ responsible for selecting a thread from an inferior among all that are
+ resumed with a pending wait status. It is currently implemented by
+ walking the inferior's thread list twice: once to count the number of
+ candidates and once to select a random one.
+
+ Since we now maintain a per target list of resumed threads with pending
+ event, we can implement this more efficiently by walking that list and
+ selecting the first thread that matches the criteria
+ (random_pending_event_thread looks for an thread from a specific
+ inferior, and possibly a filter ptid). It will be faster especially in
+ the common case where there isn't any resumed thread with pending
+ event. Currently, we have to iterate the thread list to figure this
+ out. With this patch, the list of resumed threads with pending event
+ will be empty, so it's quick to figure out.
+
+ The random selection is kept, but is moved to
+ process_stratum_target::random_resumed_with_pending_wait_status. The
+ same technique is used: do a first pass to count the number of
+ candidates, and do a second pass to select a random one. But given that
+ the list of resumed threads with pending wait statuses will generally be
+ short, or at least shorter than the full thread list, it should be
+ quicker.
+
+ Note that this isn't completely true, in case there are multiple
+ inferiors on the same target. Imagine that inferior A has 10k resumed
+ threads with pending wait statuses, and random_pending_event_thread is
+ called with inferior B. We'll need to go through the list that contains
+ inferior A's threads to realize that inferior B has no resumed threads
+ with pending wait status. But I think that this is a corner /
+ pathological case. And a possible fix for this situation would be to
+ make random_pending_event_thread work per-process-target, rather than
+ per-inferior.
+
+ Change-Id: I1b71d01beaa500a148b5b9797745103e13917325
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: optimize check for resumed threads with pending wait status in maybe_set_commit_resumed_all_targets
+ Consider a test case where many threads (thousands) keep hitting a
+ breakpoint whose condition evaluates to false.
+ maybe_set_commit_resumed_all_targets is called at each handled event,
+ when the scoped_disable_commit_resumed object in fetch_inferior_event is
+ reset_and_commit-ed. One particularly expensive check in there is
+ whether the target has at least one resumed thread with a pending wait
+ status (in which case, we don't want to commit the resumed threads, as
+ we want to consume this status first). It is currently implemented as
+ walking all threads of the target.
+
+ Since we now maintain a per-target list of resumed threads with pending
+ status, we can do this check efficiently, by checking whether that list
+ is empty or not.
+
+ Add the process_stratum_target::has_resumed_with_pending_wait_status
+ method for this, and use it in maybe_set_commit_resumed_all_targets.
+
+ Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: maintain per-process-target list of resumed threads with pending wait status
+ Looking up threads that are both resumed and have a pending wait
+ status to report is something that we do quite often in the fast path
+ and is expensive if there are many threads, since it currently requires
+ walking whole thread lists.
+
+ The first instance is in maybe_set_commit_resumed_all_targets. This is
+ called after handling each event in fetch_inferior_event, to see if we
+ should ask targets to commit their resumed threads or not. If at least
+ one thread is resumed but has a pending wait status, we don't ask the
+ targets to commit their resumed threads, because we want to consume and
+ handle the pending wait status first.
+
+ The second instance is in random_pending_event_thread, where we want to
+ select a random thread among all those that are resumed and have a
+ pending wait status. This is called every time we try to consume
+ events, to see if there are any pending events that we we want to
+ consume, before asking the targets for more events.
+
+ To allow optimizing these cases, maintain a per-process-target list of
+ threads that are resumed and have a pending wait status.
+
+ In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1)
+ if there are any such threads simply by checking whether the list is
+ empty.
+
+ In random_pending_event_thread, we'll be able to use that list, which
+ will be quicker than iterating the list of threads, especially when
+ there are no resumed with pending wait status threads.
+
+ About implementation details: using the new setters on class
+ thread_info, it's relatively easy to maintain that list. Any time the
+ "resumed" or "pending wait status" property is changed, we check whether
+ that should cause the thread to be added or removed from the list.
+
+ In set_thread_exited, we try to remove the thread from the list, because
+ keeping an exited thread in that list would make no sense (especially if
+ the thread is freed). My first implementation assumed that a process
+ stratum target was always present when set_thread_exited is called.
+ That's however, not the case: in some cases, targets unpush themselves
+ from an inferior and then call "exit_inferior", which exits all the
+ threads. If the target is unpushed before set_thread_exited is called
+ on the threads, it means we could mistakenly leave some threads in the
+ list. I tried to see how hard it would be to make it such that targets
+ have to exit all threads before unpushing themselves from the inferior
+ (that would seem logical to me, we don't want threads belonging to an
+ inferior that has no process target). That seemed quite difficult and
+ not worth the time at the moment. Instead, I changed
+ inferior::unpush_target to remove all threads of that inferior from the
+ list.
+
+ As of this patch, the list is not used, this is done in the subsequent
+ patches.
+
+ The debug messages in process-stratum-target.c need to print some ptids.
+ However, they can't use target_pid_to_str to print them without
+ introducing a dependency on the current inferior (the current inferior
+ is used to get the current target stack). For debug messages, I find it
+ clearer to print the spelled out ptid anyway (the pid, lwp and tid
+ values). Add a ptid_t::to_string method that returns a string
+ representation of the ptid that is meant for debug messages, a bit like
+ we already have frame_id::to_string.
+
+ Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: make thread_info::suspend private, add getters / setters
+ A following patch will want to take some action when a pending wait
+ status is set on or removed from a thread. Add a getter and a setter on
+ thread_info for the pending waitstatus, so that we can add some code in
+ the setter later.
+
+ The thing is, the pending wait status field is in the
+ thread_suspend_state, along with other fields that we need to backup
+ before and restore after the thread does an inferior function call.
+ Therefore, make the thread_suspend_state member private
+ (thread_info::suspend becomes thread_info::m_suspend), and add getters /
+ setters for all of its fields:
+
+ - pending wait status
+ - stop signal
+ - stop reason
+ - stop pc
+
+ For the pending wait status, add the additional has_pending_waitstatus
+ and clear_pending_waitstatus methods.
+
+ I think this makes the thread_info interface a bit nicer, because we
+ now access the fields as:
+
+ thread->stop_pc ()
+
+ rather than
+
+ thread->suspend.stop_pc
+
+ The stop_pc field being in the `suspend` structure is an implementation
+ detail of thread_info that callers don't need to be aware of.
+
+ For the backup / restore of the thread_suspend_state structure, add
+ save_suspend_to and restore_suspend_from methods. You might wonder why
+ `save_suspend_to`, as opposed to a simple getter like
+
+ thread_suspend_state &suspend ();
+
+ I want to make it clear that this is to be used only for backing up and
+ restoring the suspend state, _not_ to access fields like:
+
+ thread->suspend ()->stop_pc
+
+ Adding some getters / setters allows adding some assertions. I find
+ that this helps understand how things are supposed to work. Add:
+
+ - When getting the pending status (pending_waitstatus method), ensure
+ that there is a pending status.
+ - When setting a pending status (set_pending_waitstatus method), ensure
+ there is no pending status.
+
+ There is one case I found where this wasn't true - in
+ remote_target::process_initial_stop_replies - which needed adjustments
+ to respect that contract. I think it's because
+ process_initial_stop_replies is kind of (ab)using the
+ thread_info::suspend::waitstatus to store some statuses temporarily, for
+ its internal use (statuses it doesn't intent on leaving pending).
+
+ process_initial_stop_replies pulls out stop replies received during the
+ initial connection using target_wait. It always stores the received
+ event in `evthread->suspend.waitstatus`. But it only sets
+ waitstatus_pending_p, if it deems the event interesting enough to leave
+ pending, to be reported to the core:
+
+ if (ws.kind != TARGET_WAITKIND_STOPPED
+ || ws.value.sig != GDB_SIGNAL_0)
+ evthread->suspend.waitstatus_pending_p = 1;
+
+ It later uses this flag a bit below, to choose which thread to make the
+ "selected" one:
+
+ if (selected == NULL
+ && thread->suspend.waitstatus_pending_p)
+ selected = thread;
+
+ And ultimately that's used if the user-visible mode is all-stop, so that
+ we print the stop for that interesting thread:
+
+ /* In all-stop, we only print the status of one thread, and leave
+ others with their status pending. */
+ if (!non_stop)
+ {
+ thread_info *thread = selected;
+ if (thread == NULL)
+ thread = lowest_stopped;
+ if (thread == NULL)
+ thread = first;
+
+ print_one_stopped_thread (thread);
+ }
+
+ But in any case (all-stop or non-stop), print_one_stopped_thread needs
+ to access the waitstatus value of these threads that don't have a
+ pending waitstatus (those that had TARGET_WAITKIND_STOPPED +
+ GDB_SIGNAL_0). This doesn't work with the assertions I've
+ put.
+
+ So, change the code to only set the thread's wait status if it is an
+ interesting one that we are going to leave pending. If the thread
+ stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED +
+ GDB_SIGNAL_0), don't store it. Adjust print_one_stopped_thread to
+ understand that if a thread has no pending waitstatus, it's because it
+ stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0.
+
+ The call to set_last_target_status also uses the pending waitstatus.
+ However, given that the pending waitstatus for the thread may have been
+ cleared in print_one_stopped_thread (and that there might not even be a
+ pending waitstatus in the first place, as explained above), it is no
+ longer possible to do it at this point. To fix that, move the call to
+ set_last_target_status in print_one_stopped_thread. I think this will
+ preserve the existing behavior, because set_last_target_status is
+ currently using the current thread's wait status. And the current
+ thread is the last one for which print_one_stopped_thread is called. So
+ by calling set_last_target_status in print_one_stopped_thread, we'll get
+ the same result. set_last_target_status will possibly be called
+ multiple times, but only the last call will matter. It just means
+ possibly more calls to set_last_target_status, but those are cheap.
+
+ Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: add setter / getter for thread_info resumed state
+ A following patch will want to do things when a thread's resumed state
+ changes. Make the `resumed` field private (renamed to `m_resumed`) and
+ add a getter and a setter for it. The following patch in question will
+ therefore be able to add some code to the setter.
+
+ Change-Id: I360c48cc55a036503174313261ce4e757d795319
+
+2021-07-13 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: use intrusive list for step-over chain
+ The threads that need a step-over are currently linked using an
+ hand-written intrusive doubly-linked list, so that seems a very good
+ candidate for intrusive_list, convert it.
+
+ For this, we have a use case of appending a list to another one (in
+ start_step_over). Based on the std::list and Boost APIs, add a splice
+ method. However, only support splicing the other list at the end of the
+ `this` list, since that's all we need.
+
+ Add explicit default assignment operators to
+ reference_to_pointer_iterator, which are otherwise implicitly deleted.
+ This is needed because to define thread_step_over_list_safe_iterator, we
+ wrap reference_to_pointer_iterator inside a basic_safe_iterator, and
+ basic_safe_iterator needs to be able to copy-assign the wrapped
+ iterator. The move-assignment operator is therefore not needed, only
+ the copy-assignment operator is. But for completeness, add both.
+
+ Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c
+
+2021-07-13 Pedro Alves <pedro@palves.net>
+
+ gdb: make inferior_list use intrusive_list
+ Change inferior_list, the global list of inferiors, to use
+ intrusive_list. I think most other changes are somewhat obvious
+ fallouts from this change.
+
+ There is a small change in behavior in scoped_mock_context. Before this
+ patch, constructing a scoped_mock_context would replace the whole
+ inferior list with only the new mock inferior. Tests using two
+ scoped_mock_contexts therefore needed to manually link the two inferiors
+ together, as the second scoped_mock_context would bump the first mock
+ inferior from the thread list. With this patch, a scoped_mock_context
+ adds its mock inferior to the inferior list on construction, and removes
+ it on destruction. This means that tests run with mock inferiors in the
+ inferior list in addition to any pre-existing inferiors (there is always
+ at least one). There is no possible pid clash problem, since each
+ scoped mock inferior uses its own process target, and pids are per
+ process target.
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018
+
+2021-07-13 Pedro Alves <pedro@palves.net>
+
+ gdb: introduce intrusive_list, make thread_info use it
+ GDB currently has several objects that are put in a singly linked list,
+ by having the object's type have a "next" pointer directly. For
+ example, struct thread_info and struct inferior. Because these are
+ simply-linked lists, and we don't keep track of a "tail" pointer, when
+ we want to append a new element on the list, we need to walk the whole
+ list to find the current tail. It would be nice to get rid of that
+ walk. Removing elements from such lists also requires a walk, to find
+ the "previous" position relative to the element being removed. To
+ eliminate the need for that walk, we could make those lists
+ doubly-linked, by adding a "prev" pointer alongside "next". It would be
+ nice to avoid the boilerplate associated with maintaining such a list
+ manually, though. That is what the new intrusive_list type addresses.
+
+ With an intrusive list, it's also possible to move items out of the
+ list without destroying them, which is interesting in our case for
+ example for threads, when we exit them, but can't destroy them
+ immediately. We currently keep exited threads on the thread list, but
+ we could change that which would simplify some things.
+
+ Note that with std::list, element removal is O(N). I.e., with
+ std::list, we need to walk the list to find the iterator pointing to
+ the position to remove. However, we could store a list iterator
+ inside the object as soon as we put the object in the list, to address
+ it, because std::list iterators are not invalidated when other
+ elements are added/removed. However, if you need to put the same
+ object in more than one list, then std::list<object> doesn't work.
+ You need to instead use std::list<object *>, which is less efficient
+ for requiring extra memory allocations. For an example of an object
+ in multiple lists, see the step_over_next/step_over_prev fields in
+ thread_info:
+
+ /* Step-over chain. A thread is in the step-over queue if these are
+ non-NULL. If only a single thread is in the chain, then these
+ fields point to self. */
+ struct thread_info *step_over_prev = NULL;
+ struct thread_info *step_over_next = NULL;
+
+ The new intrusive_list type gives us the advantages of an intrusive
+ linked list, while avoiding the boilerplate associated with manually
+ maintaining it.
+
+ intrusive_list's API follows the standard container interface, and thus
+ std::list's interface. It is based the API of Boost's intrusive list,
+ here:
+
+ https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html
+
+ Our implementation is relatively simple, while Boost's is complicated
+ and intertwined due to a lot of customization options, which our version
+ doesn't have.
+
+ The easiest way to use an intrusive_list is to make the list's element
+ type inherit from intrusive_node. This adds a prev/next pointers to
+ the element type. However, to support putting the same object in more
+ than one list, intrusive_list supports putting the "node" info as a
+ field member, so you can have more than one such nodes, one per list.
+
+ As a first guinea pig, this patch makes the per-inferior thread list use
+ intrusive_list using the base class method.
+
+ Unlike Boost's implementation, ours is not a circular list. An earlier
+ version of the patch was circular: the intrusive_list type included an
+ intrusive_list_node "head". In this design, a node contained pointers
+ to the previous and next nodes, not the previous and next elements.
+ This wasn't great for when debugging GDB with GDB, as it was difficult
+ to get from a pointer to the node to a pointer to the element. With the
+ design proposed in this patch, nodes contain pointers to the previous
+ and next elements, making it easy to traverse the list by hand and
+ inspect each element.
+
+ The intrusive_list object contains pointers to the first and last
+ elements of the list. They are nullptr if the list is empty.
+ Each element's node contains a pointer to the previous and next
+ elements. The first element's previous pointer is nullptr and the last
+ element's next pointer is nullptr. Therefore, if there's a single
+ element in the list, both its previous and next pointers are nullptr.
+ To differentiate such an element from an element that is not linked into
+ a list, the previous and next pointers contain a special value (-1) when
+ the node is not linked. This is necessary to be able to reliably tell
+ if a given node is currently linked or not.
+
+ A begin() iterator points to the first item in the list. An end()
+ iterator contains nullptr. This makes iteration until end naturally
+ work, as advancing past the last element will make the iterator contain
+ nullptr, making it equal to the end iterator. If the list is empty,
+ a begin() iterator will contain nullptr from the start, and therefore be
+ immediately equal to the end.
+
+ Iterating on an intrusive_list yields references to objects (e.g.
+ `thread_info&`). The rest of GDB currently expects iterators and ranges
+ to yield pointers (e.g. `thread_info*`). To bridge the gap, add the
+ reference_to_pointer_iterator type. It is used to define
+ inf_threads_iterator.
+
+ Add a Python pretty-printer, to help inspecting intrusive lists when
+ debugging GDB with GDB. Here's an example of the output:
+
+ (top-gdb) p current_inferior_.m_obj.thread_list
+ $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80}
+
+ It's not possible with current master, but with this patch [1] that I
+ hope will be merged eventually, it's possible to index the list and
+ access the pretty-printed value's children:
+
+ (top-gdb) p current_inferior_.m_obj.thread_list[1]
+ $2 = (thread_info *) 0x617000069080
+ (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid
+ $3 = {
+ m_pid = 406499,
+ m_lwp = 406503,
+ m_tid = 0
+ }
+
+ Even though iterating the list in C++ yields references, the Python
+ pretty-printer yields pointers. The reason for this is that the output
+ of printing the thread list above would be unreadable, IMO, if each
+ thread_info object was printed in-line, since they contain so much
+ information. I think it's more useful to print pointers, and let the
+ user drill down as needed.
+
+ [1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html
+
+ Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+ Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0
+
+2021-07-13 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-12 Tucker <tuckkern@sourceware@gmail.com>
+
+ Add the SEC_ELF_OCTETS flag to debug sections created by the assembler.
+ PR 28054
+ gas * config/obj-elf.c (obj_elf_change_section): Set the
+ SEF_ELF_OCTETS flag on debug sections.
+
+2021-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcode
+ Recently I started to see this fail with trunk:
+ ...
+ (gdb) record instruction-history^M
+ 1 0x00000000004004ab <main+4>: call 0x4004b7 <test>^M
+ 2 0x00000000004004c6 <test+15>: mov $0x1,%eax^M
+ 3 0x00000000004004cb <test+20>: ret ^M
+ (gdb) FAIL: gdb.btrace/tsx.exp: speculation indication
+ ...
+
+ This is due to an intel microcode update (1) that disables Intel TSX by default.
+
+ Fix this by updating the pattern.
+
+ Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1.
+
+ [1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-12 Tom de Vries <tdevries@suse.de>
+
+ PR testsuite/28057
+ * gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in
+ microcode.
+
+2021-07-12 Nick Clifton <nickc@redhat.com>
+
+ Updated French translation for the binutils sub-directory
+
+ Fix a translation problem for the text generated by readelf at the start of a dump of a dynamic section.
+ PR 28072
+ binutils * readelf.c (process_dynamic_section): Use ngettext to help with translation of header text.
+
+2021-07-12 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug info
+ When running test-case gdb.mi/mi-info-sources.exp, I run into:
+ ...
+ Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ...
+ ERROR: internal buffer is full.
+ ...
+ due to extra debug info from the shared libraries.
+
+ Fix this by using "nosharedlibrary".
+
+ Then I run into these FAILs:
+ ...
+ FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \
+ -file-list-exec-source-files (unexpected output)
+ FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+ -file-list-exec-source-files (unexpected output)
+ FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+ -file-list-exec-source-files --group-by-objfile, look for \
+ mi-info-sources.c (unexpected output)
+ FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+ -file-list-exec-source-files --group-by-objfile, look for \
+ mi-info-sources-base.c (unexpected output)
+ ...
+ due to openSUSE executables which have debug info for objects from sources
+ like sysdeps/x86_64/crtn.S.
+
+ Fix these by updating the patterns, and adding "maint expand-symtabs" to
+ reliably get fully-read objfiles.
+
+ Then I run into FAILs when using the readnow target board. Fix these by
+ skipping the relevant tests.
+
+ Then I run into FAILs when using the cc-with-gnu-debuglink board. Fix these
+ by updating the patterns.
+
+ Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index,
+ cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-05 Tom de Vries <tdevries@suse.de>
+
+ * lib/mi-support.exp (mi_readnow): New proc.
+ * gdb.mi/mi-info-sources.exp: Use nosharedlibrary. Update patterns.
+ Skip tests for readnow. Use "maint expand-symtabs".
+
+2021-07-12 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
+
+ testsuite: fix whitespace problems in gdb.mi/mi-break.exp
+ Replace leading 8-spaces with tab and remove trailing space in
+ gdb.mi/mi-break.exp.
+
+2021-07-12 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-11 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-10 Alan Modra <amodra@gmail.com>
+
+ Tidy commit 49910fd88dcd
+ Pointer range checking is UB if the values compared are outside the
+ underlying array elements (plus one).
+
+ * dwarf2.c (read_address): Remove accidental commit.
+ (read_ranges): Compare offset rather than pointers.
+
+2021-07-10 Alan Modra <amodra@gmail.com>
+
+ PR28069, assertion fail in dwarf.c:display_discr_list
+ We shouldn't be asserting on anything to do with leb128 values, or
+ reporting file and line numbers when something unexpected happens.
+ leb128 data is of indeterminate length, perfect for fuzzer mayhem.
+ It would only make sense to assert or report dwarf.c/readelf.c source
+ lines if the code had already sized and sanity checked the leb128
+ values.
+
+ After removing the assertions, the testcase then gave:
+
+ <37> DW_AT_discr_list : 5 byte block: 0 0 0 0 0 (label 0, label 0, label 0, label 0, <corrupt>
+ readelf: Warning: corrupt discr_list - unrecognized discriminant byte 0x5
+
+ <3d> DW_AT_encoding : 0 (void)
+ <3e> DW_AT_identifier_case: 0 (case_sensitive)
+ <3f> DW_AT_virtuality : 0 (none)
+ <40> DW_AT_decimal_sign: 5 (trailing separate)
+
+ So the DW_AT_discr_list was showing more data than just the 5 byte
+ block. That happened due to "end" pointing a long way past the end of
+ block, and uvalue decrementing past zero on one of the leb128 bytes.
+
+ PR 28069
+ * dwarf.c (display_discr_list): Remove assertions. Delete "end"
+ parameter, use initial "data" pointer as the end. Formatting.
+ Don't count down bytes as they are read.
+ (read_and_display_attr_value): Adjust display_discr_list call.
+ (read_and_print_leb128): Don't pass __FILE__ and __LINE__ to
+ report_leb_status.
+ * dwarf.h (report_leb_status): Don't report file and line
+ numbers. Delete file and lnum parameters,
+ (READ_ULEB, READ_SLEB): Adjust.
+
+2021-07-10 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-09 H.J. Lu <hjl.tools@gmail.com>
+
+ ld/NEWS: Clarify -z [no]indirect-extern-access
+ -z [no]indirect-extern-access are only for x86 ELF linker.
+
+2021-07-09 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Limits 2 GNU_PROPERTY_1_NEEDED tests to Linux/x86
+ Run property-1_needed-1b.d and property-1_needed-1c.d, which pass
+ -z [no]indirect-extern-access to linker, only run for Linux/x86 targets.
+
+ * testsuite/ld-elf/property-1_needed-1b.d: Only run for
+ Linux/x86 targets.
+ * testsuite/ld-elf/property-1_needed-1c.d: Likewise.
+
+2021-07-09 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Add GNU_PROPERTY_1_NEEDED check
+ If GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS is set on any input
+ relocatable files:
+
+ 1. Don't generate copy relocations.
+ 2. Turn off extern_protected_data since it implies
+ GNU_PROPERTY_NO_COPY_ON_PROTECTED.
+ 3. Treate reference to protected symbols with indirect external access
+ as local.
+ 4. Set GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS on output.
+ 5. When generating executable, clear this bit when there are non-GOT or
+ non-PLT relocations in input relocatable files without the bit set.
+ 6. Add -z [no]indirect-extern-access to control indirect external access.
+
+ bfd/
+
+ * elf-bfd (elf_obj_tdata): Add has_indirect_extern_access.
+ (elf_has_indirect_extern_access): New.
+ * elf-properties.c (_bfd_elf_parse_gnu_properties): Set
+ elf_has_indirect_extern_access and elf_has_no_copy_on_protected
+ when seeing GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+ (elf_write_gnu_propertie): Add an argument to pass link_info.
+ Set needed_1_p for GNU_PROPERTY_1_NEEDED in memory.
+ (_bfd_elf_link_setup_gnu_properties): Handle
+ GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS for
+ -z indirect-extern-access. Set nocopyreloc to true and
+ extern_protected_data to false for indirect external access.
+ (_bfd_elf_convert_gnu_properties): Updated.
+ * elf32-i386.c (elf_i386_check_relocs): Set
+ non_got_ref_without_indirect_extern_access on legacy non-GOT or
+ non-PLT references.
+ * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+ * elflink.c (_bfd_elf_symbol_refs_local_p): Return true for
+ STV_PROTECTED symbols with indirect external access.
+ * elfxx-x86.c (_bfd_x86_elf_adjust_dynamic_symbol): Clear
+ indirect_extern_access for legacy non-GOT/non-PLT references.
+ * elfxx-x86.h (elf_x86_link_hash_entry): Add
+ non_got_ref_without_indirect_extern_access.
+
+ include/
+
+ * bfdlink.h (bfd_link_info): Add indirect_extern_access and
+ needed_1_p. Change nocopyreloc to int.
+
+ ld/
+
+ * NEWS: Mention -z [no]indirect-extern-access
+ * ld.texi: Document -z [no]indirect-extern-access
+ * ldmain.c (main): Initialize link_info.indirect_extern_access
+ to -1.
+ * emulparams/extern_protected_data.sh: Support
+ -z [no]indirect-extern-access.
+ * testsuite/ld-elf/indirect-extern-access-1.rd: New file
+ * testsuite/ld-elf/indirect-extern-access-1a.c: Likewise.
+ * testsuite/ld-elf/indirect-extern-access-1b.c: Likewise.
+ * testsuite/ld-elf/indirect-extern-access-2.rd: Likewise.
+ * testsuite/ld-elf/indirect-extern-access-2a.c: Likewise.
+ * testsuite/ld-elf/indirect-extern-access-2b.c: Likewise.
+ * testsuite/ld-elf/indirect-extern-access-3.rd: Likewise.
+ * testsuite/ld-elf/indirect-extern-access.S: Likewise.
+ * testsuite/ld-elf/property-1_needed-1b.d: Likewise.
+ * testsuite/ld-elf/property-1_needed-1c.d: Likewise.
+ * testsuite/ld-x86-64/indirect-extern-access.rd: Likewise.
+ * testsuite/ld-x86-64/protected-data-1.h: Likewise.
+ * testsuite/ld-x86-64/protected-data-1a.c: Likewise.
+ * testsuite/ld-x86-64/protected-data-1b.c: Likewise.
+ * testsuite/ld-x86-64/protected-data-2a.S: Likewise.
+ * testsuite/ld-x86-64/protected-data-2b.S: Likewise.
+ * testsuite/ld-x86-64/protected-func-2a.S: Likewise.
+ * testsuite/ld-x86-64/protected-func-2b.S: Likewise.
+ * testsuite/ld-x86-64/protected-func-2c.c: Likewise.
+ * testsuite/ld-elf/linux-x86.exp: Run test with
+ GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+ * testsuite/ld-x86-64/x86-64.exp: Run tests for protected
+ function and data with indirect external access.
+
+2021-07-09 H.J. Lu <hjl.tools@gmail.com>
+
+ elf: Add GNU_PROPERTY_1_NEEDED
+ Add GNU_PROPERTY_1_NEEDED:
+
+ #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
+
+ to indicate the needed properties by the object file.
+
+ Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS:
+
+ #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0)
+
+ to indicate that the object file requires canonical function pointers and
+ cannot be used with copy relocation.
+
+ binutils/
+
+ * readelf.c (decode_1_needed): New.
+ (print_gnu_property_note): Handle GNU_PROPERTY_1_NEEDED.
+
+ include/
+
+ * elf/common.h (GNU_PROPERTY_1_NEEDED): New.
+ (GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS): Likewise.
+
+ ld/
+
+ * testsuite/ld-elf/property-1_needed-1a.d: New file.
+ * testsuite/ld-elf/property-1_needed-1.s: Likewise.
+
+2021-07-09 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-09 Lancelot SIX <lsix@lancelotsix.com>
+
+ Remove unused parameter in maybe_software_singlestep
+ While working around, I noticed that the last parameter of
+ maybe_software_singlestep is never used. This path removes
+ it.
+
+ Built on x86_64-linux-gnu and riscv64-linux-gnu.
+
+ gdb/ChangeLog:
+
+ * infrun.c (maybe_software_singlestep): Remove unused PC
+ parameter.
+ (resume_1): Update calls to maybe_software_singlestep.
+
+2021-07-08 H.J. Lu <hjl.tools@gmail.com>
+
+ x86-64: Disallow PC reloc against weak undefined symbols in PIE
+ Disallow PC relocations against weak undefined symbols in PIE since they
+ can lead to non-zero address at run-time.
+
+ bfd/
+
+ PR ld/21782
+ * elf64-x86-64.c (elf_x86_64_relocate_section): Disallow PC
+ relocations against weak undefined symbols in PIE.
+
+ ld/
+
+ PR ld/21782
+ * testsuite/ld-x86-64/pie3.d: Expect linker error.
+
+2021-07-08 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Limit cache size and add --max-cache-size=SIZE
+ When link_info.keep_memory is true, linker caches the relocation
+ information and symbol tables of input files in memory. When there
+ are many input files with many relocations, we may run out of memory.
+ Add --max-cache-size=SIZE to set the maximum cache size.
+
+ bfd/
+
+ PR ld/18028
+ * bfd.c (bfd): Add alloc_size.
+ * elf-bfd.h (_bfd_elf_link_info_read_relocs): New.
+ * elf32-i386.c (elf_i386_check_relocs): Use _bfd_link_keep_memory.
+ Update cache_size.
+ * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+ * elflink.c (_bfd_elf_link_read_relocs): Renamed to ...
+ (_bfd_elf_link_info_read_relocs): This. Update cache_size.
+ (_bfd_elf_link_read_relocs): New.
+ (_bfd_elf_link_check_relocs): Call _bfd_elf_link_info_read_relocs
+ instead of _bfd_elf_link_read_relocs.
+ (elf_link_add_object_symbols): Likewise.
+ (elf_link_input_bfd): Likewise.
+ (init_reloc_cookie_rels): Likewise.
+ (init_reloc_cookie): Update cache_size. Call
+ _bfd_elf_link_info_read_relocs instead of
+ _bfd_elf_link_read_relocs.
+ (link_info_ok): New.
+ (elf_gc_smash_unused_vtentry_relocs): Updated. Call
+ _bfd_elf_link_info_read_relocs instead of
+ _bfd_elf_link_read_relocs.
+ (bfd_elf_gc_sections): Use link_info_ok. Pass &link_info_ok
+ to elf_gc_smash_unused_vtentry_relocs.
+ * libbfd-in.h (_bfd_link_keep_memory): New.
+ * linker.c (_bfd_link_keep_memory): New.
+ * opncls.c (bfd_alloc): Update alloc_size.
+ * bfd-in2.h: Regenerated.
+ * libbfd.h: Likewise.
+
+ include/
+
+ PR ld/18028
+ * bfdlink.h (bfd_link_info): Add cache_size and max_cache_size.
+
+ ld/
+
+ PR ld/18028
+ * NEWS: Mention --max-cache-size=SIZE.
+ * ld.texi: Document --max-cache-size=SIZE.
+ * ldlex.h (option_values): Add OPTION_MAX_CACHE_SIZE.
+ * ldmain.c: (main): Set link_info.max_cache_size to -1.
+ * lexsup.c (ld_options): Add --max-cache-size=SIZE.
+ (parse_args): Support OPTION_MAX_CACHE_SIZE.
+ * testsuite/ld-bootstrap/bootstrap.exp: Add test for
+ --max-cache-size=-1.
+
+2021-07-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_init
+ According to bug 28056, running an s390x binary gives:
+
+ (gdb) run
+ Starting program: /usr/bin/ls
+ /home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: internal-error: displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' failed.
+
+ This is because the s390 architecture registers some Linux-specific
+ displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:
+
+ set_gdbarch_displaced_step_prepare (gdbarch, linux_displaced_step_prepare);
+ set_gdbarch_displaced_step_finish (gdbarch, linux_displaced_step_finish);
+ set_gdbarch_displaced_step_restore_all_in_ptid
+ (gdbarch, linux_displaced_step_restore_all_in_ptid);
+
+ But then the Linux-specific s390_linux_init_abi_any passes
+ num_disp_step_buffers=0 to linux_init_abi:
+
+ linux_init_abi (info, gdbarch, 0);
+
+ The problem happens when linux_displaced_step_prepare is called for the
+ first time. It tries to allocate the displaced stepping buffers, but
+ sees that the number of displaced stepping buffers for that architecture
+ is 0, which is unexpected / invalid.
+
+ s390_gdbarch_init should not register the linux_* callbacks, that is
+ expected to be done by linux_init_abi. If debugging a bare-metal s390
+ program, or an s390 program on another OS GDB doesn't know about, we
+ wouldn't want to use them. We would either register no callbacks, if
+ displaced stepping isn't supported, or register a different set of
+ callbacks if we wanted to support displaced stepping in those cases.
+
+ The commit that refactored the displaced stepping machinery and
+ introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
+ ("gdb: move displaced stepping logic to gdbarch, allow starting
+ concurrent displaced steps"). However, even before that,
+ s390_gdbarch_init did:
+
+ set_gdbarch_displaced_step_location (gdbarch, linux_displaced_step_location);
+
+ ... which already seemed wrong. The Linux-specific callback was used
+ even for non-Linux system. Maybe that was on purpose, because it would
+ also happen to work in some other non-Linux case, or maybe it was simply
+ a mistake. I'll assume that this was a small mistake when
+ s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
+ ("s390: Split up s390-linux-tdep.c into two files").
+
+ Fix this by removing the setting of these displaced step callbacks from
+ s390_gdbarch_init. Instead, pass num_disp_step_buffers=1 to
+ linux_init_abi, in s390_linux_init_abi_any. Doing so will cause
+ linux_init_abi to register these same callbacks. It will also mean that
+ when debugging a bare-metal s390 executable or an executable on another
+ OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
+ set, so displaced stepping won't be used.
+
+ This patch will need to be merged in the gdb-11-branch, since this is a
+ GDB 11 regression, so here's the ChangeLog entry:
+
+ gdb/ChangeLog:
+
+ * s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
+ of displaced stepping buffers to linux_init_abi.
+ * s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
+ displaced-stepping gdbarch callbacks.
+
+ Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
+ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056
+
+2021-07-08 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/Makefile.in: remove testsuite from SUBDIRS
+ When distclean-ing a configured / built gdb directory, like so:
+
+ $ ./configure && make all-gdb && make distclean
+
+ The distclean operation fails with:
+
+ Missing testsuite/Makefile
+
+ If we look at the SUBDIRS variable in the generated gdb/Makefile,
+ testsuite is there twice:
+
+ SUBDIRS = doc testsuite data-directory testsuite
+
+ So we try distclean-ing the testsuite directory twice. The second time,
+ gdb/testsuite/Makefile doesn't exist, so it fails.
+
+ The first "testsuite" comes from the @subdirs@ replacement, because of
+ the `AC_CONFIG_SUBDIRS` macro in gdb/configure.ac. The second one is
+ hard-coded in gdb/Makefile.in:
+
+ SUBDIRS = doc @subdirs@ data-directory testsuite
+
+ The hard-coded was added by:
+
+ bdbbcd577460 ("Always build 'all' in gdb/testsuite")
+
+ which came after `testsuite` was removed from @subdirs@ by:
+
+ f99d1d37496f ("Remove gdb/testsuite/configure")
+
+ My commit a100a94530eb ("gdb/testsuite: restore configure script")
+ should have removed the hard-coded `testsuite`, since it added it back
+ as a "subdir", but I missed it because I only looked f99d1d37496f to
+ write my patch.
+
+ Fix this by removing the hard-coded one.
+
+ This patch should be pushed to both master and gdb-11-branch, hence the
+ ChangeLog entry:
+
+ gdb/ChangeLog:
+
+ * Makefile.in (SUBDIRS): Remove testsuite.
+
+ Change-Id: I63e5590b1a08673c646510b3ecc74600eae9f92d
+
+2021-07-08 Nick Clifton <nickc@redhat.com>
+
+ Updated Portuguese translation for the BFD sub-directory
+
+2021-07-08 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0
+ When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed
+ with guile 3.0, I run into:
+ ...
+ (gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M
+ ERROR: In procedure make-breakpoint:^M
+ In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
+ position 3: "BP_CATCHPOINT"^M
+ Error while executing Scheme code.^M
+ (gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \
+ create a catchpoint via the api
+ ...
+
+ The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second
+ line of the error message starts with the same prefix as the first:
+ ...
+ ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
+ position 3: "BP_CATCHPOINT"^M
+ ...
+
+ I observe the same difference in many other tests, f.i.:
+ ...
+ (gdb) gu (print (value-add i '()))^M
+ ERROR: In procedure value-add:^M
+ In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M
+ Error while executing Scheme code.^M
+ (gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion
+ ...
+ but it doesn't cause FAILs anywhere else.
+
+ Fix this by updating the regexp to make the "ERROR: " prefix optional.
+
+ Tested on x86_64-linux, with both guile 2.0 and 3.0.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-07 Tom de Vries <tdevries@suse.de>
+
+ * gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in
+ exception printing optional.
+
+2021-07-08 Mike Frysinger <vapier@gentoo.org>
+
+ sim: erc32: use libsim.a for common objects
+ We're starting to move more objects to the common build that sis did
+ not need before, so linking them is causing problems (when common
+ objects end up needing symbols from non-common objects). Switch it
+ to the libsim.a archive which will allow the link to pull out only
+ what it needs.
+
+2021-07-08 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-07 Nick Clifton <nickc@redhat.com>
+
+ Remove an accidental change to elfcode.h included as part of commit 6e0dfbf420.
+ PR 27659
+ * elfcode.h (elf_swap_symbol_out): Revert accidental change that
+ removed an abort if the shndx pointer is NULL.
+
+2021-07-07 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Check archive only for archive member
+ Since plugin_maybe_claim calls bfd_close on the original input BFD if it
+ isn't an archive member, pass NULL to bfd_plugin_close_file_descriptor
+ to indicate that the BFD isn't an archive member.
+
+ bfd/
+
+ PR ld/18028
+ * plugin.c (bfd_plugin_close_file_descriptor): Check archive
+ only of abfd != NULL.
+ (try_claim): Pass NULL to bfd_plugin_close_file_descriptor if
+ it isn't an archive member.
+
+ ld/
+
+ PR ld/18028
+ * plugin.c (plugin_input_file): Add comments for abfd and ibfd.
+ (plugin_object_p): Set input->ibfd to NULL if it isn't an
+ archive member.
+
+2021-07-07 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ Add changelog entries for last commit
+
+2021-07-07 Andreas Krebbel <krebbel@linux.ibm.com>
+
+ IBM Z: Add another arch14 instruction
+ opcodes/
+
+ * opcodes/s390-opc.txt: Add qpaci.
+
+ gas/
+
+ * testsuite/gas/s390/zarch-arch14.d: Add qpaci.
+ * testsuite/gas/s390/zarch-arch14.s: Add qpaci.
+
+2021-07-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Fix Solaris gprof build with --disable-nls
+ gprof fails to compile on Solaris 10 and 11.3 with --disable-nls:
+
+ In file included from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/gprof.h:33,
+ from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/basic_blocks.c:24:
+ /usr/include/libintl.h:45:14: error: expected identifier or '(' before 'const'
+ 45 | extern char *dcgettext(const char *, const char *, const int);
+ | ^~~~~~~~~
+ /usr/include/libintl.h:46:14: error: expected identifier or '(' before 'const'
+ 46 | extern char *dgettext(const char *, const char *);
+ | ^~~~~~~~
+ /usr/include/libintl.h:47:14: error: expected identifier or '(' before 'const'
+ 47 | extern char *gettext(const char *);
+ | ^~~~~~~
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:33:
+ error: expected identifier or '(' before 'do'
+ 165 | # define textdomain(Domainname) do {} while (0)
+ | ^~
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:39:
+ error: expected identifier or '(' before 'while'
+ 165 | # define textdomain(Domainname) do {} while (0)
+ | ^~~~~
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:46:
+ error: expected identifier or '(' before 'do'
+ 166 | # define bindtextdomain(Domainname, Dirname) do {} while (0)
+ | ^~
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:52:
+ error: expected identifier or '(' before 'while'
+ 166 | # define bindtextdomain(Domainname, Dirname) do {} while (0)
+ | ^~~~~
+ /usr/include/libintl.h:55:14: error: expected identifier or '(' before 'unsigned'
+ 55 | extern char *dcngettext(const char *, const char *,
+ | ^~~~~~~~~~
+ /usr/include/libintl.h:57:14: error: expected identifier or '(' before 'unsigned'
+ 57 | extern char *dngettext(const char *, const char *,
+ | ^~~~~~~~~
+ /usr/include/libintl.h:59:14: error: expected identifier or '(' before 'unsigned'
+ 59 | extern char *ngettext(const char *, const char *, unsigned long int);
+ | ^~~~~~~~
+
+ This is a known issue already partially fixed in binutils/sysdep.h. For
+ gprof, the same fix needs to be applied in bfd/sysdep.h, as the
+ following patch does. Tested on i386-pc-solaris2.10 and
+ i386-pc-solaris2.11.
+
+ 2021-07-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ bfd:
+ * sysdep.h [!ENABLE_NLS]: Prevent inclusion of <libintl.h> on
+ Solaris.
+
+2021-07-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ Check for strnlen declaration to fix Solaris 10 build
+ binutils currently fails to compile on Solaris 10:
+
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_debug_link_info_1':
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: implicit declaration of function 'strnlen' [-Werror=implicit-function-declaration]
+ 1231 | crc_offset = strnlen (name, size) + 1;
+ | ^~~~~~~
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_alt_debug_link_info':
+ /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1319:20: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
+ 1319 | buildid_offset = strnlen (name, size) + 1;
+ | ^~~~~~~
+
+ and in a couple of other places. The platform lacks strnlen, and while
+ libiberty.h can provide a fallback declaration, the necessary configure
+ test isn't run.
+
+ Fixed with the following patch. Tested on i386-pc-solaris2.10.
+
+ 2021-07-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ bfd:
+ * configure.ac: Check for strnlen declaration.
+ * configure, config.in: Regenerate.
+
+ binutils:
+ * configure.ac: Check for strnlen declaration.
+ * configure, config.in: Regenerate.
+
+2021-07-07 Nick Clifton <nickc@redhat.com>
+
+ Fix problems translating messages when a percentage sign appears at the end of a string.
+ PR 28051
+ gas * config/tc-i386.c (offset_in_range): Reformat error messages in
+ order to fix problems when translating.
+ (md_assemble): Likewise.
+ * messages.c (as_internal_value_out_of_range): Likewise.
+ * read.c (emit_expr_with_reloc): Likewise.
+ * testsuite/gas/all/overflow.l Change expected output format.
+ * po/gas.pot: Regenerate.
+
+ bfd * coff-rs6000.c (xcoff_reloc_type_tls): Reformat error messages in
+ order to fix problems when translating.
+ * cofflink.c (_bfd_coff_write_global_sym): Likewise.
+ * elfnn-aarch64.c (_bfd_aarch64_erratum_843419_branch_to_stub):
+ Likewise.
+ * po/bfd.pot: Regenerate.
+
+2021-07-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: introduce iterator_range, remove next_adapter
+ I was always a bit confused by next_adapter, because it kind of mixes
+ the element type and the iterator type. In reality, it is not much more
+ than a class that wraps two iterators (begin and end). However, it
+ assumes that:
+
+ - you can construct the begin iterator by passing a pointer to the
+ first element of the iterable
+ - you can default-construct iterator to make the end iterator
+
+ I think that by generalizing it a little bit, we can re-use it at more
+ places.
+
+ Rename it to "iterator_range". I think it describes a bit better: it's
+ a range made by wrapping a begin and end iterator. Move it to its own
+ file, since it's not related to next_iterator anymore.
+
+ iterator_range has two constructors. The variadic one, where arguments
+ are forwarded to construct the underlying begin iterator. The end
+ iterator is constructed through default construction. This is a
+ generalization of what we have today.
+
+ There is another constructor which receives already constructed begin
+ and end iterators, useful if the end iterator can't be obtained by
+ default-construction. Or, if you wanted to make a range that does not
+ end at the end of the container, you could pass any iterator as the
+ "end".
+
+ This generalization allows removing some "range" classes, like
+ all_inferiors_range. These classes existed only to pass some arguments
+ when constructing the begin iterator. With iterator_range, those same
+ arguments are passed to the iterator_range constructed and then
+ forwarded to the constructed begin iterator.
+
+ There is a small functional difference in how iterator_range works
+ compared to next_adapter. next_adapter stored the pointer it received
+ as argument and constructeur an iterator in the `begin` method.
+ iterator_range constructs the begin iterator and stores it as a member.
+ Its `begin` method returns a copy of that iterator.
+
+ With just iterator_range, uses of next_adapter<foo> would be replaced
+ with:
+
+ using foo_iterator = next_iterator<foo>;
+ using foo_range = iterator_range<foo_iterator>;
+
+ However, I added a `next_range` wrapper as a direct replacement for
+ next_adapter<foo>. IMO, next_range is a slightly better name than
+ next_adapter.
+
+ The rest of the changes are applications of this new class.
+
+ gdbsupport/ChangeLog:
+
+ * next-iterator.h (class next_adapter): Remove.
+ * iterator-range.h: New.
+
+ gdb/ChangeLog:
+
+ * breakpoint.h (bp_locations_range): Remove.
+ (bp_location_range): New.
+ (struct breakpoint) <locations>: Adjust type.
+ (breakpoint_range): Use iterator_range.
+ (tracepoint_range): Use iterator_range.
+ * breakpoint.c (breakpoint::locations): Adjust return type.
+ * gdb_bfd.h (gdb_bfd_section_range): Use iterator_range.
+ * gdbthread.h (all_threads_safe): Pass argument to
+ all_threads_safe_range.
+ * inferior-iter.h (all_inferiors_range): Use iterator_range.
+ (all_inferiors_safe_range): Use iterator_range.
+ (all_non_exited_inferiors_range): Use iterator_range.
+ * inferior.h (all_inferiors, all_non_exited_inferiors): Pass
+ inferior_list as argument.
+ * objfiles.h (struct objfile) <compunits_range>: Remove.
+ <compunits>: Return compunit_symtab_range.
+ * progspace.h (unwrapping_objfile_iterator)
+ <unwrapping_objfile_iterator>: Take parameter by value.
+ (unwrapping_objfile_range): Use iterator_range.
+ (struct program_space) <objfiles_range>: Define with "using".
+ <objfiles>: Adjust.
+ <objfiles_safe_range>: Define with "using".
+ <objfiles_safe>: Adjust.
+ <solibs>: Return so_list_range, define here.
+ * progspace.c (program_space::solibs): Remove.
+ * psymtab.h (class psymtab_storage) <partial_symtab_iterator>:
+ New.
+ <partial_symtab_range>: Use iterator_range.
+ * solist.h (so_list_range): New.
+ * symtab.h (compunit_symtab_range):
+ New.
+ (symtab_range): New.
+ (compunit_filetabs): Change to a function.
+ * thread-iter.h (inf_threads_range,
+ inf_non_exited_threads_range, safe_inf_threads_range,
+ all_threads_safe_range): Use iterator_range.
+ * top.h (ui_range): New.
+ (all_uis): Use ui_range.
+
+ Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
+
+2021-07-06 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb/testsuite: restore configure script
+ Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed
+ gdb/testsuite/configure, as anything gdb/testsuite/configure did could
+ be done by gdb/configure.
+
+ There is however one use case that popped up when this changed
+ propagated to downstream consumers, to run the testsuite on an already
+ built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built
+ in a CI job. This GDB package is then tested on different machines /
+ hardware configurations as part of other CI jobs. To achieve this,
+ those CI jobs only configure the testsuite directory and run "make
+ check" with an appropriate board file.
+
+ In light of this use case, the way I see it is that gdb/testsuite could
+ be considered its own project. It could be stored in a completely
+ different repo if we want to, it just happens to be stored inside gdb/.
+
+ Since the only downside of having gdb/testsuite/configure is that it
+ takes a few more seconds to run, but on the other hand it's quite useful
+ for some people, I propose re-adding it.
+
+ In a sense, this is revert of f99d1d37496f, but it's not a direct
+ git-revert, as some things have changed since.
+
+ gdb/ChangeLog:
+
+ * configure.ac: Remove things that were moved from
+ testsuite/configure.ac.
+ * configure: Re-generate.
+
+ gdb/testsuite/ChangeLog:
+
+ * configure.ac: Restore.
+ * configure: Re-generate.
+ * aclocal.m4: Re-generate.
+ * Makefile.in (distclean): Add config.status.
+ (Makefile): Adjust paths.
+ (lib/pdtrace): Adjust paths.
+ (config.status): Add.
+
+ Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1
+
+2021-07-06 Joel Brobecker <brobecker@adacore.com>
+
+ Rename gdb/ChangeLog to gdb/ChangeLog-2021
+ Now that ChangeLog entries are no longer used for GDB patches,
+ this commit renames the file gdb/ChangeLog to gdb/ChangeLog-2021,
+ similar to what we would do in the context of the "Start of New
+ Year" procedure.
+
+ The purpose of this change is to avoid people merging ChangeLog
+ entries by mistake when applying existing commits that they are
+ currently working on.
+
+2021-07-06 Dan Streetman <ddstreet@canonical.com>
+
+ sim: ppc: add missing empty targets
+ These are copied from sim/common/Make-common.in.
+
+ On ppc the build fails without at least the 'info' target, e.g.:
+
+ Making info in ppc
+ make[4]: Entering directory '/<<BUILDDIR>>/gdb-10.2.2974.g5b45e89f56d+21.10.20210510155809/build/default/sim/ppc'
+ make[4]: *** No rule to make target 'info'. Stop.
+
+2021-07-06 Yuri Chornoivan <yurchor@ukr.net>
+
+ PR 28053: Fix spelling mistakes: usupported -> unsupported and relocatation -> relocation.
+
+2021-07-06 Michael Matz <matz@suse.de>
+
+ elf/riscv: Fix relaxation with aliases [PR28021]
+ the fix for PR22756 only changed behaviour for hidden aliases,
+ but the same situation exists for non-hidden aliases: sym_hashes[]
+ can contain multiple entries pointing to the same symbol structure
+ leading to relaxation adjustment to be applied twice.
+
+ Fix this by testing for duplicates for everything that looks like it
+ has a version.
+
+ PR ld/28021
+
+ bfd/
+ * elfnn-riscv.c (riscv_relax_delete_bytes): Check for any
+ versioning.
+
+ ld/
+ * testsuite/ld-riscv-elf/relax-twice.ver: New.
+ * testsuite/ld-riscv-elf/relax-twice-1.s: New.
+ * testsuite/ld-riscv-elf/relax-twice-2.s: New.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp
+ (run_relax_twice_test): New, and call it.
+
+2021-07-06 Pedro Alves <pedro@palves.net>
+ Qingchuan Shi <qingchuan.shi@amd.com>
+
+ Update gdb performance testsuite to be compatible with Python 3.8
+ Running "make check-perf" on a system with Python 3.8 (e.g., Ubuntu
+ 20.04) runs into this Python problem:
+
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
+ self.execute_test()
+ File "<string>", line 35, in execute_test
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
+ m.start(id)
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
+ self.start_time = time.clock()
+ AttributeError: module 'time' has no attribute 'clock'
+ Error while executing Python code.
+ (gdb) FAIL: gdb.perf/single-step.exp: python SingleStep(1000).run()
+
+ ... many times over.
+
+ The problem is that the testsuite is using time.clock(), deprecated in
+ Python 3.3 and finaly removed in Python 3.8. The guidelines say to
+ use time.perf_counter() or time.process_time() instead depending on
+ requirements. Looking at the current description of those functions,
+ at:
+
+ https://docs.python.org/3.10/library/time.html
+
+ we have:
+
+ time.perf_counter() -> float
+
+ Return the value (in fractional seconds) of a performance
+ counter, i.e. a clock with the highest available resolution to
+ measure a short duration. It does include time elapsed during
+ sleep and is system-wide. (...)
+
+ time.process_time() -> float
+
+ Return the value (in fractional seconds) of the sum of the
+ system and user CPU time of the current process. It does not
+ include time elapsed during sleep. It is process-wide by
+ definition. (...)
+
+ I'm thinking that it's just best to record both instead of picking
+ one. So this patch replaces the MeasurementCpuTime measurement class
+ with two new classes -- MeasurementPerfCounter and
+ MeasurementProcessTime. Correspondingly, this changes the reports in
+ testsuite/perftest.log -- we have two new "perf_counter" and
+ "process_time" measurements and the "cpu_time" measurement is gone. I
+ don't suppose breaking backward compatibility here is a big problem.
+ I suspect no one is really tracking long term performance using the
+ perf testsuite today. And if they are, it shouldn't be hard to adjust.
+
+ For backward compatility, with Python < 3.3, both perf_counter and
+ process_time use the old time.clock.
+
+ gdb/testsuite/ChangeLog:
+ yyyy-mm-dd Qingchuan Shi <qingchuan.shi@amd.com>
+ Pedro Alves <pedro@palves.net>
+
+ * gdb.perf/lib/perftest/perftest.py: Import sys.
+ (time.perf_counter, time.process_time): Map to time.clock on
+ Python < 3.3.
+ (MeasurementCpuTime): Delete, replaced by...
+ (MeasurementPerfCounter, MeasurementProcessTime): .. these two new
+ classes.
+ * gdb.perf/lib/perftest/perftest.py: Import MeasurementPerfCounter
+ and MeasurementProcessTime instead of MeasurementCpuTime.
+ (TestCaseWithBasicMeasurements): Use MeasurementPerfCounter and
+ MeasurementProcessTime instead of MeasurementCpuTime.
+
+
+ Change-Id: Ia850c05d5ce57d2dada70ba5b0061f566444aa2b
+
+2021-07-06 Pedro Alves <pedro@palves.net>
+
+ gdb.perf/: FAIL on Python errors, avoid "ERROR: internal buffer is full"
+ Currently, if you run make check-perf on a system with Python 3.8,
+ tests seen to PASS, but they actually test a lot less than intended,
+ due to:
+
+ PerfTest::assemble, run ...
+ python BackTrace(64).run()
+ Traceback (most recent call last):
+ File "<string>", line 1, in <module>
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
+ self.execute_test()
+ File "<string>", line 49, in execute_test
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
+ m.start(id)
+ File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
+ self.start_time = time.clock()
+ AttributeError: module 'time' has no attribute 'clock'
+ Error while executing Python code.
+ (gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run()
+
+ And then, after fixing the above Python compatibility issues (which
+ will be a separate patch), I get 86 instances of overflowing expect's
+ buffer, like:
+
+ ERROR: internal buffer is full.
+ UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run()
+
+ This patch fixes both problems by adding & using a gdb_test_python_run
+ routine that:
+
+ - checks for Python errors
+ - consumes output line by line
+
+ gdb/testsuite/ChangeLog:
+ yyyy-mm-dd Pedro Alves <pedro@palves.net>
+
+ * gdb.perf/backtrace.exp: Use gdb_test_python_run.
+ * gdb.perf/disassemble.exp: Use gdb_test_python_run.
+ * gdb.perf/single-step.exp: Use gdb_test_python_run.
+ * gdb.perf/skip-command.exp: Use gdb_test_python_run.
+ * gdb.perf/skip-prologue.exp: Use gdb_test_python_run.
+ * gdb.perf/solib.exp: Use gdb_test_python_run.
+ * gdb.perf/template-breakpoints.exp: Use gdb_test_python_run.
+ * lib/perftest.exp (gdb_test_python_run): New.
+
+ Change-Id: I007af36f164b3f4cda41033616eaaa4e268dfd2f
+
+2021-07-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Remove read1 timeout factor from gdb.base/info-macros.exp
+ At the moment some check-read1 timeouts are handled like this in
+ gdb.base/info-macros.exp:
+ ...
+ gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname {
+ -re "$r1$r2$r3" {
+ pass $testname
+ }
+ -re ".*#define TWO.*\r\n$gdb_prompt" {
+ fail $testname
+ }
+ -re ".*#define THREE.*\r\n$gdb_prompt" {
+ fail $testname
+ }
+ -re ".*#define FOUR.*\r\n$gdb_prompt" {
+ fail $testname
+ }
+ }
+ ...
+ which is not ideal.
+
+ We could use gdb_test_lines, but it currently doesn't support verifying
+ the absence of regexps, which is done using the clauses above calling fail.
+
+ Fix this by using gdb_test_lines and adding a -re-not syntax to
+ gdb_test_lines, such that we can do:
+ ...
+ gdb_test_lines $test $testname $r1.*$r2 \
+ -re-not "#define TWO" \
+ -re-not "#define THREE" \
+ -re-not "#define FOUR"
+ ...
+
+ Tested on x86_64-linux, whith make targets check and check-read1.
+
+ Also observed that check-read1 execution time is reduced from 6m35s to 13s.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-06 Tom de Vries <tdevries@suse.de>
+
+ * gdb.base/info-macros.exp: Replace use of
+ gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines.
+ (gdb_test_multiple_with_read1_timeout_factor): Remove.
+ * lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>.
+
+2021-07-06 Nelson Chu <nelson.chu@sifive.com>
+
+ RISC-V: Fix the build broken with -Werror.
+ ChangeLog:
+
+ bfd/
+
+ * elfnn-riscv.c(riscv_elf_additional_program_headers): Removed the
+ unused variable s.
+ (riscv_elf_modify_segment_map): Added ATTRIBUTE_UNUSED for the
+ unused parameter info.
+
+2021-07-06 Tom de Vries <tdevries@suse.de>
+
+ [gdb/symtab] Fix skipping of import of C++ CU
+ Tom Tromey observed that when changing the language in
+ gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed.
+
+ This is due to this code in process_imported_unit_die:
+ ...
+ /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
+ into another compilation unit, at root level. Regard this as a hint,
+ and ignore it. */
+ if (die->parent && die->parent->parent == NULL
+ && per_cu->unit_type == DW_UT_compile
+ && per_cu->lang == language_cplus)
+ return;
+ ...
+ which should have a partial symtabs counterpart.
+
+ Add the missing counterpart in process_psymtab_comp_unit.
+
+ Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config:
+ - using default gcc version 7.5.0
+ (with 5 unexpected FAILs)
+ - gcc 10.3.0 and target board
+ unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects
+ (with 1000 unexpected FAILs)
+
+ gdb/ChangeLog:
+
+ 2021-07-06 Tom de Vries <tdevries@suse.de>
+
+ * dwarf2/read.c (scan_partial_symbols): Skip top-level imports of
+ c++ CU.
+ * testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ...
+ * testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here.
+ * testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test.
+ * testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test.
+ * testsuite/gdb.dwarf2/imported-unit.exp: Update.
+
+2021-07-06 Kito Cheng <kito.cheng@sifive.com>
+
+ RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR.
+ We added PT_RISCV_ATTRIBUTES to program header to make
+ .riscv.attribute easier to find in dynamic loader or kernel.
+
+ Ref:
+ https://github.com/riscv/riscv-elf-psabi-doc/pull/71
+
+ ChangeLog:
+
+ bfd/
+
+ * elfnn-riscv.c(RISCV_ATTRIBUTES_SECTION_NAME): New.
+ (riscv_elf_additional_program_headers): Ditto.
+ (riscv_elf_modify_segment_map): Ditto.
+ (elf_backend_additional_program_headers): Ditto.
+ (elf_backend_modify_segment_map): Ditto.
+ (elf_backend_obj_attrs_section): Use RISCV_ATTRIBUTES_SECTION_NAME
+ rather than string literal.
+
+ binutils/
+
+ * readelf.c(get_riscv_segment_type): New.
+ (get_segment_type): Handle EM_RISCV.
+
+ include/
+
+ * elf/riscv.h (PT_RISCV_ATTRIBUTES): New.
+ * testsuite/ld-elf/orphan-region.ld: Discard .riscv.attributes
+ section for simplify testcase.
+ * testsuite/ld-riscv-elf/attr-phdr.d: New.
+ * testsuite/ld-riscv-elf/attr-phdr.s: Ditto.
+ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Add attr-phdr to
+ testcase.
+
+2021-07-06 Alan Modra <amodra@gmail.com>
+
+ Re: PR28055, segfault in bpf special reloc function
+ PR 28055
+ * elf64-bpf.c (bpf_elf_generic_reloc): Add missing ATTRIBUTE_UNUSED.
+
+2021-07-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-05 Tom Tromey <tom@tromey.com>
+
+ Simplify debug_names index writing
+ This changes the .debug_names writer to find the TU indices in the
+ main loop over all CUs and TUs. (An earlier patch applied this same
+ treatment to the .gdb_index writer.)
+
+ Simplify gdb_index writing
+ write_gdbindex writes the CUs first, then walks the signatured type
+ hash table to write out the TUs. However, now that CUs and TUs are
+ unified in the DWARF reader, it's simpler to handle both of these in
+ the same loop.
+
+ Minor cleanup to addrmap_index_data::previous_valid
+ This changes addrmap_index_data::previous_valid to a bool, and
+ initializes it inline.
+
+2021-07-05 Tom Tromey <tom@tromey.com>
+
+ Fix oddity in write_gdbindex
+ My recent patch to unify CUs and TUs introduced an oddity in
+ write_gdbindex. Here, we pass 'i' to recursively_write_psymbols, but
+ we must instead pass 'counter', to handle the situation where a TU is
+ mixed in with the CUs.
+
+ I am not sure a test case for this is possible. I think it can only
+ happen when using DWARF 5, where a TU appears in .debug_info.
+ However, this situation is already not handled correctly by
+ .gdb_index. I filed a bug about this.
+
+2021-07-05 Tom Tromey <tom@tromey.com>
+
+ Fix warning in symtab.c
+ The compiler gives this warning when building symtab.c:
+
+ ../../binutils-gdb/gdb/symtab.c:4247:28: warning: 'to_match' may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+ This patch fixes the warning by adding a gdb_assert_not_reached.
+
+2021-07-05 H.J. Lu <hjl.tools@gmail.com>
+
+ ld: Cache and reuse the IR archive file descriptor
+ Linker plugin_object_p opens the IR archive for each IR archive member.
+ For GCC plugin, plugin_object_p closes the archive file descriptor. But
+ for LLVM plugin, the archive file descriptor remains open. If there are
+ 3000 IR archive members, there are 3000 file descriptors for them. We
+ can run out of file descriptors petty easily.
+
+ 1. Add archive_plugin_fd and archive_plugin_fd_open_count to bfd so that
+ we can cache and reuse the IR archive file descriptor for all IR archive
+ members in the archive.
+ 2. Add bfd_plugin_close_file_descriptor to properly close the IR archive
+ file descriptor.
+
+ bfd/
+
+ PR ld/28040
+ * archive.c (_bfd_archive_close_and_cleanup): Close the archive
+ plugin file descriptor if needed.
+ * bfd.c (bfd): Add archive_plugin_fd and
+ archive_plugin_fd_open_count.
+ * opncls.c (_bfd_new_bfd): Initialize to -1.
+ * plugin.c (bfd_plugin_open_input): Cache and reuse the archive
+ plugin file descriptor.
+ (bfd_plugin_close_file_descriptor): New function.
+ (try_claim): Call bfd_plugin_close_file_descriptor.
+ * plugin.h (bfd_plugin_close_file_descriptor): New.
+ * bfd-in2.h: Regenerated.
+
+ ld/
+
+ PR ld/28040
+ * plugin.c (plugin_input_file): Add ibfd.
+ (release_plugin_file_descriptor): New function.
+ (release_input_file): Call release_plugin_file_descriptor to
+ close input->fd.
+ (plugin_object_p): Call release_plugin_file_descriptor to close
+ input->fd. Also call release_plugin_file_descriptor if not
+ claimed.
+ * testsuite/config/default.exp (RANLIB): New.
+ * testsuite/ld-plugin/lto.exp: Run ranlib test.
+
+2021-07-05 Nick Clifton <nickc@redhat.com>
+
+ Restore the libiberty component of commit 50ad1254d5030d0804cbf89c758359ae202e8d55.
+ This commit has not yet been applied to the master sources in the gcc repository.
+ It was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html
+ The commit allows options to be set for the AR and RANLIB programs used when building libiberty, which in turn allows building with LTO enabled.
+
+ Updated translations (mainly Ukranian and French) triggered by creation of 2.37 branch.
+
+2021-07-05 Tom de Vries <tdevries@suse.de>
+
+ [gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7
+ Since commit 05b85772061 "gdb/fortran: Add type info of formal parameter for
+ clang" I see:
+ ...
+ (gdb) ptype say_string^M
+ type = void (character*(*), integer(kind=4))^M
+ (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string
+ ...
+
+ The part of the commit causing the fail is:
+ ...
+ gdb_test "ptype say_string" \
+ - "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)"
+ + "type = void \\(character\[^,\]+, $integer8\\)"
+ ...
+ which fails to take into account that for gcc-7 and before, the type for
+ string length of a string argument is int, not size_t.
+
+ Fix this by allowing both $integer8 and $integer4.
+
+ Tested on x86_64-linux, with gcc-7 and gcc-10.
+
+ gdb/testsuite/ChangeLog:
+
+ 2021-07-05 Tom de Vries <tdevries@suse.de>
+
+ * gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and
+ $integer4 for size of string length.
+
+2021-07-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: fall back on sigpending + sigwait if sigtimedwait is not available
+ The macOS platform does not provide sigtimedwait, so we get:
+
+ CXX compile/compile.o
+ In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
+ /Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
+ sigtimedwait (&set, nullptr, &zero_timeout);
+ ^
+
+ An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
+ to first check which signals are pending, and then sigwait, to consume
+ them. Since that's slightly more expensive (2 syscalls instead of 1),
+ keep using sigtimedwait for the platforms that provide it, and fall back
+ to sigpending + sigwait for the others.
+
+ gdbsupport/ChangeLog:
+
+ * scoped_ignore_signal.h (struct scoped_ignore_signal)
+ <~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
+ is defined, else use sigpending + sigwait.
+
+ Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87
+ Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-07-05 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdbsupport/common.m4: check for sigtimedwait
+ The next patch will make the use of sigtimedwait conditional to whether
+ the platform provides it. Start by adding a configure check for it.
+
+ gdbsupport/ChangeLog:
+
+ * common.m4 (GDB_AC_COMMON): Check for sigtimedwait.
+ * config.in, configure: Re-generate.
+
+ gdb/ChangeLog:
+
+ * config.in, configure: Re-generate.
+
+ gdbserver/ChangeLog:
+
+ * config.in, configure: Re-generate.
+
+ Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05
+
+2021-07-05 Alan Modra <amodra@gmail.com>
+
+ Re: opcodes: constify & local meps macros
+ Commit f375d32b35ce changed a generated file. Edit the source instead.
+
+ * mep.opc (macros): Make static and const.
+ (lookup_macro): Return and use const pointer.
+ (expand_macro): Make mac param const.
+ (expand_string): Make pmacro const.
+
+2021-07-05 Alan Modra <amodra@gmail.com>
+
+ PR28055, segfault in bpf special reloc function
+ The testcase in this PR tickled two bugs fixed here. output_bfd is
+ NULL when a reloc special_function is called for final linking and
+ when called from bfd_generic_get_relocated_section_contents. Clearly
+ using output_bfd is wrong as it results in segfaults. Not only that,
+ the endianness of the reloc field really should be that of the input.
+ The second bug was not checking that the entire reloc field was
+ contained in the section contents.
+
+ PR 28055
+ * elf64-bpf.c (bpf_elf_generic_reloc): Use correct bfd for bfd_put
+ and bfd_put_32 calls. Correct section limit checks.
+
+2021-07-05 Alan Modra <amodra@gmail.com>
+
+ PR28047, readelf crash due to assertion failure
+ DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref1, and
+ DW_FORM_ref_udata are all supposed to be within the containing unit.
+
+ PR 28047
+ * dwarf.c (get_type_abbrev_from_form): Add cu_end parameter.
+ Check DW_FORM_ref1 etc. arg against cu_end rather than end of
+ section. Adjust all callers.
+
+2021-07-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-04 Simon Marchi <simon.marchi@polymtl.ca>
+
+ gdb: return early if no execution in darwin_solib_create_inferior_hook
+ When loading a file using the file command on macOS, we get:
+
+ $ ./gdb -nx --data-directory=data-directory -q -ex "file ./test"
+ Reading symbols from ./test...
+ Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test...
+ /Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
+ A problem internal to GDB has been detected,
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n)
+
+ The backtrace is:
+
+ * frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3
+ frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3
+ frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31
+ frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34
+ frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5
+ frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3
+ frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7
+ frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3
+ frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3
+ frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7
+ frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2
+ frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7
+ frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9
+ frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3
+ frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3
+ frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7
+ frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10
+ frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1
+
+ The solib_create_inferior_hook call in symbol_file_command was added by
+ commit ea142fbfc9c1 ("Fix breakpoints on file reloads for PIE
+ binaries"). It causes solib_create_inferior_hook to be called while
+ the inferior is not running, which darwin_solib_create_inferior_hook
+ does not expect. darwin_solib_get_all_image_info_addr_at_init, in
+ particular, assumes that there is a current thread, as it tries to get
+ the current thread's regcache.
+
+ Fix it by adding a target_has_execution check and returning early. Note
+ that there is a similar check in svr4_solib_create_inferior_hook.
+
+ gdb/ChangeLog:
+
+ * solib-darwin.c (darwin_solib_create_inferior_hook): Return
+ early if no execution.
+
+ Change-Id: Ia11dd983a1e29786e5ce663d0fcaa6846dc611bb
+
+2021-07-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2021-07-03 H.J. Lu <hjl.tools@gmail.com>
+
+ gprof: Regenerate configure
+ * configure: Regenerated.
+
+2021-07-03 Joel Brobecker <brobecker@adacore.com>
+
+ Update NEWS post GDB 11 branch creation.
+ gdb/ChangeLog:
+
+ * NEWS: Create a new section for the next release branch.
+ Rename the section of the current branch, now that it has
+ been cut.
+
+2021-07-03 Joel Brobecker <brobecker@adacore.com>
+
+ Bump version to 12.0.50.DATE-git.
+ Now that the GDB 11 branch has been created, we can
+ bump the version number.
+
+ gdb/ChangeLog:
+
+ GDB 11 branch created (4b51505e33441c6165e7789fa2b6d21930242927):
+ * version.in: Bump version to 12.0.50.DATE-git.
+
+ gdb/testsuite/ChangeLog:
+
+ * gdb.base/default.exp: Change $_gdb_major to 12.
+
+2021-07-03 Tom Tromey <tom@tromey.com>
+
+ Use 'bool' more idiomatically in dwarf_decode_lines
+ I noticed a couple of spots related to dwarf_decode_lines where the
+ 'include_p' field was not being used idiomatically -- it is of type
+ bool now, so treat it as such.
+
+ gdb/ChangeLog
+ 2021-07-03 Tom Tromey <tom@tromey.com>
+
+ * dwarf2/read.c (lnp_state_machine::record_line): Use 'true'.
+ (dwarf_decode_lines): Remove '=='.
+
+2021-07-03 Nick Clifton <nickc@redhat.com>
+
+ More minor updates to the how-to-make-a-release documentation
+
+ Update version number and regenerate files
+
+ Add markers for 2.37 branch
+
+ Synchronize libiberty sources (and include/demangle.h) with GCC master version
projects / thirdparty / binutils-gdb.git / commitdiff
